Merge tag 'nfsd-6.3-6' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
Pull nfsd fixes from Chuck Lever:
- Address two issues with the new GSS krb5 Kunit tests
* tag 'nfsd-6.3-6' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
SUNRPC: Fix failures of checksum Kunit tests
sunrpc: Fix RFC6803 encryption test
diff --git a/.clang-format b/.clang-format
index b628364..d988e9f 100644
--- a/.clang-format
+++ b/.clang-format
@@ -190,6 +190,7 @@
- 'for_each_active_dev_scope'
- 'for_each_active_drhd_unit'
- 'for_each_active_iommu'
+ - 'for_each_active_route'
- 'for_each_aggr_pgid'
- 'for_each_available_child_of_node'
- 'for_each_bench'
@@ -225,7 +226,6 @@
- 'for_each_console_srcu'
- 'for_each_cpu'
- 'for_each_cpu_and'
- - 'for_each_cpu_not'
- 'for_each_cpu_wrap'
- 'for_each_dapm_widgets'
- 'for_each_dedup_cand'
diff --git a/.gitattributes b/.gitattributes
index 4b32eaa..c9ba5bf 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,4 +1,4 @@
-*.c diff=cpp
-*.h diff=cpp
-*.dtsi diff=dts
-*.dts diff=dts
+# SPDX-License-Identifier: GPL-2.0-only
+*.[ch] diff=cpp
+*.dts diff=dts
+*.dts[io] diff=dts
diff --git a/.gitignore b/.gitignore
index 20dce5c..70ec603 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,7 +4,7 @@
# subdirectories here. Add them in the ".gitignore" file
# in that subdirectory instead.
#
-# NOTE! Please use 'git ls-files -i --exclude-standard'
+# NOTE! Please use 'git ls-files -i -c --exclude-per-directory=.gitignore'
# command after changing this file, to see if there are
# any tracked files which get ignored after the change.
#
@@ -16,6 +16,7 @@
*.bin
*.bz2
*.c.[012]*.*
+*.cover
*.dt.yaml
*.dtb
*.dtbo
@@ -33,6 +34,7 @@
*.lz4
*.lzma
*.lzo
+*.mbx
*.mod
*.mod.c
*.o
@@ -76,6 +78,7 @@
# RPM spec file (make rpm-pkg)
#
/*.spec
+/rpmbuild/
#
# Debian directory (make deb-pkg)
diff --git a/.mailmap b/.mailmap
index a872c96..e424863 100644
--- a/.mailmap
+++ b/.mailmap
@@ -28,6 +28,7 @@
Alexander Mikhalitsyn <alexander@mihalicyn.com> <alexander.mikhalitsyn@virtuozzo.com>
Alexander Mikhalitsyn <alexander@mihalicyn.com> <aleksandr.mikhalitsyn@canonical.com>
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
+Alexandre Ghiti <alex@ghiti.fr> <alexandre.ghiti@canonical.com>
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
@@ -121,6 +122,7 @@
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
<dev.kurt@vandijck-laurijssen.be> <kurt.van.dijck@eia.be>
+Dikshita Agarwal <quic_dikshita@quicinc.com> <dikshita@codeaurora.org>
Dmitry Baryshkov <dbaryshkov@gmail.com>
Dmitry Baryshkov <dbaryshkov@gmail.com> <[dbaryshkov@gmail.com]>
Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_baryshkov@mentor.com>
@@ -131,10 +133,15 @@
Domen Puncer <domen@coderock.org>
Douglas Gilbert <dougg@torque.net>
Ed L. Cashin <ecashin@coraid.com>
+Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
+Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
+Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
+Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com>
+Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com>
Felipe W Damasio <felipewd@terra.com.br>
Felix Kuhling <fxkuehl@gmx.de>
Felix Moeller <felix@derklecks.de>
@@ -150,6 +157,7 @@
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@linux.alibaba.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@redhat.com>
+Georgi Djakov <djakov@kernel.org> <georgi.djakov@linaro.org>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@linux.vnet.ibm.com>
@@ -189,6 +197,7 @@
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
+Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
@@ -208,6 +217,9 @@
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
+Jiri Pirko <jiri@resnulli.us> <jiri@nvidia.com>
+Jiri Pirko <jiri@resnulli.us> <jiri@mellanox.com>
+Jiri Pirko <jiri@resnulli.us> <jpirko@redhat.com>
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>
@@ -253,7 +265,9 @@
Krzysztof Kozlowski <krzk@kernel.org> <krzysztof.kozlowski@canonical.com>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Kuogee Hsieh <quic_khsieh@quicinc.com> <khsieh@codeaurora.org>
+Leonard Crestez <leonard.crestez@nxp.com> Leonard Crestez <cdleonard@gmail.com>
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
+Leonard Göhrs <l.goehrs@pengutronix.de>
Leonid I Ananiev <leonid.i.ananiev@intel.com>
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
@@ -304,6 +318,8 @@
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
+Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@mellanox.com>
+Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@nvidia.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
Mayuresh Janorkar <mayur@ti.com>
@@ -367,6 +383,7 @@
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
Rajeev Nandan <quic_rajeevny@quicinc.com> <rajeevny@codeaurora.org>
+Rajendra Nayak <quic_rjendra@quicinc.com> <rnayak@codeaurora.org>
Rajesh Shah <rajesh.shah@intel.com>
Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
@@ -375,6 +392,9 @@
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
+Richard Leitner <richard.leitner@linux.dev> <dev@g0hl1n.net>
+Richard Leitner <richard.leitner@linux.dev> <me@g0hl1n.net>
+Richard Leitner <richard.leitner@linux.dev> <richard.leitner@skidata.com>
Robert Foss <rfoss@kernel.org> <robert.foss@linaro.org>
Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com>
Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com>
@@ -385,6 +405,7 @@
Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
+Sai Prakash Ranjan <quic_saipraka@quicinc.com> <saiprakash.ranjan@codeaurora.org>
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
Sam Ravnborg <sam@mars.ravnborg.org>
Sankeerth Billakanti <quic_sbillaka@quicinc.com> <sbillaka@codeaurora.org>
@@ -409,7 +430,10 @@
Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
-Stephen Hemminger <shemminger@osdl.org>
+Stephen Hemminger <stephen@networkplumber.org> <shemminger@linux-foundation.org>
+Stephen Hemminger <stephen@networkplumber.org> <shemminger@osdl.org>
+Stephen Hemminger <stephen@networkplumber.org> <sthemmin@microsoft.com>
+Stephen Hemminger <stephen@networkplumber.org> <sthemmin@vyatta.com>
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
@@ -422,6 +446,10 @@
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
Thomas Pedersen <twp@codeaurora.org>
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
+Tobias Klauser <tklauser@distanz.ch> <tobias.klauser@gmail.com>
+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>
Tony Luck <tony.luck@intel.com>
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
@@ -441,6 +469,7 @@
Vasily Averin <vasily.averin@linux.dev> <vvs@parallels.com>
Vasily Averin <vasily.averin@linux.dev> <vvs@sw.ru>
Valentin Schneider <vschneid@redhat.com> <valentin.schneider@arm.com>
+Vikash Garodia <quic_vgarodia@quicinc.com> <vgarodia@codeaurora.org>
Vinod Koul <vkoul@kernel.org> <vinod.koul@intel.com>
Vinod Koul <vkoul@kernel.org> <vinod.koul@linux.intel.com>
Vinod Koul <vkoul@kernel.org> <vkoul@infradead.org>
diff --git a/CREDITS b/CREDITS
index 5f5d70c..8470591 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1852,11 +1852,11 @@
D: fbdev hacking
N: Jesper Juhl
-E: jj@chaosbits.net
+E: jesperjuhl76@gmail.com
D: Various fixes, cleanups and minor features all over the tree.
D: Wrote initial version of the hdaps driver (since passed on to others).
-S: Lemnosvej 1, 3.tv
-S: 2300 Copenhagen S.
+S: Titangade 5G, 2.tv
+S: 2200 Copenhagen N.
S: Denmark
N: Jozsef Kadlecsik
diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block
index cd14ecb..282de36 100644
--- a/Documentation/ABI/stable/sysfs-block
+++ b/Documentation/ABI/stable/sysfs-block
@@ -432,7 +432,8 @@
Description:
[RW] This is the maximum number of kilobytes that the block
layer will allow for a filesystem request. Must be smaller than
- or equal to the maximum size allowed by the hardware.
+ or equal to the maximum size allowed by the hardware. Write 0
+ to use default kernel settings.
What: /sys/block/<disk>/queue/max_segment_size
@@ -704,6 +705,15 @@
zoned will report "none".
+What: /sys/block/<disk>/hidden
+Date: March 2023
+Contact: linux-block@vger.kernel.org
+Description:
+ [RO] the block device is hidden. it doesn’t produce events, and
+ can’t be opened from userspace or using blkdev_get*.
+ Used for the underlying components of multipath devices.
+
+
What: /sys/block/<disk>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node
index 8db67aa..402af4b 100644
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -182,3 +182,42 @@
Contact: Jarkko Sakkinen <jarkko@kernel.org>
Description:
The total amount of SGX physical memory in bytes.
+
+What: /sys/devices/system/node/nodeX/memory_failure/total
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ The total number of raw poisoned pages (pages containing
+ corrupted data due to memory errors) on a NUMA node.
+
+What: /sys/devices/system/node/nodeX/memory_failure/ignored
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ ignored by memory error recovery attempt, usually because
+ support for this type of pages is unavailable, and kernel
+ gives up the recovery.
+
+What: /sys/devices/system/node/nodeX/memory_failure/failed
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ failed by memory error recovery attempt. This usually means
+ a key recovery operation failed.
+
+What: /sys/devices/system/node/nodeX/memory_failure/delayed
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ delayed by memory error recovery attempt. Delayed poisoned
+ pages usually will be retried by kernel.
+
+What: /sys/devices/system/node/nodeX/memory_failure/recovered
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ recovered by memory error recovery attempt.
diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
index af0cbf1..6095390 100644
--- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io
+++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
@@ -522,7 +522,6 @@
The files are write only.
-
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/comm_chnl_ready
Date: July 2022
KernelVersion: 5.20
@@ -542,3 +541,124 @@
The purpose is to expose some minor BOM changes for the same system SKU.
The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_pwr_converter_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows the system reset cause due to power converter
+ devices failure.
+ Value 1 in file means this is reset cause, 0 - otherwise.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_ap_reset
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_ap_reset
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files aim to monitor the status of the External Root of Trust (EROT)
+ processor's RESET output to the Application Processor (AP).
+ By reading this file, could be determined if the EROT has invalidated or
+ revoked AP Firmware, at which point it will hold the AP in RESET until a
+ valid firmware is loaded. This protects the AP from running an
+ unauthorized firmware. In the normal flow, the AP reset should be released
+ after the EROT validates the integrity of the FW, and it should be done so
+ as quickly as possible so that the AP boots before the CPU starts to
+ communicate to each ASIC.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_recovery
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_recovery
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_reset
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_reset
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files aim to perform External Root of Trust (EROT) recovery
+ sequence after EROT device failure.
+ These EROT devices protect ASICs from unauthorized access and in normal
+ flow their reset should be released with system power – earliest power
+ up stage, so that EROTs can begin boot and authentication process before
+ CPU starts to communicate to ASICs.
+ Issuing a reset to the EROT while asserting the recovery signal will cause
+ the EROT Application Processor to enter recovery mode so that the EROT FW
+ can be updated/recovered.
+ For reset/recovery the related file should be toggled by 1/0.
+
+ The files are read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_wp
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_wp
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files allow access to External Root of Trust (EROT) for reset
+ and recovery sequence after EROT device failure.
+ Default is 0 (programming disabled).
+ If the system is in locked-down mode writing this file will not be allowed.
+
+ The files are read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/spi_chnl_select
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file allows SPI chip selection for External Root of Trust (EROT)
+ device Out-of-Band recovery.
+ File can be written with 0 or with 1. It selects which EROT can be accessed
+ through SPI device.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_pg_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak vadimp@nvidia.com
+Description: This file shows ASIC Power Good status.
+ Value 1 in file means ASIC Power Good failed, 0 - otherwise.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd1_boot_fail
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd2_boot_fail
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak vadimp@nvidia.com
+Description: These files are related to clock boards status in system.
+ - clk_brd1_boot_fail: warning about 1-st clock board failed to boot from CI.
+ - clk_brd2_boot_fail: warning about 2-nd clock board failed to boot from CI.
+ - clk_brd_fail: error about common clock board boot failure.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_prog_en
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file enables programming of clock boards.
+ Default is 0 (programming disabled).
+ If the system is in locked-down mode writing this file will not be allowed.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_converter_prog_en
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file enables programming of power converters.
+ Default is 0 (programming disabled).
+ If the system is in locked-down mode writing this file will not be allowed.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_ac_ok_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows the system reset cause due to AC power failure.
+ Value 1 in file means this is reset cause, 0 - otherwise.
+
+ The file is read only.
diff --git a/Documentation/ABI/stable/sysfs-hypervisor-xen b/Documentation/ABI/stable/sysfs-hypervisor-xen
index 748593c..be9ca99 100644
--- a/Documentation/ABI/stable/sysfs-hypervisor-xen
+++ b/Documentation/ABI/stable/sysfs-hypervisor-xen
@@ -120,3 +120,16 @@
Description: If running under Xen:
The Xen version is in the format <major>.<minor><extra>
This is the <minor> part of it.
+
+What: /sys/hypervisor/start_flags/*
+Date: March 2023
+KernelVersion: 6.3.0
+Contact: xen-devel@lists.xenproject.org
+Description: If running under Xen:
+ All bits in Xen's start-flags are represented as
+ boolean files, returning '1' if set, '0' otherwise.
+ This takes the place of the defunct /proc/xen/capabilities,
+ which would contain "control_d" on dom0, and be empty
+ otherwise. This flag is now exposed as "initdomain" in
+ addition to the "privileged" flag; all other possible flags
+ are accessible as "unknownXX".
diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget
index b7943aa..a8bb896 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -143,3 +143,16 @@
qw_sign an identifier to be reported as "OS String"
proper
============= ===============================================
+
+What: /config/usb-gadget/gadget/webusb
+Date: Dec 2022
+KernelVersion: 6.3
+Description:
+ This group contains "WebUSB" extension handling attributes.
+
+ ============= ===============================================
+ use flag turning "WebUSB" support on/off
+ bcdVersion bcd WebUSB specification version number
+ bVendorCode one-byte value used for custom per-device
+ landingPage UTF-8 encoded URL of the device's landing page
+ ============= ===============================================
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index f00cff6..80b98a4 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -15,12 +15,14 @@
KernelVersion: 4.0
Description: Control descriptors
- All attributes read only:
+ All attributes read only except enable_interrupt_ep:
- ================ =============================
+ =================== =============================
bInterfaceNumber USB interface number for this
streaming interface
- ================ =============================
+ enable_interrupt_ep flag to enable the interrupt
+ endpoint for the VC interface
+ =================== =============================
What: /config/usb-gadget/gadget/functions/uvc.name/control/class
Date: Dec 2014
@@ -52,7 +54,7 @@
KernelVersion: 4.0
Description: Default output terminal descriptors
- All attributes read only:
+ All attributes read only except bSourceID:
============== =============================================
iTerminal index of string descriptor
@@ -111,6 +113,34 @@
bUnitID a non-zero id of this unit
=============== ========================================
+What: /config/usb-gadget/gadget/functions/uvc.name/control/extensions
+Date: Nov 2022
+KernelVersion: 6.1
+Description: Extension unit descriptors
+
+What: /config/usb-gadget/gadget/functions/uvc.name/control/extensions/name
+Date: Nov 2022
+KernelVersion: 6.1
+Description: Extension Unit (XU) Descriptor
+
+ bLength, bUnitID and iExtension are read-only. All others are
+ read-write.
+
+ ================= ========================================
+ bLength size of the descriptor in bytes
+ bUnitID non-zero ID of this unit
+ guidExtensionCode Vendor-specific code identifying the XU
+ bNumControls number of controls in this XU
+ bNrInPins number of input pins for this unit
+ baSourceID list of the IDs of the units or terminals
+ to which this XU is connected
+ bControlSize size of the bmControls field in bytes
+ bmControls list of bitmaps detailing which vendor
+ specific controls are supported
+ iExtension index of a string descriptor that describes
+ this extension unit
+ ================= ========================================
+
What: /config/usb-gadget/gadget/functions/uvc.name/control/header
Date: Dec 2014
KernelVersion: 4.0
@@ -165,7 +195,24 @@
KernelVersion: 4.0
Description: Default color matching descriptors
- All attributes read only:
+ All attributes read/write:
+
+ ======================== ======================================
+ bMatrixCoefficients matrix used to compute luma and
+ chroma values from the color primaries
+ bTransferCharacteristics optoelectronic transfer
+ characteristic of the source picture,
+ also called the gamma function
+ bColorPrimaries color primaries and the reference
+ white
+ ======================== ======================================
+
+What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching/name
+Date: Dec 2022
+KernelVersion: 6.3
+Description: Additional color matching descriptors
+
+ All attributes read/write:
======================== ======================================
bMatrixCoefficients matrix used to compute luma and
diff --git a/Documentation/ABI/testing/debugfs-driver-dcc b/Documentation/ABI/testing/debugfs-driver-dcc
new file mode 100644
index 0000000..27ed591
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-driver-dcc
@@ -0,0 +1,127 @@
+What: /sys/kernel/debug/dcc/.../ready
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This file is used to check the status of the dcc
+ hardware if it's ready to receive user configurations.
+ A 'Y' here indicates dcc is ready.
+
+What: /sys/kernel/debug/dcc/.../trigger
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This is the debugfs interface for manual software
+ triggers. The trigger can be invoked by writing '1'
+ to the file.
+
+What: /sys/kernel/debug/dcc/.../config_reset
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This file is used to reset the configuration of
+ a dcc driver to the default configuration. When '1'
+ is written to the file, all the previous addresses
+ stored in the driver gets removed and users need to
+ reconfigure addresses again.
+
+What: /sys/kernel/debug/dcc/.../[list-number]/config
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This stores the addresses of the registers which
+ can be read in case of a hardware crash or manual
+ software triggers. The input addresses type
+ can be one of following dcc instructions: read,
+ write, read-write, and loop type. The lists need to
+ be configured sequentially and not in a overlapping
+ manner; e.g. users can jump to list x only after
+ list y is configured and enabled. The input format for
+ each type is as follows:
+
+ i) Read instruction
+
+ ::
+
+ echo R <addr> <n> <bus> >/sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <addr>
+ The address to be read.
+
+ <n>
+ The addresses word count, starting from address <1>.
+ Each word is 32 bits (4 bytes). If omitted, defaulted
+ to 1.
+
+ <bus type>
+ The bus type, which can be either 'apb' or 'ahb'.
+ The default is 'ahb' if leaved out.
+
+ ii) Write instruction
+
+ ::
+
+ echo W <addr> <n> <bus type> > /sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <addr>
+ The address to be written.
+
+ <n>
+ The value to be written at <addr>.
+
+ <bus type>
+ The bus type, which can be either 'apb' or 'ahb'.
+
+ iii) Read-write instruction
+
+ ::
+
+ echo RW <addr> <n> <mask> > /sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <addr>
+ The address to be read and written.
+
+ <n>
+ The value to be written at <addr>.
+
+ <mask>
+ The value mask.
+
+ iv) Loop instruction
+
+ ::
+
+ echo L <loop count> <address count> <address>... > /sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <loop count>
+ Number of iterations
+
+ <address count>
+ total number of addresses to be written
+
+ <address>
+ Space-separated list of addresses.
+
+What: /sys/kernel/debug/dcc/.../[list-number]/enable
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This debugfs interface is used for enabling the
+ the dcc hardware. A file named "enable" is in the
+ directory list number where users can enable/disable
+ the specific list by writing boolean (1 or 0) to the
+ file.
+
+ On enabling the dcc, all the addresses specified
+ by the user for the corresponding list is written
+ into dcc sram which is read by the dcc hardware
+ on manual or crash induced triggers. Lists must
+ be configured and enabled sequentially, e.g. list
+ 2 can only be enabled when list 1 have so.
diff --git a/Documentation/ABI/testing/debugfs-scmi b/Documentation/ABI/testing/debugfs-scmi
new file mode 100644
index 0000000..ee7179a
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-scmi
@@ -0,0 +1,70 @@
+What: /sys/kernel/debug/scmi/<n>/instance_name
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: The name of the underlying SCMI instance <n> described by
+ all the debugfs accessors rooted at /sys/kernel/debug/scmi/<n>,
+ expressed as the full name of the top DT SCMI node under which
+ this SCMI instance is rooted.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/atomic_threshold_us
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: An optional time value, expressed in microseconds, representing,
+ on this SCMI instance <n>, the threshold above which any SCMI
+ command, advertised to have an higher-than-threshold execution
+ latency, should not be considered for atomic mode of operation,
+ even if requested.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/type
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: A string representing the type of transport configured for this
+ SCMI instance <n>.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/is_atomic
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: A boolean stating if the transport configured on the underlying
+ SCMI instance <n> is capable of atomic mode of operation.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/max_rx_timeout_ms
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Timeout in milliseconds allowed for SCMI synchronous replies
+ for the currently configured SCMI transport for instance <n>.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/max_msg_size
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Max message size of allowed SCMI messages for the currently
+ configured SCMI transport for instance <n>.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/tx_max_msg
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Max number of concurrently allowed in-flight SCMI messages for
+ the currently configured SCMI transport for instance <n> on the
+ TX channels.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/rx_max_msg
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Max number of concurrently allowed in-flight SCMI messages for
+ the currently configured SCMI transport for instance <n> on the
+ RX channels.
+Users: Debugging, any userspace test suite
diff --git a/Documentation/ABI/testing/debugfs-scmi-raw b/Documentation/ABI/testing/debugfs-scmi-raw
new file mode 100644
index 0000000..97678cc
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-scmi-raw
@@ -0,0 +1,117 @@
+What: /sys/kernel/debug/scmi/<n>/raw/message
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw synchronous message injection/snooping facility; write
+ a complete SCMI synchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n>.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/message_async
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility; write
+ a complete SCMI asynchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n>.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/errors
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw message errors facility; any kind of timed-out or
+ generally unexpectedly received SCMI message, for instance <n>,
+ can be read from this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/notification
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw notification snooping facility; any notification
+ emitted by the backend SCMI server, for instance <n>, can be
+ read from this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/reset
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw stack reset facility; writing a value to this entry
+ causes the internal queues of any kind of received message,
+ still pending to be read out for instance <n>, to be immediately
+ flushed.
+ Can be used to reset and clean the SCMI Raw stack between to
+ different test-run.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw synchronous message injection/snooping facility; write
+ a complete SCMI synchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n> through the <m> transport
+ channel.
+ Any subsequently received response can be read from this same
+ entry if it arrived on channel <m> within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+ Channel identifier <m> matches the SCMI protocol number which
+ has been associated with this transport channel in the DT
+ description, with base protocol number 0x10 being the default
+ channel for this instance.
+ Note that these per-channel entries rooted at <..>/channels
+ exist only if the transport is configured to have more than
+ one default channel.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_async
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility; write
+ a complete SCMI asynchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n> through the <m> transport
+ channel.
+ Any subsequently received response can be read from this same
+ entry if it arrived on channel <m> within the configured
+ timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+ Channel identifier <m> matches the SCMI protocol number which
+ has been associated with this transport channel in the DT
+ description, with base protocol number 0x10 being the default
+ channel for this instance.
+ Note that these per-channel entries rooted at <..>/channels
+ exist only if the transport is configured to have more than
+ one default channel.
+Users: Debugging, any userspace test suite
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index db17fc8..49db0ff 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -35,7 +35,7 @@
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
- [SETXATTR_CHECK]
+ [SETXATTR_CHECK][MMAP_CHECK_REQPROT]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
[[^]MAY_EXEC]
fsmagic:= hex value
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
index 651602a..234c33f 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
@@ -236,7 +236,7 @@
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RW) Holds the trace ID that will appear in the trace stream
+Description: (RO) Holds the trace ID that will appear in the trace stream
coming from this trace entity.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/trigger_event
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
new file mode 100644
index 0000000..4a58e64
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
@@ -0,0 +1,13 @@
+What: /sys/bus/coresight/devices/<tpdm-name>/integration_test
+Date: January 2023
+KernelVersion 6.2
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (Write) Run integration test for tpdm. Integration test
+ will generate test data for tpdm. It can help to make
+ sure that the trace path is enabled and the link configurations
+ are fine.
+
+ Accepts only one of the 2 values - 1 or 2.
+ 1 : Generate 64 bits data
+ 2 : Generate 32 bits data
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb
new file mode 100644
index 0000000..f560918
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb
@@ -0,0 +1,31 @@
+What: /sys/bus/coresight/devices/ultra_smb<N>/enable_sink
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RW) Add/remove a SMB device from a trace path. There can be
+ multiple sources for a single SMB device.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/buf_size
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the buffer size of each UltraSoc SMB device.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/buf_status
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the value of UltraSoc SMB status register.
+ BIT(0) is zero means buffer is empty.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/read_pos
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the value of UltraSoc SMB Read Pointer register.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/write_pos
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the value of UltraSoc SMB Write Pointer register.
diff --git a/Documentation/ABI/testing/sysfs-bus-css b/Documentation/ABI/testing/sysfs-bus-css
index 12a733f..d4d5cfb 100644
--- a/Documentation/ABI/testing/sysfs-bus-css
+++ b/Documentation/ABI/testing/sysfs-bus-css
@@ -1,22 +1,19 @@
What: /sys/bus/css/devices/.../type
Date: March 2008
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the subchannel type, as reported by the hardware.
This attribute is present for all subchannel types.
What: /sys/bus/css/devices/.../modalias
Date: March 2008
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the module alias as reported with uevents.
It is of the format css:t<type> and present for all
subchannel types.
What: /sys/bus/css/drivers/io_subchannel/.../chpids
Date: December 2002
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the ids of the channel paths used by this
subchannel, as reported by the channel subsystem
during subchannel recognition.
@@ -26,8 +23,7 @@
What: /sys/bus/css/drivers/io_subchannel/.../pimpampom
Date: December 2002
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the PIM/PAM/POM values, as reported by the
channel subsystem when last queried by the common I/O
layer (this implies that this attribute is not necessarily
@@ -38,8 +34,7 @@
What: /sys/bus/css/devices/.../driver_override
Date: June 2019
-Contact: Cornelia Huck <cohuck@redhat.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: This file allows the driver for a device to be specified. When
specified, only a driver with a name matching the value written
to driver_override will have an opportunity to bind to the
diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl
index 8494ef2..3acf2f1 100644
--- a/Documentation/ABI/testing/sysfs-bus-cxl
+++ b/Documentation/ABI/testing/sysfs-bus-cxl
@@ -90,6 +90,21 @@
capability.
+What: /sys/bus/cxl/devices/{port,endpoint}X/parent_dport
+Date: January, 2023
+KernelVersion: v6.3
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) CXL port objects are instantiated for each upstream port in
+ a CXL/PCIe switch, and for each endpoint to map the
+ corresponding memory device into the CXL port hierarchy. When a
+ descendant CXL port (switch or endpoint) is enumerated it is
+ useful to know which 'dport' object in the parent CXL port
+ routes to this descendant. The 'parent_dport' symlink points to
+ the device representing the downstream port of a CXL switch that
+ routes to {port,endpoint}X.
+
+
What: /sys/bus/cxl/devices/portX/dportY
Date: June, 2021
KernelVersion: v5.14
@@ -183,7 +198,7 @@
What: /sys/bus/cxl/devices/endpointX/CDAT
Date: July, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) If this sysfs entry is not present no DOE mailbox was
@@ -194,7 +209,7 @@
What: /sys/bus/cxl/devices/decoderX.Y/mode
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
@@ -214,7 +229,7 @@
What: /sys/bus/cxl/devices/decoderX.Y/dpa_resource
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) When a CXL decoder is of devtype "cxl_decoder_endpoint",
@@ -225,7 +240,7 @@
What: /sys/bus/cxl/devices/decoderX.Y/dpa_size
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
@@ -245,7 +260,7 @@
What: /sys/bus/cxl/devices/decoderX.Y/interleave_ways
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The number of targets across which this decoder's host
@@ -260,7 +275,7 @@
What: /sys/bus/cxl/devices/decoderX.Y/interleave_granularity
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The number of consecutive bytes of host physical address
@@ -270,25 +285,25 @@
interleave_granularity).
-What: /sys/bus/cxl/devices/decoderX.Y/create_pmem_region
-Date: May, 2022
-KernelVersion: v5.20
+What: /sys/bus/cxl/devices/decoderX.Y/create_{pmem,ram}_region
+Date: May, 2022, January, 2023
+KernelVersion: v6.0 (pmem), v6.3 (ram)
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a string in the form 'regionZ' to start the process
- of defining a new persistent memory region (interleave-set)
- within the decode range bounded by root decoder 'decoderX.Y'.
- The value written must match the current value returned from
- reading this attribute. An atomic compare exchange operation is
- done on write to assign the requested id to a region and
- allocate the region-id for the next creation attempt. EBUSY is
- returned if the region name written does not match the current
- cached value.
+ of defining a new persistent, or volatile memory region
+ (interleave-set) within the decode range bounded by root decoder
+ 'decoderX.Y'. The value written must match the current value
+ returned from reading this attribute. An atomic compare exchange
+ operation is done on write to assign the requested id to a
+ region and allocate the region-id for the next creation attempt.
+ EBUSY is returned if the region name written does not match the
+ current cached value.
What: /sys/bus/cxl/devices/decoderX.Y/delete_region
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(WO) Write a string in the form 'regionZ' to delete that region,
@@ -297,17 +312,18 @@
What: /sys/bus/cxl/devices/regionZ/uuid
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a unique identifier for the region. This field must
be set for persistent regions and it must not conflict with the
- UUID of another region.
+ UUID of another region. For volatile ram regions this
+ attribute is a read-only empty string.
What: /sys/bus/cxl/devices/regionZ/interleave_granularity
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Set the number of consecutive bytes each device in the
@@ -318,7 +334,7 @@
What: /sys/bus/cxl/devices/regionZ/interleave_ways
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Configures the number of devices participating in the
@@ -328,7 +344,7 @@
What: /sys/bus/cxl/devices/regionZ/size
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) System physical address space to be consumed by the region.
@@ -343,9 +359,20 @@
results in the same address being allocated.
+What: /sys/bus/cxl/devices/regionZ/mode
+Date: January, 2023
+KernelVersion: v6.3
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) The mode of a region is established at region creation time
+ and dictates the mode of the endpoint decoder that comprise the
+ region. For more details on the possible modes see
+ /sys/bus/cxl/devices/decoderX.Y/mode
+
+
What: /sys/bus/cxl/devices/regionZ/resource
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) A region is a contiguous partition of a CXL root decoder
@@ -357,7 +384,7 @@
What: /sys/bus/cxl/devices/regionZ/target[0..N]
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write an endpoint decoder object name to 'targetX' where X
@@ -376,7 +403,7 @@
What: /sys/bus/cxl/devices/regionZ/commit
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a boolean 'true' string value to this attribute to
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu b/Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu
new file mode 100644
index 0000000..d7af491
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu
@@ -0,0 +1,37 @@
+What: /sys/bus/event_source/devices/dmar*/format
+Date: Jan 2023
+KernelVersion: 6.3
+Contact: Kan Liang <kan.liang@linux.intel.com>
+Description: Read-only. Attribute group to describe the magic bits
+ that go into perf_event_attr.config,
+ perf_event_attr.config1 or perf_event_attr.config2 for
+ the IOMMU pmu. (See also
+ ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute in this group defines a bit range in
+ perf_event_attr.config, perf_event_attr.config1,
+ or perf_event_attr.config2. All supported attributes
+ are listed below (See the VT-d Spec 4.0 for possible
+ attribute values)::
+
+ event = "config:0-27" - event ID
+ event_group = "config:28-31" - event group ID
+
+ filter_requester_en = "config1:0" - Enable Requester ID filter
+ filter_domain_en = "config1:1" - Enable Domain ID filter
+ filter_pasid_en = "config1:2" - Enable PASID filter
+ filter_ats_en = "config1:3" - Enable Address Type filter
+ filter_page_table_en= "config1:4" - Enable Page Table Level filter
+ filter_requester_id = "config1:16-31" - Requester ID filter
+ filter_domain = "config1:32-47" - Domain ID filter
+ filter_pasid = "config2:0-21" - PASID filter
+ filter_ats = "config2:24-28" - Address Type filter
+ filter_page_table = "config2:32-36" - Page Table Level filter
+
+What: /sys/bus/event_source/devices/dmar*/cpumask
+Date: Jan 2023
+KernelVersion: 6.3
+Contact: Kan Liang <kan.liang@linux.intel.com>
+Description: Read-only. This file always returns the CPU to which the
+ IOMMU pmu is bound for access to all IOMMU pmu performance
+ monitoring events.
diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon
index 7271781..638f4c6 100644
--- a/Documentation/ABI/testing/sysfs-class-hwmon
+++ b/Documentation/ABI/testing/sysfs-class-hwmon
@@ -276,6 +276,15 @@
RW
+What: /sys/class/hwmon/hwmonX/fanY_fault
+Description:
+ Reports if a fan has reported failure.
+
+ - 1: Failed
+ - 0: Ok
+
+ RO
+
What: /sys/class/hwmon/hwmonX/pwmY
Description:
Pulse width modulation fan control.
diff --git a/Documentation/ABI/testing/sysfs-class-net-peak_usb b/Documentation/ABI/testing/sysfs-class-net-peak_usb
new file mode 100644
index 0000000..9e3d0bf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-peak_usb
@@ -0,0 +1,19 @@
+
+What: /sys/class/net/<iface>/peak_usb/can_channel_id
+Date: November 2022
+KernelVersion: 6.2
+Contact: Stephane Grosjean <s.grosjean@peak-system.com>
+Description:
+ PEAK PCAN-USB devices support user-configurable CAN channel
+ identifiers. Contrary to a USB serial number, these identifiers
+ are writable and can be set per CAN interface. This means that
+ if a USB device exports multiple CAN interfaces, each of them
+ can be assigned a unique channel ID.
+ This attribute provides read-only access to the currently
+ configured value of the channel identifier. Depending on the
+ device type, the identifier has a length of 8 or 32 bit. The
+ value read from this attribute is always an 8 digit 32 bit
+ hexadecimal value in big endian format. If the device only
+ supports an 8 bit identifier, the upper 24 bit of the value are
+ set to zero.
+
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
index e434fc5..7c81f0a 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -437,7 +437,8 @@
Date: May 2007
Contact: linux-pm@vger.kernel.org
Description:
- Reports whether a battery is present or not in the system.
+ Reports whether a battery is present or not in the system. If the
+ property does not exist, the battery is considered to be present.
Access: Read
diff --git a/Documentation/ABI/testing/sysfs-class-power-rt9467 b/Documentation/ABI/testing/sysfs-class-power-rt9467
new file mode 100644
index 0000000..619b7c4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-rt9467
@@ -0,0 +1,19 @@
+What: /sys/class/power_supply/rt9467-*/sysoff_enable
+Date: Feb 2023
+KernelVersion: 6.3
+Contact: ChiaEn Wu <chiaen_wu@richtek.com>
+Description:
+ This entry allows enabling the sysoff mode of rt9467 charger
+ devices.
+ If enabled and the input is removed, the internal battery FET
+ is turned off to reduce the leakage from the BAT pin. See
+ device datasheet for details. It's commonly used when the
+ product enter shipping stage. After entering shipping mode,
+ only 'VBUS' or 'Power key" pressed can make it leave this mode.
+ 'Disable' also can help to leave it, but it's more like to
+ abort the action before the device really enter shipping mode.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
diff --git a/Documentation/ABI/testing/sysfs-class-power-rt9471 b/Documentation/ABI/testing/sysfs-class-power-rt9471
new file mode 100644
index 0000000..0a390ee
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-rt9471
@@ -0,0 +1,32 @@
+What: /sys/class/power_supply/rt9471-*/sysoff_enable
+Date: Feb 2023
+KernelVersion: 6.3
+Contact: ChiYuan Huang <cy_huang@richtek.com>
+Description:
+ This entry allows enabling the sysoff mode of rt9471 charger devices.
+ If enabled and the input is removed, the internal battery FET is turned
+ off to reduce the leakage from the BAT pin. See device datasheet for details.
+ It's commonly used when the product enter shipping stage. After entering
+ shipping mode, only 'VBUS' or 'Power key" pressed can make it leave this
+ mode. 'Disable' also can help to leave it, but it's more like to abort
+ the action before the device really enter shipping mode.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
+
+What: /sys/class/power_supply/rt9471-*/port_detect_enable
+Date: Feb 2023
+KernelVersion: 6.3
+Contact: ChiYuan Huang <cy_huang@richtek.com>
+Description:
+ This entry allows enabling the USB BC12 port detect function of rt9471 charger
+ devices. If enabled and VBUS is inserted, device will start to do the BC12
+ port detect and report the usb port type when port detect is done. See
+ datasheet for details. Normally controlled when TypeC/USBPD port integrated.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
diff --git a/Documentation/ABI/testing/sysfs-class-usb_power_delivery b/Documentation/ABI/testing/sysfs-class-usb_power_delivery
index ce2b1b56..1bf9d1d 100644
--- a/Documentation/ABI/testing/sysfs-class-usb_power_delivery
+++ b/Documentation/ABI/testing/sysfs-class-usb_power_delivery
@@ -69,7 +69,7 @@
This file contains boolean value that tells does the device
support both source and sink power roles.
-What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_suspend_supported
+What: /sys/class/usb_power_delivery/.../source-capabilities/1:fixed_supply/usb_suspend_supported
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@@ -78,6 +78,15 @@
will follow the USB 2.0 and USB 3.2 rules for suspend and
resume.
+What: /sys/class/usb_power_delivery/.../sink-capabilities/1:fixed_supply/higher_capability
+Date: February 2023
+Contact: Saranya Gopal <saranya.gopal@linux.intel.com>
+Description:
+ This file shows the value of the Higher capability bit in
+ vsafe5V Fixed Supply Object. If the bit is set, then the sink
+ needs more than vsafe5V(eg. 12 V) to provide full functionality.
+ Valid values: 0, 1
+
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unconstrained_power
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
diff --git a/Documentation/ABI/testing/sysfs-class-watchdog b/Documentation/ABI/testing/sysfs-class-watchdog
index 585caec..94fb746 100644
--- a/Documentation/ABI/testing/sysfs-class-watchdog
+++ b/Documentation/ABI/testing/sysfs-class-watchdog
@@ -6,6 +6,19 @@
device at boot. It is equivalent to WDIOC_GETBOOTSTATUS of
ioctl interface.
+What: /sys/class/watchdog/watchdogn/options
+Date: April 2023
+Contact: Thomas Weißschuh
+Description:
+ It is a read only file. It contains options of watchdog device.
+
+What: /sys/class/watchdog/watchdogn/fw_version
+Date: April 2023
+Contact: Thomas Weißschuh
+Description:
+ It is a read only file. It contains firmware version of
+ watchdog device.
+
What: /sys/class/watchdog/watchdogn/identity
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs
index 13b5b2e..1b98b65 100644
--- a/Documentation/ABI/testing/sysfs-driver-habanalabs
+++ b/Documentation/ABI/testing/sysfs-driver-habanalabs
@@ -201,7 +201,19 @@
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
-Description: Status of the card: "Operational", "Malfunction", "In reset".
+Description: Status of the card:
+
+ * "operational" - Device is available for work.
+ * "in reset" - Device is going through reset, will be
+ available shortly.
+ * "disabled" - Device is not usable.
+ * "needs reset" - Device is not usable until a hard reset
+ is initiated.
+ * "in device creation" - Device is not available yet, as it
+ is still initializing.
+ * "in reset after device release" - Device is going through
+ a compute-reset which is executed after a device release
+ (relevant for Gaudi2 only).
What: /sys/class/habanalabs/hl<n>/thermal_ver
Date: Jan 2019
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
index 9773925..a8ab580 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
@@ -1,4 +1,4 @@
-What: /sys/bus/spi/devices/.../bmc_version
+What: /sys/bus/.../drivers/intel-m10-bmc/.../bmc_version
Date: June 2020
KernelVersion: 5.10
Contact: Xu Yilun <yilun.xu@intel.com>
@@ -6,7 +6,7 @@
MAX10 BMC chip.
Format: "0x%x".
-What: /sys/bus/spi/devices/.../bmcfw_version
+What: /sys/bus/.../drivers/intel-m10-bmc/.../bmcfw_version
Date: June 2020
KernelVersion: 5.10
Contact: Xu Yilun <yilun.xu@intel.com>
@@ -14,7 +14,7 @@
BMC chip.
Format: "0x%x".
-What: /sys/bus/spi/devices/.../mac_address
+What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_address
Date: January 2021
KernelVersion: 5.12
Contact: Russ Weight <russell.h.weight@intel.com>
@@ -25,7 +25,7 @@
space.
Format: "%02x:%02x:%02x:%02x:%02x:%02x".
-What: /sys/bus/spi/devices/.../mac_count
+What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_count
Date: January 2021
KernelVersion: 5.12
Contact: Russ Weight <russell.h.weight@intel.com>
diff --git a/Documentation/ABI/testing/sysfs-driver-qat b/Documentation/ABI/testing/sysfs-driver-qat
index 185f81a..087842b 100644
--- a/Documentation/ABI/testing/sysfs-driver-qat
+++ b/Documentation/ABI/testing/sysfs-driver-qat
@@ -1,6 +1,6 @@
What: /sys/bus/pci/devices/<BDF>/qat/state
Date: June 2022
-KernelVersion: 5.20
+KernelVersion: 6.0
Contact: qat-linux@intel.com
Description: (RW) Reports the current state of the QAT device. Write to
the file to start or stop the device.
@@ -18,7 +18,7 @@
What: /sys/bus/pci/devices/<BDF>/qat/cfg_services
Date: June 2022
-KernelVersion: 5.20
+KernelVersion: 6.0
Contact: qat-linux@intel.com
Description: (RW) Reports the current configuration of the QAT device.
Write to the file to change the configured services.
diff --git a/Documentation/ABI/testing/sysfs-driver-typec-displayport b/Documentation/ABI/testing/sysfs-driver-typec-displayport
index 231471a..256c87c5 100644
--- a/Documentation/ABI/testing/sysfs-driver-typec-displayport
+++ b/Documentation/ABI/testing/sysfs-driver-typec-displayport
@@ -47,3 +47,18 @@
USB SuperSpeed protocol. From user perspective pin assignments C
and E are equal, where all channels on the connector are used
for carrying DisplayPort protocol (allowing higher resolutions).
+
+What: /sys/bus/typec/devices/.../displayport/hpd
+Date: Dec 2022
+Contact: Badhri Jagan Sridharan <badhri@google.com>
+Description:
+ VESA DisplayPort Alt Mode on USB Type-C Standard defines how
+ HotPlugDetect(HPD) shall be supported on the USB-C connector when
+ operating in DisplayPort Alt Mode. This is a read only node which
+ reflects the current state of HPD.
+
+ Valid values:
+ - 1: when HPD’s logical state is high (HPD_High) as defined
+ by VESA DisplayPort Alt Mode on USB Type-C Standard.
+ - 0 when HPD’s logical state is low (HPD_Low) as defined by
+ VESA DisplayPort Alt Mode on USB Type-C Standard.
diff --git a/Documentation/ABI/testing/sysfs-driver-uacce b/Documentation/ABI/testing/sysfs-driver-uacce
index 08f2591..d3f0b8f 100644
--- a/Documentation/ABI/testing/sysfs-driver-uacce
+++ b/Documentation/ABI/testing/sysfs-driver-uacce
@@ -19,6 +19,24 @@
Description: Available instances left of the device
Return -ENODEV if uacce_ops get_available_instances is not provided
+What: /sys/class/uacce/<dev_name>/isolate_strategy
+Date: Nov 2022
+KernelVersion: 6.1
+Contact: linux-accelerators@lists.ozlabs.org
+Description: (RW) A sysfs node that configure the error threshold for the hardware
+ isolation strategy. This size is a configured integer value, which is the
+ number of threshold for hardware errors occurred in one hour. The default is 0.
+ 0 means never isolate the device. The maximum value is 65535. You can write
+ a number of threshold based on your hardware.
+
+What: /sys/class/uacce/<dev_name>/isolate
+Date: Nov 2022
+KernelVersion: 6.1
+Contact: linux-accelerators@lists.ozlabs.org
+Description: (R) A sysfs node that read the device isolated state. The value 1
+ means the device is unavailable. The 0 means the device is
+ available.
+
What: /sys/class/uacce/<dev_name>/algorithms
Date: Feb 2020
KernelVersion: 5.7
diff --git a/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager b/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
new file mode 100644
index 0000000..57b9b68
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
@@ -0,0 +1,16 @@
+What: /sys/devices/platform/amba_pl/<dev>/errcnt
+Date: Nov 2022
+Contact: appana.durga.kedareswara.rao@amd.com
+Description: This control file provides the fault detection count.
+ This file cannot be written.
+ Example:
+ # cat /sys/devices/platform/amba_pl/44a10000.tmr_manager/errcnt
+ 1
+
+What: /sys/devices/platform/amba_pl/<dev>/dis_block_break
+Date: Nov 2022
+Contact: appana.durga.kedareswara.rao@amd.com
+Description: Write any value to it, This control file enables the break signal.
+ This file is write only.
+ Example:
+ # echo <any value> > /sys/devices/platform/amba_pl/44a10000.tmr_manager/dis_block_break
diff --git a/Documentation/ABI/testing/sysfs-fs-erofs b/Documentation/ABI/testing/sysfs-fs-erofs
index bb4681a..284224d 100644
--- a/Documentation/ABI/testing/sysfs-fs-erofs
+++ b/Documentation/ABI/testing/sysfs-fs-erofs
@@ -4,7 +4,8 @@
Description: Shows all enabled kernel features.
Supported features:
zero_padding, compr_cfgs, big_pcluster, chunked_file,
- device_table, compr_head2, sb_chksum.
+ device_table, compr_head2, sb_chksum, ztailpacking,
+ dedupe, fragments.
What: /sys/fs/erofs/<disk>/sync_decompress
Date: November 2021
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 9e37566..9413274 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -49,16 +49,23 @@
Description: Controls the in-place-update policy.
updates in f2fs. User can set:
- ==== =================
- 0x01 F2FS_IPU_FORCE
- 0x02 F2FS_IPU_SSR
- 0x04 F2FS_IPU_UTIL
- 0x08 F2FS_IPU_SSR_UTIL
- 0x10 F2FS_IPU_FSYNC
- 0x20 F2FS_IPU_ASYNC
- 0x40 F2FS_IPU_NOCACHE
- 0x80 F2FS_IPU_HONOR_OPU_WRITE
- ==== =================
+ ===== =============== ===================================================
+ value policy description
+ 0x00 DISABLE disable IPU(=default option in LFS mode)
+ 0x01 FORCE all the time
+ 0x02 SSR if SSR mode is activated
+ 0x04 UTIL if FS utilization is over threashold
+ 0x08 SSR_UTIL if SSR mode is activated and FS utilization is over
+ threashold
+ 0x10 FSYNC activated in fsync path only for high performance
+ flash storages. IPU will be triggered only if the
+ # of dirty pages over min_fsync_blocks.
+ (=default option)
+ 0x20 ASYNC do IPU given by asynchronous write requests
+ 0x40 NOCACHE disable IPU bio cache
+ 0x80 HONOR_OPU_WRITE use OPU write prior to IPU write if inode has
+ FI_OPU_WRITE flag
+ ===== =============== ===================================================
Refer segment.h for details.
@@ -669,3 +676,56 @@
Description: When DATA SEPARATION is on, it controls the age threshold to indicate
the data blocks as warm. By default it was initialized as 2621440 blocks
(equals to 10GB).
+
+What: /sys/fs/f2fs/<disk>/fault_rate
+Date: May 2016
+Contact: "Sheng Yong" <shengyong@oppo.com>
+Contact: "Chao Yu" <chao@kernel.org>
+Description: Enable fault injection in all supported types with
+ specified injection rate.
+
+What: /sys/fs/f2fs/<disk>/fault_type
+Date: May 2016
+Contact: "Sheng Yong" <shengyong@oppo.com>
+Contact: "Chao Yu" <chao@kernel.org>
+Description: Support configuring fault injection type, should be
+ enabled with fault_injection option, fault type value
+ is shown below, it supports single or combined type.
+
+ =================== ===========
+ Type_Name Type_Value
+ =================== ===========
+ FAULT_KMALLOC 0x000000001
+ FAULT_KVMALLOC 0x000000002
+ FAULT_PAGE_ALLOC 0x000000004
+ FAULT_PAGE_GET 0x000000008
+ FAULT_ALLOC_BIO 0x000000010 (obsolete)
+ FAULT_ALLOC_NID 0x000000020
+ FAULT_ORPHAN 0x000000040
+ FAULT_BLOCK 0x000000080
+ FAULT_DIR_DEPTH 0x000000100
+ FAULT_EVICT_INODE 0x000000200
+ FAULT_TRUNCATE 0x000000400
+ FAULT_READ_IO 0x000000800
+ FAULT_CHECKPOINT 0x000001000
+ FAULT_DISCARD 0x000002000
+ FAULT_WRITE_IO 0x000004000
+ FAULT_SLAB_ALLOC 0x000008000
+ FAULT_DQUOT_INIT 0x000010000
+ FAULT_LOCK_OP 0x000020000
+ FAULT_BLKADDR 0x000040000
+ =================== ===========
+
+What: /sys/fs/f2fs/<disk>/discard_io_aware_gran
+Date: January 2023
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: Controls background discard granularity of inner discard thread
+ when is not in idle. Inner thread will not issue discards with size that
+ is smaller than granularity. The unit size is one block(4KB), now only
+ support configuring in range of [0, 512].
+ Default: 512
+
+What: /sys/fs/f2fs/<disk>/last_age_weight
+Date: January 2023
+Contact: "Ping Xiong" <xiongping1@xiaomi.com>
+Description: When DATA SEPARATION is on, it controls the weight of last data block age.
diff --git a/Documentation/ABI/testing/sysfs-kernel-address_bits b/Documentation/ABI/testing/sysfs-kernel-address_bits
new file mode 100644
index 0000000..5d09ff8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-address_bits
@@ -0,0 +1,10 @@
+What: /sys/kernel/address_bit
+Date: May 2023
+KernelVersion: 6.3
+Contact: Thomas Weißschuh <linux@weissschuh.net>
+Description:
+ The address size of the running kernel in bits.
+
+ Access: Read
+
+Users: util-linux
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index 13397b8..2744f21 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -258,6 +258,35 @@
Description: Writing to and reading from this file sets and gets the low
watermark of the scheme in permil.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/nr_filters
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a number 'N' to this file creates the number of
+ directories for setting filters of the scheme named '0' to
+ 'N-1' under the filters/ directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/type
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the type of
+ the memory of the interest. 'anon' for anonymous pages, or
+ 'memcg' for specific memory cgroup can be written and read.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/memcg_path
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'memcg' is written to the 'type' file, writing to and
+ reading from this file sets and gets the path to the memory
+ cgroup of the interest.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/matching
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing 'Y' or 'N' to this file sets whether to filter out
+ pages that do or do not match to the 'type' and 'memcg_path',
+ respectively. Filter out means the action of the scheme will
+ not be applied to.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_tried
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
diff --git a/Documentation/ABI/testing/sysfs-secvar b/Documentation/ABI/testing/sysfs-secvar
index feebb8c..857cf12b 100644
--- a/Documentation/ABI/testing/sysfs-secvar
+++ b/Documentation/ABI/testing/sysfs-secvar
@@ -18,6 +18,14 @@
This determines the format of the variable and the accepted
format of variable updates.
+ On powernv/OPAL, this value is provided by the OPAL firmware
+ and is expected to be "ibm,edk2-compat-v1".
+
+ On pseries/PLPKS, this is generated by the kernel based on the
+ version number in the SB_VERSION variable in the keystore, and
+ has the form "ibm,plpks-sb-v<version>", or
+ "ibm,plpks-sb-unknown" if there is no SB_VERSION variable.
+
What: /sys/firmware/secvar/vars/<variable name>
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
@@ -34,7 +42,7 @@
What: /sys/firmware/secvar/vars/<variable_name>/data
Date: August 2019
-Contact: Nayna Jain h<nayna@linux.ibm.com>
+Contact: Nayna Jain <nayna@linux.ibm.com>
Description: A read-only file containing the value of the variable. The size
of the file represents the maximum size of the variable data.
@@ -44,3 +52,68 @@
Description: A write-only file that is used to submit the new value for the
variable. The size of the file represents the maximum size of
the variable data that can be written.
+
+What: /sys/firmware/secvar/config
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: This optional directory contains read-only config attributes as
+ defined by the secure variable implementation. All data is in
+ ASCII format. The directory is only created if the backing
+ implementation provides variables to populate it, which at
+ present is only PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/version
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Config version as reported by the hypervisor in ASCII decimal
+ format.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/max_object_size
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Maximum allowed size of objects in the keystore in bytes,
+ represented in ASCII decimal format.
+
+ This is not necessarily the same as the max size that can be
+ written to an update file as writes can contain more than
+ object data, you should use the size of the update file for
+ that purpose.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/total_size
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Total size of the PLPKS in bytes, represented in ASCII decimal
+ format.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/used_space
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Current space consumed by the key store, in bytes, represented
+ in ASCII decimal format.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/supported_policies
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Bitmask of supported policy flags by the hypervisor,
+ represented as an 8 byte hexadecimal ASCII string. Consult the
+ hypervisor documentation for what these flags are.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/signed_update_algorithms
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Bitmask of flags indicating which algorithms the hypervisor
+ supports for signed update of objects, represented as a 16 byte
+ hexadecimal ASCII string. Consult the hypervisor documentation
+ for what these flags mean.
+
+ Currently only provided by PLPKS on the pseries platform.
diff --git a/Documentation/Kconfig b/Documentation/Kconfig
index 252bfc1..3a0e7ac 100644
--- a/Documentation/Kconfig
+++ b/Documentation/Kconfig
@@ -1,6 +1,9 @@
+if COMPILE_TEST
+
+menu "Documentation"
+
config WARN_MISSING_DOCUMENTS
bool "Warn if there's a missing documentation file"
- depends on COMPILE_TEST
help
It is not uncommon that a document gets renamed.
This option makes the Kernel to check for missing dependencies,
@@ -11,7 +14,6 @@
config WARN_ABI_ERRORS
bool "Warn if there are errors at ABI files"
- depends on COMPILE_TEST
help
The files under Documentation/ABI should follow what's
described at Documentation/ABI/README. Yet, as they're manually
@@ -20,3 +22,7 @@
scripts/get_abi.pl. Add a check to verify them.
If unsure, select 'N'.
+
+endmenu
+
+endif
diff --git a/Documentation/Makefile b/Documentation/Makefile
index bb73dcb..023fa65 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -28,7 +28,7 @@
PDFLATEX = xelatex
LATEXOPTS = -interaction=batchmode -no-shell-escape
-ifeq ($(KBUILD_VERBOSE),0)
+ifeq ($(findstring 1, $(KBUILD_VERBOSE)),)
SPHINXOPTS += "-q"
endif
diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
index c17c87a..e73f84ae 100644
--- a/Documentation/PCI/index.rst
+++ b/Documentation/PCI/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-=======================
-Linux PCI Bus Subsystem
-=======================
+=================
+PCI Bus Subsystem
+=================
.. toctree::
:maxdepth: 2
diff --git a/Documentation/RCU/NMI-RCU.rst b/Documentation/RCU/NMI-RCU.rst
index 2a92bc6..dff60a8 100644
--- a/Documentation/RCU/NMI-RCU.rst
+++ b/Documentation/RCU/NMI-RCU.rst
@@ -8,7 +8,7 @@
it is possible to use RCU to provide dynamic non-maskable interrupt
handlers, as well as dynamic irq handlers. This document describes
how to do this, drawing loosely from Zwane Mwaikambo's NMI-timer
-work in "arch/x86/kernel/traps.c".
+work in an old version of "arch/x86/kernel/traps.c".
The relevant pieces of code are listed below, each followed by a
brief explanation::
@@ -116,7 +116,7 @@
This same sad story can happen on other CPUs when using
a compiler with aggressive pointer-value speculation
- optimizations.
+ optimizations. (But please don't!)
More important, the rcu_dereference_sched() makes it
clear to someone reading the code that the pointer is
diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst
index e26dda2..8b20fd4 100644
--- a/Documentation/RCU/UP.rst
+++ b/Documentation/RCU/UP.rst
@@ -38,7 +38,7 @@
from process context. However, this can fail in a similar manner.
Suppose that an RCU-based algorithm again scans a linked list containing
-elements A, B, and C in process contexts, but that it invokes a function
+elements A, B, and C in process context, but that it invokes a function
on each element as it is scanned. Suppose further that this function
deletes element B from the list, then passes it to call_rcu() for deferred
freeing. This may be a bit unconventional, but it is perfectly legal
@@ -59,7 +59,8 @@
Suppose that call_rcu() is invoked while holding a lock, and that the
callback function must acquire this same lock. In this case, if
call_rcu() were to directly invoke the callback, the result would
-be self-deadlock.
+be self-deadlock *even if* this invocation occurred from a later
+call_rcu() invocation a full grace period later.
In some cases, it would possible to restructure to code so that
the call_rcu() is delayed until after the lock is released. However,
@@ -85,6 +86,14 @@
:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
+It is important to note that userspace RCU implementations *do*
+permit call_rcu() to directly invoke callbacks, but only if a full
+grace period has elapsed since those callbacks were queued. This is
+the case because some userspace environments are extremely constrained.
+Nevertheless, people writing userspace RCU implementations are strongly
+encouraged to avoid invoking callbacks from call_rcu(), thus obtaining
+the deadlock-avoidance benefits called out above.
+
Summary
-------
diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst
index 9308f1b..2749f43 100644
--- a/Documentation/RCU/lockdep.rst
+++ b/Documentation/RCU/lockdep.rst
@@ -69,9 +69,8 @@
value of the pointer itself, for example, against NULL.
The rcu_dereference_check() check expression can be any boolean
-expression, but would normally include a lockdep expression. However,
-any boolean expression can be used. For a moderately ornate example,
-consider the following::
+expression, but would normally include a lockdep expression. For a
+moderately ornate example, consider the following::
file = rcu_dereference_check(fdt->fd[fd],
lockdep_is_held(&files->file_lock) ||
@@ -97,10 +96,10 @@
atomic_read(&files->count) == 1);
This would verify cases #2 and #3 above, and furthermore lockdep would
-complain if this was used in an RCU read-side critical section unless one
-of these two cases held. Because rcu_dereference_protected() omits all
-barriers and compiler constraints, it generates better code than do the
-other flavors of rcu_dereference(). On the other hand, it is illegal
+complain even if this was used in an RCU read-side critical section unless
+one of these two cases held. Because rcu_dereference_protected() omits
+all barriers and compiler constraints, it generates better code than do
+the other flavors of rcu_dereference(). On the other hand, it is illegal
to use rcu_dereference_protected() if either the RCU-protected pointer
or the RCU-protected data that it points to can change concurrently.
diff --git a/Documentation/RCU/rcu.rst b/Documentation/RCU/rcu.rst
index 3cfe01b..bf6617b 100644
--- a/Documentation/RCU/rcu.rst
+++ b/Documentation/RCU/rcu.rst
@@ -77,15 +77,17 @@
search for the string "Patent" in Documentation/RCU/RTFP.txt to find them.
Of these, one was allowed to lapse by the assignee, and the
others have been contributed to the Linux kernel under GPL.
+ Many (but not all) have long since expired.
There are now also LGPL implementations of user-level RCU
available (https://liburcu.org/).
- I hear that RCU needs work in order to support realtime kernels?
- Realtime-friendly RCU can be enabled via the CONFIG_PREEMPT_RCU
+ Realtime-friendly RCU are enabled via the CONFIG_PREEMPTION
kernel configuration parameter.
- Where can I find more information on RCU?
See the Documentation/RCU/RTFP.txt file.
- Or point your browser at (http://www.rdrop.com/users/paulmck/RCU/).
+ Or point your browser at (https://docs.google.com/document/d/1X0lThx8OK0ZgLMqVoXiR4ZrGURHrXK6NyLRbeXe3Xac/edit)
+ or (https://docs.google.com/document/d/1GCdQC8SDbb54W1shjEXqGZ0Rq8a6kIeYutdSIajfpLA/edit?usp=sharing).
diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst
index 81e828c..3b739f6 100644
--- a/Documentation/RCU/rcu_dereference.rst
+++ b/Documentation/RCU/rcu_dereference.rst
@@ -19,8 +19,9 @@
can reload the value, and won't your code have fun with two
different values for a single pointer! Without rcu_dereference(),
DEC Alpha can load a pointer, dereference that pointer, and
- return data preceding initialization that preceded the store of
- the pointer.
+ return data preceding initialization that preceded the store
+ of the pointer. (As noted later, in recent kernels READ_ONCE()
+ also prevents DEC Alpha from playing these tricks.)
In addition, the volatile cast in rcu_dereference() prevents the
compiler from deducing the resulting pointer value. Please see
@@ -34,7 +35,7 @@
takes on the role of the lockless_dereference() primitive that
was removed in v4.15.
-- You are only permitted to use rcu_dereference on pointer values.
+- You are only permitted to use rcu_dereference() on pointer values.
The compiler simply knows too much about integral values to
trust it to carry dependencies through integer operations.
There are a very few exceptions, namely that you can temporarily
@@ -240,6 +241,7 @@
struct foo *q;
int r1, r2;
+ rcu_read_lock();
p = rcu_dereference(gp2);
if (p == NULL)
return;
@@ -248,7 +250,10 @@
if (p == q) {
/* The compiler decides that q->c is same as p->c. */
r2 = p->c; /* Could get 44 on weakly order system. */
+ } else {
+ r2 = p->c - r1; /* Unconditional access to p->c. */
}
+ rcu_read_unlock();
do_something_with(r1, r2);
}
@@ -297,6 +302,7 @@
struct foo *q;
int r1, r2;
+ rcu_read_lock();
p = rcu_dereference(gp2);
if (p == NULL)
return;
@@ -306,7 +312,12 @@
if (p == q) {
/* The compiler decides that q->c is same as p->c. */
r2 = p->c; /* Locking guarantees r2 == 144. */
+ } else {
+ spin_lock(&q->lock);
+ r2 = q->c - r1;
+ spin_unlock(&q->lock);
}
+ rcu_read_unlock();
spin_unlock(&p->lock);
do_something_with(r1, r2);
}
@@ -364,7 +375,7 @@
compiler to make the return values independent of the load from "gp",
in turn destroying the ordering between this load and the loads of the
return values. This can result in "p->b" returning pre-initialization
-garbage values.
+garbage values on weakly ordered systems.
In short, rcu_dereference() is *not* optional when you are going to
dereference the resulting pointer.
@@ -430,7 +441,7 @@
SPARSE CHECKING OF RCU-PROTECTED POINTERS
-----------------------------------------
-The sparse static-analysis tool checks for direct access to RCU-protected
+The sparse static-analysis tool checks for non-RCU access to RCU-protected
pointers, which can result in "interesting" bugs due to compiler
optimizations involving invented loads and perhaps also load tearing.
For example, suppose someone mistakenly does something like this::
diff --git a/Documentation/RCU/rcubarrier.rst b/Documentation/RCU/rcubarrier.rst
index 3b4a248..6da7f66 100644
--- a/Documentation/RCU/rcubarrier.rst
+++ b/Documentation/RCU/rcubarrier.rst
@@ -5,37 +5,12 @@
[Originally published in LWN Jan. 14, 2007: http://lwn.net/Articles/217484/]
-RCU (read-copy update) is a synchronization mechanism that can be thought
-of as a replacement for read-writer locking (among other things), but with
-very low-overhead readers that are immune to deadlock, priority inversion,
-and unbounded latency. RCU read-side critical sections are delimited
-by rcu_read_lock() and rcu_read_unlock(), which, in non-CONFIG_PREEMPTION
-kernels, generate no code whatsoever.
-
-This means that RCU writers are unaware of the presence of concurrent
-readers, so that RCU updates to shared data must be undertaken quite
-carefully, leaving an old version of the data structure in place until all
-pre-existing readers have finished. These old versions are needed because
-such readers might hold a reference to them. RCU updates can therefore be
-rather expensive, and RCU is thus best suited for read-mostly situations.
-
-How can an RCU writer possibly determine when all readers are finished,
-given that readers might well leave absolutely no trace of their
-presence? There is a synchronize_rcu() primitive that blocks until all
-pre-existing readers have completed. An updater wishing to delete an
-element p from a linked list might do the following, while holding an
-appropriate lock, of course::
-
- list_del_rcu(p);
- synchronize_rcu();
- kfree(p);
-
-But the above code cannot be used in IRQ context -- the call_rcu()
-primitive must be used instead. This primitive takes a pointer to an
-rcu_head struct placed within the RCU-protected data structure and
-another pointer to a function that may be invoked later to free that
-structure. Code to delete an element p from the linked list from IRQ
-context might then be as follows::
+RCU updaters sometimes use call_rcu() to initiate an asynchronous wait for
+a grace period to elapse. This primitive takes a pointer to an rcu_head
+struct placed within the RCU-protected data structure and another pointer
+to a function that may be invoked later to free that structure. Code to
+delete an element p from the linked list from IRQ context might then be
+as follows::
list_del_rcu(p);
call_rcu(&p->rcu, p_callback);
@@ -54,7 +29,7 @@
Unloading Modules That Use call_rcu()
-------------------------------------
-But what if p_callback is defined in an unloadable module?
+But what if the p_callback() function is defined in an unloadable module?
If we unload the module while some RCU callbacks are pending,
the CPUs executing these callbacks are going to be severely
@@ -67,20 +42,21 @@
One might be tempted to try several back-to-back synchronize_rcu()
calls, but this is still not guaranteed to work. If there is a very
-heavy RCU-callback load, then some of the callbacks might be deferred
-in order to allow other processing to proceed. Such deferral is required
-in realtime kernels in order to avoid excessive scheduling latencies.
+heavy RCU-callback load, then some of the callbacks might be deferred in
+order to allow other processing to proceed. For but one example, such
+deferral is required in realtime kernels in order to avoid excessive
+scheduling latencies.
rcu_barrier()
-------------
-We instead need the rcu_barrier() primitive. Rather than waiting for
-a grace period to elapse, rcu_barrier() waits for all outstanding RCU
-callbacks to complete. Please note that rcu_barrier() does **not** imply
-synchronize_rcu(), in particular, if there are no RCU callbacks queued
-anywhere, rcu_barrier() is within its rights to return immediately,
-without waiting for a grace period to elapse.
+This situation can be handled by the rcu_barrier() primitive. Rather
+than waiting for a grace period to elapse, rcu_barrier() waits for all
+outstanding RCU callbacks to complete. Please note that rcu_barrier()
+does **not** imply synchronize_rcu(), in particular, if there are no RCU
+callbacks queued anywhere, rcu_barrier() is within its rights to return
+immediately, without waiting for anything, let alone a grace period.
Pseudo-code using rcu_barrier() is as follows:
@@ -89,83 +65,86 @@
3. Allow the module to be unloaded.
There is also an srcu_barrier() function for SRCU, and you of course
-must match the flavor of rcu_barrier() with that of call_rcu(). If your
-module uses multiple flavors of call_rcu(), then it must also use multiple
-flavors of rcu_barrier() when unloading that module. For example, if
-it uses call_rcu(), call_srcu() on srcu_struct_1, and call_srcu() on
-srcu_struct_2, then the following three lines of code will be required
-when unloading::
+must match the flavor of srcu_barrier() with that of call_srcu().
+If your module uses multiple srcu_struct structures, then it must also
+use multiple invocations of srcu_barrier() when unloading that module.
+For example, if it uses call_rcu(), call_srcu() on srcu_struct_1, and
+call_srcu() on srcu_struct_2, then the following three lines of code
+will be required when unloading::
- 1 rcu_barrier();
- 2 srcu_barrier(&srcu_struct_1);
- 3 srcu_barrier(&srcu_struct_2);
+ 1 rcu_barrier();
+ 2 srcu_barrier(&srcu_struct_1);
+ 3 srcu_barrier(&srcu_struct_2);
-The rcutorture module makes use of rcu_barrier() in its exit function
-as follows::
+If latency is of the essence, workqueues could be used to run these
+three functions concurrently.
- 1 static void
- 2 rcu_torture_cleanup(void)
- 3 {
- 4 int i;
- 5
- 6 fullstop = 1;
- 7 if (shuffler_task != NULL) {
- 8 VERBOSE_PRINTK_STRING("Stopping rcu_torture_shuffle task");
- 9 kthread_stop(shuffler_task);
- 10 }
- 11 shuffler_task = NULL;
+An ancient version of the rcutorture module makes use of rcu_barrier()
+in its exit function as follows::
+
+ 1 static void
+ 2 rcu_torture_cleanup(void)
+ 3 {
+ 4 int i;
+ 5
+ 6 fullstop = 1;
+ 7 if (shuffler_task != NULL) {
+ 8 VERBOSE_PRINTK_STRING("Stopping rcu_torture_shuffle task");
+ 9 kthread_stop(shuffler_task);
+ 10 }
+ 11 shuffler_task = NULL;
12
- 13 if (writer_task != NULL) {
- 14 VERBOSE_PRINTK_STRING("Stopping rcu_torture_writer task");
- 15 kthread_stop(writer_task);
- 16 }
- 17 writer_task = NULL;
+ 13 if (writer_task != NULL) {
+ 14 VERBOSE_PRINTK_STRING("Stopping rcu_torture_writer task");
+ 15 kthread_stop(writer_task);
+ 16 }
+ 17 writer_task = NULL;
18
- 19 if (reader_tasks != NULL) {
- 20 for (i = 0; i < nrealreaders; i++) {
- 21 if (reader_tasks[i] != NULL) {
- 22 VERBOSE_PRINTK_STRING(
- 23 "Stopping rcu_torture_reader task");
- 24 kthread_stop(reader_tasks[i]);
- 25 }
- 26 reader_tasks[i] = NULL;
- 27 }
- 28 kfree(reader_tasks);
- 29 reader_tasks = NULL;
- 30 }
- 31 rcu_torture_current = NULL;
+ 19 if (reader_tasks != NULL) {
+ 20 for (i = 0; i < nrealreaders; i++) {
+ 21 if (reader_tasks[i] != NULL) {
+ 22 VERBOSE_PRINTK_STRING(
+ 23 "Stopping rcu_torture_reader task");
+ 24 kthread_stop(reader_tasks[i]);
+ 25 }
+ 26 reader_tasks[i] = NULL;
+ 27 }
+ 28 kfree(reader_tasks);
+ 29 reader_tasks = NULL;
+ 30 }
+ 31 rcu_torture_current = NULL;
32
- 33 if (fakewriter_tasks != NULL) {
- 34 for (i = 0; i < nfakewriters; i++) {
- 35 if (fakewriter_tasks[i] != NULL) {
- 36 VERBOSE_PRINTK_STRING(
- 37 "Stopping rcu_torture_fakewriter task");
- 38 kthread_stop(fakewriter_tasks[i]);
- 39 }
- 40 fakewriter_tasks[i] = NULL;
- 41 }
- 42 kfree(fakewriter_tasks);
- 43 fakewriter_tasks = NULL;
- 44 }
+ 33 if (fakewriter_tasks != NULL) {
+ 34 for (i = 0; i < nfakewriters; i++) {
+ 35 if (fakewriter_tasks[i] != NULL) {
+ 36 VERBOSE_PRINTK_STRING(
+ 37 "Stopping rcu_torture_fakewriter task");
+ 38 kthread_stop(fakewriter_tasks[i]);
+ 39 }
+ 40 fakewriter_tasks[i] = NULL;
+ 41 }
+ 42 kfree(fakewriter_tasks);
+ 43 fakewriter_tasks = NULL;
+ 44 }
45
- 46 if (stats_task != NULL) {
- 47 VERBOSE_PRINTK_STRING("Stopping rcu_torture_stats task");
- 48 kthread_stop(stats_task);
- 49 }
- 50 stats_task = NULL;
+ 46 if (stats_task != NULL) {
+ 47 VERBOSE_PRINTK_STRING("Stopping rcu_torture_stats task");
+ 48 kthread_stop(stats_task);
+ 49 }
+ 50 stats_task = NULL;
51
- 52 /* Wait for all RCU callbacks to fire. */
- 53 rcu_barrier();
+ 52 /* Wait for all RCU callbacks to fire. */
+ 53 rcu_barrier();
54
- 55 rcu_torture_stats_print(); /* -After- the stats thread is stopped! */
+ 55 rcu_torture_stats_print(); /* -After- the stats thread is stopped! */
56
- 57 if (cur_ops->cleanup != NULL)
- 58 cur_ops->cleanup();
- 59 if (atomic_read(&n_rcu_torture_error))
- 60 rcu_torture_print_module_parms("End of test: FAILURE");
- 61 else
- 62 rcu_torture_print_module_parms("End of test: SUCCESS");
- 63 }
+ 57 if (cur_ops->cleanup != NULL)
+ 58 cur_ops->cleanup();
+ 59 if (atomic_read(&n_rcu_torture_error))
+ 60 rcu_torture_print_module_parms("End of test: FAILURE");
+ 61 else
+ 62 rcu_torture_print_module_parms("End of test: SUCCESS");
+ 63 }
Line 6 sets a global variable that prevents any RCU callbacks from
re-posting themselves. This will not be necessary in most cases, since
@@ -190,16 +169,17 @@
:ref:`Answer to Quick Quiz #1 <answer_rcubarrier_quiz_1>`
Your module might have additional complications. For example, if your
-module invokes call_rcu() from timers, you will need to first cancel all
-the timers, and only then invoke rcu_barrier() to wait for any remaining
+module invokes call_rcu() from timers, you will need to first refrain
+from posting new timers, cancel (or wait for) all the already-posted
+timers, and only then invoke rcu_barrier() to wait for any remaining
RCU callbacks to complete.
-Of course, if you module uses call_rcu(), you will need to invoke
+Of course, if your module uses call_rcu(), you will need to invoke
rcu_barrier() before unloading. Similarly, if your module uses
call_srcu(), you will need to invoke srcu_barrier() before unloading,
and on the same srcu_struct structure. If your module uses call_rcu()
-**and** call_srcu(), then you will need to invoke rcu_barrier() **and**
-srcu_barrier().
+**and** call_srcu(), then (as noted above) you will need to invoke
+rcu_barrier() **and** srcu_barrier().
Implementing rcu_barrier()
@@ -211,27 +191,40 @@
callback queues, and then waits until they have all started executing, at
which point, all earlier RCU callbacks are guaranteed to have completed.
-The original code for rcu_barrier() was as follows::
+The original code for rcu_barrier() was roughly as follows::
- 1 void rcu_barrier(void)
- 2 {
- 3 BUG_ON(in_interrupt());
- 4 /* Take cpucontrol mutex to protect against CPU hotplug */
- 5 mutex_lock(&rcu_barrier_mutex);
- 6 init_completion(&rcu_barrier_completion);
- 7 atomic_set(&rcu_barrier_cpu_count, 0);
- 8 on_each_cpu(rcu_barrier_func, NULL, 0, 1);
- 9 wait_for_completion(&rcu_barrier_completion);
- 10 mutex_unlock(&rcu_barrier_mutex);
- 11 }
+ 1 void rcu_barrier(void)
+ 2 {
+ 3 BUG_ON(in_interrupt());
+ 4 /* Take cpucontrol mutex to protect against CPU hotplug */
+ 5 mutex_lock(&rcu_barrier_mutex);
+ 6 init_completion(&rcu_barrier_completion);
+ 7 atomic_set(&rcu_barrier_cpu_count, 1);
+ 8 on_each_cpu(rcu_barrier_func, NULL, 0, 1);
+ 9 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
+ 10 complete(&rcu_barrier_completion);
+ 11 wait_for_completion(&rcu_barrier_completion);
+ 12 mutex_unlock(&rcu_barrier_mutex);
+ 13 }
-Line 3 verifies that the caller is in process context, and lines 5 and 10
+Line 3 verifies that the caller is in process context, and lines 5 and 12
use rcu_barrier_mutex to ensure that only one rcu_barrier() is using the
global completion and counters at a time, which are initialized on lines
6 and 7. Line 8 causes each CPU to invoke rcu_barrier_func(), which is
shown below. Note that the final "1" in on_each_cpu()'s argument list
ensures that all the calls to rcu_barrier_func() will have completed
-before on_each_cpu() returns. Line 9 then waits for the completion.
+before on_each_cpu() returns. Line 9 removes the initial count from
+rcu_barrier_cpu_count, and if this count is now zero, line 10 finalizes
+the completion, which prevents line 11 from blocking. Either way,
+line 11 then waits (if needed) for the completion.
+
+.. _rcubarrier_quiz_2:
+
+Quick Quiz #2:
+ Why doesn't line 8 initialize rcu_barrier_cpu_count to zero,
+ thereby avoiding the need for lines 9 and 10?
+
+:ref:`Answer to Quick Quiz #2 <answer_rcubarrier_quiz_2>`
This code was rewritten in 2008 and several times thereafter, but this
still gives the general idea.
@@ -239,21 +232,21 @@
The rcu_barrier_func() runs on each CPU, where it invokes call_rcu()
to post an RCU callback, as follows::
- 1 static void rcu_barrier_func(void *notused)
- 2 {
- 3 int cpu = smp_processor_id();
- 4 struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
- 5 struct rcu_head *head;
- 6
- 7 head = &rdp->barrier;
- 8 atomic_inc(&rcu_barrier_cpu_count);
- 9 call_rcu(head, rcu_barrier_callback);
- 10 }
+ 1 static void rcu_barrier_func(void *notused)
+ 2 {
+ 3 int cpu = smp_processor_id();
+ 4 struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
+ 5 struct rcu_head *head;
+ 6
+ 7 head = &rdp->barrier;
+ 8 atomic_inc(&rcu_barrier_cpu_count);
+ 9 call_rcu(head, rcu_barrier_callback);
+ 10 }
Lines 3 and 4 locate RCU's internal per-CPU rcu_data structure,
which contains the struct rcu_head that needed for the later call to
call_rcu(). Line 7 picks up a pointer to this struct rcu_head, and line
-8 increments a global counter. This counter will later be decremented
+8 increments the global counter. This counter will later be decremented
by the callback. Line 9 then registers the rcu_barrier_callback() on
the current CPU's queue.
@@ -261,33 +254,34 @@
rcu_barrier_cpu_count variable and finalizes the completion when it
reaches zero, as follows::
- 1 static void rcu_barrier_callback(struct rcu_head *notused)
- 2 {
- 3 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
- 4 complete(&rcu_barrier_completion);
- 5 }
+ 1 static void rcu_barrier_callback(struct rcu_head *notused)
+ 2 {
+ 3 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
+ 4 complete(&rcu_barrier_completion);
+ 5 }
-.. _rcubarrier_quiz_2:
+.. _rcubarrier_quiz_3:
-Quick Quiz #2:
+Quick Quiz #3:
What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in
rcu_barrier() returning prematurely?
-:ref:`Answer to Quick Quiz #2 <answer_rcubarrier_quiz_2>`
+:ref:`Answer to Quick Quiz #3 <answer_rcubarrier_quiz_3>`
The current rcu_barrier() implementation is more complex, due to the need
to avoid disturbing idle CPUs (especially on battery-powered systems)
and the need to minimally disturb non-idle CPUs in real-time systems.
-However, the code above illustrates the concepts.
+In addition, a great many optimizations have been applied. However,
+the code above illustrates the concepts.
rcu_barrier() Summary
---------------------
-The rcu_barrier() primitive has seen relatively little use, since most
+The rcu_barrier() primitive is used relatively infrequently, since most
code using RCU is in the core kernel rather than in modules. However, if
you are using RCU from an unloadable module, you need to use rcu_barrier()
so that your module may be safely unloaded.
@@ -302,7 +296,8 @@
Is there any other situation where rcu_barrier() might
be required?
-Answer: Interestingly enough, rcu_barrier() was not originally
+Answer:
+ Interestingly enough, rcu_barrier() was not originally
implemented for module unloading. Nikita Danilov was using
RCU in a filesystem, which resulted in a similar situation at
filesystem-unmount time. Dipankar Sarma coded up rcu_barrier()
@@ -318,13 +313,48 @@
.. _answer_rcubarrier_quiz_2:
Quick Quiz #2:
+ Why doesn't line 8 initialize rcu_barrier_cpu_count to zero,
+ thereby avoiding the need for lines 9 and 10?
+
+Answer:
+ Suppose that the on_each_cpu() function shown on line 8 was
+ delayed, so that CPU 0's rcu_barrier_func() executed and
+ the corresponding grace period elapsed, all before CPU 1's
+ rcu_barrier_func() started executing. This would result in
+ rcu_barrier_cpu_count being decremented to zero, so that line
+ 11's wait_for_completion() would return immediately, failing to
+ wait for CPU 1's callbacks to be invoked.
+
+ Note that this was not a problem when the rcu_barrier() code
+ was first added back in 2005. This is because on_each_cpu()
+ disables preemption, which acted as an RCU read-side critical
+ section, thus preventing CPU 0's grace period from completing
+ until on_each_cpu() had dealt with all of the CPUs. However,
+ with the advent of preemptible RCU, rcu_barrier() no longer
+ waited on nonpreemptible regions of code in preemptible kernels,
+ that being the job of the new rcu_barrier_sched() function.
+
+ However, with the RCU flavor consolidation around v4.20, this
+ possibility was once again ruled out, because the consolidated
+ RCU once again waits on nonpreemptible regions of code.
+
+ Nevertheless, that extra count might still be a good idea.
+ Relying on these sort of accidents of implementation can result
+ in later surprise bugs when the implementation changes.
+
+:ref:`Back to Quick Quiz #2 <rcubarrier_quiz_2>`
+
+.. _answer_rcubarrier_quiz_3:
+
+Quick Quiz #3:
What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in
rcu_barrier() returning prematurely?
-Answer: This cannot happen. The reason is that on_each_cpu() has its last
+Answer:
+ This cannot happen. The reason is that on_each_cpu() has its last
argument, the wait flag, set to "1". This flag is passed through
to smp_call_function() and further to smp_call_function_on_cpu(),
causing this latter to spin until the cross-CPU invocation of
@@ -336,18 +366,15 @@
Therefore, on_each_cpu() disables preemption across its call
to smp_call_function() and also across the local call to
- rcu_barrier_func(). This prevents the local CPU from context
- switching, again preventing grace periods from completing. This
+ rcu_barrier_func(). Because recent RCU implementations treat
+ preemption-disabled regions of code as RCU read-side critical
+ sections, this prevents grace periods from completing. This
means that all CPUs have executed rcu_barrier_func() before
the first rcu_barrier_callback() can possibly execute, in turn
preventing rcu_barrier_cpu_count from prematurely reaching zero.
- Currently, -rt implementations of RCU keep but a single global
- queue for RCU callbacks, and thus do not suffer from this
- problem. However, when the -rt RCU eventually does have per-CPU
- callback queues, things will have to change. One simple change
- is to add an rcu_read_lock() before line 8 of rcu_barrier()
- and an rcu_read_unlock() after line 8 of this same function. If
- you can think of a better change, please let me know!
+ But if on_each_cpu() ever decides to forgo disabling preemption,
+ as might well happen due to real-time latency considerations,
+ initializing rcu_barrier_cpu_count to one will save the day.
-:ref:`Back to Quick Quiz #2 <rcubarrier_quiz_2>`
+:ref:`Back to Quick Quiz #3 <rcubarrier_quiz_3>`
diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst
index ca46927..9a734bf 100644
--- a/Documentation/RCU/rculist_nulls.rst
+++ b/Documentation/RCU/rculist_nulls.rst
@@ -14,19 +14,19 @@
=============
Using special makers (called 'nulls') is a convenient way
-to solve following problem :
+to solve following problem.
-A typical RCU linked list managing objects which are
-allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can
-use following algos :
+Without 'nulls', a typical RCU linked list managing objects which are
+allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following
+algorithms:
-1) Lookup algo
---------------
+1) Lookup algorithm
+-------------------
::
- rcu_read_lock()
begin:
+ rcu_read_lock()
obj = lockless_lookup(key);
if (obj) {
if (!try_get_ref(obj)) // might fail for free objects
@@ -38,6 +38,7 @@
*/
if (obj->key != key) { // not the object we expected
put_ref(obj);
+ rcu_read_unlock();
goto begin;
}
}
@@ -52,9 +53,9 @@
{
struct hlist_node *node, *next;
for (pos = rcu_dereference((head)->first);
- pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
- ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
- pos = rcu_dereference(next))
+ pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
+ ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
+ pos = rcu_dereference(next))
if (obj->key == key)
return obj;
return NULL;
@@ -64,9 +65,9 @@
struct hlist_node *node;
for (pos = rcu_dereference((head)->first);
- pos && ({ prefetch(pos->next); 1; }) &&
- ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
- pos = rcu_dereference(pos->next))
+ pos && ({ prefetch(pos->next); 1; }) &&
+ ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
+ pos = rcu_dereference(pos->next))
if (obj->key == key)
return obj;
return NULL;
@@ -82,36 +83,32 @@
solved by pre-fetching the "next" field (with proper barriers) before
checking the key."
-2) Insert algo
---------------
+2) Insertion algorithm
+----------------------
We need to make sure a reader cannot read the new 'obj->obj_next' value
-and previous value of 'obj->key'. Or else, an item could be deleted
+and previous value of 'obj->key'. Otherwise, an item could be deleted
from a chain, and inserted into another chain. If new chain was empty
-before the move, 'next' pointer is NULL, and lockless reader can
-not detect it missed following items in original chain.
+before the move, 'next' pointer is NULL, and lockless reader can not
+detect the fact that it missed following items in original chain.
::
/*
- * Please note that new inserts are done at the head of list,
- * not in the middle or end.
- */
+ * Please note that new inserts are done at the head of list,
+ * not in the middle or end.
+ */
obj = kmem_cache_alloc(...);
lock_chain(); // typically a spin_lock()
obj->key = key;
- /*
- * we need to make sure obj->key is updated before obj->next
- * or obj->refcnt
- */
- smp_wmb();
- atomic_set(&obj->refcnt, 1);
+ atomic_set_release(&obj->refcnt, 1); // key before refcnt
hlist_add_head_rcu(&obj->obj_node, list);
unlock_chain(); // typically a spin_unlock()
-3) Remove algo
---------------
+3) Removal algorithm
+--------------------
+
Nothing special here, we can use a standard RCU hlist deletion.
But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
very very fast (before the end of RCU grace period)
@@ -133,7 +130,7 @@
========================
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
-and extra smp_wmb() in insert function.
+and extra _release() in insert function.
For example, if we choose to store the slot number as the 'nulls'
end-of-list marker for each slot of the hash table, we can detect
@@ -142,59 +139,61 @@
the lookup met the end of chain. If final 'nulls' value
is not the slot number, then we must restart the lookup at
the beginning. If the object was moved to the same chain,
-then the reader doesn't care : It might eventually
+then the reader doesn't care: It might occasionally
scan the list again without harm.
-1) lookup algo
---------------
+1) lookup algorithm
+-------------------
::
head = &table[slot];
- rcu_read_lock();
begin:
+ rcu_read_lock();
hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
if (obj->key == key) {
- if (!try_get_ref(obj)) // might fail for free objects
- goto begin;
- if (obj->key != key) { // not the object we expected
- put_ref(obj);
+ if (!try_get_ref(obj)) { // might fail for free objects
+ rcu_read_unlock();
goto begin;
}
- goto out;
+ if (obj->key != key) { // not the object we expected
+ put_ref(obj);
+ rcu_read_unlock();
+ goto begin;
+ }
+ goto out;
+ }
}
- /*
- * if the nulls value we got at the end of this lookup is
- * not the expected one, we must restart lookup.
- * We probably met an item that was moved to another chain.
- */
- if (get_nulls_value(node) != slot)
- goto begin;
+
+ // If the nulls value we got at the end of this lookup is
+ // not the expected one, we must restart lookup.
+ // We probably met an item that was moved to another chain.
+ if (get_nulls_value(node) != slot) {
+ put_ref(obj);
+ rcu_read_unlock();
+ goto begin;
+ }
obj = NULL;
out:
rcu_read_unlock();
-2) Insert function
-------------------
+2) Insert algorithm
+-------------------
::
/*
- * Please note that new inserts are done at the head of list,
- * not in the middle or end.
- */
+ * Please note that new inserts are done at the head of list,
+ * not in the middle or end.
+ */
obj = kmem_cache_alloc(cachep);
lock_chain(); // typically a spin_lock()
obj->key = key;
+ atomic_set_release(&obj->refcnt, 1); // key before refcnt
/*
- * changes to obj->key must be visible before refcnt one
- */
- smp_wmb();
- atomic_set(&obj->refcnt, 1);
- /*
- * insert obj in RCU way (readers might be traversing chain)
- */
+ * insert obj in RCU way (readers might be traversing chain)
+ */
hlist_nulls_add_head_rcu(&obj->obj_node, list);
unlock_chain(); // typically a spin_unlock()
diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst
index e38c587..ca7b7cd 100644
--- a/Documentation/RCU/stallwarn.rst
+++ b/Documentation/RCU/stallwarn.rst
@@ -25,10 +25,10 @@
- A CPU looping with bottom halves disabled.
-- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the kernel
- without invoking schedule(). If the looping in the kernel is
- really expected and desirable behavior, you might need to add
- some calls to cond_resched().
+- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the
+ kernel without potentially invoking schedule(). If the looping
+ in the kernel is really expected and desirable behavior, you
+ might need to add some calls to cond_resched().
- Booting Linux using a console connection that is too slow to
keep up with the boot-time console-message rate. For example,
@@ -108,16 +108,17 @@
- A bug in the RCU implementation.
-- A hardware failure. This is quite unlikely, but has occurred
- at least once in real life. A CPU failed in a running system,
- becoming unresponsive, but not causing an immediate crash.
- This resulted in a series of RCU CPU stall warnings, eventually
- leading the realization that the CPU had failed.
+- A hardware failure. This is quite unlikely, but is not at all
+ uncommon in large datacenter. In one memorable case some decades
+ back, a CPU failed in a running system, becoming unresponsive,
+ but not causing an immediate crash. This resulted in a series
+ of RCU CPU stall warnings, eventually leading the realization
+ that the CPU had failed.
-The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning.
-Note that SRCU does *not* have CPU stall warnings. Please note that
-RCU only detects CPU stalls when there is a grace period in progress.
-No grace period, no CPU stall warnings.
+The RCU, RCU-sched, RCU-tasks, and RCU-tasks-trace implementations have
+CPU stall warning. Note that SRCU does *not* have CPU stall warnings.
+Please note that RCU only detects CPU stalls when there is a grace period
+in progress. No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.
@@ -205,16 +206,21 @@
rcupdate.rcu_task_stall_timeout
-------------------------------
- This boot/sysfs parameter controls the RCU-tasks stall warning
- interval. A value of zero or less suppresses RCU-tasks stall
- warnings. A positive value sets the stall-warning interval
- in seconds. An RCU-tasks stall warning starts with the line:
+ This boot/sysfs parameter controls the RCU-tasks and
+ RCU-tasks-trace stall warning intervals. A value of zero or less
+ suppresses RCU-tasks stall warnings. A positive value sets the
+ stall-warning interval in seconds. An RCU-tasks stall warning
+ starts with the line:
INFO: rcu_tasks detected stalls on tasks:
And continues with the output of sched_show_task() for each
task stalling the current RCU-tasks grace period.
+ An RCU-tasks-trace stall warning starts (and continues) similarly:
+
+ INFO: rcu_tasks_trace detected stalls on tasks
+
Interpreting RCU's CPU Stall-Detector "Splats"
==============================================
@@ -248,7 +254,8 @@
is in dyntick-idle mode and an odd-numbered value otherwise. The hex
number between the two "/"s is the value of the nesting, which will be
a small non-negative number if in the idle loop (as shown above) and a
-very large positive number otherwise.
+very large positive number otherwise. The number following the final
+"/" is the NMI nesting, which will be a small non-negative number.
The "softirq=" portion of the message tracks the number of RCU softirq
handlers that the stalled CPU has executed. The number before the "/"
@@ -383,3 +390,95 @@
It is entirely possible to see stall warnings from normal and from
expedited grace periods at about the same time during the same run.
+
+RCU_CPU_STALL_CPUTIME
+=====================
+
+In kernels built with CONFIG_RCU_CPU_STALL_CPUTIME=y or booted with
+rcupdate.rcu_cpu_stall_cputime=1, the following additional information
+is supplied with each RCU CPU stall warning::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 624 45 0
+ rcu: cputime: 69 1 2425 ==> 2500(ms)
+
+These statistics are collected during the sampling period. The values
+in row "number:" are the number of hard interrupts, number of soft
+interrupts, and number of context switches on the stalled CPU. The
+first three values in row "cputime:" indicate the CPU time in
+milliseconds consumed by hard interrupts, soft interrupts, and tasks
+on the stalled CPU. The last number is the measurement interval, again
+in milliseconds. Because user-mode tasks normally do not cause RCU CPU
+stalls, these tasks are typically kernel tasks, which is why only the
+system CPU time are considered.
+
+The sampling period is shown as follows::
+
+ |<------------first timeout---------->|<-----second timeout----->|
+ |<--half timeout-->|<--half timeout-->| |
+ | |<--first period-->| |
+ | |<-----------second sampling period---------->|
+ | | | |
+ snapshot time point 1st-stall 2nd-stall
+
+The following describes four typical scenarios:
+
+1. A CPU looping with interrupts disabled.
+
+ ::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 0 0 0
+ rcu: cputime: 0 0 0 ==> 2500(ms)
+
+ Because interrupts have been disabled throughout the measurement
+ interval, there are no interrupts and no context switches.
+ Furthermore, because CPU time consumption was measured using interrupt
+ handlers, the system CPU consumption is misleadingly measured as zero.
+ This scenario will normally also have "(0 ticks this GP)" printed on
+ this CPU's summary line.
+
+2. A CPU looping with bottom halves disabled.
+
+ This is similar to the previous example, but with non-zero number of
+ and CPU time consumed by hard interrupts, along with non-zero CPU
+ time consumed by in-kernel execution::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 624 0 0
+ rcu: cputime: 49 0 2446 ==> 2500(ms)
+
+ The fact that there are zero softirqs gives a hint that these were
+ disabled, perhaps via local_bh_disable(). It is of course possible
+ that there were no softirqs, perhaps because all events that would
+ result in softirq execution are confined to other CPUs. In this case,
+ the diagnosis should continue as shown in the next example.
+
+3. A CPU looping with preemption disabled.
+
+ Here, only the number of context switches is zero::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 624 45 0
+ rcu: cputime: 69 1 2425 ==> 2500(ms)
+
+ This situation hints that the stalled CPU was looping with preemption
+ disabled.
+
+4. No looping, but massive hard and soft interrupts.
+
+ ::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: xx xx 0
+ rcu: cputime: xx xx 0 ==> 2500(ms)
+
+ Here, the number and CPU time of hard interrupts are all non-zero,
+ but the number of context switches and the in-kernel CPU time consumed
+ are zero. The number and cputime of soft interrupts will usually be
+ non-zero, but could be zero, for example, if the CPU was spinning
+ within a single hard interrupt handler.
+
+ If this type of RCU CPU stall warning can be reproduced, you can
+ narrow it down by looking at /proc/interrupts or by writing code to
+ trace each interrupt, for example, by referring to show_interrupts().
diff --git a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst
index a901477..0316ba0 100644
--- a/Documentation/RCU/torture.rst
+++ b/Documentation/RCU/torture.rst
@@ -206,7 +206,11 @@
using the --bootargs parameter discussed below.
Sometimes additional debugging is useful, and in such cases the --kconfig
-parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_KASAN=y'``.
+parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_RCU_EQS_DEBUG=y'``.
+In addition, there are the --gdb, --kasan, and --kcsan parameters.
+Note that --gdb limits you to one scenario per kvm.sh run and requires
+that you have another window open from which to run ``gdb`` as instructed
+by the script.
Kernel boot arguments can also be supplied, for example, to control
rcutorture's module parameters. For example, to test a change to RCU's
@@ -219,10 +223,17 @@
--bootargs 'rcutorture.fwd_progress=0'
Sometimes all that is needed is a full set of kernel builds. This is
-what the --buildonly argument does.
+what the --buildonly parameter does.
-Finally, the --trust-make argument allows each kernel build to reuse what
-it can from the previous kernel build.
+The --duration parameter can override the default run time of 30 minutes.
+For example, ``--duration 2d`` would run for two days, ``--duration 3h``
+would run for three hours, ``--duration 5m`` would run for five minutes,
+and ``--duration 45s`` would run for 45 seconds. This last can be useful
+for tracking down rare boot-time failures.
+
+Finally, the --trust-make parameter allows each kernel build to reuse what
+it can from the previous kernel build. Please note that without the
+--trust-make parameter, your tags files may be demolished.
There are additional more arcane arguments that are documented in the
source code of the kvm.sh script.
@@ -291,3 +302,73 @@
TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
CPU count limited from 16 to 12
TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011
+
+
+Repeated Runs
+=============
+
+Suppose that you are chasing down a rare boot-time failure. Although you
+could use kvm.sh, doing so will rebuild the kernel on each run. If you
+need (say) 1,000 runs to have confidence that you have fixed the bug,
+these pointless rebuilds can become extremely annoying.
+
+This is why kvm-again.sh exists.
+
+Suppose that a previous kvm.sh run left its output in this directory::
+
+ tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
+
+Then this run can be re-run without rebuilding as follow:
+
+ kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
+
+A few of the original run's kvm.sh parameters may be overridden, perhaps
+most notably --duration and --bootargs. For example::
+
+ kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 \
+ --duration 45s
+
+would re-run the previous test, but for only 45 seconds, thus facilitating
+tracking down the aforementioned rare boot-time failure.
+
+
+Distributed Runs
+================
+
+Although kvm.sh is quite useful, its testing is confined to a single
+system. It is not all that hard to use your favorite framework to cause
+(say) 5 instances of kvm.sh to run on your 5 systems, but this will very
+likely unnecessarily rebuild kernels. In addition, manually distributing
+the desired rcutorture scenarios across the available systems can be
+painstaking and error-prone.
+
+And this is why the kvm-remote.sh script exists.
+
+If you the following command works::
+
+ ssh system0 date
+
+and if it also works for system1, system2, system3, system4, and system5,
+and all of these systems have 64 CPUs, you can type::
+
+ kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
+ --cpus 64 --duration 8h --configs "5*CFLIST"
+
+This will build each default scenario's kernel on the local system, then
+spread each of five instances of each scenario over the systems listed,
+running each scenario for eight hours. At the end of the runs, the
+results will be gathered, recorded, and printed. Most of the parameters
+that kvm.sh will accept can be passed to kvm-remote.sh, but the list of
+systems must come first.
+
+The kvm.sh ``--dryrun scenarios`` argument is useful for working out
+how many scenarios may be run in one batch across a group of systems.
+
+You can also re-run a previous remote run in a manner similar to kvm.sh:
+
+ kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
+ tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \
+ --duration 24h
+
+In this case, most of the kvm-again.sh parmeters may be supplied following
+the pathname of the old run-results directory.
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index 1c747ac3..2c5563a 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -16,18 +16,23 @@
| 6. The RCU API, 2019 Edition https://lwn.net/Articles/777036/
| 2019 Big API Table https://lwn.net/Articles/777165/
+For those preferring video:
+
+| 1. Unraveling RCU Mysteries: Fundamentals https://www.linuxfoundation.org/webinars/unraveling-rcu-usage-mysteries
+| 2. Unraveling RCU Mysteries: Additional Use Cases https://www.linuxfoundation.org/webinars/unraveling-rcu-usage-mysteries-additional-use-cases
+
What is RCU?
RCU is a synchronization mechanism that was added to the Linux kernel
during the 2.5 development effort that is optimized for read-mostly
-situations. Although RCU is actually quite simple once you understand it,
-getting there can sometimes be a challenge. Part of the problem is that
-most of the past descriptions of RCU have been written with the mistaken
-assumption that there is "one true way" to describe RCU. Instead,
-the experience has been that different people must take different paths
-to arrive at an understanding of RCU. This document provides several
-different paths, as follows:
+situations. Although RCU is actually quite simple, making effective use
+of it requires you to think differently about your code. Another part
+of the problem is the mistaken assumption that there is "one true way" to
+describe and to use RCU. Instead, the experience has been that different
+people must take different paths to arrive at an understanding of RCU,
+depending on their experiences and use cases. This document provides
+several different paths, as follows:
:ref:`1. RCU OVERVIEW <1_whatisRCU>`
@@ -157,34 +162,36 @@
^^^^^^^^^^^^^^^
void rcu_read_lock(void);
- Used by a reader to inform the reclaimer that the reader is
- entering an RCU read-side critical section. It is illegal
- to block while in an RCU read-side critical section, though
- kernels built with CONFIG_PREEMPT_RCU can preempt RCU
- read-side critical sections. Any RCU-protected data structure
- accessed during an RCU read-side critical section is guaranteed to
- remain unreclaimed for the full duration of that critical section.
- Reference counts may be used in conjunction with RCU to maintain
- longer-term references to data structures.
+ This temporal primitive is used by a reader to inform the
+ reclaimer that the reader is entering an RCU read-side critical
+ section. It is illegal to block while in an RCU read-side
+ critical section, though kernels built with CONFIG_PREEMPT_RCU
+ can preempt RCU read-side critical sections. Any RCU-protected
+ data structure accessed during an RCU read-side critical section
+ is guaranteed to remain unreclaimed for the full duration of that
+ critical section. Reference counts may be used in conjunction
+ with RCU to maintain longer-term references to data structures.
rcu_read_unlock()
^^^^^^^^^^^^^^^^^
void rcu_read_unlock(void);
- Used by a reader to inform the reclaimer that the reader is
- exiting an RCU read-side critical section. Note that RCU
- read-side critical sections may be nested and/or overlapping.
+ This temporal primitives is used by a reader to inform the
+ reclaimer that the reader is exiting an RCU read-side critical
+ section. Note that RCU read-side critical sections may be nested
+ and/or overlapping.
synchronize_rcu()
^^^^^^^^^^^^^^^^^
void synchronize_rcu(void);
- Marks the end of updater code and the beginning of reclaimer
- code. It does this by blocking until all pre-existing RCU
- read-side critical sections on all CPUs have completed.
- Note that synchronize_rcu() will **not** necessarily wait for
- any subsequent RCU read-side critical sections to complete.
- For example, consider the following sequence of events::
+ This temporal primitive marks the end of updater code and the
+ beginning of reclaimer code. It does this by blocking until
+ all pre-existing RCU read-side critical sections on all CPUs
+ have completed. Note that synchronize_rcu() will **not**
+ necessarily wait for any subsequent RCU read-side critical
+ sections to complete. For example, consider the following
+ sequence of events::
CPU 0 CPU 1 CPU 2
----------------- ------------------------- ---------------
@@ -211,13 +218,13 @@
to be useful in all but the most read-intensive situations,
synchronize_rcu()'s overhead must also be quite small.
- The call_rcu() API is a callback form of synchronize_rcu(),
- and is described in more detail in a later section. Instead of
- blocking, it registers a function and argument which are invoked
- after all ongoing RCU read-side critical sections have completed.
- This callback variant is particularly useful in situations where
- it is illegal to block or where update-side performance is
- critically important.
+ The call_rcu() API is an asynchronous callback form of
+ synchronize_rcu(), and is described in more detail in a later
+ section. Instead of blocking, it registers a function and
+ argument which are invoked after all ongoing RCU read-side
+ critical sections have completed. This callback variant is
+ particularly useful in situations where it is illegal to block
+ or where update-side performance is critically important.
However, the call_rcu() API should not be used lightly, as use
of the synchronize_rcu() API generally results in simpler code.
@@ -236,11 +243,13 @@
would be cool to be able to declare a function in this manner.
(Compiler experts will no doubt disagree.)
- The updater uses this function to assign a new value to an
+ The updater uses this spatial macro to assign a new value to an
RCU-protected pointer, in order to safely communicate the change
- in value from the updater to the reader. This macro does not
- evaluate to an rvalue, but it does execute any memory-barrier
- instructions required for a given CPU architecture.
+ in value from the updater to the reader. This is a spatial (as
+ opposed to temporal) macro. It does not evaluate to an rvalue,
+ but it does execute any memory-barrier instructions required
+ for a given CPU architecture. Its ordering properties are that
+ of a store-release operation.
Perhaps just as important, it serves to document (1) which
pointers are protected by RCU and (2) the point at which a
@@ -255,14 +264,15 @@
Like rcu_assign_pointer(), rcu_dereference() must be implemented
as a macro.
- The reader uses rcu_dereference() to fetch an RCU-protected
- pointer, which returns a value that may then be safely
- dereferenced. Note that rcu_dereference() does not actually
- dereference the pointer, instead, it protects the pointer for
- later dereferencing. It also executes any needed memory-barrier
- instructions for a given CPU architecture. Currently, only Alpha
- needs memory barriers within rcu_dereference() -- on other CPUs,
- it compiles to nothing, not even a compiler directive.
+ The reader uses the spatial rcu_dereference() macro to fetch
+ an RCU-protected pointer, which returns a value that may
+ then be safely dereferenced. Note that rcu_dereference()
+ does not actually dereference the pointer, instead, it
+ protects the pointer for later dereferencing. It also
+ executes any needed memory-barrier instructions for a given
+ CPU architecture. Currently, only Alpha needs memory barriers
+ within rcu_dereference() -- on other CPUs, it compiles to a
+ volatile load.
Common coding practice uses rcu_dereference() to copy an
RCU-protected pointer to a local variable, then dereferences
@@ -355,12 +365,15 @@
synchronize_rcu() & call_rcu()
-The RCU infrastructure observes the time sequence of rcu_read_lock(),
+The RCU infrastructure observes the temporal sequence of rcu_read_lock(),
rcu_read_unlock(), synchronize_rcu(), and call_rcu() invocations in
order to determine when (1) synchronize_rcu() invocations may return
to their callers and (2) call_rcu() callbacks may be invoked. Efficient
implementations of the RCU infrastructure make heavy use of batching in
order to amortize their overhead over many uses of the corresponding APIs.
+The rcu_assign_pointer() and rcu_dereference() invocations communicate
+spatial changes via stores to and loads from the RCU-protected pointer in
+question.
There are at least three flavors of RCU usage in the Linux kernel. The diagram
above shows the most common one. On the updater side, the rcu_assign_pointer(),
@@ -392,7 +405,9 @@
c. RCU applied to scheduler and interrupt/NMI-handler tasks.
Again, most uses will be of (a). The (b) and (c) cases are important
-for specialized uses, but are relatively uncommon.
+for specialized uses, but are relatively uncommon. The SRCU, RCU-Tasks,
+RCU-Tasks-Rude, and RCU-Tasks-Trace have similar relationships among
+their assorted primitives.
.. _3_whatisRCU:
@@ -468,7 +483,7 @@
- Within an RCU read-side critical section, use rcu_dereference()
to dereference RCU-protected pointers.
-- Use some solid scheme (such as locks or semaphores) to
+- Use some solid design (such as locks or semaphores) to
keep concurrent updates from interfering with each other.
- Use rcu_assign_pointer() to update an RCU-protected pointer.
@@ -579,6 +594,14 @@
kfree_rcu(old_fp, rcu);
+If the occasional sleep is permitted, the single-argument form may
+be used, omitting the rcu_head structure from struct foo.
+
+ kfree_rcu(old_fp);
+
+This variant of kfree_rcu() almost never blocks, but might do so by
+invoking synchronize_rcu() in response to memory-allocation failure.
+
Again, see checklist.rst for additional rules governing the use of RCU.
.. _5_whatisRCU:
@@ -596,7 +619,7 @@
in getting a feel for how RCU works. See kernel/rcu/update.c for a
production-quality implementation, and see:
- http://www.rdrop.com/users/paulmck/RCU
+ https://docs.google.com/document/d/1X0lThx8OK0ZgLMqVoXiR4ZrGURHrXK6NyLRbeXe3Xac/edit
for papers describing the Linux kernel RCU implementation. The OLS'01
and OLS'02 papers are a good introduction, and the dissertation provides
@@ -929,6 +952,8 @@
initialized after each and every call to kmem_cache_alloc(), which renders
reference-free spinlock acquisition completely unsafe. Therefore, when
using ``SLAB_TYPESAFE_BY_RCU``, make proper use of a reference counter.
+(Those willing to use a kmem_cache constructor may also use locking,
+including cache-friendly sequence locking.)
With traditional reference counting -- such as that implemented by the
kref library in Linux -- there is typically code that runs when the last
@@ -1047,6 +1072,30 @@
rcu_read_lock_sched_held
+RCU-Tasks::
+
+ Critical sections Grace period Barrier
+
+ N/A call_rcu_tasks rcu_barrier_tasks
+ synchronize_rcu_tasks
+
+
+RCU-Tasks-Rude::
+
+ Critical sections Grace period Barrier
+
+ N/A call_rcu_tasks_rude rcu_barrier_tasks_rude
+ synchronize_rcu_tasks_rude
+
+
+RCU-Tasks-Trace::
+
+ Critical sections Grace period Barrier
+
+ rcu_read_lock_trace call_rcu_tasks_trace rcu_barrier_tasks_trace
+ rcu_read_unlock_trace synchronize_rcu_tasks_trace
+
+
SRCU::
Critical sections Grace period Barrier
@@ -1087,35 +1136,43 @@
a. Will readers need to block? If so, you need SRCU.
-b. What about the -rt patchset? If readers would need to block
- in an non-rt kernel, you need SRCU. If readers would block
- in a -rt kernel, but not in a non-rt kernel, SRCU is not
- necessary. (The -rt patchset turns spinlocks into sleeplocks,
- hence this distinction.)
+b. Will readers need to block and are you doing tracing, for
+ example, ftrace or BPF? If so, you need RCU-tasks,
+ RCU-tasks-rude, and/or RCU-tasks-trace.
-c. Do you need to treat NMI handlers, hardirq handlers,
+c. What about the -rt patchset? If readers would need to block in
+ an non-rt kernel, you need SRCU. If readers would block when
+ acquiring spinlocks in a -rt kernel, but not in a non-rt kernel,
+ SRCU is not necessary. (The -rt patchset turns spinlocks into
+ sleeplocks, hence this distinction.)
+
+d. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
- If so, RCU-sched is the only choice that will work for you.
+ If so, RCU-sched readers are the only choice that will work
+ for you, but since about v4.20 you use can use the vanilla RCU
+ update primitives.
-d. Do you need RCU grace periods to complete even in the face
- of softirq monopolization of one or more of the CPUs? For
- example, is your code subject to network-based denial-of-service
- attacks? If so, you should disable softirq across your readers,
- for example, by using rcu_read_lock_bh().
+e. Do you need RCU grace periods to complete even in the face of
+ softirq monopolization of one or more of the CPUs? For example,
+ is your code subject to network-based denial-of-service attacks?
+ If so, you should disable softirq across your readers, for
+ example, by using rcu_read_lock_bh(). Since about v4.20 you
+ use can use the vanilla RCU update primitives.
-e. Is your workload too update-intensive for normal use of
+f. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_TYPESAFE_BY_RCU (which was originally
named SLAB_DESTROY_BY_RCU). But please be careful!
-f. Do you need read-side critical sections that are respected
- even though they are in the middle of the idle loop, during
- user-mode execution, or on an offlined CPU? If so, SRCU is the
- only choice that will work for you.
+g. Do you need read-side critical sections that are respected even
+ on CPUs that are deep in the idle loop, during entry to or exit
+ from user-mode execution, or on an offlined CPU? If so, SRCU
+ and RCU Tasks Trace are the only choices that will work for you,
+ with SRCU being strongly preferred in almost all cases.
-g. Otherwise, use RCU.
+h. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.
diff --git a/Documentation/accel/introduction.rst b/Documentation/accel/introduction.rst
index 6f31af1..89984df 100644
--- a/Documentation/accel/introduction.rst
+++ b/Documentation/accel/introduction.rst
@@ -67,9 +67,9 @@
The accelerator devices will be exposed to the user space with the dedicated
261 major number and will have the following convention:
-- device char files - /dev/accel/accel*
-- sysfs - /sys/class/accel/accel*/
-- debugfs - /sys/kernel/debug/accel/accel*/
+- device char files - /dev/accel/accel\*
+- sysfs - /sys/class/accel/accel\*/
+- debugfs - /sys/kernel/debug/accel/\*/
Getting Started
===============
diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
index 8d3a2d0..bb5032a 100644
--- a/Documentation/admin-guide/bcache.rst
+++ b/Documentation/admin-guide/bcache.rst
@@ -204,7 +204,7 @@
This should present your unmodified backing device data in /dev/loop0
If your cache is in writethrough mode, then you can safely discard the
-cache device without loosing data.
+cache device without losing data.
E) Wiping a cache device
diff --git a/Documentation/admin-guide/blockdev/paride.rst b/Documentation/admin-guide/blockdev/paride.rst
index e1ce90a..e85ad37 100644
--- a/Documentation/admin-guide/blockdev/paride.rst
+++ b/Documentation/admin-guide/blockdev/paride.rst
@@ -3,6 +3,7 @@
===================================
PARIDE v1.03 (c) 1997-8 Grant Guenther <grant@torque.net>
+PATA_PARPORT (c) 2023 Ondrej Zary
1. Introduction
===============
@@ -51,27 +52,15 @@
as well as most of the clone and no-name products on the market.
-To support such a wide range of devices, PARIDE, the parallel port IDE
-subsystem, is actually structured in three parts. There is a base
-paride module which provides a registry and some common methods for
-accessing the parallel ports. The second component is a set of
-high-level drivers for each of the different types of supported devices:
+To support such a wide range of devices, pata_parport is actually structured
+in two parts. There is a base pata_parport module which provides an interface
+to kernel libata subsystem, registry and some common methods for accessing
+the parallel ports.
- === =============
- pd IDE disk
- pcd ATAPI CD-ROM
- pf ATAPI disk
- pt ATAPI tape
- pg ATAPI generic
- === =============
-
-(Currently, the pg driver is only used with CD-R drives).
-
-The high-level drivers function according to the relevant standards.
-The third component of PARIDE is a set of low-level protocol drivers
-for each of the parallel port IDE adapter chips. Thanks to the interest
-and encouragement of Linux users from many parts of the world,
-support is available for almost all known adapter protocols:
+The second component is a set of low-level protocol drivers for each of the
+parallel port IDE adapter chips. Thanks to the interest and encouragement of
+Linux users from many parts of the world, support is available for almost all
+known adapter protocols:
==== ====================================== ====
aten ATEN EH-100 (HK)
@@ -91,251 +80,87 @@
==== ====================================== ====
-2. Using the PARIDE subsystem
-=============================
+2. Using pata_parport subsystem
+===============================
While configuring the Linux kernel, you may choose either to build
-the PARIDE drivers into your kernel, or to build them as modules.
+the pata_parport drivers into your kernel, or to build them as modules.
In either case, you will need to select "Parallel port IDE device support"
-as well as at least one of the high-level drivers and at least one
-of the parallel port communication protocols. If you do not know
-what kind of parallel port adapter is used in your drive, you could
-begin by checking the file names and any text files on your DOS
+and at least one of the parallel port communication protocols.
+If you do not know what kind of parallel port adapter is used in your drive,
+you could begin by checking the file names and any text files on your DOS
installation floppy. Alternatively, you can look at the markings on
the adapter chip itself. That's usually sufficient to identify the
correct device.
-You can actually select all the protocol modules, and allow the PARIDE
+You can actually select all the protocol modules, and allow the pata_parport
subsystem to try them all for you.
For the "brand-name" products listed above, here are the protocol
and high-level drivers that you would use:
- ================ ============ ====== ========
- Manufacturer Model Driver Protocol
- ================ ============ ====== ========
- MicroSolutions CD-ROM pcd bpck
- MicroSolutions PD drive pf bpck
- MicroSolutions hard-drive pd bpck
- MicroSolutions 8000t tape pt bpck
- SyQuest EZ, SparQ pd epat
- Imation Superdisk pf epat
- Maxell Superdisk pf friq
- Avatar Shark pd epat
- FreeCom CD-ROM pcd frpw
- Hewlett-Packard 5GB Tape pt epat
- Hewlett-Packard 7200e (CD) pcd epat
- Hewlett-Packard 7200e (CD-R) pg epat
- ================ ============ ====== ========
+ ================ ============ ========
+ Manufacturer Model Protocol
+ ================ ============ ========
+ MicroSolutions CD-ROM bpck
+ MicroSolutions PD drive bpck
+ MicroSolutions hard-drive bpck
+ MicroSolutions 8000t tape bpck
+ SyQuest EZ, SparQ epat
+ Imation Superdisk epat
+ Maxell Superdisk friq
+ Avatar Shark epat
+ FreeCom CD-ROM frpw
+ Hewlett-Packard 5GB Tape epat
+ Hewlett-Packard 7200e (CD) epat
+ Hewlett-Packard 7200e (CD-R) epat
+ ================ ============ ========
-2.1 Configuring built-in drivers
----------------------------------
+All parports and all protocol drivers are probed automatically unless probe=0
+parameter is used. So just "modprobe epat" is enough for a Imation SuperDisk
+drive to work.
-We recommend that you get to know how the drivers work and how to
-configure them as loadable modules, before attempting to compile a
-kernel with the drivers built-in.
+Manual device creation::
-If you built all of your PARIDE support directly into your kernel,
-and you have just a single parallel port IDE device, your kernel should
-locate it automatically for you. If you have more than one device,
-you may need to give some command line options to your bootloader
-(eg: LILO), how to do that is beyond the scope of this document.
+ # echo "port protocol mode unit delay" >/sys/bus/pata_parport/new_device
-The high-level drivers accept a number of command line parameters, all
-of which are documented in the source files in linux/drivers/block/paride.
-By default, each driver will automatically try all parallel ports it
-can find, and all protocol types that have been installed, until it finds
-a parallel port IDE adapter. Once it finds one, the probe stops. So,
-if you have more than one device, you will need to tell the drivers
-how to identify them. This requires specifying the port address, the
-protocol identification number and, for some devices, the drive's
-chain ID. While your system is booting, a number of messages are
-displayed on the console. Like all such messages, they can be
-reviewed with the 'dmesg' command. Among those messages will be
-some lines like::
+where:
- paride: bpck registered as protocol 0
- paride: epat registered as protocol 1
-
-The numbers will always be the same until you build a new kernel with
-different protocol selections. You should note these numbers as you
-will need them to identify the devices.
+ ======== ================================================
+ port parport name (or "auto" for all parports)
+ protocol protocol name (or "auto" for all protocols)
+ mode mode number (protocol-specific) or -1 for probe
+ unit unit number (for backpack only, see below)
+ delay I/O delay (see troubleshooting section below)
+ ======== ================================================
If you happen to be using a MicroSolutions backpack device, you will
also need to know the unit ID number for each drive. This is usually
the last two digits of the drive's serial number (but read MicroSolutions'
documentation about this).
-As an example, let's assume that you have a MicroSolutions PD/CD drive
-with unit ID number 36 connected to the parallel port at 0x378, a SyQuest
-EZ-135 connected to the chained port on the PD/CD drive and also an
-Imation Superdisk connected to port 0x278. You could give the following
-options on your boot command::
+If you omit the parameters from the end, defaults will be used, e.g.:
- pd.drive0=0x378,1 pf.drive0=0x278,1 pf.drive1=0x378,0,36
+Probe all parports with all protocols::
-In the last option, pf.drive1 configures device /dev/pf1, the 0x378
-is the parallel port base address, the 0 is the protocol registration
-number and 36 is the chain ID.
+ # echo auto >/sys/bus/pata_parport/new_device
-Please note: while PARIDE will work both with and without the
-PARPORT parallel port sharing system that is included by the
-"Parallel port support" option, PARPORT must be included and enabled
-if you want to use chains of devices on the same parallel port.
+Probe parport0 using protocol epat and mode 4 (EPP-16)::
-2.2 Loading and configuring PARIDE as modules
-----------------------------------------------
+ # echo "parport0 epat 4" >/sys/bus/pata_parport/new_device
-It is much faster and simpler to get to understand the PARIDE drivers
-if you use them as loadable kernel modules.
+Probe parport0 using all protocols::
-Note 1:
- using these drivers with the "kerneld" automatic module loading
- system is not recommended for beginners, and is not documented here.
+ # echo "parport0 auto" >/sys/bus/pata_parport/new_device
-Note 2:
- if you build PARPORT support as a loadable module, PARIDE must
- also be built as loadable modules, and PARPORT must be loaded before
- the PARIDE modules.
+Probe all parports using protoocol epat::
-To use PARIDE, you must begin by::
+ # echo "auto epat" >/sys/bus/pata_parport/new_device
- insmod paride
+Deleting devices::
-this loads a base module which provides a registry for the protocols,
-among other tasks.
-
-Then, load as many of the protocol modules as you think you might need.
-As you load each module, it will register the protocols that it supports,
-and print a log message to your kernel log file and your console. For
-example::
-
- # insmod epat
- paride: epat registered as protocol 0
- # insmod kbic
- paride: k951 registered as protocol 1
- paride: k971 registered as protocol 2
-
-Finally, you can load high-level drivers for each kind of device that
-you have connected. By default, each driver will autoprobe for a single
-device, but you can support up to four similar devices by giving their
-individual coordinates when you load the driver.
-
-For example, if you had two no-name CD-ROM drives both using the
-KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc
-you could give the following command::
-
- # insmod pcd drive0=0x378,1 drive1=0x3bc,1
-
-For most adapters, giving a port address and protocol number is sufficient,
-but check the source files in linux/drivers/block/paride for more
-information. (Hopefully someone will write some man pages one day !).
-
-As another example, here's what happens when PARPORT is installed, and
-a SyQuest EZ-135 is attached to port 0x378::
-
- # insmod paride
- paride: version 1.0 installed
- # insmod epat
- paride: epat registered as protocol 0
- # insmod pd
- pd: pd version 1.0, major 45, cluster 64, nice 0
- pda: Sharing parport1 at 0x378
- pda: epat 1.0, Shuttle EPAT chip c3 at 0x378, mode 5 (EPP-32), delay 1
- pda: SyQuest EZ135A, 262144 blocks [128M], (512/16/32), removable media
- pda: pda1
-
-Note that the last line is the output from the generic partition table
-scanner - in this case it reports that it has found a disk with one partition.
-
-2.3 Using a PARIDE device
---------------------------
-
-Once the drivers have been loaded, you can access PARIDE devices in the
-same way as their traditional counterparts. You will probably need to
-create the device "special files". Here is a simple script that you can
-cut to a file and execute::
-
- #!/bin/bash
- #
- # mkd -- a script to create the device special files for the PARIDE subsystem
- #
- function mkdev {
- mknod $1 $2 $3 $4 ; chmod 0660 $1 ; chown root:disk $1
- }
- #
- function pd {
- D=$( printf \\$( printf "x%03x" $[ $1 + 97 ] ) )
- mkdev pd$D b 45 $[ $1 * 16 ]
- for P in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
- do mkdev pd$D$P b 45 $[ $1 * 16 + $P ]
- done
- }
- #
- cd /dev
- #
- for u in 0 1 2 3 ; do pd $u ; done
- for u in 0 1 2 3 ; do mkdev pcd$u b 46 $u ; done
- for u in 0 1 2 3 ; do mkdev pf$u b 47 $u ; done
- for u in 0 1 2 3 ; do mkdev pt$u c 96 $u ; done
- for u in 0 1 2 3 ; do mkdev npt$u c 96 $[ $u + 128 ] ; done
- for u in 0 1 2 3 ; do mkdev pg$u c 97 $u ; done
- #
- # end of mkd
-
-With the device files and drivers in place, you can access PARIDE devices
-like any other Linux device. For example, to mount a CD-ROM in pcd0, use::
-
- mount /dev/pcd0 /cdrom
-
-If you have a fresh Avatar Shark cartridge, and the drive is pda, you
-might do something like::
-
- fdisk /dev/pda -- make a new partition table with
- partition 1 of type 83
-
- mke2fs /dev/pda1 -- to build the file system
-
- mkdir /shark -- make a place to mount the disk
-
- mount /dev/pda1 /shark
-
-Devices like the Imation superdisk work in the same way, except that
-they do not have a partition table. For example to make a 120MB
-floppy that you could share with a DOS system::
-
- mkdosfs /dev/pf0
- mount /dev/pf0 /mnt
-
-
-2.4 The pf driver
-------------------
-
-The pf driver is intended for use with parallel port ATAPI disk
-devices. The most common devices in this category are PD drives
-and LS-120 drives. Traditionally, media for these devices are not
-partitioned. Consequently, the pf driver does not support partitioned
-media. This may be changed in a future version of the driver.
-
-2.5 Using the pt driver
-------------------------
-
-The pt driver for parallel port ATAPI tape drives is a minimal driver.
-It does not yet support many of the standard tape ioctl operations.
-For best performance, a block size of 32KB should be used. You will
-probably want to set the parallel port delay to 0, if you can.
-
-2.6 Using the pg driver
-------------------------
-
-The pg driver can be used in conjunction with the cdrecord program
-to create CD-ROMs. Please get cdrecord version 1.6.1 or later
-from ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ . To record CD-R media
-your parallel port should ideally be set to EPP mode, and the "port delay"
-should be set to 0. With those settings it is possible to record at 2x
-speed without any buffer underruns. If you cannot get the driver to work
-in EPP mode, try to use "bidirectional" or "PS/2" mode and 1x speeds only.
+ # echo pata_parport.0 >/sys/bus/pata_parport/delete_device
3. Troubleshooting
@@ -344,9 +169,9 @@
3.1 Use EPP mode if you can
----------------------------
-The most common problems that people report with the PARIDE drivers
+The most common problems that people report with the pata_parport drivers
concern the parallel port CMOS settings. At this time, none of the
-PARIDE protocol modules support ECP mode, or any ECP combination modes.
+protocol modules support ECP mode, or any ECP combination modes.
If you are able to do so, please set your parallel port into EPP mode
using your CMOS setup procedure.
@@ -354,17 +179,14 @@
-------------------------
Some parallel ports cannot reliably transfer data at full speed. To
-offset the errors, the PARIDE protocol modules introduce a "port
+offset the errors, the protocol modules introduce a "port
delay" between each access to the i/o ports. Each protocol sets
a default value for this delay. In most cases, the user can override
the default and set it to 0 - resulting in somewhat higher transfer
rates. In some rare cases (especially with older 486 systems) the
default delays are not long enough. if you experience corrupt data
transfers, or unexpected failures, you may wish to increase the
-port delay. The delay can be programmed using the "driveN" parameters
-to each of the high-level drivers. Please see the notes above, or
-read the comments at the beginning of the driver source files in
-linux/drivers/block/paride.
+port delay.
3.3 Some drives need a printer reset
-------------------------------------
@@ -374,66 +196,12 @@
drives based on OnSpec and older Freecom adapters. In these rare cases,
the adapter can often be reinitialised by issuing a "printer reset" on
the parallel port. As the reset operation is potentially disruptive in
-multiple device environments, the PARIDE drivers will not do it
+multiple device environments, the pata_parport drivers will not do it
automatically. You can however, force a printer reset by doing::
insmod lp reset=1
rmmod lp
If you have one of these marginal cases, you should probably build
-your paride drivers as modules, and arrange to do the printer reset
-before loading the PARIDE drivers.
-
-3.4 Use the verbose option and dmesg if you need help
-------------------------------------------------------
-
-While a lot of testing has gone into these drivers to make them work
-as smoothly as possible, problems will arise. If you do have problems,
-please check all the obvious things first: does the drive work in
-DOS with the manufacturer's drivers ? If that doesn't yield any useful
-clues, then please make sure that only one drive is hooked to your system,
-and that either (a) PARPORT is enabled or (b) no other device driver
-is using your parallel port (check in /proc/ioports). Then, load the
-appropriate drivers (you can load several protocol modules if you want)
-as in::
-
- # insmod paride
- # insmod epat
- # insmod bpck
- # insmod kbic
- ...
- # insmod pd verbose=1
-
-(using the correct driver for the type of device you have, of course).
-The verbose=1 parameter will cause the drivers to log a trace of their
-activity as they attempt to locate your drive.
-
-Use 'dmesg' to capture a log of all the PARIDE messages (any messages
-beginning with paride:, a protocol module's name or a driver's name) and
-include that with your bug report. You can submit a bug report in one
-of two ways. Either send it directly to the author of the PARIDE suite,
-by e-mail to grant@torque.net, or join the linux-parport mailing list
-and post your report there.
-
-3.5 For more information or help
----------------------------------
-
-You can join the linux-parport mailing list by sending a mail message
-to:
-
- linux-parport-request@torque.net
-
-with the single word::
-
- subscribe
-
-in the body of the mail message (not in the subject line). Please be
-sure that your mail program is correctly set up when you do this, as
-the list manager is a robot that will subscribe you using the reply
-address in your mail headers. REMOVE any anti-spam gimmicks you may
-have in your mail headers, when sending mail to the list server.
-
-You might also find some useful information on the linux-parport
-web pages (although they are not always up to date) at
-
- http://web.archive.org/web/%2E/http://www.torque.net/parport/
+your pata_parport drivers as modules, and arrange to do the printer reset
+before loading the pata_parport drivers.
diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst
index 9355c52..91339ef 100644
--- a/Documentation/admin-guide/bootconfig.rst
+++ b/Documentation/admin-guide/bootconfig.rst
@@ -201,6 +201,8 @@
Then add "bootconfig" on the normal kernel command line to tell the
kernel to look for the bootconfig at the end of the initrd file.
+Alternatively, build your kernel with the ``CONFIG_BOOT_CONFIG_FORCE``
+Kconfig option selected.
Embedding a Boot Config into Kernel
-----------------------------------
@@ -217,7 +219,9 @@
The kernel will embed it as the default bootconfig.
Just as when attaching the bootconfig to the initrd, you need ``bootconfig``
-option on the kernel command line to enable the embedded bootconfig.
+option on the kernel command line to enable the embedded bootconfig, or,
+alternatively, build your kernel with the ``CONFIG_BOOT_CONFIG_FORCE``
+Kconfig option selected.
Note that even if you set this option, you can override the embedded
bootconfig by another bootconfig which attached to the initrd.
diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
index 16253ed..dabb80c 100644
--- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
+++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
@@ -106,7 +106,7 @@
see Documentation/block/bfq-iosched.rst.
blkio.bfq.weight_device
- Specifes per cgroup per device weights, overriding the default group
+ Specifies per cgroup per device weights, overriding the default group
weight. For more details, see Documentation/block/bfq-iosched.rst.
Following is the format::
diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
index b068801..9343148 100644
--- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
+++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
@@ -80,6 +80,8 @@
you to associate a set of CPUs and a set of memory nodes with the
tasks in each cgroup.
+.. _cgroups-why-needed:
+
1.2 Why are cgroups needed ?
----------------------------
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
index 60370f2..47d1d7d 100644
--- a/Documentation/admin-guide/cgroup-v1/memory.rst
+++ b/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -2,18 +2,18 @@
Memory Resource Controller
==========================
-NOTE:
+.. caution::
This document is hopelessly outdated and it asks for a complete
rewrite. It still contains a useful information so we are keeping it
here but make sure to check the current code if you need a deeper
understanding.
-NOTE:
+.. note::
The Memory Resource Controller has generically been referred to as the
memory controller in this document. Do not confuse memory controller
used here with the memory controller that is used in hardware.
-(For editors) In this document:
+.. hint::
When we mention a cgroup (cgroupfs's directory) with memory controller,
we call it "memory cgroup". When you see git-log and source code, you'll
see patch's title and function names tend to use "memcg".
@@ -23,7 +23,7 @@
=============================================
The memory controller isolates the memory behaviour of a group of tasks
-from the rest of the system. The article on LWN [12] mentions some probable
+from the rest of the system. The article on LWN [12]_ mentions some probable
uses of the memory controller. The memory controller can be used to
a. Isolate an application or a group of applications
@@ -55,7 +55,8 @@
- Root cgroup has no limit controls.
Kernel memory support is a work in progress, and the current version provides
- basically functionality. (See Section 2.7)
+ basically functionality. (See :ref:`section 2.7
+ <cgroup-v1-memory-kernel-extension>`)
Brief summary of control files.
@@ -86,6 +87,8 @@
memory.swappiness set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate set/show controls of moving charges
+ This knob is deprecated and shouldn't be
+ used.
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
@@ -107,16 +110,16 @@
==========
The memory controller has a long history. A request for comments for the memory
-controller was posted by Balbir Singh [1]. At the time the RFC was posted
+controller was posted by Balbir Singh [1]_. At the time the RFC was posted
there were several implementations for memory control. The goal of the
RFC was to build consensus and agreement for the minimal features required
-for memory control. The first RSS controller was posted by Balbir Singh[2]
-in Feb 2007. Pavel Emelianov [3][4][5] has since posted three versions of the
-RSS controller. At OLS, at the resource management BoF, everyone suggested
-that we handle both page cache and RSS together. Another request was raised
-to allow user space handling of OOM. The current memory controller is
+for memory control. The first RSS controller was posted by Balbir Singh [2]_
+in Feb 2007. Pavel Emelianov [3]_ [4]_ [5]_ has since posted three versions
+of the RSS controller. At OLS, at the resource management BoF, everyone
+suggested that we handle both page cache and RSS together. Another request was
+raised to allow user space handling of OOM. The current memory controller is
at version 6; it combines both mapped (RSS) and unmapped Page
-Cache Control [11].
+Cache Control [11]_.
2. Memory Control
=================
@@ -147,7 +150,8 @@
2.2. Accounting
---------------
-::
+.. code-block::
+ :caption: Figure 1: Hierarchy of Accounting
+--------------------+
| mem_cgroup |
@@ -167,7 +171,6 @@
| | | |
+---------------+ +---------------+
- (Figure 1: Hierarchy of Accounting)
Figure 1 shows the important aspects of the controller
@@ -221,8 +224,9 @@
page will eventually get charged for it (once it is uncharged from
the cgroup that brought it in -- this will happen on memory pressure).
-But see section 8.2: when moving a task to another cgroup, its pages may
-be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
+But see :ref:`section 8.2 <cgroup-v1-memory-movable-charges>` when moving a
+task to another cgroup, its pages may be recharged to the new cgroup, if
+move_charge_at_immigrate has been chosen.
2.4 Swap Extension
--------------------------------------
@@ -244,7 +248,8 @@
By using the memsw limit, you can avoid system OOM which can be caused by swap
shortage.
-**why 'memory+swap' rather than swap**
+2.4.1 why 'memory+swap' rather than swap
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
to move account from memory to swap...there is no change in usage of
@@ -252,7 +257,8 @@
affecting global LRU, memory+swap limit is better than just limiting swap from
an OS point of view.
-**What happens when a cgroup hits memory.memsw.limit_in_bytes**
+2.4.2. What happens when a cgroup hits memory.memsw.limit_in_bytes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
in this cgroup. Then, swap-out will not be done by cgroup routine and file
@@ -268,26 +274,26 @@
to reclaim memory from the cgroup so as to make space for the new
pages that the cgroup has touched. If the reclaim is unsuccessful,
an OOM routine is invoked to select and kill the bulkiest task in the
-cgroup. (See 10. OOM Control below.)
+cgroup. (See :ref:`10. OOM Control <cgroup-v1-memory-oom-control>` below.)
The reclaim algorithm has not been modified for cgroups, except that
pages that are selected for reclaiming come from the per-cgroup LRU
list.
-NOTE:
- Reclaim does not work for the root cgroup, since we cannot set any
- limits on the root cgroup.
+.. note::
+ Reclaim does not work for the root cgroup, since we cannot set any
+ limits on the root cgroup.
-Note2:
- When panic_on_oom is set to "2", the whole system will panic.
+.. note::
+ When panic_on_oom is set to "2", the whole system will panic.
When oom event notifier is registered, event will be delivered.
-(See oom_control section)
+(See :ref:`oom_control <cgroup-v1-memory-oom-control>` section)
2.6 Locking
-----------
-Lock order is as follows:
+Lock order is as follows::
Page lock (PG_locked bit of page->flags)
mm->page_table_lock or split pte_lock
@@ -299,6 +305,8 @@
lruvec->lru_lock; PG_lru bit of page->flags is cleared before
isolating a page from its LRU under lruvec->lru_lock.
+.. _cgroup-v1-memory-kernel-extension:
+
2.7 Kernel Memory Extension
-----------------------------------------------
@@ -367,10 +375,10 @@
never greater than the total memory, and freely set U at the cost of his
QoS.
-WARNING:
- In the current implementation, memory reclaim will NOT be
- triggered for a cgroup when it hits K while staying below U, which makes
- this setup impractical.
+ .. warning::
+ In the current implementation, memory reclaim will NOT be triggered for
+ a cgroup when it hits K while staying below U, which makes this setup
+ impractical.
U != 0, K >= U:
Since kmem charges will also be fed to the user counter and reclaim will be
@@ -381,45 +389,41 @@
3. User Interface
=================
-3.0. Configuration
-------------------
+To use the user interface:
-a. Enable CONFIG_CGROUPS
-b. Enable CONFIG_MEMCG
-
-3.1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
--------------------------------------------------------------------
-
-::
+1. Enable CONFIG_CGROUPS and CONFIG_MEMCG options
+2. Prepare the cgroups (see :ref:`Why are cgroups needed?
+ <cgroups-why-needed>` for the background information)::
# mount -t tmpfs none /sys/fs/cgroup
# mkdir /sys/fs/cgroup/memory
# mount -t cgroup none /sys/fs/cgroup/memory -o memory
-3.2. Make the new group and move bash into it::
+3. Make the new group and move bash into it::
# mkdir /sys/fs/cgroup/memory/0
# echo $$ > /sys/fs/cgroup/memory/0/tasks
-Since now we're in the 0 cgroup, we can alter the memory limit::
+4. Since now we're in the 0 cgroup, we can alter the memory limit::
# echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes
-NOTE:
- We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
- mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes,
- Gibibytes.)
+ The limit can now be queried::
-NOTE:
- We can write "-1" to reset the ``*.limit_in_bytes(unlimited)``.
+ # cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
+ 4194304
-NOTE:
- We cannot set limits on the root cgroup any more.
+.. note::
+ We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
+ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes,
+ Gibibytes.)
-::
+.. note::
+ We can write "-1" to reset the ``*.limit_in_bytes(unlimited)``.
- # cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
- 4194304
+.. note::
+ We cannot set limits on the root cgroup any more.
+
We can check the usage::
@@ -458,6 +462,8 @@
But the above two are testing extreme situations.
Trying usual test under memory controller is always helpful.
+.. _cgroup-v1-memory-test-troubleshoot:
+
4.1 Troubleshooting
-------------------
@@ -470,8 +476,11 @@
A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
some of the pages cached in the cgroup (page cache pages).
-To know what happens, disabling OOM_Kill as per "10. OOM Control" (below) and
-seeing what happens will be helpful.
+To know what happens, disabling OOM_Kill as per :ref:`"10. OOM Control"
+<cgroup-v1-memory-oom-control>` (below) and seeing what happens will be
+helpful.
+
+.. _cgroup-v1-memory-test-task-migration:
4.2 Task migration
------------------
@@ -482,15 +491,16 @@
reclaimed.
You can move charges of a task along with task migration.
-See 8. "Move charges at task migration"
+See :ref:`8. "Move charges at task migration" <cgroup-v1-memory-move-charges>`
4.3 Removing a cgroup
---------------------
-A cgroup can be removed by rmdir, but as discussed in sections 4.1 and 4.2, a
-cgroup might have some charge associated with it, even though all
-tasks have migrated away from it. (because we charge against pages, not
-against tasks.)
+A cgroup can be removed by rmdir, but as discussed in :ref:`sections 4.1
+<cgroup-v1-memory-test-troubleshoot>` and :ref:`4.2
+<cgroup-v1-memory-test-task-migration>`, a cgroup might have some charge
+associated with it, even though all tasks have migrated away from it. (because
+we charge against pages, not against tasks.)
We move the stats to parent, and no change on the charge except uncharging
from the child.
@@ -519,67 +529,66 @@
5.2 stat file
-------------
-memory.stat file includes following statistics
+memory.stat file includes following statistics:
-per-memory cgroup local status
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ * per-memory cgroup local status
-=============== ===============================================================
-cache # of bytes of page cache memory.
-rss # of bytes of anonymous and swap cache memory (includes
- transparent hugepages).
-rss_huge # of bytes of anonymous transparent hugepages.
-mapped_file # of bytes of mapped file (includes tmpfs/shmem)
-pgpgin # of charging events to the memory cgroup. The charging
- event happens each time a page is accounted as either mapped
- anon page(RSS) or cache page(Page Cache) to the cgroup.
-pgpgout # of uncharging events to the memory cgroup. The uncharging
- event happens each time a page is unaccounted from the cgroup.
-swap # of bytes of swap usage
-dirty # of bytes that are waiting to get written back to the disk.
-writeback # of bytes of file/anon cache that are queued for syncing to
- disk.
-inactive_anon # of bytes of anonymous and swap cache memory on inactive
- LRU list.
-active_anon # of bytes of anonymous and swap cache memory on active
- LRU list.
-inactive_file # of bytes of file-backed memory and MADV_FREE anonymous memory(
- LazyFree pages) on inactive LRU list.
-active_file # of bytes of file-backed memory on active LRU list.
-unevictable # of bytes of memory that cannot be reclaimed (mlocked etc).
-=============== ===============================================================
+ =============== ===============================================================
+ cache # of bytes of page cache memory.
+ rss # of bytes of anonymous and swap cache memory (includes
+ transparent hugepages).
+ rss_huge # of bytes of anonymous transparent hugepages.
+ mapped_file # of bytes of mapped file (includes tmpfs/shmem)
+ pgpgin # of charging events to the memory cgroup. The charging
+ event happens each time a page is accounted as either mapped
+ anon page(RSS) or cache page(Page Cache) to the cgroup.
+ pgpgout # of uncharging events to the memory cgroup. The uncharging
+ event happens each time a page is unaccounted from the
+ cgroup.
+ swap # of bytes of swap usage
+ dirty # of bytes that are waiting to get written back to the disk.
+ writeback # of bytes of file/anon cache that are queued for syncing to
+ disk.
+ inactive_anon # of bytes of anonymous and swap cache memory on inactive
+ LRU list.
+ active_anon # of bytes of anonymous and swap cache memory on active
+ LRU list.
+ inactive_file # of bytes of file-backed memory and MADV_FREE anonymous
+ memory (LazyFree pages) on inactive LRU list.
+ active_file # of bytes of file-backed memory on active LRU list.
+ unevictable # of bytes of memory that cannot be reclaimed (mlocked etc).
+ =============== ===============================================================
-status considering hierarchy (see memory.use_hierarchy settings)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ * status considering hierarchy (see memory.use_hierarchy settings):
-========================= ===================================================
-hierarchical_memory_limit # of bytes of memory limit with regard to hierarchy
- under which the memory cgroup is
-hierarchical_memsw_limit # of bytes of memory+swap limit with regard to
- hierarchy under which memory cgroup is.
+ ========================= ===================================================
+ hierarchical_memory_limit # of bytes of memory limit with regard to
+ hierarchy
+ under which the memory cgroup is
+ hierarchical_memsw_limit # of bytes of memory+swap limit with regard to
+ hierarchy under which memory cgroup is.
-total_<counter> # hierarchical version of <counter>, which in
- addition to the cgroup's own value includes the
- sum of all hierarchical children's values of
- <counter>, i.e. total_cache
-========================= ===================================================
+ total_<counter> # hierarchical version of <counter>, which in
+ addition to the cgroup's own value includes the
+ sum of all hierarchical children's values of
+ <counter>, i.e. total_cache
+ ========================= ===================================================
-The following additional stats are dependent on CONFIG_DEBUG_VM
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ * additional vm parameters (depends on CONFIG_DEBUG_VM):
-========================= ========================================
-recent_rotated_anon VM internal parameter. (see mm/vmscan.c)
-recent_rotated_file VM internal parameter. (see mm/vmscan.c)
-recent_scanned_anon VM internal parameter. (see mm/vmscan.c)
-recent_scanned_file VM internal parameter. (see mm/vmscan.c)
-========================= ========================================
+ ========================= ========================================
+ recent_rotated_anon VM internal parameter. (see mm/vmscan.c)
+ recent_rotated_file VM internal parameter. (see mm/vmscan.c)
+ recent_scanned_anon VM internal parameter. (see mm/vmscan.c)
+ recent_scanned_file VM internal parameter. (see mm/vmscan.c)
+ ========================= ========================================
-Memo:
+.. hint::
recent_rotated means recent frequency of LRU rotation.
recent_scanned means recent # of scans to LRU.
showing for better debug please see the code for meanings.
-Note:
+.. note::
Only anonymous and swap cache memory is listed as part of 'rss' stat.
This should not be confused with the true 'resident set size' or the
amount of physical memory used by the cgroup.
@@ -710,15 +719,25 @@
# echo 1G > memory.soft_limit_in_bytes
-NOTE1:
+.. note::
Soft limits take effect over a long period of time, since they involve
reclaiming memory for balancing between memory cgroups
-NOTE2:
+
+.. note::
It is recommended to set the soft limit always below the hard limit,
otherwise the hard limit will take precedence.
-8. Move charges at task migration
-=================================
+.. _cgroup-v1-memory-move-charges:
+
+8. Move charges at task migration (DEPRECATED!)
+===============================================
+
+THIS IS DEPRECATED!
+
+It's expensive and unreliable! It's better practice to launch workload
+tasks directly from inside their target cgroup. Use dedicated workload
+cgroups to allow fine-grained policy adjustments without having to
+move physical pages between control domains.
Users can move charges associated with a task along with task migration, that
is, uncharge task's pages from the old cgroup and charge them to the new cgroup.
@@ -735,23 +754,29 @@
# echo (some positive value) > memory.move_charge_at_immigrate
-Note:
+.. note::
Each bits of move_charge_at_immigrate has its own meaning about what type
- of charges should be moved. See 8.2 for details.
-Note:
+ of charges should be moved. See :ref:`section 8.2
+ <cgroup-v1-memory-movable-charges>` for details.
+
+.. note::
Charges are moved only when you move mm->owner, in other words,
a leader of a thread group.
-Note:
+
+.. note::
If we cannot find enough space for the task in the destination cgroup, we
try to make space by reclaiming memory. Task migration may fail if we
cannot make enough space.
-Note:
+
+.. note::
It can take several seconds if you move charges much.
And if you want disable it again::
# echo 0 > memory.move_charge_at_immigrate
+.. _cgroup-v1-memory-movable-charges:
+
8.2 Type of charges which can be moved
--------------------------------------
@@ -801,6 +826,8 @@
It's applicable for root and non-root cgroup.
+.. _cgroup-v1-memory-oom-control:
+
10. OOM Control
===============
@@ -956,15 +983,16 @@
References
==========
-1. Singh, Balbir. RFC: Memory Controller, http://lwn.net/Articles/206697/
-2. Singh, Balbir. Memory Controller (RSS Control),
+.. [1] Singh, Balbir. RFC: Memory Controller, http://lwn.net/Articles/206697/
+.. [2] Singh, Balbir. Memory Controller (RSS Control),
http://lwn.net/Articles/222762/
-3. Emelianov, Pavel. Resource controllers based on process cgroups
+.. [3] Emelianov, Pavel. Resource controllers based on process cgroups
https://lore.kernel.org/r/45ED7DEC.7010403@sw.ru
-4. Emelianov, Pavel. RSS controller based on process cgroups (v2)
+.. [4] Emelianov, Pavel. RSS controller based on process cgroups (v2)
https://lore.kernel.org/r/461A3010.90403@sw.ru
-5. Emelianov, Pavel. RSS controller based on process cgroups (v3)
+.. [5] Emelianov, Pavel. RSS controller based on process cgroups (v3)
https://lore.kernel.org/r/465D9739.8070209@openvz.org
+
6. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/
7. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control
subsystem (v3), http://lwn.net/Articles/235534/
@@ -974,7 +1002,8 @@
https://lore.kernel.org/r/464D267A.50107@linux.vnet.ibm.com
10. Singh, Balbir. Memory controller v6 test results,
https://lore.kernel.org/r/20070819094658.654.84837.sendpatchset@balbir-laptop
-11. Singh, Balbir. Memory controller introduction (v6),
- https://lore.kernel.org/r/20070817084228.26003.12568.sendpatchset@balbir-laptop
-12. Corbet, Jonathan, Controlling memory use in cgroups,
- http://lwn.net/Articles/243795/
+
+.. [11] Singh, Balbir. Memory controller introduction (v6),
+ https://lore.kernel.org/r/20070817084228.26003.12568.sendpatchset@balbir-laptop
+.. [12] Corbet, Jonathan, Controlling memory use in cgroups,
+ http://lwn.net/Articles/243795/
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 74cec76..f67c082 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -619,10 +619,12 @@
and is an example of this type.
+.. _cgroupv2-limits-distributor:
+
Limits
------
-A child can only consume upto the configured amount of the resource.
+A child can only consume up to the configured amount of the resource.
Limits can be over-committed - the sum of the limits of children can
exceed the amount of resource available to the parent.
@@ -635,15 +637,16 @@
"io.max" limits the maximum BPS and/or IOPS that a cgroup can consume
on an IO device and is an example of this type.
+.. _cgroupv2-protections-distributor:
Protections
-----------
-A cgroup is protected upto the configured amount of the resource
+A cgroup is protected up to the configured amount of the resource
as long as the usages of all its ancestors are under their
protected levels. Protections can be hard guarantees or best effort
soft boundaries. Protections can also be over-committed in which case
-only upto the amount available to the parent is protected among
+only up to the amount available to the parent is protected among
children.
Protections are in the range [0, max] and defaults to 0, which is
@@ -1076,7 +1079,7 @@
$MAX $PERIOD
- which indicates that the group may consume upto $MAX in each
+ which indicates that the group may consume up to $MAX in each
$PERIOD duration. "max" for $MAX indicates no limit. If only
one number is written, $MAX is updated.
@@ -2286,7 +2289,7 @@
For a valid partition root with the sibling cpu exclusivity
rule enabled, changes made to "cpuset.cpus" that violate the
exclusivity rule will invalidate the partition as well as its
- sibiling partitions with conflicting cpuset.cpus values. So
+ sibling partitions with conflicting cpuset.cpus values. So
care must be taking in changing "cpuset.cpus".
A valid non-root parent partition may distribute out all its CPUs
diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst
index ed3b8dc..2e151cd 100644
--- a/Documentation/admin-guide/cifs/usage.rst
+++ b/Documentation/admin-guide/cifs/usage.rst
@@ -399,7 +399,7 @@
sep
if first mount option (after the -o), overrides
the comma as the separator between the mount
- parms. e.g.::
+ parameters. e.g.::
-o user=myname,password=mypassword,domain=mydom
@@ -765,7 +765,7 @@
Some debugging statements are not compiled into the
cifs kernel unless CONFIG_CIFS_DEBUG2 is enabled in the
kernel configuration. cifsFYI may be set to one or
- nore of the following flags (7 sets them all)::
+ more of the following flags (7 sets them all)::
+-----------------------------------------------+------+
| log cifs informational messages | 0x01 |
diff --git a/Documentation/admin-guide/device-mapper/cache-policies.rst b/Documentation/admin-guide/device-mapper/cache-policies.rst
index b17fe35..13da4d8 100644
--- a/Documentation/admin-guide/device-mapper/cache-policies.rst
+++ b/Documentation/admin-guide/device-mapper/cache-policies.rst
@@ -70,7 +70,7 @@
cache block).
All this means smq uses ~25bytes per cache block. Still a lot of
-memory, but a substantial improvement nontheless.
+memory, but a substantial improvement nonetheless.
Level balancing
^^^^^^^^^^^^^^^
diff --git a/Documentation/admin-guide/device-mapper/dm-ebs.rst b/Documentation/admin-guide/device-mapper/dm-ebs.rst
index 534fa38..c09f66d 100644
--- a/Documentation/admin-guide/device-mapper/dm-ebs.rst
+++ b/Documentation/admin-guide/device-mapper/dm-ebs.rst
@@ -31,7 +31,7 @@
Optional parameter:
- <underyling sectors>:
+ <underlying sectors>:
Number of sectors defining the logical block size of <dev path>.
2^N supported, e.g. 8 = emulate 8 sectors of 512 bytes = 4KiB.
If not provided, the logical block size of <dev path> will be used.
diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst b/Documentation/admin-guide/device-mapper/dm-zoned.rst
index 0fac051..932383f 100644
--- a/Documentation/admin-guide/device-mapper/dm-zoned.rst
+++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst
@@ -46,7 +46,7 @@
The zones of the device(s) are separated into 2 types:
1) Metadata zones: these are conventional zones used to store metadata.
-Metadata zones are not reported as useable capacity to the user.
+Metadata zones are not reported as usable capacity to the user.
2) Data zones: all remaining zones, the vast majority of which will be
sequential zones used exclusively to store user data. The conventional
diff --git a/Documentation/admin-guide/device-mapper/unstriped.rst b/Documentation/admin-guide/device-mapper/unstriped.rst
index 0a8d3eb..5772ccd 100644
--- a/Documentation/admin-guide/device-mapper/unstriped.rst
+++ b/Documentation/admin-guide/device-mapper/unstriped.rst
@@ -35,7 +35,7 @@
This small bash script will setup 4 loop devices and use the existing
striped target to combine the 4 devices into one. It then will use
-the unstriped target ontop of the striped device to access the
+the unstriped target on top of the striped device to access the
individual backing loop devices. We write data to the newly exposed
unstriped devices and verify the data written matches the correct
underlying device on the striped array::
@@ -110,8 +110,8 @@
Example dmsetup usage
=====================
-unstriped ontop of Intel NVMe device that has 2 cores
------------------------------------------------------
+unstriped on top of Intel NVMe device that has 2 cores
+------------------------------------------------------
::
@@ -124,8 +124,8 @@
/dev/mapper/nvmset0
/dev/mapper/nvmset1
-unstriped ontop of striped with 4 drives using 128K chunk size
---------------------------------------------------------------
+unstriped on top of striped with 4 drives using 128K chunk size
+---------------------------------------------------------------
::
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst
index faa22f7..8dc668c 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -330,7 +330,7 @@
// boot-args example, with newlines and comments for readability
Kernel command line: ...
- // see whats going on in dyndbg=value processing
+ // see what's going on in dyndbg=value processing
dynamic_debug.verbose=3
// enable pr_debugs in the btrfs module (can be builtin or loadable)
btrfs.dyndbg="+p"
diff --git a/Documentation/admin-guide/gpio/gpio-sim.rst b/Documentation/admin-guide/gpio/gpio-sim.rst
index d8a90c8..1cc5567 100644
--- a/Documentation/admin-guide/gpio/gpio-sim.rst
+++ b/Documentation/admin-guide/gpio/gpio-sim.rst
@@ -123,7 +123,7 @@
directory for each exposed line
(e.g. ``/sys/devices/platform/gpio-sim.X/gpiochipY/``). The name of each group
is of the form: ``'sim_gpioX'`` where X is the offset of the line. Inside each
-group there are two attibutes:
+group there are two attributes:
``pull`` - allows to read and set the current simulated pull setting for
every line, when writing the value must be one of: ``'pull-up'``,
diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
index 2d19c9f..f491de7 100644
--- a/Documentation/admin-guide/hw-vuln/mds.rst
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -64,8 +64,8 @@
Attack scenarios
----------------
-Attacks against the MDS vulnerabilities can be mounted from malicious non
-priviledged user space applications running on hosts or guest. Malicious
+Attacks against the MDS vulnerabilities can be mounted from malicious non-
+privileged user space applications running on hosts or guest. Malicious
guest OSes can obviously mount attacks as well.
Contrary to other speculation based vulnerabilities the MDS vulnerability
diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
index c4dcdb3..4d186f59 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -479,8 +479,16 @@
On Intel Skylake-era systems the mitigation covers most, but not all,
cases. See :ref:`[3] <spec_ref3>` for more details.
- On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
- IBRS on x86), retpoline is automatically disabled at run time.
+ On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS
+ or enhanced IBRS on x86), retpoline is automatically disabled at run time.
+
+ Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at
+ boot, by setting the IBRS bit, and they're automatically protected against
+ Spectre v2 variant attacks, including cross-thread branch target injections
+ on SMT systems (STIBP). In other words, eIBRS enables STIBP too.
+
+ Legacy IBRS systems clear the IBRS bit on exit to userspace and
+ therefore explicitly enable STIBP for that
The retpoline mitigation is turned on by default on vulnerable
CPUs. It can be forced on or off by the administrator
@@ -504,9 +512,12 @@
For Spectre variant 2 mitigation, individual user programs
can be compiled with return trampolines for indirect branches.
This protects them from consuming poisoned entries in the branch
- target buffer left by malicious software. Alternatively, the
- programs can disable their indirect branch speculation via prctl()
- (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
+ target buffer left by malicious software.
+
+ On legacy IBRS systems, at return to userspace, implicit STIBP is disabled
+ because the kernel clears the IBRS bit. In this case, the userspace programs
+ can disable indirect branch speculation via prctl() (See
+ :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
On x86, this will turn on STIBP to guard against attacks from the
sibling thread when the user program is running, and use IBPB to
flush the branch target buffer when switching to/from the program.
@@ -610,9 +621,9 @@
retpoline,generic Retpolines
retpoline,lfence LFENCE; indirect branch
retpoline,amd alias for retpoline,lfence
- eibrs enhanced IBRS
- eibrs,retpoline enhanced IBRS + Retpolines
- eibrs,lfence enhanced IBRS + LFENCE
+ eibrs Enhanced/Auto IBRS
+ eibrs,retpoline Enhanced/Auto IBRS + Retpolines
+ eibrs,lfence Enhanced/Auto IBRS + LFENCE
ibrs use IBRS to protect kernel
Not specifying this option is equivalent to
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 5bfafcb..09a563b 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -36,7 +36,6 @@
reporting-issues
reporting-regressions
- security-bugs
bug-hunting
bug-bisect
tainted-kernels
@@ -56,6 +55,17 @@
sysfs-rules
+This is the beginning of a section with information of interest to
+application developers and system integrators doing analysis of the
+Linux kernel for safety critical applications. Documents supporting
+analysis of kernel interactions with applications, and key kernel
+subsystems expectations will be found here.
+
+.. toctree::
+ :maxdepth: 1
+
+ workload-tracing
+
The rest of this manual consists of various unordered guides on how to
configure specific aspects of kernel behavior to your liking.
@@ -116,6 +126,7 @@
svga
syscall-user-dispatch
sysrq
+ thermal/index
thunderbolt
ufs
unicode
diff --git a/Documentation/admin-guide/kdump/gdbmacros.txt b/Documentation/admin-guide/kdump/gdbmacros.txt
index 82aecdc..030de95 100644
--- a/Documentation/admin-guide/kdump/gdbmacros.txt
+++ b/Documentation/admin-guide/kdump/gdbmacros.txt
@@ -312,10 +312,10 @@
set var $prev_flags = $info->flags
end
- set var $id = ($id + 1) & $id_mask
if ($id == $end_id)
loop_break
end
+ set var $id = ($id + 1) & $id_mask
end
end
document dmesg
diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst
index 959f73a..6ae5f12 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -128,6 +128,7 @@
KVM Kernel Virtual Machine support is enabled.
LIBATA Libata driver is enabled
LP Printer support is enabled.
+ LOONGARCH LoongArch architecture is enabled.
LOOP Loopback device support is enabled.
M68k M68k architecture is enabled.
These options have more detailed description inside of
@@ -142,7 +143,6 @@
NFS Appropriate NFS support is enabled.
OF Devicetree is enabled.
PV_OPS A paravirtualized kernel is enabled.
- PARIDE The ParIDE (parallel port IDE) subsystem is enabled.
PARISC The PA-RISC architecture is enabled.
PCI PCI bus support is enabled.
PCIE PCI Express support is enabled.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 6cfa6e3..7016cb1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -378,18 +378,16 @@
autoconf= [IPV6]
See Documentation/networking/ipv6.rst.
- show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
- Limit apic dumping. The parameter defines the maximal
- number of local apics being dumped. Also it is possible
- to set it to "all" by meaning -- no limit here.
- Format: { 1 (default) | 2 | ... | all }.
- The parameter valid if only apic=debug or
- apic=verbose is specified.
- Example: apic=debug show_lapic=all
-
apm= [APM] Advanced Power Management
See header of arch/x86/kernel/apm_32.c.
+ apparmor= [APPARMOR] Disable or enable AppArmor at boot time
+ Format: { "0" | "1" }
+ See security/apparmor/Kconfig help text
+ 0 -- disable.
+ 1 -- enable.
+ Default value is set via kernel config option.
+
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
Format: <io>,<irq>,<nodeID>
@@ -480,8 +478,10 @@
See Documentation/block/cmdline-partition.rst
boot_delay= Milliseconds to delay each printk during boot.
- Values larger than 10 seconds (10000) are changed to
- no delay (0).
+ Only works if CONFIG_BOOT_PRINTK_DELAY is enabled,
+ and you may also have to specify "lpj=". Boot_delay
+ values larger than 10 seconds (10000) are assumed
+ erroneous and ignored.
Format: integer
bootconfig [KNL]
@@ -557,6 +557,7 @@
Format: <string>
nosocket -- Disable socket memory accounting.
nokmem -- Disable kernel memory accounting.
+ nobpf -- Disable BPF memory accounting.
checkreqprot= [SELINUX] Set initial checkreqprot flag value.
Format: { "0" | "1" }
@@ -672,7 +673,7 @@
Sets the size of kernel per-numa memory area for
contiguous memory allocations. A value of 0 disables
per-numa CMA altogether. And If this option is not
- specificed, the default value is 0.
+ specified, the default value is 0.
With per-numa CMA enabled, DMA users on node nid will
first try to allocate buffer from the pernuma area
which is located in node nid, if the allocation fails,
@@ -944,7 +945,7 @@
driver code when a CPU writes to (or reads from) a
random memory location. Note that there exists a class
of memory corruptions problems caused by buggy H/W or
- F/W or by drivers badly programing DMA (basically when
+ F/W or by drivers badly programming DMA (basically when
memory is written at bus level and the CPU MMU is
bypassed) which are not detectable by
CONFIG_DEBUG_PAGEALLOC, hence this option will not help
@@ -1045,26 +1046,12 @@
can be useful when debugging issues that require an SLB
miss to occur.
- stress_slb [PPC]
- Limits the number of kernel SLB entries, and flushes
- them frequently to increase the rate of SLB faults
- on kernel addresses.
-
- stress_hpt [PPC]
- Limits the number of kernel HPT entries in the hash
- page table to increase the rate of hash page table
- faults on kernel addresses.
-
disable= [IPV6]
See Documentation/networking/ipv6.rst.
disable_radix [PPC]
Disable RADIX MMU mode on POWER9
- radix_hcall_invalidate=on [PPC/PSERIES]
- Disable RADIX GTSE feature and use hcall for TLB
- invalidate.
-
disable_tlbie [PPC]
Disable TLBIE instruction. Currently does not work
with KVM, with HASH MMU, or with coherent accelerators.
@@ -1166,16 +1153,6 @@
Documentation/admin-guide/dynamic-debug-howto.rst
for details.
- nopku [X86] Disable Memory Protection Keys CPU feature found
- in some Intel CPUs.
-
- <module>.async_probe[=<bool>] [KNL]
- If no <bool> value is specified or if the value
- specified is not a valid <bool>, enable asynchronous
- probe on this module. Otherwise, enable/disable
- asynchronous probe on this module as indicated by the
- <bool> value. See also: module.async_probe
-
early_ioremap_debug [KNL]
Enable debug messages in early_ioremap support. This
is useful for tracking down temporary early mappings
@@ -1195,10 +1172,10 @@
specified, the serial port must already be setup and
configured.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
- uart[8250],mmio32,<addr>[,options]
- uart[8250],mmio32be,<addr>[,options]
+ uart[8250],io,<addr>[,options[,uartclk]]
+ uart[8250],mmio,<addr>[,options[,uartclk]]
+ uart[8250],mmio32,<addr>[,options[,uartclk]]
+ uart[8250],mmio32be,<addr>[,options[,uartclk]]
uart[8250],0x<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
@@ -1207,7 +1184,9 @@
If none of [io|mmio|mmio32|mmio32be], <addr> is assumed
to be equivalent to 'mmio'. 'options' are specified
in the same format described for "console=ttyS<n>"; if
- unspecified, the h/w is not initialized.
+ unspecified, the h/w is not initialized. 'uartclk' is
+ the uart clock frequency; if unspecified, it is set
+ to 'BASE_BAUD' * 16.
pl011,<addr>
pl011,mmio32,<addr>
@@ -1532,6 +1511,15 @@
boot up that is likely to be overridden by user space
start up functionality.
+ Optionally, the snapshot can also be defined for a tracing
+ instance that was created by the trace_instance= command
+ line parameter.
+
+ trace_instance=foo,sched_switch ftrace_boot_snapshot=foo
+
+ The above will cause the "foo" tracing instance to trigger
+ a snapshot at the end of boot up.
+
ftrace_dump_on_oops[=orig_cpu]
[FTRACE] will dump the trace buffers on oops.
If no parameter is passed, ftrace will dump
@@ -1752,7 +1740,7 @@
boot-time allocation of gigantic hugepages is skipped.
hugetlb_free_vmemmap=
- [KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+ [KNL] Requires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
enabled.
Control if HugeTLB Vmemmap Optimization (HVO) is enabled.
Allows heavy hugetlb users to free up some more
@@ -1791,12 +1779,6 @@
which allow the hypervisor to 'idle' the
guest on lock contention.
- keep_bootcon [KNL]
- Do not unregister boot console at start. This is only
- useful for debugging when something happens in the window
- between unregistering the boot console and initializing
- the real console.
-
i2c_bus= [HW] Override the default board specific I2C bus speed
or register an additional I2C bus that is not
registered from board initialization code.
@@ -2366,17 +2348,18 @@
js= [HW,JOY] Analog joystick
See Documentation/input/joydev/joystick.rst.
- nokaslr [KNL]
- When CONFIG_RANDOMIZE_BASE is set, this disables
- kernel and module base offset ASLR (Address Space
- Layout Randomization).
-
kasan_multi_shot
[KNL] Enforce KASAN (Kernel Address Sanitizer) to print
report on every invalid memory access. Without this
parameter KASAN will print report only for the first
invalid access.
+ keep_bootcon [KNL]
+ Do not unregister boot console at start. This is only
+ useful for debugging when something happens in the window
+ between unregistering the boot console and initializing
+ the real console.
+
keepinitrd [HW,ARM]
kernelcore= [KNL,X86,IA-64,PPC]
@@ -2553,9 +2536,14 @@
protected: nVHE-based mode with support for guests whose
state is kept private from the host.
+ nested: VHE-based mode with support for nested
+ virtualization. Requires at least ARMv8.3
+ hardware.
+
Defaults to VHE/nVHE based on hardware support. Setting
mode to "protected" will disable kexec and hibernation
- for the host.
+ for the host. "nested" is experimental and should be
+ used with extreme caution.
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
@@ -2816,6 +2804,9 @@
* [no]setxfer: Indicate if transfer speed mode setting
should be skipped.
+ * [no]fua: Disable or enable FUA (Force Unit Access)
+ support for devices supporting this feature.
+
* dump_id: Dump IDENTIFY data.
* disable: Disable this device.
@@ -3325,6 +3316,13 @@
For details see:
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
+ <module>.async_probe[=<bool>] [KNL]
+ If no <bool> value is specified or if the value
+ specified is not a valid <bool>, enable asynchronous
+ probe on this module. Otherwise, enable/disable
+ asynchronous probe on this module as indicated by the
+ <bool> value. See also: module.async_probe
+
module.async_probe=<bool>
[KNL] When set to true, modules will use async probing
by default. To enable/disable async probing for a
@@ -3708,7 +3706,7 @@
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
to be effective. This is useful on platforms where the
sleep(SH) or wfi(ARM,ARM64) instructions do not work
- correctly or when doing power measurements to evalute
+ correctly or when doing power measurements to evaluate
the impact of the sleep instructions. This is also
useful when using JTAG debugger.
@@ -3779,6 +3777,11 @@
nojitter [IA-64] Disables jitter checking for ITC timers.
+ nokaslr [KNL]
+ When CONFIG_RANDOMIZE_BASE is set, this disables
+ kernel and module base offset ASLR (Address Space
+ Layout Randomization).
+
no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page
@@ -3824,6 +3827,19 @@
nopcid [X86-64] Disable the PCID cpu feature.
+ nopku [X86] Disable Memory Protection Keys CPU feature found
+ in some Intel CPUs.
+
+ nopv= [X86,XEN,KVM,HYPER_V,VMWARE]
+ Disables the PV optimizations forcing the guest to run
+ as generic guest with no PV drivers. Currently support
+ XEN HVM, KVM, HYPER_V and VMWARE guest.
+
+ nopvspin [X86,XEN,KVM]
+ Disables the qspinlock slow path using PV optimizations
+ which allow the hypervisor to 'idle' the guest on lock
+ contention.
+
norandmaps Don't use address space randomization. Equivalent to
echo 0 > /proc/sys/kernel/randomize_va_space
@@ -4117,10 +4133,6 @@
pcbit= [HW,ISDN]
- pcd. [PARIDE]
- See header of drivers/block/paride/pcd.c.
- See also Documentation/admin-guide/blockdev/paride.rst.
-
pci=option[,option...] [PCI] various PCI subsystem options.
Some options herein operate on a specific device
@@ -4296,7 +4308,9 @@
specified, e.g., 12@pci:8086:9c22:103c:198f
for 4096-byte alignment.
ecrc= Enable/disable PCIe ECRC (transaction layer
- end-to-end CRC checking).
+ end-to-end CRC checking). Only effective if
+ OS has native AER control (either granted by
+ ACPI _OSC or forced via "pcie_ports=native")
bios: Use BIOS/firmware settings. This is the
the default.
off: Turn ECRC off
@@ -4383,9 +4397,6 @@
for debug and development, but should not be
needed on a platform with proper driver support.
- pd. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
pdcchassis= [PARISC,HW] Disable/Enable PDC Chassis Status codes at
boot time.
Format: { 0 | 1 }
@@ -4398,12 +4409,6 @@
allocator. This parameter is primarily for debugging
and performance comparison.
- pf. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
- pg. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
pirq= [SMP,APIC] Manual mp-table setup
See Documentation/x86/i386/IO-APIC.rst.
@@ -4565,9 +4570,6 @@
pstore.backend= Specify the name of the pstore backend to use
- pt. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
pti= [X86-64] Control Page Table Isolation of user and
kernel address spaces. Disabling this feature
removes hardening, but improves performance of
@@ -4591,6 +4593,10 @@
r128= [HW,DRM]
+ radix_hcall_invalidate=on [PPC/PSERIES]
+ Disable RADIX GTSE feature and use hcall for TLB
+ invalidate.
+
raid= [HW,RAID]
See Documentation/admin-guide/md.rst.
@@ -5113,6 +5119,17 @@
rcupdate.rcu_cpu_stall_timeout to be used (after
conversion from seconds to milliseconds).
+ rcupdate.rcu_cpu_stall_cputime= [KNL]
+ Provide statistics on the cputime and count of
+ interrupts and tasks during the sampling period. For
+ multiple continuous RCU stalls, all sampling periods
+ begin at half of the first RCU stall timeout.
+
+ rcupdate.rcu_exp_stall_task_details= [KNL]
+ Print stack dumps of any tasks blocking the
+ current expedited RCU grace period during an
+ expedited RCU CPU stall warning.
+
rcupdate.rcu_expedited= [KNL]
Use expedited grace-period primitives, for
example, synchronize_rcu_expedited() instead
@@ -5221,7 +5238,7 @@
rdt= [HW,X86,RDT]
Turn on/off individual RDT features. List is:
cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
- mba.
+ mba, smba, bmec.
E.g. to turn on cmt and turn off mba use:
rdt=cmt,!mba
@@ -5572,13 +5589,6 @@
1 -- enable.
Default value is 1.
- apparmor= [APPARMOR] Disable or enable AppArmor at boot time
- Format: { "0" | "1" }
- See security/apparmor/Kconfig help text
- 0 -- disable.
- 1 -- enable.
- Default value is set via kernel config option.
-
serialnumber [BUGS=X86-32]
sev=option[,option...] [X86-64] See Documentation/x86/x86_64/boot-options.rst
@@ -5586,6 +5596,15 @@
shapers= [NET]
Maximal number of shapers.
+ show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
+ Limit apic dumping. The parameter defines the maximal
+ number of local apics being dumped. Also it is possible
+ to set it to "all" by meaning -- no limit here.
+ Format: { 1 (default) | 2 | ... | all }.
+ The parameter valid if only apic=debug or
+ apic=verbose is specified.
+ Example: apic=debug show_lapic=all
+
simeth= [IA-64]
simscsi=
@@ -5729,9 +5748,9 @@
retpoline,generic - Retpolines
retpoline,lfence - LFENCE; indirect branch
retpoline,amd - alias for retpoline,lfence
- eibrs - enhanced IBRS
- eibrs,retpoline - enhanced IBRS + Retpolines
- eibrs,lfence - enhanced IBRS + LFENCE
+ eibrs - Enhanced/Auto IBRS
+ eibrs,retpoline - Enhanced/Auto IBRS + Retpolines
+ eibrs,lfence - Enhanced/Auto IBRS + LFENCE
ibrs - use IBRS to protect kernel
Not specifying this option is equivalent to
@@ -6025,6 +6044,16 @@
be used to filter out binaries which have
not yet been made aware of AT_MINSIGSTKSZ.
+ stress_hpt [PPC]
+ Limits the number of kernel HPT entries in the hash
+ page table to increase the rate of hash page table
+ faults on kernel addresses.
+
+ stress_slb [PPC]
+ Limits the number of kernel SLB entries, and flushes
+ them frequently to increase the rate of SLB faults
+ on kernel addresses.
+
sunrpc.min_resvport=
sunrpc.max_resvport=
[NFS,SUNRPC]
@@ -6272,13 +6301,33 @@
comma-separated list of trace events to enable. See
also Documentation/trace/events.rst
+ trace_instance=[instance-info]
+ [FTRACE] Create a ring buffer instance early in boot up.
+ This will be listed in:
+
+ /sys/kernel/tracing/instances
+
+ Events can be enabled at the time the instance is created
+ via:
+
+ trace_instance=<name>,<system1>:<event1>,<system2>:<event2>
+
+ Note, the "<system*>:" portion is optional if the event is
+ unique.
+
+ trace_instance=foo,sched:sched_switch,irq_handler_entry,initcall
+
+ will enable the "sched_switch" event (note, the "sched:" is optional, and
+ the same thing would happen if it was left off). The irq_handler_entry
+ event, and all events under the "initcall" system.
+
trace_options=[option-list]
[FTRACE] Enable or disable tracer options at boot.
The option-list is a comma delimited list of options
that can be enabled or disabled just as if you were
to echo the option name into
- /sys/kernel/debug/tracing/trace_options
+ /sys/kernel/tracing/trace_options
For example, to enable stacktrace option (to dump the
stack trace of each event), add to the command line:
@@ -6311,7 +6360,7 @@
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
be enabled again by echoing '1' into the "tracing_on"
- file located in /sys/kernel/debug/tracing/
+ file located in /sys/kernel/tracing/
This option is useful, as it disables the trace before
the WARNING dump is called, which prevents the trace to
@@ -6369,6 +6418,16 @@
in situations with strict latency requirements (where
interruptions from clocksource watchdog are not
acceptable).
+ [x86] recalibrate: force recalibration against a HW timer
+ (HPET or PM timer) on systems whose TSC frequency was
+ obtained from HW or FW using either an MSR or CPUID(0x15).
+ Warn if the difference is more than 500 ppm.
+ [x86] watchdog: Use TSC as the watchdog clocksource with
+ which to check other HW timers (HPET or PM timer), but
+ only on systems where TSC has been deemed trustworthy.
+ This will be suppressed by an earlier tsc=nowatchdog and
+ can be overridden by a later tsc=nowatchdog. A console
+ message will flag any such suppression or overriding.
tsc_early_khz= [X86] Skip early TSC calibration and use the given
value instead. Useful when the early TSC frequency discovery
@@ -6756,11 +6815,11 @@
functions are at fixed addresses, they make nice
targets for exploits that can control RIP.
- emulate [default] Vsyscalls turn into traps and are
- emulated reasonably safely. The vsyscall
- page is readable.
+ emulate Vsyscalls turn into traps and are emulated
+ reasonably safely. The vsyscall page is
+ readable.
- xonly Vsyscalls turn into traps and are
+ xonly [default] Vsyscalls turn into traps and are
emulated reasonably safely. The vsyscall
page is not readable.
@@ -6874,6 +6933,12 @@
When enabled, memory and cache locality will be
impacted.
+ writecombine= [LOONGARCH] Control the MAT (Memory Access Type) of
+ ioremap_wc().
+
+ on - Enable writecombine, use WUC for ioremap_wc()
+ off - Disable writecombine, use SUC for ioremap_wc()
+
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
default x2apic cluster mode on platforms
supporting x2apic.
@@ -6957,16 +7022,6 @@
fairer and the number of possible event channels is
much higher. Default is on (use fifo events).
- nopv= [X86,XEN,KVM,HYPER_V,VMWARE]
- Disables the PV optimizations forcing the guest to run
- as generic guest with no PV drivers. Currently support
- XEN HVM, KVM, HYPER_V and VMWARE guest.
-
- nopvspin [X86,XEN,KVM]
- Disables the qspinlock slow path using PV optimizations
- which allow the hypervisor to 'idle' the guest on lock
- contention.
-
xirc2ps_cs= [NET,PCMCIA]
Format:
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
@@ -7020,3 +7075,10 @@
management firmware translates the requests into actual
hardware states (core frequency, data fabric and memory
clocks etc.)
+ active
+ Use amd_pstate_epp driver instance as the scaling driver,
+ driver provides a hint to the hardware if software wants
+ to bias toward performance (0x0) or energy efficiency (0xff)
+ to the CPPC firmware. then CPPC power algorithm will
+ calculate the runtime workload and adjust the realtime cores
+ frequency.
diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
index e4a5fc2..993c2a0 100644
--- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
+++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
@@ -25,7 +25,7 @@
- In order to locate kernel-generated OS jitter on CPU N:
- cd /sys/kernel/debug/tracing
+ cd /sys/kernel/tracing
echo 1 > max_graph_depth # Increase the "1" for more detail
echo function_graph > current_tracer
# run workload
diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
index 475eb0e..e27a1c3 100644
--- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -1488,7 +1488,7 @@
Text corresponding to keyboard layout to be set in sysfs are: be(Belgian),
cz(Czech), da(Danish), de(German), en(English), es(Spain), et(Estonian),
fr(French), fr-ch(French(Switzerland)), hu(Hungarian), it(Italy), jp (Japan),
-nl(Dutch), nn(Norway), pl(Polish), pt(portugese), sl(Slovenian), sv(Sweden),
+nl(Dutch), nn(Norway), pl(Polish), pt(portuguese), sl(Slovenian), sv(Sweden),
tr(Turkey)
WWAN Antenna type
diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst
index d8fc9a5..4ff2cc2 100644
--- a/Documentation/admin-guide/md.rst
+++ b/Documentation/admin-guide/md.rst
@@ -317,7 +317,7 @@
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
- Writing this, if accepted, will block until array is quiessent
+ Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
diff --git a/Documentation/admin-guide/media/bttv.rst b/Documentation/admin-guide/media/bttv.rst
index 125f6f4..58cbaf6 100644
--- a/Documentation/admin-guide/media/bttv.rst
+++ b/Documentation/admin-guide/media/bttv.rst
@@ -909,7 +909,7 @@
- TVPhone98 (Bt878)
- AVerTV und TVCapture98 w/VCR (Bt 878)
- AVerTVStudio und TVPhone98 w/VCR (Bt878)
- - AVerTV GO Serie (Kein SVideo Input)
+ - AVerTV GO Series (Kein SVideo Input)
- AVerTV98 (BT-878 chip)
- AVerTV98 mit Fernbedienung (BT-878 chip)
- AVerTV/FM98 (BT-878 chip)
diff --git a/Documentation/admin-guide/media/building.rst b/Documentation/admin-guide/media/building.rst
index 2d660b7..a064734 100644
--- a/Documentation/admin-guide/media/building.rst
+++ b/Documentation/admin-guide/media/building.rst
@@ -137,7 +137,7 @@
from remote controllers.
The ``Support for eBPF programs attached to lirc devices`` option allows
-the usage of special programs (called eBPF) that would allow aplications
+the usage of special programs (called eBPF) that would allow applications
to add extra remote controller decoding functionality to the Linux Kernel.
The ``Remote controller decoders`` option allows selecting the
diff --git a/Documentation/admin-guide/media/cec.rst b/Documentation/admin-guide/media/cec.rst
index 5c72593..14ec3ff 100644
--- a/Documentation/admin-guide/media/cec.rst
+++ b/Documentation/admin-guide/media/cec.rst
@@ -340,14 +340,14 @@
This kernel patch will hook up the cec-gpio driver correctly to
e.g. ``arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts``::
- cec-gpio@7 {
+ cec@7 {
compatible = "cec-gpio";
cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
};
- cec-gpio@8 {
+ cec@8 {
compatible = "cec-gpio";
cec-gpios = <&gpio 8 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
hpd-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
diff --git a/Documentation/admin-guide/media/cpia2.rst b/Documentation/admin-guide/media/cpia2.rst
deleted file mode 100644
index f6ffef6..0000000
--- a/Documentation/admin-guide/media/cpia2.rst
+++ /dev/null
@@ -1,145 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The cpia2 driver
-================
-
-Authors: Peter Pregler <Peter_Pregler@email.com>,
-Scott J. Bertin <scottbertin@yahoo.com>, and
-Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
-this one was modelled from.
-
-Introduction
-------------
-
-This is a driver for STMicroelectronics's CPiA2 (second generation
-Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
-stream at up to vga size. It implements the Video4Linux interface as much as
-possible. Since the V4L interface does not support compressed formats, only
-an mjpeg enabled application can be used with the camera. We have modified the
-gqcam application to view this stream.
-
-The driver is implemented as two kernel modules. The cpia2 module
-contains the camera functions and the V4L interface. The cpia2_usb module
-contains usb specific functions. The main reason for this was the size of the
-module was getting out of hand, so I separated them. It is not likely that
-there will be a parallel port version.
-
-Features
---------
-
-- Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
- sensors. I only have the vga sensor, so can't test the other.
-- Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
- VGA and QVGA are the native image sizes for the VGA camera. CIF is done
- in the coprocessor by scaling QVGA. All other sizes are done by clipping.
-- Palette: YCrCb, compressed with MJPEG.
-- Some compression parameters are settable.
-- Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
-- Adjust brightness, color, contrast while streaming.
-- Flicker control settable for 50 or 60 Hz mains frequency.
-
-Making and installing the stv672 driver modules
------------------------------------------------
-
-Requirements
-~~~~~~~~~~~~
-
-Video4Linux must be either compiled into the kernel or
-available as a module. Video4Linux2 is automatically detected and made
-available at compile time.
-
-Setup
-~~~~~
-
-Use ``modprobe cpia2`` to load and ``modprobe -r cpia2`` to unload. This
-may be done automatically by your distribution.
-
-Driver options
-~~~~~~~~~~~~~~
-
-.. tabularcolumns:: |p{13ex}|L|
-
-
-============== ========================================================
-Option Description
-============== ========================================================
-video_nr video device to register (0=/dev/video0, etc)
- range -1 to 64. default is -1 (first available)
- If you have more than 1 camera, this MUST be -1.
-buffer_size Size for each frame buffer in bytes (default 68k)
-num_buffers Number of frame buffers (1-32, default 3)
-alternate USB Alternate (2-7, default 7)
-flicker_freq Frequency for flicker reduction(50 or 60, default 60)
-flicker_mode 0 to disable, or 1 to enable flicker reduction.
- (default 0). This is only effective if the camera
- uses a stv0672 coprocessor.
-============== ========================================================
-
-Setting the options
-~~~~~~~~~~~~~~~~~~~
-
-If you are using modules, edit /etc/modules.conf and add an options
-line like this::
-
- options cpia2 num_buffers=3 buffer_size=65535
-
-If the driver is compiled into the kernel, at boot time specify them
-like this::
-
- cpia2.num_buffers=3 cpia2.buffer_size=65535
-
-What buffer size should I use?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The maximum image size depends on the alternate you choose, and the
-frame rate achieved by the camera. If the compression engine is able to
-keep up with the frame rate, the maximum image size is given by the table
-below.
-
-The compression engine starts out at maximum compression, and will
-increase image quality until it is close to the size in the table. As long
-as the compression engine can keep up with the frame rate, after a short time
-the images will all be about the size in the table, regardless of resolution.
-
-At low alternate settings, the compression engine may not be able to
-compress the image enough and will reduce the frame rate by producing larger
-images.
-
-The default of 68k should be good for most users. This will handle
-any alternate at frame rates down to 15fps. For lower frame rates, it may
-be necessary to increase the buffer size to avoid having frames dropped due
-to insufficient space.
-
-========== ========== ======== =====
-Alternate bytes/ms 15fps 30fps
-========== ========== ======== =====
- 2 128 8533 4267
- 3 384 25600 12800
- 4 640 42667 21333
- 5 768 51200 25600
- 6 896 59733 29867
- 7 1023 68200 34100
-========== ========== ======== =====
-
-Table: Image size(bytes)
-
-
-How many buffers should I use?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For normal streaming, 3 should give the best results. With only 2,
-it is possible for the camera to finish sending one image just after a
-program has started reading the other. If this happens, the driver must drop
-a frame. The exception to this is if you have a heavily loaded machine. In
-this case use 2 buffers. You are probably not reading at the full frame rate.
-If the camera can send multiple images before a read finishes, it could
-overwrite the third buffer before the read finishes, leading to a corrupt
-image. Single and double buffering have extra checks to avoid overwriting.
-
-Using the camera
-~~~~~~~~~~~~~~~~
-
-We are providing a modified gqcam application to view the output. In
-order to avoid confusion, here it is called mview. There is also the qx5view
-program which can also control the lights on the qx5 microscope. MJPEG Tools
-(http://mjpeg.sourceforge.net) can also be used to record from the camera.
diff --git a/Documentation/admin-guide/media/davinci-vpbe.rst b/Documentation/admin-guide/media/davinci-vpbe.rst
deleted file mode 100644
index 9e6360f..0000000
--- a/Documentation/admin-guide/media/davinci-vpbe.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The VPBE V4L2 driver design
-===========================
-
-Functional partitioning
------------------------
-
-Consists of the following:
-
- 1. V4L2 display driver
-
- Implements creation of video2 and video3 device nodes and
- provides v4l2 device interface to manage VID0 and VID1 layers.
-
- 2. Display controller
-
- Loads up VENC, OSD and external encoders such as ths8200. It provides
- a set of API calls to V4L2 drivers to set the output/standards
- in the VENC or external sub devices. It also provides
- a device object to access the services from OSD subdevice
- using sub device ops. The connection of external encoders to VENC LCD
- controller port is done at init time based on default output and standard
- selection or at run time when application change the output through
- V4L2 IOCTLs.
-
- When connected to an external encoder, vpbe controller is also responsible
- for setting up the interface between VENC and external encoders based on
- board specific settings (specified in board-xxx-evm.c). This allows
- interfacing external encoders such as ths8200. The setup_if_config()
- is implemented for this as well as configure_venc() (part of the next patch)
- API to set timings in VENC for a specific display resolution. As of this
- patch series, the interconnection and enabling and setting of the external
- encoders is not present, and would be a part of the next patch series.
-
- 3. VENC subdevice module
-
- Responsible for setting outputs provided through internal DACs and also
- setting timings at LCD controller port when external encoders are connected
- at the port or LCD panel timings required. When external encoder/LCD panel
- is connected, the timings for a specific standard/preset is retrieved from
- the board specific table and the values are used to set the timings in
- venc using non-standard timing mode.
-
- Support LCD Panel displays using the VENC. For example to support a Logic
- PD display, it requires setting up the LCD controller port with a set of
- timings for the resolution supported and setting the dot clock. So we could
- add the available outputs as a board specific entry (i.e add the "LogicPD"
- output name to board-xxx-evm.c). A table of timings for various LCDs
- supported can be maintained in the board specific setup file to support
- various LCD displays.As of this patch a basic driver is present, and this
- support for external encoders and displays forms a part of the next
- patch series.
-
- 4. OSD module
-
- OSD module implements all OSD layer management and hardware specific
- features. The VPBE module interacts with the OSD for enabling and
- disabling appropriate features of the OSD.
-
-Current status
---------------
-
-A fully functional working version of the V4L2 driver is available. This
-driver has been tested with NTSC and PAL standards and buffer streaming.
diff --git a/Documentation/admin-guide/media/dvb-drivers.rst b/Documentation/admin-guide/media/dvb-drivers.rst
index 8df637c..66fa4ed 100644
--- a/Documentation/admin-guide/media/dvb-drivers.rst
+++ b/Documentation/admin-guide/media/dvb-drivers.rst
@@ -13,4 +13,3 @@
opera-firmware
technisat
ttusb-dec
- zr364xx
diff --git a/Documentation/admin-guide/media/meye.rst b/Documentation/admin-guide/media/meye.rst
deleted file mode 100644
index 9098a1e..0000000
--- a/Documentation/admin-guide/media/meye.rst
+++ /dev/null
@@ -1,93 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: <isonum.txt>
-
-Vaio Picturebook Motion Eye Camera Driver
-=========================================
-
-Copyright |copy| 2001-2004 Stelian Pop <stelian@popies.net>
-
-Copyright |copy| 2001-2002 Alcôve <www.alcove.com>
-
-Copyright |copy| 2000 Andrew Tridgell <tridge@samba.org>
-
-This driver enable the use of video4linux compatible applications with the
-Motion Eye camera. This driver requires the "Sony Laptop Extras" driver (which
-can be found in the "Misc devices" section of the kernel configuration utility)
-to be compiled and installed (using its "camera=1" parameter).
-
-It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
-
-Grabbing is supported in packed YUV colorspace only.
-
-MJPEG hardware grabbing is supported via a private API (see below).
-
-Hardware supported
-------------------
-
-This driver supports the 'second' version of the MotionEye camera :)
-
-The first version was connected directly on the video bus of the Neomagic
-video card and is unsupported.
-
-The second one, made by Kawasaki Steel is fully supported by this
-driver (PCI vendor/device is 0x136b/0xff01)
-
-The third one, present in recent (more or less last year) Picturebooks
-(C1M* models), is not supported. The manufacturer has given the specs
-to the developers under a NDA (which allows the development of a GPL
-driver however), but things are not moving very fast (see
-http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
-
-There is a forth model connected on the USB bus in TR1* Vaio laptops.
-This camera is not supported at all by the current driver, in fact
-little information if any is available for this camera
-(USB vendor/device is 0x054c/0x0107).
-
-Driver options
---------------
-
-Several options can be passed to the meye driver using the standard
-module argument syntax (<param>=<value> when passing the option to the
-module or meye.<param>=<value> on the kernel boot line when meye is
-statically linked into the kernel). Those options are:
-
-.. code-block:: none
-
- gbuffers: number of capture buffers, default is 2 (32 max)
-
- gbufsize: size of each capture buffer, default is 614400
-
- video_nr: video device to register (0 = /dev/video0, etc)
-
-Module use
-----------
-
-In order to automatically load the meye module on use, you can put those lines
-in your /etc/modprobe.d/meye.conf file:
-
-.. code-block:: none
-
- alias char-major-81 videodev
- alias char-major-81-0 meye
- options meye gbuffers=32
-
-Usage:
-------
-
-.. code-block:: none
-
- xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
- for display and uncompressed video capture:
-
- xawtv -c /dev/video0 -geometry 640x480
- or
- xawtv -c /dev/video0 -geometry 320x240
-
- motioneye (<http://popies.net/meye/>)
- for getting ppm or jpg snapshots, mjpeg video
-
-Bugs / Todo
------------
-
-- 'motioneye' still uses the meye private v4l1 API extensions.
diff --git a/Documentation/admin-guide/media/other-usb-cardlist.rst b/Documentation/admin-guide/media/other-usb-cardlist.rst
index bbfdb13..fb88db5 100644
--- a/Documentation/admin-guide/media/other-usb-cardlist.rst
+++ b/Documentation/admin-guide/media/other-usb-cardlist.rst
@@ -14,8 +14,6 @@
dvb-as102 Sky IT Digital Key (green led) 2137:0001
b2c2-flexcop-usb Technisat/B2C2 FlexCop II/IIb/III 0af7:0101
Digital TV
-cpia2 Vision's CPiA2 cameras 0553:0100, 0553:0140,
- such as the Digital Blue QX5 0553:0151
go7007 WIS GO7007 MPEG encoder 1943:a250, 093b:a002,
093b:a004, 0eb1:6666,
0eb1:6668
@@ -66,7 +64,6 @@
pwc Visionite VCS-UM100 0d81:1910
s2255drv Sensoray 2255 1943:2255, 1943:2257
stk1160 STK1160 USB video capture dongle 05e1:0408
-stkwebcam Syntek DC1125 174f:a311, 05e1:0501
dvb-ttusb-budget Technotrend/Hauppauge Nova-USB devices 0b48:1003, 0b48:1004,
0b48:1005
dvb-ttusb_dec Technotrend/Hauppauge MPEG decoder 0b48:1006
@@ -78,15 +75,4 @@
DEC2540-t 0b48:1009
usbtv Fushicai USBTV007 Audio-Video Grabber 1b71:3002, 1f71:3301,
1f71:3306
-zr364xx USB ZR364XX Camera 08ca:0109, 041e:4024,
- 0d64:0108, 0546:3187,
- 0d64:3108, 0595:4343,
- 0bb0:500d, 0feb:2004,
- 055f:b500, 08ca:2062,
- 052b:1a18, 04c8:0729,
- 04f2:a208, 0784:0040,
- 06d6:0034, 0a17:0062,
- 06d6:003b, 0a17:004e,
- 041e:405d, 08ca:2102,
- 06d6:003d
================ ====================================== =====================
diff --git a/Documentation/admin-guide/media/pci-cardlist.rst b/Documentation/admin-guide/media/pci-cardlist.rst
index f4d670e6..42528795d 100644
--- a/Documentation/admin-guide/media/pci-cardlist.rst
+++ b/Documentation/admin-guide/media/pci-cardlist.rst
@@ -77,7 +77,6 @@
ivtv Conexant cx23416/cx23415 MPEG encoder/decoder
ivtvfb Conexant cx23415 framebuffer
mantis MANTIS based cards
-meye Sony Vaio Picturebook Motion Eye
mxb Siemens-Nixdorf 'Multimedia eXtension Board'
netup-unidvb NetUP Universal DVB card
ngene Micronas nGene
diff --git a/Documentation/admin-guide/media/platform-cardlist.rst b/Documentation/admin-guide/media/platform-cardlist.rst
index ac73c41..1230ae4 100644
--- a/Documentation/admin-guide/media/platform-cardlist.rst
+++ b/Documentation/admin-guide/media/platform-cardlist.rst
@@ -30,7 +30,6 @@
exynos-fimc-lite EXYNOS FIMC-LITE camera interface
exynos-gsc Samsung Exynos G-Scaler
exy Samsung S5P/EXYNOS4 SoC series Camera Subsystem
-fsl-viu Freescale VIU
imx-pxp i.MX Pixel Pipeline (PXP)
isdf TI DM365 ISIF video capture
mmp_camera Marvell Armada 610 integrated camera controller
@@ -73,7 +72,6 @@
video-mux Video Multiplexer
vpif_display TI DaVinci VPIF V4L2-Display
vpif_capture TI DaVinci VPIF video capture
-vpss TI DaVinci VPBE V4L2-Display
vsp1 Renesas VSP1 Video Processing Engine
xilinx-tpg Xilinx Video Test Pattern Generator
xilinx-video Xilinx Video IP (EXPERIMENTAL)
diff --git a/Documentation/admin-guide/media/si476x.rst b/Documentation/admin-guide/media/si476x.rst
index 8706230..c8882ee 100644
--- a/Documentation/admin-guide/media/si476x.rst
+++ b/Documentation/admin-guide/media/si476x.rst
@@ -142,7 +142,7 @@
indicator
0x18 lassi Signed Low side adjacent Channel
Strength indicator
- 0x19 hassi ditto fpr High side
+ 0x19 hassi ditto for High side
0x20 mult Multipath indicator
0x21 dev Frequency deviation
0x24 assi Adjacent channel SSI
diff --git a/Documentation/admin-guide/media/tm6000-cardlist.rst b/Documentation/admin-guide/media/tm6000-cardlist.rst
deleted file mode 100644
index 6d2769c..0000000
--- a/Documentation/admin-guide/media/tm6000-cardlist.rst
+++ /dev/null
@@ -1,83 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-TM6000 cards list
-=================
-
-.. tabularcolumns:: |p{1.4cm}|p{11.1cm}|p{4.2cm}|
-
-.. flat-table::
- :header-rows: 1
- :widths: 2 19 18
- :stub-columns: 0
-
- * - Card number
- - Card name
- - USB IDs
-
- * - 0
- - Unknown tm6000 video grabber
- -
-
- * - 1
- - Generic tm5600 board
- - 6000:0001
-
- * - 2
- - Generic tm6000 board
- -
-
- * - 3
- - Generic tm6010 board
- - 6000:0002
-
- * - 4
- - 10Moons UT 821
- -
-
- * - 5
- - 10Moons UT 330
- -
-
- * - 6
- - ADSTECH Dual TV USB
- - 06e1:f332
-
- * - 7
- - Freecom Hybrid Stick / Moka DVB-T Receiver Dual
- - 14aa:0620
-
- * - 8
- - ADSTECH Mini Dual TV USB
- - 06e1:b339
-
- * - 9
- - Hauppauge WinTV HVR-900H / WinTV USB2-Stick
- - 2040:6600, 2040:6601, 2040:6610, 2040:6611
-
- * - 10
- - Beholder Wander DVB-T/TV/FM USB2.0
- - 6000:dec0
-
- * - 11
- - Beholder Voyager TV/FM USB2.0
- - 6000:dec1
-
- * - 12
- - Terratec Cinergy Hybrid XE / Cinergy Hybrid-Stick
- - 0ccd:0086, 0ccd:00A5
-
- * - 13
- - Twinhan TU501(704D1)
- - 13d3:3240, 13d3:3241, 13d3:3243, 13d3:3264
-
- * - 14
- - Beholder Wander Lite DVB-T/TV/FM USB2.0
- - 6000:dec2
-
- * - 15
- - Beholder Voyager Lite TV/FM USB2.0
- - 6000:dec3
-
- * - 16
- - Terratec Grabster AV 150/250 MX
- - 0ccd:0079
diff --git a/Documentation/admin-guide/media/usb-cardlist.rst b/Documentation/admin-guide/media/usb-cardlist.rst
index 1e96f92..5f5ab07 100644
--- a/Documentation/admin-guide/media/usb-cardlist.rst
+++ b/Documentation/admin-guide/media/usb-cardlist.rst
@@ -43,7 +43,6 @@
airspy AirSpy
au0828 Auvitek AU0828
b2c2-flexcop-usb Technisat/B2C2 Air/Sky/Cable2PC USB
-cpia2 CPiA2 Video For Linux
cx231xx Conexant cx231xx USB video capture
dvb-as102 Abilis AS102 DVB receiver
dvb-ttusb-budget Technotrend/Hauppauge Nova - USB devices
@@ -93,15 +92,10 @@
s2250 Sensoray 2250/2251
s2255drv USB Sensoray 2255 video capture device
smsusb Siano SMS1xxx based MDTV receiver
-stkwebcam USB Syntek DC1125 Camera
-tm6000-alsa TV Master TM5600/6000/6010 audio
-tm6000-dvb DVB Support for tm6000 based TV cards
-tm6000 TV Master TM5600/6000/6010 driver
ttusb_dec Technotrend/Hauppauge USB DEC devices
usbtv USBTV007 video capture
uvcvideo USB Video Class (UVC)
zd1301 ZyDAS ZD1301
-zr364xx USB ZR364XX Camera
====================== =========================================================
.. toctree::
@@ -110,7 +104,6 @@
au0828-cardlist
cx231xx-cardlist
em28xx-cardlist
- tm6000-cardlist
siano-cardlist
gspca-cardlist
diff --git a/Documentation/admin-guide/media/v4l-drivers.rst b/Documentation/admin-guide/media/v4l-drivers.rst
index 90a026e..1c41f87 100644
--- a/Documentation/admin-guide/media/v4l-drivers.rst
+++ b/Documentation/admin-guide/media/v4l-drivers.rst
@@ -11,15 +11,12 @@
bttv
cafe_ccic
- cpia2
cx88
- davinci-vpbe
fimc
imx
imx7
ipu3
ivtv
- meye
omap3isp
omap4_camera
philips
diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst
index 672a837..58ac25b 100644
--- a/Documentation/admin-guide/media/vivid.rst
+++ b/Documentation/admin-guide/media/vivid.rst
@@ -580,7 +580,7 @@
----------------
The Metadata capture generates UVC format metadata. The PTS and SCR are
-transmitted based on the values set in vivid contols.
+transmitted based on the values set in vivid controls.
The Metadata device will only work for the Webcam input, it will give
back an error for all other inputs.
diff --git a/Documentation/admin-guide/media/zr364xx.rst b/Documentation/admin-guide/media/zr364xx.rst
deleted file mode 100644
index 7291e54..0000000
--- a/Documentation/admin-guide/media/zr364xx.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-Zoran 364xx based USB webcam module
-===================================
-
-site: http://royale.zerezo.com/zr364xx/
-
-mail: royale@zerezo.com
-
-
-Introduction
-------------
-
-
-This brings support under Linux for the Aiptek PocketDV 3300 and similar
-devices in webcam mode. If you just want to get on your PC the pictures
-and movies on the camera, you should use the usb-storage module instead.
-
-The driver works with several other cameras in webcam mode (see the list
-below).
-
-Possible chipsets are : ZR36430 (ZR36430BGC) and
-maybe ZR36431, ZR36440, ZR36442...
-
-You can try the experience changing the vendor/product ID values (look
-at the source code).
-
-You can get these values by looking at /var/log/messages when you plug
-your camera, or by typing : cat /sys/kernel/debug/usb/devices.
-
-
-Install
--------
-
-In order to use this driver, you must compile it with your kernel,
-with the following config options::
-
- ./scripts/config -e USB
- ./scripts/config -m MEDIA_SUPPORT
- ./scripts/config -e MEDIA_USB_SUPPORT
- ./scripts/config -e MEDIA_CAMERA_SUPPORT
- ./scripts/config -m USB_ZR364XX
-
-Usage
------
-
-modprobe zr364xx debug=X mode=Y
-
-- debug : set to 1 to enable verbose debug messages
-- mode : 0 = 320x240, 1 = 160x120, 2 = 640x480
-
-You can then use the camera with V4L2 compatible applications, for
-example Ekiga.
-
-To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M
-count=1
-
-links
------
-
-http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV)
-http://www.harmwal.nl/pccam880/ (this project also supports cameras based on this chipset)
-
-Supported devices
------------------
-
-====== ======= ============== ====================
-Vendor Product Distributor Model
-====== ======= ============== ====================
-0x08ca 0x0109 Aiptek PocketDV 3300
-0x08ca 0x0109 Maxell Maxcam PRO DV3
-0x041e 0x4024 Creative PC-CAM 880
-0x0d64 0x0108 Aiptek Fidelity 3200
-0x0d64 0x0108 Praktica DCZ 1.3 S
-0x0d64 0x0108 Genius Digital Camera (?)
-0x0d64 0x0108 DXG Technology Fashion Cam
-0x0546 0x3187 Polaroid iON 230
-0x0d64 0x3108 Praktica Exakta DC 2200
-0x0d64 0x3108 Genius G-Shot D211
-0x0595 0x4343 Concord Eye-Q Duo 1300
-0x0595 0x4343 Concord Eye-Q Duo 2000
-0x0595 0x4343 Fujifilm EX-10
-0x0595 0x4343 Ricoh RDC-6000
-0x0595 0x4343 Digitrex DSC 1300
-0x0595 0x4343 Firstline FDC 2000
-0x0bb0 0x500d Concord EyeQ Go Wireless
-0x0feb 0x2004 CRS Electronic 3.3 Digital Camera
-0x0feb 0x2004 Packard Bell DSC-300
-0x055f 0xb500 Mustek MDC 3000
-0x08ca 0x2062 Aiptek PocketDV 5700
-0x052b 0x1a18 Chiphead Megapix V12
-0x04c8 0x0729 Konica Revio 2
-0x04f2 0xa208 Creative PC-CAM 850
-0x0784 0x0040 Traveler Slimline X5
-0x06d6 0x0034 Trust Powerc@m 750
-0x0a17 0x0062 Pentax Optio 50L
-0x06d6 0x003b Trust Powerc@m 970Z
-0x0a17 0x004e Pentax Optio 50
-0x041e 0x405d Creative DiVi CAM 516
-0x08ca 0x2102 Aiptek DV T300
-0x06d6 0x003d Trust Powerc@m 910Z
-====== ======= ============== ====================
diff --git a/Documentation/admin-guide/mm/concepts.rst b/Documentation/admin-guide/mm/concepts.rst
index c79f1e3..e796b0a 100644
--- a/Documentation/admin-guide/mm/concepts.rst
+++ b/Documentation/admin-guide/mm/concepts.rst
@@ -1,5 +1,3 @@
-.. _mm_concepts:
-
=================
Concepts overview
=================
@@ -86,16 +84,15 @@
hugetlbfs. It is a pseudo filesystem that uses RAM as its backing
store. For the files created in this filesystem the data resides in
the memory and mapped using huge pages. The hugetlbfs is described at
-:ref:`Documentation/admin-guide/mm/hugetlbpage.rst <hugetlbpage>`.
+Documentation/admin-guide/mm/hugetlbpage.rst.
Another, more recent, mechanism that enables use of the huge pages is
called `Transparent HugePages`, or THP. Unlike the hugetlbfs that
requires users and/or system administrators to configure what parts of
the system memory should and can be mapped by the huge pages, THP
manages such mappings transparently to the user and hence the
-name. See
-:ref:`Documentation/admin-guide/mm/transhuge.rst <admin_guide_transhuge>`
-for more details about THP.
+name. See Documentation/admin-guide/mm/transhuge.rst for more details
+about THP.
Zones
=====
@@ -125,8 +122,8 @@
constructs an independent memory management subsystem. A node has its
own set of zones, lists of free and used pages and various statistics
counters. You can find more details about NUMA in
-:ref:`Documentation/mm/numa.rst <numa>` and in
-:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`.
+Documentation/mm/numa.rst` and in
+Documentation/admin-guide/mm/numa_memory_policy.rst.
Page cache
==========
diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
index c09cace..7b0775d 100644
--- a/Documentation/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
@@ -54,7 +54,7 @@
To let sysadmins enable or disable it and tune for the given system,
DAMON_LRU_SORT utilizes module parameters. That is, you can put
``damon_lru_sort.<parameter>=<value>`` on the kernel boot command line or write
-proper values to ``/sys/modules/damon_lru_sort/parameters/<parameter>`` files.
+proper values to ``/sys/module/damon_lru_sort/parameters/<parameter>`` files.
Below are the description of each parameter.
@@ -283,7 +283,7 @@
20%, it asks DAMON_LRU_SORT to do nothing again, so that we can fall back to
the LRU-list based page granularity reclamation. ::
- # cd /sys/modules/damon_lru_sort/parameters
+ # cd /sys/module/damon_lru_sort/parameters
# echo 500 > hot_thres_access_freq
# echo 120000000 > cold_min_age
# echo 10 > quota_ms
diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
index 4f1479a..343e25b 100644
--- a/Documentation/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/admin-guide/mm/damon/reclaim.rst
@@ -46,7 +46,7 @@
To let sysadmins enable or disable it and tune for the given system,
DAMON_RECLAIM utilizes module parameters. That is, you can put
``damon_reclaim.<parameter>=<value>`` on the kernel boot command line or write
-proper values to ``/sys/modules/damon_reclaim/parameters/<parameter>`` files.
+proper values to ``/sys/module/damon_reclaim/parameters/<parameter>`` files.
Below are the description of each parameter.
@@ -205,6 +205,15 @@
against. That is, DAMON_RECLAIM will find cold memory regions in this region
and reclaims. By default, biggest System RAM is used as the region.
+skip_anon
+---------
+
+Skip anonymous pages reclamation.
+
+If this parameter is set as ``Y``, DAMON_RECLAIM does not reclaim anonymous
+pages. By default, ``N``.
+
+
kdamond_pid
-----------
@@ -251,7 +260,7 @@
do nothing again, so that we can fall back to the LRU-list based page
granularity reclamation. ::
- # cd /sys/modules/damon_reclaim/parameters
+ # cd /sys/module/damon_reclaim/parameters
# echo 30000000 > min_age
# echo $((1 * 1024 * 1024 * 1024)) > quota_sz
# echo 1000 > quota_reset_interval_ms
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 1a5b6b7..9b823fe 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -25,10 +25,12 @@
interface provides only simple :ref:`statistics <damos_stats>` for the
monitoring results. For detailed monitoring results, DAMON provides a
:ref:`tracepoint <tracepoint>`.
-- *debugfs interface.*
+- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This will be removed after next LTS kernel is released,
- so users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ <sysfs_interface>`. This is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
@@ -87,6 +89,8 @@
│ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
│ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
+ │ │ │ │ │ │ │ filters/nr_filters
+ │ │ │ │ │ │ │ │ 0/type,matching,memcg_id
│ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
│ │ │ │ │ │ │ tried_regions/
│ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age
@@ -151,6 +155,8 @@
moment, only one context per kdamond is supported, so only ``0`` or ``1`` can
be written to the file.
+.. _sysfs_contexts:
+
contexts/<N>/
-------------
@@ -268,21 +274,32 @@
------------
In each scheme directory, five directories (``access_pattern``, ``quotas``,
-``watermarks``, ``stats``, and ``tried_regions``) and one file (``action``)
-exist.
+``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and one file
+(``action``) exist.
The ``action`` file is for setting and getting what action you want to apply to
memory regions having specific access pattern of the interest. The keywords
that can be written to and read from the file and their meaning are as below.
- - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``
- - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``
- - ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
+Note that support of each action depends on the running DAMON operations set
+`implementation <sysfs_contexts>`.
+
+ - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT``.
+ Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set.
+ - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
- ``lru_prio``: Prioritize the region on its LRU lists.
+ Supported by ``paddr`` operations set.
- ``lru_deprio``: Deprioritize the region on its LRU lists.
- - ``stat``: Do nothing but count the statistics
+ Supported by ``paddr`` operations set.
+ - ``stat``: Do nothing but count the statistics.
+ Supported by all operations sets.
schemes/<N>/access_pattern/
---------------------------
@@ -347,6 +364,46 @@
The ``interval`` should written in microseconds unit.
+schemes/<N>/filters/
+--------------------
+
+Users could know something more than the kernel for specific types of memory.
+In the case, users could do their own management for the memory and hence
+doesn't want DAMOS bothers that. Users could limit DAMOS by setting the access
+pattern of the scheme and/or the monitoring regions for the purpose, but that
+can be inefficient in some cases. In such cases, users could set non-access
+pattern driven filters using files in this directory.
+
+In the beginning, this directory has only one file, ``nr_filters``. Writing a
+number (``N``) to the file creates the number of child directories named ``0``
+to ``N-1``. Each directory represents each filter. The filters are evaluated
+in the numeric order.
+
+Each filter directory contains three files, namely ``type``, ``matcing``, and
+``memcg_path``. You can write one of two special keywords, ``anon`` for
+anonymous pages, or ``memcg`` for specific memory cgroup filtering. In case of
+the memory cgroup filtering, you can specify the memory cgroup of the interest
+by writing the path of the memory cgroup from the cgroups mount point to
+``memcg_path`` file. You can write ``Y`` or ``N`` to ``matching`` file to
+filter out pages that does or does not match to the type, respectively. Then,
+the scheme's action will not be applied to the pages that specified to be
+filtered out.
+
+For example, below restricts a DAMOS action to be applied to only non-anonymous
+pages of all memory cgroups except ``/having_care_already``.::
+
+ # echo 2 > nr_filters
+ # # filter out anonymous pages
+ echo anon > 0/type
+ echo Y > 0/matching
+ # # further filter out all cgroups except one at '/having_care_already'
+ echo memcg > 1/type
+ echo /having_care_already > 1/memcg_path
+ echo N > 1/matching
+
+Note that filters are currently supported only when ``paddr``
+`implementation <sysfs_contexts>` is being used.
+
.. _sysfs_schemes_stats:
schemes/<N>/stats/
@@ -432,13 +489,17 @@
.. _debugfs_interface:
-debugfs Interface
-=================
+debugfs Interface (DEPRECATED!)
+===============================
.. note::
- DAMON debugfs interface will be removed after next LTS kernel is released, so
- users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ THIS IS DEPRECATED!
+
+ DAMON debugfs interface is deprecated, so users should move to the
+ :ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
+ move, please report your usecase to damon@lists.linux.dev and
+ linux-mm@kvack.org.
DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
@@ -574,11 +635,15 @@
DAMON will apply to the regions having the target access pattern. The
supported numbers and their meanings are as below.
- - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``
- - 1: Call ``madvise()`` for the region with ``MADV_COLD``
- - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
+ - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``. Ignored if
+ ``target`` is ``paddr``.
+ - 1: Call ``madvise()`` for the region with ``MADV_COLD``. Ignored if
+ ``target`` is ``paddr``.
+ - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT``.
+ - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``. Ignored if
+ ``target`` is ``paddr``.
+ - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``. Ignored if
+ ``target`` is ``paddr``.
- 5: Do nothing but count the statistics
Quota
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst
index 19f27c0..e4d4b4a 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -1,5 +1,3 @@
-.. _hugetlbpage:
-
=============
HugeTLB Pages
=============
@@ -86,7 +84,7 @@
Note: When the feature of freeing unused vmemmap pages associated with each
hugetlb page is enabled, we can fail to free the huge pages triggered by
-the user when ths system is under memory pressure. Please try again later.
+the user when the system is under memory pressure. Please try again later.
Pages that are used as huge pages are reserved inside the kernel and cannot
be used for other purposes. Huge pages cannot be swapped out under
@@ -313,7 +311,7 @@
resulting effect on persistent huge page allocation is as follows:
#. Regardless of mempolicy mode [see
- :ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`],
+ Documentation/admin-guide/mm/numa_memory_policy.rst],
persistent huge pages will be distributed across the node or nodes
specified in the mempolicy as if "interleave" had been specified.
However, if a node in the policy does not contain sufficient contiguous
@@ -461,13 +459,13 @@
.. _map_hugetlb:
``map_hugetlb``
- see tools/testing/selftests/vm/map_hugetlb.c
+ see tools/testing/selftests/mm/map_hugetlb.c
``hugepage-shm``
- see tools/testing/selftests/vm/hugepage-shm.c
+ see tools/testing/selftests/mm/hugepage-shm.c
``hugepage-mmap``
- see tools/testing/selftests/vm/hugepage-mmap.c
+ see tools/testing/selftests/mm/hugepage-mmap.c
The `libhugetlbfs`_ library provides a wide range of userspace tools
to help with huge page usability, environment setup, and control.
diff --git a/Documentation/admin-guide/mm/idle_page_tracking.rst b/Documentation/admin-guide/mm/idle_page_tracking.rst
index df9394f..16fcf38 100644
--- a/Documentation/admin-guide/mm/idle_page_tracking.rst
+++ b/Documentation/admin-guide/mm/idle_page_tracking.rst
@@ -1,5 +1,3 @@
-.. _idle_page_tracking:
-
==================
Idle Page Tracking
==================
@@ -65,14 +63,13 @@
are not reclaimable, he or she can filter them out using
``/proc/kpageflags``.
-The page-types tool in the tools/vm directory can be used to assist in this.
+The page-types tool in the tools/mm directory can be used to assist in this.
If the tool is run initially with the appropriate option, it will mark all the
queried pages as idle. Subsequent runs of the tool can then show which pages have
their idle flag cleared in the interim.
-See :ref:`Documentation/admin-guide/mm/pagemap.rst <pagemap>` for more
-information about ``/proc/pid/pagemap``, ``/proc/kpageflags``, and
-``/proc/kpagecgroup``.
+See Documentation/admin-guide/mm/pagemap.rst for more information about
+``/proc/pid/pagemap``, ``/proc/kpageflags``, and ``/proc/kpagecgroup``.
.. _impl_details:
diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst
index d1064e0..1f883ab 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -16,8 +16,7 @@
.. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html
Linux memory management has its own jargon and if you are not yet
-familiar with it, consider reading
-:ref:`Documentation/admin-guide/mm/concepts.rst <mm_concepts>`.
+familiar with it, consider reading Documentation/admin-guide/mm/concepts.rst.
Here we document in detail how to interact with various mechanisms in
the Linux memory management.
diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index fb6ba20..eed51a91 100644
--- a/Documentation/admin-guide/mm/ksm.rst
+++ b/Documentation/admin-guide/mm/ksm.rst
@@ -1,5 +1,3 @@
-.. _admin_guide_ksm:
-
=======================
Kernel Samepage Merging
=======================
diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst
index a3c9e8a..1b02fe5 100644
--- a/Documentation/admin-guide/mm/memory-hotplug.rst
+++ b/Documentation/admin-guide/mm/memory-hotplug.rst
@@ -1,5 +1,3 @@
-.. _admin_guide_memory_hotplug:
-
==================
Memory Hot(Un)Plug
==================
diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst
index 5a6afec..46515ad 100644
--- a/Documentation/admin-guide/mm/numa_memory_policy.rst
+++ b/Documentation/admin-guide/mm/numa_memory_policy.rst
@@ -1,5 +1,3 @@
-.. _numa_memory_policy:
-
==================
NUMA Memory Policy
==================
@@ -246,7 +244,7 @@
interleaved system default policy works in this mode.
MPOL_PREFERRED_MANY
- This mode specifices that the allocation should be preferrably
+ This mode specifies that the allocation should be preferably
satisfied from the nodemask specified in the policy. If there is
a memory pressure on all nodes in the nodemask, the allocation
can fall back to all existing numa nodes. This is effectively
@@ -360,7 +358,7 @@
2) examination of the policy to determine the policy mode and associated node
or node lists, if any, for page allocation. This is considered a "hot
path". Note that for MPOL_BIND, the "usage" extends across the entire
- allocation process, which may sleep during page reclaimation, because the
+ allocation process, which may sleep during page reclamation, because the
BIND policy nodemask is used, by reference, to filter ineligible nodes.
We can avoid taking an extra reference during the usages listed above as
diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
index 1666973..90a12b6 100644
--- a/Documentation/admin-guide/mm/numaperf.rst
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -1,6 +1,7 @@
-.. _numaperf:
+=======================
+NUMA Memory Performance
+=======================
-=============
NUMA Locality
=============
@@ -61,7 +62,6 @@
IO initiators such as GPUs and NICs. Unlike access class 0, only
nodes containing CPUs are considered.
-================
NUMA Performance
================
@@ -96,7 +96,6 @@
Access class 1 takes the same form but only includes values for CPU to
memory activity.
-==========
NUMA Cache
==========
@@ -170,7 +169,6 @@
The "write_policy" will be 0 for write-back, and non-zero for
write-through caching.
-========
See Also
========
diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
index 6e2e416..b5f970d 100644
--- a/Documentation/admin-guide/mm/pagemap.rst
+++ b/Documentation/admin-guide/mm/pagemap.rst
@@ -1,5 +1,3 @@
-.. _pagemap:
-
=============================
Examining Process Page Tables
=============================
@@ -19,10 +17,10 @@
* Bits 0-4 swap type if swapped
* Bits 5-54 swap offset if swapped
* Bit 55 pte is soft-dirty (see
- :ref:`Documentation/admin-guide/mm/soft-dirty.rst <soft_dirty>`)
+ Documentation/admin-guide/mm/soft-dirty.rst)
* Bit 56 page exclusively mapped (since 4.2)
* Bit 57 pte is uffd-wp write-protected (since 5.13) (see
- :ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`)
+ Documentation/admin-guide/mm/userfaultfd.rst)
* Bits 58-60 zero
* Bit 61 page is file-page or shared-anon (since 3.5)
* Bit 62 page swapped
@@ -46,7 +44,7 @@
* ``/proc/kpagecount``. This file contains a 64-bit count of the number of
times each page is mapped, indexed by PFN.
-The page-types tool in the tools/vm directory can be used to query the
+The page-types tool in the tools/mm directory can be used to query the
number of times a page is mapped.
* ``/proc/kpageflags``. This file contains a 64-bit set of flags for each
@@ -105,8 +103,7 @@
A compound page with order N consists of 2^N physically contiguous pages.
A compound page with order 2 takes the form of "HTTT", where H donates its
head page and T donates its tail page(s). The major consumers of compound
- pages are hugeTLB pages
- (:ref:`Documentation/admin-guide/mm/hugetlbpage.rst <hugetlbpage>`),
+ pages are hugeTLB pages (Documentation/admin-guide/mm/hugetlbpage.rst),
the SLUB etc. memory allocators and various device drivers.
However in this interface, only huge/giga pages are made visible
to end users.
@@ -128,7 +125,7 @@
Zero page for pfn_zero or huge_zero page.
25 - IDLE
The page has not been accessed since it was marked idle (see
- :ref:`Documentation/admin-guide/mm/idle_page_tracking.rst <idle_page_tracking>`).
+ Documentation/admin-guide/mm/idle_page_tracking.rst).
Note that this flag may be stale in case the page was accessed via
a PTE. To make sure the flag is up-to-date one has to read
``/sys/kernel/mm/page_idle/bitmap`` first.
@@ -173,7 +170,7 @@
14 - SWAPBACKED
The page is backed by swap/RAM.
-The page-types tool in the tools/vm directory can be used to query the
+The page-types tool in the tools/mm directory can be used to query the
above flags.
Using pagemap to do something useful
diff --git a/Documentation/admin-guide/mm/shrinker_debugfs.rst b/Documentation/admin-guide/mm/shrinker_debugfs.rst
index 3887f0b..c582033 100644
--- a/Documentation/admin-guide/mm/shrinker_debugfs.rst
+++ b/Documentation/admin-guide/mm/shrinker_debugfs.rst
@@ -1,5 +1,3 @@
-.. _shrinker_debugfs:
-
==========================
Shrinker Debugfs Interface
==========================
diff --git a/Documentation/admin-guide/mm/soft-dirty.rst b/Documentation/admin-guide/mm/soft-dirty.rst
index cb0cfd6..aeea936 100644
--- a/Documentation/admin-guide/mm/soft-dirty.rst
+++ b/Documentation/admin-guide/mm/soft-dirty.rst
@@ -1,5 +1,3 @@
-.. _soft_dirty:
-
===============
Soft-Dirty PTEs
===============
diff --git a/Documentation/admin-guide/mm/swap_numa.rst b/Documentation/admin-guide/mm/swap_numa.rst
index e0466f2..2e63062 100644
--- a/Documentation/admin-guide/mm/swap_numa.rst
+++ b/Documentation/admin-guide/mm/swap_numa.rst
@@ -1,5 +1,3 @@
-.. _swap_numa:
-
===========================================
Automatically bind swap device to numa node
===========================================
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index 8ee78ec..b0cc824 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -1,5 +1,3 @@
-.. _admin_guide_transhuge:
-
============================
Transparent Hugepage Support
============================
diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
index 83f3191..7dc823b 100644
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -1,5 +1,3 @@
-.. _userfaultfd:
-
===========
Userfaultfd
===========
diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst
index 6dd74a1..c5c2c7d 100644
--- a/Documentation/admin-guide/mm/zswap.rst
+++ b/Documentation/admin-guide/mm/zswap.rst
@@ -1,5 +1,3 @@
-.. _zswap:
-
=====
zswap
=====
diff --git a/Documentation/admin-guide/perf/hns3-pmu.rst b/Documentation/admin-guide/perf/hns3-pmu.rst
index 578407e..75a4084 100644
--- a/Documentation/admin-guide/perf/hns3-pmu.rst
+++ b/Documentation/admin-guide/perf/hns3-pmu.rst
@@ -53,7 +53,7 @@
event pair. And the bit 16 of config indicates getting counter 0 or
counter 1 of hardware event.
-After getting two values of event pair in usersapce, the formula of
+After getting two values of event pair in userspace, the formula of
computation to calculate real performance data is:::
counter 0 / counter 1
diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst
index 5376d53f..6e5298b 100644
--- a/Documentation/admin-guide/pm/amd-pstate.rst
+++ b/Documentation/admin-guide/pm/amd-pstate.rst
@@ -230,8 +230,8 @@
to the request from AMD P-States.
-User Space Interface in ``sysfs``
-==================================
+User Space Interface in ``sysfs`` - Per-policy control
+======================================================
``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to
control its functionality at the system level. They are located in the
@@ -262,6 +262,25 @@
<perf_cap_>`_.)
This attribute is read-only.
+``energy_performance_available_preferences``
+
+A list of all the supported EPP preferences that could be used for
+``energy_performance_preference`` on this system.
+These profiles represent different hints that are provided
+to the low-level firmware about the user's desired energy vs efficiency
+tradeoff. ``default`` represents the epp value is set by platform
+firmware. This attribute is read-only.
+
+``energy_performance_preference``
+
+The current energy performance preference can be read from this attribute.
+and user can change current preference according to energy or performance needs
+Please get all support profiles list from
+``energy_performance_available_preferences`` attribute, all the profiles are
+integer values defined between 0 to 255 when EPP feature is enabled by platform
+firmware, if EPP feature is disabled, driver will ignore the written value
+This attribute is read-write.
+
Other performance and frequency values can be read back from
``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`.
@@ -280,8 +299,30 @@
platforms. The AMD P-States mechanism is the more performance and energy
efficiency frequency management method on AMD processors.
-Kernel Module Options for ``amd-pstate``
-=========================================
+
+AMD Pstate Driver Operation Modes
+=================================
+
+``amd_pstate`` CPPC has two operation modes: CPPC Autonomous(active) mode and
+CPPC non-autonomous(passive) mode.
+active mode and passive mode can be chosen by different kernel parameters.
+When in Autonomous mode, CPPC ignores requests done in the Desired Performance
+Target register and takes into account only the values set to the Minimum requested
+performance, Maximum requested performance, and Energy Performance Preference
+registers. When Autonomous is disabled, it only considers the Desired Performance Target.
+
+Active Mode
+------------
+
+``amd_pstate=active``
+
+This is the low-level firmware control mode which is implemented by ``amd_pstate_epp``
+driver with ``amd_pstate=active`` passed to the kernel in the command line.
+In this mode, ``amd_pstate_epp`` driver provides a hint to the hardware if software
+wants to bias toward performance (0x0) or energy efficiency (0xff) to the CPPC firmware.
+then CPPC power algorithm will calculate the runtime workload and adjust the realtime
+cores frequency according to the power supply and thermal, core voltage and some other
+hardware conditions.
Passive Mode
------------
@@ -298,6 +339,35 @@
operating conditions allow.
+User Space Interface in ``sysfs`` - General
+===========================================
+
+Global Attributes
+-----------------
+
+``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to
+control its functionality at the system level. They are located in the
+``/sys/devices/system/cpu/amd-pstate/`` directory and affect all CPUs.
+
+``status``
+ Operation mode of the driver: "active", "passive" or "disable".
+
+ "active"
+ The driver is functional and in the ``active mode``
+
+ "passive"
+ The driver is functional and in the ``passive mode``
+
+ "disable"
+ The driver is unregistered and not functional now.
+
+ This attribute can be written to in order to change the driver's
+ operation mode or to unregister it. The string written to it must be
+ one of the possible values of it and, if successful, writing one of
+ these values to the sysfs file will cause the driver to switch over
+ to the operation mode represented by that string - or to be
+ unregistered in the "disable" case.
+
``cpupower`` tool support for ``amd-pstate``
===============================================
@@ -403,7 +473,7 @@
* We can introduce more functional or performance tests to align the result together, it will benefit power and performance scale optimization.
-1. Test case decriptions
+1. Test case descriptions
1). Basic tests
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst
index d5043cd..bf13ad2 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -712,7 +712,7 @@
The following sequence of shell commands can be used to enable them and see
their output (if the kernel is generally configured to support event tracing)::
- # cd /sys/kernel/debug/tracing/
+ # cd /sys/kernel/tracing/
# echo 1 > events/power/pstate_sample/enable
# echo 1 > events/power/cpu_frequency/enable
# cat trace
@@ -732,7 +732,7 @@
P-state is called, the ``ftrace`` filter can be set to
:c:func:`intel_pstate_set_pstate`::
- # cd /sys/kernel/debug/tracing/
+ # cd /sys/kernel/tracing/
# cat available_filter_functions | grep -i pstate
intel_pstate_set_pstate
intel_pstate_cpu_init
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index ec62151..2fd5a03 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -395,7 +395,7 @@
list of tracked regressions, to ensure it won't fall through the cracks.
What qualifies as security issue is left to your judgment. Consider reading
-Documentation/admin-guide/security-bugs.rst before proceeding, as it
+Documentation/process/security-bugs.rst before proceeding, as it
provides additional details how to best handle security issues.
An issue is a 'really severe problem' when something totally unacceptably bad
@@ -1269,7 +1269,7 @@
the report's text to these addresses; but on top of it put a small note where
you mention that you filed it with a link to the ticket.
-See Documentation/admin-guide/security-bugs.rst for more information.
+See Documentation/process/security-bugs.rst for more information.
Duties after the report went out
diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt
index 1265c1e..74ea7f3 100644
--- a/Documentation/admin-guide/spkguide.txt
+++ b/Documentation/admin-guide/spkguide.txt
@@ -1105,8 +1105,8 @@
Alternatively, you can add the above line to your file
~/.bashrc or ~/.bash_profile.
-If your system administrator ran himself the script, all the users will be able
-to change from English to the language choosed by root and do directly
+If your system administrator himself ran the script, all the users will be able
+to change from English to the language chosen by root and do directly
speakupconf load (or add this to the ~/.bashrc or
~/.bash_profile file). If there are several languages to handle, the
administrator (or every user) will have to run the first steps until speakupconf
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 46e3d62..4b7bfea 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -453,9 +453,10 @@
kexec_load_disabled
===================
-A toggle indicating if the ``kexec_load`` syscall has been disabled.
-This value defaults to 0 (false: ``kexec_load`` enabled), but can be
-set to 1 (true: ``kexec_load`` disabled).
+A toggle indicating if the syscalls ``kexec_load`` and
+``kexec_file_load`` have been disabled.
+This value defaults to 0 (false: ``kexec_*load`` enabled), but can be
+set to 1 (true: ``kexec_*load`` disabled).
Once true, kexec can no longer be used, and the toggle cannot be set
back to false.
This allows a kexec image to be loaded before disabling the syscall,
@@ -463,6 +464,24 @@
altered.
Generally used together with the `modules_disabled`_ sysctl.
+kexec_load_limit_panic
+======================
+
+This parameter specifies a limit to the number of times the syscalls
+``kexec_load`` and ``kexec_file_load`` can be called with a crash
+image. It can only be set with a more restrictive value than the
+current one.
+
+== ======================================================
+-1 Unlimited calls to kexec. This is the default setting.
+N Number of calls left.
+== ======================================================
+
+kexec_load_limit_reboot
+=======================
+
+Similar functionality as ``kexec_load_limit_panic``, but for a normal
+image.
kptr_restrict
=============
diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
index 6394f5d..466c560 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -215,6 +215,12 @@
The maximum receive socket buffer size in bytes.
+rps_default_mask
+----------------
+
+The default RPS CPU mask used on newly created network devices. An empty
+mask means RPS disabled by default.
+
tstamp_allow_data
-----------------
Allow processes to receive tx timestamps looped together with the original
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 988f6a4..45ba1f4 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -356,7 +356,7 @@
But, these values are not used directly. The kernel calculates # of protection
pages for each zones from them. These are shown as array of protection pages
-in /proc/zoneinfo like followings. (This is an example of x86-64 box).
+in /proc/zoneinfo like the following. (This is an example of x86-64 box).
Each zone has an array of protection pages like this::
Node 0, zone DMA
@@ -433,7 +433,7 @@
that cannot be handled by the kernel. In some cases (like the page
still having a valid copy on disk) the kernel will handle the failure
transparently without affecting any applications. But if there is
-no other uptodate copy of the data it will kill to prevent any data
+no other up-to-date copy of the data it will kill to prevent any data
corruptions from propagating.
1: Kill all processes that have the corrupted and not reloadable page mapped
diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/sysrq.rst
index 0a178ef..51906e47 100644
--- a/Documentation/admin-guide/sysrq.rst
+++ b/Documentation/admin-guide/sysrq.rst
@@ -138,7 +138,7 @@
``v`` Forcefully restores framebuffer console
``v`` Causes ETM buffer dump [ARM-specific]
-``w`` Dumps tasks that are in uninterruptable (blocked) state.
+``w`` Dumps tasks that are in uninterruptible (blocked) state.
``x`` Used by xmon interface on ppc/powerpc platforms.
Show global PMU Registers on sparc64.
diff --git a/Documentation/admin-guide/thermal/index.rst b/Documentation/admin-guide/thermal/index.rst
new file mode 100644
index 0000000..193b7b0
--- /dev/null
+++ b/Documentation/admin-guide/thermal/index.rst
@@ -0,0 +1,8 @@
+=================
+Thermal Subsystem
+=================
+
+.. toctree::
+ :maxdepth: 1
+
+ intel_powerclamp
diff --git a/Documentation/admin-guide/thermal/intel_powerclamp.rst b/Documentation/admin-guide/thermal/intel_powerclamp.rst
new file mode 100644
index 0000000..08509b9
--- /dev/null
+++ b/Documentation/admin-guide/thermal/intel_powerclamp.rst
@@ -0,0 +1,345 @@
+=======================
+Intel Powerclamp Driver
+=======================
+
+By:
+ - Arjan van de Ven <arjan@linux.intel.com>
+ - Jacob Pan <jacob.jun.pan@linux.intel.com>
+
+.. Contents:
+
+ (*) Introduction
+ - Goals and Objectives
+
+ (*) Theory of Operation
+ - Idle Injection
+ - Calibration
+
+ (*) Performance Analysis
+ - Effectiveness and Limitations
+ - Power vs Performance
+ - Scalability
+ - Calibration
+ - Comparison with Alternative Techniques
+
+ (*) Usage and Interfaces
+ - Generic Thermal Layer (sysfs)
+ - Kernel APIs (TBD)
+
+ (*) Module Parameters
+
+INTRODUCTION
+============
+
+Consider the situation where a system’s power consumption must be
+reduced at runtime, due to power budget, thermal constraint, or noise
+level, and where active cooling is not preferred. Software managed
+passive power reduction must be performed to prevent the hardware
+actions that are designed for catastrophic scenarios.
+
+Currently, P-states, T-states (clock modulation), and CPU offlining
+are used for CPU throttling.
+
+On Intel CPUs, C-states provide effective power reduction, but so far
+they’re only used opportunistically, based on workload. With the
+development of intel_powerclamp driver, the method of synchronizing
+idle injection across all online CPU threads was introduced. The goal
+is to achieve forced and controllable C-state residency.
+
+Test/Analysis has been made in the areas of power, performance,
+scalability, and user experience. In many cases, clear advantage is
+shown over taking the CPU offline or modulating the CPU clock.
+
+
+THEORY OF OPERATION
+===================
+
+Idle Injection
+--------------
+
+On modern Intel processors (Nehalem or later), package level C-state
+residency is available in MSRs, thus also available to the kernel.
+
+These MSRs are::
+
+ #define MSR_PKG_C2_RESIDENCY 0x60D
+ #define MSR_PKG_C3_RESIDENCY 0x3F8
+ #define MSR_PKG_C6_RESIDENCY 0x3F9
+ #define MSR_PKG_C7_RESIDENCY 0x3FA
+
+If the kernel can also inject idle time to the system, then a
+closed-loop control system can be established that manages package
+level C-state. The intel_powerclamp driver is conceived as such a
+control system, where the target set point is a user-selected idle
+ratio (based on power reduction), and the error is the difference
+between the actual package level C-state residency ratio and the target idle
+ratio.
+
+Injection is controlled by high priority kernel threads, spawned for
+each online CPU.
+
+These kernel threads, with SCHED_FIFO class, are created to perform
+clamping actions of controlled duty ratio and duration. Each per-CPU
+thread synchronizes its idle time and duration, based on the rounding
+of jiffies, so accumulated errors can be prevented to avoid a jittery
+effect. Threads are also bound to the CPU such that they cannot be
+migrated, unless the CPU is taken offline. In this case, threads
+belong to the offlined CPUs will be terminated immediately.
+
+Running as SCHED_FIFO and relatively high priority, also allows such
+scheme to work for both preemptible and non-preemptible kernels.
+Alignment of idle time around jiffies ensures scalability for HZ
+values. This effect can be better visualized using a Perf timechart.
+The following diagram shows the behavior of kernel thread
+kidle_inject/cpu. During idle injection, it runs monitor/mwait idle
+for a given "duration", then relinquishes the CPU to other tasks,
+until the next time interval.
+
+The NOHZ schedule tick is disabled during idle time, but interrupts
+are not masked. Tests show that the extra wakeups from scheduler tick
+have a dramatic impact on the effectiveness of the powerclamp driver
+on large scale systems (Westmere system with 80 processors).
+
+::
+
+ CPU0
+ ____________ ____________
+ kidle_inject/0 | sleep | mwait | sleep |
+ _________| |________| |_______
+ duration
+ CPU1
+ ____________ ____________
+ kidle_inject/1 | sleep | mwait | sleep |
+ _________| |________| |_______
+ ^
+ |
+ |
+ roundup(jiffies, interval)
+
+Only one CPU is allowed to collect statistics and update global
+control parameters. This CPU is referred to as the controlling CPU in
+this document. The controlling CPU is elected at runtime, with a
+policy that favors BSP, taking into account the possibility of a CPU
+hot-plug.
+
+In terms of dynamics of the idle control system, package level idle
+time is considered largely as a non-causal system where its behavior
+cannot be based on the past or current input. Therefore, the
+intel_powerclamp driver attempts to enforce the desired idle time
+instantly as given input (target idle ratio). After injection,
+powerclamp monitors the actual idle for a given time window and adjust
+the next injection accordingly to avoid over/under correction.
+
+When used in a causal control system, such as a temperature control,
+it is up to the user of this driver to implement algorithms where
+past samples and outputs are included in the feedback. For example, a
+PID-based thermal controller can use the powerclamp driver to
+maintain a desired target temperature, based on integral and
+derivative gains of the past samples.
+
+
+
+Calibration
+-----------
+During scalability testing, it is observed that synchronized actions
+among CPUs become challenging as the number of cores grows. This is
+also true for the ability of a system to enter package level C-states.
+
+To make sure the intel_powerclamp driver scales well, online
+calibration is implemented. The goals for doing such a calibration
+are:
+
+a) determine the effective range of idle injection ratio
+b) determine the amount of compensation needed at each target ratio
+
+Compensation to each target ratio consists of two parts:
+
+ a) steady state error compensation
+
+ This is to offset the error occurring when the system can
+ enter idle without extra wakeups (such as external interrupts).
+
+ b) dynamic error compensation
+
+ When an excessive amount of wakeups occurs during idle, an
+ additional idle ratio can be added to quiet interrupts, by
+ slowing down CPU activities.
+
+A debugfs file is provided for the user to examine compensation
+progress and results, such as on a Westmere system::
+
+ [jacob@nex01 ~]$ cat
+ /sys/kernel/debug/intel_powerclamp/powerclamp_calib
+ controlling cpu: 0
+ pct confidence steady dynamic (compensation)
+ 0 0 0 0
+ 1 1 0 0
+ 2 1 1 0
+ 3 3 1 0
+ 4 3 1 0
+ 5 3 1 0
+ 6 3 1 0
+ 7 3 1 0
+ 8 3 1 0
+ ...
+ 30 3 2 0
+ 31 3 2 0
+ 32 3 1 0
+ 33 3 2 0
+ 34 3 1 0
+ 35 3 2 0
+ 36 3 1 0
+ 37 3 2 0
+ 38 3 1 0
+ 39 3 2 0
+ 40 3 3 0
+ 41 3 1 0
+ 42 3 2 0
+ 43 3 1 0
+ 44 3 1 0
+ 45 3 2 0
+ 46 3 3 0
+ 47 3 0 0
+ 48 3 2 0
+ 49 3 3 0
+
+Calibration occurs during runtime. No offline method is available.
+Steady state compensation is used only when confidence levels of all
+adjacent ratios have reached satisfactory level. A confidence level
+is accumulated based on clean data collected at runtime. Data
+collected during a period without extra interrupts is considered
+clean.
+
+To compensate for excessive amounts of wakeup during idle, additional
+idle time is injected when such a condition is detected. Currently,
+we have a simple algorithm to double the injection ratio. A possible
+enhancement might be to throttle the offending IRQ, such as delaying
+EOI for level triggered interrupts. But it is a challenge to be
+non-intrusive to the scheduler or the IRQ core code.
+
+
+CPU Online/Offline
+------------------
+Per-CPU kernel threads are started/stopped upon receiving
+notifications of CPU hotplug activities. The intel_powerclamp driver
+keeps track of clamping kernel threads, even after they are migrated
+to other CPUs, after a CPU offline event.
+
+
+Performance Analysis
+====================
+This section describes the general performance data collected on
+multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P).
+
+Effectiveness and Limitations
+-----------------------------
+The maximum range that idle injection is allowed is capped at 50
+percent. As mentioned earlier, since interrupts are allowed during
+forced idle time, excessive interrupts could result in less
+effectiveness. The extreme case would be doing a ping -f to generated
+flooded network interrupts without much CPU acknowledgement. In this
+case, little can be done from the idle injection threads. In most
+normal cases, such as scp a large file, applications can be throttled
+by the powerclamp driver, since slowing down the CPU also slows down
+network protocol processing, which in turn reduces interrupts.
+
+When control parameters change at runtime by the controlling CPU, it
+may take an additional period for the rest of the CPUs to catch up
+with the changes. During this time, idle injection is out of sync,
+thus not able to enter package C- states at the expected ratio. But
+this effect is minor, in that in most cases change to the target
+ratio is updated much less frequently than the idle injection
+frequency.
+
+Scalability
+-----------
+Tests also show a minor, but measurable, difference between the 4P/8P
+Ivy Bridge system and the 80P Westmere server under 50% idle ratio.
+More compensation is needed on Westmere for the same amount of
+target idle ratio. The compensation also increases as the idle ratio
+gets larger. The above reason constitutes the need for the
+calibration code.
+
+On the IVB 8P system, compared to an offline CPU, powerclamp can
+achieve up to 40% better performance per watt. (measured by a spin
+counter summed over per CPU counting threads spawned for all running
+CPUs).
+
+Usage and Interfaces
+====================
+The powerclamp driver is registered to the generic thermal layer as a
+cooling device. Currently, it’s not bound to any thermal zones::
+
+ jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
+ cur_state:0
+ max_state:50
+ type:intel_powerclamp
+
+cur_state allows user to set the desired idle percentage. Writing 0 to
+cur_state will stop idle injection. Writing a value between 1 and
+max_state will start the idle injection. Reading cur_state returns the
+actual and current idle percentage. This may not be the same value
+set by the user in that current idle percentage depends on workload
+and includes natural idle. When idle injection is disabled, reading
+cur_state returns value -1 instead of 0 which is to avoid confusing
+100% busy state with the disabled state.
+
+Example usage:
+
+- To inject 25% idle time::
+
+ $ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
+
+If the system is not busy and has more than 25% idle time already,
+then the powerclamp driver will not start idle injection. Using Top
+will not show idle injection kernel threads.
+
+If the system is busy (spin test below) and has less than 25% natural
+idle time, powerclamp kernel threads will do idle injection. Forced
+idle time is accounted as normal idle in that common code path is
+taken as the idle task.
+
+In this example, 24.1% idle is shown. This helps the system admin or
+user determine the cause of slowdown, when a powerclamp driver is in action::
+
+
+ Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie
+ Cpu(s): 71.2%us, 4.7%sy, 0.0%ni, 24.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
+ Mem: 3943228k total, 1689632k used, 2253596k free, 74960k buffers
+ Swap: 4087804k total, 0k used, 4087804k free, 945336k cached
+
+ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
+ 3352 jacob 20 0 262m 644 428 S 286 0.0 0:17.16 spin
+ 3341 root -51 0 0 0 0 D 25 0.0 0:01.62 kidle_inject/0
+ 3344 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/3
+ 3342 root -51 0 0 0 0 D 25 0.0 0:01.61 kidle_inject/1
+ 3343 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/2
+ 2935 jacob 20 0 696m 125m 35m S 5 3.3 0:31.11 firefox
+ 1546 root 20 0 158m 20m 6640 S 3 0.5 0:26.97 Xorg
+ 2100 jacob 20 0 1223m 88m 30m S 3 2.3 0:23.68 compiz
+
+Tests have shown that by using the powerclamp driver as a cooling
+device, a PID based userspace thermal controller can manage to
+control CPU temperature effectively, when no other thermal influence
+is added. For example, a UltraBook user can compile the kernel under
+certain temperature (below most active trip points).
+
+Module Parameters
+=================
+
+``cpumask`` (RW)
+ A bit mask of CPUs to inject idle. The format of the bitmask is same as
+ used in other subsystems like in /proc/irq/\*/smp_affinity. The mask is
+ comma separated 32 bit groups. Each CPU is one bit. For example for a 256
+ CPU system the full mask is:
+ ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
+
+ The rightmost mask is for CPU 0-32.
+
+``max_idle`` (RW)
+ Maximum injected idle time to the total CPU time ratio in percent range
+ from 1 to 100. Even if the cooling device max_state is always 100 (100%),
+ this parameter allows to add a max idle percent limit. The default is 50,
+ to match the current implementation of powerclamp driver. Also doesn't
+ allow value more than 75, if the cpumask includes every CPU present in
+ the system.
diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst
new file mode 100644
index 0000000..b2e254e
--- /dev/null
+++ b/Documentation/admin-guide/workload-tracing.rst
@@ -0,0 +1,606 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+
+======================================================
+Discovering Linux kernel subsystems used by a workload
+======================================================
+
+:Authors: - Shuah Khan <skhan@linuxfoundation.org>
+ - Shefali Sharma <sshefali021@gmail.com>
+:maintained-by: Shuah Khan <skhan@linuxfoundation.org>
+
+Key Points
+==========
+
+ * Understanding system resources necessary to build and run a workload
+ is important.
+ * Linux tracing and strace can be used to discover the system resources
+ in use by a workload. The completeness of the system usage information
+ depends on the completeness of coverage of a workload.
+ * Performance and security of the operating system can be analyzed with
+ the help of tools such as:
+ `perf <https://man7.org/linux/man-pages/man1/perf.1.html>`_,
+ `stress-ng <https://www.mankier.com/1/stress-ng>`_,
+ `paxtest <https://github.com/opntr/paxtest-freebsd>`_.
+ * Once we discover and understand the workload needs, we can focus on them
+ to avoid regressions and use it to evaluate safety considerations.
+
+Methodology
+===========
+
+`strace <https://man7.org/linux/man-pages/man1/strace.1.html>`_ is a
+diagnostic, instructional, and debugging tool and can be used to discover
+the system resources in use by a workload. Once we discover and understand
+the workload needs, we can focus on them to avoid regressions and use it
+to evaluate safety considerations. We use strace tool to trace workloads.
+
+This method of tracing using strace tells us the system calls invoked by
+the workload and doesn't include all the system calls that can be invoked
+by it. In addition, this tracing method tells us just the code paths within
+these system calls that are invoked. As an example, if a workload opens a
+file and reads from it successfully, then the success path is the one that
+is traced. Any error paths in that system call will not be traced. If there
+is a workload that provides full coverage of a workload then the method
+outlined here will trace and find all possible code paths. The completeness
+of the system usage information depends on the completeness of coverage of a
+workload.
+
+The goal is tracing a workload on a system running a default kernel without
+requiring custom kernel installs.
+
+How do we gather fine-grained system information?
+=================================================
+
+strace tool can be used to trace system calls made by a process and signals
+it receives. System calls are the fundamental interface between an
+application and the operating system kernel. They enable a program to
+request services from the kernel. For instance, the open() system call in
+Linux is used to provide access to a file in the file system. strace enables
+us to track all the system calls made by an application. It lists all the
+system calls made by a process and their resulting output.
+
+You can generate profiling data combining strace and perf record tools to
+record the events and information associated with a process. This provides
+insight into the process. "perf annotate" tool generates the statistics of
+each instruction of the program. This document goes over the details of how
+to gather fine-grained information on a workload's usage of system resources.
+
+We used strace to trace the perf, stress-ng, paxtest workloads to illustrate
+our methodology to discover resources used by a workload. This process can
+be applied to trace other workloads.
+
+Getting the system ready for tracing
+====================================
+
+Before we can get started we will show you how to get your system ready.
+We assume that you have a Linux distribution running on a physical system
+or a virtual machine. Most distributions will include strace command. Let’s
+install other tools that aren’t usually included to build Linux kernel.
+Please note that the following works on Debian based distributions. You
+might have to find equivalent packages on other Linux distributions.
+
+Install tools to build Linux kernel and tools in kernel repository.
+scripts/ver_linux is a good way to check if your system already has
+the necessary tools::
+
+ sudo apt-get build-essentials flex bison yacc
+ sudo apt install libelf-dev systemtap-sdt-dev libaudit-dev libslang2-dev libperl-dev libdw-dev
+
+cscope is a good tool to browse kernel sources. Let's install it now::
+
+ sudo apt-get install cscope
+
+Install stress-ng and paxtest::
+
+ apt-get install stress-ng
+ apt-get install paxtest
+
+Workload overview
+=================
+
+As mentioned earlier, we used strace to trace perf bench, stress-ng and
+paxtest workloads to show how to analyze a workload and identify Linux
+subsystems used by these workloads. Let's start with an overview of these
+three workloads to get a better understanding of what they do and how to
+use them.
+
+perf bench (all) workload
+-------------------------
+
+The perf bench command contains multiple multi-threaded microkernel
+benchmarks for executing different subsystems in the Linux kernel and
+system calls. This allows us to easily measure the impact of changes,
+which can help mitigate performance regressions. It also acts as a common
+benchmarking framework, enabling developers to easily create test cases,
+integrate transparently, and use performance-rich tooling subsystems.
+
+Stress-ng netdev stressor workload
+----------------------------------
+
+stress-ng is used for performing stress testing on the kernel. It allows
+you to exercise various physical subsystems of the computer, as well as
+interfaces of the OS kernel, using "stressor-s". They are available for
+CPU, CPU cache, devices, I/O, interrupts, file system, memory, network,
+operating system, pipelines, schedulers, and virtual machines. Please refer
+to the `stress-ng man-page <https://www.mankier.com/1/stress-ng>`_ to
+find the description of all the available stressor-s. The netdev stressor
+starts specified number (N) of workers that exercise various netdevice
+ioctl commands across all the available network devices.
+
+paxtest kiddie workload
+-----------------------
+
+paxtest is a program that tests buffer overflows in the kernel. It tests
+kernel enforcements over memory usage. Generally, execution in some memory
+segments makes buffer overflows possible. It runs a set of programs that
+attempt to subvert memory usage. It is used as a regression test suite for
+PaX, but might be useful to test other memory protection patches for the
+kernel. We used paxtest kiddie mode which looks for simple vulnerabilities.
+
+What is strace and how do we use it?
+====================================
+
+As mentioned earlier, strace which is a useful diagnostic, instructional,
+and debugging tool and can be used to discover the system resources in use
+by a workload. It can be used:
+
+ * To see how a process interacts with the kernel.
+ * To see why a process is failing or hanging.
+ * For reverse engineering a process.
+ * To find the files on which a program depends.
+ * For analyzing the performance of an application.
+ * For troubleshooting various problems related to the operating system.
+
+In addition, strace can generate run-time statistics on times, calls, and
+errors for each system call and report a summary when program exits,
+suppressing the regular output. This attempts to show system time (CPU time
+spent running in the kernel) independent of wall clock time. We plan to use
+these features to get information on workload system usage.
+
+strace command supports basic, verbose, and stats modes. strace command when
+run in verbose mode gives more detailed information about the system calls
+invoked by a process.
+
+Running strace -c generates a report of the percentage of time spent in each
+system call, the total time in seconds, the microseconds per call, the total
+number of calls, the count of each system call that has failed with an error
+and the type of system call made.
+
+ * Usage: strace <command we want to trace>
+ * Verbose mode usage: strace -v <command>
+ * Gather statistics: strace -c <command>
+
+We used the “-c” option to gather fine-grained run-time statistics in use
+by three workloads we have chose for this analysis.
+
+ * perf
+ * stress-ng
+ * paxtest
+
+What is cscope and how do we use it?
+====================================
+
+Now let’s look at `cscope <https://cscope.sourceforge.net/>`_, a command
+line tool for browsing C, C++ or Java code-bases. We can use it to find
+all the references to a symbol, global definitions, functions called by a
+function, functions calling a function, text strings, regular expression
+patterns, files including a file.
+
+We can use cscope to find which system call belongs to which subsystem.
+This way we can find the kernel subsystems used by a process when it is
+executed.
+
+Let’s checkout the latest Linux repository and build cscope database::
+
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
+ cd linux
+ cscope -R -p10 # builds cscope.out database before starting browse session
+ cscope -d -p10 # starts browse session on cscope.out database
+
+Note: Run "cscope -R -p10" to build the database and c"scope -d -p10" to
+enter into the browsing session. cscope by default cscope.out database.
+To get out of this mode press ctrl+d. -p option is used to specify the
+number of file path components to display. -p10 is optimal for browsing
+kernel sources.
+
+What is perf and how do we use it?
+==================================
+
+Perf is an analysis tool based on Linux 2.6+ systems, which abstracts the
+CPU hardware difference in performance measurement in Linux, and provides
+a simple command line interface. Perf is based on the perf_events interface
+exported by the kernel. It is very useful for profiling the system and
+finding performance bottlenecks in an application.
+
+If you haven't already checked out the Linux mainline repository, you can do
+so and then build kernel and perf tool::
+
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
+ cd linux
+ make -j3 all
+ cd tools/perf
+ make
+
+Note: The perf command can be built without building the kernel in the
+repository and can be run on older kernels. However matching the kernel
+and perf revisions gives more accurate information on the subsystem usage.
+
+We used "perf stat" and "perf bench" options. For a detailed information on
+the perf tool, run "perf -h".
+
+perf stat
+---------
+The perf stat command generates a report of various hardware and software
+events. It does so with the help of hardware counter registers found in
+modern CPUs that keep the count of these activities. "perf stat cal" shows
+stats for cal command.
+
+Perf bench
+----------
+The perf bench command contains multiple multi-threaded microkernel
+benchmarks for executing different subsystems in the Linux kernel and
+system calls. This allows us to easily measure the impact of changes,
+which can help mitigate performance regressions. It also acts as a common
+benchmarking framework, enabling developers to easily create test cases,
+integrate transparently, and use performance-rich tooling.
+
+"perf bench all" command runs the following benchmarks:
+
+ * sched/messaging
+ * sched/pipe
+ * syscall/basic
+ * mem/memcpy
+ * mem/memset
+
+What is stress-ng and how do we use it?
+=======================================
+
+As mentioned earlier, stress-ng is used for performing stress testing on
+the kernel. It allows you to exercise various physical subsystems of the
+computer, as well as interfaces of the OS kernel, using stressor-s. They
+are available for CPU, CPU cache, devices, I/O, interrupts, file system,
+memory, network, operating system, pipelines, schedulers, and virtual
+machines.
+
+The netdev stressor starts N workers that exercise various netdevice ioctl
+commands across all the available network devices. The following ioctls are
+exercised:
+
+ * SIOCGIFCONF, SIOCGIFINDEX, SIOCGIFNAME, SIOCGIFFLAGS
+ * SIOCGIFADDR, SIOCGIFNETMASK, SIOCGIFMETRIC, SIOCGIFMTU
+ * SIOCGIFHWADDR, SIOCGIFMAP, SIOCGIFTXQLEN
+
+The following command runs the stressor::
+
+ stress-ng --netdev 1 -t 60 --metrics command.
+
+We can use the perf record command to record the events and information
+associated with a process. This command records the profiling data in the
+perf.data file in the same directory.
+
+Using the following commands you can record the events associated with the
+netdev stressor, view the generated report perf.data and annotate the to
+view the statistics of each instruction of the program::
+
+ perf record stress-ng --netdev 1 -t 60 --metrics command.
+ perf report
+ perf annotate
+
+What is paxtest and how do we use it?
+=====================================
+
+paxtest is a program that tests buffer overflows in the kernel. It tests
+kernel enforcements over memory usage. Generally, execution in some memory
+segments makes buffer overflows possible. It runs a set of programs that
+attempt to subvert memory usage. It is used as a regression test suite for
+PaX, and will be useful to test other memory protection patches for the
+kernel.
+
+paxtest provides kiddie and blackhat modes. The paxtest kiddie mode runs
+in normal mode, whereas the blackhat mode tries to get around the protection
+of the kernel testing for vulnerabilities. We focus on the kiddie mode here
+and combine "paxtest kiddie" run with "perf record" to collect CPU stack
+traces for the paxtest kiddie run to see which function is calling other
+functions in the performance profile. Then the "dwarf" (DWARF's Call Frame
+Information) mode can be used to unwind the stack.
+
+The following command can be used to view resulting report in call-graph
+format::
+
+ perf record --call-graph dwarf paxtest kiddie
+ perf report --stdio
+
+Tracing workloads
+=================
+
+Now that we understand the workloads, let's start tracing them.
+
+Tracing perf bench all workload
+-------------------------------
+
+Run the following command to trace perf bench all workload::
+
+ strace -c perf bench all
+
+**System Calls made by the workload**
+
+The below table shows the system calls invoked by the workload, number of
+times each system call is invoked, and the corresponding Linux subsystem.
+
++-------------------+-----------+-----------------+-------------------------+
+| System Call | # calls | Linux Subsystem | System Call (API) |
++===================+===========+=================+=========================+
+| getppid | 10000001 | Process Mgmt | sys_getpid() |
++-------------------+-----------+-----------------+-------------------------+
+| clone | 1077 | Process Mgmt. | sys_clone() |
++-------------------+-----------+-----------------+-------------------------+
+| prctl | 23 | Process Mgmt. | sys_prctl() |
++-------------------+-----------+-----------------+-------------------------+
+| prlimit64 | 7 | Process Mgmt. | sys_prlimit64() |
++-------------------+-----------+-----------------+-------------------------+
+| getpid | 10 | Process Mgmt. | sys_getpid() |
++-------------------+-----------+-----------------+-------------------------+
+| uname | 3 | Process Mgmt. | sys_uname() |
++-------------------+-----------+-----------------+-------------------------+
+| sysinfo | 1 | Process Mgmt. | sys_sysinfo() |
++-------------------+-----------+-----------------+-------------------------+
+| getuid | 1 | Process Mgmt. | sys_getuid() |
++-------------------+-----------+-----------------+-------------------------+
+| getgid | 1 | Process Mgmt. | sys_getgid() |
++-------------------+-----------+-----------------+-------------------------+
+| geteuid | 1 | Process Mgmt. | sys_geteuid() |
++-------------------+-----------+-----------------+-------------------------+
+| getegid | 1 | Process Mgmt. | sys_getegid |
++-------------------+-----------+-----------------+-------------------------+
+| close | 49951 | Filesystem | sys_close() |
++-------------------+-----------+-----------------+-------------------------+
+| pipe | 604 | Filesystem | sys_pipe() |
++-------------------+-----------+-----------------+-------------------------+
+| openat | 48560 | Filesystem | sys_opennat() |
++-------------------+-----------+-----------------+-------------------------+
+| fstat | 8338 | Filesystem | sys_fstat() |
++-------------------+-----------+-----------------+-------------------------+
+| stat | 1573 | Filesystem | sys_stat() |
++-------------------+-----------+-----------------+-------------------------+
+| pread64 | 9646 | Filesystem | sys_pread64() |
++-------------------+-----------+-----------------+-------------------------+
+| getdents64 | 1873 | Filesystem | sys_getdents64() |
++-------------------+-----------+-----------------+-------------------------+
+| access | 3 | Filesystem | sys_access() |
++-------------------+-----------+-----------------+-------------------------+
+| lstat | 1880 | Filesystem | sys_lstat() |
++-------------------+-----------+-----------------+-------------------------+
+| lseek | 6 | Filesystem | sys_lseek() |
++-------------------+-----------+-----------------+-------------------------+
+| ioctl | 3 | Filesystem | sys_ioctl() |
++-------------------+-----------+-----------------+-------------------------+
+| dup2 | 1 | Filesystem | sys_dup2() |
++-------------------+-----------+-----------------+-------------------------+
+| execve | 2 | Filesystem | sys_execve() |
++-------------------+-----------+-----------------+-------------------------+
+| fcntl | 8779 | Filesystem | sys_fcntl() |
++-------------------+-----------+-----------------+-------------------------+
+| statfs | 1 | Filesystem | sys_statfs() |
++-------------------+-----------+-----------------+-------------------------+
+| epoll_create | 2 | Filesystem | sys_epoll_create() |
++-------------------+-----------+-----------------+-------------------------+
+| epoll_ctl | 64 | Filesystem | sys_epoll_ctl() |
++-------------------+-----------+-----------------+-------------------------+
+| newfstatat | 8318 | Filesystem | sys_newfstatat() |
++-------------------+-----------+-----------------+-------------------------+
+| eventfd2 | 192 | Filesystem | sys_eventfd2() |
++-------------------+-----------+-----------------+-------------------------+
+| mmap | 243 | Memory Mgmt. | sys_mmap() |
++-------------------+-----------+-----------------+-------------------------+
+| mprotect | 32 | Memory Mgmt. | sys_mprotect() |
++-------------------+-----------+-----------------+-------------------------+
+| brk | 21 | Memory Mgmt. | sys_brk() |
++-------------------+-----------+-----------------+-------------------------+
+| munmap | 128 | Memory Mgmt. | sys_munmap() |
++-------------------+-----------+-----------------+-------------------------+
+| set_mempolicy | 156 | Memory Mgmt. | sys_set_mempolicy() |
++-------------------+-----------+-----------------+-------------------------+
+| set_tid_address | 1 | Process Mgmt. | sys_set_tid_address() |
++-------------------+-----------+-----------------+-------------------------+
+| set_robust_list | 1 | Futex | sys_set_robust_list() |
++-------------------+-----------+-----------------+-------------------------+
+| futex | 341 | Futex | sys_futex() |
++-------------------+-----------+-----------------+-------------------------+
+| sched_getaffinity | 79 | Scheduler | sys_sched_getaffinity() |
++-------------------+-----------+-----------------+-------------------------+
+| sched_setaffinity | 223 | Scheduler | sys_sched_setaffinity() |
++-------------------+-----------+-----------------+-------------------------+
+| socketpair | 202 | Network | sys_socketpair() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigprocmask | 21 | Signal | sys_rt_sigprocmask() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigaction | 36 | Signal | sys_rt_sigaction() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigreturn | 2 | Signal | sys_rt_sigreturn() |
++-------------------+-----------+-----------------+-------------------------+
+| wait4 | 889 | Time | sys_wait4() |
++-------------------+-----------+-----------------+-------------------------+
+| clock_nanosleep | 37 | Time | sys_clock_nanosleep() |
++-------------------+-----------+-----------------+-------------------------+
+| capget | 4 | Capability | sys_capget() |
++-------------------+-----------+-----------------+-------------------------+
+
+Tracing stress-ng netdev stressor workload
+------------------------------------------
+
+Run the following command to trace stress-ng netdev stressor workload::
+
+ strace -c stress-ng --netdev 1 -t 60 --metrics
+
+**System Calls made by the workload**
+
+The below table shows the system calls invoked by the workload, number of
+times each system call is invoked, and the corresponding Linux subsystem.
+
++-------------------+-----------+-----------------+-------------------------+
+| System Call | # calls | Linux Subsystem | System Call (API) |
++===================+===========+=================+=========================+
+| openat | 74 | Filesystem | sys_openat() |
++-------------------+-----------+-----------------+-------------------------+
+| close | 75 | Filesystem | sys_close() |
++-------------------+-----------+-----------------+-------------------------+
+| read | 58 | Filesystem | sys_read() |
++-------------------+-----------+-----------------+-------------------------+
+| fstat | 20 | Filesystem | sys_fstat() |
++-------------------+-----------+-----------------+-------------------------+
+| flock | 10 | Filesystem | sys_flock() |
++-------------------+-----------+-----------------+-------------------------+
+| write | 7 | Filesystem | sys_write() |
++-------------------+-----------+-----------------+-------------------------+
+| getdents64 | 8 | Filesystem | sys_getdents64() |
++-------------------+-----------+-----------------+-------------------------+
+| pread64 | 8 | Filesystem | sys_pread64() |
++-------------------+-----------+-----------------+-------------------------+
+| lseek | 1 | Filesystem | sys_lseek() |
++-------------------+-----------+-----------------+-------------------------+
+| access | 2 | Filesystem | sys_access() |
++-------------------+-----------+-----------------+-------------------------+
+| getcwd | 1 | Filesystem | sys_getcwd() |
++-------------------+-----------+-----------------+-------------------------+
+| execve | 1 | Filesystem | sys_execve() |
++-------------------+-----------+-----------------+-------------------------+
+| mmap | 61 | Memory Mgmt. | sys_mmap() |
++-------------------+-----------+-----------------+-------------------------+
+| munmap | 3 | Memory Mgmt. | sys_munmap() |
++-------------------+-----------+-----------------+-------------------------+
+| mprotect | 20 | Memory Mgmt. | sys_mprotect() |
++-------------------+-----------+-----------------+-------------------------+
+| mlock | 2 | Memory Mgmt. | sys_mlock() |
++-------------------+-----------+-----------------+-------------------------+
+| brk | 3 | Memory Mgmt. | sys_brk() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigaction | 21 | Signal | sys_rt_sigaction() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigprocmask | 1 | Signal | sys_rt_sigprocmask() |
++-------------------+-----------+-----------------+-------------------------+
+| sigaltstack | 1 | Signal | sys_sigaltstack() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigreturn | 1 | Signal | sys_rt_sigreturn() |
++-------------------+-----------+-----------------+-------------------------+
+| getpid | 8 | Process Mgmt. | sys_getpid() |
++-------------------+-----------+-----------------+-------------------------+
+| prlimit64 | 5 | Process Mgmt. | sys_prlimit64() |
++-------------------+-----------+-----------------+-------------------------+
+| arch_prctl | 2 | Process Mgmt. | sys_arch_prctl() |
++-------------------+-----------+-----------------+-------------------------+
+| sysinfo | 2 | Process Mgmt. | sys_sysinfo() |
++-------------------+-----------+-----------------+-------------------------+
+| getuid | 2 | Process Mgmt. | sys_getuid() |
++-------------------+-----------+-----------------+-------------------------+
+| uname | 1 | Process Mgmt. | sys_uname() |
++-------------------+-----------+-----------------+-------------------------+
+| setpgid | 1 | Process Mgmt. | sys_setpgid() |
++-------------------+-----------+-----------------+-------------------------+
+| getrusage | 1 | Process Mgmt. | sys_getrusage() |
++-------------------+-----------+-----------------+-------------------------+
+| geteuid | 1 | Process Mgmt. | sys_geteuid() |
++-------------------+-----------+-----------------+-------------------------+
+| getppid | 1 | Process Mgmt. | sys_getppid() |
++-------------------+-----------+-----------------+-------------------------+
+| sendto | 3 | Network | sys_sendto() |
++-------------------+-----------+-----------------+-------------------------+
+| connect | 1 | Network | sys_connect() |
++-------------------+-----------+-----------------+-------------------------+
+| socket | 1 | Network | sys_socket() |
++-------------------+-----------+-----------------+-------------------------+
+| clone | 1 | Process Mgmt. | sys_clone() |
++-------------------+-----------+-----------------+-------------------------+
+| set_tid_address | 1 | Process Mgmt. | sys_set_tid_address() |
++-------------------+-----------+-----------------+-------------------------+
+| wait4 | 2 | Time | sys_wait4() |
++-------------------+-----------+-----------------+-------------------------+
+| alarm | 1 | Time | sys_alarm() |
++-------------------+-----------+-----------------+-------------------------+
+| set_robust_list | 1 | Futex | sys_set_robust_list() |
++-------------------+-----------+-----------------+-------------------------+
+
+Tracing paxtest kiddie workload
+-------------------------------
+
+Run the following command to trace paxtest kiddie workload::
+
+ strace -c paxtest kiddie
+
+**System Calls made by the workload**
+
+The below table shows the system calls invoked by the workload, number of
+times each system call is invoked, and the corresponding Linux subsystem.
+
++-------------------+-----------+-----------------+----------------------+
+| System Call | # calls | Linux Subsystem | System Call (API) |
++===================+===========+=================+======================+
+| read | 3 | Filesystem | sys_read() |
++-------------------+-----------+-----------------+----------------------+
+| write | 11 | Filesystem | sys_write() |
++-------------------+-----------+-----------------+----------------------+
+| close | 41 | Filesystem | sys_close() |
++-------------------+-----------+-----------------+----------------------+
+| stat | 24 | Filesystem | sys_stat() |
++-------------------+-----------+-----------------+----------------------+
+| fstat | 2 | Filesystem | sys_fstat() |
++-------------------+-----------+-----------------+----------------------+
+| pread64 | 6 | Filesystem | sys_pread64() |
++-------------------+-----------+-----------------+----------------------+
+| access | 1 | Filesystem | sys_access() |
++-------------------+-----------+-----------------+----------------------+
+| pipe | 1 | Filesystem | sys_pipe() |
++-------------------+-----------+-----------------+----------------------+
+| dup2 | 24 | Filesystem | sys_dup2() |
++-------------------+-----------+-----------------+----------------------+
+| execve | 1 | Filesystem | sys_execve() |
++-------------------+-----------+-----------------+----------------------+
+| fcntl | 26 | Filesystem | sys_fcntl() |
++-------------------+-----------+-----------------+----------------------+
+| openat | 14 | Filesystem | sys_openat() |
++-------------------+-----------+-----------------+----------------------+
+| rt_sigaction | 7 | Signal | sys_rt_sigaction() |
++-------------------+-----------+-----------------+----------------------+
+| rt_sigreturn | 38 | Signal | sys_rt_sigreturn() |
++-------------------+-----------+-----------------+----------------------+
+| clone | 38 | Process Mgmt. | sys_clone() |
++-------------------+-----------+-----------------+----------------------+
+| wait4 | 44 | Time | sys_wait4() |
++-------------------+-----------+-----------------+----------------------+
+| mmap | 7 | Memory Mgmt. | sys_mmap() |
++-------------------+-----------+-----------------+----------------------+
+| mprotect | 3 | Memory Mgmt. | sys_mprotect() |
++-------------------+-----------+-----------------+----------------------+
+| munmap | 1 | Memory Mgmt. | sys_munmap() |
++-------------------+-----------+-----------------+----------------------+
+| brk | 3 | Memory Mgmt. | sys_brk() |
++-------------------+-----------+-----------------+----------------------+
+| getpid | 1 | Process Mgmt. | sys_getpid() |
++-------------------+-----------+-----------------+----------------------+
+| getuid | 1 | Process Mgmt. | sys_getuid() |
++-------------------+-----------+-----------------+----------------------+
+| getgid | 1 | Process Mgmt. | sys_getgid() |
++-------------------+-----------+-----------------+----------------------+
+| geteuid | 2 | Process Mgmt. | sys_geteuid() |
++-------------------+-----------+-----------------+----------------------+
+| getegid | 1 | Process Mgmt. | sys_getegid() |
++-------------------+-----------+-----------------+----------------------+
+| getppid | 1 | Process Mgmt. | sys_getppid() |
++-------------------+-----------+-----------------+----------------------+
+| arch_prctl | 2 | Process Mgmt. | sys_arch_prctl() |
++-------------------+-----------+-----------------+----------------------+
+
+Conclusion
+==========
+
+This document is intended to be used as a guide on how to gather fine-grained
+information on the resources in use by workloads using strace.
+
+References
+==========
+
+ * `Discovery Linux Kernel Subsystems used by OpenAPS <https://elisa.tech/blog/2022/02/02/discovery-linux-kernel-subsystems-used-by-openaps>`_
+ * `ELISA-White-Papers-Discovering Linux kernel subsystems used by a workload <https://github.com/elisa-tech/ELISA-White-Papers/blob/master/Processes/Discovering_Linux_kernel_subsystems_used_by_a_workload.md>`_
+ * `strace <https://man7.org/linux/man-pages/man1/strace.1.html>`_
+ * `perf <https://man7.org/linux/man-pages/man1/perf.1.html>`_
+ * `paxtest README <https://github.com/opntr/paxtest-freebsd/blob/hardenedbsd/0.9.14-hbsd/README>`_
+ * `stress-ng <https://www.mankier.com/1/stress-ng>`_
+ * `Monitoring and managing system status and performance <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/index>`_
diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst
index 8de008c..e256141 100644
--- a/Documentation/admin-guide/xfs.rst
+++ b/Documentation/admin-guide/xfs.rst
@@ -296,7 +296,7 @@
XFS_ERRLEVEL_LOW: 1
XFS_ERRLEVEL_HIGH: 5
- fs.xfs.panic_mask (Min: 0 Default: 0 Max: 256)
+ fs.xfs.panic_mask (Min: 0 Default: 0 Max: 511)
Causes certain error conditions to call BUG(). Value is a bitmask;
OR together the tags which represent errors which should cause panics:
diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst
index 8c636d4..ae42fe8 100644
--- a/Documentation/arm/index.rst
+++ b/Documentation/arm/index.rst
@@ -64,7 +64,6 @@
sunxi
samsung/index
- samsung-s3c24xx/index
sunxi/clocks
diff --git a/Documentation/arm/samsung-s3c24xx/cpufreq.rst b/Documentation/arm/samsung-s3c24xx/cpufreq.rst
deleted file mode 100644
index cd22697..0000000
--- a/Documentation/arm/samsung-s3c24xx/cpufreq.rst
+++ /dev/null
@@ -1,77 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0-only
-
-=======================
-S3C24XX CPUfreq support
-=======================
-
-Introduction
-------------
-
- The S3C24XX series support a number of power saving systems, such as
- the ability to change the core, memory and peripheral operating
- frequencies. The core control is exported via the CPUFreq driver
- which has a number of different manual or automatic controls over the
- rate the core is running at.
-
- There are two forms of the driver depending on the specific CPU and
- how the clocks are arranged. The first implementation used as single
- PLL to feed the ARM, memory and peripherals via a series of dividers
- and muxes and this is the implementation that is documented here. A
- newer version where there is a separate PLL and clock divider for the
- ARM core is available as a separate driver.
-
-
-Layout
-------
-
- The code core manages the CPU specific drivers, any data that they
- need to register and the interface to the generic drivers/cpufreq
- system. Each CPU registers a driver to control the PLL, clock dividers
- and anything else associated with it. Any board that wants to use this
- framework needs to supply at least basic details of what is required.
-
- The core registers with drivers/cpufreq at init time if all the data
- necessary has been supplied.
-
-
-CPU support
------------
-
- The support for each CPU depends on the facilities provided by the
- SoC and the driver as each device has different PLL and clock chains
- associated with it.
-
-
-Slow Mode
----------
-
- The SLOW mode where the PLL is turned off altogether and the
- system is fed by the external crystal input is currently not
- supported.
-
-
-sysfs
------
-
- The core code exports extra information via sysfs in the directory
- devices/system/cpu/cpu0/arch-freq.
-
-
-Board Support
--------------
-
- Each board that wants to use the cpufreq code must register some basic
- information with the core driver to provide information about what the
- board requires and any restrictions being placed on it.
-
- The board needs to supply information about whether it needs the IO bank
- timings changing, any maximum frequency limits and information about the
- SDRAM refresh rate.
-
-
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2009 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/eb2410itx.rst b/Documentation/arm/samsung-s3c24xx/eb2410itx.rst
deleted file mode 100644
index 7863c93..0000000
--- a/Documentation/arm/samsung-s3c24xx/eb2410itx.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-===================================
-Simtec Electronics EB2410ITX (BAST)
-===================================
-
- http://www.simtec.co.uk/products/EB2410ITX/
-
-Introduction
-------------
-
- The EB2410ITX is a S3C2410 based development board with a variety of
- peripherals and expansion connectors. This board is also known by
- the shortened name of Bast.
-
-
-Configuration
--------------
-
- To set the default configuration, use `make bast_defconfig` which
- supports the commonly used features of this board.
-
-
-Support
--------
-
- Official support information can be found on the Simtec Electronics
- website, at the product page http://www.simtec.co.uk/products/EB2410ITX/
-
- Useful links:
-
- - Resources Page http://www.simtec.co.uk/products/EB2410ITX/resources.html
-
- - Board FAQ at http://www.simtec.co.uk/products/EB2410ITX/faq.html
-
- - Bootloader info http://www.simtec.co.uk/products/SWABLE/resources.html
- and FAQ http://www.simtec.co.uk/products/SWABLE/faq.html
-
-
-MTD
----
-
- The NAND and NOR support has been merged from the linux-mtd project.
- Any problems, see http://www.linux-mtd.infradead.org/ for more
- information or up-to-date versions of linux-mtd.
-
-
-IDE
----
-
- Both onboard IDE ports are supported, however there is no support for
- changing speed of devices, PIO Mode 4 capable drives should be used.
-
-
-Maintainers
------------
-
- This board is maintained by Simtec Electronics.
-
-
-Copyright 2004 Ben Dooks, Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/gpio.rst b/Documentation/arm/samsung-s3c24xx/gpio.rst
deleted file mode 100644
index f4a8c80..0000000
--- a/Documentation/arm/samsung-s3c24xx/gpio.rst
+++ /dev/null
@@ -1,172 +0,0 @@
-====================
-S3C24XX GPIO Control
-====================
-
-Introduction
-------------
-
- The s3c2410 kernel provides an interface to configure and
- manipulate the state of the GPIO pins, and find out other
- information about them.
-
- There are a number of conditions attached to the configuration
- of the s3c2410 GPIO system, please read the Samsung provided
- data-sheet/users manual to find out the complete list.
-
- See Documentation/arm/samsung/gpio.rst for the core implementation.
-
-
-GPIOLIB
--------
-
- With the event of the GPIOLIB in drivers/gpio, support for some
- of the GPIO functions such as reading and writing a pin will
- be removed in favour of this common access method.
-
- Once all the extant drivers have been converted, the functions
- listed below will be removed (they may be marked as __deprecated
- in the near future).
-
- The following functions now either have a `s3c_` specific variant
- or are merged into gpiolib. See the definitions in
- arch/arm/mach-s3c/gpio-cfg.h:
-
- - s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
- - s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
- - s3c2410_gpio_getirq() gpio_to_irq()
- - s3c2410_gpio_cfgpin() s3c_gpio_cfgpin()
- - s3c2410_gpio_getcfg() s3c_gpio_getcfg()
- - s3c2410_gpio_pullup() s3c_gpio_setpull()
-
-
-GPIOLIB conversion
-------------------
-
-If you need to convert your board or driver to use gpiolib from the phased
-out s3c2410 API, then here are some notes on the process.
-
-1) If your board is exclusively using an GPIO, say to control peripheral
- power, then it will require to claim the gpio with gpio_request() before
- it can use it.
-
- It is recommended to check the return value, with at least WARN_ON()
- during initialisation.
-
-2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
- as they have the same arguments, and can either take the pin specific
- values, or the more generic special-function-number arguments.
-
-3) s3c2410_gpio_pullup() changes have the problem that while the
- s3c2410_gpio_pullup(x, 1) can be easily translated to the
- s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
- are not so easy.
-
- The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
- of some of the devices, a pull-down) and as such the new API distinguishes
- between the UP and DOWN case. There is currently no 'just turn on' setting
- which may be required if this becomes a problem.
-
-4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
- does not implicitly configure the relevant gpio to output. The gpio
- direction should be changed before using gpio_set_value().
-
-5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
- has been set to input. It is currently unknown what the behaviour is
- when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
- would return the value the pin is supposed to be outputting).
-
-6) s3c2410_gpio_getirq() should be directly replaceable with the
- gpio_to_irq() call.
-
-The s3c2410_gpio and `gpio_` calls have always operated on the same gpio
-numberspace, so there is no problem with converting the gpio numbering
-between the calls.
-
-
-Headers
--------
-
- See arch/arm/mach-s3c/regs-gpio-s3c24xx.h for the list
- of GPIO pins, and the configuration values for them. This
- is included by using #include <mach/regs-gpio.h>
-
-
-PIN Numbers
------------
-
- Each pin has an unique number associated with it in regs-gpio.h,
- e.g. S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
- the GPIO functions which pin is to be used.
-
- With the conversion to gpiolib, there is no longer a direct conversion
- from gpio pin number to register base address as in earlier kernels. This
- is due to the number space required for newer SoCs where the later
- GPIOs are not contiguous.
-
-
-Configuring a pin
------------------
-
- The following function allows the configuration of a given pin to
- be changed.
-
- void s3c_gpio_cfgpin(unsigned int pin, unsigned int function);
-
- e.g.:
-
- s3c_gpio_cfgpin(S3C2410_GPA(0), S3C_GPIO_SFN(1));
- s3c_gpio_cfgpin(S3C2410_GPE(8), S3C_GPIO_SFN(2));
-
- which would turn GPA(0) into the lowest Address line A0, and set
- GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
-
-
-Reading the current configuration
----------------------------------
-
- The current configuration of a pin can be read by using standard
- gpiolib function:
-
- s3c_gpio_getcfg(unsigned int pin);
-
- The return value will be from the same set of values which can be
- passed to s3c_gpio_cfgpin().
-
-
-Configuring a pull-up resistor
-------------------------------
-
- A large proportion of the GPIO pins on the S3C2410 can have weak
- pull-up resistors enabled. This can be configured by the following
- function:
-
- void s3c_gpio_setpull(unsigned int pin, unsigned int to);
-
- Where the to value is S3C_GPIO_PULL_NONE to set the pull-up off,
- and S3C_GPIO_PULL_UP to enable the specified pull-up. Any other
- values are currently undefined.
-
-
-Getting and setting the state of a PIN
---------------------------------------
-
- These calls are now implemented by the relevant gpiolib calls, convert
- your board or driver to use gpiolib.
-
-
-Getting the IRQ number associated with a PIN
---------------------------------------------
-
- A standard gpiolib function can map the given pin number to an IRQ
- number to pass to the IRQ system.
-
- int gpio_to_irq(unsigned int pin);
-
- Note, not all pins have an IRQ.
-
-
-Author
--------
-
-Ben Dooks, 03 October 2004
-Copyright 2004 Ben Dooks, Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/h1940.rst b/Documentation/arm/samsung-s3c24xx/h1940.rst
deleted file mode 100644
index 62a562c..0000000
--- a/Documentation/arm/samsung-s3c24xx/h1940.rst
+++ /dev/null
@@ -1,41 +0,0 @@
-=============
-HP IPAQ H1940
-=============
-
-http://www.handhelds.org/projects/h1940.html
-
-Introduction
-------------
-
- The HP H1940 is a S3C2410 based handheld device, with
- bluetooth connectivity.
-
-
-Support
--------
-
- A variety of information is available
-
- handhelds.org project page:
-
- http://www.handhelds.org/projects/h1940.html
-
- handhelds.org wiki page:
-
- http://handhelds.org/moin/moin.cgi/HpIpaqH1940
-
- Herbert Pötzl pages:
-
- http://vserver.13thfloor.at/H1940/
-
-
-Maintainers
------------
-
- This project is being maintained and developed by a variety
- of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
-
- Thanks to the many others who have also provided support.
-
-
-(c) 2005 Ben Dooks
diff --git a/Documentation/arm/samsung-s3c24xx/index.rst b/Documentation/arm/samsung-s3c24xx/index.rst
deleted file mode 100644
index ccb951a..0000000
--- a/Documentation/arm/samsung-s3c24xx/index.rst
+++ /dev/null
@@ -1,20 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-==========================
-Samsung S3C24XX SoC Family
-==========================
-
-.. toctree::
- :maxdepth: 1
-
- h1940
- gpio
- cpufreq
- suspend
- usb-host
- s3c2412
- eb2410itx
- nand
- smdk2440
- s3c2413
- overview
diff --git a/Documentation/arm/samsung-s3c24xx/nand.rst b/Documentation/arm/samsung-s3c24xx/nand.rst
deleted file mode 100644
index 9389956..0000000
--- a/Documentation/arm/samsung-s3c24xx/nand.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-====================
-S3C24XX NAND Support
-====================
-
-Introduction
-------------
-
-Small Page NAND
----------------
-
-The driver uses a 512 byte (1 page) ECC code for this setup. The
-ECC code is not directly compatible with the default kernel ECC
-code, so the driver enforces its own OOB layout and ECC parameters
-
-Large Page NAND
----------------
-
-The driver is capable of handling NAND flash with a 2KiB page
-size, with support for hardware ECC generation and correction.
-
-Unlike the 512byte page mode, the driver generates ECC data for
-each 256 byte block in an 2KiB page. This means that more than
-one error in a page can be rectified. It also means that the
-OOB layout remains the default kernel layout for these flashes.
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2007 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/overview.rst b/Documentation/arm/samsung-s3c24xx/overview.rst
deleted file mode 100644
index 14535e5..0000000
--- a/Documentation/arm/samsung-s3c24xx/overview.rst
+++ /dev/null
@@ -1,311 +0,0 @@
-==========================
-S3C24XX ARM Linux Overview
-==========================
-
-
-
-Introduction
-------------
-
- The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
- by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
- S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443 and S3C2450 devices
- are supported.
-
- Support for the S3C2400 and S3C24A0 series was never completed and the
- corresponding code has been removed after a while. If someone wishes to
- revive this effort, partial support can be retrieved from earlier Linux
- versions.
-
- The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
- included under the arch/arm/mach-s3c directory. Note, while core
- support for these SoCs is in, work on some of the extra peripherals
- and extra interrupts is still ongoing.
-
-
-Configuration
--------------
-
- A generic S3C2410 configuration is provided, and can be used as the
- default by `make s3c2410_defconfig`. This configuration has support
- for all the machines, and the commonly used features on them.
-
- Certain machines may have their own default configurations as well,
- please check the machine specific documentation.
-
-
-Layout
-------
-
- The core support files, register, kernel and paltform data are located in the
- platform code contained in arch/arm/mach-s3c with headers in
- arch/arm/mach-s3c/include
-
-arch/arm/mach-s3c:
-
- Files in here are either common to all the s3c24xx family,
- or are common to only some of them with names to indicate this
- status. The files that are not common to all are generally named
- with the initial cpu they support in the series to ensure a short
- name without any possibility of confusion with newer devices.
-
- As an example, initially s3c244x would cover s3c2440 and s3c2442, but
- with the s3c2443 which does not share many of the same drivers in
- this directory, the name becomes invalid. We stick to s3c2440-<x>
- to indicate a driver that is s3c2440 and s3c2442 compatible.
-
- This does mean that to find the status of any given SoC, a number
- of directories may need to be searched.
-
-
-Machines
---------
-
- The currently supported machines are as follows:
-
- Simtec Electronics EB2410ITX (BAST)
-
- A general purpose development board, see EB2410ITX.txt for further
- details
-
- Simtec Electronics IM2440D20 (Osiris)
-
- CPU Module from Simtec Electronics, with a S3C2440A CPU, nand flash
- and a PCMCIA controller.
-
- Samsung SMDK2410
-
- Samsung's own development board, geared for PDA work.
-
- Samsung/Aiji SMDK2412
-
- The S3C2412 version of the SMDK2440.
-
- Samsung/Aiji SMDK2413
-
- The S3C2412 version of the SMDK2440.
-
- Samsung/Meritech SMDK2440
-
- The S3C2440 compatible version of the SMDK2440, which has the
- option of an S3C2440 or S3C2442 CPU module.
-
- Thorcom VR1000
-
- Custom embedded board
-
- HP IPAQ 1940
-
- Handheld (IPAQ), available in several varieties
-
- HP iPAQ rx3715
-
- S3C2440 based IPAQ, with a number of variations depending on
- features shipped.
-
- Acer N30
-
- A S3C2410 based PDA from Acer. There is a Wiki page at
- http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
-
- AML M5900
-
- American Microsystems' M5900
-
- Nex Vision Nexcoder
- Nex Vision Otom
-
- Two machines by Nex Vision
-
-
-Adding New Machines
--------------------
-
- The architecture has been designed to support as many machines as can
- be configured for it in one kernel build, and any future additions
- should keep this in mind before altering items outside of their own
- machine files.
-
- Machine definitions should be kept in arch/arm/mach-s3c,
- and there are a number of examples that can be looked at.
-
- Read the kernel patch submission policies as well as the
- Documentation/arm directory before submitting patches. The
- ARM kernel series is managed by Russell King, and has a patch system
- located at http://www.arm.linux.org.uk/developer/patches/
- as well as mailing lists that can be found from the same site.
-
- As a courtesy, please notify <ben-linux@fluff.org> of any new
- machines or other modifications.
-
- Any large scale modifications, or new drivers should be discussed
- on the ARM kernel mailing list (linux-arm-kernel) before being
- attempted. See http://www.arm.linux.org.uk/mailinglists/ for the
- mailing list information.
-
-
-I2C
----
-
- The hardware I2C core in the CPU is supported in single master
- mode, and can be configured via platform data.
-
-
-RTC
----
-
- Support for the onboard RTC unit, including alarm function.
-
- This has recently been upgraded to use the new RTC core,
- and the module has been renamed to rtc-s3c to fit in with
- the new rtc naming scheme.
-
-
-Watchdog
---------
-
- The onchip watchdog is available via the standard watchdog
- interface.
-
-
-NAND
-----
-
- The current kernels now have support for the s3c2410 NAND
- controller. If there are any problems the latest linux-mtd
- code can be found from http://www.linux-mtd.infradead.org/
-
- For more information see Documentation/arm/samsung-s3c24xx/nand.rst
-
-
-SD/MMC
-------
-
- The SD/MMC hardware pre S3C2443 is supported in the current
- kernel, the driver is drivers/mmc/host/s3cmci.c and supports
- 1 and 4 bit SD or MMC cards.
-
- The SDIO behaviour of this driver has not been fully tested. There is no
- current support for hardware SDIO interrupts.
-
-
-Serial
-------
-
- The s3c2410 serial driver provides support for the internal
- serial ports. These devices appear as /dev/ttySAC0 through 3.
-
- To create device nodes for these, use the following commands
-
- mknod ttySAC0 c 204 64
- mknod ttySAC1 c 204 65
- mknod ttySAC2 c 204 66
-
-
-GPIO
-----
-
- The core contains support for manipulating the GPIO, see the
- documentation in GPIO.txt in the same directory as this file.
-
- Newer kernels carry GPIOLIB, and support is being moved towards
- this with some of the older support in line to be removed.
-
- As of v2.6.34, the move towards using gpiolib support is almost
- complete, and very little of the old calls are left.
-
- See Documentation/arm/samsung-s3c24xx/gpio.rst for the S3C24XX specific
- support and Documentation/arm/samsung/gpio.rst for the core Samsung
- implementation.
-
-
-Clock Management
-----------------
-
- The core provides the interface defined in the header file
- include/asm-arm/hardware/clock.h, to allow control over the
- various clock units
-
-
-Suspend to RAM
---------------
-
- For boards that provide support for suspend to RAM, the
- system can be placed into low power suspend.
-
- See Suspend.txt for more information.
-
-
-SPI
----
-
- SPI drivers are available for both the in-built hardware
- (although there is no DMA support yet) and a generic
- GPIO based solution.
-
-
-LEDs
-----
-
- There is support for GPIO based LEDs via a platform driver
- in the LED subsystem.
-
-
-Platform Data
--------------
-
- Whenever a device has platform specific data that is specified
- on a per-machine basis, care should be taken to ensure the
- following:
-
- 1) that default data is not left in the device to confuse the
- driver if a machine does not set it at startup
-
- 2) the data should (if possible) be marked as __initdata,
- to ensure that the data is thrown away if the machine is
- not the one currently in use.
-
- The best way of doing this is to make a function that
- kmalloc()s an area of memory, and copies the __initdata
- and then sets the relevant device's platform data. Making
- the function `__init` takes care of ensuring it is discarded
- with the rest of the initialisation code::
-
- static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)
- {
- struct s3c2410_xxx_mach_info *npd;
-
- npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);
- if (npd) {
- memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info));
- s3c_device_xxx.dev.platform_data = npd;
- } else {
- printk(KERN_ERR "no memory for xxx platform data\n");
- }
- }
-
- Note, since the code is marked as __init, it should not be
- exported outside arch/arm/mach-s3c/, or exported to
- modules via EXPORT_SYMBOL() and related functions.
-
-
-Port Contributors
------------------
-
- Ben Dooks (BJD)
- Vincent Sanders
- Herbert Potzl
- Arnaud Patard (RTP)
- Roc Wu
- Klaus Fetscher
- Dimitry Andric
- Shannon Holland
- Guillaume Gourat (NexVision)
- Christer Weinigel (wingel) (Acer N30)
- Lucas Correia Villa Real (S3C2400 port)
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2004-2006 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/s3c2412.rst b/Documentation/arm/samsung-s3c24xx/s3c2412.rst
deleted file mode 100644
index 68b985f..0000000
--- a/Documentation/arm/samsung-s3c24xx/s3c2412.rst
+++ /dev/null
@@ -1,121 +0,0 @@
-==========================
-S3C2412 ARM Linux Overview
-==========================
-
-Introduction
-------------
-
- The S3C2412 is part of the S3C24XX range of ARM9 System-on-Chip CPUs
- from Samsung. This part has an ARM926-EJS core, capable of running up
- to 266MHz (see data-sheet for more information)
-
-
-Clock
------
-
- The core clock code provides a set of clocks to the drivers, and allows
- for source selection and a number of other features.
-
-
-Power
------
-
- No support for suspend/resume to RAM in the current system.
-
-
-DMA
----
-
- No current support for DMA.
-
-
-GPIO
-----
-
- There is support for setting the GPIO to input/output/special function
- and reading or writing to them.
-
-
-UART
-----
-
- The UART hardware is similar to the S3C2440, and is supported by the
- s3c2410 driver in the drivers/serial directory.
-
-
-NAND
-----
-
- The NAND hardware is similar to the S3C2440, and is supported by the
- s3c2410 driver in the drivers/mtd/nand/raw directory.
-
-
-USB Host
---------
-
- The USB hardware is similar to the S3C2410, with extended clock source
- control. The OHCI portion is supported by the ohci-s3c2410 driver, and
- the clock control selection is supported by the core clock code.
-
-
-USB Device
-----------
-
- No current support in the kernel
-
-
-IRQs
-----
-
- All the standard, and external interrupt sources are supported. The
- extra sub-sources are not yet supported.
-
-
-RTC
----
-
- The RTC hardware is similar to the S3C2410, and is supported by the
- s3c2410-rtc driver.
-
-
-Watchdog
---------
-
- The watchdog hardware is the same as the S3C2410, and is supported by
- the s3c2410_wdt driver.
-
-
-MMC/SD/SDIO
------------
-
- No current support for the MMC/SD/SDIO block.
-
-IIC
----
-
- The IIC hardware is the same as the S3C2410, and is supported by the
- i2c-s3c24xx driver.
-
-
-IIS
----
-
- No current support for the IIS interface.
-
-
-SPI
----
-
- No current support for the SPI interfaces.
-
-
-ATA
----
-
- No current support for the on-board ATA block.
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2006 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/s3c2413.rst b/Documentation/arm/samsung-s3c24xx/s3c2413.rst
deleted file mode 100644
index 1f51e20..0000000
--- a/Documentation/arm/samsung-s3c24xx/s3c2413.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-==========================
-S3C2413 ARM Linux Overview
-==========================
-
-Introduction
-------------
-
- The S3C2413 is an extended version of the S3C2412, with an camera
- interface and mobile DDR memory support. See the S3C2412 support
- documentation for more information.
-
-
-Camera Interface
-----------------
-
- This block is currently not supported.
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2006 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/smdk2440.rst b/Documentation/arm/samsung-s3c24xx/smdk2440.rst
deleted file mode 100644
index 524fd0b..0000000
--- a/Documentation/arm/samsung-s3c24xx/smdk2440.rst
+++ /dev/null
@@ -1,57 +0,0 @@
-=========================
-Samsung/Meritech SMDK2440
-=========================
-
-Introduction
-------------
-
- The SMDK2440 is a two part evaluation board for the Samsung S3C2440
- processor. It includes support for LCD, SmartMedia, Audio, SD and
- 10MBit Ethernet, and expansion headers for various signals, including
- the camera and unused GPIO.
-
-
-Configuration
--------------
-
- To set the default configuration, use `make smdk2440_defconfig` which
- will configure the common features of this board, or use
- `make s3c2410_config` to include support for all s3c2410/s3c2440 machines
-
-
-Support
--------
-
- Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which
- includes linux based USB download tools.
-
- Some of the h1940 patches that can be found from the H1940 project
- site at http://www.handhelds.org/projects/h1940.html can also be
- applied to this board.
-
-
-Peripherals
------------
-
- There is no current support for any of the extra peripherals on the
- base-board itself.
-
-
-MTD
----
-
- The NAND flash should be supported by the in kernel MTD NAND support,
- NOR flash will be added later.
-
-
-Maintainers
------------
-
- This board is being maintained by Ben Dooks, for more info, see
- http://www.fluff.org/ben/smdk2440/
-
- Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440,
- and to Simtec Electronics for allowing me time to work on this.
-
-
-(c) 2004 Ben Dooks
diff --git a/Documentation/arm/samsung-s3c24xx/suspend.rst b/Documentation/arm/samsung-s3c24xx/suspend.rst
deleted file mode 100644
index b4f3ae9..0000000
--- a/Documentation/arm/samsung-s3c24xx/suspend.rst
+++ /dev/null
@@ -1,137 +0,0 @@
-=======================
-S3C24XX Suspend Support
-=======================
-
-
-Introduction
-------------
-
- The S3C24XX supports a low-power suspend mode, where the SDRAM is kept
- in Self-Refresh mode, and all but the essential peripheral blocks are
- powered down. For more information on how this works, please look
- at the relevant CPU datasheet from Samsung.
-
-
-Requirements
-------------
-
- 1) A bootloader that can support the necessary resume operation
-
- 2) Support for at least 1 source for resume
-
- 3) CONFIG_PM enabled in the kernel
-
- 4) Any peripherals that are going to be powered down at the same
- time require suspend/resume support.
-
-
-Resuming
---------
-
- The S3C2410 user manual defines the process of sending the CPU to
- sleep and how it resumes. The default behaviour of the Linux code
- is to set the GSTATUS3 register to the physical address of the
- code to resume Linux operation.
-
- GSTATUS4 is currently left alone by the sleep code, and is free to
- use for any other purposes (for example, the EB2410ITX uses this to
- save memory configuration in).
-
-
-Machine Support
----------------
-
- The machine specific functions must call the s3c_pm_init() function
- to say that its bootloader is capable of resuming. This can be as
- simple as adding the following to the machine's definition:
-
- INITMACHINE(s3c_pm_init)
-
- A board can do its own setup before calling s3c_pm_init, if it
- needs to setup anything else for power management support.
-
- There is currently no support for over-riding the default method of
- saving the resume address, if your board requires it, then contact
- the maintainer and discuss what is required.
-
- Note, the original method of adding an late_initcall() is wrong,
- and will end up initialising all compiled machines' pm init!
-
- The following is an example of code used for testing wakeup from
- an falling edge on IRQ_EINT0::
-
-
- static irqreturn_t button_irq(int irq, void *pw)
- {
- return IRQ_HANDLED;
- }
-
- statuc void __init machine_init(void)
- {
- ...
-
- request_irq(IRQ_EINT0, button_irq, IRQF_TRIGGER_FALLING,
- "button-irq-eint0", NULL);
-
- enable_irq_wake(IRQ_EINT0);
-
- s3c_pm_init();
- }
-
-
-Debugging
----------
-
- There are several important things to remember when using PM suspend:
-
- 1) The uart drivers will disable the clocks to the UART blocks when
- suspending, which means that use of printascii() or similar direct
- access to the UARTs will cause the debug to stop.
-
- 2) While the pm code itself will attempt to re-enable the UART clocks,
- care should be taken that any external clock sources that the UARTs
- rely on are still enabled at that point.
-
- 3) If any debugging is placed in the resume path, then it must have the
- relevant clocks and peripherals setup before use (ie, bootloader).
-
- For example, if you transmit a character from the UART, the baud
- rate and uart controls must be setup beforehand.
-
-
-Configuration
--------------
-
- The S3C2410 specific configuration in `System Type` defines various
- aspects of how the S3C2410 suspend and resume support is configured
-
- `S3C2410 PM Suspend debug`
-
- This option prints messages to the serial console before and after
- the actual suspend, giving detailed information on what is
- happening
-
-
- `S3C2410 PM Suspend Memory CRC`
-
- Allows the entire memory to be checksummed before and after the
- suspend to see if there has been any corruption of the contents.
-
- Note, the time to calculate the CRC is dependent on the CPU speed
- and the size of memory. For an 64Mbyte RAM area on an 200MHz
- S3C2410, this can take approximately 4 seconds to complete.
-
- This support requires the CRC32 function to be enabled.
-
-
- `S3C2410 PM Suspend CRC Chunksize (KiB)`
-
- Defines the size of memory each CRC chunk covers. A smaller value
- will mean that the CRC data block will take more memory, but will
- identify any faults with better precision
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2004 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/usb-host.rst b/Documentation/arm/samsung-s3c24xx/usb-host.rst
deleted file mode 100644
index 7aaffac..0000000
--- a/Documentation/arm/samsung-s3c24xx/usb-host.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-========================
-S3C24XX USB Host support
-========================
-
-
-
-Introduction
-------------
-
- This document details the S3C2410/S3C2440 in-built OHCI USB host support.
-
-Configuration
--------------
-
- Enable at least the following kernel options:
-
- menuconfig::
-
- Device Drivers --->
- USB support --->
- <*> Support for Host-side USB
- <*> OHCI HCD support
-
-
- .config:
-
- - CONFIG_USB
- - CONFIG_USB_OHCI_HCD
-
-
- Once these options are configured, the standard set of USB device
- drivers can be configured and used.
-
-
-Board Support
--------------
-
- The driver attaches to a platform device, which will need to be
- added by the board specific support file in arch/arm/mach-s3c,
- such as mach-bast.c or mach-smdk2410.c
-
- The platform device's platform_data field is only needed if the
- board implements extra power control or over-current monitoring.
-
- The OHCI driver does not ensure the state of the S3C2410's MISCCTRL
- register, so if both ports are to be used for the host, then it is
- the board support file's responsibility to ensure that the second
- port is configured to be connected to the OHCI core.
-
-
-Platform Data
--------------
-
- See include/linux/platform_data/usb-ohci-s3c2410.h for the
- descriptions of the platform device data. An implementation
- can be found in arch/arm/mach-s3c/simtec-usb.c .
-
- The `struct s3c2410_hcd_info` contains a pair of functions
- that get called to enable over-current detection, and to
- control the port power status.
-
- The ports are numbered 0 and 1.
-
- power_control:
- Called to enable or disable the power on the port.
-
- enable_oc:
- Called to enable or disable the over-current monitoring.
- This should claim or release the resources being used to
- check the power condition on the port, such as an IRQ.
-
- report_oc:
- The OHCI driver fills this field in for the over-current code
- to call when there is a change to the over-current state on
- an port. The ports argument is a bitmask of 1 bit per port,
- with bit X being 1 for an over-current on port X.
-
- The function s3c2410_usb_report_oc() has been provided to
- ensure this is called correctly.
-
- port[x]:
- This is struct describes each port, 0 or 1. The platform driver
- should set the flags field of each port to S3C_HCDFLG_USED if
- the port is enabled.
-
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2005 Simtec Electronics
diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arm/samsung/gpio.rst
index f6e27b0..27fae0d 100644
--- a/Documentation/arm/samsung/gpio.rst
+++ b/Documentation/arm/samsung/gpio.rst
@@ -9,14 +9,6 @@
specific calls provided alongside the drivers/gpio core.
-S3C24XX (Legacy)
-----------------
-
-See Documentation/arm/samsung-s3c24xx/gpio.rst for more information
-about these devices. Their implementation has been brought into line
-with the core samsung implementation described in this document.
-
-
GPIOLIB integration
-------------------
diff --git a/Documentation/arm/samsung/overview.rst b/Documentation/arm/samsung/overview.rst
index e743078..8b15a19 100644
--- a/Documentation/arm/samsung/overview.rst
+++ b/Documentation/arm/samsung/overview.rst
@@ -12,21 +12,10 @@
The currently supported SoCs are:
- - S3C24XX: See Documentation/arm/samsung-s3c24xx/overview.rst for full list
- S3C64XX: S3C6400 and S3C6410
- S5PC110 / S5PV210
-S3C24XX Systems
----------------
-
- There is still documentation in Documnetation/arm/Samsung-S3C24XX/ which
- deals with the architecture and drivers specific to these devices.
-
- See Documentation/arm/samsung-s3c24xx/overview.rst for more information
- on the implementation details and specific support.
-
-
Configuration
-------------
@@ -51,8 +40,6 @@
specific information. It contains the base clock, GPIO and device definitions
to get the system running.
- plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs.
-
plat-s5p is for s5p specific builds, and contains common support for the
S5P specific systems. Not all S5Ps use all the features in this directory
due to differences in the hardware.
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 96fe10e..ffeccdd 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -223,7 +223,7 @@
For systems with a GICv3 interrupt controller to be used in v3 mode:
- If EL3 is present:
- - ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
+ - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
- ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
all CPUs the kernel is executing on, and must stay constant
@@ -369,6 +369,16 @@
- HCR_EL2.ATA (bit 56) must be initialised to 0b1.
+ For CPUs with the Scalable Matrix Extension version 2 (FEAT_SME2):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.EZT0 (bit 30) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1.
+
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level. Where the values documented
diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
index 6fed84f..83e57e4d 100644
--- a/Documentation/arm64/elf_hwcaps.rst
+++ b/Documentation/arm64/elf_hwcaps.rst
@@ -14,7 +14,7 @@
implementations, and/or with certain kernel configurations, but have no
architected discovery mechanism available to userspace code at EL0. The
kernel exposes the presence of these features to userspace through a set
-of flags called hwcaps, exposed in the auxilliary vector.
+of flags called hwcaps, exposed in the auxiliary vector.
Userspace software can test for features by acquiring the AT_HWCAP or
AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
@@ -284,6 +284,24 @@
HWCAP2_SVE2P1
Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0010.
+HWCAP2_SME2
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
+
+HWCAP2_SME2P1
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0010.
+
+HWCAP2_SMEI16I32
+ Functionality implied by ID_AA64SMFR0_EL1.I16I32 == 0b0101
+
+HWCAP2_SMEBI32I32
+ Functionality implied by ID_AA64SMFR0_EL1.BI32I32 == 0b1
+
+HWCAP2_SMEB16B16
+ Functionality implied by ID_AA64SMFR0_EL1.B16B16 == 0b1
+
+HWCAP2_SMEF16F16
+ Functionality implied by ID_AA64SMFR0_EL1.F16F16 == 0b1
+
4. Unused AT_HWCAP bits
-----------------------
diff --git a/Documentation/arm64/sme.rst b/Documentation/arm64/sme.rst
index 16d2db4..1c43ea1 100644
--- a/Documentation/arm64/sme.rst
+++ b/Documentation/arm64/sme.rst
@@ -18,14 +18,19 @@
1. General
-----------
-* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA
- register state and TPIDR2_EL0 are tracked per thread.
+* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA and (when
+ present) ZTn register state and TPIDR2_EL0 are tracked per thread.
* The presence of SME is reported to userspace via HWCAP2_SME in the aux vector
AT_HWCAP2 entry. Presence of this flag implies the presence of the SME
instructions and registers, and the Linux-specific system interfaces
described in this document. SME is reported in /proc/cpuinfo as "sme".
+* The presence of SME2 is reported to userspace via HWCAP2_SME2 in the
+ aux vector AT_HWCAP2 entry. Presence of this flag implies the presence of
+ the SME2 instructions and ZT0, and the Linux-specific system interfaces
+ described in this document. SME2 is reported in /proc/cpuinfo as "sme2".
+
* Support for the execution of SME instructions in userspace can also be
detected by reading the CPU ID register ID_AA64PFR1_EL1 using an MRS
instruction, and checking that the value of the SME field is nonzero. [3]
@@ -44,6 +49,7 @@
HWCAP2_SME_B16F32
HWCAP2_SME_F32F32
HWCAP2_SME_FA64
+ HWCAP2_SME2
This list may be extended over time as the SME architecture evolves.
@@ -52,8 +58,8 @@
cpu-feature-registers.txt for details.
* Debuggers should restrict themselves to interacting with the target via the
- NT_ARM_SVE, NT_ARM_SSVE and NT_ARM_ZA regsets. The recommended way
- of detecting support for these regsets is to connect to a target process
+ NT_ARM_SVE, NT_ARM_SSVE, NT_ARM_ZA and NT_ARM_ZT regsets. The recommended
+ way of detecting support for these regsets is to connect to a target process
first and then attempt a
ptrace(PTRACE_GETREGSET, pid, NT_ARM_<regset>, &iov).
@@ -89,13 +95,13 @@
-------------------------
* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the
- ZA matrix are preserved.
+ ZA matrix and ZTn (if present) are preserved.
* On syscall PSTATE.SM will be cleared and the SVE registers will be handled
as per the standard SVE ABI.
-* Neither the SVE registers nor ZA are used to pass arguments to or receive
- results from any syscall.
+* None of the SVE registers, ZA or ZTn are used to pass arguments to
+ or receive results from any syscall.
* On process creation (eg, clone()) the newly created process will have
PSTATE.SM cleared.
@@ -111,6 +117,9 @@
* Signal handlers are invoked with streaming mode and ZA disabled.
+* A new signal frame record TPIDR2_MAGIC is added formatted as a struct
+ tpidr2_context to allow access to TPIDR2_EL0 from signal handlers.
+
* A new signal frame record za_context encodes the ZA register contents on
signal delivery. [1]
@@ -134,6 +143,14 @@
__reserved[] referencing this space. za_context is then written in the
extra space. Refer to [1] for further details about this mechanism.
+* If ZTn is supported and PSTATE.ZA==1 then a signal frame record for ZTn will
+ be generated.
+
+* The signal record for ZTn has magic ZT_MAGIC (0x5a544e01) and consists of a
+ standard signal frame header followed by a struct zt_context specifying
+ the number of ZTn registers supported by the system, then zt_context.nregs
+ blocks of 64 bytes of data per register.
+
5. Signal return
-----------------
@@ -151,6 +168,9 @@
the signal frame does not match the current vector length, the signal return
attempt is treated as illegal, resulting in a forced SIGSEGV.
+* If ZTn is not supported or PSTATE.ZA==0 then it is illegal to have a
+ signal frame record for ZTn, resulting in a forced SIGSEGV.
+
6. prctl extensions
--------------------
@@ -214,8 +234,8 @@
vector length that will be applied at the next execve() by the calling
thread.
- * Changing the vector length causes all of ZA, P0..P15, FFR and all bits of
- Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
+ * Changing the vector length causes all of ZA, ZTn, P0..P15, FFR and all
+ bits of Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
unspecified, including both streaming and non-streaming SVE state.
Calling PR_SME_SET_VL with vl equal to the thread's current vector
length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
@@ -317,6 +337,15 @@
* The effect of writing a partial, incomplete payload is unspecified.
+* A new regset NT_ARM_ZT is defined for access to ZTn state via
+ PTRACE_GETREGSET and PTRACE_SETREGSET.
+
+* The NT_ARM_ZT regset consists of a single 512 bit register.
+
+* When PSTATE.ZA==0 reads of NT_ARM_ZT will report all bits of ZTn as 0.
+
+* Writes to NT_ARM_ZT will set PSTATE.ZA to 1.
+
8. ELF coredump extensions
---------------------------
@@ -331,6 +360,11 @@
been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread
when the coredump was generated.
+* A NT_ARM_ZT note will be added to each coredump for each thread of the
+ dumped process. The contents will be equivalent to the data that would have
+ been read if a PTRACE_GETREGSET of NT_ARM_ZT were executed for each thread
+ when the coredump was generated.
+
* The NT_ARM_TLS note will be extended to two registers, the second register
will contain TPIDR2_EL0 on systems that support SME and will be read as
zero with writes ignored otherwise.
@@ -406,6 +440,9 @@
For best system performance it is strongly encouraged for software to enable
ZA only when it is actively being used.
+* A new ZT0 register is introduced when SME2 is present. This is a 512 bit
+ register which is accessible when PSTATE.ZA is set, as ZA itself is.
+
* Two new 1 bit fields in PSTATE which may be controlled via the SMSTART and
SMSTOP instructions or by access to the SVCR system register:
diff --git a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst
index c7a356b..1b90a30 100644
--- a/Documentation/arm64/sve.rst
+++ b/Documentation/arm64/sve.rst
@@ -175,7 +175,7 @@
When returning from a signal handler:
* If there is no sve_context record in the signal frame, or if the record is
- present but contains no register data as desribed in the previous section,
+ present but contains no register data as described in the previous section,
then the SVE registers/bits become non-live and take unspecified values.
* If sve_context is present in the signal frame and contains full register
@@ -223,7 +223,7 @@
Defer the requested vector length change until the next execve()
performed by this thread.
- The effect is equivalent to implicit exceution of the following
+ The effect is equivalent to implicit execution of the following
call immediately after the next execve() (if any) by the thread:
prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)
diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
index 0f1ffa03..d7adc6d 100644
--- a/Documentation/atomic_t.txt
+++ b/Documentation/atomic_t.txt
@@ -324,7 +324,7 @@
Specifically 'simple' cmpxchg() loops are expected to not starve one another
indefinitely. However, this is not evident on LL/SC architectures, because
-while an LL/SC architecure 'can/should/must' provide forward progress
+while an LL/SC architecture 'can/should/must' provide forward progress
guarantees between competing LL/SC sections, such a guarantee does not
transfer to cmpxchg() implemented using LL/SC. Consider:
diff --git a/Documentation/block/capability.rst b/Documentation/block/capability.rst
deleted file mode 100644
index 2ae7f06..0000000
--- a/Documentation/block/capability.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-===============================
-Generic Block Device Capability
-===============================
-
-This file documents the sysfs file ``block/<disk>/capability``.
-
-``capability`` is a bitfield, printed in hexadecimal, indicating which
-capabilities a specific block device supports:
-
-.. kernel-doc:: include/linux/blkdev.h
diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst
index c4c73db..10295316 100644
--- a/Documentation/block/index.rst
+++ b/Documentation/block/index.rst
@@ -10,7 +10,6 @@
bfq-iosched
biovecs
blk-mq
- capability
cmdline-partition
data-integrity
deadline-iosched
diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst
index ba45c46..1713b28 100644
--- a/Documentation/block/ublk.rst
+++ b/Documentation/block/ublk.rst
@@ -144,6 +144,43 @@
For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's
responsibility to save IO target specific info in userspace.
+- ``UBLK_CMD_GET_DEV_INFO2``
+ Same purpose with ``UBLK_CMD_GET_DEV_INFO``, but ublk server has to
+ provide path of the char device of ``/dev/ublkc*`` for kernel to run
+ permission check, and this command is added for supporting unprivileged
+ ublk device, and introduced with ``UBLK_F_UNPRIVILEGED_DEV`` together.
+ Only the user owning the requested device can retrieve the device info.
+
+ How to deal with userspace/kernel compatibility:
+
+ 1) if kernel is capable of handling ``UBLK_F_UNPRIVILEGED_DEV``
+
+ If ublk server supports ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ublk server should send ``UBLK_CMD_GET_DEV_INFO2``, given anytime
+ unprivileged application needs to query devices the current user owns,
+ when the application has no idea if ``UBLK_F_UNPRIVILEGED_DEV`` is set
+ given the capability info is stateless, and application should always
+ retrieve it via ``UBLK_CMD_GET_DEV_INFO2``
+
+ If ublk server doesn't support ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ``UBLK_CMD_GET_DEV_INFO`` is always sent to kernel, and the feature of
+ UBLK_F_UNPRIVILEGED_DEV isn't available for user
+
+ 2) if kernel isn't capable of handling ``UBLK_F_UNPRIVILEGED_DEV``
+
+ If ublk server supports ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ``UBLK_CMD_GET_DEV_INFO2`` is tried first, and will be failed, then
+ ``UBLK_CMD_GET_DEV_INFO`` needs to be retried given
+ ``UBLK_F_UNPRIVILEGED_DEV`` can't be set
+
+ If ublk server doesn't support ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ``UBLK_CMD_GET_DEV_INFO`` is always sent to kernel, and the feature of
+ ``UBLK_F_UNPRIVILEGED_DEV`` isn't available for user
+
- ``UBLK_CMD_START_USER_RECOVERY``
This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This
@@ -180,6 +217,15 @@
double-write since the driver may issue the same I/O request twice. It
might be useful to a read-only FS or a VM backend.
+Unprivileged ublk device is supported by passing ``UBLK_F_UNPRIVILEGED_DEV``.
+Once the flag is set, all control commands can be sent by unprivileged
+user. Except for command of ``UBLK_CMD_ADD_DEV``, permission check on
+the specified char device(``/dev/ublkc*``) is done for all other control
+commands by ublk driver, for doing that, path of the char device has to
+be provided in these commands' payload from ublk server. With this way,
+ublk device becomes container-ware, and device created in one container
+can be controlled/accessed just inside this container.
+
Data plane
----------
@@ -254,15 +300,6 @@
Future development
==================
-Container-aware ublk deivice
-----------------------------
-
-ublk driver doesn't handle any IO logic. Its function is well defined
-for now and very limited userspace interfaces are needed, which is also
-well defined too. It is possible to make ublk devices container-aware block
-devices in future as Stefan Hajnoczi suggested [#stefan]_, by removing
-ADMIN privilege.
-
Zero copy
---------
diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
index cec2371..bfff0e7 100644
--- a/Documentation/bpf/bpf_design_QA.rst
+++ b/Documentation/bpf/bpf_design_QA.rst
@@ -208,6 +208,10 @@
kernel internals are subject to change and can break with newer kernels
such that the program needs to be adapted accordingly.
+New BPF functionality is generally added through the use of kfuncs instead of
+new helpers. Kfuncs are not considered part of the stable API, and have their own
+lifecycle expectations as described in :ref:`BPF_kfunc_lifecycle_expectations`.
+
Q: Are tracepoints part of the stable ABI?
------------------------------------------
A: NO. Tracepoints are tied to internal implementation details hence they are
@@ -236,8 +240,8 @@
Q: Can BPF call arbitrary kernel functions?
-------------------------------------------
-A: NO. BPF programs can only call a set of helper functions which
-is defined for every program type.
+A: NO. BPF programs can only call specific functions exposed as BPF helpers or
+kfuncs. The set of available functions is defined for every program type.
Q: Can BPF overwrite arbitrary kernel memory?
---------------------------------------------
@@ -263,7 +267,12 @@
Q: Can BPF functionality such as new program or map types, new
helpers, etc be added out of kernel module code?
-A: NO.
+A: Yes, through kfuncs and kptrs
+
+The core BPF functionality such as program types, maps and helpers cannot be
+added to by modules. However, modules can expose functionality to BPF programs
+by exporting kfuncs (which may return pointers to module-internal data
+structures as kptrs).
Q: Directly calling kernel function is an ABI?
----------------------------------------------
@@ -278,7 +287,8 @@
cc (congestion-control) implementations. If any of these kernel
functions has changed, both the in-tree and out-of-tree kernel tcp cc
implementations have to be changed. The same goes for the bpf
-programs and they have to be adjusted accordingly.
+programs and they have to be adjusted accordingly. See
+:ref:`BPF_kfunc_lifecycle_expectations` for details.
Q: Attaching to arbitrary kernel functions is an ABI?
-----------------------------------------------------
@@ -340,6 +350,7 @@
A: NO.
-Unlike map value types, there are no stability guarantees for this case. The
-whole API to work with allocated objects and any support for special fields
-inside them is unstable (since it is exposed through kfuncs).
+Unlike map value types, the API to work with allocated objects and any support
+for special fields inside them is exposed through kfuncs, and thus has the same
+lifecycle expectations as the kfuncs themselves. See
+:ref:`BPF_kfunc_lifecycle_expectations` for details.
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
index 03d4993..b421d94 100644
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@ -7,8 +7,8 @@
patches for stable kernels.
For general information about submitting patches, please refer to
-`Documentation/process/`_. This document only describes additional specifics
-related to BPF.
+Documentation/process/submitting-patches.rst. This document only describes
+additional specifics related to BPF.
.. contents::
:local:
@@ -461,15 +461,15 @@
$ sudo make run_tests
-See the kernels selftest `Documentation/dev-tools/kselftest.rst`_
-document for further documentation.
+See :doc:`kernel selftest documentation </dev-tools/kselftest>`
+for details.
To maximize the number of tests passing, the .config of the kernel
under test should match the config file fragment in
tools/testing/selftests/bpf as closely as possible.
Finally to ensure support for latest BPF Type Format features -
-discussed in `Documentation/bpf/btf.rst`_ - pahole version 1.16
+discussed in Documentation/bpf/btf.rst - pahole version 1.16
is required for kernels built with CONFIG_DEBUG_INFO_BTF=y.
pahole is delivered in the dwarves package or can be built
from source at
@@ -684,12 +684,8 @@
.. Links
-.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
.. _selftests:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
-.. _Documentation/dev-tools/kselftest.rst:
- https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
-.. _Documentation/bpf/btf.rst: btf.rst
Happy BPF hacking!
diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst
new file mode 100644
index 0000000..24bef9c
--- /dev/null
+++ b/Documentation/bpf/cpumasks.rst
@@ -0,0 +1,393 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _cpumasks-header-label:
+
+==================
+BPF cpumask kfuncs
+==================
+
+1. Introduction
+===============
+
+``struct cpumask`` is a bitmap data structure in the kernel whose indices
+reflect the CPUs on the system. Commonly, cpumasks are used to track which CPUs
+a task is affinitized to, but they can also be used to e.g. track which cores
+are associated with a scheduling domain, which cores on a machine are idle,
+etc.
+
+BPF provides programs with a set of :ref:`kfuncs-header-label` that can be
+used to allocate, mutate, query, and free cpumasks.
+
+2. BPF cpumask objects
+======================
+
+There are two different types of cpumasks that can be used by BPF programs.
+
+2.1 ``struct bpf_cpumask *``
+----------------------------
+
+``struct bpf_cpumask *`` is a cpumask that is allocated by BPF, on behalf of a
+BPF program, and whose lifecycle is entirely controlled by BPF. These cpumasks
+are RCU-protected, can be mutated, can be used as kptrs, and can be safely cast
+to a ``struct cpumask *``.
+
+2.1.1 ``struct bpf_cpumask *`` lifecycle
+----------------------------------------
+
+A ``struct bpf_cpumask *`` is allocated, acquired, and released, using the
+following functions:
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_create
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_acquire
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_release
+
+For example:
+
+.. code-block:: c
+
+ struct cpumask_map_value {
+ struct bpf_cpumask __kptr_ref * cpumask;
+ };
+
+ struct array_map {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, int);
+ __type(value, struct cpumask_map_value);
+ __uint(max_entries, 65536);
+ } cpumask_map SEC(".maps");
+
+ static int cpumask_map_insert(struct bpf_cpumask *mask, u32 pid)
+ {
+ struct cpumask_map_value local, *v;
+ long status;
+ struct bpf_cpumask *old;
+ u32 key = pid;
+
+ local.cpumask = NULL;
+ status = bpf_map_update_elem(&cpumask_map, &key, &local, 0);
+ if (status) {
+ bpf_cpumask_release(mask);
+ return status;
+ }
+
+ v = bpf_map_lookup_elem(&cpumask_map, &key);
+ if (!v) {
+ bpf_cpumask_release(mask);
+ return -ENOENT;
+ }
+
+ old = bpf_kptr_xchg(&v->cpumask, mask);
+ if (old)
+ bpf_cpumask_release(old);
+
+ return 0;
+ }
+
+ /**
+ * A sample tracepoint showing how a task's cpumask can be queried and
+ * recorded as a kptr.
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(record_task_cpumask, struct task_struct *task, u64 clone_flags)
+ {
+ struct bpf_cpumask *cpumask;
+ int ret;
+
+ cpumask = bpf_cpumask_create();
+ if (!cpumask)
+ return -ENOMEM;
+
+ if (!bpf_cpumask_full(task->cpus_ptr))
+ bpf_printk("task %s has CPU affinity", task->comm);
+
+ bpf_cpumask_copy(cpumask, task->cpus_ptr);
+ return cpumask_map_insert(cpumask, task->pid);
+ }
+
+----
+
+2.1.1 ``struct bpf_cpumask *`` as kptrs
+---------------------------------------
+
+As mentioned and illustrated above, these ``struct bpf_cpumask *`` objects can
+also be stored in a map and used as kptrs. If a ``struct bpf_cpumask *`` is in
+a map, the reference can be removed from the map with bpf_kptr_xchg(), or
+opportunistically acquired with bpf_cpumask_kptr_get():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_kptr_get
+
+Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
+
+.. code-block:: c
+
+ /* struct containing the struct bpf_cpumask kptr which is stored in the map. */
+ struct cpumasks_kfunc_map_value {
+ struct bpf_cpumask __kptr_ref * bpf_cpumask;
+ };
+
+ /* The map containing struct cpumasks_kfunc_map_value entries. */
+ struct {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, int);
+ __type(value, struct cpumasks_kfunc_map_value);
+ __uint(max_entries, 1);
+ } cpumasks_kfunc_map SEC(".maps");
+
+ /* ... */
+
+ /**
+ * A simple example tracepoint program showing how a
+ * struct bpf_cpumask * kptr that is stored in a map can
+ * be acquired using the bpf_cpumask_kptr_get() kfunc.
+ */
+ SEC("tp_btf/cgroup_mkdir")
+ int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path)
+ {
+ struct bpf_cpumask *kptr;
+ struct cpumasks_kfunc_map_value *v;
+ u32 key = 0;
+
+ /* Assume a bpf_cpumask * kptr was previously stored in the map. */
+ v = bpf_map_lookup_elem(&cpumasks_kfunc_map, &key);
+ if (!v)
+ return -ENOENT;
+
+ /* Acquire a reference to the bpf_cpumask * kptr that's already stored in the map. */
+ kptr = bpf_cpumask_kptr_get(&v->cpumask);
+ if (!kptr)
+ /* If no bpf_cpumask was present in the map, it's because
+ * we're racing with another CPU that removed it with
+ * bpf_kptr_xchg() between the bpf_map_lookup_elem()
+ * above, and our call to bpf_cpumask_kptr_get().
+ * bpf_cpumask_kptr_get() internally safely handles this
+ * race, and will return NULL if the cpumask is no longer
+ * present in the map by the time we invoke the kfunc.
+ */
+ return -EBUSY;
+
+ /* Free the reference we just took above. Note that the
+ * original struct bpf_cpumask * kptr is still in the map. It will
+ * be freed either at a later time if another context deletes
+ * it from the map, or automatically by the BPF subsystem if
+ * it's still present when the map is destroyed.
+ */
+ bpf_cpumask_release(kptr);
+
+ return 0;
+ }
+
+----
+
+2.2 ``struct cpumask``
+----------------------
+
+``struct cpumask`` is the object that actually contains the cpumask bitmap
+being queried, mutated, etc. A ``struct bpf_cpumask`` wraps a ``struct
+cpumask``, which is why it's safe to cast it as such (note however that it is
+**not** safe to cast a ``struct cpumask *`` to a ``struct bpf_cpumask *``, and
+the verifier will reject any program that tries to do so).
+
+As we'll see below, any kfunc that mutates its cpumask argument will take a
+``struct bpf_cpumask *`` as that argument. Any argument that simply queries the
+cpumask will instead take a ``struct cpumask *``.
+
+3. cpumask kfuncs
+=================
+
+Above, we described the kfuncs that can be used to allocate, acquire, release,
+etc a ``struct bpf_cpumask *``. This section of the document will describe the
+kfuncs for mutating and querying cpumasks.
+
+3.1 Mutating cpumasks
+---------------------
+
+Some cpumask kfuncs are "read-only" in that they don't mutate any of their
+arguments, whereas others mutate at least one argument (which means that the
+argument must be a ``struct bpf_cpumask *``, as described above).
+
+This section will describe all of the cpumask kfuncs which mutate at least one
+argument. :ref:`cpumasks-querying-label` below describes the read-only kfuncs.
+
+3.1.1 Setting and clearing CPUs
+-------------------------------
+
+bpf_cpumask_set_cpu() and bpf_cpumask_clear_cpu() can be used to set and clear
+a CPU in a ``struct bpf_cpumask`` respectively:
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_set_cpu bpf_cpumask_clear_cpu
+
+These kfuncs are pretty straightforward, and can be used, for example, as
+follows:
+
+.. code-block:: c
+
+ /**
+ * A sample tracepoint showing how a cpumask can be queried.
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(test_set_clear_cpu, struct task_struct *task, u64 clone_flags)
+ {
+ struct bpf_cpumask *cpumask;
+
+ cpumask = bpf_cpumask_create();
+ if (!cpumask)
+ return -ENOMEM;
+
+ bpf_cpumask_set_cpu(0, cpumask);
+ if (!bpf_cpumask_test_cpu(0, cast(cpumask)))
+ /* Should never happen. */
+ goto release_exit;
+
+ bpf_cpumask_clear_cpu(0, cpumask);
+ if (bpf_cpumask_test_cpu(0, cast(cpumask)))
+ /* Should never happen. */
+ goto release_exit;
+
+ /* struct cpumask * pointers such as task->cpus_ptr can also be queried. */
+ if (bpf_cpumask_test_cpu(0, task->cpus_ptr))
+ bpf_printk("task %s can use CPU %d", task->comm, 0);
+
+ release_exit:
+ bpf_cpumask_release(cpumask);
+ return 0;
+ }
+
+----
+
+bpf_cpumask_test_and_set_cpu() and bpf_cpumask_test_and_clear_cpu() are
+complementary kfuncs that allow callers to atomically test and set (or clear)
+CPUs:
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_test_and_set_cpu bpf_cpumask_test_and_clear_cpu
+
+----
+
+We can also set and clear entire ``struct bpf_cpumask *`` objects in one
+operation using bpf_cpumask_setall() and bpf_cpumask_clear():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_setall bpf_cpumask_clear
+
+3.1.2 Operations between cpumasks
+---------------------------------
+
+In addition to setting and clearing individual CPUs in a single cpumask,
+callers can also perform bitwise operations between multiple cpumasks using
+bpf_cpumask_and(), bpf_cpumask_or(), and bpf_cpumask_xor():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_and bpf_cpumask_or bpf_cpumask_xor
+
+The following is an example of how they may be used. Note that some of the
+kfuncs shown in this example will be covered in more detail below.
+
+.. code-block:: c
+
+ /**
+ * A sample tracepoint showing how a cpumask can be mutated using
+ bitwise operators (and queried).
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(test_and_or_xor, struct task_struct *task, u64 clone_flags)
+ {
+ struct bpf_cpumask *mask1, *mask2, *dst1, *dst2;
+
+ mask1 = bpf_cpumask_create();
+ if (!mask1)
+ return -ENOMEM;
+
+ mask2 = bpf_cpumask_create();
+ if (!mask2) {
+ bpf_cpumask_release(mask1);
+ return -ENOMEM;
+ }
+
+ // ...Safely create the other two masks... */
+
+ bpf_cpumask_set_cpu(0, mask1);
+ bpf_cpumask_set_cpu(1, mask2);
+ bpf_cpumask_and(dst1, (const struct cpumask *)mask1, (const struct cpumask *)mask2);
+ if (!bpf_cpumask_empty((const struct cpumask *)dst1))
+ /* Should never happen. */
+ goto release_exit;
+
+ bpf_cpumask_or(dst1, (const struct cpumask *)mask1, (const struct cpumask *)mask2);
+ if (!bpf_cpumask_test_cpu(0, (const struct cpumask *)dst1))
+ /* Should never happen. */
+ goto release_exit;
+
+ if (!bpf_cpumask_test_cpu(1, (const struct cpumask *)dst1))
+ /* Should never happen. */
+ goto release_exit;
+
+ bpf_cpumask_xor(dst2, (const struct cpumask *)mask1, (const struct cpumask *)mask2);
+ if (!bpf_cpumask_equal((const struct cpumask *)dst1,
+ (const struct cpumask *)dst2))
+ /* Should never happen. */
+ goto release_exit;
+
+ release_exit:
+ bpf_cpumask_release(mask1);
+ bpf_cpumask_release(mask2);
+ bpf_cpumask_release(dst1);
+ bpf_cpumask_release(dst2);
+ return 0;
+ }
+
+----
+
+The contents of an entire cpumask may be copied to another using
+bpf_cpumask_copy():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_copy
+
+----
+
+.. _cpumasks-querying-label:
+
+3.2 Querying cpumasks
+---------------------
+
+In addition to the above kfuncs, there is also a set of read-only kfuncs that
+can be used to query the contents of cpumasks.
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_first bpf_cpumask_first_zero bpf_cpumask_test_cpu
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_equal bpf_cpumask_intersects bpf_cpumask_subset
+ bpf_cpumask_empty bpf_cpumask_full
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_any bpf_cpumask_any_and
+
+----
+
+Some example usages of these querying kfuncs were shown above. We will not
+replicate those exmaples here. Note, however, that all of the aforementioned
+kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so
+please take a look there if you're looking for more examples of how they can be
+used.
+
+.. _tools/testing/selftests/bpf/progs/cpumask_success.c:
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/bpf/progs/cpumask_success.c
+
+
+4. Adding BPF cpumask kfuncs
+============================
+
+The set of supported BPF cpumask kfuncs are not (yet) a 1-1 match with the
+cpumask operations in include/linux/cpumask.h. Any of those cpumask operations
+could easily be encapsulated in a new kfunc if and when required. If you'd like
+to support a new cpumask operation, please feel free to submit a patch. If you
+do add a new cpumask kfunc, please document it here, and add any relevant
+selftest testcases to the cpumask selftest suite.
diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
new file mode 100644
index 0000000..6127462
--- /dev/null
+++ b/Documentation/bpf/graph_ds_impl.rst
@@ -0,0 +1,267 @@
+=========================
+BPF Graph Data Structures
+=========================
+
+This document describes implementation details of new-style "graph" data
+structures (linked_list, rbtree), with particular focus on the verifier's
+implementation of semantics specific to those data structures.
+
+Although no specific verifier code is referred to in this document, the document
+assumes that the reader has general knowledge of BPF verifier internals, BPF
+maps, and BPF program writing.
+
+Note that the intent of this document is to describe the current state of
+these graph data structures. **No guarantees** of stability for either
+semantics or APIs are made or implied here.
+
+.. contents::
+ :local:
+ :depth: 2
+
+Introduction
+------------
+
+The BPF map API has historically been the main way to expose data structures
+of various types for use within BPF programs. Some data structures fit naturally
+with the map API (HASH, ARRAY), others less so. Consequentially, programs
+interacting with the latter group of data structures can be hard to parse
+for kernel programmers without previous BPF experience.
+
+Luckily, some restrictions which necessitated the use of BPF map semantics are
+no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
+BPF allocator, it is now possible to implement BPF data structures whose API
+and semantics more closely match those exposed to the rest of the kernel.
+
+Two such data structures - linked_list and rbtree - have many verification
+details in common. Because both have "root"s ("head" for linked_list) and
+"node"s, the verifier code and this document refer to common functionality
+as "graph_api", "graph_root", "graph_node", etc.
+
+Unless otherwise stated, examples and semantics below apply to both graph data
+structures.
+
+Unstable API
+------------
+
+Data structures implemented using the BPF map API have historically used BPF
+helper functions - either standard map API helpers like ``bpf_map_update_elem``
+or map-specific helpers. The new-style graph data structures instead use kfuncs
+to define their manipulation helpers. Because there are no stability guarantees
+for kfuncs, the API and semantics for these data structures can be evolved in
+a way that breaks backwards compatibility if necessary.
+
+Root and node types for the new data structures are opaquely defined in the
+``uapi/linux/bpf.h`` header.
+
+Locking
+-------
+
+The new-style data structures are intrusive and are defined similarly to their
+vanilla kernel counterparts:
+
+.. code-block:: c
+
+ struct node_data {
+ long key;
+ long data;
+ struct bpf_rb_node node;
+ };
+
+ struct bpf_spin_lock glock;
+ struct bpf_rb_root groot __contains(node_data, node);
+
+The "root" type for both linked_list and rbtree expects to be in a map_value
+which also contains a ``bpf_spin_lock`` - in the above example both global
+variables are placed in a single-value arraymap. The verifier considers this
+spin_lock to be associated with the ``bpf_rb_root`` by virtue of both being in
+the same map_value and will enforce that the correct lock is held when
+verifying BPF programs that manipulate the tree. Since this lock checking
+happens at verification time, there is no runtime penalty.
+
+Non-owning references
+---------------------
+
+**Motivation**
+
+Consider the following BPF code:
+
+.. code-block:: c
+
+ struct node_data *n = bpf_obj_new(typeof(*n)); /* ACQUIRED */
+
+ bpf_spin_lock(&lock);
+
+ bpf_rbtree_add(&tree, n); /* PASSED */
+
+ bpf_spin_unlock(&lock);
+
+From the verifier's perspective, the pointer ``n`` returned from ``bpf_obj_new``
+has type ``PTR_TO_BTF_ID | MEM_ALLOC``, with a ``btf_id`` of
+``struct node_data`` and a nonzero ``ref_obj_id``. Because it holds ``n``, the
+program has ownership of the pointee's (object pointed to by ``n``) lifetime.
+The BPF program must pass off ownership before exiting - either via
+``bpf_obj_drop``, which ``free``'s the object, or by adding it to ``tree`` with
+``bpf_rbtree_add``.
+
+(``ACQUIRED`` and ``PASSED`` comments in the example denote statements where
+"ownership is acquired" and "ownership is passed", respectively)
+
+What should the verifier do with ``n`` after ownership is passed off? If the
+object was ``free``'d with ``bpf_obj_drop`` the answer is obvious: the verifier
+should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as
+the object is no longer valid. The underlying memory may have been reused for
+some other allocation, unmapped, etc.
+
+When ownership is passed to ``tree`` via ``bpf_rbtree_add`` the answer is less
+obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
+but that would result in programs with useful, common coding patterns being
+rejected, e.g.:
+
+.. code-block:: c
+
+ int x;
+ struct node_data *n = bpf_obj_new(typeof(*n)); /* ACQUIRED */
+
+ bpf_spin_lock(&lock);
+
+ bpf_rbtree_add(&tree, n); /* PASSED */
+ x = n->data;
+ n->data = 42;
+
+ bpf_spin_unlock(&lock);
+
+Both the read from and write to ``n->data`` would be rejected. The verifier
+can do better, though, by taking advantage of two details:
+
+ * Graph data structure APIs can only be used when the ``bpf_spin_lock``
+ associated with the graph root is held
+
+ * Both graph data structures have pointer stability
+
+ * Because graph nodes are allocated with ``bpf_obj_new`` and
+ adding / removing from the root involves fiddling with the
+ ``bpf_{list,rb}_node`` field of the node struct, a graph node will
+ remain at the same address after either operation.
+
+Because the associated ``bpf_spin_lock`` must be held by any program adding
+or removing, if we're in the critical section bounded by that lock, we know
+that no other program can add or remove until the end of the critical section.
+This combined with pointer stability means that, until the critical section
+ends, we can safely access the graph node through ``n`` even after it was used
+to pass ownership.
+
+The verifier considers such a reference a *non-owning reference*. The ref
+returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
+Both terms currently only have meaning in the context of graph nodes and API.
+
+**Details**
+
+Let's enumerate the properties of both types of references.
+
+*owning reference*
+
+ * This reference controls the lifetime of the pointee
+
+ * Ownership of pointee must be 'released' by passing it to some graph API
+ kfunc, or via ``bpf_obj_drop``, which ``free``'s the pointee
+
+ * If not released before program ends, verifier considers program invalid
+
+ * Access to the pointee's memory will not page fault
+
+*non-owning reference*
+
+ * This reference does not own the pointee
+
+ * It cannot be used to add the graph node to a graph root, nor ``free``'d via
+ ``bpf_obj_drop``
+
+ * No explicit control of lifetime, but can infer valid lifetime based on
+ non-owning ref existence (see explanation below)
+
+ * Access to the pointee's memory will not page fault
+
+From verifier's perspective non-owning references can only exist
+between spin_lock and spin_unlock. Why? After spin_unlock another program
+can do arbitrary operations on the data structure like removing and ``free``-ing
+via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,
+``free``'d, and reused via bpf_obj_new would point to an entirely different thing.
+Or the memory could go away.
+
+To prevent this logic violation all non-owning references are invalidated by the
+verifier after a critical section ends. This is necessary to ensure the "will
+not page fault" property of non-owning references. So if the verifier hasn't
+invalidated a non-owning ref, accessing it will not page fault.
+
+Currently ``bpf_obj_drop`` is not allowed in the critical section, so
+if there's a valid non-owning ref, we must be in a critical section, and can
+conclude that the ref's memory hasn't been dropped-and- ``free``'d or
+dropped-and-reused.
+
+Any reference to a node that is in an rbtree _must_ be non-owning, since
+the tree has control of the pointee's lifetime. Similarly, any ref to a node
+that isn't in rbtree _must_ be owning. This results in a nice property:
+graph API add / remove implementations don't need to check if a node
+has already been added (or already removed), as the ownership model
+allows the verifier to prevent such a state from being valid by simply checking
+types.
+
+However, pointer aliasing poses an issue for the above "nice property".
+Consider the following example:
+
+.. code-block:: c
+
+ struct node_data *n, *m, *o, *p;
+ n = bpf_obj_new(typeof(*n)); /* 1 */
+
+ bpf_spin_lock(&lock);
+
+ bpf_rbtree_add(&tree, n); /* 2 */
+ m = bpf_rbtree_first(&tree); /* 3 */
+
+ o = bpf_rbtree_remove(&tree, n); /* 4 */
+ p = bpf_rbtree_remove(&tree, m); /* 5 */
+
+ bpf_spin_unlock(&lock);
+
+ bpf_obj_drop(o);
+ bpf_obj_drop(p); /* 6 */
+
+Assume the tree is empty before this program runs. If we track verifier state
+changes here using numbers in above comments:
+
+ 1) n is an owning reference
+
+ 2) n is a non-owning reference, it's been added to the tree
+
+ 3) n and m are non-owning references, they both point to the same node
+
+ 4) o is an owning reference, n and m non-owning, all point to same node
+
+ 5) o and p are owning, n and m non-owning, all point to the same node
+
+ 6) a double-free has occurred, since o and p point to same node and o was
+ ``free``'d in previous statement
+
+States 4 and 5 violate our "nice property", as there are non-owning refs to
+a node which is not in an rbtree. Statement 5 will try to remove a node which
+has already been removed as a result of this violation. State 6 is a dangerous
+double-free.
+
+At a minimum we should prevent state 6 from being possible. If we can't also
+prevent state 5 then we must abandon our "nice property" and check whether a
+node has already been removed at runtime.
+
+We prevent both by generalizing the "invalidate non-owning references" behavior
+of ``bpf_spin_unlock`` and doing similar invalidation after
+``bpf_rbtree_remove``. The logic here being that any graph API kfunc which:
+
+ * takes an arbitrary node argument
+
+ * removes it from the data structure
+
+ * returns an owning reference to the removed node
+
+May result in a state where some other non-owning reference points to the same
+node. So ``remove``-type kfuncs must be considered a non-owning reference
+invalidation point as well.
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
index b81533d..dbb39e8 100644
--- a/Documentation/bpf/index.rst
+++ b/Documentation/bpf/index.rst
@@ -20,6 +20,7 @@
syscall_api
helpers
kfuncs
+ cpumasks
programs
maps
bpf_prog_run
diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst
index e672d5e..af515de 100644
--- a/Documentation/bpf/instruction-set.rst
+++ b/Documentation/bpf/instruction-set.rst
@@ -7,6 +7,11 @@
This document specifies version 1.0 of the eBPF instruction set.
+Documentation conventions
+=========================
+
+For brevity, this document uses the type notion "u64", "u32", etc.
+to mean an unsigned integer whose width is the specified number of bits.
Registers and calling convention
================================
@@ -30,20 +35,56 @@
eBPF has two instruction encodings:
* the basic instruction encoding, which uses 64 bits to encode an instruction
-* the wide instruction encoding, which appends a second 64-bit immediate value
- (imm64) after the basic instruction for a total of 128 bits.
+* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
+ constant) value after the basic instruction for a total of 128 bits.
-The basic instruction encoding looks as follows:
+The basic instruction encoding is as follows, where MSB and LSB mean the most significant
+bits and least significant bits, respectively:
-============= ======= =============== ==================== ============
-32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
-============= ======= =============== ==================== ============
-immediate offset source register destination register opcode
-============= ======= =============== ==================== ============
+============= ======= ======= ======= ============
+32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
+============= ======= ======= ======= ============
+imm offset src_reg dst_reg opcode
+============= ======= ======= ======= ============
+
+**imm**
+ signed integer immediate value
+
+**offset**
+ signed integer offset used with pointer arithmetic
+
+**src_reg**
+ the source register number (0-10), except where otherwise specified
+ (`64-bit immediate instructions`_ reuse this field for other purposes)
+
+**dst_reg**
+ destination register number (0-10)
+
+**opcode**
+ operation to perform
Note that most instructions do not use all of the fields.
Unused fields shall be cleared to zero.
+As discussed below in `64-bit immediate instructions`_, a 64-bit immediate
+instruction uses a 64-bit immediate value that is constructed as follows.
+The 64 bits following the basic instruction contain a pseudo instruction
+using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
+and imm containing the high 32 bits of the immediate value.
+
+================= ==================
+64 bits (MSB) 64 bits (LSB)
+================= ==================
+basic instruction pseudo instruction
+================= ==================
+
+Thus the 64-bit immediate value is constructed as follows:
+
+ imm64 = (next_imm << 32) | imm
+
+where 'next_imm' refers to the imm value of the pseudo instruction
+following the basic instruction.
+
Instruction classes
-------------------
@@ -71,27 +112,32 @@
============== ====== =================
4 bits (MSB) 1 bit 3 bits (LSB)
============== ====== =================
-operation code source instruction class
+code source instruction class
============== ====== =================
-The 4th bit encodes the source operand:
+**code**
+ the operation code, whose meaning varies by instruction class
- ====== ===== ========================================
+**source**
+ the source operand location, which unless otherwise specified is one of:
+
+ ====== ===== ==============================================
source value description
- ====== ===== ========================================
- BPF_K 0x00 use 32-bit immediate as source operand
- BPF_X 0x08 use 'src_reg' register as source operand
- ====== ===== ========================================
+ ====== ===== ==============================================
+ BPF_K 0x00 use 32-bit 'imm' value as source operand
+ BPF_X 0x08 use 'src_reg' register value as source operand
+ ====== ===== ==============================================
-The four MSB bits store the operation code.
-
+**instruction class**
+ the instruction class (see `Instruction classes`_)
Arithmetic instructions
-----------------------
``BPF_ALU`` uses 32-bit wide operands while ``BPF_ALU64`` uses 64-bit wide operands for
otherwise identical operations.
-The 'code' field encodes the operation as below:
+The 'code' field encodes the operation as below, where 'src' and 'dst' refer
+to the values of the source and destination registers, respectively.
======== ===== ==========================================================
code value description
@@ -99,35 +145,49 @@
BPF_ADD 0x00 dst += src
BPF_SUB 0x10 dst -= src
BPF_MUL 0x20 dst \*= src
-BPF_DIV 0x30 dst /= src
+BPF_DIV 0x30 dst = (src != 0) ? (dst / src) : 0
BPF_OR 0x40 dst \|= src
BPF_AND 0x50 dst &= src
BPF_LSH 0x60 dst <<= src
BPF_RSH 0x70 dst >>= src
BPF_NEG 0x80 dst = ~src
-BPF_MOD 0x90 dst %= src
+BPF_MOD 0x90 dst = (src != 0) ? (dst % src) : dst
BPF_XOR 0xa0 dst ^= src
BPF_MOV 0xb0 dst = src
BPF_ARSH 0xc0 sign extending shift right
BPF_END 0xd0 byte swap operations (see `Byte swap instructions`_ below)
======== ===== ==========================================================
+Underflow and overflow are allowed during arithmetic operations, meaning
+the 64-bit or 32-bit value will wrap. If eBPF program execution would
+result in division by zero, the destination register is instead set to zero.
+If execution would result in modulo by zero, for ``BPF_ALU64`` the value of
+the destination register is unchanged whereas for ``BPF_ALU`` the upper
+32 bits of the destination register are zeroed.
+
``BPF_ADD | BPF_X | BPF_ALU`` means::
- dst_reg = (u32) dst_reg + (u32) src_reg;
+ dst = (u32) ((u32) dst + (u32) src)
+
+where '(u32)' indicates that the upper 32 bits are zeroed.
``BPF_ADD | BPF_X | BPF_ALU64`` means::
- dst_reg = dst_reg + src_reg
+ dst = dst + src
``BPF_XOR | BPF_K | BPF_ALU`` means::
- dst_reg = (u32) dst_reg ^ (u32) imm32
+ dst = (u32) dst ^ (u32) imm32
``BPF_XOR | BPF_K | BPF_ALU64`` means::
- dst_reg = dst_reg ^ imm32
+ dst = dst ^ imm32
+Also note that the division and modulo operations are unsigned. Thus, for
+``BPF_ALU``, 'imm' is first interpreted as an unsigned 32-bit value, whereas
+for ``BPF_ALU64``, 'imm' is first sign extended to 64 bits and the result
+interpreted as an unsigned 64-bit value. There are no instructions for
+signed division or modulo.
Byte swap instructions
~~~~~~~~~~~~~~~~~~~~~~
@@ -155,11 +215,11 @@
``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means::
- dst_reg = htole16(dst_reg)
+ dst = htole16(dst)
``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means::
- dst_reg = htobe64(dst_reg)
+ dst = htobe64(dst)
Jump instructions
-----------------
@@ -234,15 +294,15 @@
``BPF_MEM | <size> | BPF_STX`` means::
- *(size *) (dst_reg + off) = src_reg
+ *(size *) (dst + offset) = src
``BPF_MEM | <size> | BPF_ST`` means::
- *(size *) (dst_reg + off) = imm32
+ *(size *) (dst + offset) = imm32
``BPF_MEM | <size> | BPF_LDX`` means::
- dst_reg = *(size *) (src_reg + off)
+ dst = *(size *) (src + offset)
Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``.
@@ -276,11 +336,11 @@
``BPF_ATOMIC | BPF_W | BPF_STX`` with 'imm' = BPF_ADD means::
- *(u32 *)(dst_reg + off16) += src_reg
+ *(u32 *)(dst + offset) += src
``BPF_ATOMIC | BPF_DW | BPF_STX`` with 'imm' = BPF ADD means::
- *(u64 *)(dst_reg + off16) += src_reg
+ *(u64 *)(dst + offset) += src
In addition to the simple atomic operations, there also is a modifier and
two complex atomic operations:
@@ -295,16 +355,16 @@
The ``BPF_FETCH`` modifier is optional for simple atomic operations, and
always set for the complex atomic operations. If the ``BPF_FETCH`` flag
-is set, then the operation also overwrites ``src_reg`` with the value that
+is set, then the operation also overwrites ``src`` with the value that
was in memory before it was modified.
-The ``BPF_XCHG`` operation atomically exchanges ``src_reg`` with the value
-addressed by ``dst_reg + off``.
+The ``BPF_XCHG`` operation atomically exchanges ``src`` with the value
+addressed by ``dst + offset``.
The ``BPF_CMPXCHG`` operation atomically compares the value addressed by
-``dst_reg + off`` with ``R0``. If they match, the value addressed by
-``dst_reg + off`` is replaced with ``src_reg``. In either case, the
-value that was at ``dst_reg + off`` before the operation is zero-extended
+``dst + offset`` with ``R0``. If they match, the value addressed by
+``dst + offset`` is replaced with ``src``. In either case, the
+value that was at ``dst + offset`` before the operation is zero-extended
and loaded back to ``R0``.
64-bit immediate instructions
@@ -317,7 +377,7 @@
``BPF_LD | BPF_DW | BPF_IMM`` means::
- dst_reg = imm64
+ dst = imm64
Legacy BPF Packet access instructions
diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
index 9fd7fb5..ca96ef3 100644
--- a/Documentation/bpf/kfuncs.rst
+++ b/Documentation/bpf/kfuncs.rst
@@ -1,3 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _kfuncs-header-label:
+
=============================
BPF Kernel Functions (kfuncs)
=============================
@@ -9,7 +13,7 @@
kernel which are exposed for use by BPF programs. Unlike normal BPF helpers,
kfuncs do not have a stable interface and can change from one kernel release to
another. Hence, BPF programs need to be updated in response to changes in the
-kernel.
+kernel. See :ref:`BPF_kfunc_lifecycle_expectations` for more information.
2. Defining a kfunc
===================
@@ -37,7 +41,7 @@
__diag_ignore_all("-Wmissing-prototypes",
"Global kfuncs as their definitions will be in BTF");
- struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
+ __bpf_kfunc struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
{
return find_get_task_by_vpid(nr);
}
@@ -62,7 +66,7 @@
This annotation is used to indicate a memory and size pair in the argument list.
An example is given below::
- void bpf_memzero(void *mem, int mem__sz)
+ __bpf_kfunc void bpf_memzero(void *mem, int mem__sz)
{
...
}
@@ -82,7 +86,7 @@
An example is given below::
- void *bpf_obj_new(u32 local_type_id__k, ...)
+ __bpf_kfunc void *bpf_obj_new(u32 local_type_id__k, ...)
{
...
}
@@ -121,6 +125,20 @@
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
along with it. Ofcourse, it is also allowed to specify no flags.
+kfunc definitions should also always be annotated with the ``__bpf_kfunc``
+macro. This prevents issues such as the compiler inlining the kfunc if it's a
+static kernel function, or the function being elided in an LTO build as it's
+not used in the rest of the kernel. Developers should not manually add
+annotations to their kfunc to prevent these issues. If an annotation is
+required to prevent such an issue with your kfunc, it is a bug and should be
+added to the definition of the macro so that other kfuncs are similarly
+protected. An example is given below::
+
+ __bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
+ {
+ ...
+ }
+
2.4.1 KF_ACQUIRE flag
---------------------
@@ -163,7 +181,8 @@
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
indicates that the all pointer arguments are valid, and that all pointers to
BTF objects have been passed in their unmodified form (that is, at a zero
-offset, and without having been obtained from walking another pointer).
+offset, and without having been obtained from walking another pointer, with one
+exception described below).
There are two types of pointers to kernel objects which are considered "valid":
@@ -176,6 +195,25 @@
The definition of "valid" pointers is subject to change at any time, and has
absolutely no ABI stability guarantees.
+As mentioned above, a nested pointer obtained from walking a trusted pointer is
+no longer trusted, with one exception. If a struct type has a field that is
+guaranteed to be valid as long as its parent pointer is trusted, the
+``BTF_TYPE_SAFE_NESTED`` macro can be used to express that to the verifier as
+follows:
+
+.. code-block:: c
+
+ BTF_TYPE_SAFE_NESTED(struct task_struct) {
+ const cpumask_t *cpus_ptr;
+ };
+
+In other words, you must:
+
+1. Wrap the trusted pointer type in the ``BTF_TYPE_SAFE_NESTED`` macro.
+
+2. Specify the type and name of the trusted nested field. This field must match
+ the field in the original type definition exactly.
+
2.4.6 KF_SLEEPABLE flag
-----------------------
@@ -200,6 +238,28 @@
The argument may have reference count of 0 and the kfunc must take this
into consideration.
+.. _KF_deprecated_flag:
+
+2.4.9 KF_DEPRECATED flag
+------------------------
+
+The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
+changed or removed in a subsequent kernel release. A kfunc that is
+marked with KF_DEPRECATED should also have any relevant information
+captured in its kernel doc. Such information typically includes the
+kfunc's expected remaining lifespan, a recommendation for new
+functionality that can replace it if any is available, and possibly a
+rationale for why it is being removed.
+
+Note that while on some occasions, a KF_DEPRECATED kfunc may continue to be
+supported and have its KF_DEPRECATED flag removed, it is likely to be far more
+difficult to remove a KF_DEPRECATED flag after it's been added than it is to
+prevent it from being added in the first place. As described in
+:ref:`BPF_kfunc_lifecycle_expectations`, users that rely on specific kfuncs are
+encouraged to make their use-cases known as early as possible, and participate
+in upstream discussions regarding whether to keep, change, deprecate, or remove
+those kfuncs if and when such discussions occur.
+
2.5 Registering the kfuncs
--------------------------
@@ -223,14 +283,150 @@
}
late_initcall(init_subsystem);
-3. Core kfuncs
+2.6 Specifying no-cast aliases with ___init
+--------------------------------------------
+
+The verifier will always enforce that the BTF type of a pointer passed to a
+kfunc by a BPF program, matches the type of pointer specified in the kfunc
+definition. The verifier, does, however, allow types that are equivalent
+according to the C standard to be passed to the same kfunc arg, even if their
+BTF_IDs differ.
+
+For example, for the following type definition:
+
+.. code-block:: c
+
+ struct bpf_cpumask {
+ cpumask_t cpumask;
+ refcount_t usage;
+ };
+
+The verifier would allow a ``struct bpf_cpumask *`` to be passed to a kfunc
+taking a ``cpumask_t *`` (which is a typedef of ``struct cpumask *``). For
+instance, both ``struct cpumask *`` and ``struct bpf_cpmuask *`` can be passed
+to bpf_cpumask_test_cpu().
+
+In some cases, this type-aliasing behavior is not desired. ``struct
+nf_conn___init`` is one such example:
+
+.. code-block:: c
+
+ struct nf_conn___init {
+ struct nf_conn ct;
+ };
+
+The C standard would consider these types to be equivalent, but it would not
+always be safe to pass either type to a trusted kfunc. ``struct
+nf_conn___init`` represents an allocated ``struct nf_conn`` object that has
+*not yet been initialized*, so it would therefore be unsafe to pass a ``struct
+nf_conn___init *`` to a kfunc that's expecting a fully initialized ``struct
+nf_conn *`` (e.g. ``bpf_ct_change_timeout()``).
+
+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``.
+
+.. _BPF_kfunc_lifecycle_expectations:
+
+3. kfunc lifecycle expectations
+===============================
+
+kfuncs provide a kernel <-> kernel API, and thus are not bound by any of the
+strict stability restrictions associated with kernel <-> user UAPIs. This means
+they can be thought of as similar to EXPORT_SYMBOL_GPL, and can therefore be
+modified or removed by a maintainer of the subsystem they're defined in when
+it's deemed necessary.
+
+Like any other change to the kernel, maintainers will not change or remove a
+kfunc without having a reasonable justification. Whether or not they'll choose
+to change a kfunc will ultimately depend on a variety of factors, such as how
+widely used the kfunc is, how long the kfunc has been in the kernel, whether an
+alternative kfunc exists, what the norm is in terms of stability for the
+subsystem in question, and of course what the technical cost is of continuing
+to support the kfunc.
+
+There are several implications of this:
+
+a) kfuncs that are widely used or have been in the kernel for a long time will
+ be more difficult to justify being changed or removed by a maintainer. In
+ other words, kfuncs that are known to have a lot of users and provide
+ significant value provide stronger incentives for maintainers to invest the
+ time and complexity in supporting them. It is therefore important for
+ developers that are using kfuncs in their BPF programs to communicate and
+ explain how and why those kfuncs are being used, and to participate in
+ discussions regarding those kfuncs when they occur upstream.
+
+b) Unlike regular kernel symbols marked with EXPORT_SYMBOL_GPL, BPF programs
+ that call kfuncs are generally not part of the kernel tree. This means that
+ refactoring cannot typically change callers in-place when a kfunc changes,
+ as is done for e.g. an upstreamed driver being updated in place when a
+ kernel symbol is changed.
+
+ Unlike with regular kernel symbols, this is expected behavior for BPF
+ symbols, and out-of-tree BPF programs that use kfuncs should be considered
+ relevant to discussions and decisions around modifying and removing those
+ kfuncs. The BPF community will take an active role in participating in
+ upstream discussions when necessary to ensure that the perspectives of such
+ users are taken into account.
+
+c) A kfunc will never have any hard stability guarantees. BPF APIs cannot and
+ will not ever hard-block a change in the kernel purely for stability
+ reasons. That being said, kfuncs are features that are meant to solve
+ problems and provide value to users. The decision of whether to change or
+ remove a kfunc is a multivariate technical decision that is made on a
+ case-by-case basis, and which is informed by data points such as those
+ mentioned above. It is expected that a kfunc being removed or changed with
+ no warning will not be a common occurrence or take place without sound
+ justification, but it is a possibility that must be accepted if one is to
+ use kfuncs.
+
+3.1 kfunc deprecation
+---------------------
+
+As described above, while sometimes a maintainer may find that a kfunc must be
+changed or removed immediately to accommodate some changes in their subsystem,
+usually kfuncs will be able to accommodate a longer and more measured
+deprecation process. For example, if a new kfunc comes along which provides
+superior functionality to an existing kfunc, the existing kfunc may be
+deprecated for some period of time to allow users to migrate their BPF programs
+to use the new one. Or, if a kfunc has no known users, a decision may be made
+to remove the kfunc (without providing an alternative API) after some
+deprecation period so as to provide users with a window to notify the kfunc
+maintainer if it turns out that the kfunc is actually being used.
+
+It's expected that the common case will be that kfuncs will go through a
+deprecation period rather than being changed or removed without warning. As
+described in :ref:`KF_deprecated_flag`, the kfunc framework provides the
+KF_DEPRECATED flag to kfunc developers to signal to users that a kfunc has been
+deprecated. Once a kfunc has been marked with KF_DEPRECATED, the following
+procedure is followed for removal:
+
+1. Any relevant information for deprecated kfuncs is documented in the kfunc's
+ kernel docs. This documentation will typically include the kfunc's expected
+ remaining lifespan, a recommendation for new functionality that can replace
+ the usage of the deprecated function (or an explanation as to why no such
+ replacement exists), etc.
+
+2. The deprecated kfunc is kept in the kernel for some period of time after it
+ was first marked as deprecated. This time period will be chosen on a
+ case-by-case basis, and will typically depend on how widespread the use of
+ the kfunc is, how long it has been in the kernel, and how hard it is to move
+ to alternatives. This deprecation time period is "best effort", and as
+ described :ref:`above<BPF_kfunc_lifecycle_expectations>`, circumstances may
+ sometimes dictate that the kfunc be removed before the full intended
+ deprecation period has elapsed.
+
+3. After the deprecation period the kfunc will be removed. At this point, BPF
+ programs calling the kfunc will be rejected by the verifier.
+
+4. Core kfuncs
==============
The BPF subsystem provides a number of "core" kfuncs that are potentially
applicable to a wide variety of different possible use cases and programs.
Those kfuncs are documented here.
-3.1 struct task_struct * kfuncs
+4.1 struct task_struct * kfuncs
-------------------------------
There are a number of kfuncs that allow ``struct task_struct *`` objects to be
@@ -306,7 +502,7 @@
return 0;
}
-3.2 struct cgroup * kfuncs
+4.2 struct cgroup * kfuncs
--------------------------
``struct cgroup *`` objects also have acquire and release functions:
@@ -420,3 +616,10 @@
bpf_cgroup_release(parent);
return 0;
}
+
+4.3 struct cpumask * kfuncs
+---------------------------
+
+BPF provides a set of kfuncs that can be used to query, allocate, mutate, and
+destroy struct cpumask * objects. Please refer to :ref:`cpumasks-header-label`
+for more details.
diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst
index c5ac97f..b5b41b6 100644
--- a/Documentation/bpf/libbpf/libbpf_naming_convention.rst
+++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst
@@ -83,8 +83,8 @@
to be a part of ABI what, in turn, improves both libbpf developer- and
user-experiences.
-ABI versionning
----------------
+ABI versioning
+--------------
To make future ABI extensions possible libbpf ABI is versioned.
Versioning is implemented by ``libbpf.map`` version script that is
@@ -148,7 +148,7 @@
The libbpf API is documented via comments above definitions in
header files. These comments can be rendered by doxygen and sphinx
for well organized html output. This section describes the
-convention in which these comments should be formated.
+convention in which these comments should be formatted.
Here is an example from btf.h:
diff --git a/Documentation/bpf/map_sockmap.rst b/Documentation/bpf/map_sockmap.rst
new file mode 100644
index 0000000..cc92047
--- /dev/null
+++ b/Documentation/bpf/map_sockmap.rst
@@ -0,0 +1,498 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright Red Hat
+
+==============================================
+BPF_MAP_TYPE_SOCKMAP and BPF_MAP_TYPE_SOCKHASH
+==============================================
+
+.. note::
+ - ``BPF_MAP_TYPE_SOCKMAP`` was introduced in kernel version 4.14
+ - ``BPF_MAP_TYPE_SOCKHASH`` was introduced in kernel version 4.18
+
+``BPF_MAP_TYPE_SOCKMAP`` and ``BPF_MAP_TYPE_SOCKHASH`` maps can be used to
+redirect skbs between sockets or to apply policy at the socket level based on
+the result of a BPF (verdict) program with the help of the BPF helpers
+``bpf_sk_redirect_map()``, ``bpf_sk_redirect_hash()``,
+``bpf_msg_redirect_map()`` and ``bpf_msg_redirect_hash()``.
+
+``BPF_MAP_TYPE_SOCKMAP`` is backed by an array that uses an integer key as the
+index to look up a reference to a ``struct sock``. The map values are socket
+descriptors. Similarly, ``BPF_MAP_TYPE_SOCKHASH`` is a hash backed BPF map that
+holds references to sockets via their socket descriptors.
+
+.. note::
+ The value type is either __u32 or __u64; the latter (__u64) is to support
+ returning socket cookies to userspace. Returning the ``struct sock *`` that
+ the map holds to user-space is neither safe nor useful.
+
+These maps may have BPF programs attached to them, specifically a parser program
+and a verdict program. The parser program determines how much data has been
+parsed and therefore how much data needs to be queued to come to a verdict. The
+verdict program is essentially the redirect program and can return a verdict
+of ``__SK_DROP``, ``__SK_PASS``, or ``__SK_REDIRECT``.
+
+When a socket is inserted into one of these maps, its socket callbacks are
+replaced and a ``struct sk_psock`` is attached to it. Additionally, this
+``sk_psock`` inherits the programs that are attached to the map.
+
+A sock object may be in multiple maps, but can only inherit a single
+parse or verdict program. If adding a sock object to a map would result
+in having multiple parser programs the update will return an EBUSY error.
+
+The supported programs to attach to these maps are:
+
+.. code-block:: c
+
+ struct sk_psock_progs {
+ struct bpf_prog *msg_parser;
+ struct bpf_prog *stream_parser;
+ struct bpf_prog *stream_verdict;
+ struct bpf_prog *skb_verdict;
+ };
+
+.. note::
+ Users are not allowed to attach ``stream_verdict`` and ``skb_verdict``
+ programs to the same map.
+
+The attach types for the map programs are:
+
+- ``msg_parser`` program - ``BPF_SK_MSG_VERDICT``.
+- ``stream_parser`` program - ``BPF_SK_SKB_STREAM_PARSER``.
+- ``stream_verdict`` program - ``BPF_SK_SKB_STREAM_VERDICT``.
+- ``skb_verdict`` program - ``BPF_SK_SKB_VERDICT``.
+
+There are additional helpers available to use with the parser and verdict
+programs: ``bpf_msg_apply_bytes()`` and ``bpf_msg_cork_bytes()``. With
+``bpf_msg_apply_bytes()`` BPF programs can tell the infrastructure how many
+bytes the given verdict should apply to. The helper ``bpf_msg_cork_bytes()``
+handles a different case where a BPF program cannot reach a verdict on a msg
+until it receives more bytes AND the program doesn't want to forward the packet
+until it is known to be good.
+
+Finally, the helpers ``bpf_msg_pull_data()`` and ``bpf_msg_push_data()`` are
+available to ``BPF_PROG_TYPE_SK_MSG`` BPF programs to pull in data and set the
+start and end pointers to given values or to add metadata to the ``struct
+sk_msg_buff *msg``.
+
+All these helpers will be described in more detail below.
+
+Usage
+=====
+Kernel BPF
+----------
+bpf_msg_redirect_map()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_redirect_map(struct sk_msg_buff *msg, struct bpf_map *map, u32 key, u64 flags)
+
+This helper is used in programs implementing policies at the socket level. If
+the message ``msg`` is allowed to pass (i.e., if the verdict BPF program
+returns ``SK_PASS``), redirect it to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKMAP``) at index ``key``. Both ingress and egress interfaces
+can be used for redirection. The ``BPF_F_INGRESS`` value in ``flags`` is used
+to select the ingress path otherwise the egress path is selected. This is the
+only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_sk_redirect_map()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sk_redirect_map(struct sk_buff *skb, struct bpf_map *map, u32 key u64 flags)
+
+Redirect the packet to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKMAP``) at index ``key``. Both ingress and egress interfaces
+can be used for redirection. The ``BPF_F_INGRESS`` value in ``flags`` is used
+to select the ingress path otherwise the egress path is selected. This is the
+only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+socket entries of type ``struct sock *`` can be retrieved using the
+``bpf_map_lookup_elem()`` helper.
+
+bpf_sock_map_update()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sock_map_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags)
+
+Add an entry to, or update a ``map`` referencing sockets. The ``skops`` is used
+as a new value for the entry associated to ``key``. The ``flags`` argument can
+be one of the following:
+
+- ``BPF_ANY``: Create a new element or update an existing element.
+- ``BPF_NOEXIST``: Create a new element only if it did not exist.
+- ``BPF_EXIST``: Update an existing element.
+
+If the ``map`` has BPF programs (parser and verdict), those will be inherited
+by the socket being added. If the socket is already attached to BPF programs,
+this results in an error.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_sock_hash_update()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sock_hash_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags)
+
+Add an entry to, or update a sockhash ``map`` referencing sockets. The ``skops``
+is used as a new value for the entry associated to ``key``.
+
+The ``flags`` argument can be one of the following:
+
+- ``BPF_ANY``: Create a new element or update an existing element.
+- ``BPF_NOEXIST``: Create a new element only if it did not exist.
+- ``BPF_EXIST``: Update an existing element.
+
+If the ``map`` has BPF programs (parser and verdict), those will be inherited
+by the socket being added. If the socket is already attached to BPF programs,
+this results in an error.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_msg_redirect_hash()
+^^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_redirect_hash(struct sk_msg_buff *msg, struct bpf_map *map, void *key, u64 flags)
+
+This helper is used in programs implementing policies at the socket level. If
+the message ``msg`` is allowed to pass (i.e., if the verdict BPF program returns
+``SK_PASS``), redirect it to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKHASH``) using hash ``key``. Both ingress and egress
+interfaces can be used for redirection. The ``BPF_F_INGRESS`` value in
+``flags`` is used to select the ingress path otherwise the egress path is
+selected. This is the only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_sk_redirect_hash()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sk_redirect_hash(struct sk_buff *skb, struct bpf_map *map, void *key, u64 flags)
+
+This helper is used in programs implementing policies at the skb socket level.
+If the sk_buff ``skb`` is allowed to pass (i.e., if the verdict BPF program
+returns ``SK_PASS``), redirect it to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKHASH``) using hash ``key``. Both ingress and egress
+interfaces can be used for redirection. The ``BPF_F_INGRESS`` value in
+``flags`` is used to select the ingress path otherwise the egress path is
+selected. This is the only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_msg_apply_bytes()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_apply_bytes(struct sk_msg_buff *msg, u32 bytes)
+
+For socket policies, apply the verdict of the BPF program to the next (number
+of ``bytes``) of message ``msg``. For example, this helper can be used in the
+following cases:
+
+- A single ``sendmsg()`` or ``sendfile()`` system call contains multiple
+ logical messages that the BPF program is supposed to read and for which it
+ should apply a verdict.
+- A BPF program only cares to read the first ``bytes`` of a ``msg``. If the
+ message has a large payload, then setting up and calling the BPF program
+ repeatedly for all bytes, even though the verdict is already known, would
+ create unnecessary overhead.
+
+Returns 0
+
+bpf_msg_cork_bytes()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_cork_bytes(struct sk_msg_buff *msg, u32 bytes)
+
+For socket policies, prevent the execution of the verdict BPF program for
+message ``msg`` until the number of ``bytes`` have been accumulated.
+
+This can be used when one needs a specific number of bytes before a verdict can
+be assigned, even if the data spans multiple ``sendmsg()`` or ``sendfile()``
+calls.
+
+Returns 0
+
+bpf_msg_pull_data()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_pull_data(struct sk_msg_buff *msg, u32 start, u32 end, u64 flags)
+
+For socket policies, pull in non-linear data from user space for ``msg`` and set
+pointers ``msg->data`` and ``msg->data_end`` to ``start`` and ``end`` bytes
+offsets into ``msg``, respectively.
+
+If a program of type ``BPF_PROG_TYPE_SK_MSG`` is run on a ``msg`` it can only
+parse data that the (``data``, ``data_end``) pointers have already consumed.
+For ``sendmsg()`` hooks this is likely the first scatterlist element. But for
+calls relying on the ``sendpage`` handler (e.g., ``sendfile()``) this will be
+the range (**0**, **0**) because the data is shared with user space and by
+default the objective is to avoid allowing user space to modify data while (or
+after) BPF verdict is being decided. This helper can be used to pull in data
+and to set the start and end pointers to given values. Data will be copied if
+necessary (i.e., if data was not linear and if start and end pointers do not
+point to the same chunk).
+
+A call to this helper is susceptible to change the underlying packet buffer.
+Therefore, at load time, all checks on pointers previously done by the verifier
+are invalidated and must be performed again, if the helper is used in
+combination with direct packet access.
+
+All values for ``flags`` are reserved for future usage, and must be left at
+zero.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+Look up a socket entry in the sockmap or sockhash map.
+
+Returns the socket entry associated to ``key``, or NULL if no entry was found.
+
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
+
+Add or update a socket entry in a sockmap or sockhash.
+
+The flags argument can be one of the following:
+
+- BPF_ANY: Create a new element or update an existing element.
+- BPF_NOEXIST: Create a new element only if it did not exist.
+- BPF_EXIST: Update an existing element.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_map_delete_elem(struct bpf_map *map, const void *key)
+
+Delete a socket entry from a sockmap or a sockhash.
+
+Returns 0 on success, or a negative error in case of failure.
+
+User space
+----------
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_update_elem(int fd, const void *key, const void *value, __u64 flags)
+
+Sockmap entries can be added or updated using the ``bpf_map_update_elem()``
+function. The ``key`` parameter is the index value of the sockmap array. And the
+``value`` parameter is the FD value of that socket.
+
+Under the hood, the sockmap update function uses the socket FD value to
+retrieve the associated socket and its attached psock.
+
+The flags argument can be one of the following:
+
+- BPF_ANY: Create a new element or update an existing element.
+- BPF_NOEXIST: Create a new element only if it did not exist.
+- BPF_EXIST: Update an existing element.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_lookup_elem(int fd, const void *key, void *value)
+
+Sockmap entries can be retrieved using the ``bpf_map_lookup_elem()`` function.
+
+.. note::
+ The entry returned is a socket cookie rather than a socket itself.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_delete_elem(int fd, const void *key)
+
+Sockmap entries can be deleted using the ``bpf_map_delete_elem()``
+function.
+
+Returns 0 on success, or negative error in case of failure.
+
+Examples
+========
+
+Kernel BPF
+----------
+Several examples of the use of sockmap APIs can be found in:
+
+- `tools/testing/selftests/bpf/progs/test_sockmap_kern.h`_
+- `tools/testing/selftests/bpf/progs/sockmap_parse_prog.c`_
+- `tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c`_
+- `tools/testing/selftests/bpf/progs/test_sockmap_listen.c`_
+- `tools/testing/selftests/bpf/progs/test_sockmap_update.c`_
+
+The following code snippet shows how to declare a sockmap.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_SOCKMAP);
+ __uint(max_entries, 1);
+ __type(key, __u32);
+ __type(value, __u64);
+ } sock_map_rx SEC(".maps");
+
+The following code snippet shows a sample parser program.
+
+.. code-block:: c
+
+ SEC("sk_skb/stream_parser")
+ int bpf_prog_parser(struct __sk_buff *skb)
+ {
+ return skb->len;
+ }
+
+The following code snippet shows a simple verdict program that interacts with a
+sockmap to redirect traffic to another socket based on the local port.
+
+.. code-block:: c
+
+ SEC("sk_skb/stream_verdict")
+ int bpf_prog_verdict(struct __sk_buff *skb)
+ {
+ __u32 lport = skb->local_port;
+ __u32 idx = 0;
+
+ if (lport == 10000)
+ return bpf_sk_redirect_map(skb, &sock_map_rx, idx, 0);
+
+ return SK_PASS;
+ }
+
+The following code snippet shows how to declare a sockhash map.
+
+.. code-block:: c
+
+ struct socket_key {
+ __u32 src_ip;
+ __u32 dst_ip;
+ __u32 src_port;
+ __u32 dst_port;
+ };
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_SOCKHASH);
+ __uint(max_entries, 1);
+ __type(key, struct socket_key);
+ __type(value, __u64);
+ } sock_hash_rx SEC(".maps");
+
+The following code snippet shows a simple verdict program that interacts with a
+sockhash to redirect traffic to another socket based on a hash of some of the
+skb parameters.
+
+.. code-block:: c
+
+ static inline
+ void extract_socket_key(struct __sk_buff *skb, struct socket_key *key)
+ {
+ key->src_ip = skb->remote_ip4;
+ key->dst_ip = skb->local_ip4;
+ key->src_port = skb->remote_port >> 16;
+ key->dst_port = (bpf_htonl(skb->local_port)) >> 16;
+ }
+
+ SEC("sk_skb/stream_verdict")
+ int bpf_prog_verdict(struct __sk_buff *skb)
+ {
+ struct socket_key key;
+
+ extract_socket_key(skb, &key);
+
+ return bpf_sk_redirect_hash(skb, &sock_hash_rx, &key, 0);
+ }
+
+User space
+----------
+Several examples of the use of sockmap APIs can be found in:
+
+- `tools/testing/selftests/bpf/prog_tests/sockmap_basic.c`_
+- `tools/testing/selftests/bpf/test_sockmap.c`_
+- `tools/testing/selftests/bpf/test_maps.c`_
+
+The following code sample shows how to create a sockmap, attach a parser and
+verdict program, as well as add a socket entry.
+
+.. code-block:: c
+
+ int create_sample_sockmap(int sock, int parse_prog_fd, int verdict_prog_fd)
+ {
+ int index = 0;
+ int map, err;
+
+ map = bpf_map_create(BPF_MAP_TYPE_SOCKMAP, NULL, sizeof(int), sizeof(int), 1, NULL);
+ if (map < 0) {
+ fprintf(stderr, "Failed to create sockmap: %s\n", strerror(errno));
+ return -1;
+ }
+
+ err = bpf_prog_attach(parse_prog_fd, map, BPF_SK_SKB_STREAM_PARSER, 0);
+ if (err){
+ fprintf(stderr, "Failed to attach_parser_prog_to_map: %s\n", strerror(errno));
+ goto out;
+ }
+
+ err = bpf_prog_attach(verdict_prog_fd, map, BPF_SK_SKB_STREAM_VERDICT, 0);
+ if (err){
+ fprintf(stderr, "Failed to attach_verdict_prog_to_map: %s\n", strerror(errno));
+ goto out;
+ }
+
+ err = bpf_map_update_elem(map, &index, &sock, BPF_NOEXIST);
+ if (err) {
+ fprintf(stderr, "Failed to update sockmap: %s\n", strerror(errno));
+ goto out;
+ }
+
+ out:
+ close(map);
+ return err;
+ }
+
+References
+===========
+
+- https://github.com/jrfastab/linux-kernel-xdp/commit/c89fd73cb9d2d7f3c716c3e00836f07b1aeb261f
+- https://lwn.net/Articles/731133/
+- http://vger.kernel.org/lpc_net2018_talks/ktls_bpf_paper.pdf
+- https://lwn.net/Articles/748628/
+- https://lore.kernel.org/bpf/20200218171023.844439-7-jakub@cloudflare.com/
+
+.. _`tools/testing/selftests/bpf/progs/test_sockmap_kern.h`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/test_sockmap_kern.h
+.. _`tools/testing/selftests/bpf/progs/sockmap_parse_prog.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c
+.. _`tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c
+.. _`tools/testing/selftests/bpf/prog_tests/sockmap_basic.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+.. _`tools/testing/selftests/bpf/test_sockmap.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/test_sockmap.c
+.. _`tools/testing/selftests/bpf/test_maps.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/test_maps.c
+.. _`tools/testing/selftests/bpf/progs/test_sockmap_listen.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/test_sockmap_listen.c
+.. _`tools/testing/selftests/bpf/progs/test_sockmap_update.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/test_sockmap_update.c
diff --git a/Documentation/bpf/map_xskmap.rst b/Documentation/bpf/map_xskmap.rst
index 7093b82..dc143ed 100644
--- a/Documentation/bpf/map_xskmap.rst
+++ b/Documentation/bpf/map_xskmap.rst
@@ -178,7 +178,7 @@
For an example on how create AF_XDP sockets, please see the AF_XDP-example and
AF_XDP-forwarding programs in the `bpf-examples`_ directory in the `libxdp`_ repository.
-For a detailed explaination of the AF_XDP interface please see:
+For a detailed explanation of the AF_XDP interface please see:
- `libxdp-readme`_.
- `AF_XDP`_ kernel documentation.
diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst
index 3d61963..7e6b120 100644
--- a/Documentation/bpf/other.rst
+++ b/Documentation/bpf/other.rst
@@ -6,4 +6,5 @@
:maxdepth: 1
ringbuf
- llvm_reloc
\ No newline at end of file
+ llvm_reloc
+ graph_ds_impl
diff --git a/Documentation/bpf/ringbuf.rst b/Documentation/bpf/ringbuf.rst
index 6a615cd..a99cd05 100644
--- a/Documentation/bpf/ringbuf.rst
+++ b/Documentation/bpf/ringbuf.rst
@@ -124,7 +124,7 @@
- ``BPF_RB_AVAIL_DATA`` returns amount of unconsumed data in ring buffer;
- ``BPF_RB_RING_SIZE`` returns the size of ring buffer;
-- ``BPF_RB_CONS_POS``/``BPF_RB_PROD_POS`` returns current logical possition
+- ``BPF_RB_CONS_POS``/``BPF_RB_PROD_POS`` returns current logical position
of consumer/producer, respectively.
Returned values are momentarily snapshots of ring buffer state and could be
@@ -146,7 +146,7 @@
This reserve/commit schema allows a natural way for multiple producers, either
on different CPUs or even on the same CPU/in the same BPF program, to reserve
independent records and work with them without blocking other producers. This
-means that if BPF program was interruped by another BPF program sharing the
+means that if BPF program was interrupted by another BPF program sharing the
same ring buffer, they will both get a record reserved (provided there is
enough space left) and can work with it and submit it independently. This
applies to NMI context as well, except that due to using a spinlock during
diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst
index d4326ca..f0ec19d 100644
--- a/Documentation/bpf/verifier.rst
+++ b/Documentation/bpf/verifier.rst
@@ -192,7 +192,7 @@
As well as range-checking, the tracked information is also used for enforcing
alignment of pointer accesses. For instance, on most systems the packet pointer
is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump
-over the Ethernet header, then reads IHL and addes (IHL * 4), the resulting
+over the Ethernet header, then reads IHL and adds (IHL * 4), the resulting
pointer will have a variable offset known to be 4n+2 for some n, so adding the 2
bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through
that pointer are safe.
@@ -316,6 +316,301 @@
registers it may hold). They must all be safe for the branch to be pruned.
This is implemented in states_equal().
+Some technical details about state pruning implementation could be found below.
+
+Register liveness tracking
+--------------------------
+
+In order to make state pruning effective, liveness state is tracked for each
+register and stack slot. The basic idea is to track which registers and stack
+slots are actually used during subseqeuent execution of the program, until
+program exit is reached. Registers and stack slots that were never used could be
+removed from the cached state thus making more states equivalent to a cached
+state. This could be illustrated by the following program::
+
+ 0: call bpf_get_prandom_u32()
+ 1: r1 = 0
+ 2: if r0 == 0 goto +1
+ 3: r0 = 1
+ --- checkpoint ---
+ 4: r0 = r1
+ 5: exit
+
+Suppose that a state cache entry is created at instruction #4 (such entries are
+also called "checkpoints" in the text below). The verifier could reach the
+instruction with one of two possible register states:
+
+* r0 = 1, r1 = 0
+* r0 = 0, r1 = 0
+
+However, only the value of register ``r1`` is important to successfully finish
+verification. The goal of the liveness tracking algorithm is to spot this fact
+and figure out that both states are actually equivalent.
+
+Data structures
+~~~~~~~~~~~~~~~
+
+Liveness is tracked using the following data structures::
+
+ enum bpf_reg_liveness {
+ REG_LIVE_NONE = 0,
+ REG_LIVE_READ32 = 0x1,
+ REG_LIVE_READ64 = 0x2,
+ REG_LIVE_READ = REG_LIVE_READ32 | REG_LIVE_READ64,
+ REG_LIVE_WRITTEN = 0x4,
+ REG_LIVE_DONE = 0x8,
+ };
+
+ struct bpf_reg_state {
+ ...
+ struct bpf_reg_state *parent;
+ ...
+ enum bpf_reg_liveness live;
+ ...
+ };
+
+ struct bpf_stack_state {
+ struct bpf_reg_state spilled_ptr;
+ ...
+ };
+
+ struct bpf_func_state {
+ struct bpf_reg_state regs[MAX_BPF_REG];
+ ...
+ struct bpf_stack_state *stack;
+ }
+
+ struct bpf_verifier_state {
+ struct bpf_func_state *frame[MAX_CALL_FRAMES];
+ struct bpf_verifier_state *parent;
+ ...
+ }
+
+* ``REG_LIVE_NONE`` is an initial value assigned to ``->live`` fields upon new
+ verifier state creation;
+
+* ``REG_LIVE_WRITTEN`` means that the value of the register (or stack slot) is
+ defined by some instruction verified between this verifier state's parent and
+ verifier state itself;
+
+* ``REG_LIVE_READ{32,64}`` means that the value of the register (or stack slot)
+ is read by a some child state of this verifier state;
+
+* ``REG_LIVE_DONE`` is a marker used by ``clean_verifier_state()`` to avoid
+ processing same verifier state multiple times and for some sanity checks;
+
+* ``->live`` field values are formed by combining ``enum bpf_reg_liveness``
+ values using bitwise or.
+
+Register parentage chains
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to propagate information between parent and child states, a *register
+parentage chain* is established. Each register or stack slot is linked to a
+corresponding register or stack slot in its parent state via a ``->parent``
+pointer. This link is established upon state creation in ``is_state_visited()``
+and might be modified by ``set_callee_state()`` called from
+``__check_func_call()``.
+
+The rules for correspondence between registers / stack slots are as follows:
+
+* For the current stack frame, registers and stack slots of the new state are
+ linked to the registers and stack slots of the parent state with the same
+ indices.
+
+* For the outer stack frames, only caller saved registers (r6-r9) and stack
+ slots are linked to the registers and stack slots of the parent state with the
+ same indices.
+
+* When function call is processed a new ``struct bpf_func_state`` instance is
+ allocated, it encapsulates a new set of registers and stack slots. For this
+ new frame, parent links for r6-r9 and stack slots are set to nil, parent links
+ for r1-r5 are set to match caller r1-r5 parent links.
+
+This could be illustrated by the following diagram (arrows stand for
+``->parent`` pointers)::
+
+ ... ; Frame #0, some instructions
+ --- checkpoint #0 ---
+ 1 : r6 = 42 ; Frame #0
+ --- checkpoint #1 ---
+ 2 : call foo() ; Frame #0
+ ... ; Frame #1, instructions from foo()
+ --- checkpoint #2 ---
+ ... ; Frame #1, instructions from foo()
+ --- checkpoint #3 ---
+ exit ; Frame #1, return from foo()
+ 3 : r1 = r6 ; Frame #0 <- current state
+
+ +-------------------------------+-------------------------------+
+ | Frame #0 | Frame #1 |
+ Checkpoint +-------------------------------+-------------------------------+
+ #0 | r0 | r1-r5 | r6-r9 | fp-8 ... |
+ +-------------------------------+
+ ^ ^ ^ ^
+ | | | |
+ Checkpoint +-------------------------------+
+ #1 | r0 | r1-r5 | r6-r9 | fp-8 ... |
+ +-------------------------------+
+ ^ ^ ^
+ |_______|_______|_______________
+ | | |
+ nil nil | | | nil nil
+ | | | | | | |
+ Checkpoint +-------------------------------+-------------------------------+
+ #2 | r0 | r1-r5 | r6-r9 | fp-8 ... | r0 | r1-r5 | r6-r9 | fp-8 ... |
+ +-------------------------------+-------------------------------+
+ ^ ^ ^ ^ ^
+ nil nil | | | | |
+ | | | | | | |
+ Checkpoint +-------------------------------+-------------------------------+
+ #3 | r0 | r1-r5 | r6-r9 | fp-8 ... | r0 | r1-r5 | r6-r9 | fp-8 ... |
+ +-------------------------------+-------------------------------+
+ ^ ^
+ nil nil | |
+ | | | |
+ Current +-------------------------------+
+ state | r0 | r1-r5 | r6-r9 | fp-8 ... |
+ +-------------------------------+
+ \
+ r6 read mark is propagated via these links
+ all the way up to checkpoint #1.
+ The checkpoint #1 contains a write mark for r6
+ because of instruction (1), thus read propagation
+ does not reach checkpoint #0 (see section below).
+
+Liveness marks tracking
+~~~~~~~~~~~~~~~~~~~~~~~
+
+For each processed instruction, the verifier tracks read and written registers
+and stack slots. The main idea of the algorithm is that read marks propagate
+back along the state parentage chain until they hit a write mark, which 'screens
+off' earlier states from the read. The information about reads is propagated by
+function ``mark_reg_read()`` which could be summarized as follows::
+
+ mark_reg_read(struct bpf_reg_state *state, ...):
+ parent = state->parent
+ while parent:
+ if state->live & REG_LIVE_WRITTEN:
+ break
+ if parent->live & REG_LIVE_READ64:
+ break
+ parent->live |= REG_LIVE_READ64
+ state = parent
+ parent = state->parent
+
+Notes:
+
+* The read marks are applied to the **parent** state while write marks are
+ applied to the **current** state. The write mark on a register or stack slot
+ means that it is updated by some instruction in the straight-line code leading
+ from the parent state to the current state.
+
+* Details about REG_LIVE_READ32 are omitted.
+
+* Function ``propagate_liveness()`` (see section :ref:`read_marks_for_cache_hits`)
+ might override the first parent link. Please refer to the comments in the
+ ``propagate_liveness()`` and ``mark_reg_read()`` source code for further
+ details.
+
+Because stack writes could have different sizes ``REG_LIVE_WRITTEN`` marks are
+applied conservatively: stack slots are marked as written only if write size
+corresponds to the size of the register, e.g. see function ``save_register_state()``.
+
+Consider the following example::
+
+ 0: (*u64)(r10 - 8) = 0 ; define 8 bytes of fp-8
+ --- checkpoint #0 ---
+ 1: (*u32)(r10 - 8) = 1 ; redefine lower 4 bytes
+ 2: r1 = (*u32)(r10 - 8) ; read lower 4 bytes defined at (1)
+ 3: r2 = (*u32)(r10 - 4) ; read upper 4 bytes defined at (0)
+
+As stated above, the write at (1) does not count as ``REG_LIVE_WRITTEN``. Should
+it be otherwise, the algorithm above wouldn't be able to propagate the read mark
+from (3) to checkpoint #0.
+
+Once the ``BPF_EXIT`` instruction is reached ``update_branch_counts()`` is
+called to update the ``->branches`` counter for each verifier state in a chain
+of parent verifier states. When the ``->branches`` counter reaches zero the
+verifier state becomes a valid entry in a set of cached verifier states.
+
+Each entry of the verifier states cache is post-processed by a function
+``clean_live_states()``. This function marks all registers and stack slots
+without ``REG_LIVE_READ{32,64}`` marks as ``NOT_INIT`` or ``STACK_INVALID``.
+Registers/stack slots marked in this way are ignored in function ``stacksafe()``
+called from ``states_equal()`` when a state cache entry is considered for
+equivalence with a current state.
+
+Now it is possible to explain how the example from the beginning of the section
+works::
+
+ 0: call bpf_get_prandom_u32()
+ 1: r1 = 0
+ 2: if r0 == 0 goto +1
+ 3: r0 = 1
+ --- checkpoint[0] ---
+ 4: r0 = r1
+ 5: exit
+
+* At instruction #2 branching point is reached and state ``{ r0 == 0, r1 == 0, pc == 4 }``
+ is pushed to states processing queue (pc stands for program counter).
+
+* At instruction #4:
+
+ * ``checkpoint[0]`` states cache entry is created: ``{ r0 == 1, r1 == 0, pc == 4 }``;
+ * ``checkpoint[0].r0`` is marked as written;
+ * ``checkpoint[0].r1`` is marked as read;
+
+* At instruction #5 exit is reached and ``checkpoint[0]`` can now be processed
+ by ``clean_live_states()``. After this processing ``checkpoint[0].r0`` has a
+ read mark and all other registers and stack slots are marked as ``NOT_INIT``
+ or ``STACK_INVALID``
+
+* The state ``{ r0 == 0, r1 == 0, pc == 4 }`` is popped from the states queue
+ and is compared against a cached state ``{ r1 == 0, pc == 4 }``, the states
+ are considered equivalent.
+
+.. _read_marks_for_cache_hits:
+
+Read marks propagation for cache hits
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Another point is the handling of read marks when a previously verified state is
+found in the states cache. Upon cache hit verifier must behave in the same way
+as if the current state was verified to the program exit. This means that all
+read marks, present on registers and stack slots of the cached state, must be
+propagated over the parentage chain of the current state. Example below shows
+why this is important. Function ``propagate_liveness()`` handles this case.
+
+Consider the following state parentage chain (S is a starting state, A-E are
+derived states, -> arrows show which state is derived from which)::
+
+ r1 read
+ <------------- A[r1] == 0
+ C[r1] == 0
+ S ---> A ---> B ---> exit E[r1] == 1
+ |
+ ` ---> C ---> D
+ |
+ ` ---> E ^
+ |___ suppose all these
+ ^ states are at insn #Y
+ |
+ suppose all these
+ states are at insn #X
+
+* Chain of states ``S -> A -> B -> exit`` is verified first.
+
+* While ``B -> exit`` is verified, register ``r1`` is read and this read mark is
+ propagated up to state ``A``.
+
+* When chain of states ``C -> D`` is verified the state ``D`` turns out to be
+ equivalent to state ``B``.
+
+* The read mark for ``r1`` has to be propagated to state ``C``, otherwise state
+ ``C`` might get mistakenly marked as equivalent to state ``E`` even though
+ values for register ``r1`` differ between ``C`` and ``E``.
+
Understanding eBPF verifier messages
====================================
diff --git a/Documentation/conf.py b/Documentation/conf.py
index d927737..db16814 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -116,6 +116,9 @@
# include/linux/linkage.h:
"asmlinkage",
+
+ # include/linux/btf.h
+ "__bpf_kfunc",
]
else:
@@ -153,7 +156,7 @@
math_renderer = 'mathjax'
# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
+templates_path = ['sphinx/templates']
# The suffix(es) of source filenames.
# You can specify multiple suffix as a list of string:
@@ -328,6 +331,7 @@
'description': get_cline_version(),
'page_width': '65em',
'sidebar_width': '15em',
+ 'fixed_sidebar': 'true',
'font_size': 'inherit',
'font_family': 'serif',
}
@@ -345,7 +349,7 @@
# Custom sidebar templates, maps document names to template names.
# Note that the RTD theme ignores this
-html_sidebars = { '**': ['searchbox.html', 'localtoc.html', 'sourcelink.html']}
+html_sidebars = { '**': ['searchbox.html', 'kernel-toc.html', 'sourcelink.html']}
# about.html is available for alabaster theme. Add it at the front.
if html_theme == 'alabaster':
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index 77eb775..7a3a08d 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -127,6 +127,7 @@
:maxdepth: 1
librs
+ netlink
.. only:: subproject and html
diff --git a/Documentation/core-api/netlink.rst b/Documentation/core-api/netlink.rst
new file mode 100644
index 0000000..e4a938a
--- /dev/null
+++ b/Documentation/core-api/netlink.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+
+.. _kernel_netlink:
+
+===================================
+Netlink notes for kernel developers
+===================================
+
+General guidance
+================
+
+Attribute enums
+---------------
+
+Older families often define "null" attributes and commands with value
+of ``0`` and named ``unspec``. This is supported (``type: unused``)
+but should be avoided in new families. The ``unspec`` enum values are
+not used in practice, so just set the value of the first attribute to ``1``.
+
+Message enums
+-------------
+
+Use the same command IDs for requests and replies. This makes it easier
+to match them up, and we have plenty of ID space.
+
+Use separate command IDs for notifications. This makes it easier to
+sort the notifications from replies (and present them to the user
+application via a different API than replies).
+
+Answer requests
+---------------
+
+Older families do not reply to all of the commands, especially NEW / ADD
+commands. User only gets information whether the operation succeeded or
+not via the ACK. Try to find useful data to return. Once the command is
+added whether it replies with a full message or only an ACK is uAPI and
+cannot be changed. It's better to err on the side of replying.
+
+Specifically NEW and ADD commands should reply with information identifying
+the created object such as the allocated object's ID (without having to
+resort to using ``NLM_F_ECHO``).
+
+NLM_F_ECHO
+----------
+
+Make sure to pass the request info to genl_notify() to allow ``NLM_F_ECHO``
+to take effect. This is useful for programs that need precise feedback
+from the kernel (for example for logging purposes).
+
+Support dump consistency
+------------------------
+
+If iterating over objects during dump may skip over objects or repeat
+them - make sure to report dump inconsistency with ``NLM_F_DUMP_INTR``.
+This is usually implemented by maintaining a generation id for the
+structure and recording it in the ``seq`` member of struct netlink_callback.
+
+Netlink specification
+=====================
+
+Documentation of the Netlink specification parts which are only relevant
+to the kernel space.
+
+Globals
+-------
+
+kernel-policy
+~~~~~~~~~~~~~
+
+Defines if the kernel validation policy is per operation (``per-op``)
+or for the entire family (``global``). New families should use ``per-op``
+(default) to be able to narrow down the attributes accepted by a specific
+command.
+
+checks
+------
+
+Documentation for the ``checks`` sub-sections of attribute specs.
+
+unterminated-ok
+~~~~~~~~~~~~~~~
+
+Accept strings without the null-termination (for legacy families only).
+Switches from the ``NLA_NUL_STRING`` to ``NLA_STRING`` policy type.
+
+max-len
+~~~~~~~
+
+Defines max length for a binary or string attribute (corresponding
+to the ``len`` member of struct nla_policy). For string attributes terminating
+null character is not counted towards ``max-len``.
+
+The field may either be a literal integer value or a name of a defined
+constant. String types may reduce the constant by one
+(i.e. specify ``max-len: CONST - 1``) to reserve space for the terminating
+character so implementations should recognize such pattern.
+
+min-len
+~~~~~~~
+
+Similar to ``max-len`` but defines minimum length.
diff --git a/Documentation/core-api/packing.rst b/Documentation/core-api/packing.rst
index d8c341f..3ed13bc 100644
--- a/Documentation/core-api/packing.rst
+++ b/Documentation/core-api/packing.rst
@@ -161,6 +161,6 @@
The packing() function returns an int-encoded error code, which protects the
programmer against incorrect API use. The errors are not expected to occur
-durring runtime, therefore it is reasonable for xxx_packing() to return void
+during runtime, therefore it is reasonable for xxx_packing() to return void
and simply swallow those errors. Optionally it can dump stack or print the
error description.
diff --git a/Documentation/core-api/padata.rst b/Documentation/core-api/padata.rst
index 3517571..05b73c6 100644
--- a/Documentation/core-api/padata.rst
+++ b/Documentation/core-api/padata.rst
@@ -42,7 +42,7 @@
Modifying cpumasks
------------------
-The CPUs used to run jobs can be changed in two ways, programatically with
+The CPUs used to run jobs can be changed in two ways, programmatically with
padata_set_cpumask() or via sysfs. The former is defined::
int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type,
diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst
index b18416f..9fb0b10 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -55,18 +55,17 @@
pages* array, and the function then pins pages by incrementing each by a special
value: GUP_PIN_COUNTING_BIAS.
-For compound pages, the GUP_PIN_COUNTING_BIAS scheme is not used. Instead,
-an exact form of pin counting is achieved, by using the 2nd struct page
-in the compound page. A new struct page field, compound_pincount, has
-been added in order to support this.
+For large folios, the GUP_PIN_COUNTING_BIAS scheme is not used. Instead,
+the extra space available in the struct folio is used to store the
+pincount directly.
-This approach for compound pages avoids the counting upper limit problems that
-are discussed below. Those limitations would have been aggravated severely by
-huge pages, because each tail page adds a refcount to the head page. And in
-fact, testing revealed that, without a separate compound_pincount field,
-page overflows were seen in some huge page stress tests.
+This approach for large folios avoids the counting upper limit problems
+that are discussed below. Those limitations would have been aggravated
+severely by huge pages, because each tail page adds a refcount to the
+head page. And in fact, testing revealed that, without a separate pincount
+field, refcount overflows were seen in some huge page stress tests.
-This also means that huge pages and compound pages do not suffer
+This also means that huge pages and large folios do not suffer
from the false positives problem that is mentioned below.::
Function
@@ -221,7 +220,7 @@
============
This file::
- tools/testing/selftests/vm/gup_test.c
+ tools/testing/selftests/mm/gup_test.c
has the following new calls to exercise the new pin*() wrapper functions:
@@ -264,9 +263,9 @@
Other diagnostics
=================
-dump_page() has been enhanced slightly, to handle these new counting
-fields, and to better report on compound pages in general. Specifically,
-for compound pages, the exact (compound_pincount) pincount is reported.
+dump_page() has been enhanced slightly to handle these new counting
+fields, and to better report on large folios in general. Specifically,
+for large folios, the exact pincount is reported.
References
==========
diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst
index 3b22ed1..8ec4d62 100644
--- a/Documentation/core-api/workqueue.rst
+++ b/Documentation/core-api/workqueue.rst
@@ -370,8 +370,8 @@
The first one can be tracked using tracing: ::
- $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
- $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
+ $ echo workqueue:workqueue_queue_work > /sys/kernel/tracing/set_event
+ $ cat /sys/kernel/tracing/trace_pipe > out.txt
(wait a few secs)
^C
diff --git a/Documentation/cpu-freq/index.rst b/Documentation/cpu-freq/index.rst
index 2fe32da..de25740 100644
--- a/Documentation/cpu-freq/index.rst
+++ b/Documentation/cpu-freq/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-==============================================================================
-Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
-==============================================================================
+========================================================================
+CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
+========================================================================
Author: Dominik Brodowski <linux@brodo.de>
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index 21338fa..da5d5ad 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -1,6 +1,6 @@
-=======================
-Linux Kernel Crypto API
-=======================
+==========
+Crypto API
+==========
:Author: Stephan Mueller
:Author: Marek Vasut
diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst
index d997606..535ce12 100644
--- a/Documentation/dev-tools/coccinelle.rst
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -219,7 +219,7 @@
cat cocci.err
You can use SPFLAGS to add debugging flags; for instance you may want to
-add both --profile --show-trying to SPFLAGS when debugging. For example
+add both ``--profile --show-trying`` to SPFLAGS when debugging. For example
you may want to use::
rm -f err.log
@@ -248,7 +248,7 @@
- Your current user's home directory is processed first
- Your directory from which spatch is called is processed next
-- The directory provided with the --dir option is processed last, if used
+- The directory provided with the ``--dir`` option is processed last, if used
Since coccicheck runs through make, it naturally runs from the kernel
proper dir; as such the second rule above would be implied for picking up a
@@ -265,8 +265,8 @@
fi
KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
-the spatch --dir argument is used, as such third rule applies when whether M=
-is used or not, and when M= is used the target directory can have its own
+the spatch ``--dir`` argument is used, as such third rule applies when whether
+M= is used or not, and when M= is used the target directory can have its own
.cocciconfig file. When M= is not passed as an argument to coccicheck the
target directory is the same as the directory from where spatch was called.
diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst b/Documentation/dev-tools/gdb-kernel-debugging.rst
index 8e0f1fe..895285c 100644
--- a/Documentation/dev-tools/gdb-kernel-debugging.rst
+++ b/Documentation/dev-tools/gdb-kernel-debugging.rst
@@ -39,6 +39,10 @@
this mode. In this case, you should build the kernel with
CONFIG_RANDOMIZE_BASE disabled if the architecture supports KASLR.
+- Build the gdb scripts (required on kernels v5.1 and above)::
+
+ make scripts_gdb
+
- Enable the gdb stub of QEMU/KVM, either
- at VM startup time by appending "-s" to the QEMU command line
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 5c93ab9..e66916a 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -140,6 +140,23 @@
- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc
allocations (default: ``on``).
+- ``kasan.page_alloc.sample=<sampling interval>`` makes KASAN tag only every
+ Nth page_alloc allocation with the order equal or greater than
+ ``kasan.page_alloc.sample.order``, where N is the value of the ``sample``
+ parameter (default: ``1``, or tag every such allocation).
+ This parameter is intended to mitigate the performance overhead introduced
+ by KASAN.
+ Note that enabling this parameter makes Hardware Tag-Based KASAN skip checks
+ of allocations chosen by sampling and thus miss bad accesses to these
+ allocations. Use the default value for accurate bug detection.
+
+- ``kasan.page_alloc.sample.order=<minimum page order>`` specifies the minimum
+ order of allocations that are affected by sampling (default: ``3``).
+ Only applies when ``kasan.page_alloc.sample`` is set to a value greater
+ than ``1``.
+ This parameter is intended to allow sampling only large page_alloc
+ allocations, which is the biggest source of the performance overhead.
+
Error reports
~~~~~~~~~~~~~
diff --git a/Documentation/dev-tools/kunit/api/functionredirection.rst b/Documentation/dev-tools/kunit/api/functionredirection.rst
new file mode 100644
index 0000000..3791efc
--- /dev/null
+++ b/Documentation/dev-tools/kunit/api/functionredirection.rst
@@ -0,0 +1,162 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+Function Redirection API
+========================
+
+Overview
+========
+
+When writing unit tests, it's important to be able to isolate the code being
+tested from other parts of the kernel. This ensures the reliability of the test
+(it won't be affected by external factors), reduces dependencies on specific
+hardware or config options (making the test easier to run), and protects the
+stability of the rest of the system (making it less likely for test-specific
+state to interfere with the rest of the system).
+
+While for some code (typically generic data structures, helpers, and other
+"pure functions") this is trivial, for others (like device drivers,
+filesystems, core subsystems) the code is heavily coupled with other parts of
+the kernel.
+
+This coupling is often due to global state in some way: be it a global list of
+devices, the filesystem, or some hardware state. Tests need to either carefully
+manage, isolate, and restore state, or they can avoid it altogether by
+replacing access to and mutation of this state with a "fake" or "mock" variant.
+
+By refactoring access to such state, such as by introducing a layer of
+indirection which can use or emulate a separate set of test state. However,
+such refactoring comes with its own costs (and undertaking significant
+refactoring before being able to write tests is suboptimal).
+
+A simpler way to intercept and replace some of the function calls is to use
+function redirection via static stubs.
+
+
+Static Stubs
+============
+
+Static stubs are a way of redirecting calls to one function (the "real"
+function) to another function (the "replacement" function).
+
+It works by adding a macro to the "real" function which checks to see if a test
+is running, and if a replacement function is available. If so, that function is
+called in place of the original.
+
+Using static stubs is pretty straightforward:
+
+1. Add the KUNIT_STATIC_STUB_REDIRECT() macro to the start of the "real"
+ function.
+
+ This should be the first statement in the function, after any variable
+ declarations. KUNIT_STATIC_STUB_REDIRECT() takes the name of the
+ function, followed by all of the arguments passed to the real function.
+
+ For example:
+
+ .. code-block:: c
+
+ void send_data_to_hardware(const char *str)
+ {
+ KUNIT_STATIC_STUB_REDIRECT(send_data_to_hardware, str);
+ /* real implementation */
+ }
+
+2. Write one or more replacement functions.
+
+ These functions should have the same function signature as the real function.
+ In the event they need to access or modify test-specific state, they can use
+ kunit_get_current_test() to get a struct kunit pointer. This can then
+ be passed to the expectation/assertion macros, or used to look up KUnit
+ resources.
+
+ For example:
+
+ .. code-block:: c
+
+ void fake_send_data_to_hardware(const char *str)
+ {
+ struct kunit *test = kunit_get_current_test();
+ KUNIT_EXPECT_STREQ(test, str, "Hello World!");
+ }
+
+3. Activate the static stub from your test.
+
+ From within a test, the redirection can be enabled with
+ kunit_activate_static_stub(), which accepts a struct kunit pointer,
+ the real function, and the replacement function. You can call this several
+ times with different replacement functions to swap out implementations of the
+ function.
+
+ In our example, this would be
+
+ .. code-block:: c
+
+ kunit_activate_static_stub(test,
+ send_data_to_hardware,
+ fake_send_data_to_hardware);
+
+4. Call (perhaps indirectly) the real function.
+
+ Once the redirection is activated, any call to the real function will call
+ the replacement function instead. Such calls may be buried deep in the
+ implementation of another function, but must occur from the test's kthread.
+
+ For example:
+
+ .. code-block:: c
+
+ send_data_to_hardware("Hello World!"); /* Succeeds */
+ send_data_to_hardware("Something else"); /* Fails the test. */
+
+5. (Optionally) disable the stub.
+
+ When you no longer need it, disable the redirection (and hence resume the
+ original behaviour of the 'real' function) using
+ kunit_deactivate_static_stub(). Otherwise, it will be automatically disabled
+ when the test exits.
+
+ For example:
+
+ .. code-block:: c
+
+ kunit_deactivate_static_stub(test, send_data_to_hardware);
+
+
+It's also possible to use these replacement functions to test to see if a
+function is called at all, for example:
+
+.. code-block:: c
+
+ void send_data_to_hardware(const char *str)
+ {
+ KUNIT_STATIC_STUB_REDIRECT(send_data_to_hardware, str);
+ /* real implementation */
+ }
+
+ /* In test file */
+ int times_called = 0;
+ void fake_send_data_to_hardware(const char *str)
+ {
+ times_called++;
+ }
+ ...
+ /* In the test case, redirect calls for the duration of the test */
+ kunit_activate_static_stub(test, send_data_to_hardware, fake_send_data_to_hardware);
+
+ send_data_to_hardware("hello");
+ KUNIT_EXPECT_EQ(test, times_called, 1);
+
+ /* Can also deactivate the stub early, if wanted */
+ kunit_deactivate_static_stub(test, send_data_to_hardware);
+
+ send_data_to_hardware("hello again");
+ KUNIT_EXPECT_EQ(test, times_called, 1);
+
+
+
+API Reference
+=============
+
+.. kernel-doc:: include/kunit/static_stub.h
+ :internal:
diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst
index 45ce048..2d8f756 100644
--- a/Documentation/dev-tools/kunit/api/index.rst
+++ b/Documentation/dev-tools/kunit/api/index.rst
@@ -4,17 +4,24 @@
API Reference
=============
.. toctree::
+ :hidden:
test
resource
+ functionredirection
-This section documents the KUnit kernel testing API. It is divided into the
+
+This page documents the KUnit kernel testing API. It is divided into the
following sections:
Documentation/dev-tools/kunit/api/test.rst
- - documents all of the standard testing API
+ - Documents all of the standard testing API
Documentation/dev-tools/kunit/api/resource.rst
- - documents the KUnit resource API
+ - Documents the KUnit resource API
+
+Documentation/dev-tools/kunit/api/functionredirection.rst
+
+ - Documents the KUnit Function Redirection API
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 48f8196..9faf2b4 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -648,10 +648,9 @@
access using the ``kunit_get_current_test()`` function in ``kunit/test-bug.h``.
``kunit_get_current_test()`` is safe to call even if KUnit is not enabled. If
-KUnit is not enabled, was built as a module (``CONFIG_KUNIT=m``), or no test is
-running in the current task, it will return ``NULL``. This compiles down to
-either a no-op or a static key check, so will have a negligible performance
-impact when no test is running.
+KUnit is not enabled, or if no test is running in the current task, it will
+return ``NULL``. This compiles down to either a no-op or a static key check,
+so will have a negligible performance impact when no test is running.
The example below uses this to implement a "mock" implementation of a function, ``foo``:
@@ -726,8 +725,6 @@
#endif
``kunit_fail_current_test()`` is safe to call even if KUnit is not enabled. If
-KUnit is not enabled, was built as a module (``CONFIG_KUNIT=m``), or no test is
-running in the current task, it will do nothing. This compiles down to either a
-no-op or a static key check, so will have a negligible performance impact when
-no test is running.
-
+KUnit is not enabled, or if no test is running in the current task, it will do
+nothing. This compiles down to either a no-op or a static key check, so will
+have a negligible performance impact when no test is running.
diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
index bf2d8a8..8b39589 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -28,7 +28,7 @@
find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
-name 'processed-schema*' \)
-find_cmd = $(find_all_cmd) | grep -F "$(DT_SCHEMA_FILES)"
+find_cmd = $(find_all_cmd) | grep -F -e "$(subst :," -e ",$(DT_SCHEMA_FILES))"
CHK_DT_DOCS := $(shell $(find_cmd))
quiet_cmd_yamllint = LINT $(src)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 3eee03a..8c75754 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -31,6 +31,7 @@
- description: Mercury+ AA1 boards
items:
- enum:
+ - enclustra,mercury-pe1
- google,chameleon-v3
- const: enclustra,mercury-aa1
- const: altr,socfpga-arria10
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index e16b5fa..b634d5b 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -154,6 +154,7 @@
items:
- enum:
- khadas,vim3
+ - radxa,zero2
- const: amlogic,a311d
- const: amlogic,g12b
@@ -165,6 +166,7 @@
- azw,gtking-pro
- hardkernel,odroid-go-ultra
- hardkernel,odroid-n2
+ - hardkernel,odroid-n2l
- hardkernel,odroid-n2-plus
- khadas,vim3
- ugoos,am6
@@ -176,6 +178,7 @@
- enum:
- amediatech,x96-air
- amediatech,x96-air-gbit
+ - bananapi,bpi-m2-pro
- bananapi,bpi-m5
- cyx,a95xf3-air
- cyx,a95xf3-air-gbit
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 73f2726..e0eff4c 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -78,6 +78,7 @@
- facebook,cloudripper-bmc
- facebook,elbert-bmc
- facebook,fuji-bmc
+ - facebook,greatlakes-bmc
- ibm,everest-bmc
- ibm,rainier-bmc
- ibm,tacoma-bmc
@@ -85,6 +86,7 @@
- jabil,rbp-bmc
- qcom,dc-scm-v1-bmc
- quanta,s6q-bmc
+ - ufispace,ncplite-bmc
- const: aspeed,ast2600
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
index 2224b18..dfb8fd0 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
@@ -91,9 +91,11 @@
- const: atmel,sama5d2
- const: atmel,sama5
- - description: SAM9X60-EK board
+ - description: Microchip SAM9X60 Evaluation Boards
items:
- - const: microchip,sam9x60ek
+ - enum:
+ - microchip,sam9x60ek
+ - microchip,sam9x60-curiosity
- const: microchip,sam9x60
- const: atmel,at91sam9
diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt b/Documentation/devicetree/bindings/arm/cpu-capacity.txt
deleted file mode 100644
index cc5e190..0000000
--- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt
+++ /dev/null
@@ -1,238 +0,0 @@
-==========================================
-ARM CPUs capacity bindings
-==========================================
-
-==========================================
-1 - Introduction
-==========================================
-
-ARM systems may be configured to have cpus with different power/performance
-characteristics within the same chip. In this case, additional information has
-to be made available to the kernel for it to be aware of such differences and
-take decisions accordingly.
-
-==========================================
-2 - CPU capacity definition
-==========================================
-
-CPU capacity is a number that provides the scheduler information about CPUs
-heterogeneity. Such heterogeneity can come from micro-architectural differences
-(e.g., ARM big.LITTLE systems) or maximum frequency at which CPUs can run
-(e.g., SMP systems with multiple frequency domains). Heterogeneity in this
-context is about differing performance characteristics; this binding tries to
-capture a first-order approximation of the relative performance of CPUs.
-
-CPU capacities are obtained by running a suitable benchmark. This binding makes
-no guarantees on the validity or suitability of any particular benchmark, the
-final capacity should, however, be:
-
-* A "single-threaded" or CPU affine benchmark
-* Divided by the running frequency of the CPU executing the benchmark
-* Not subject to dynamic frequency scaling of the CPU
-
-For the time being we however advise usage of the Dhrystone benchmark. What
-above thus becomes:
-
-CPU capacities are obtained by running the Dhrystone benchmark on each CPU at
-max frequency (with caches enabled). The obtained DMIPS score is then divided
-by the frequency (in MHz) at which the benchmark has been run, so that
-DMIPS/MHz are obtained. Such values are then normalized w.r.t. the highest
-score obtained in the system.
-
-==========================================
-3 - capacity-dmips-mhz
-==========================================
-
-capacity-dmips-mhz is an optional cpu node [1] property: u32 value
-representing CPU capacity expressed in normalized DMIPS/MHz. At boot time, the
-maximum frequency available to the cpu is then used to calculate the capacity
-value internally used by the kernel.
-
-capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu
-node, it has to be specified for every other cpu nodes, or the system will
-fall back to the default capacity value for every CPU. If cpufreq is not
-available, final capacities are calculated by directly using capacity-dmips-
-mhz values (normalized w.r.t. the highest value found while parsing the DT).
-
-===========================================
-4 - Examples
-===========================================
-
-Example 1 (ARM 64-bit, 6-cpu system, two clusters):
-The capacities-dmips-mhz or DMIPS/MHz values (scaled to 1024)
-are 1024 and 578 for cluster0 and cluster1. Further normalization
-is done by the operating system based on cluster0@max-freq=1100 and
-cluster1@max-freq=850, final capacities are 1024 for cluster0 and
-446 for cluster1 (578*850/1100).
-
-cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- cpu-map {
- cluster0 {
- core0 {
- cpu = <&A57_0>;
- };
- core1 {
- cpu = <&A57_1>;
- };
- };
-
- cluster1 {
- core0 {
- cpu = <&A53_0>;
- };
- core1 {
- cpu = <&A53_1>;
- };
- core2 {
- cpu = <&A53_2>;
- };
- core3 {
- cpu = <&A53_3>;
- };
- };
- };
-
- idle-states {
- entry-method = "psci";
-
- CPU_SLEEP_0: cpu-sleep-0 {
- compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x0010000>;
- local-timer-stop;
- entry-latency-us = <100>;
- exit-latency-us = <250>;
- min-residency-us = <150>;
- };
-
- CLUSTER_SLEEP_0: cluster-sleep-0 {
- compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x1010000>;
- local-timer-stop;
- entry-latency-us = <800>;
- exit-latency-us = <700>;
- min-residency-us = <2500>;
- };
- };
-
- A57_0: cpu@0 {
- compatible = "arm,cortex-a57";
- reg = <0x0 0x0>;
- device_type = "cpu";
- enable-method = "psci";
- next-level-cache = <&A57_L2>;
- clocks = <&scpi_dvfs 0>;
- cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
- capacity-dmips-mhz = <1024>;
- };
-
- A57_1: cpu@1 {
- compatible = "arm,cortex-a57";
- reg = <0x0 0x1>;
- device_type = "cpu";
- enable-method = "psci";
- next-level-cache = <&A57_L2>;
- clocks = <&scpi_dvfs 0>;
- cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
- capacity-dmips-mhz = <1024>;
- };
-
- A53_0: cpu@100 {
- compatible = "arm,cortex-a53";
- reg = <0x0 0x100>;
- device_type = "cpu";
- enable-method = "psci";
- next-level-cache = <&A53_L2>;
- clocks = <&scpi_dvfs 1>;
- cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
- capacity-dmips-mhz = <578>;
- };
-
- A53_1: cpu@101 {
- compatible = "arm,cortex-a53";
- reg = <0x0 0x101>;
- device_type = "cpu";
- enable-method = "psci";
- next-level-cache = <&A53_L2>;
- clocks = <&scpi_dvfs 1>;
- cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
- capacity-dmips-mhz = <578>;
- };
-
- A53_2: cpu@102 {
- compatible = "arm,cortex-a53";
- reg = <0x0 0x102>;
- device_type = "cpu";
- enable-method = "psci";
- next-level-cache = <&A53_L2>;
- clocks = <&scpi_dvfs 1>;
- cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
- capacity-dmips-mhz = <578>;
- };
-
- A53_3: cpu@103 {
- compatible = "arm,cortex-a53";
- reg = <0x0 0x103>;
- device_type = "cpu";
- enable-method = "psci";
- next-level-cache = <&A53_L2>;
- clocks = <&scpi_dvfs 1>;
- cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
- capacity-dmips-mhz = <578>;
- };
-
- A57_L2: l2-cache0 {
- compatible = "cache";
- };
-
- A53_L2: l2-cache1 {
- compatible = "cache";
- };
-};
-
-Example 2 (ARM 32-bit, 4-cpu system, two clusters,
- cpus 0,1@1GHz, cpus 2,3@500MHz):
-capacities-dmips-mhz are scaled w.r.t. 2 (cpu@0 and cpu@1), this means that first
-cpu@0 and cpu@1 are twice fast than cpu@2 and cpu@3 (at the same frequency)
-
-cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0>;
- capacity-dmips-mhz = <2>;
- };
-
- cpu1: cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <1>;
- capacity-dmips-mhz = <2>;
- };
-
- cpu2: cpu@2 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0x100>;
- capacity-dmips-mhz = <1>;
- };
-
- cpu3: cpu@3 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0x101>;
- capacity-dmips-mhz = <1>;
- };
-};
-
-===========================================
-5 - References
-===========================================
-
-[1] ARM Linux Kernel documentation - CPUs bindings
- Documentation/devicetree/bindings/arm/cpus.yaml
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 01b5a9c..c145f6a 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -141,6 +141,7 @@
- arm,cortex-a78ae
- arm,cortex-a510
- arm,cortex-a710
+ - arm,cortex-a715
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
@@ -151,6 +152,7 @@
- arm,cortex-r7
- arm,cortex-x1
- arm,cortex-x2
+ - arm,cortex-x3
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
@@ -257,7 +259,7 @@
capacity-dmips-mhz:
description:
- u32 value representing CPU capacity (see ./cpu-capacity.txt) in
+ u32 value representing CPU capacity (see ../cpu/cpu-capacity.txt) in
DMIPS/MHz, relative to highest capacity-dmips-mhz
in the system.
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 05b5276..442ce8f 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -88,12 +88,56 @@
items:
- enum:
- armadeus,imx28-apf28 # APF28 SoM
- - armadeus,imx28-apf28dev # APF28 SoM on APF28Dev board
+ - bluegiga,apx4devkit # Bluegiga APx4 SoM on dev board
+ - crystalfontz,cfa10036 # Crystalfontz CFA-10036 SoM
+ - eukrea,mbmx28lc
- fsl,imx28-evk
- i2se,duckbill
- i2se,duckbill-2
+ - karo,tx28 # Ka-Ro electronics TX28 module
+ - lwn,imx28-xea
+ - msr,m28cu3 # M28 SoM with custom base board
+ - schulercontrol,imx28-sps1
- technologic,imx28-ts4600
- const: fsl,imx28
+
+ - description: i.MX28 Aries M28 SoM Board
+ items:
+ - const: aries,m28
+ - const: denx,m28
+ - const: fsl,imx28
+
+ - description: i.MX28 Aries M28EVK Board
+ items:
+ - const: aries,m28evk
+ - const: denx,m28evk
+ - const: fsl,imx28
+
+ - description: i.MX28 Armadeus Systems APF28Dev Board
+ items:
+ - const: armadeus,imx28-apf28dev
+ - const: armadeus,imx28-apf28
+ - const: fsl,imx28
+
+ - description: i.MX28 Crystalfontz CFA-10036 based Boards
+ items:
+ - enum:
+ - crystalfontz,cfa10037
+ - crystalfontz,cfa10049
+ - crystalfontz,cfa10057
+ - crystalfontz,cfa10058
+ - const: crystalfontz,cfa10036
+ - const: fsl,imx28
+
+ - description: i.MX28 Crystalfontz CFA-10037 based Boards
+ items:
+ - enum:
+ - crystalfontz,cfa10055
+ - crystalfontz,cfa10056
+ - const: crystalfontz,cfa10037
+ - const: crystalfontz,cfa10036
+ - const: fsl,imx28
+
- description: i.MX28 Duckbill 2 based Boards
items:
- enum:
@@ -103,6 +147,19 @@
- const: i2se,duckbill-2
- const: fsl,imx28
+ - description: i.MX28 Eukrea Electromatique MBMX283LC Board
+ items:
+ - const: eukrea,mbmx283lc
+ - const: eukrea,mbmx28lc
+ - const: fsl,imx28
+
+ - description: i.MX28 Eukrea Electromatique MBMX287LC Board
+ items:
+ - const: eukrea,mbmx287lc
+ - const: eukrea,mbmx283lc
+ - const: eukrea,mbmx28lc
+ - const: fsl,imx28
+
- description: i.MX31 based Boards
items:
- enum:
@@ -173,6 +230,7 @@
- kiebackpeter,imx53-ddc # K+P imx53 DDC
- kiebackpeter,imx53-hsc # K+P imx53 HSC
- menlo,m53menlo # i.MX53 Menlo board
+ - starterkit,sk-imx53
- voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668
- const: fsl,imx53
@@ -644,6 +702,16 @@
- const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
- const: fsl,imx6ull
+ - description: i.MX6ULL DHCOM SoM based Boards
+ items:
+ - enum:
+ - dh,imx6ull-dhcom-drc02
+ - dh,imx6ull-dhcom-pdk2
+ - dh,imx6ull-dhcom-picoitx
+ - const: dh,imx6ull-dhcom-som # The DHCOR is soldered on the DHCOM
+ - const: dh,imx6ull-dhcor-som
+ - const: fsl,imx6ull
+
- description: i.MX6ULL PHYTEC phyBOARD-Segin
items:
- enum:
@@ -815,7 +883,6 @@
- enum:
- beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit
- boundary,imx8mm-nitrogen8mm # i.MX8MM Nitrogen Board
- - cloos,imx8mm-phg # i.MX8MM Cloos PHG Board
- dmo,imx8mm-data-modul-edm-sbc # i.MX8MM eDM SBC
- emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
@@ -830,7 +897,6 @@
- innocomm,wb15-evk # i.MX8MM Innocomm EVK board with WB15 SoM
- kontron,imx8mm-sl # i.MX8MM Kontron SL (N801X) SOM
- kontron,imx8mm-osm-s # i.MX8MM Kontron OSM-S (N802X) SOM
- - menlo,mx8menlo # i.MX8MM Menlo board with Verdin SoM
- toradex,verdin-imx8mm # Verdin iMX8M Mini Modules
- toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT
- toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules
@@ -861,8 +927,10 @@
- description: Toradex Boards with Verdin iMX8M Mini Modules
items:
- enum:
+ - menlo,mx8menlo # Verdin iMX8M Mini Module on i.MX8MM Menlo board
- toradex,verdin-imx8mm-nonwifi-dahlia # Verdin iMX8M Mini Module on Dahlia
- toradex,verdin-imx8mm-nonwifi-dev # Verdin iMX8M Mini Module on Verdin Development Board
+ - toradex,verdin-imx8mm-nonwifi-yavia # Verdin iMX8M Mini Module on Yavia
- const: toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Module without Wi-Fi / BT
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -872,6 +940,7 @@
- enum:
- toradex,verdin-imx8mm-wifi-dahlia # Verdin iMX8M Mini Wi-Fi / BT Module on Dahlia
- toradex,verdin-imx8mm-wifi-dev # Verdin iMX8M Mini Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-imx8mm-wifi-yavia # Verdin iMX8M Mini Wi-Fi / BT Module on Yavia
- const: toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Module
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -895,6 +964,7 @@
one compatible is needed.
items:
- enum:
+ - cloos,imx8mm-phg # i.MX8MM Cloos PHG Board
- tq,imx8mm-tqma8mqml-mba8mx # TQ-Systems GmbH i.MX8MM TQMa8MQML SOM on MBa8Mx
- const: tq,imx8mm-tqma8mqml # TQ-Systems GmbH i.MX8MM TQMa8MQML SOM
- const: fsl,imx8mm
@@ -931,10 +1001,11 @@
- description: i.MX8MP based Boards
items:
- enum:
- - dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM
- - dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board
+ - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
- fsl,imx8mp-evk # i.MX8MP EVK Board
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
+ - polyhex,imx8mp-debix # Polyhex Debix boards
+ - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board
- toradex,verdin-imx8mp # Verdin iMX8M Plus Modules
- toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Modules without Wi-Fi / BT
- toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
@@ -947,6 +1018,12 @@
- const: avnet,sm2s-imx8mp # SM2S-IMX8PLUS SoM
- const: fsl,imx8mp
+ - description: i.MX8MP DHCOM based Boards
+ items:
+ - const: dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board
+ - const: dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM
+ - const: fsl,imx8mp
+
- description: Engicam i.Core MX8M Plus SoM based boards
items:
- enum:
@@ -965,6 +1042,7 @@
- enum:
- toradex,verdin-imx8mp-nonwifi-dahlia # Verdin iMX8M Plus Module on Dahlia
- toradex,verdin-imx8mp-nonwifi-dev # Verdin iMX8M Plus Module on Verdin Development Board
+ - toradex,verdin-imx8mp-nonwifi-yavia # Verdin iMX8M Plus Module on Yavia
- const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -974,6 +1052,7 @@
- enum:
- toradex,verdin-imx8mp-wifi-dahlia # Verdin iMX8M Plus Wi-Fi / BT Module on Dahlia
- toradex,verdin-imx8mp-wifi-dev # Verdin iMX8M Plus Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-imx8mp-wifi-yavia # Verdin iMX8M Plus Wi-Fi / BT Module on Yavia
- const: toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Module
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -999,12 +1078,17 @@
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- google,imx8mq-phanbell # Google Coral Edge TPU
- kontron,pitx-imx8m # Kontron pITX-imx8m Board
- - mntre,reform2 # MNT Reform2 Laptop
- purism,librem5-devkit # Purism Librem5 devkit
- solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
- technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk
- const: fsl,imx8mq
+ - description: i.MX8MQ NITROGEN SoM based Boards
+ items:
+ - const: mntre,reform2 # MNT Reform2 Laptop
+ - const: boundary,imx8mq-nitrogen8m-som # i.MX8MQ NITROGEN SoM
+ - const: fsl,imx8mq
+
- description: Purism Librem5 phones
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 2275e5d..ae12b1c 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -246,6 +246,10 @@
- const: mediatek,mt8183
- items:
- enum:
+ - mediatek,mt8365-evk
+ - const: mediatek,mt8365
+ - items:
+ - enum:
- mediatek,mt8516-pumpkin
- const: mediatek,mt8516
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
index 0502db7..eccd4b7 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
@@ -10,6 +10,7 @@
- "mediatek,mt7622-ethsys", "syscon"
- "mediatek,mt7623-ethsys", "mediatek,mt2701-ethsys", "syscon"
- "mediatek,mt7629-ethsys", "syscon"
+ - "mediatek,mt7981-ethsys", "syscon"
- "mediatek,mt7986-ethsys", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
index 1d7c837..e997635 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
@@ -28,6 +28,7 @@
- mediatek,mt6797-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7629-infracfg
+ - mediatek,mt7981-infracfg
- mediatek,mt7986-infracfg
- mediatek,mt8135-infracfg
- mediatek,mt8167-infracfg
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index 0711f18..d141034 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -31,7 +31,11 @@
- mediatek,mt8173-mmsys
- mediatek,mt8183-mmsys
- mediatek,mt8186-mmsys
+ - mediatek,mt8188-vdosys0
- mediatek,mt8192-mmsys
+ - mediatek,mt8195-vdosys1
+ - mediatek,mt8195-vppsys0
+ - mediatek,mt8195-vppsys1
- mediatek,mt8365-mmsys
- const: syscon
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml
index 17fcbb4..d62d601 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml
@@ -28,11 +28,9 @@
- mediatek,mt8195-imp_iic_wrap_s
- mediatek,mt8195-imp_iic_wrap_w
- mediatek,mt8195-mfgcfg
- - mediatek,mt8195-vppsys0
- mediatek,mt8195-wpesys
- mediatek,mt8195-wpesys_vpp0
- mediatek,mt8195-wpesys_vpp1
- - mediatek,mt8195-vppsys1
- mediatek,mt8195-imgsys
- mediatek,mt8195-imgsys1_dip_top
- mediatek,mt8195-imgsys1_dip_nr
@@ -93,13 +91,6 @@
};
- |
- vppsys0: clock-controller@14000000 {
- compatible = "mediatek,mt8195-vppsys0";
- reg = <0x14000000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
wpesys: clock-controller@14e00000 {
compatible = "mediatek,mt8195-wpesys";
reg = <0x14e00000 0x1000>;
@@ -121,13 +112,6 @@
};
- |
- vppsys1: clock-controller@14f00000 {
- compatible = "mediatek,mt8195-vppsys1";
- reg = <0x14f00000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
imgsys: clock-controller@15000000 {
compatible = "mediatek,mt8195-imgsys";
reg = <0x15000000 0x1000>;
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
index 29ca7a1..d2c24c2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
@@ -8,6 +8,8 @@
- compatible: Should be:
- "mediatek,mt7622-sgmiisys", "syscon"
- "mediatek,mt7629-sgmiisys", "syscon"
+ - "mediatek,mt7981-sgmiisys_0", "syscon"
+ - "mediatek,mt7981-sgmiisys_1", "syscon"
- "mediatek,mt7986-sgmiisys_0", "syscon"
- "mediatek,mt7986-sgmiisys_1", "syscon"
- #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
new file mode 100644
index 0000000..2ec9b5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-tpda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trace, Profiling and Diagnostics Aggregator - TPDA
+
+description: |
+ TPDAs are responsible for packetization and timestamping of data sets
+ utilizing the MIPI STPv2 packet protocol. Pulling data sets from one or
+ more attached TPDM and pushing the resultant (packetized) data out a
+ master ATB interface. Performing an arbitrated ATB interleaving (funneling)
+ task for free-flowing data from TPDM (i.e. CMB and DSB data set flows).
+
+ There is no strict binding between TPDM and TPDA. TPDA can have multiple
+ TPDMs connect to it. But There must be only one TPDA in the path from the
+ TPDM source to TMC sink. TPDM can directly connect to TPDA's inport or
+ connect to funnel which will connect to TPDA's inport.
+
+ We can use the commands are similar to the below to validate TPDMs.
+ Enable coresight sink first.
+
+ echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
+ echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
+ echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test
+ echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test
+
+ The test data will be collected in the coresight sink which is enabled.
+ If rwp register of the sink is keeping updating when do integration_test
+ (by cat tmc_etf0/mgmt/rwp), it means there is data generated from TPDM
+ to sink.
+
+maintainers:
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Tao Zhang <quic_taozha@quicinc.com>
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,coresight-tpda
+ required:
+ - compatible
+
+properties:
+ $nodename:
+ pattern: "^tpda(@[0-9a-f]+)$"
+ compatible:
+ items:
+ - const: qcom,coresight-tpda
+ - const: arm,primecell
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb_pclk
+
+ in-ports:
+ type: object
+ description: |
+ Input connections from TPDM to TPDA
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ out-ports:
+ type: object
+ description: |
+ Output connections from the TPDA to legacy CoreSight trace bus.
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description:
+ Output connection from the TPDA to legacy CoreSight Trace bus.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - in-ports
+ - out-ports
+
+additionalProperties: false
+
+examples:
+ # minimum tpda definition.
+ - |
+ tpda@6004000 {
+ compatible = "qcom,coresight-tpda", "arm,primecell";
+ reg = <0x6004000 0x1000>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tpda_qdss_0_in_tpdm_dcc: endpoint {
+ remote-endpoint =
+ <&tpdm_dcc_out_tpda_qdss_0>;
+ };
+ };
+ };
+
+ out-ports {
+ port {
+ tpda_qdss_out_funnel_in0: endpoint {
+ remote-endpoint =
+ <&funnel_in0_in_tpda_qdss>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
new file mode 100644
index 0000000..5c08342
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-tpdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trace, Profiling and Diagnostics Monitor - TPDM
+
+description: |
+ The TPDM or Monitor serves as data collection component for various dataset
+ types specified in the QPMDA spec. It covers Implementation defined ((ImplDef),
+ Basic Counts (BC), Tenure Counts (TC), Continuous Multi-Bit (CMB), and Discrete
+ Single Bit (DSB). It performs data collection in the data producing clock
+ domain and transfers it to the data collection time domain, generally ATB
+ clock domain.
+
+ The primary use case of the TPDM is to collect data from different data
+ sources and send it to a TPDA for packetization, timestamping, and funneling.
+
+maintainers:
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Tao Zhang <quic_taozha@quicinc.com>
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,coresight-tpdm
+ required:
+ - compatible
+
+properties:
+ $nodename:
+ pattern: "^tpdm(@[0-9a-f]+)$"
+ compatible:
+ items:
+ - const: qcom,coresight-tpdm
+ - const: arm,primecell
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb_pclk
+
+ out-ports:
+ description: |
+ Output connections from the TPDM to coresight funnel/TPDA.
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description: Output connection from the TPDM to coresight
+ funnel/TPDA.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ # minimum TPDM definition. TPDM connect to coresight TPDA.
+ - |
+ tpdm@684c000 {
+ compatible = "qcom,coresight-tpdm", "arm,primecell";
+ reg = <0x0684c000 0x1000>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ out-ports {
+ port {
+ tpdm_prng_out_tpda_qdss: endpoint {
+ remote-endpoint =
+ <&tpda_qdss_in_tpdm_prng>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 27063a0..1bb24d4 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -35,6 +35,8 @@
mdm9615
msm8226
msm8916
+ msm8939
+ msm8953
msm8956
msm8974
msm8976
@@ -47,11 +49,13 @@
qru1000
sa8155p
sa8540p
+ sa8775p
sc7180
sc7280
sc8180x
sc8280xp
sda660
+ sdm450
sdm630
sdm632
sdm636
@@ -62,6 +66,7 @@
sdx65
sm4250
sm6115
+ sm6115p
sm6125
sm6350
sm6375
@@ -70,6 +75,7 @@
sm8250
sm8350
sm8450
+ sm8550
The 'board' element must be one of the following strings:
@@ -84,6 +90,7 @@
liquid
mtp
qrd
+ ride
sbc
x100
@@ -162,6 +169,12 @@
- items:
- enum:
+ - sony,kanuti-tulip
+ - square,apq8039-t2
+ - const: qcom,msm8939
+
+ - items:
+ - enum:
- sony,kugo-row
- sony,suzu-row
- const: qcom,msm8956
@@ -194,8 +207,10 @@
- items:
- enum:
+ - acer,a1-724
- alcatel,idol347
- asus,z00l
+ - gplus,fl8005a
- huawei,g7
- longcheer,l8910
- samsung,a3u-eur
@@ -203,8 +218,13 @@
- samsung,e5
- samsung,e7
- samsung,grandmax
+ - samsung,gt510
+ - samsung,gt58
- samsung,j5
+ - samsung,j5x
- samsung,serranove
+ - thwc,uf896
+ - thwc,ufi001c
- wingtech,wt88047
- const: qcom,msm8916
@@ -215,6 +235,15 @@
- items:
- enum:
+ - motorola,potter
+ - xiaomi,daisy
+ - xiaomi,mido
+ - xiaomi,tissot
+ - xiaomi,vince
+ - const: qcom,msm8953
+
+ - items:
+ - enum:
- lg,bullhead
- microsoft,talkman
- xiaomi,libra
@@ -627,6 +656,12 @@
- const: google,hoglin
- const: qcom,sc7280
+ - description: Qualcomm Technologies, Inc. sc7280 CRD Pro platform (newest rev)
+ items:
+ - const: google,zoglin-sku1536
+ - const: google,hoglin-sku1536
+ - const: qcom,sc7280
+
- description: Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform
items:
- const: qcom,sc7280-idp
@@ -679,6 +714,18 @@
- const: google,zombie-sku512
- const: qcom,sc7280
+ - description: Google Zombie with NVMe (newest rev)
+ items:
+ - const: google,zombie-sku2
+ - const: google,zombie-sku3
+ - const: google,zombie-sku515
+ - const: qcom,sc7280
+
+ - description: Google Zombie with LTE and NVMe (newest rev)
+ items:
+ - const: google,zombie-sku514
+ - const: qcom,sc7280
+
- items:
- enum:
- lenovo,flex-5g
@@ -695,6 +742,11 @@
- items:
- enum:
+ - motorola,ali
+ - const: qcom,sdm450
+
+ - items:
+ - enum:
- sony,discovery-row
- sony,kirin-row
- sony,pioneer-row
@@ -709,6 +761,7 @@
- items:
- enum:
- fairphone,fp3
+ - motorola,ocean
- const: qcom,sdm632
- items:
@@ -764,6 +817,11 @@
- items:
- enum:
+ - qcom,sa8775p-ride
+ - const: qcom,sa8775p
+
+ - items:
+ - enum:
- google,cheza
- google,cheza-rev1
- google,cheza-rev2
@@ -792,6 +850,12 @@
- items:
- enum:
+ - lenovo,j606f
+ - const: qcom,sm6115p
+ - const: qcom,sm6115
+
+ - items:
+ - enum:
- sony,pdx201
- const: qcom,sm6125
@@ -826,6 +890,7 @@
- qcom,sm8250-mtp
- sony,pdx203-generic
- sony,pdx206-generic
+ - xiaomi,elish
- const: qcom,sm8250
- items:
@@ -845,6 +910,11 @@
- sony,pdx224
- const: qcom,sm8450
+ - items:
+ - enum:
+ - qcom,sm8550-mtp
+ - const: qcom,sm8550
+
# Board compatibles go above
qcom,msm-id:
@@ -922,15 +992,22 @@
- qcom,apq8026
- qcom,apq8094
- qcom,apq8096
+ - qcom,msm8939
+ - qcom,msm8953
+ - qcom,msm8956
- qcom,msm8992
- qcom,msm8994
- qcom,msm8996
- qcom,msm8998
+ - qcom,sdm450
- qcom,sdm630
- qcom,sdm632
+ - qcom,sdm636
- qcom,sdm845
- qcom,sdx55
- qcom,sdx65
+ - qcom,sm4250
+ - qcom,sm6115
- qcom,sm6125
- qcom,sm6350
- qcom,sm7225
@@ -954,6 +1031,8 @@
- oneplus,dumpling
- oneplus,enchilada
- oneplus,fajita
+ - oneplus,oneplus3
+ - oneplus,oneplus3t
then:
properties:
qcom,board-id:
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 88ff442..35f74ed 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -90,11 +90,33 @@
- const: chipspark,rayeager-px2
- const: rockchip,rk3066a
+ - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
+ items:
+ - const: edgeble,neural-compute-module-2-io # Edgeble Neural Compute Module 2 IO Board
+ - const: edgeble,neural-compute-module-2 # Edgeble Neural Compute Module 2 SoM
+ - const: rockchip,rv1126
+
+ - description: Edgeble Neural Compute Module 6(Neu6) Model A SoM based boards
+ items:
+ - const: edgeble,neural-compute-module-6a-io # Edgeble Neural Compute Module 6A IO Board
+ - const: edgeble,neural-compute-module-6a # Edgeble Neural Compute Module 6A SoM
+ - const: rockchip,rk3588
+
- description: Elgin RV1108 R1
items:
- const: elgin,rv1108-r1
- const: rockchip,rv1108
+ - description: EmbedFire LubanCat 1
+ items:
+ - const: embedfire,lubancat-1
+ - const: rockchip,rk3566
+
+ - description: EmbedFire LubanCat 2
+ items:
+ - const: embedfire,lubancat-2
+ - const: rockchip,rk3568
+
- description: Engicam PX30.Core C.TOUCH 2.0
items:
- const: engicam,px30-core-ctouch2
@@ -599,6 +621,20 @@
- const: pine64,soquartz
- const: rockchip,rk3566
+ - description: Radxa Compute Module 3(CM3)
+ items:
+ - enum:
+ - radxa,cm3-io
+ - const: radxa,cm3
+ - const: rockchip,rk3566
+
+ - description: Radxa CM3 Industrial
+ items:
+ - enum:
+ - radxa,e25
+ - const: radxa,cm3i
+ - const: rockchip,rk3568
+
- description: Radxa Rock
items:
- const: radxa,rock
@@ -652,6 +688,16 @@
- const: radxa,rock3a
- const: rockchip,rk3568
+ - description: Radxa ROCK 5 Model A
+ items:
+ - const: radxa,rock-5a
+ - const: rockchip,rk3588s
+
+ - description: Radxa ROCK 5 Model B
+ items:
+ - const: radxa,rock-5b
+ - const: rockchip,rk3588
+
- description: Rikomagic MK808 v1
items:
- const: rikomagic,mk808
@@ -689,6 +735,11 @@
- const: rockchip,rk3036-evb
- const: rockchip,rk3036
+ - description: Rockchip RK3128 Evaluation board
+ items:
+ - const: rockchip,rk3128-evb
+ - const: rockchip,rk3128
+
- description: Rockchip RK3228 Evaluation board
items:
- const: rockchip,rk3228-evb
@@ -736,6 +787,11 @@
- const: rockchip,rk3399-sapphire-excavator
- const: rockchip,rk3399
+ - description: Rockchip RK3588 Evaluation board
+ items:
+ - const: rockchip,rk3588-evb1-v10
+ - const: rockchip,rk3588
+
- description: Rockchip RV1108 Evaluation board
items:
- const: rockchip,rv1108-evb
@@ -761,6 +817,11 @@
- const: tronsmart,orion-r68-meta
- const: rockchip,rk3368
+ - description: Xunlong Orange Pi R1 Plus
+ items:
+ - const: xunlong,orangepi-r1-plus
+ - const: rockchip,rk3328
+
- description: Zkmagic A95X Z2
items:
- const: zkmagic,a95x-z2
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
index 8c73bc7..b79c81c 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -27,6 +27,7 @@
- rockchip,rk3399-pmu
- rockchip,rk3568-pmu
- rockchip,rk3588-pmu
+ - rockchip,rv1126-pmu
required:
- compatible
@@ -43,6 +44,7 @@
- rockchip,rk3399-pmu
- rockchip,rk3568-pmu
- rockchip,rk3588-pmu
+ - rockchip,rv1126-pmu
- const: syscon
- const: simple-mfd
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index faea33e..deb2cf9 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -171,6 +171,7 @@
- hardkernel,odroid-xu3-lite # Hardkernel Odroid XU3 Lite
- hardkernel,odroid-xu4 # Hardkernel Odroid XU4
- hardkernel,odroid-hc1 # Hardkernel Odroid HC1
+ - samsung,k3g # Samsung Galaxy S5 (SM-G900H)
- const: samsung,exynos5800
- const: samsung,exynos5
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 203faab..a60a406 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -38,10 +38,17 @@
- ti,am642-sk
- const: ti,am642
+ - description: K3 AM642 SoC PHYTEC phyBOARD-Electra
+ items:
+ - const: phytec,am642-phyboard-electra-rdk
+ - const: phytec,am64-phycore-som
+ - const: ti,am642
+
- description: K3 AM654 SoC
items:
- enum:
- siemens,iot2050-advanced
+ - siemens,iot2050-advanced-m2
- siemens,iot2050-advanced-pg2
- siemens,iot2050-basic
- siemens,iot2050-basic-pg2
@@ -69,9 +76,17 @@
- description: K3 J721s2 SoC
items:
- enum:
+ - ti,am68-sk
- ti,j721s2-evm
- const: ti,j721s2
+ - description: K3 J784s4 SoC
+ items:
+ - enum:
+ - ti,am69-sk
+ - ti,j784s4-evm
+ - const: ti,j784s4
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml
index 52e1860..3786920 100644
--- a/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml
+++ b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml
@@ -35,6 +35,7 @@
allOf:
- $ref: pata-common.yaml#
+ - $ref: /schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml b/Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml
new file mode 100644
index 0000000..2894256
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/aspeed,ast2600-ahbc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED Advanced High-Performance Bus Controller (AHBC)
+
+maintainers:
+ - Neal Liu <neal_liu@aspeedtech.com>
+ - Chia-Wei Wang <chiawei_wang@aspeedtech.com>
+
+description: |
+ Advanced High-performance Bus Controller (AHBC) supports plenty of mechanisms
+ including a priority arbiter, an address decoder and a data multiplexer
+ to control the overall operations of Advanced High-performance Bus (AHB).
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-ahbc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ ahbc@1e600000 {
+ compatible = "aspeed,ast2600-ahbc";
+ reg = <0x1e600000 0x100>;
+ };
diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
deleted file mode 100644
index 5fb4e7b..0000000
--- a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
+++ /dev/null
@@ -1,168 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Intel IXP4xx Expansion Bus Controller
-
-description: |
- The IXP4xx expansion bus controller handles access to devices on the
- memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
- including IXP42x, IXP43x, IXP45x and IXP46x.
-
-maintainers:
- - Linus Walleij <linus.walleij@linaro.org>
-
-properties:
- $nodename:
- pattern: '^bus@[0-9a-f]+$'
-
- compatible:
- items:
- - enum:
- - intel,ixp42x-expansion-bus-controller
- - intel,ixp43x-expansion-bus-controller
- - intel,ixp45x-expansion-bus-controller
- - intel,ixp46x-expansion-bus-controller
- - const: syscon
-
- reg:
- description: Control registers for the expansion bus, these are not
- inside the memory range handled by the expansion bus.
- maxItems: 1
-
- native-endian:
- $ref: /schemas/types.yaml#/definitions/flag
- description: The IXP4xx has a peculiar MMIO access scheme, as it changes
- the access pattern for words (swizzling) on the bus depending on whether
- the SoC is running in big-endian or little-endian mode. Thus the
- registers must always be accessed using native endianness.
-
- "#address-cells":
- description: |
- The first cell is the chip select number.
- The second cell is the address offset within the bank.
- const: 2
-
- "#size-cells":
- const: 1
-
- ranges: true
- dma-ranges: true
-
-patternProperties:
- "^.*@[0-7],[0-9a-f]+$":
- description: Devices attached to chip selects are represented as
- subnodes.
- type: object
-
- properties:
- intel,ixp4xx-eb-t1:
- description: Address timing, extend address phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 3
-
- intel,ixp4xx-eb-t2:
- description: Setup chip select timing, extend setup phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 3
-
- intel,ixp4xx-eb-t3:
- description: Strobe timing, extend strobe phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 15
-
- intel,ixp4xx-eb-t4:
- description: Hold timing, extend hold phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 3
-
- intel,ixp4xx-eb-t5:
- description: Recovery timing, extend recovery phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 15
-
- intel,ixp4xx-eb-cycle-type:
- description: The type of cycles to use on the expansion bus for this
- chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
-
- intel,ixp4xx-eb-byte-access-on-halfword:
- description: Allow byte read access on half word devices.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-hpi-hrdy-pol-high:
- description: Set HPI HRDY polarity to active high when using HPI.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-mux-address-and-data:
- description: Multiplex address and data on the data bus.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-ahb-split-transfers:
- description: Enable AHB split transfers.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-write-enable:
- description: Enable write cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-byte-access:
- description: Expansion bus uses only 8 bits. The default is to use
- 16 bits.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
-required:
- - compatible
- - reg
- - native-endian
- - "#address-cells"
- - "#size-cells"
- - ranges
- - dma-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
- bus@50000000 {
- compatible = "intel,ixp42x-expansion-bus-controller", "syscon";
- reg = <0xc4000000 0x28>;
- native-endian;
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0x0 0x50000000 0x01000000>,
- <1 0x0 0x51000000 0x01000000>;
- dma-ranges = <0 0x0 0x50000000 0x01000000>,
- <1 0x0 0x51000000 0x01000000>;
- flash@0,0 {
- compatible = "intel,ixp4xx-flash", "cfi-flash";
- bank-width = <2>;
- reg = <0 0x00000000 0x1000000>;
- intel,ixp4xx-eb-t3 = <3>;
- intel,ixp4xx-eb-cycle-type = <0>;
- intel,ixp4xx-eb-byte-access-on-halfword = <1>;
- intel,ixp4xx-eb-write-enable = <1>;
- intel,ixp4xx-eb-byte-access = <0>;
- };
- serial@1,0 {
- compatible = "exar,xr16l2551", "ns8250";
- reg = <1 0x00000000 0x10>;
- interrupt-parent = <&gpio0>;
- interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
- clock-frequency = <1843200>;
- intel,ixp4xx-eb-t3 = <3>;
- intel,ixp4xx-eb-cycle-type = <1>;
- intel,ixp4xx-eb-write-enable = <1>;
- intel,ixp4xx-eb-byte-access = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
index d3ed048..4157e88 100644
--- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
@@ -40,10 +40,10 @@
maxItems: 1
"#address-cells":
- const: 1
+ enum: [ 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
ranges: true
diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
index 61b246c..a2c6eea 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
@@ -54,6 +54,7 @@
- idt,5p49v5925
- idt,5p49v5933
- idt,5p49v5935
+ - idt,5p49v60
- idt,5p49v6901
- idt,5p49v6965
- idt,5p49v6975
diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
index e4c4cad..0dbc143 100644
--- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
@@ -108,7 +108,7 @@
};
- |
- clock-controller@30390000 {
+ clock-controller@30380000 {
compatible = "fsl,imx8mq-ccm";
reg = <0x30380000 0x10000>;
#clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml b/Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml
new file mode 100644
index 0000000..63a5901
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/loongson,ls2k-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 SoC Clock Control Module
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+description: |
+ Loongson-2 SoC clock control module is an integrated clock controller, which
+ generates and supplies to all modules.
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: 100m ref
+
+ clock-names:
+ items:
+ - const: ref_100m
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/loongson,ls2k-clk.h
+ for the full list of Loongson-2 SoC clock IDs.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ ref_100m: clock-ref-100m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "ref_100m";
+ };
+
+ clk: clock-controller@1fe00480 {
+ compatible = "loongson,ls2k-clk";
+ reg = <0x1fe00480 0x58>;
+ #clock-cells = <1>;
+ clocks = <&ref_100m>;
+ clock-names = "ref_100m";
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 731bfe0..dae25db 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -20,6 +20,7 @@
- enum:
- mediatek,mt6797-apmixedsys
- mediatek,mt7622-apmixedsys
+ - mediatek,mt7981-apmixedsys
- mediatek,mt7986-apmixedsys
- mediatek,mt8135-apmixedsys
- mediatek,mt8173-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 81531b5..0fdf564 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -35,6 +35,7 @@
- mediatek,mt6779-topckgen
- mediatek,mt6795-topckgen
- mediatek,mt7629-topckgen
+ - mediatek,mt7981-topckgen
- mediatek,mt7986-topckgen
- mediatek,mt8167-topckgen
- mediatek,mt8183-topckgen
diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
index 93ec1f5..426335a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
@@ -21,12 +21,16 @@
clocks:
items:
+ - description: AHB
- description: Board XO source
+ - description: Board active XO source
- description: Sleep clock source
clock-names:
items:
+ - const: iface
- const: bi_tcxo
+ - const: bi_tcxo_ao
- const: sleep_clk
'#clock-cells':
@@ -38,9 +42,18 @@
'#power-domain-cells':
const: 1
+ power-domains:
+ items:
+ - description: MMCX power domain
+
reg:
maxItems: 1
+ required-opps:
+ maxItems: 1
+ description:
+ OPP node describing required MMCX performance point.
+
required:
- compatible
- reg
@@ -54,13 +67,16 @@
examples:
- |
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@ad00000 {
compatible = "qcom,sm8250-camcc";
reg = <0x0ad00000 0x10000>;
- clocks = <&rpmhcc RPMH_CXO_CLK>,
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- clock-names = "bi_tcxo", "sleep_clk";
+ clock-names = "iface", "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
index 8ade176..d846082 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
@@ -25,6 +25,30 @@
compatible:
const: qcom,gcc-apq8084
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+ - description: UFS RX symbol 0 clock
+ - description: UFS RX symbol 1 clock
+ - description: UFS TX symbol 0 clock
+ - description: UFS TX symbol 1 clock
+ - description: SATA ASIC0 clock
+ - description: SATA RX clock
+ - description: PCIe PIPE clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: ufs_rx_symbol_0_clk_src
+ - const: ufs_rx_symbol_1_clk_src
+ - const: ufs_tx_symbol_0_clk_src
+ - const: ufs_tx_symbol_1_clk_src
+ - const: sata_asic0_clk
+ - const: sata_rx_clk
+ - const: pcie_pipe
+
required:
- compatible
@@ -32,11 +56,31 @@
examples:
- |
+ /* UFS PHY on APQ8084 is not supported (yet), so these bindings just serve an example */
clock-controller@fc400000 {
compatible = "qcom,gcc-apq8084";
reg = <0xfc400000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
+
+ clocks = <&xo_board>,
+ <&sleep_clk>,
+ <&ufsphy 0>,
+ <&ufsphy 1>,
+ <&ufsphy 2>,
+ <&ufsphy 3>,
+ <&sata 0>,
+ <&sata 1>,
+ <&pcie_phy>;
+ clock-names = "xo",
+ "sleep_clk",
+ "ufs_rx_symbol_0_clk_src",
+ "ufs_rx_symbol_1_clk_src",
+ "ufs_tx_symbol_0_clk_src",
+ "ufs_tx_symbol_1_clk_src",
+ "sata_asic0_clk",
+ "sata_rx_clk",
+ "pcie_pipe";
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
index 2d5355c..3c97290 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
@@ -25,7 +25,6 @@
- description: Board XO source
- description: Sleep clock source
- description: Audio reference clock (Optional clock)
- - description: PLL test clock source (Optional clock)
minItems: 2
clock-names:
@@ -33,7 +32,6 @@
- const: xo
- const: sleep_clk
- const: aud_ref_clk # Optional clock
- - const: core_bi_pll_test_se # Optional clock
minItems: 2
required:
@@ -57,11 +55,9 @@
reg = <0x00100000 0xb0000>;
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&sleep>,
- <0>,
<0>;
clock-names = "xo",
"sleep_clk",
- "aud_ref_clk",
- "core_bi_pll_test_se";
+ "aud_ref_clk";
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
index dca5775..b2256f8 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
@@ -20,26 +20,31 @@
compatible:
const: qcom,gcc-qcs404
- '#clock-cells':
- const: 1
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+ - description: PCIe 0 PIPE clock (optional)
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: HDMI phy PLL clock
- '#reset-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
+ clock-names:
+ items:
+ - const: cxo
+ - const: sleep_clk
+ - const: pcie_0_pipe_clk_src
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: hdmi_pll
required:
- compatible
- - reg
- - '#clock-cells'
- - '#reset-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -48,5 +53,6 @@
reg = <0x01800000 0x80000>;
#clock-cells = <1>;
#reset-cells = <1>;
+ #power-domain-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml
index c9d8e43..5681e53 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml
@@ -55,6 +55,10 @@
- description: First EMAC controller reference clock
- description: Second EMAC controller reference clock
+ power-domains:
+ items:
+ - description: CX domain
+
protected-clocks:
maxItems: 389
@@ -70,6 +74,8 @@
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
clock-controller@100000 {
compatible = "qcom,gcc-sc8280xp";
reg = <0x00100000 0x1f0000>;
@@ -106,6 +112,7 @@
<&pcie4_lane>,
<&rxc0_ref_clk>,
<&rxc1_ref_clk>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
index 68d3099..428e954 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
@@ -24,15 +24,11 @@
items:
- description: Board XO source
- description: Sleep clock source
- - description: PLL test clock source (Optional clock)
- minItems: 2
clock-names:
items:
- const: bi_tcxo
- const: sleep_clk
- - const: core_bi_pll_test_se # Optional clock
- minItems: 2
required:
- compatible
@@ -51,8 +47,9 @@
compatible = "qcom,gcc-sdx55";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
- <&sleep_clk>, <&pll_test_clk>;
- clock-names = "bi_tcxo", "sleep_clk", "core_bi_pll_test_se";
+ <&sleep_clk>;
+ clock-names = "bi_tcxo",
+ "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml
index ba62baa..523e18d7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml
@@ -26,8 +26,6 @@
- description: Sleep clock source
- description: PCIE Pipe clock source
- description: USB3 phy wrapper pipe clock source
- - description: PLL test clock source (Optional clock)
- minItems: 5
clock-names:
items:
@@ -36,8 +34,6 @@
- const: sleep_clk
- const: pcie_pipe_clk
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk
- - const: core_bi_pll_test_se # Optional clock
- minItems: 5
required:
- compatible
@@ -56,9 +52,9 @@
compatible = "qcom,gcc-sdx65";
reg = <0x100000 0x1f7400>;
clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>,
- <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>, <&pll_test_clk>;
+ <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk",
- "pcie_pipe_clk", "usb3_phy_wrapper_gcc_usb30_pipe_clk", "core_bi_pll_test_se";
+ "pcie_pipe_clk", "usb3_phy_wrapper_gcc_usb30_pipe_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
index 703d9e0..b4fdde7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
@@ -23,7 +23,6 @@
items:
- description: Board XO source
- description: Sleep clock source
- - description: PLL test clock source (Optional clock)
- description: PCIE 0 Pipe clock source (Optional clock)
- description: PCIE 1 Pipe clock source (Optional clock)
- description: UFS card Rx symbol 0 clock source (Optional clock)
@@ -40,7 +39,6 @@
items:
- const: bi_tcxo
- const: sleep_clk
- - const: core_bi_pll_test_se # Optional clock
- const: pcie_0_pipe_clk # Optional clock
- const: pcie_1_pipe_clk # Optional clock
- const: ufs_card_rx_symbol_0_clk # Optional clock
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
deleted file mode 100644
index fb7ae3d1..0000000
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/qcom,gpucc-sm8350.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Graphics Clock & Reset Controller on SM8350
-
-maintainers:
- - Robert Foss <robert.foss@linaro.org>
-
-description: |
- Qualcomm graphics clock control module provides the clocks, resets and power
- domains on Qualcomm SoCs.
-
- See also:: include/dt-bindings/clock/qcom,gpucc-sm8350.h
-
-properties:
- compatible:
- enum:
- - qcom,sm8350-gpucc
-
- clocks:
- items:
- - description: Board XO source
- - description: GPLL0 main branch source
- - description: GPLL0 div branch source
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
-required:
- - compatible
- - reg
- - clocks
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sm8350.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
-
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
-
- clock-controller@3d90000 {
- compatible = "qcom,sm8350-gpucc";
- reg = <0 0x03d90000 0 0x9000>;
- clocks = <&rpmhcc RPMH_CXO_CLK>,
- <&gcc GCC_GPU_GPLL0_CLK_SRC>,
- <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- #power-domain-cells = <1>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 7256c43..db53eb2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -21,6 +21,7 @@
include/dt-bindings/clock/qcom,gpucc-sm6350.h
include/dt-bindings/clock/qcom,gpucc-sm8150.h
include/dt-bindings/clock/qcom,gpucc-sm8250.h
+ include/dt-bindings/clock/qcom,gpucc-sm8350.h
properties:
compatible:
@@ -33,6 +34,7 @@
- qcom,sm6350-gpucc
- qcom,sm8150-gpucc
- qcom,sm8250-gpucc
+ - qcom,sm8350-gpucc
clocks:
items:
diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
index e6d1742..acf0c92 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
@@ -32,11 +32,11 @@
clocks:
minItems: 8
- maxItems: 10
+ maxItems: 13
clock-names:
minItems: 8
- maxItems: 10
+ maxItems: 13
'#clock-cells':
const: 1
@@ -142,6 +142,46 @@
compatible:
contains:
enum:
+ - qcom,mmcc-apq8084
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board sleep source
+ - description: MMSS GPLL0 voted clock
+ - description: GPLL0 clock
+ - description: GPLL0 voted clock
+ - description: GPLL1 clock
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: HDMI phy PLL clock
+ - description: eDP phy PLL link clock
+ - description: eDP phy PLL vco clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: mmss_gpll0_vote
+ - const: gpll0
+ - const: gpll0_vote
+ - const: gpll1
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: hdmipll
+ - const: edp_link_clk
+ - const: edp_vco_div
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,mmcc-msm8994
- qcom,mmcc-msm8998
- qcom,mmcc-sdm630
@@ -229,7 +269,6 @@
- description: HDMI phy PLL clock
- description: DisplayPort phy PLL link clock
- description: DisplayPort phy PLL vco clock
- - description: Test clock
clock-names:
items:
@@ -242,7 +281,6 @@
- const: hdmipll
- const: dplink
- const: dpvco
- - const: core_bi_pll_test_se
- if:
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml
index c497123..fcace96 100644
--- a/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml
@@ -27,10 +27,12 @@
clocks:
items:
- description: XO source
+ - description: SYS APCS AUX clock
clock-names:
items:
- const: xo
+ - const: sys_apcs_aux
required:
- compatible
@@ -48,6 +50,6 @@
reg = <0x6400000 0x90000>;
#clock-cells = <1>;
- clocks = <&xo_board>;
- clock-names = "xo";
+ clocks = <&xo_board>, <&apcs_glb>;
+ clock-names = "xo", "sys_apcs_aux";
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
new file mode 100644
index 0000000..3ffe69d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,msm8996-cbf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8996 Core Bus Fabric (CBF) clock controller
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description: >
+ The clock controller for the Qualcomm MSM8996 CBF clock, which drives the
+ interconnect between two CPU clusters.
+
+properties:
+ compatible:
+ const: qcom,msm8996-cbf
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO source
+ - description: SYS APCS AUX clock
+
+ '#clock-cells':
+ const: 0
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#interconnect-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ clock-controller@9a11000 {
+ compatible = "qcom,msm8996-cbf";
+ reg = <0x09a11000 0x10000>;
+ clocks = <&rpmcc RPM_SMD_BB_CLK1>, <&apcs_glb>;
+ #clock-cells = <0>;
+ #interconnect-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
new file mode 100644
index 0000000..767a9d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qdu1000-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller for QDU1000 and QRU1000
+
+maintainers:
+ - Melody Olvera <quic_molvera@quicinc.com>
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on QDU1000 and QRU1000
+
+ See also:: include/dt-bindings/clock/qcom,qdu1000-gcc.h
+
+properties:
+ compatible:
+ const: qcom,qdu1000-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 0 Phy Auxiliary clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,qdu1000-gcc";
+ reg = <0x00100000 0x001f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>,
+ <&pcie_0_pipe_clk>, <&pcie_0_phy_aux_clk>,
+ <&usb3_phy_wrapper_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
index cf25ba04..d5a250b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
@@ -18,6 +18,7 @@
compatible:
enum:
- qcom,qdu1000-rpmh-clk
+ - qcom,sa8775p-rpmh-clk
- qcom,sc7180-rpmh-clk
- qcom,sc7280-rpmh-clk
- qcom,sc8180x-rpmh-clk
@@ -31,6 +32,7 @@
- qcom,sm8250-rpmh-clk
- qcom,sm8350-rpmh-clk
- qcom,sm8450-rpmh-clk
+ - qcom,sm8550-rpmh-clk
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml
new file mode 100644
index 0000000..0f641c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sa8775p-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on sa8775p
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and
+ power domains on sa8775p.
+
+ See also:: include/dt-bindings/clock/qcom,sa8775p-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sa8775p-gcc
+
+ clocks:
+ items:
+ - description: XO reference clock
+ - description: Sleep clock
+ - description: UFS memory first RX symbol clock
+ - description: UFS memory second RX symbol clock
+ - description: UFS memory first TX symbol clock
+ - description: UFS card first RX symbol clock
+ - description: UFS card second RX symbol clock
+ - description: UFS card first TX symbol clock
+ - description: Primary USB3 PHY wrapper pipe clock
+ - description: Secondary USB3 PHY wrapper pipe clock
+ - description: PCIe 0 pipe clock
+ - description: PCIe 1 pipe clock
+ - description: PCIe PHY clock
+ - description: First EMAC controller reference clock
+ - description: Second EMAC controller reference clock
+
+ protected-clocks:
+ maxItems: 240
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ gcc: clock-controller@100000 {
+ compatible = "qcom,sa8775p-gcc";
+ reg = <0x100000 0xc7018>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&ufs_phy_rx_symbol_0_clk>,
+ <&ufs_phy_rx_symbol_1_clk>,
+ <&ufs_phy_tx_symbol_0_clk>,
+ <&ufs_card_rx_symbol_0_clk>,
+ <&ufs_card_rx_symbol_1_clk>,
+ <&ufs_card_tx_symbol_0_clk>,
+ <&usb_0_ssphy>,
+ <&usb_1_ssphy>,
+ <&pcie_0_pipe_clk>,
+ <&pcie_1_pipe_clk>,
+ <&pcie_phy_pipe_clk>,
+ <&rxc0_ref_clk>,
+ <&rxc1_ref_clk>;
+ power-domains = <&rpmhpd SA8775P_CX>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml
new file mode 100644
index 0000000..fd6658c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6350-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SM6350
+
+maintainers:
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SM6350.
+
+ See also:: include/dt-bindings/clock/qcom,sm6350-camcc.h
+
+properties:
+ compatible:
+ const: qcom,sm6350-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@ad00000 {
+ compatible = "qcom,sm6350-camcc";
+ reg = <0x0ad00000 0x16000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
index a52a83f..87ae741 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
@@ -32,6 +32,7 @@
A phandle and PM domain specifier for the MMCX power domain.
required-opps:
+ maxItems: 1
description:
A phandle to an OPP node describing required MMCX performance point.
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
new file mode 100644
index 0000000..ab25f7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8550-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller for SM8550
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM8550.
+
+ See also:: include/dt-bindings/clock/qcom,sm8550-dispcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8550-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
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sm8550-dispcc";
+ reg = <0x0af00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&sleep_clk>,
+ <&dsi0_phy 0>,
+ <&dsi0_phy 1>,
+ <&dsi1_phy 0>,
+ <&dsi1_phy 1>,
+ <&dp0_phy 0>,
+ <&dp0_phy 1>,
+ <&dp1_phy 0>,
+ <&dp1_phy 1>,
+ <&dp2_phy 0>,
+ <&dp2_phy 1>,
+ <&dp3_phy 0>,
+ <&dp3_phy 1>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ power-domains = <&rpmhpd SM8550_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
new file mode 100644
index 0000000..1bf1a41
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8550-tcsr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm TCSR Clock Controller on SM8550
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Qualcomm TCSR clock control module provides the clocks, resets and
+ power domains on SM8550
+
+ See also:: include/dt-bindings/clock/qcom,sm8550-tcsr.h
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sm8550-tcsr
+ - const: syscon
+
+ clocks:
+ items:
+ - description: TCXO pad clock
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ clock-controller@1fc0000 {
+ compatible = "qcom,sm8550-tcsr", "syscon";
+ reg = <0x1fc0000 0x30000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt b/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt
deleted file mode 100644
index 7474aba..0000000
--- a/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
-
-clkdiv configures the clock frequency of a set of outputs on the PMIC.
-These clocks are typically wired through alternate functions on
-gpio pins.
-
-=======================
-Properties
-=======================
-
-- compatible
- Usage: required
- Value type: <string>
- Definition: must be "qcom,spmi-clkdiv".
-
-- reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: base address of CLKDIV peripherals.
-
-- qcom,num-clkdivs
- Usage: required
- Value type: <u32>
- Definition: number of CLKDIV peripherals.
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the xo clock.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "xo".
-
-- #clock-cells:
- Usage: required
- Value type: <u32>
- Definition: shall contain 1.
-
-=======
-Example
-=======
-
-pm8998_clk_divs: clock-controller@5b00 {
- compatible = "qcom,spmi-clkdiv";
- reg = <0x5b00>;
- #clock-cells = <1>;
- qcom,num-clkdivs = <3>;
- clocks = <&xo_board>;
- clock-names = "xo";
-
- assigned-clocks = <&pm8998_clk_divs 1>,
- <&pm8998_clk_divs 2>,
- <&pm8998_clk_divs 3>;
- assigned-clock-rates = <9600000>,
- <9600000>,
- <9600000>;
-};
diff --git a/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml b/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml
new file mode 100644
index 0000000..16c95ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,spmi-clkdiv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SPMI PMIC clock divider
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+ Qualcomm SPMI PMIC clock divider configures the clock frequency of a set of
+ outputs on the PMIC. These clocks are typically wired through alternate
+ functions on GPIO pins.
+
+properties:
+ compatible:
+ const: qcom,spmi-clkdiv
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Board XO source
+
+ clock-names:
+ items:
+ - const: xo
+
+ "#clock-cells":
+ const: 1
+
+ qcom,num-clkdivs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of CLKDIV peripherals.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+ - qcom,num-clkdivs
+
+additionalProperties: false
+
+examples:
+ - |
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@5b00 {
+ compatible = "qcom,spmi-clkdiv";
+ reg = <0x5b00>;
+ clocks = <&xo_board>;
+ clock-names = "xo";
+ #clock-cells = <1>;
+ qcom,num-clkdivs = <3>;
+
+ assigned-clocks = <&pm8998_clk_divs 1>,
+ <&pm8998_clk_divs 2>,
+ <&pm8998_clk_divs 3>;
+ assigned-clock-rates = <9600000>,
+ <9600000>,
+ <9600000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index e221985..2b07146 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -30,12 +30,12 @@
- qcom,sm8250-videocc
clocks:
- items:
- - description: Board XO source
+ minItems: 1
+ maxItems: 3
clock-names:
- items:
- - const: bi_tcxo
+ minItems: 1
+ maxItems: 3
'#clock-cells':
const: 1
@@ -68,6 +68,57 @@
- '#reset-cells'
- '#power-domain-cells'
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-videocc
+ - qcom,sdm845-videocc
+ - qcom,sm8150-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ clock-names:
+ items:
+ - const: bi_tcxo
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8250-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: AHB
+ - description: Board XO source
+ - description: Board active XO source
+ clock-names:
+ items:
+ - const: iface
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
deleted file mode 100644
index 2632d3f..0000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Samsung S3C2410 Clock Controller
-
-The S3C2410 clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to the s3c2410,
-s3c2440 and s3c2442 SoCs in the s3c24x family.
-
-Required Properties:
-
-- compatible: should be one of the following.
- - "samsung,s3c2410-clock" - controller compatible with S3C2410 SoC.
- - "samsung,s3c2440-clock" - controller compatible with S3C2440 SoC.
- - "samsung,s3c2442-clock" - controller compatible with S3C2442 SoC.
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular SoC.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/s3c2410.h header and can be used in device
-tree sources.
-
-External clocks:
-
-The xti clock used as input for the plls is generated outside the SoC. It is
-expected that is are defined using standard clock bindings with a
-clock-output-names value of "xti".
-
-Example: Clock controller node:
-
- clocks: clock-controller@4c000000 {
- compatible = "samsung,s3c2410-clock";
- reg = <0x4c000000 0x20>;
- #clock-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- serial@50004000 {
- compatible = "samsung,s3c2440-uart";
- reg = <0x50004000 0x4000>;
- interrupts = <1 23 3 4>, <1 23 4 4>;
- clock-names = "uart", "clk_uart_baud2";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>;
- };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt
deleted file mode 100644
index 21a8c23..0000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Samsung S3C2412 Clock Controller
-
-The S3C2412 clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to the s3c2412
-and s3c2413 SoCs in the s3c24x family.
-
-Required Properties:
-
-- compatible: should be "samsung,s3c2412-clock"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular SoC.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/s3c2412.h header and can be used in device
-tree sources.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "xti" - crystal input - required,
- - "ext" - external clock source - optional,
-
-Example: Clock controller node:
-
- clocks: clock-controller@4c000000 {
- compatible = "samsung,s3c2412-clock";
- reg = <0x4c000000 0x20>;
- #clock-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- serial@50004000 {
- compatible = "samsung,s3c2412-uart";
- reg = <0x50004000 0x4000>;
- interrupts = <1 23 3 4>, <1 23 4 4>;
- clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
- <&clocks SCLK_UART>;
- };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
deleted file mode 100644
index 985c0f5..0000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-* Samsung S3C2443 Clock Controller
-
-The S3C2443 clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to all SoCs in
-the s3c24x family starting with the s3c2443.
-
-Required Properties:
-
-- compatible: should be one of the following.
- - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC.
- - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC.
- - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC.
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular SoC.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/s3c2443.h header and can be used in device
-tree sources.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "xti" - crystal input - required,
- - "ext" - external clock source - optional,
- - "ext_i2s" - external I2S clock - optional,
- - "ext_uart" - external uart clock - optional,
-
-Example: Clock controller node:
-
- clocks: clock-controller@4c000000 {
- compatible = "samsung,s3c2416-clock";
- reg = <0x4c000000 0x40>;
- #clock-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- serial@50004000 {
- compatible = "samsung,s3c2440-uart";
- reg = <0x50004000 0x4000>;
- interrupts = <1 23 3 4>, <1 23 4 4>;
- clock-names = "uart", "clk_uart_baud2",
- "clk_uart_baud3";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
- <&clocks SCLK_UART>;
- };
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
index c3be1b6..c79e752 100644
--- a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
+++ b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
@@ -8,7 +8,6 @@
title: SiFive FU540 Power Reset Clock Interrupt Controller (PRCI)
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
description:
diff --git a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
index 9a0cc73..4e82582 100644
--- a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
@@ -61,40 +61,7 @@
examples:
- |
- sysctrl@61840000 {
- compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon";
- reg = <0x61840000 0x4000>;
-
- clock {
- compatible = "socionext,uniphier-ld11-clock";
- #clock-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- mioctrl@59810000 {
- compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon";
- reg = <0x59810000 0x800>;
-
- clock {
- compatible = "socionext,uniphier-ld11-mio-clock";
- #clock-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- perictrl@59820000 {
- compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon";
- reg = <0x59820000 0x200>;
-
- clock {
- compatible = "socionext,uniphier-ld11-peri-clock";
- #clock-cells = <1>;
- };
-
- // other nodes ...
+ clock-controller {
+ compatible = "socionext,uniphier-ld11-clock";
+ #clock-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/cpu/cpu-capacity.txt b/Documentation/devicetree/bindings/cpu/cpu-capacity.txt
new file mode 100644
index 0000000..f28e1ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpu/cpu-capacity.txt
@@ -0,0 +1,238 @@
+==========================================
+CPU capacity bindings
+==========================================
+
+==========================================
+1 - Introduction
+==========================================
+
+Some systems may be configured to have cpus with different power/performance
+characteristics within the same chip. In this case, additional information has
+to be made available to the kernel for it to be aware of such differences and
+take decisions accordingly.
+
+==========================================
+2 - CPU capacity definition
+==========================================
+
+CPU capacity is a number that provides the scheduler information about CPUs
+heterogeneity. Such heterogeneity can come from micro-architectural differences
+(e.g., ARM big.LITTLE systems) or maximum frequency at which CPUs can run
+(e.g., SMP systems with multiple frequency domains). Heterogeneity in this
+context is about differing performance characteristics; this binding tries to
+capture a first-order approximation of the relative performance of CPUs.
+
+CPU capacities are obtained by running a suitable benchmark. This binding makes
+no guarantees on the validity or suitability of any particular benchmark, the
+final capacity should, however, be:
+
+* A "single-threaded" or CPU affine benchmark
+* Divided by the running frequency of the CPU executing the benchmark
+* Not subject to dynamic frequency scaling of the CPU
+
+For the time being we however advise usage of the Dhrystone benchmark. What
+above thus becomes:
+
+CPU capacities are obtained by running the Dhrystone benchmark on each CPU at
+max frequency (with caches enabled). The obtained DMIPS score is then divided
+by the frequency (in MHz) at which the benchmark has been run, so that
+DMIPS/MHz are obtained. Such values are then normalized w.r.t. the highest
+score obtained in the system.
+
+==========================================
+3 - capacity-dmips-mhz
+==========================================
+
+capacity-dmips-mhz is an optional cpu node [1] property: u32 value
+representing CPU capacity expressed in normalized DMIPS/MHz. At boot time, the
+maximum frequency available to the cpu is then used to calculate the capacity
+value internally used by the kernel.
+
+capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu
+node, it has to be specified for every other cpu nodes, or the system will
+fall back to the default capacity value for every CPU. If cpufreq is not
+available, final capacities are calculated by directly using capacity-dmips-
+mhz values (normalized w.r.t. the highest value found while parsing the DT).
+
+===========================================
+4 - Examples
+===========================================
+
+Example 1 (ARM 64-bit, 6-cpu system, two clusters):
+The capacities-dmips-mhz or DMIPS/MHz values (scaled to 1024)
+are 1024 and 578 for cluster0 and cluster1. Further normalization
+is done by the operating system based on cluster0@max-freq=1100 and
+cluster1@max-freq=850, final capacities are 1024 for cluster0 and
+446 for cluster1 (578*850/1100).
+
+cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&A57_0>;
+ };
+ core1 {
+ cpu = <&A57_1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&A53_0>;
+ };
+ core1 {
+ cpu = <&A53_1>;
+ };
+ core2 {
+ cpu = <&A53_2>;
+ };
+ core3 {
+ cpu = <&A53_3>;
+ };
+ };
+ };
+
+ idle-states {
+ entry-method = "psci";
+
+ CPU_SLEEP_0: cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x0010000>;
+ local-timer-stop;
+ entry-latency-us = <100>;
+ exit-latency-us = <250>;
+ min-residency-us = <150>;
+ };
+
+ CLUSTER_SLEEP_0: cluster-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1010000>;
+ local-timer-stop;
+ entry-latency-us = <800>;
+ exit-latency-us = <700>;
+ min-residency-us = <2500>;
+ };
+ };
+
+ A57_0: cpu@0 {
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x0>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A57_L2>;
+ clocks = <&scpi_dvfs 0>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ capacity-dmips-mhz = <1024>;
+ };
+
+ A57_1: cpu@1 {
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x1>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A57_L2>;
+ clocks = <&scpi_dvfs 0>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ capacity-dmips-mhz = <1024>;
+ };
+
+ A53_0: cpu@100 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ clocks = <&scpi_dvfs 1>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ capacity-dmips-mhz = <578>;
+ };
+
+ A53_1: cpu@101 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ clocks = <&scpi_dvfs 1>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ capacity-dmips-mhz = <578>;
+ };
+
+ A53_2: cpu@102 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x102>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ clocks = <&scpi_dvfs 1>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ capacity-dmips-mhz = <578>;
+ };
+
+ A53_3: cpu@103 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x103>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <&A53_L2>;
+ clocks = <&scpi_dvfs 1>;
+ cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ capacity-dmips-mhz = <578>;
+ };
+
+ A57_L2: l2-cache0 {
+ compatible = "cache";
+ };
+
+ A53_L2: l2-cache1 {
+ compatible = "cache";
+ };
+};
+
+Example 2 (ARM 32-bit, 4-cpu system, two clusters,
+ cpus 0,1@1GHz, cpus 2,3@500MHz):
+capacities-dmips-mhz are scaled w.r.t. 2 (cpu@0 and cpu@1), this means that first
+cpu@0 and cpu@1 are twice fast than cpu@2 and cpu@3 (at the same frequency)
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ capacity-dmips-mhz = <2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ capacity-dmips-mhz = <2>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x100>;
+ capacity-dmips-mhz = <1>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x101>;
+ capacity-dmips-mhz = <1>;
+ };
+};
+
+===========================================
+5 - References
+===========================================
+
+[1] ARM Linux Kernel documentation - CPUs bindings
+ Documentation/devicetree/bindings/arm/cpus.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
index 99e159b..e4aa8c6 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
@@ -26,8 +26,13 @@
items:
- enum:
- qcom,qdu1000-cpufreq-epss
+ - qcom,sc7280-cpufreq-epss
+ - qcom,sc8280xp-cpufreq-epss
- qcom,sm6375-cpufreq-epss
- qcom,sm8250-cpufreq-epss
+ - qcom,sm8350-cpufreq-epss
+ - qcom,sm8450-cpufreq-epss
+ - qcom,sm8550-cpufreq-epss
- const: qcom,cpufreq-epss
reg:
diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
index 9c086ea..6f5e790 100644
--- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
@@ -17,6 +17,9 @@
on the CPU OPP in use. The CPUFreq driver sets the CPR power domain level
according to the required OPPs defined in the CPU OPP tables.
+ For old implementation efuses are parsed to select the correct opp table and
+ voltage and CPR is not supported/used.
+
select:
properties:
compatible:
@@ -33,37 +36,65 @@
required:
- compatible
-properties:
- cpus:
- type: object
-
- patternProperties:
- '^cpu@[0-9a-f]+$':
- type: object
-
- properties:
- power-domains:
- maxItems: 1
-
- power-domain-names:
- items:
- - const: cpr
-
- required:
- - power-domains
- - power-domain-names
-
patternProperties:
'^opp-table(-[a-z0-9]+)?$':
- if:
+ allOf:
+ - if:
+ properties:
+ compatible:
+ const: operating-points-v2-kryo-cpu
+ then:
+ $ref: /schemas/opp/opp-v2-kryo-cpu.yaml#
+
+ - if:
+ properties:
+ compatible:
+ const: operating-points-v2-qcom-level
+ then:
+ $ref: /schemas/opp/opp-v2-qcom-level.yaml#
+
+ unevaluatedProperties: false
+
+allOf:
+ - if:
properties:
compatible:
- const: operating-points-v2-kryo-cpu
+ contains:
+ enum:
+ - qcom,qcs404
+
then:
+ properties:
+ cpus:
+ type: object
+
+ patternProperties:
+ '^cpu@[0-9a-f]+$':
+ type: object
+
+ properties:
+ power-domains:
+ maxItems: 1
+
+ power-domain-names:
+ items:
+ - const: cpr
+
+ required:
+ - power-domains
+ - power-domain-names
+
patternProperties:
- '^opp-?[0-9]+$':
- required:
- - required-opps
+ '^opp-table(-[a-z0-9]+)?$':
+ if:
+ properties:
+ compatible:
+ const: operating-points-v2-kryo-cpu
+ then:
+ patternProperties:
+ '^opp-?[0-9]+$':
+ required:
+ - required-opps
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
index 026a9f9..4287678 100644
--- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
+++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
@@ -14,6 +14,7 @@
enum:
- allwinner,sun8i-h3-crypto
- allwinner,sun8i-r40-crypto
+ - allwinner,sun20i-d1-crypto
- allwinner,sun50i-a64-crypto
- allwinner,sun50i-h5-crypto
- allwinner,sun50i-h6-crypto
@@ -29,6 +30,7 @@
- description: Bus clock
- description: Module clock
- description: MBus clock
+ - description: TRNG clock (RC oscillator)
minItems: 2
clock-names:
@@ -36,6 +38,7 @@
- const: bus
- const: mod
- const: ram
+ - const: trng
minItems: 2
resets:
@@ -44,19 +47,33 @@
if:
properties:
compatible:
- const: allwinner,sun50i-h6-crypto
+ enum:
+ - allwinner,sun20i-d1-crypto
then:
properties:
clocks:
- minItems: 3
+ minItems: 4
clock-names:
- minItems: 3
+ minItems: 4
else:
- properties:
- clocks:
- maxItems: 2
- clock-names:
- maxItems: 2
+ if:
+ properties:
+ compatible:
+ const: allwinner,sun50i-h6-crypto
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ else:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
required:
- compatible
diff --git a/Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml b/Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml
new file mode 100644
index 0000000..b18f178
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/aspeed,ast2600-acry.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED ACRY ECDSA/RSA Hardware Accelerator Engines
+
+maintainers:
+ - Neal Liu <neal_liu@aspeedtech.com>
+
+description:
+ The ACRY ECDSA/RSA engines is designed to accelerate the throughput
+ of ECDSA/RSA signature and verification. Basically, ACRY can be
+ divided into two independent engines - ECC Engine and RSA Engine.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-acry
+
+ reg:
+ items:
+ - description: acry base address & size
+ - description: acry sram base address & size
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ acry: crypto@1e6fa000 {
+ compatible = "aspeed,ast2600-acry";
+ reg = <0x1e6fa000 0x400>, <0x1e710000 0x1800>;
+ interrupts = <160>;
+ clocks = <&syscon ASPEED_CLK_GATE_RSACLK>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
index 4ccb335..b767ec7 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -6,12 +6,18 @@
title: STMicroelectronics STM32 HASH
+description: The STM32 HASH block is built on the HASH block found in
+ the STn8820 SoC introduced in 2007, and subsequently used in the U8500
+ SoC in 2010.
+
maintainers:
- Lionel Debieve <lionel.debieve@foss.st.com>
properties:
compatible:
enum:
+ - st,stn8820-hash
+ - stericsson,ux500-hash
- st,stm32f456-hash
- st,stm32f756-hash
@@ -41,11 +47,26 @@
maximum: 2
default: 0
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
- clocks
- - interrupts
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ items:
+ const: stericsson,ux500-hash
+ then:
+ properties:
+ interrupts: false
+ else:
+ required:
+ - interrupts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
deleted file mode 100644
index 525a4bf..0000000
--- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-Cadence DSI bridge
-==================
-
-The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
-
-Required properties:
-- compatible: should be set to "cdns,dsi".
-- reg: physical base address and length of the controller's registers.
-- interrupts: interrupt line connected to the DSI bridge.
-- clocks: DSI bridge clocks.
-- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
-- phys: phandle link to the MIPI D-PHY controller.
-- phy-names: must contain "dphy".
-- #address-cells: must be set to 1.
-- #size-cells: must be set to 0.
-
-Optional properties:
-- resets: DSI reset lines.
-- reset-names: can contain "dsi_p_rst".
-
-Required subnodes:
-- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
- 2 ports are available:
- * port 0: this port is only needed if some of your DSI devices are
- controlled through an external bus like I2C or SPI. Can have at
- most 4 endpoints. The endpoint number is directly encoding the
- DSI virtual channel used by this device.
- * port 1: represents the DPI input.
- Other ports will be added later to support the new kind of inputs.
-
-- one subnode per DSI device connected on the DSI bus. Each DSI device should
- contain a reg property encoding its virtual channel.
-
-Example:
- dsi0: dsi@fd0c0000 {
- compatible = "cdns,dsi";
- reg = <0x0 0xfd0c0000 0x0 0x1000>;
- clocks = <&pclk>, <&sysclk>;
- clock-names = "dsi_p_clk", "dsi_sys_clk";
- interrupts = <1>;
- phys = <&dphy0>;
- phy-names = "dphy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
- dsi0_dpi_input: endpoint {
- remote-endpoint = <&xxx_dpi_output>;
- };
- };
- };
-
- panel: dsi-dev@0 {
- compatible = "<vendor,panel>";
- reg = <0>;
- };
- };
-
-or
-
- dsi0: dsi@fd0c0000 {
- compatible = "cdns,dsi";
- reg = <0x0 0xfd0c0000 0x0 0x1000>;
- clocks = <&pclk>, <&sysclk>;
- clock-names = "dsi_p_clk", "dsi_sys_clk";
- interrupts = <1>;
- phys = <&dphy1>;
- phy-names = "dphy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- dsi0_output: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&dsi_panel_input>;
- };
- };
-
- port@1 {
- reg = <1>;
- dsi0_dpi_input: endpoint {
- remote-endpoint = <&xxx_dpi_output>;
- };
- };
- };
- };
-
- i2c@xxx {
- panel: panel@59 {
- compatible = "<vendor,panel>";
- reg = <0x59>;
-
- port {
- dsi_panel_input: endpoint {
- remote-endpoint = <&dsi0_output>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
new file mode 100644
index 0000000..2306032
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DSI bridge
+
+maintainers:
+ - Boris Brezillon <boris.brezillon@bootlin.com>
+
+description: |
+ CDNS DSI is a bridge device which converts DPI to DSI
+
+properties:
+ compatible:
+ enum:
+ - cdns,dsi
+ - ti,j721e-dsi
+
+ reg:
+ minItems: 1
+ items:
+ - description:
+ Register block for controller's registers.
+ - description:
+ Register block for wrapper settings registers in case of TI J7 SoCs.
+
+ clocks:
+ items:
+ - description: PSM clock, used by the IP
+ - description: sys clock, used by the IP
+
+ clock-names:
+ items:
+ - const: dsi_p_clk
+ - const: dsi_sys_clk
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: dphy
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: dsi_p_rst
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port representing the DSI output. It can have
+ at most 4 endpoints. The endpoint number is directly encoding
+ the DSI virtual channel used by this device.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input port representing the DPI input.
+
+ required:
+ - port@1
+
+allOf:
+ - $ref: ../dsi-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,j721e-dsi
+ then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+ power-domains:
+ maxItems: 1
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - phys
+ - phy-names
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dsi@fd0c0000 {
+ compatible = "cdns,dsi";
+ reg = <0x0 0xfd0c0000 0x0 0x1000>;
+ clocks = <&pclk>, <&sysclk>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ interrupts = <1>;
+ phys = <&dphy0>;
+ phy-names = "dphy";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "panasonic,vvx10f034n00";
+ reg = <0>;
+ power-supply = <&vcc_lcd_reg>;
+ };
+ };
+ };
+
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dsi@fd0c0000 {
+ compatible = "cdns,dsi";
+ reg = <0x0 0xfd0c0000 0x0 0x1000>;
+ clocks = <&pclk>, <&sysclk>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ interrupts = <1>;
+ phys = <&dphy1>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsi_panel_input>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
index b19be08..6e0e3ba 100644
--- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -16,7 +16,9 @@
properties:
compatible:
- const: fsl,imx8mp-ldb
+ enum:
+ - fsl,imx8mp-ldb
+ - fsl,imx93-ldb
clocks:
maxItems: 1
@@ -57,6 +59,18 @@
- clocks
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx93-ldb
+ then:
+ properties:
+ ports:
+ properties:
+ port@2: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
index b697c42..c9a882e 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -52,9 +52,49 @@
maxItems: 1
description: extcon specifier for the Power Delivery
- port:
- $ref: /schemas/graph.yaml#/properties/port
- description: A port node pointing to DPI host port node
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: A port node pointing to DPI host port node
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ link-frequencies:
+ minItems: 1
+ maxItems: 1
+ description: Allowed max link frequencies in Hz
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Video port for DP output
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ uniqueItems: true
+ items:
+ - enum: [ 0, 1 ]
+ - const: 1
+ - const: 2
+ - const: 3
+
+ required:
+ - port@0
+ - port@1
required:
- compatible
@@ -63,6 +103,7 @@
- interrupts
- reset-gpios
- extcon
+ - ports
additionalProperties: false
@@ -85,9 +126,24 @@
reset-gpios = <&pio 179 1>;
extcon = <&usbc_extcon>;
- port {
- it6505_in: endpoint {
- remote-endpoint = <&dpi_out>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ it6505_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ link-frequencies = /bits/ 64 <150000000>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ it6505_out: endpoint {
+ remote-endpoint = <&dp_in>;
+ data-lanes = <0 1>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
index d3454da..a7eb260 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
@@ -17,7 +17,9 @@
properties:
compatible:
- const: ite,it66121
+ enum:
+ - ite,it66121
+ - ite,it6610
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
index afeeb96..d33026f 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
@@ -11,13 +11,14 @@
description: |
This binding describes the MIPI DSI/CSI-2 encoder embedded in the Renesas
- R-Car V3U SoC. The encoder can operate in either DSI or CSI-2 mode, with up
+ R-Car Gen4 SoCs. The encoder can operate in either DSI or CSI-2 mode, with up
to four data lanes.
properties:
compatible:
enum:
- renesas,r8a779a0-dsi-csi2-tx # for V3U
+ - renesas,r8a779g0-dsi-csi2-tx # for V4H
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
index 131d5b6..e08c246 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
@@ -22,6 +22,7 @@
items:
- enum:
- renesas,r9a07g044-mipi-dsi # RZ/G2{L,LC}
+ - renesas,r9a07g054-mipi-dsi # RZ/V2L
- const: renesas,rzg2l-mipi-dsi
reg:
diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
new file mode 100644
index 0000000..6d1a36b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/sil,sii8620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Image SiI8620 HDMI/MHL bridge
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+properties:
+ compatible:
+ const: sil,sii8620
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xtal
+
+ cvcc10-supply:
+ description: Digital Core Supply Voltage (1.0V)
+
+ interrupts:
+ maxItems: 1
+
+ iovcc18-supply:
+ description: I/O Supply Voltage (1.8V)
+
+ reset-gpios:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ unevaluatedProperties: false
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port for HDMI (encoder) input
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MHL to connector port
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - cvcc10-supply
+ - interrupts
+ - iovcc18-supply
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@39 {
+ reg = <0x39>;
+ compatible = "sil,sii8620";
+ cvcc10-supply = <&ldo36_reg>;
+ iovcc18-supply = <&ldo34_reg>;
+ interrupt-parent = <&gpf0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ reset-gpios = <&gpv7 0 GPIO_ACTIVE_LOW>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "xtal";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mhl_to_musb_con: endpoint {
+ remote-endpoint = <&musb_con_to_mhl>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
deleted file mode 100644
index b05052f..0000000
--- a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Silicon Image SiI8620 HDMI/MHL bridge bindings
-
-Required properties:
- - compatible: "sil,sii8620"
- - reg: i2c address of the bridge
- - cvcc10-supply: Digital Core Supply Voltage (1.0V)
- - iovcc18-supply: I/O Supply Voltage (1.8V)
- - interrupts: interrupt specifier of INT pin
- - reset-gpios: gpio specifier of RESET pin
- - clocks, clock-names: specification and name of "xtal" clock
- - video interfaces: Device node can contain video interface port
- node for HDMI encoder according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
- sii8620@39 {
- reg = <0x39>;
- compatible = "sil,sii8620";
- cvcc10-supply = <&ldo36_reg>;
- iovcc18-supply = <&ldo34_reg>;
- interrupt-parent = <&gpf0>;
- interrupts = <2 0>;
- reset-gpio = <&gpv7 0 0>;
- clocks = <&pmu_system_controller 0>;
- clock-names = "xtal";
-
- port {
- mhl_to_hdmi: endpoint {
- remote-endpoint = <&hdmi_to_mhl>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index d4d5854..9274148 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -31,6 +31,7 @@
- items:
- enum:
- mediatek,mt8186-disp-aal
+ - mediatek,mt8188-disp-aal
- mediatek,mt8192-disp-aal
- mediatek,mt8195-disp-aal
- const: mediatek,mt8183-disp-aal
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 63fb020..b04820c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -27,12 +27,13 @@
- const: mediatek,mt8192-disp-ccorr
- items:
- enum:
+ - mediatek,mt8188-disp-ccorr
- mediatek,mt8195-disp-ccorr
- const: mediatek,mt8192-disp-ccorr
- items:
- enum:
- mediatek,mt8186-disp-ccorr
- - const: mediatek,mt8183-disp-ccorr
+ - const: mediatek,mt8192-disp-ccorr
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index d2f89ee..62306c8 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -37,6 +37,7 @@
- enum:
- mediatek,mt8183-disp-color
- mediatek,mt8186-disp-color
+ - mediatek,mt8188-disp-color
- mediatek,mt8192-disp-color
- mediatek,mt8195-disp-color
- const: mediatek,mt8173-disp-color
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 8ad8187..5c7445c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -27,6 +27,7 @@
- items:
- enum:
- mediatek,mt8186-disp-dither
+ - mediatek,mt8188-disp-dither
- mediatek,mt8192-disp-dither
- mediatek,mt8195-disp-dither
- const: mediatek,mt8183-disp-dither
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index a89ea0e..a5c6a91 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -28,6 +28,7 @@
- items:
- enum:
- mediatek,mt8186-disp-gamma
+ - mediatek,mt8188-disp-gamma
- mediatek,mt8192-disp-gamma
- mediatek,mt8195-disp-gamma
- const: mediatek,mt8183-disp-gamma
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index a2a27d0..065e526 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -36,6 +36,7 @@
- const: mediatek,mt2701-disp-ovl
- items:
- enum:
+ - mediatek,mt8188-disp-ovl
- mediatek,mt8195-disp-ovl
- const: mediatek,mt8183-disp-ovl
- items:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 654080b..27de644 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -26,6 +26,7 @@
- items:
- enum:
- mediatek,mt8186-disp-postmask
+ - mediatek,mt8188-disp-postmask
- const: mediatek,mt8192-disp-postmask
reg:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 0882ae8..3ade2ec 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -33,6 +33,10 @@
- const: mediatek,mt8195-disp-rdma
- items:
- enum:
+ - mediatek,mt8188-disp-rdma
+ - const: mediatek,mt8195-disp-rdma
+ - items:
+ - enum:
- mediatek,mt7623-disp-rdma
- mediatek,mt2712-disp-rdma
- const: mediatek,mt2701-disp-rdma
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..0e8d8df 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -21,6 +21,9 @@
- qcom,sc7280-edp
- qcom,sc8180x-dp
- qcom,sc8180x-edp
+ - qcom,sc8280xp-dp
+ - qcom,sc8280xp-edp
+ - qcom,sdm845-dp
- qcom,sm8350-dp
reg:
@@ -68,8 +71,7 @@
items:
- const: dp
- operating-points-v2:
- maxItems: 1
+ operating-points-v2: true
opp-table: true
@@ -81,6 +83,7 @@
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -102,8 +105,28 @@
description: Input endpoint of the controller
port@1:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ 0, 1, 2, 3 ]
+
+ link-frequencies:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ 1620000000, 2700000000, 5400000000, 8100000000 ]
+
+ required:
+ - port@0
+ - port@1
required:
- compatible
@@ -127,11 +150,10 @@
enum:
- qcom,sc7280-edp
- qcom,sc8180x-edp
+ - qcom,sc8280xp-edp
then:
properties:
"#sound-dai-cells": false
- reg:
- maxItems: 4
else:
properties:
aux-bus: false
@@ -193,6 +215,8 @@
reg = <1>;
endpoint {
remote-endpoint = <&typec>;
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
};
};
};
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
index 8ffbc30..3f953aa 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
@@ -13,7 +13,15 @@
description: |
Common properties for QCom DPU display controller.
+# Do not select this by default, otherwise it is also selected for all
+# display-controller@ nodes
+select:
+ false
+
properties:
+ $nodename:
+ pattern: '^display-controller@[0-9a-f]+$'
+
interrupts:
maxItems: 1
@@ -40,10 +48,6 @@
- port@0
required:
- - compatible
- - reg
- - reg-names
- - clocks
- interrupts
- power-domains
- operating-points-v2
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 6e2fd6e..e75a3ef 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -9,14 +9,33 @@
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
-allOf:
- - $ref: "../dsi-controller.yaml#"
-
properties:
compatible:
- enum:
- - qcom,mdss-dsi-ctrl
- - qcom,dsi-ctrl-6g-qcm2290
+ oneOf:
+ - items:
+ - enum:
+ - qcom,apq8064-dsi-ctrl
+ - qcom,msm8916-dsi-ctrl
+ - qcom,msm8953-dsi-ctrl
+ - qcom,msm8974-dsi-ctrl
+ - qcom,msm8996-dsi-ctrl
+ - qcom,msm8998-dsi-ctrl
+ - qcom,qcm2290-dsi-ctrl
+ - qcom,sc7180-dsi-ctrl
+ - qcom,sc7280-dsi-ctrl
+ - qcom,sdm660-dsi-ctrl
+ - qcom,sdm845-dsi-ctrl
+ - qcom,sm8150-dsi-ctrl
+ - qcom,sm8250-dsi-ctrl
+ - qcom,sm8350-dsi-ctrl
+ - qcom,sm8450-dsi-ctrl
+ - qcom,sm8550-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+ - items:
+ - enum:
+ - dsi-ctrl-6g-qcm2290
+ - const: qcom,mdss-dsi-ctrl
+ deprecated: true
reg:
maxItems: 1
@@ -28,22 +47,23 @@
maxItems: 1
clocks:
- items:
- - description: Display byte clock
- - description: Display byte interface clock
- - description: Display pixel clock
- - description: Display core clock
- - description: Display AHB clock
- - description: Display AXI clock
+ description: |
+ Several clocks are used, depending on the variant. Typical ones are::
+ - bus:: Display AHB clock.
+ - byte:: Display byte clock.
+ - byte_intf:: Display byte interface clock.
+ - core:: Display core clock.
+ - core_mss:: Core MultiMedia SubSystem clock.
+ - iface:: Display AXI clock.
+ - mdp_core:: MDP Core clock.
+ - mnoc:: MNOC clock
+ - pixel:: Display pixel clock.
+ minItems: 3
+ maxItems: 9
clock-names:
- items:
- - const: byte
- - const: byte_intf
- - const: pixel
- - const: core
- - const: iface
- - const: bus
+ minItems: 3
+ maxItems: 9
phys:
maxItems: 1
@@ -52,10 +72,6 @@
deprecated: true
const: dsi
- "#address-cells": true
-
- "#size-cells": true
-
syscon-sfpb:
description: A phandle to mmss_sfpb syscon node (only for DSIv2).
$ref: "/schemas/types.yaml#/definitions/phandle"
@@ -67,12 +83,16 @@
2 DSI links.
assigned-clocks:
- maxItems: 2
+ minItems: 2
+ maxItems: 4
description: |
Parents of "byte" and "pixel" for the given platform.
+ For DSIv2 platforms this should contain "byte", "esc", "src" and
+ "pixel_src" clocks.
assigned-clock-parents:
- maxItems: 2
+ minItems: 2
+ maxItems: 4
description: |
The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block.
@@ -103,7 +123,7 @@
properties:
data-lanes:
maxItems: 4
- minItems: 4
+ minItems: 1
items:
enum: [ 0, 1, 2, 3 ]
@@ -119,7 +139,7 @@
properties:
data-lanes:
maxItems: 4
- minItems: 4
+ minItems: 1
items:
enum: [ 0, 1, 2, 3 ]
@@ -127,6 +147,26 @@
- port@0
- port@1
+ avdd-supply:
+ description:
+ Phandle to vdd regulator device node
+
+ vcca-supply:
+ description:
+ Phandle to vdd regulator device node
+
+ vdd-supply:
+ description:
+ VDD regulator
+
+ vddio-supply:
+ description:
+ VDD-IO regulator
+
+ vdda-supply:
+ description:
+ VDDA regulator
+
required:
- compatible
- reg
@@ -139,7 +179,192 @@
- assigned-clock-parents
- ports
-additionalProperties: false
+allOf:
+ - $ref: ../dsi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,apq8064-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 7
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core_mmss
+ - const: src
+ - const: byte
+ - const: pixel
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8916-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 6
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: iface
+ - const: bus
+ - const: byte
+ - const: pixel
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8953-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 6
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: iface
+ - const: bus
+ - const: byte
+ - const: pixel
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8974-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 7
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: iface
+ - const: bus
+ - const: byte
+ - const: pixel
+ - const: core
+ - const: core_mmss
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 7
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: byte
+ - const: iface
+ - const: bus
+ - const: core_mmss
+ - const: pixel
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 6
+ clock-names:
+ items:
+ - const: byte
+ - const: byte_intf
+ - const: pixel
+ - const: core
+ - const: iface
+ - const: bus
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7180-dsi-ctrl
+ - qcom,sc7280-dsi-ctrl
+ - qcom,sm8150-dsi-ctrl
+ - qcom,sm8250-dsi-ctrl
+ - qcom,sm8350-dsi-ctrl
+ - qcom,sm8450-dsi-ctrl
+ - qcom,sm8550-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 6
+ clock-names:
+ items:
+ - const: byte
+ - const: byte_intf
+ - const: pixel
+ - const: core
+ - const: iface
+ - const: bus
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdm660-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 9
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: byte
+ - const: byte_intf
+ - const: mnoc
+ - const: iface
+ - const: bus
+ - const: core_mmss
+ - const: pixel
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdm845-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 6
+ clock-names:
+ items:
+ - const: byte
+ - const: byte_intf
+ - const: pixel
+ - const: core
+ - const: iface
+ - const: bus
+
+unevaluatedProperties: false
examples:
- |
@@ -149,7 +374,7 @@
#include <dt-bindings/power/qcom-rpmpd.h>
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
index 2f1fd14..cf4a338 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
@@ -16,6 +16,7 @@
compatible:
enum:
- qcom,dsi-phy-28nm-hpm
+ - qcom,dsi-phy-28nm-hpm-fam-b
- qcom,dsi-phy-28nm-lp
- qcom,dsi-phy-28nm-8960
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
index c851770..8e9031b 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
@@ -18,6 +18,10 @@
- qcom,dsi-phy-7nm
- qcom,dsi-phy-7nm-8150
- qcom,sc7280-dsi-phy-7nm
+ - qcom,sm6375-dsi-phy-7nm
+ - qcom,sm8350-dsi-phy-5nm
+ - qcom,sm8450-dsi-phy-5nm
+ - qcom,sm8550-dsi-phy-4nm
reg:
items:
@@ -44,7 +48,6 @@
- compatible
- reg
- reg-names
- - vdds-supply
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
index 76d40f7..0f6f088 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
@@ -4,14 +4,13 @@
$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Description of Qualcomm Display DSI PHY common dt properties
+title: Qualcomm Display DSI PHY Common Properties
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
-description: |
- This defines the DSI PHY dt properties which are common for all
- dsi phy versions.
+description:
+ Common properties for Qualcomm Display DSI PHY.
properties:
"#clock-cells":
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index c5f4984..d4191cc 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -89,7 +89,7 @@
help bring the GPU out of secure mode.
properties:
memory-region:
- $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
firmware-name:
description: |
@@ -149,6 +149,8 @@
description: GPU 3D engine clock
- const: rbbmtimer
description: GPU RBBM Timer for Adreno 5xx series
+ - const: rbcpr
+ description: GPU RB Core Power Reduction clock
minItems: 2
maxItems: 7
diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt b/Documentation/devicetree/bindings/display/msm/mdp5.txt
deleted file mode 100644
index 65d03c5..0000000
--- a/Documentation/devicetree/bindings/display/msm/mdp5.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-Qualcomm adreno/snapdragon MDP5 display controller
-
-Description:
-
-This is the bindings documentation for the MDP5 display
-controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994 and MSM8996.
-
-MDP5:
-Required properties:
-- compatible:
- * "qcom,mdp5" - MDP5
-- reg: Physical base address and length of the controller's registers.
-- reg-names: The names of register regions. The following regions are required:
- * "mdp_phys"
-- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
-- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required.
-- * "bus"
-- * "iface"
-- * "core"
-- * "vsync"
-- ports: contains the list of output ports from MDP. These connect to interfaces
- that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
- special case since it is a part of the MDP block itself).
-
- Each output port contains an endpoint that describes how it is connected to an
- external interface. These are described by the standard properties documented
- here:
- Documentation/devicetree/bindings/graph.txt
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
- The availability of output ports can vary across SoC revisions:
-
- For MSM8974 and APQ8084:
- Port 0 -> MDP_INTF0 (eDP)
- Port 1 -> MDP_INTF1 (DSI1)
- Port 2 -> MDP_INTF2 (DSI2)
- Port 3 -> MDP_INTF3 (HDMI)
-
- For MSM8916:
- Port 0 -> MDP_INTF1 (DSI1)
-
- For MSM8994 and MSM8996:
- Port 0 -> MDP_INTF1 (DSI1)
- Port 1 -> MDP_INTF2 (DSI2)
- Port 2 -> MDP_INTF3 (HDMI)
-
-Optional properties:
-- clock-names: the following clocks are optional:
- * "lut"
- * "tbu"
- * "tbu_rt"
-
-Example:
-
-/ {
- ...
-
- mdss: mdss@1a00000 {
- compatible = "qcom,mdss";
- reg = <0x1a00000 0x1000>,
- <0x1ac8000 0x3000>;
- reg-names = "mdss_phys", "vbif_phys";
-
- power-domains = <&gcc MDSS_GDSC>;
-
- clocks = <&gcc GCC_MDSS_AHB_CLK>,
- <&gcc GCC_MDSS_AXI_CLK>,
- <&gcc GCC_MDSS_VSYNC_CLK>;
- clock-names = "iface",
- "bus",
- "vsync"
-
- interrupts = <0 72 0>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- mdp: mdp@1a01000 {
- compatible = "qcom,mdp5";
- reg = <0x1a01000 0x90000>;
- reg-names = "mdp_phys";
-
- interrupt-parent = <&mdss>;
- interrupts = <0 0>;
-
- clocks = <&gcc GCC_MDSS_AHB_CLK>,
- <&gcc GCC_MDSS_AXI_CLK>,
- <&gcc GCC_MDSS_MDP_CLK>,
- <&gcc GCC_MDSS_VSYNC_CLK>;
- clock-names = "iface",
- "bus",
- "core",
- "vsync";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- mdp5_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
- };
- };
-
- dsi0: dsi@1a98000 {
- ...
- ports {
- ...
- port@0 {
- reg = <0>;
- dsi0_in: endpoint {
- remote-endpoint = <&mdp5_intf1_out>;
- };
- };
- ...
- };
- ...
- };
-
- dsi_phy0: dsi-phy@1a98300 {
- ...
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
index 27d7242..ccd7d64 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -15,7 +15,15 @@
Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
sub-blocks like DPU display controller, DSI and DP interfaces etc.
+# Do not select this by default, otherwise it is also selected for qcom,mdss
+# devices.
+select:
+ false
+
properties:
+ $nodename:
+ pattern: "^display-subsystem@[0-9a-f]+$"
+
reg:
maxItems: 1
@@ -70,7 +78,6 @@
- description: MDSS_CORE reset
required:
- - compatible
- reg
- reg-names
- power-domains
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
new file mode 100644
index 0000000..ef461ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,mdp5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno/Snapdragon Mobile Display controller (MDP5)
+
+description:
+ MDP5 display controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994
+ and MSM8996.
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Rob Clark <robdclark@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,mdp5
+ deprecated: true
+ - items:
+ - enum:
+ - qcom,apq8084-mdp5
+ - qcom,msm8916-mdp5
+ - qcom,msm8917-mdp5
+ - qcom,msm8953-mdp5
+ - qcom,msm8974-mdp5
+ - qcom,msm8976-mdp5
+ - qcom,msm8994-mdp5
+ - qcom,msm8996-mdp5
+ - qcom,sdm630-mdp5
+ - qcom,sdm660-mdp5
+ - const: qcom,mdp5
+
+ $nodename:
+ pattern: '^display-controller@[0-9a-f]+$'
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: mdp_phys
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ maxItems: 7
+
+ clock-names:
+ oneOf:
+ - minItems: 4
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+ - const: lut
+ - const: tbu
+ - const: tbu_rt
+ #MSM8996 has additional iommu clock
+ - items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: iommu
+ - const: vsync
+
+ interconnects:
+ minItems: 1
+ items:
+ - description: Interconnect path from mdp0 (or a single mdp) port to the data bus
+ - description: Interconnect path from mdp1 port to the data bus
+ - description: Interconnect path from rotator port to the data bus
+
+ interconnect-names:
+ minItems: 1
+ items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+ - const: rotator-mem
+
+ iommus:
+ items:
+ - description: apps SMMU with the Stream-ID mask for Hard-Fail port0
+
+ power-domains:
+ maxItems: 1
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: >
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI, DP etc. MDP5 devices support up to 4 ports:
+ one or two DSI ports, HDMI and eDP.
+
+ patternProperties:
+ "^port@[0-3]+$":
+ $ref: /schemas/graph.yaml#/properties/port
+
+ # at least one port is required
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ display-controller@1a01000 {
+ compatible = "qcom,mdp5";
+ reg = <0x1a01000 0x90000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_MDP_CLK>,
+ <&gcc GCC_MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
index ba04602..20889e4 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
@@ -15,6 +15,9 @@
encapsulates sub-blocks like MDP5, DSI, HDMI, eDP, etc.
properties:
+ $nodename:
+ pattern: "^display-subsystem@[0-9a-f]+$"
+
compatible:
enum:
- qcom,mdss
@@ -44,18 +47,30 @@
The MDSS power domain provided by GCC
clocks:
- minItems: 1
- items:
- - description: Display abh clock
- - description: Display axi clock
- - description: Display vsync clock
+ oneOf:
+ - minItems: 3
+ items:
+ - description: Display abh clock
+ - description: Display axi clock
+ - description: Display vsync clock
+ - description: Display core clock
+ - minItems: 1
+ items:
+ - description: Display abh clock
+ - description: Display core clock
clock-names:
- minItems: 1
- items:
- - const: iface
- - const: bus
- - const: vsync
+ oneOf:
+ - minItems: 3
+ items:
+ - const: iface
+ - const: bus
+ - const: vsync
+ - const: core
+ - minItems: 1
+ items:
+ - const: iface
+ - const: core
"#address-cells":
const: 1
@@ -84,17 +99,19 @@
- ranges
patternProperties:
- "^mdp@[1-9a-f][0-9a-f]*$":
+ "^display-controller@[1-9a-f][0-9a-f]*$":
type: object
properties:
compatible:
- const: qcom,mdp5
+ contains:
+ const: qcom,mdp5
"^dsi@[1-9a-f][0-9a-f]*$":
type: object
properties:
compatible:
- const: qcom,mdss-dsi-ctrl
+ contains:
+ const: qcom,mdss-dsi-ctrl
"^phy@[1-9a-f][0-9a-f]*$":
type: object
@@ -107,12 +124,6 @@
- qcom,dsi-phy-20nm
- qcom,dsi-phy-28nm-hpm
- qcom,dsi-phy-28nm-lp
-
- "^hdmi-phy@[1-9a-f][0-9a-f]*$":
- type: object
- properties:
- compatible:
- enum:
- qcom,hdmi-phy-8084
- qcom,hdmi-phy-8660
- qcom,hdmi-phy-8960
@@ -137,7 +148,7 @@
- |
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- mdss@1a00000 {
+ display-subsystem@1a00000 {
compatible = "qcom,mdss";
reg = <0x1a00000 0x1000>,
<0x1ac8000 0x3000>;
@@ -161,8 +172,8 @@
#size-cells = <1>;
ranges;
- mdp@1a01000 {
- compatible = "qcom,mdp5";
+ display-controller@1a01000 {
+ compatible = "qcom,msm8916-mdp5", "qcom,mdp5";
reg = <0x01a01000 0x89000>;
reg-names = "mdp_phys";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
index b02adba..8d3cd46 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,msm8998-dpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display DPU dt properties for MSM8998 target
+title: Qualcomm Display DPU on MSM8998
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
@@ -13,8 +13,7 @@
properties:
compatible:
- items:
- - const: qcom,msm8998-dpu
+ const: qcom,msm8998-dpu
reg:
items:
@@ -46,6 +45,13 @@
- const: core
- const: vsync
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
index cf52ff7..3c2b6ed 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
@@ -18,8 +18,7 @@
properties:
compatible:
- items:
- - const: qcom,msm8998-mdss
+ const: qcom,msm8998-mdss
clocks:
items:
@@ -47,7 +46,9 @@
type: object
properties:
compatible:
- const: qcom,mdss-dsi-ctrl
+ items:
+ - const: qcom,msm8998-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -55,6 +56,9 @@
compatible:
const: qcom,dsi-phy-10nm-8998
+required:
+ - compatible
+
unevaluatedProperties: false
examples:
@@ -126,7 +130,7 @@
};
dsi@c994000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8998-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0c994000 0x400>;
reg-names = "dsi_ctrl";
@@ -196,7 +200,7 @@
};
dsi@c996000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,msm8998-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0c996000 0x400>;
reg-names = "dsi_ctrl";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
index a7b382f..414f4e7 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-dpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display DPU dt properties for QCM2290 target
+title: Qualcomm Display DPU on QCM2290
maintainers:
- Loic Poulain <loic.poulain@linaro.org>
@@ -13,8 +13,7 @@
properties:
compatible:
- items:
- - const: qcom,qcm2290-dpu
+ const: qcom,qcm2290-dpu
reg:
items:
@@ -42,6 +41,13 @@
- const: lut
- const: vsync
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index 4795e13..2995b84 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -18,8 +18,7 @@
properties:
compatible:
- items:
- - const: qcom,qcm2290-mdss
+ const: qcom,qcm2290-mdss
clocks:
items:
@@ -61,6 +60,9 @@
compatible:
const: qcom,dsi-phy-14nm-2290
+required:
+ - compatible
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
index bd590a6..1fb8321 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-dpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display DPU dt properties for SC7180 target
+title: Qualcomm Display DPU on SC7180
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
@@ -13,8 +13,7 @@
properties:
compatible:
- items:
- - const: qcom,sc7180-dpu
+ const: qcom,sc7180-dpu
reg:
items:
@@ -44,6 +43,13 @@
- const: core
- const: vsync
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
index 13e396d..42ef06e 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
@@ -18,8 +18,7 @@
properties:
compatible:
- items:
- - const: qcom,sc7180-mdss
+ const: qcom,sc7180-mdss
clocks:
items:
@@ -59,7 +58,9 @@
type: object
properties:
compatible:
- const: qcom,mdss-dsi-ctrl
+ items:
+ - const: qcom,sc7180-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -67,6 +68,9 @@
compatible:
const: qcom,dsi-phy-10nm
+required:
+ - compatible
+
unevaluatedProperties: false
examples:
@@ -142,7 +146,7 @@
};
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
index 924059b..26dc073 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,sc7280-dpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display DPU dt properties for SC7280
+title: Qualcomm Display DPU on SC7280
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
@@ -43,6 +43,13 @@
- const: core
- const: vsync
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
index a3de174..078e1d1 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
@@ -58,7 +58,9 @@
type: object
properties:
compatible:
- const: qcom,mdss-dsi-ctrl
+ items:
+ - const: qcom,sc7280-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^edp@[0-9a-f]+$":
type: object
@@ -74,6 +76,9 @@
- qcom,sc7280-dsi-phy-7nm
- qcom,sc7280-edp-phy
+required:
+ - compatible
+
unevaluatedProperties: false
examples:
@@ -162,7 +167,7 @@
};
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sc7280-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml
new file mode 100644
index 0000000..f2c8e16
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP Display Processing Unit
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ Device tree bindings for SC8280XP Display Processing Unit.
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc8280xp-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display ahb clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sc8280xp.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc8280xp-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc0 DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc0 DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <460000000>,
+ <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SC8280XP_MMCX>;
+
+ interrupt-parent = <&mdss0>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp0_in>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp1_in>;
+ };
+ };
+
+ port@5 {
+ reg = <5>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp3_in>;
+ };
+ };
+
+ port@6 {
+ reg = <6>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp2_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
new file mode 100644
index 0000000..c239544
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP Mobile Display Subsystem
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc8280xp-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sc8280xp-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-dp
+ - qcom,sc8280xp-edp
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sc8280xp.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sc8280xp-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc0 MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ resets = <&dispcc0 DISP_CC_MDSS_CORE_BCR>;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_MDP1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ iommus = <&apps_smmu 0x1000 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc8280xp-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc0 DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdss0_mdp_opp_table>;
+ power-domains = <&rpmhpd SC8280XP_MMCX>;
+
+ interrupt-parent = <&mdss0>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp0_in>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp1_in>;
+ };
+ };
+
+ port@5 {
+ reg = <5>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp3_in>;
+ };
+ };
+
+ port@6 {
+ reg = <6>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp2_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
index 5719b45..0f7765d 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,sdm845-dpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display DPU dt properties for SDM845 target
+title: Qualcomm Display DPU on SDM845
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
@@ -13,8 +13,7 @@
properties:
compatible:
- items:
- - const: qcom,sdm845-dpu
+ const: qcom,sdm845-dpu
reg:
items:
@@ -42,6 +41,13 @@
- const: core
- const: vsync
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
index 31ca6f9..6ecb009 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
@@ -18,8 +18,7 @@
properties:
compatible:
- items:
- - const: qcom,sdm845-mdss
+ const: qcom,sdm845-mdss
clocks:
items:
@@ -47,11 +46,19 @@
compatible:
const: qcom,sdm845-dpu
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sdm845-dp
+
"^dsi@[0-9a-f]+$":
type: object
properties:
compatible:
- const: qcom,mdss-dsi-ctrl
+ items:
+ - const: qcom,sdm845-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -59,6 +66,9 @@
compatible:
const: qcom,dsi-phy-10nm
+required:
+ - compatible
+
unevaluatedProperties: false
examples:
@@ -128,7 +138,7 @@
};
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm845-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
@@ -198,7 +208,7 @@
};
dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sdm845-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae96000 0x400>;
reg-names = "dsi_ctrl";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
index 4a39a30..bf62c2f 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/msm/qcom,sm6115-dpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display DPU dt properties for SM6115 target
+title: Qualcomm Display DPU on SM6115
maintainers:
- Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
@@ -13,8 +13,7 @@
properties:
compatible:
- items:
- - const: qcom,sm6115-dpu
+ const: qcom,sm6115-dpu
reg:
items:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
index 886858e..2491cb1 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
@@ -18,8 +18,7 @@
properties:
compatible:
- items:
- - const: qcom,sm6115-mdss
+ const: qcom,sm6115-mdss
clocks:
items:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
new file mode 100644
index 0000000..2b3f3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8150-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150 Display DPU
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8150-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display ahb clock
+ - description: Display hf axi clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8150.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
new file mode 100644
index 0000000..5182e95
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
@@ -0,0 +1,332 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8150-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150 Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SM8150 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sm8150-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm8150-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8150-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,dsi-phy-7nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8150.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8150-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP_PORT0 &mc_virt SLAVE_EBI_CH0>,
+ <&mmss_noc MASTER_MDP_PORT1 &mc_virt SLAVE_EBI_CH0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x420>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-171428571 {
+ opp-hz = /bits/ 64 <171428571>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8150-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8150-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml
index 9ff8a26..687c8c1 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml
@@ -39,6 +39,13 @@
- const: core
- const: vsync
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
index 0d3be53..368d3db 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
@@ -18,8 +18,7 @@
properties:
compatible:
- items:
- - const: qcom,sm8250-mdss
+ const: qcom,sm8250-mdss
clocks:
items:
@@ -55,7 +54,9 @@
type: object
properties:
compatible:
- const: qcom,mdss-dsi-ctrl
+ items:
+ - const: qcom,sm8250-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
@@ -63,6 +64,9 @@
compatible:
const: qcom,dsi-phy-7nm
+required:
+ - compatible
+
unevaluatedProperties: false
examples:
@@ -167,7 +171,7 @@
};
dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8250-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae94000 0x400>;
reg-names = "dsi_ctrl";
@@ -257,7 +261,7 @@
};
dsi@ae96000 {
- compatible = "qcom,mdss-dsi-ctrl";
+ compatible = "qcom,sm8250-dsi-ctrl", "qcom,mdss-dsi-ctrl";
reg = <0x0ae96000 0x400>;
reg-names = "dsi_ctrl";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml
new file mode 100644
index 0000000..1205003
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8350-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 Display DPU
+
+maintainers:
+ - Robert Foss <robert.foss@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8350-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display ahb clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8350.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8350.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8350.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8350-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8350_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
new file mode 100644
index 0000000..4d94dbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8350-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 Display MDSS
+
+maintainers:
+ - Robert Foss <robert.foss@linaro.org>
+
+description:
+ MSM Mobile Display Subsystem(MDSS) that encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sm8350-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm8350-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8350-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,dsi-phy-5nm-8350
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8350.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8350.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8350.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8350-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_MDP1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ iommus = <&apps_smmu 0x820 0x402>;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8350-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8350_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi0: dsi@ae94000 {
+ compatible = "qcom,sm8350-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8350_MMCX>;
+
+ phys = <&mdss_dsi0_phy>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml
new file mode 100644
index 0000000..0d17ece
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8450-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8450 Display DPU
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8450-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display hf axi
+ - description: Display sf axi
+ - description: Display ahb
+ - description: Display lut
+ - description: Display core
+ - description: Display vsync
+
+ clock-names:
+ items:
+ - const: bus
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8450-dispcc.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8450.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8450-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8450_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-172000000{
+ opp-hz = /bits/ 64 <172000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
new file mode 100644
index 0000000..4c6929e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
@@ -0,0 +1,345 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8450-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8450 Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ SM8450 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8450-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display sf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm8450-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8450-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,dsi-phy-5nm-8450
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8450-dispcc.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8450.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8450-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP_DISP 0 &mc_virt SLAVE_EBI1_DISP 0>,
+ <&mmss_noc MASTER_MDP_DISP 0 &mc_virt SLAVE_EBI1_DISP 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x2800 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8450-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8450_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-172000000{
+ opp-hz = /bits/ 64 <172000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8450-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8450_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160310000{
+ opp-hz = /bits/ 64 <160310000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-5nm-8450";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8450-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8450_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-5nm-8450";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml b/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
new file mode 100644
index 0000000..86c834e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,a030jtn01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO A030JTN01 3.0" (320x480 pixels) 24-bit TFT LCD panel
+
+description: |
+ Delta RGB 8-bit panel found in some Retrogame handhelds
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+ - Christophe Branchereau <cbranchereau@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: auo,a030jtn01
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "auo,a030jtn01";
+ reg = <0>;
+
+ spi-max-frequency = <10000000>;
+
+ reset-gpios = <&gpe 4 GPIO_ACTIVE_LOW>;
+ power-supply = <&lcd_power>;
+
+ backlight = <&backlight>;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&panel_output>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
new file mode 100644
index 0000000..d54e96b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/focaltech,gpt3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Focaltech GPT3 3.0" (640x480 pixels) IPS LCD panel
+
+maintainers:
+ - Christophe Branchereau <cbranchereau@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: focaltech,gpt3
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "focaltech,gpt3";
+ reg = <0>;
+
+ spi-max-frequency = <3125000>;
+
+ reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+ backlight = <&backlight>;
+ power-supply = <&vcc>;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&panel_output>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
new file mode 100644
index 0000000..1b2a1ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx8394.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX8394 MIPI-DSI LCD panel controller
+
+maintainers:
+ - Ondrej Jirman <megi@xff.cz>
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+description:
+ Device tree bindings for panels based on the Himax HX8394 controller,
+ such as the HannStar HSD060BHW4 720x1440 TFT LCD panel connected with
+ a MIPI-DSI video interface.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - hannstar,hsd060bhw4
+ - const: himax,hx8394
+
+ reg: true
+
+ reset-gpios: true
+
+ backlight: true
+
+ port: true
+
+ vcc-supply:
+ description: Panel power supply
+
+ iovcc-supply:
+ description: I/O voltage supply
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - backlight
+ - port
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "hannstar,hsd060bhw4", "himax,hx8394";
+ reg = <0>;
+ vcc-supply = <®_2v8_p>;
+ iovcc-supply = <®_1v8_p>;
+ reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
index c2df8d2..9b701df 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
@@ -22,8 +22,9 @@
The standard defines the following interface signals for type C:
- Power:
- Vdd: Power supply for display module
+ Called power-supply in this binding.
- Vddi: Logic level supply for interface signals
- Combined into one in this binding called: power-supply
+ Called io-supply in this binding.
- Interface:
- CSx: Chip select
- SCL: Serial clock
@@ -80,6 +81,11 @@
Controller data/command selection (D/CX) in 4-line SPI mode.
If not set, the controller is in 3-line SPI mode.
+ io-supply:
+ description: |
+ Logic level supply for interface signals (Vddi).
+ No need to set if this is the same as power-supply.
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
new file mode 100644
index 0000000..84562a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,vtdr6130.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox VTDR6130 AMOLED DSI Panel
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: visionox,vtdr6130
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vddio-supply: true
+ vci-supply: true
+ vdd-supply: true
+ port: true
+ reset-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - vci-supply
+ - vdd-supply
+ - reset-gpios
+ - port
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "visionox,vtdr6130";
+ reg = <0>;
+
+ vddio-supply = <&vreg_l12b_1p8>;
+ vci-supply = <&vreg_l13b_3p0>;
+ vdd-supply = <&vreg_l11b_1p2>;
+
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
index b3e5880..d4830f5 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -40,6 +40,7 @@
- renesas,du-r8a77990 # for R-Car E3 compatible DU
- renesas,du-r8a77995 # for R-Car D3 compatible DU
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
+ - renesas,du-r8a779g0 # for R-Car V4H compatible DU
reg:
maxItems: 1
@@ -762,6 +763,7 @@
contains:
enum:
- renesas,du-r8a779a0
+ - renesas,du-r8a779g0
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
index dd64f70..3c9f29e 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
@@ -63,6 +63,11 @@
reg:
description: Location and size of the framebuffer memory
+ memory-region:
+ maxItems: 1
+ description: Phandle to a node describing the memory to be used for the
+ framebuffer. If present, overrides the "reg" property (if one exists).
+
clocks:
description: List of clocks used by the framebuffer.
@@ -94,6 +99,7 @@
* `x1r5g5b5` - 16-bit pixels, d[14:10]=r, d[9:5]=g, d[4:0]=b
* `x2r10g10b10` - 32-bit pixels, d[29:20]=r, d[19:10]=g, d[9:0]=b
* `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
+ * `x8b8g8r8` - 32-bit pixels, d[23:16]=b, d[15:8]=g, d[7:0]=r
enum:
- a1r5g5b5
- a2r10g10b10
@@ -105,6 +111,7 @@
- x1r5g5b5
- x2r10g10b10
- x8r8g8b8
+ - x8b8g8r8
display:
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
index ce5c673..117c371 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
@@ -20,10 +20,10 @@
- nvidia,tegra194-display
'#address-cells':
- const: 1
+ enum: [ 1, 2 ]
'#size-cells':
- const: 1
+ enum: [ 1, 2 ]
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
index 6eedee5..69be95a 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
@@ -59,8 +59,7 @@
iommus:
maxItems: 1
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
index 75546f2..511cbe7 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
@@ -47,8 +47,7 @@
items:
- const: dsi
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
index 0d55e62..3c095a5 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
@@ -46,8 +46,7 @@
interconnect-names:
maxItems: 4
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
index bf38acc..1026b0b 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
@@ -49,8 +49,7 @@
interconnect-names:
maxItems: 4
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
index 4755a73..59a52e7 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
@@ -51,8 +51,7 @@
minItems: 4
maxItems: 10
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
minItems: 1
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
index 035b9f1..f65e59c 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
@@ -50,8 +50,7 @@
items:
- const: hdmi
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 913ca10..94c5242 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -90,8 +90,7 @@
items:
- const: dma-mem # read
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
index 5f4f0fb..2cd3e60 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
@@ -47,8 +47,7 @@
interconnect-names:
maxItems: 6
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
index 467b015..6c84d8b 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
@@ -30,8 +30,7 @@
items:
- description: module clock
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
index 782a4b1..a42bf33 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
@@ -55,8 +55,7 @@
minItems: 4
maxItems: 5
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
index 26d0d8a..02d5bd0 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
@@ -11,7 +11,7 @@
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
index bd599bd..ec2d7a78 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
@@ -11,7 +11,7 @@
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
index 344dc7e..5d554bc 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
@@ -11,7 +11,7 @@
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml
index b53ac76..391bf58 100644
--- a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml
+++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml
@@ -14,7 +14,7 @@
intellectual property (IP)
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml
index 9728246..05163d1 100644
--- a/Documentation/devicetree/bindings/dma/apple,admac.yaml
+++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml
@@ -18,7 +18,7 @@
- Martin Povišer <povik+lin@cutebit.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml
index 9193b18..ab25ae63 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml
+++ b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml
@@ -11,7 +11,7 @@
allOf:
- $ref: /schemas/arm/primecell.yaml#
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
diff --git a/Documentation/devicetree/bindings/dma/dma-controller.yaml b/Documentation/devicetree/bindings/dma/dma-controller.yaml
index 538ebad..04d150d4 100644
--- a/Documentation/devicetree/bindings/dma/dma-controller.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-controller.yaml
@@ -10,7 +10,7 @@
- Vinod Koul <vkoul@kernel.org>
allOf:
- - $ref: "dma-common.yaml#"
+ - $ref: dma-common.yaml#
# Everything else is described in the common file
properties:
diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml
index f8d8c3c..346fe0f 100644
--- a/Documentation/devicetree/bindings/dma/dma-router.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-router.yaml
@@ -10,7 +10,7 @@
- Vinod Koul <vkoul@kernel.org>
allOf:
- - $ref: "dma-common.yaml#"
+ - $ref: dma-common.yaml#
description:
DMA routers are transparent IP blocks used to route DMA request
diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
index 050e6cd..5fd8fc6 100644
--- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
+++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
@@ -64,7 +64,7 @@
- dma-channels
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml b/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
new file mode 100644
index 0000000..b95dd8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,imx-sdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Smart Direct Memory Access (SDMA) Controller for i.MX
+
+maintainers:
+ - Joy Zou <joy.zou@nxp.com>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx50-sdma
+ - fsl,imx51-sdma
+ - fsl,imx53-sdma
+ - fsl,imx6q-sdma
+ - fsl,imx7d-sdma
+ - const: fsl,imx35-sdma
+ - items:
+ - enum:
+ - fsl,imx6sx-sdma
+ - fsl,imx6sl-sdma
+ - const: fsl,imx6q-sdma
+ - items:
+ - const: fsl,imx6ul-sdma
+ - const: fsl,imx6q-sdma
+ - const: fsl,imx35-sdma
+ - items:
+ - const: fsl,imx6sll-sdma
+ - const: fsl,imx6ul-sdma
+ - items:
+ - const: fsl,imx8mq-sdma
+ - const: fsl,imx7d-sdma
+ - items:
+ - enum:
+ - fsl,imx8mp-sdma
+ - fsl,imx8mn-sdma
+ - fsl,imx8mm-sdma
+ - const: fsl,imx8mq-sdma
+ - items:
+ - enum:
+ - fsl,imx25-sdma
+ - fsl,imx31-sdma
+ - fsl,imx35-sdma
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,sdma-ram-script-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Should contain the full path of SDMA RAM scripts firmware.
+
+ "#dma-cells":
+ const: 3
+ description: |
+ The first cell: request/event ID
+
+ The second cell: peripheral types ID
+ enum:
+ - MCU domain SSI: 0
+ - Shared SSI: 1
+ - MMC: 2
+ - SDHC: 3
+ - MCU domain UART: 4
+ - Shared UART: 5
+ - FIRI: 6
+ - MCU domain CSPI: 7
+ - Shared CSPI: 8
+ - SIM: 9
+ - ATA: 10
+ - CCM: 11
+ - External peripheral: 12
+ - Memory Stick Host Controller: 13
+ - Shared Memory Stick Host Controller: 14
+ - DSP: 15
+ - Memory: 16
+ - FIFO type Memory: 17
+ - SPDIF: 18
+ - IPU Memory: 19
+ - ASRC: 20
+ - ESAI: 21
+ - SSI Dual FIFO: 22
+ description: needs firmware more than ver 2
+ - Shared ASRC: 23
+ - SAI: 24
+ - HDMI Audio: 25
+
+ The third cell: transfer priority ID
+ enum:
+ - High: 0
+ - Medium: 1
+ - Low: 2
+
+ gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the General Purpose Register (GPR) node
+
+ fsl,sdma-event-remap:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ maxItems: 2
+ items:
+ items:
+ - description: GPR register offset
+ - description: GPR register shift
+ - description: GPR register value
+ description: |
+ Register bits of sdma event remap, the format is <reg shift val>.
+ The order is <RX>, <TX>.
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
+
+ iram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the On-chip RAM (OCRAM) node.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,sdma-ram-script-name
+
+additionalProperties: false
+
+examples:
+ - |
+ sdma: dma-controller@83fb0000 {
+ compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
+ reg = <0x83fb0000 0x4000>;
+ interrupts = <6>;
+ #dma-cells = <3>;
+ fsl,sdma-ram-script-name = "sdma-imx51.bin";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml
new file mode 100644
index 0000000..add9c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Direct Memory Access (DMA) Controller from i.MX23/i.MX28
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx6q-dma-apbh
+ - fsl,imx6sx-dma-apbh
+ - fsl,imx7d-dma-apbh
+ - const: fsl,imx28-dma-apbh
+ - enum:
+ - fsl,imx23-dma-apbh
+ - fsl,imx23-dma-apbx
+ - fsl,imx28-dma-apbh
+ - fsl,imx28-dma-apbx
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ minItems: 4
+ maxItems: 16
+
+ "#dma-cells":
+ const: 1
+
+ dma-channels:
+ enum: [4, 8, 16]
+
+required:
+ - compatible
+ - reg
+ - "#dma-cells"
+ - dma-channels
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-parent = <&irqc>;
+
+ dma-controller@80004000 {
+ compatible = "fsl,imx28-dma-apbh";
+ reg = <0x80004000 0x2000>;
+ interrupts = <82 83 84 85
+ 88 88 88 88
+ 88 88 88 88
+ 87 86 0 0>;
+ #dma-cells = <1>;
+ dma-channels = <16>;
+ };
+
+ dma-controller@80024000 {
+ compatible = "fsl,imx28-dma-apbx";
+ reg = <0x80024000 0x2000>;
+ interrupts = <78 79 66 0
+ 80 81 68 69
+ 70 71 72 73
+ 74 75 76 77>;
+ #dma-cells = <1>;
+ dma-channels = <16>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
deleted file mode 100644
index 12c316f..0000000
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ /dev/null
@@ -1,118 +0,0 @@
-* Freescale Smart Direct Memory Access (SDMA) Controller for i.MX
-
-Required properties:
-- compatible : Should be one of
- "fsl,imx25-sdma"
- "fsl,imx31-sdma", "fsl,imx31-to1-sdma", "fsl,imx31-to2-sdma"
- "fsl,imx35-sdma", "fsl,imx35-to1-sdma", "fsl,imx35-to2-sdma"
- "fsl,imx51-sdma"
- "fsl,imx53-sdma"
- "fsl,imx6q-sdma"
- "fsl,imx7d-sdma"
- "fsl,imx6ul-sdma"
- "fsl,imx8mq-sdma"
- "fsl,imx8mm-sdma"
- "fsl,imx8mn-sdma"
- "fsl,imx8mp-sdma"
- The -to variants should be preferred since they allow to determine the
- correct ROM script addresses needed for the driver to work without additional
- firmware.
-- reg : Should contain SDMA registers location and length
-- interrupts : Should contain SDMA interrupt
-- #dma-cells : Must be <3>.
- The first cell specifies the DMA request/event ID. See details below
- about the second and third cell.
-- fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
- scripts firmware
-
-The second cell of dma phandle specifies the peripheral type of DMA transfer.
-The full ID of peripheral types can be found below.
-
- ID transfer type
- ---------------------
- 0 MCU domain SSI
- 1 Shared SSI
- 2 MMC
- 3 SDHC
- 4 MCU domain UART
- 5 Shared UART
- 6 FIRI
- 7 MCU domain CSPI
- 8 Shared CSPI
- 9 SIM
- 10 ATA
- 11 CCM
- 12 External peripheral
- 13 Memory Stick Host Controller
- 14 Shared Memory Stick Host Controller
- 15 DSP
- 16 Memory
- 17 FIFO type Memory
- 18 SPDIF
- 19 IPU Memory
- 20 ASRC
- 21 ESAI
- 22 SSI Dual FIFO (needs firmware ver >= 2)
- 23 Shared ASRC
- 24 SAI
-
-The third cell specifies the transfer priority as below.
-
- ID transfer priority
- -------------------------
- 0 High
- 1 Medium
- 2 Low
-
-Optional properties:
-
-- gpr : The phandle to the General Purpose Register (GPR) node.
-- fsl,sdma-event-remap : Register bits of sdma event remap, the format is
- <reg shift val>.
- reg is the GPR register offset.
- shift is the bit position inside the GPR register.
- val is the value of the bit (0 or 1).
-
-Examples:
-
-sdma@83fb0000 {
- compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
- reg = <0x83fb0000 0x4000>;
- interrupts = <6>;
- #dma-cells = <3>;
- fsl,sdma-ram-script-name = "sdma-imx51.bin";
-};
-
-DMA clients connected to the i.MX SDMA controller must use the format
-described in the dma.txt file.
-
-Examples:
-
-ssi2: ssi@70014000 {
- compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
- reg = <0x70014000 0x4000>;
- interrupts = <30>;
- clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
- dma-names = "rx", "tx";
- fsl,fifo-depth = <15>;
-};
-
-Using the fsl,sdma-event-remap property:
-
-If we want to use SDMA on the SAI1 port on a MX6SX:
-
-&sdma {
- gpr = <&gpr>;
- /* SDMA events remap for SAI1_RX and SAI1_TX */
- fsl,sdma-event-remap = <0 15 1>, <0 16 1>;
-};
-
-The fsl,sdma-event-remap property in this case has two values:
-- <0 15 1> means that the offset is 0, so GPR0 is the register of the
-SDMA remap. Bit 15 of GPR0 selects between UART4_RX and SAI1_RX.
-Setting bit 15 to 1 selects SAI1_RX.
-- <0 16 1> means that the offset is 0, so GPR0 is the register of the
-SDMA remap. Bit 16 of GPR0 selects between UART4_TX and SAI1_TX.
-Setting bit 16 to 1 selects SAI1_TX.
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
deleted file mode 100644
index e30e184..0000000
--- a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-* Freescale MXS DMA
-
-Required properties:
-- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
-- reg : Should contain registers location and length
-- interrupts : Should contain the interrupt numbers of DMA channels.
- If a channel is empty/reserved, 0 should be filled in place.
-- #dma-cells : Must be <1>. The number cell specifies the channel ID.
-- dma-channels : Number of channels supported by the DMA controller
-
-Optional properties:
-- interrupt-names : Name of DMA channel interrupts
-
-Supported chips:
-imx23, imx28.
-
-Examples:
-
-dma_apbh: dma-apbh@80004000 {
- compatible = "fsl,imx28-dma-apbh";
- reg = <0x80004000 0x2000>;
- interrupts = <82 83 84 85
- 88 88 88 88
- 88 88 88 88
- 87 86 0 0>;
- interrupt-names = "ssp0", "ssp1", "ssp2", "ssp3",
- "gpmi0", "gmpi1", "gpmi2", "gmpi3",
- "gpmi4", "gmpi5", "gpmi6", "gmpi7",
- "hsadc", "lcdif", "empty", "empty";
- #dma-cells = <1>;
- dma-channels = <16>;
-};
-
-dma_apbx: dma-apbx@80024000 {
- compatible = "fsl,imx28-dma-apbx";
- reg = <0x80024000 0x2000>;
- interrupts = <78 79 66 0
- 80 81 68 69
- 70 71 72 73
- 74 75 76 77>;
- interrupt-names = "auart4-rx", "auart4-tx", "spdif-tx", "empty",
- "saif0", "saif1", "i2c0", "i2c1",
- "auart0-rx", "auart0-tx", "auart1-rx", "auart1-tx",
- "auart2-rx", "auart2-tx", "auart3-rx", "auart3-tx";
- #dma-cells = <1>;
- dma-channels = <16>;
-};
-
-DMA clients connected to the MXS DMA controller must use the format
-described in the dma.txt file.
-
-Examples:
-
-auart0: serial@8006a000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
- reg = <0x8006a000 0x2000>;
- interrupts = <112>;
- dmas = <&dma_apbx 8>, <&dma_apbx 9>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
index fd5b0a8..3740049 100644
--- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
+++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
@@ -10,7 +10,7 @@
- Paul Cercueil <paul@crapouillou.net>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
index a5c4be7..d6bb553 100644
--- a/Documentation/devicetree/bindings/dma/intel,ldma.yaml
+++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
@@ -11,7 +11,7 @@
- mallikarjunax.reddy@intel.com
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
index 9ab4d81..dab468a 100644
--- a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
@@ -14,7 +14,7 @@
for the UART peripheral bus.
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index 851bd50..a790e56 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -16,7 +16,7 @@
- Rajesh Gumasta <rgumasta@nvidia.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
index fef8045..4003dbe 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
@@ -14,7 +14,7 @@
- Jon Hunter <jonathanh@nvidia.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
index 93b4847..ec8b3dc 100644
--- a/Documentation/devicetree/bindings/dma/owl-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
@@ -15,7 +15,7 @@
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
index 003098c..f1ddcf6 100644
--- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
@@ -11,7 +11,7 @@
- Bjorn Andersson <andersson@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
index e7ba1c47..fc5de7b 100644
--- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
@@ -14,7 +14,7 @@
peripheral buses such as I2C, UART, and SPI.
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -24,15 +24,18 @@
- qcom,sm6350-gpi-dma
- items:
- enum:
+ - qcom,qdu1000-gpi-dma
- qcom,sc7280-gpi-dma
- qcom,sm6115-gpi-dma
- qcom,sm6375-gpi-dma
- qcom,sm8350-gpi-dma
- qcom,sm8450-gpi-dma
+ - qcom,sm8550-gpi-dma
- const: qcom,sm6350-gpi-dma
- items:
- enum:
- qcom,sdm670-gpi-dma
+ - qcom,sm6125-gpi-dma
- qcom,sm8150-gpi-dma
- qcom,sm8250-gpi-dma
- const: qcom,sdm845-gpi-dma
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
index 89b591a..03aa067 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
@@ -10,7 +10,7 @@
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
index 1e25c5b..f638d39 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
@@ -10,7 +10,7 @@
- Biju Das <biju.das.jz@bp.renesas.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
index d83013b0..ee9833d 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
@@ -10,7 +10,7 @@
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- - $ref: "dma-router.yaml#"
+ - $ref: dma-router.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
index ab287c6..1781359 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
@@ -10,7 +10,7 @@
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
index 3271755..a1af0b90 100644
--- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
+++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
@@ -23,7 +23,7 @@
https://static.dev.sifive.com/FU540-C000-v1.0.pdf
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index c13649b..5da8291 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -11,7 +11,7 @@
- Andy Shevchenko <andriy.shevchenko@linux.intel.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
index ad107a4..5c81194 100644
--- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
@@ -13,7 +13,7 @@
Synopsys DesignWare AXI DMA Controller DT Binding
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -113,21 +113,21 @@
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- /* example with snps,dw-axi-dmac */
- dmac: dma-controller@80000 {
- compatible = "snps,axi-dma-1.01a";
- reg = <0x80000 0x400>;
- clocks = <&core_clk>, <&cfgr_clk>;
- clock-names = "core-clk", "cfgr-clk";
- interrupt-parent = <&intc>;
- interrupts = <27>;
- #dma-cells = <1>;
- dma-channels = <4>;
- snps,dma-masters = <2>;
- snps,data-width = <3>;
- snps,block-size = <4096 4096 4096 4096>;
- snps,priority = <0 1 2 3>;
- snps,axi-max-burst-len = <16>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ /* example with snps,dw-axi-dmac */
+ dma-controller@80000 {
+ compatible = "snps,axi-dma-1.01a";
+ reg = <0x80000 0x400>;
+ clocks = <&core_clk>, <&cfgr_clk>;
+ clock-names = "core-clk", "cfgr-clk";
+ interrupt-parent = <&intc>;
+ interrupts = <27>;
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ snps,dma-masters = <2>;
+ snps,data-width = <3>;
+ snps,block-size = <4096 4096 4096 4096>;
+ snps,priority = <0 1 2 3>;
+ snps,axi-max-burst-len = <16>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml b/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml
index e7bf6dd..23c8a7b 100644
--- a/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml
@@ -14,7 +14,7 @@
- Masahiro Yamada <yamada.masahiro@socionext.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml b/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
index 371f187..da61d1d 100644
--- a/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
+++ b/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
@@ -15,7 +15,7 @@
- Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
index 158c791..329847e 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
@@ -53,7 +53,7 @@
- Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
index 3e0b82d..e722fbc 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
@@ -10,7 +10,7 @@
- Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf:
- - $ref: "dma-router.yaml#"
+ - $ref: dma-router.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml b/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml
index 08a59bd..3874544 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml
+++ b/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml
@@ -53,7 +53,7 @@
- Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
index 8bddfb3..6484534 100644
--- a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
+++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
@@ -10,7 +10,7 @@
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
@@ -147,13 +147,13 @@
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mfd/dbx500-prcmu.h>
- dma-controller@801C0000 {
- compatible = "stericsson,db8500-dma40", "stericsson,dma40";
- reg = <0x801C0000 0x1000>, <0x40010000 0x800>;
- reg-names = "base", "lcpa";
- interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
- #dma-cells = <3>;
- memcpy-channels = <56 57 58 59 60>;
- clocks = <&prcmu_clk PRCMU_DMACLK>;
+ dma-controller@801c0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801c0000 0x1000>, <0x40010000 0x800>;
+ reg-names = "base", "lcpa";
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <3>;
+ memcpy-channels = <56 57 58 59 60>;
+ clocks = <&prcmu_clk PRCMU_DMACLK>;
};
...
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
index a702d2c2..beecfe7 100644
--- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -28,13 +28,19 @@
PDMAs can be configured via BCDMA split channel's peer registers to match with
the configuration of the legacy peripheral.
-allOf:
- - $ref: /schemas/dma/dma-controller.yaml#
- - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
-
properties:
compatible:
- const: ti,am64-dmss-bcdma
+ enum:
+ - ti,am62a-dmss-bcdma-csirx
+ - ti,am64-dmss-bcdma
+
+ reg:
+ minItems: 3
+ maxItems: 5
+
+ reg-names:
+ minItems: 3
+ maxItems: 5
"#dma-cells":
const: 3
@@ -65,19 +71,13 @@
cell 3: ASEL value for the channel
- reg:
- maxItems: 5
-
- reg-names:
- items:
- - const: gcfg
- - const: bchanrt
- - const: rchanrt
- - const: tchanrt
- - const: ringrt
-
msi-parent: true
+ power-domains:
+ description:
+ Power domain if available
+ maxItems: 1
+
ti,asel:
$ref: /schemas/types.yaml#/definitions/uint32
description: ASEL value for non slave channels
@@ -123,10 +123,51 @@
- msi-parent
- ti,sci
- ti,sci-dev-id
- - ti,sci-rm-range-bchan
- - ti,sci-rm-range-tchan
- ti,sci-rm-range-rchan
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am62a-dmss-bcdma-csirx
+ then:
+ properties:
+ ti,sci-rm-range-bchan: false
+ ti,sci-rm-range-tchan: false
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: rchanrt
+ - const: ringrt
+
+ required:
+ - power-domains
+
+ else:
+ properties:
+ reg:
+ minItems: 5
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: bchanrt
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ required:
+ - ti,sci-rm-range-bchan
+ - ti,sci-rm-range-tchan
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
index 7ff428a..97f6ae9 100644
--- a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
+++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
@@ -44,6 +44,7 @@
allOf:
- $ref: "../dma-controller.yaml#"
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
properties:
"#dma-cells":
@@ -78,14 +79,6 @@
msi-parent: true
- ti,sci:
- description: phandle to TI-SCI compatible System controller node
- $ref: /schemas/types.yaml#/definitions/phandle
-
- ti,sci-dev-id:
- description: TI-SCI device id of UDMAP
- $ref: /schemas/types.yaml#/definitions/uint32
-
ti,ringacc:
description: phandle to the ring accelerator node
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml
index 3e63f79..88575da 100644
--- a/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml
@@ -15,7 +15,9 @@
properties:
compatible:
- const: mediatek,mt8186-dsp
+ enum:
+ - mediatek,mt8186-dsp
+ - mediatek,mt8188-dsp
reg:
items:
diff --git a/Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml b/Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml
new file mode 100644
index 0000000..8f50e69
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/amlogic,meson-gxbb-sm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Secure Monitor (SM)
+
+description:
+ In the Amlogic SoCs the Secure Monitor code is used to provide access to the
+ NVMEM, enable JTAG, set USB boot, etc...
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-gxbb-sm
+ - items:
+ - const: amlogic,meson-gx-sm
+ - const: amlogic,meson-gxbb-sm
+
+ power-controller:
+ type: object
+ $ref: /schemas/power/amlogic,meson-sec-pwrc.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ firmware {
+ secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 1767969..2f7c51c 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -100,7 +100,9 @@
Channel specifier required when using OP-TEE transport.
protocol@11:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x11
@@ -112,7 +114,9 @@
- '#power-domain-cells'
protocol@13:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x13
@@ -124,7 +128,9 @@
- '#clock-cells'
protocol@14:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x14
@@ -136,7 +142,9 @@
- '#clock-cells'
protocol@15:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x15
@@ -148,7 +156,9 @@
- '#thermal-sensor-cells'
protocol@16:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x16
@@ -160,20 +170,31 @@
- '#reset-cells'
protocol@17:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x17
regulators:
type: object
+ additionalProperties: false
description:
The list of all regulators provided by this SCMI controller.
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
patternProperties:
- '^regulators@[0-9a-f]+$':
+ '^regulator@[0-9a-f]+$':
type: object
$ref: "../regulator/regulator.yaml#"
+ unevaluatedProperties: false
properties:
reg:
@@ -184,15 +205,17 @@
- reg
protocol@18:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x18
additionalProperties: false
-patternProperties:
- '^protocol@[0-9a-f]+$':
+$defs:
+ protocol-node:
type: object
description:
Each sub-node represents a protocol supported. If the platform
diff --git a/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt b/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt
deleted file mode 100644
index c248cd4..0000000
--- a/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* Amlogic Secure Monitor
-
-In the Amlogic SoCs the Secure Monitor code is used to provide access to the
-NVMEM, enable JTAG, set USB boot, etc...
-
-Required properties for the secure monitor node:
-- compatible: Should be "amlogic,meson-gxbb-sm"
-
-Example:
-
- firmware {
- sm: secure-monitor {
- compatible = "amlogic,meson-gxbb-sm";
- };
- };
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index 2568857..a66e998 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -38,6 +38,8 @@
- qcom,scm-msm8994
- qcom,scm-msm8996
- qcom,scm-msm8998
+ - qcom,scm-qdu1000
+ - qcom,scm-sa8775p
- qcom,scm-sc7180
- qcom,scm-sc7280
- qcom,scm-sc8280xp
@@ -53,6 +55,7 @@
- qcom,scm-sm8250
- qcom,scm-sm8350
- qcom,scm-sm8450
+ - qcom,scm-sm8550
- qcom,scm-qcs404
- const: qcom,scm
@@ -73,6 +76,12 @@
'#reset-cells':
const: 1
+ interrupts:
+ description:
+ The wait-queue interrupt that firmware raises as part of handshake
+ protocol to handle sleeping SCM calls.
+ maxItems: 1
+
qcom,dload-mode:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
@@ -82,6 +91,32 @@
description: TCSR hardware block
allOf:
+ # Clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,scm-apq8064
+ - qcom,scm-apq8084
+ - qcom,scm-mdm9607
+ - qcom,scm-msm8226
+ - qcom,scm-msm8660
+ - qcom,scm-msm8916
+ - qcom,scm-msm8953
+ - qcom,scm-msm8960
+ - qcom,scm-msm8974
+ - qcom,scm-msm8976
+ - qcom,scm-sm6375
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clock-names: false
+ clocks: false
+
- if:
properties:
compatible:
@@ -100,10 +135,6 @@
clocks:
maxItems: 1
- required:
- - clocks
- - clock-names
-
- if:
properties:
compatible:
@@ -111,6 +142,7 @@
enum:
- qcom,scm-apq8084
- qcom,scm-mdm9607
+ - qcom,scm-msm8226
- qcom,scm-msm8916
- qcom,scm-msm8953
- qcom,scm-msm8974
@@ -127,9 +159,31 @@
minItems: 3
maxItems: 3
- required:
- - clocks
- - clock-names
+ # Interconnects
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,scm-sm8450
+ - qcom,scm-sm8550
+ then:
+ properties:
+ interconnects: false
+
+ # Interrupts
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,scm-sm8450
+ - qcom,scm-sm8550
+ then:
+ properties:
+ interrupts: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml
index 4819012..02f0b04 100644
--- a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml
+++ b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml
@@ -44,8 +44,7 @@
items:
- const: fuse
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt b/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt
deleted file mode 100644
index bef353f..0000000
--- a/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Fujitsu MB86S7x GPIO Controller
--------------------------------
-
-Required properties:
-- compatible: Should be "fujitsu,mb86s70-gpio"
-- reg: Base address and length of register space
-- clocks: Specify the clock
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be <2>. The first cell is the pin number and the
- second cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted).
-
-Examples:
- gpio0: gpio@31000000 {
- compatible = "fujitsu,mb86s70-gpio";
- reg = <0 0x31000000 0x10000>;
- gpio-controller;
- #gpio-cells = <2>;
- clocks = <&clk 0 2 1>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml b/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml
new file mode 100644
index 0000000..d18d952
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/fujitsu,mb86s70-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fujitsu MB86S7x GPIO Controller
+
+maintainers:
+ - Jassi Brar <jaswinder.singh@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: socionext,synquacer-gpio
+ - const: fujitsu,mb86s70-gpio
+ - const: fujitsu,mb86s70-gpio
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+ gpio-line-names: true
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@31000000 {
+ compatible = "fujitsu,mb86s70-gpio";
+ reg = <0x31000000 0x10000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ clocks = <&clk 0 2 1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt b/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
deleted file mode 100644
index 54040a2..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Spreadtrum EIC controller bindings
-
-The EIC is the abbreviation of external interrupt controller, which can
-be used only in input mode. The Spreadtrum platform has 2 EIC controllers,
-one is in digital chip, and another one is in PMIC. The digital chip EIC
-controller contains 4 sub-modules: EIC-debounce, EIC-latch, EIC-async and
-EIC-sync. But the PMIC EIC controller contains only one EIC-debounce sub-
-module.
-
-The EIC-debounce sub-module provides up to 8 source input signal
-connections. A debounce mechanism is used to capture the input signals'
-stable status (millisecond resolution) and a single-trigger mechanism
-is introduced into this sub-module to enhance the input event detection
-reliability. In addition, this sub-module's clock can be shut off
-automatically to reduce power dissipation. Moreover the debounce range
-is from 1ms to 4s with a step size of 1ms. The input signal will be
-ignored if it is asserted for less than 1 ms.
-
-The EIC-latch sub-module is used to latch some special power down signals
-and generate interrupts, since the EIC-latch does not depend on the APB
-clock to capture signals.
-
-The EIC-async sub-module uses a 32kHz clock to capture the short signals
-(microsecond resolution) to generate interrupts by level or edge trigger.
-
-The EIC-sync is similar with GPIO's input function, which is a synchronized
-signal input register. It can generate interrupts by level or edge trigger
-when detecting input signals.
-
-Required properties:
-- compatible: Should be one of the following:
- "sprd,sc9860-eic-debounce",
- "sprd,sc9860-eic-latch",
- "sprd,sc9860-eic-async",
- "sprd,sc9860-eic-sync",
- "sprd,sc2731-eic".
-- reg: Define the base and range of the I/O address space containing
- the GPIO controller registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be <2>. The first cell is the gpio number and
- the second cell is used to specify optional parameters.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be <2>. Specifies the number of cells needed
- to encode interrupt source.
-- interrupts: Should be the port interrupt shared by all the gpios.
-
-Example:
- eic_debounce: gpio@40210000 {
- compatible = "sprd,sc9860-eic-debounce";
- reg = <0 0x40210000 0 0x80>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- eic_latch: gpio@40210080 {
- compatible = "sprd,sc9860-eic-latch";
- reg = <0 0x40210080 0 0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- eic_async: gpio@402100a0 {
- compatible = "sprd,sc9860-eic-async";
- reg = <0 0x402100a0 0 0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- eic_sync: gpio@402100c0 {
- compatible = "sprd,sc9860-eic-sync";
- reg = <0 0x402100c0 0 0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- pmic_eic: gpio@300 {
- compatible = "sprd,sc2731-eic";
- reg = <0x300>;
- interrupt-parent = <&sc2731_pmic>;
- interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-sprd.txt b/Documentation/devicetree/bindings/gpio/gpio-sprd.txt
deleted file mode 100644
index eca97d4..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio-sprd.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Spreadtrum GPIO controller bindings
-
-The controller's registers are organized as sets of sixteen 16-bit
-registers with each set controlling a bank of up to 16 pins. A single
-interrupt is shared for all of the banks handled by the controller.
-
-Required properties:
-- compatible: Should be "sprd,sc9860-gpio".
-- reg: Define the base and range of the I/O address space containing
-the GPIO controller registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be <2>. The first cell is the gpio number and
-the second cell is used to specify optional parameters.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be <2>. Specifies the number of cells needed
-to encode interrupt source.
-- interrupts: Should be the port interrupt shared by all the gpios.
-
-Example:
- ap_gpio: gpio@40280000 {
- compatible = "sprd,sc9860-gpio";
- reg = <0 0x40280000 0 0x1000>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml b/Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml
new file mode 100644
index 0000000..99fcf97
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2022 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/sprd,gpio-eic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc EIC controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ The EIC is the abbreviation of external interrupt controller, which can
+ be used only in input mode. The Spreadtrum platform has 2 EIC controllers,
+ one is in digital chip, and another one is in PMIC. The digital chip EIC
+ controller contains 4 sub-modules, i.e. EIC-debounce, EIC-latch, EIC-async and
+ EIC-sync. But the PMIC EIC controller contains only one EIC-debounce sub-
+ module.
+
+ The EIC-debounce sub-module provides up to 8 source input signal
+ connections. A debounce mechanism is used to capture the input signals'
+ stable status (millisecond resolution) and a single-trigger mechanism
+ is introduced into this sub-module to enhance the input event detection
+ reliability. In addition, this sub-module's clock can be shut off
+ automatically to reduce power dissipation. Moreover the debounce range
+ is from 1ms to 4s with a step size of 1ms. The input signal will be
+ ignored if it is asserted for less than 1 ms.
+
+ The EIC-latch sub-module is used to latch some special power down signals
+ and generate interrupts, since the EIC-latch does not depend on the APB
+ clock to capture signals.
+
+ The EIC-async sub-module uses a 32kHz clock to capture the short signals
+ (microsecond resolution) to generate interrupts by level or edge trigger.
+
+ The EIC-sync is similar with GPIO's input function, which is a synchronized
+ signal input register. It can generate interrupts by level or edge trigger
+ when detecting input signals.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - sprd,sc9860-eic-debounce
+ - sprd,sc9860-eic-latch
+ - sprd,sc9860-eic-async
+ - sprd,sc9860-eic-sync
+ - sprd,sc2731-eic
+ - items:
+ - enum:
+ - sprd,ums512-eic-debounce
+ - const: sprd,sc9860-eic-debounce
+ - items:
+ - enum:
+ - sprd,ums512-eic-latch
+ - const: sprd,sc9860-eic-latch
+ - items:
+ - enum:
+ - sprd,ums512-eic-async
+ - const: sprd,sc9860-eic-async
+ - items:
+ - enum:
+ - sprd,ums512-eic-sync
+ - const: sprd,sc9860-eic-sync
+ - items:
+ - enum:
+ - sprd,sc2730-eic
+ - const: sprd,sc2731-eic
+
+ reg:
+ minItems: 1
+ maxItems: 3
+ description:
+ EIC controller can support maximum 3 banks which has its own
+ address base.
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+ description:
+ The interrupt shared by all GPIO lines for this controller.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ eic_debounce: gpio@40210000 {
+ compatible = "sprd,sc9860-eic-debounce";
+ reg = <0 0x40210000 0 0x80>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/sprd,gpio.yaml b/Documentation/devicetree/bindings/gpio/sprd,gpio.yaml
new file mode 100644
index 0000000..4831688
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/sprd,gpio.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2022 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/sprd,gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc GPIO controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ The controller's registers are organized as sets of sixteen 16-bit
+ registers with each set controlling a bank of up to 16 pins. A single
+ interrupt is shared for all of the banks handled by the controller.
+
+properties:
+ compatible:
+ oneOf:
+ - const: sprd,sc9860-gpio
+ - items:
+ - enum:
+ - sprd,ums512-gpio
+ - const: sprd,sc9860-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+ description: The interrupt shared by all GPIO lines for this controller.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ap_gpio: gpio@40280000 {
+ compatible = "sprd,sc9860-gpio";
+ reg = <0 0x40280000 0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
index 10e5a53..38478da 100644
--- a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
@@ -26,11 +26,15 @@
resets:
maxItems: 1
+ '#hwlock-cells':
+ const: 1
+
required:
- compatible
- reg
- clocks
- resets
+ - "#hwlock-cells"
additionalProperties: false
@@ -44,5 +48,6 @@
reg = <0x01c18000 0x1000>;
clocks = <&ccu CLK_BUS_SPINLOCK>;
resets = <&ccu RST_BUS_SPINLOCK>;
+ #hwlock-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
index d794deb..ca2b473 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
@@ -52,16 +52,16 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
pwmon@5a {
- compatible = "adi,adm1177";
- reg = <0x5a>;
- shunt-resistor-micro-ohms = <50000>; /* 50 mOhm */
- adi,shutdown-threshold-microamp = <1059000>; /* 1.059 A */
- adi,vrange-high-enable;
+ compatible = "adi,adm1177";
+ reg = <0x5a>;
+ shunt-resistor-micro-ohms = <50000>; /* 50 mOhm */
+ adi,shutdown-threshold-microamp = <1059000>; /* 1.059 A */
+ adi,vrange-high-enable;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
index 43b4f4f..4f8e11b 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
@@ -39,13 +39,13 @@
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
adm1266@40 {
- compatible = "adi,adm1266";
- reg = <0x40>;
+ compatible = "adi,adm1266";
+ reg = <0x40>;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
index f2f99af..0cf3ed6 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
@@ -49,15 +49,15 @@
examples:
- |
fpga_axi: fpga-axi {
- #address-cells = <0x2>;
- #size-cells = <0x1>;
+ #address-cells = <0x2>;
+ #size-cells = <0x1>;
- axi_fan_control: axi-fan-control@80000000 {
- compatible = "adi,axi-fan-control-1.00.a";
- reg = <0x0 0x80000000 0x10000>;
- clocks = <&clk 71>;
- interrupts = <0 110 0>;
- pulses-per-revolution = <2>;
- };
+ axi_fan_control: axi-fan-control@80000000 {
+ compatible = "adi,axi-fan-control-1.00.a";
+ reg = <0x0 0x80000000 0x10000>;
+ clocks = <&clk 71>;
+ interrupts = <0 110 0>;
+ pulses-per-revolution = <2>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml
new file mode 100644
index 0000000..5cb66e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc2945.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2945 wide range i2c power monitor
+
+maintainers:
+ - Guenter Roeck <linux@roeck-us.net>
+
+description: |
+ Analog Devices LTC2945 wide range i2c power monitor over I2C.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2945.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc2945
+
+ reg:
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description:
+ Shunt resistor value in micro-Ohms
+ default: 1000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-monitor@6e {
+ compatible = "adi,ltc2945";
+ reg = <0x6e>;
+ /* 10 milli-Ohm shunt resistor */
+ shunt-resistor-micro-ohms = <10000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
index bf04151..1529353 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
@@ -87,15 +87,15 @@
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- ltc2947_spi: ltc2947@0 {
- compatible = "adi,ltc2947";
- reg = <0>;
- /* accumulation takes place always for energ1/charge1. */
- /* accumulation only on positive current for energy2/charge2. */
- adi,accumulator-ctl-pol = <0 1>;
- };
+ ltc2947_spi: ltc2947@0 {
+ compatible = "adi,ltc2947";
+ reg = <0>;
+ /* accumulation takes place always for energ1/charge1. */
+ /* accumulation only on positive current for energy2/charge2. */
+ adi,accumulator-ctl-pol = <0 1>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
index 64a8fcb..dba74f4 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
@@ -55,26 +55,26 @@
examples:
- |
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
- ltc2992@6F {
- #address-cells = <1>;
- #size-cells = <0>;
+ ltc2992@6f {
+ #address-cells = <1>;
+ #size-cells = <0>;
- compatible = "adi,ltc2992";
- reg = <0x6F>;
+ compatible = "adi,ltc2992";
+ reg = <0x6f>;
- channel@0 {
- reg = <0x0>;
- shunt-resistor-micro-ohms = <10000>;
- };
+ channel@0 {
+ reg = <0x0>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
- channel@1 {
- reg = <0x1>;
- shunt-resistor-micro-ohms = <10000>;
- };
+ channel@1 {
+ reg = <0x1>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
index 7598b08..353d81d 100644
--- a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
@@ -41,13 +41,13 @@
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
sbrmi@3c {
- compatible = "amd,sbrmi";
- reg = <0x3c>;
+ compatible = "amd,sbrmi";
+ reg = <0x3c>;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
index 446b09f..7508824 100644
--- a/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
@@ -42,13 +42,13 @@
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
sbtsi@4c {
- compatible = "amd,sbtsi";
- reg = <0x4c>;
+ compatible = "amd,sbtsi";
+ reg = <0x4c>;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml b/Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml
new file mode 100644
index 0000000..4a52aac
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/hpe,gxp-fan-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE GXP Fan Controller
+
+maintainers:
+ - Nick Hawkins <nick.hawkins@hpe.com>
+
+description: |
+ The HPE GXP fan controller controls the fans through an external CPLD
+ device that connects to the fans.
+
+properties:
+ compatible:
+ const: hpe,gxp-fan-ctrl
+
+ reg:
+ items:
+ - description: Fan controller PWM
+ - description: Programmable logic
+ - description: Function 2
+
+ reg-names:
+ items:
+ - const: base
+ - const: pl
+ - const: fn2
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ fan-controller@1000c00 {
+ compatible = "hpe,gxp-fan-ctrl";
+ reg = <0x1000c00 0x200>, <0xd1000000 0xff>, <0x80200000 0x100000>;
+ reg-names = "base", "pl", "fn2";
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
index e1ccbd3..c54b598 100644
--- a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
+++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
@@ -31,7 +31,7 @@
examples:
- |
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = <&adc 1>, <&adc 2>;
- };
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc 1>, <&adc 2>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
index e171983..7b9d48d 100644
--- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
+++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
@@ -198,30 +198,30 @@
};
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sensor@4c {
- compatible = "adi,adt7481";
- reg = <0x4c>;
#address-cells = <1>;
#size-cells = <0>;
- channel@0 {
- reg = <0x0>;
- label = "local";
- };
+ sensor@4c {
+ compatible = "adi,adt7481";
+ reg = <0x4c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- channel@1 {
- reg = <0x1>;
- label = "front";
- temperature-offset-millicelsius = <4000>;
- };
+ channel@0 {
+ reg = <0x0>;
+ label = "local";
+ };
- channel@2 {
- reg = <0x2>;
- label = "back";
- temperature-offset-millicelsius = <750>;
+ channel@1 {
+ reg = <0x1>;
+ label = "front";
+ temperature-offset-millicelsius = <4000>;
+ };
+
+ channel@2 {
+ reg = <0x2>;
+ label = "back";
+ temperature-offset-millicelsius = <750>;
+ };
};
- };
};
diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
index 6a19207..3d0146e 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
@@ -131,7 +131,7 @@
examples:
- |
- thermistor0 {
+ thermistor {
compatible = "murata,ncp18wb473";
io-channels = <&gpadc 0x06>;
pullup-uv = <1800000>;
diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml
index 2f0620e..cd8dcd7 100644
--- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml
+++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml
@@ -123,23 +123,23 @@
#size-cells = <0>;
channel@0 { /* LTD */
- reg = <0>;
+ reg = <0>;
};
channel@1 { /* RTD1 */
- reg = <1>;
- sensor-type = "voltage";
+ reg = <1>;
+ sensor-type = "voltage";
};
channel@2 { /* RTD2 */
- reg = <2>;
- sensor-type = "temperature";
- temperature-mode = "thermal-diode";
+ reg = <2>;
+ sensor-type = "temperature";
+ temperature-mode = "thermal-diode";
};
channel@3 { /* RTD3 */
- reg = <3>;
- sensor-type = "temperature";
+ reg = <3>;
+ sensor-type = "temperature";
};
};
};
diff --git a/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
new file mode 100644
index 0000000..306f673
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/nxp,mc34vr500.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP MC34VR500 hwmon sensor
+
+maintainers:
+ - Mario Kicherer <dev@kicherer.org>
+
+properties:
+ compatible:
+ enum:
+ - nxp,mc34vr500
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "nxp,mc34vr500";
+ reg = <0x08>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
index 1502b22..fde5225 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
@@ -77,15 +77,15 @@
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- tmp513@5c {
- compatible = "ti,tmp513";
- reg = <0x5C>;
- shunt-resistor-micro-ohms = <330000>;
- ti,bus-range-microvolt = <32000000>;
- ti,pga-gain = <8>;
- ti,nfactor = <0x1 0xF3 0x00>;
- };
+ tmp513@5c {
+ compatible = "ti,tmp513";
+ reg = <0x5c>;
+ shunt-resistor-micro-ohms = <330000>;
+ ti,bus-range-microvolt = <32000000>;
+ ti,pga-gain = <8>;
+ ti,nfactor = <0x1 0xf3 0x00>;
+ };
};
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
index 3bc8e73..bce68a3 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
@@ -40,12 +40,12 @@
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- tps23861@30 {
- compatible = "ti,tps23861";
- reg = <0x30>;
- shunt-resistor-micro-ohms = <255000>;
- };
+ tps23861@30 {
+ compatible = "ti,tps23861";
+ reg = <0x30>;
+ shunt-resistor-micro-ohms = <255000>;
+ };
};
diff --git a/Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml b/Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml
new file mode 100644
index 0000000..6604dcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/hpe,gxp-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE GXP SoC I2C Controller
+
+maintainers:
+ - Nick Hawkins <nick.hawkins@hpe.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: hpe,gxp-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ default: 100000
+
+ hpe,sysreg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the global status and enable interrupt registers shared
+ between each I2C engine controller instance. It enables the I2C
+ engine controller to act as both a master or slave by being able to
+ arm and respond to interrupts from its engine. Each bit in the
+ registers represent the respective bit position.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@2600 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0x2500 0x70>;
+ interrupts = <9>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hpe,sysreg = <&sysreg_system_controller>;
+ clock-frequency = <10000>;
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
index e0d76d5..afd4925 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
@@ -33,6 +33,10 @@
open drain.
maxItems: 1
+ i2c-gpio,sda-output-only:
+ description: sda as output only
+ type: boolean
+
i2c-gpio,scl-output-only:
description: scl as output only
type: boolean
@@ -63,6 +67,28 @@
GPIO line used for SCL into open drain mode, and that something is not
the GPIO chip. It is essentially an inconsistency flag.
+ i2c-gpio,sda-has-no-pullup:
+ type: boolean
+ description: sda is used in a non-compliant way and has no pull-up.
+ Therefore disable open-drain. This property is mutually-exclusive
+ with i2c-gpio,sda-open-drain.
+
+ i2c-gpio,scl-has-no-pullup:
+ type: boolean
+ description: scl is used in a non-compliant way and has no pull-up.
+ Therefore disable open-drain. This property is mutually-exclusive
+ with i2c-gpio,scl-open-drain.
+
+dependencies:
+ i2c-gpio,sda-has-no-pullup:
+ not:
+ required:
+ - i2c-gpio,sda-open-drain
+ i2c-gpio,scl-has-no-pullup:
+ not:
+ required:
+ - i2c-gpio,scl-open-drain
+
required:
- compatible
- sda-gpios
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml
index 421563b..72ae2e0 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml
@@ -43,6 +43,10 @@
- const: mediatek,mt6577-i2c
- items:
- enum:
+ - mediatek,mt8365-i2c
+ - const: mediatek,mt8168-i2c
+ - items:
+ - enum:
- mediatek,mt8195-i2c
- const: mediatek,mt8192-i2c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt b/Documentation/devicetree/bindings/i2c/i2c-st.txt
deleted file mode 100644
index 4c26fda..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-st.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-ST SSC binding, for I2C mode operation
-
-Required properties :
-- compatible : Must be "st,comms-ssc-i2c" or "st,comms-ssc4-i2c"
-- reg : Offset and length of the register set for the device
-- interrupts : the interrupt specifier
-- clock-names: Must contain "ssc".
-- clocks: Must contain an entry for each name in clock-names. See the common
- clock bindings.
-- A pinctrl state named "default" must be defined to set pins in mode of
- operation for I2C transfer.
-
-Optional properties :
-- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
- the default 100 kHz frequency will be used. As only Normal and Fast modes
- are supported, possible values are 100000 and 400000.
-- st,i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
- allowed through the deglitch circuit. In units of us.
-- st,i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
- allowed through the deglitch circuit. In units of us.
-- A pinctrl state named "idle" could be defined to set pins in idle state
- when I2C instance is not performing a transfer.
-- A pinctrl state named "sleep" could be defined to set pins in sleep state
- when driver enters in suspend.
-
-
-
-Example :
-
-i2c0: i2c@fed40000 {
- compatible = "st,comms-ssc4-i2c";
- reg = <0xfed40000 0x110>;
- interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_s_a0_ls CLK_ICN_REG>;
- clock-names = "ssc";
- clock-frequency = <400000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c0_default>;
- st,i2c-min-scl-pulse-width-us = <0>;
- st,i2c-min-sda-pulse-width-us = <5>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-synquacer.txt b/Documentation/devicetree/bindings/i2c/i2c-synquacer.txt
deleted file mode 100644
index 72f4a2f..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-synquacer.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Socionext SynQuacer I2C
-
-Required properties:
-- compatible : Must be "socionext,synquacer-i2c"
-- reg : Offset and length of the register set for the device
-- interrupts : A single interrupt specifier
-- #address-cells : Must be <1>;
-- #size-cells : Must be <0>;
-- clock-names : Must contain "pclk".
-- clocks : Must contain an entry for each name in clock-names.
- (See the common clock bindings.)
-
-Optional properties:
-- clock-frequency : Desired I2C bus clock frequency in Hz. As only Normal and
- Fast modes are supported, possible values are 100000 and
- 400000.
-
-Example :
-
- i2c@51210000 {
- compatible = "socionext,synquacer-i2c";
- reg = <0x51210000 0x1000>;
- interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- clock-names = "pclk";
- clocks = <&clk_i2c>;
- clock-frequency = <400000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml b/Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml
new file mode 100644
index 0000000..67882ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/loongson,ls2x-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS2X I2C Controller
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k-i2c
+ - loongson,ls7a-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c0: i2c@1fe21000 {
+ compatible = "loongson,ls2k-i2c";
+ reg = <0x1fe21000 0x8>;
+ interrupt-parent = <&extioiic>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@57 {
+ compatible = "atmel,24c16";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
index cf9f8fd..ec79b72 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
@@ -12,14 +12,24 @@
properties:
compatible:
- enum:
- - qcom,msm8226-cci
- - qcom,msm8916-cci
- - qcom,msm8974-cci
- - qcom,msm8996-cci
- - qcom,sdm845-cci
- - qcom,sm8250-cci
- - qcom,sm8450-cci
+ oneOf:
+ - enum:
+ - qcom,msm8226-cci
+ - qcom,msm8974-cci
+ - qcom,msm8996-cci
+
+ - items:
+ - enum:
+ - qcom,msm8916-cci
+ - const: qcom,msm8226-cci # CCI v1
+
+ - items:
+ - enum:
+ - qcom,sdm845-cci
+ - qcom,sm6350-cci
+ - qcom,sm8250-cci
+ - qcom,sm8450-cci
+ - const: qcom,msm8996-cci # CCI v2
"#address-cells":
const: 1
@@ -88,10 +98,12 @@
- if:
properties:
compatible:
- contains:
- enum:
- - qcom,msm8226-cci
- - qcom,msm8974-cci
+ oneOf:
+ - contains:
+ enum:
+ - qcom,msm8974-cci
+
+ - const: qcom,msm8226-cci
then:
properties:
clocks:
@@ -105,10 +117,12 @@
- if:
properties:
compatible:
- contains:
- enum:
- - qcom,msm8916-cci
- - qcom,msm8996-cci
+ oneOf:
+ - contains:
+ enum:
+ - qcom,msm8916-cci
+
+ - const: qcom,msm8996-cci
then:
properties:
clocks:
@@ -126,6 +140,7 @@
contains:
enum:
- qcom,sdm845-cci
+ - qcom,sm6350-cci
then:
properties:
clocks:
@@ -169,7 +184,7 @@
cci@ac4a000 {
reg = <0x0ac4a000 0x4000>;
- compatible = "qcom,sdm845-cci";
+ compatible = "qcom,sdm845-cci", "qcom,msm8996-cci";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
index f5f7dc8..0e88c85 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
@@ -46,6 +46,8 @@
interrupts:
maxItems: 1
+ operating-points-v2: true
+
pinctrl-0: true
pinctrl-1: true
diff --git a/Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml b/Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml
new file mode 100644
index 0000000..f9d6e20
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/socionext,synquacer-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext SynQuacer I2C Controller
+
+maintainers:
+ - Ard Biesheuvel <ardb@kernel.org>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: socionext,synquacer-i2c
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pclk
+
+ clock-frequency:
+ minimum: 100000
+ maximum: 400000
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c@51210000 {
+ compatible = "socionext,synquacer-i2c";
+ reg = <0x51210000 0x1000>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "pclk";
+ clocks = <&clk_i2c>;
+ clock-frequency = <400000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml b/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml
index c761319..4bbe9e7 100644
--- a/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml
@@ -29,6 +29,9 @@
minimum: 100000
maximum: 400000
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml b/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml
index ddde086..5abf496 100644
--- a/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml
@@ -29,6 +29,9 @@
minimum: 100000
maximum: 400000
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml
new file mode 100644
index 0000000..08f9c1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/st,sti-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C controller embedded in STMicroelectronics STi platform
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,comms-ssc-i2c
+ - st,comms-ssc4-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ clock-frequency:
+ enum: [ 100000, 400000 ]
+ default: 100000
+
+ st,i2c-min-scl-pulse-width-us:
+ description:
+ The minimum valid SCL pulse width that is allowed through the
+ deglitch circuit. In units of us.
+
+ st,i2c-min-sda-pulse-width-us:
+ description:
+ The minimum valid SDA pulse width that is allowed through the
+ deglitch circuit. In units of us.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ i2c@fed40000 {
+ compatible = "st,comms-ssc4-i2c";
+ reg = <0xfed40000 0x110>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_s_a0_ls CLK_ICN_REG>;
+ clock-names = "ssc";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c0_default>;
+ st,i2c-min-scl-pulse-width-us = <0>;
+ st,i2c-min-sda-pulse-width-us = <5>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
index 8d241a7..1b59863 100644
--- a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+++ b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
@@ -14,7 +14,9 @@
properties:
compatible:
- const: xlnx,xps-iic-2.00.a
+ enum:
+ - xlnx,axi-iic-2.1
+ - xlnx,xps-iic-2.00.a
reg:
maxItems: 1
@@ -30,6 +32,13 @@
description: |
Input clock name.
+ clock-frequency:
+ description:
+ Optional I2C SCL clock frequency. If not specified, do not configure
+ in software, rely only on hardware design value.
+ default: 100000
+ enum: [ 100000, 400000, 1000000 ]
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml
index 7332442..b6ba7ad 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml
@@ -41,7 +41,7 @@
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
index f6f9716..5887021 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
@@ -39,7 +39,7 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml
index 185b68f..0c5b64c 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml
@@ -59,7 +59,7 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
index 346abfb..07cacc3 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
@@ -49,7 +49,7 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -64,7 +64,7 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml
index 6b03c4e..c07261c 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml
@@ -58,34 +58,34 @@
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
- /* Example for a I2C device node */
- accelerometer@1d {
- compatible = "adi,adxl355";
- reg = <0x1d>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "DRDY";
- };
+ /* Example for a I2C device node */
+ accelerometer@1d {
+ compatible = "adi,adxl355";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "DRDY";
};
+ };
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- accelerometer@0 {
- compatible = "adi,adxl355";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "DRDY";
- };
+ accelerometer@0 {
+ compatible = "adi,adxl355";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "DRDY";
};
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
index 73a5c8f..62465e3 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
@@ -37,32 +37,32 @@
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
- /* Example for a I2C device node */
- accelerometer@53 {
- compatible = "adi,adxl372";
- reg = <0x53>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- };
+ /* Example for a I2C device node */
+ accelerometer@53 {
+ compatible = "adi,adxl372";
+ reg = <0x53>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
};
+ };
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- accelerometer@0 {
- compatible = "adi,adxl372";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- };
+ accelerometer@0 {
+ compatible = "adi,adxl372";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
};
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml
index 5dd06f5..ec643de 100644
--- a/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml
@@ -36,7 +36,7 @@
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
index 714e48e..6ddb03f 100644
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
@@ -44,7 +44,7 @@
accel@f {
compatible = "kionix,kxtf9";
- reg = <0x0F>;
+ reg = <0xf>;
mount-matrix = "0", "1", "0",
"1", "0", "0",
"0", "0", "1";
diff --git a/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml b/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
index 23528dc..d530ec0 100644
--- a/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/accel/memsensing,msa311.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/accel/memsensing,msa311.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MEMSensing digital 3-Axis accelerometer
diff --git a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml
index 65ce8ea..783c7ddf 100644
--- a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml
@@ -50,7 +50,7 @@
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -65,7 +65,7 @@
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
index b97559f..ce7ba63 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
@@ -44,11 +44,11 @@
#size-cells = <0>;
adc@2f {
- compatible = "adi,ad7091r5";
- reg = <0x2f>;
+ compatible = "adi,ad7091r5";
+ reg = <0x2f>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
index 75a7184..35ed043 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
@@ -61,7 +61,7 @@
patternProperties:
"^channel@([0-9]|1[0-5])$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
index cc347da..d521d51 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
@@ -99,26 +99,26 @@
examples:
- |
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- adc@0 {
- compatible = "adi,ad7192";
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpol;
- spi-cpha;
- clocks = <&ad7192_mclk>;
- clock-names = "mclk";
- interrupts = <25 0x2>;
- interrupt-parent = <&gpio>;
- dvdd-supply = <&dvdd>;
- avdd-supply = <&avdd>;
+ adc@0 {
+ compatible = "adi,ad7192";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+ spi-cpha;
+ clocks = <&ad7192_mclk>;
+ clock-names = "mclk";
+ interrupts = <25 0x2>;
+ interrupt-parent = <&gpio>;
+ dvdd-supply = <&dvdd>;
+ avdd-supply = <&avdd>;
- adi,refin2-pins-enable;
- adi,rejection-60-Hz-enable;
- adi,buffer-enable;
- adi,burnout-currents-enable;
+ adi,refin2-pins-enable;
+ adi,rejection-60-Hz-enable;
+ adi,buffer-enable;
+ adi,burnout-currents-enable;
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
index 1bfbeed..7cc4ddc 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
@@ -43,7 +43,7 @@
patternProperties:
"^channel@[0-7]$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
index ac5a47c..7fa46df 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
@@ -112,30 +112,30 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
- compatible = "adi,ad7606-8";
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpol;
- spi-cpha;
+ compatible = "adi,ad7606-8";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+ spi-cpha;
- avcc-supply = <&adc_vref>;
+ avcc-supply = <&adc_vref>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
- adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
- adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
- adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
- <&gpio 23 GPIO_ACTIVE_HIGH>,
- <&gpio 26 GPIO_ACTIVE_HIGH>;
- standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
- adi,sw-mode;
+ adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
+ adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
+ <&gpio 23 GPIO_ACTIVE_HIGH>,
+ <&gpio 26 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+ adi,sw-mode;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
index a67ba67..5fcc8dd 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
@@ -72,7 +72,7 @@
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml
index 29641ce7..433ed2c 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml
@@ -57,17 +57,17 @@
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- adc1: adc@28 {
- reg = <0x28>;
- compatible = "adi,ad7991";
- interrupts = <13 2>;
- interrupt-parent = <&gpio6>;
+ adc1: adc@28 {
+ reg = <0x28>;
+ compatible = "adi,ad7991";
+ interrupts = <13 2>;
+ interrupt-parent = <&gpio6>;
- vcc-supply = <&vcc_3v3>;
- vref-supply = <&adc_vref>;
+ vcc-supply = <&vcc_3v3>;
+ vref-supply = <&adc_vref>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
index 2d72ff6..7aa748d 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
@@ -64,10 +64,10 @@
#size-cells = <0>;
adc@0 {
- compatible = "adi,ad9467";
- reg = <0>;
- clocks = <&adc_clk>;
- clock-names = "adc-clk";
+ compatible = "adi,ad9467";
+ reg = <0>;
+ clocks = <&adc_clk>;
+ clock-names = "adc-clk";
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
index 8e25773..9996dd9 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
@@ -51,11 +51,11 @@
examples:
- |
axi-adc@44a00000 {
- compatible = "adi,axi-adc-10.0.a";
- reg = <0x44a00000 0x10000>;
- dmas = <&rx_dma 0>;
- dma-names = "rx";
+ compatible = "adi,axi-adc-10.0.a";
+ reg = <0x44a00000 0x10000>;
+ dmas = <&rx_dma 0>;
+ dma-names = "rx";
- adi,adc-dev = <&spi_adc>;
+ adi,adc-dev = <&spi_adc>;
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
index 31f840d..4817b84 100644
--- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
@@ -41,7 +41,7 @@
description: Startup time expressed in ms, it depends on SoC.
atmel,trigger-edge-type:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
One of possible edge types for the ADTRG hardware trigger pin.
When the specific edge type is detected, the conversion will
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
index 77605f1..9c57eb1 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: AVIA HX711 ADC chip for weight cells
diff --git a/Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml b/Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml
new file mode 100644
index 0000000..6d4fb3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/cirrus,ep9301-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP930x internal ADC
+
+description: |
+ Cirrus Logic EP9301/EP9302 SoCs' internal ADC block.
+
+ User's manual:
+ https://cdn.embeddedts.com/resource-attachments/ts-7000_ep9301-ug.pdf
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+properties:
+ compatible:
+ const: cirrus,ep9301-adc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ adc: adc@80900000 {
+ compatible = "cirrus,ep9301-adc";
+ reg = <0x80900000 0x28>;
+ clocks = <&syscon 24>;
+ interrupt-parent = <&vic1>;
+ interrupts = <30>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
index 517e8b1..9cd0fd5 100644
--- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
@@ -2,8 +2,8 @@
# Copyright 2019-2020 Artur Rojek
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/ingenic,adc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/ingenic,adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ingenic JZ47xx ADC controller IIO
@@ -78,14 +78,14 @@
#include <dt-bindings/iio/adc/ingenic,adc.h>
adc@10070000 {
- compatible = "ingenic,jz4740-adc";
- #io-channel-cells = <1>;
+ compatible = "ingenic,jz4740-adc";
+ #io-channel-cells = <1>;
- reg = <0x10070000 0x30>;
+ reg = <0x10070000 0x30>;
- clocks = <&cgu JZ4740_CLK_ADC>;
- clock-names = "adc";
+ clocks = <&cgu JZ4740_CLK_ADC>;
+ clock-names = "adc";
- interrupt-parent = <&intc>;
- interrupts = <18>;
+ interrupt-parent = <&intc>;
+ interrupts = <18>;
};
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
index d0a7ed2..e4b3621 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
@@ -54,8 +54,8 @@
- |
#include <dt-bindings/interrupt-controller/irq.h>
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
maxadc: adc@0 {
compatible = "maxim,max1027";
reg = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml
index 50bcd72..60d7b34 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml
@@ -10,7 +10,7 @@
- Jonathan Cameron <jic23@kernel.org>
description: |
- Family of simple ADCs with i2c inteface and internal references.
+ Family of simple ADCs with i2c interface and internal references.
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
index 58b12fe..ef8d51e 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
@@ -54,8 +54,8 @@
- |
#include <dt-bindings/gpio/gpio.h>
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
adc@0 {
compatible = "maxim,max1241";
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml
index e04f09f..96f3f53 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml
@@ -10,7 +10,7 @@
- Jonathan Cameron <jic23@kernel.org>
description: |
- Family of ADCs with i2c inteface, internal references and threshold
+ Family of ADCs with i2c interface, internal references and threshold
monitoring.
properties:
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
index 2c93fb4..f7b3fde 100644
--- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Marcus Folkesson <marcus.folkesson@gmail.com>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/microchip,mcp3911.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/microchip,mcp3911.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip MCP3911 Dual channel analog front end (ADC)
diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
new file mode 100644
index 0000000..dacc526
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/nxp,imx93-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP iMX93 ADC
+
+maintainers:
+ - Haibo Chen <haibo.chen@nxp.com>
+
+description:
+ The ADC on iMX93 is a 8-channel 12-bit 1MS/s ADC with 4 channels
+ connected to pins. it support normal and inject mode, include
+ One-Shot and Scan (continuous) conversions. Programmable DMA
+ enables for each channel Also this ADC contain alternate analog
+ watchdog thresholds, select threshold through input ports. And
+ also has Self-test logic and Software-initiated calibration.
+
+properties:
+ compatible:
+ const: nxp,imx93-adc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: WDGnL, watchdog threshold interrupt requests.
+ - description: WDGnH, watchdog threshold interrupt requests.
+ - description: normal conversion, include EOC (End of Conversion),
+ ECH (End of Chain), JEOC (End of Injected Conversion) and
+ JECH (End of injected Chain).
+ - description: Self-testing Interrupts.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ipg
+
+ vref-supply:
+ description:
+ The reference voltage which used to establish channel scaling.
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - vref-supply
+ - "#io-channel-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/imx93-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ adc@44530000 {
+ compatible = "nxp,imx93-adc";
+ reg = <0x44530000 0x10000>;
+ interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_ADC1_GATE>;
+ clock-names = "ipg";
+ vref-supply = <®_vref_1v8>;
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
index d186b713..58ea1ca 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
@@ -160,7 +160,7 @@
};
ref_muxoff: adc-channel@f {
reg = <0x00 0x0f>;
- };
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
index fa855ba..73def67 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
@@ -20,6 +20,7 @@
compatible:
items:
- enum:
+ - qcom,pm8226-iadc
- qcom,pm8941-iadc
- const: qcom,spmi-iadc
@@ -49,7 +50,7 @@
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spmi_bus {
+ spmi {
#address-cells = <1>;
#size-cells = <0>;
pmic_iadc: adc@3600 {
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
index c8cbfd3..b3a6263 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
@@ -40,12 +40,12 @@
examples:
- |
pmic {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- pmic_rradc: adc@4500 {
- compatible = "qcom,pmi8998-rradc";
- reg = <0x4500>;
- #io-channel-cells = <1>;
- };
+ pmic_rradc: adc@4500 {
+ compatible = "qcom,pmi8998-rradc";
+ reg = <0x4500>;
+ #io-channel-cells = <1>;
+ };
};
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
index 8b743742..ba86c7b 100644
--- a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
@@ -69,7 +69,7 @@
patternProperties:
"^channel@[0-7]$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
index 81c8729..582d0a0 100644
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
@@ -52,7 +52,7 @@
vdd-supply: true
samsung,syscon-phandle:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the PMU system controller node (to access the ADC_PHY
register on Exynos3250/4x12/5250/5420/5800).
@@ -142,7 +142,7 @@
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 4>;
- };
+ };
};
- |
@@ -150,7 +150,7 @@
adc@126c0000 {
compatible = "samsung,exynos3250-adc";
- reg = <0x126C0000 0x100>;
+ reg = <0x126c0000 0x100>;
interrupts = <0 137 0>;
#io-channel-cells = <1>;
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
index 1c340c9..995cbf8 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/st,stm32-adc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/st,stm32-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 ADC
@@ -80,7 +80,7 @@
description:
Phandle to system configuration controller. It can be used to control the
analog circuitry on stm32mp1.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
interrupt-controller: true
@@ -341,7 +341,7 @@
patternProperties:
"^channel@([0-9]|1[0-9])$":
type: object
- $ref: "adc.yaml"
+ $ref: adc.yaml
description: Represents the external channels which are connected to the ADC.
properties:
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml
index 333744a..474e35c 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml
@@ -35,10 +35,8 @@
examples:
- |
- stmpe {
- stmpe_adc {
- compatible = "st,stmpe-adc";
- st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
- };
+ adc {
+ compatible = "st,stmpe-adc";
+ st,norequest-mask = <0x0f>; /* dont use ADC CH3-0 */
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml
new file mode 100644
index 0000000..caaad77
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,adc081c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Single-channel I2C ADCs
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+description: |
+ Single-channel ADC supporting 8, 10, or 12-bit samples and high/low alerts.
+
+properties:
+ compatible:
+ enum:
+ - ti,adc081c
+ - ti,adc101c
+ - ti,adc121c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Regulator for the combined power supply and voltage reference
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@52 {
+ compatible = "ti,adc081c";
+ reg = <0x52>;
+ vref-supply = <®_2p5v>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
index 2c3c2cf..2127d63 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
@@ -104,12 +104,12 @@
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
- reg = <0>;
+ reg = <0>;
};
channel@4 {
- reg = <4>;
- ti,gain = <3>;
- ti,datarate = <5>;
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <5>;
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml
index 55c2c73..890f125 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml
@@ -77,7 +77,7 @@
patternProperties:
"^channel@([0-7])$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml
new file mode 100644
index 0000000..0d8d06a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads7924.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI ADS7924 4 channels 12 bits I2C analog to digital converter
+
+maintainers:
+ - Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+description: |
+ Texas Instruments ADS7924 4 channels 12 bits I2C analog to digital converter
+
+ Specifications:
+ https://www.ti.com/lit/gpn/ads7924
+
+properties:
+ compatible:
+ const: ti,ads7924
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ The regulator supply for the ADC reference voltage (AVDD)
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ "#io-channel-cells":
+ const: 1
+
+patternProperties:
+ "^channel@[0-3]+$":
+ $ref: adc.yaml
+
+ description: |
+ Represents the external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description: |
+ The channel number. It can have up to 4 channels numbered from 0 to 3.
+ items:
+ - minimum: 0
+ maximum: 3
+
+ label: true
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@48 {
+ compatible = "ti,ads7924";
+ reg = <0x48>;
+ vref-supply = <&ads7924_reg>;
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ label = "CH0";
+ };
+ channel@1 {
+ reg = <1>;
+ label = "CH1";
+ };
+ channel@2 {
+ reg = <2>;
+ label = "CH2";
+ };
+ channel@3 {
+ reg = <3>;
+ label = "CH3";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml b/Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml
new file mode 100644
index 0000000..5fb65bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,lmp92064.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LMP92064 Precision Current and Voltage Sensor.
+
+maintainers:
+ - Leonard Göhrs <l.goehrs@pengutronix.de>
+
+description: |
+ The LMP92064 is a two channel ADC intended for combined voltage and current
+ measurements.
+
+ The device contains two ADCs to allow simultaneous sampling of voltage and
+ current and thus of instantaneous power consumption.
+
+properties:
+ compatible:
+ enum:
+ - ti,lmp92064
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the main part of the chip
+
+ vdig-supply:
+ description: |
+ Regulator that provides power to the digital I/O part of the chip
+
+ shunt-resistor-micro-ohms:
+ description: |
+ Value of the shunt resistor (in µΩ) connected between INCP and INCN,
+ across which current is measured. Used to provide correct scaling of the
+ raw ADC measurement.
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - shunt-resistor-micro-ohms
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "ti,lmp92064";
+ reg = <0>;
+ vdd-supply = <&vdd>;
+ vdig-supply = <&vdd>;
+ spi-max-frequency = <20000000>;
+ shunt-resistor-micro-ohms = <15000>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
index bdf3bba..866a05c 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
@@ -41,7 +41,7 @@
patternProperties:
"^channel@[0-7]$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
properties:
@@ -83,36 +83,36 @@
#size-cells = <0>;
channel@0 {
- reg = <0>;
+ reg = <0>;
};
channel@1 {
- reg = <1>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <1>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@2 {
- reg = <2>;
+ reg = <2>;
};
channel@3 {
- reg = <3>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <3>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@4 {
- reg = <4>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <4>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@5 {
- reg = <5>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <5>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@6 {
- reg = <6>;
+ reg = <6>;
};
channel@7 {
- reg = <7>;
+ reg = <7>;
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
index fee0f02..96340a0 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
@@ -192,26 +192,26 @@
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
- ad3552r@0 {
- compatible = "adi,ad3552r";
- reg = <0>;
- spi-max-frequency = <20000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- channel@0 {
- reg = <0>;
- adi,output-range-microvolt = <0 10000000>;
- };
- channel@1 {
- reg = <1>;
- custom-output-range-config {
- adi,gain-offset = <5>;
- adi,gain-scaling-p-inv-log2 = <1>;
- adi,gain-scaling-n-inv-log2 = <2>;
- adi,rfb-ohms = <1>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ad3552r@0 {
+ compatible = "adi,ad3552r";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ adi,output-range-microvolt = <0 10000000>;
+ };
+ channel@1 {
+ reg = <1>;
+ custom-output-range-config {
+ adi,gain-offset = <5>;
+ adi,gain-scaling-p-inv-log2 = <1>;
+ adi,gain-scaling-n-inv-log2 = <2>;
+ adi,rfb-ohms = <1>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
index ff50c72..9eb9928 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
@@ -12,6 +12,7 @@
description: |
DAC devices supporting both SPI and I2C interfaces.
+
properties:
compatible:
enum:
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
index 13f2142..b4400c5 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
@@ -33,6 +33,7 @@
- description: I2C devices
enum:
- adi,ad5311r
+ - adi,ad5337r
- adi,ad5338r
- adi,ad5671r
- adi,ad5675r
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml
index 3c8784a..212c936 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml
@@ -51,15 +51,15 @@
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- ad5766@0 {
- compatible = "adi,ad5766";
- output-range-microvolts = <(-5000000) 5000000>;
- reg = <0>;
- spi-cpol;
- spi-max-frequency = <1000000>;
- reset-gpios = <&gpio 22 0>;
- };
- };
+ ad5766@0 {
+ compatible = "adi,ad5766";
+ output-range-microvolts = <(-5000000) 5000000>;
+ reg = <0>;
+ spi-cpol;
+ spi-max-frequency = <1000000>;
+ reset-gpios = <&gpio 22 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml
index 8e7da0d..82b0eed 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml
@@ -147,49 +147,49 @@
examples:
- |
- spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- ad5770r@0 {
- compatible = "adi,ad5770r";
- reg = <0>;
- spi-max-frequency = <1000000>;
- vref-supply = <&vref>;
- adi,external-resistor;
- reset-gpios = <&gpio 22 0>;
- #address-cells = <1>;
- #size-cells = <0>;
+ ad5770r@0 {
+ compatible = "adi,ad5770r";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ vref-supply = <&vref>;
+ adi,external-resistor;
+ reset-gpios = <&gpio 22 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- channel@0 {
- reg = <0>;
- adi,range-microamp = <0 300000>;
- };
+ channel@0 {
+ reg = <0>;
+ adi,range-microamp = <0 300000>;
+ };
- channel@1 {
- reg = <1>;
- adi,range-microamp = <0 140000>;
- };
+ channel@1 {
+ reg = <1>;
+ adi,range-microamp = <0 140000>;
+ };
- channel@2 {
- reg = <2>;
- adi,range-microamp = <0 55000>;
- };
+ channel@2 {
+ reg = <2>;
+ adi,range-microamp = <0 55000>;
+ };
- channel@3 {
- reg = <3>;
- adi,range-microamp = <0 45000>;
- };
+ channel@3 {
+ reg = <3>;
+ adi,range-microamp = <0 45000>;
+ };
- channel@4 {
- reg = <4>;
- adi,range-microamp = <0 45000>;
- };
+ channel@4 {
+ reg = <4>;
+ adi,range-microamp = <0 45000>;
+ };
- channel@5 {
- reg = <5>;
- adi,range-microamp = <0 45000>;
- };
- };
+ channel@5 {
+ reg = <5>;
+ adi,range-microamp = <0 45000>;
+ };
};
+ };
...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml
index 15cc6bf..f22ef71 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml
@@ -116,32 +116,32 @@
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
- ltc2688: ltc2688@0 {
- compatible = "adi,ltc2688";
- reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ltc2688: ltc2688@0 {
+ compatible = "adi,ltc2688";
+ reg = <0>;
- vcc-supply = <&vcc>;
- iovcc-supply = <&vcc>;
- vref-supply = <&vref>;
+ vcc-supply = <&vcc>;
+ iovcc-supply = <&vcc>;
+ vref-supply = <&vref>;
- #address-cells = <1>;
- #size-cells = <0>;
- channel@0 {
- reg = <0>;
- adi,toggle-mode;
- adi,overrange;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ adi,toggle-mode;
+ adi,overrange;
+ };
- channel@1 {
- reg = <1>;
- adi,output-range-microvolt = <0 10000000>;
+ channel@1 {
+ reg = <1>;
+ adi,output-range-microvolt = <0 10000000>;
- clocks = <&clock_tgp3>;
- adi,toggle-dither-input = <2>;
- };
- };
+ clocks = <&clock_tgp3>;
+ adi,toggle-dither-input = <2>;
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml b/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
index 133b0f8..c9f51d0 100644
--- a/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Marcus Folkesson <marcus.folkesson@gmail.com>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/dac/lltc,ltc1660.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/dac/lltc,ltc1660.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Linear Technology Micropower octal 8-Bit and 10-Bit DACs
diff --git a/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml b/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml
index b1eb773..733edc7 100644
--- a/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/dac/lltc,ltc2632.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/dac/lltc,ltc2632.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Linear Technology LTC263x 12-/10-/8-Bit Rail-to-Rail DAC
@@ -64,14 +64,14 @@
};
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- dac@0 {
- compatible = "lltc,ltc2632-l12";
- reg = <0>; /* CS0 */
- spi-max-frequency = <1000000>;
- vref-supply = <&vref>;
- };
+ dac@0 {
+ compatible = "lltc,ltc2632-l12";
+ reg = <0>; /* CS0 */
+ spi-max-frequency = <1000000>;
+ vref-supply = <&vref>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml
new file mode 100644
index 0000000..24830f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/maxim,max5522.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX5522 Dual 10-bit Voltage-Output SPI DACs
+
+maintainers:
+ - Angelo Dureghello <angelo.dureghello@timesys.com>
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Datasheet available at:
+ https://www.analog.com/en/products/max5522.html
+
+properties:
+ compatible:
+ const: maxim,max5522
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vrefin-supply: true
+
+required:
+ - compatible
+ - reg
+ - vrefin-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "maxim,max5522";
+ reg = <0>;
+ vrefin-supply = <&vref>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
index 0f1bf11..04045b9 100644
--- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/dac/st,stm32-dac.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/dac/st,stm32-dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DAC
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
index 88298bc..79da032 100644
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
@@ -46,7 +46,7 @@
dac@4c {
compatible = "ti,dac5571";
- reg = <0x4C>;
+ reg = <0x4c>;
vref-supply = <&vdd_supply>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml b/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
index 0144f74..1cb2ada 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
@@ -53,16 +53,16 @@
examples:
- |
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
frequency@0 {
- compatible = "adi,adf4371";
- reg = <0>;
- spi-max-frequency = <1000000>;
- clocks = <&adf4371_clkin>;
- clock-names = "clkin";
+ compatible = "adi,adf4371";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ clocks = <&adf4371_clkin>;
+ clock-names = "clkin";
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml b/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml
index 0ae2464..3d94dd4 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml
@@ -50,13 +50,13 @@
#address-cells = <1>;
#size-cells = <0>;
gyro@0 {
- compatible = "adi,adxrs290";
- reg = <0>;
- spi-max-frequency = <5000000>;
- spi-cpol;
- spi-cpha;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ compatible = "adi,adxrs290";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-cpol;
+ spi-cpha;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
index 2c900e9..297d519 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
@@ -65,34 +65,34 @@
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
gyroscope@20 {
- compatible = "nxp,fxas21002c";
- reg = <0x20>;
+ compatible = "nxp,fxas21002c";
+ reg = <0x20>;
- vdd-supply = <®_peri_3p15v>;
- vddio-supply = <®_peri_3p15v>;
+ vdd-supply = <®_peri_3p15v>;
+ vddio-supply = <®_peri_3p15v>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT1";
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
};
};
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
gyroscope@0 {
- compatible = "nxp,fxas21002c";
- reg = <0x0>;
+ compatible = "nxp,fxas21002c";
+ reg = <0x0>;
- spi-max-frequency = <2000000>;
+ spi-max-frequency = <2000000>;
- interrupt-parent = <&gpio2>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT2";
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml b/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
index 6c5ad42..b9b5bea 100644
--- a/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
+++ b/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
@@ -42,7 +42,7 @@
#address-cells = <1>;
#size-cells = <0>;
- heart_mon@0 {
+ heart-mon@0 {
compatible = "ti,afe4403";
reg = <0>;
spi-max-frequency = <10000000>;
diff --git a/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml b/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
index c0e815d..2958c4c 100644
--- a/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
+++ b/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
@@ -39,7 +39,7 @@
#address-cells = <1>;
#size-cells = <0>;
- heart_mon@58 {
+ heart-mon@58 {
compatible = "ti,afe4404";
reg = <0x58>;
tx-supply = <&vbat>;
diff --git a/Documentation/devicetree/bindings/iio/humidity/dht11.yaml b/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
index 2247481..0103f42 100644
--- a/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
+++ b/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
@@ -34,7 +34,7 @@
examples:
- |
- humidity_sensor {
+ humidity-sensor {
compatible = "dht11";
gpios = <&gpio0 6 0>;
};
diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
index 88384b6..a2bc1fa 100644
--- a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
+++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
@@ -35,12 +35,12 @@
examples:
- |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
- humidity@40 {
- compatible = "ti,hdc2010";
- reg = <0x40>;
- };
+ humidity@40 {
+ compatible = "ti,hdc2010";
+ reg = <0x40>;
+ };
};
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
index d166dbc..4e43c80 100644
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
@@ -42,7 +42,7 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
index 5dbfae8..c73533c 100644
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
@@ -114,17 +114,17 @@
- |
#include <dt-bindings/interrupt-controller/irq.h>
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- adis16475: adis16475-3@0 {
- compatible = "adi,adis16475-3";
- reg = <0>;
- spi-cpha;
- spi-cpol;
- spi-max-frequency = <2000000>;
- interrupts = <4 IRQ_TYPE_EDGE_RISING>;
- interrupt-parent = <&gpio>;
- };
+ adis16475: adis16475-3@0 {
+ compatible = "adi,adis16475-3";
+ reg = <0>;
+ spi-cpha;
+ spi-cpol;
+ spi-max-frequency = <2000000>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ interrupt-parent = <&gpio>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
index a076038..47cfba9 100644
--- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
@@ -64,16 +64,16 @@
#size-cells = <0>;
bmi160@68 {
- compatible = "bosch,bmi160";
- reg = <0x68>;
- vdd-supply = <&pm8916_l17>;
- vddio-supply = <&pm8916_l6>;
- interrupt-parent = <&gpio4>;
- interrupts = <12 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT1";
- mount-matrix = "0", "1", "0",
- "-1", "0", "0",
- "0", "0", "1";
+ compatible = "bosch,bmi160";
+ reg = <0x68>;
+ vdd-supply = <&pm8916_l17>;
+ vddio-supply = <&pm8916_l6>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ mount-matrix = "0", "1", "0",
+ "-1", "0", "0",
+ "0", "0", "1";
};
};
- |
@@ -84,11 +84,11 @@
#size-cells = <0>;
bmi160@0 {
- compatible = "bosch,bmi160";
- reg = <0>;
- spi-max-frequency = <10000000>;
- interrupt-parent = <&gpio2>;
- interrupts = <12 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT2";
+ compatible = "bosch,bmi160";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
index 13c9abdd..7cd05bc 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
@@ -65,35 +65,35 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
icm42605@68 {
- compatible = "invensense,icm42605";
- reg = <0x68>;
- interrupt-parent = <&gpio2>;
- interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
- vdd-supply = <&vdd>;
- vddio-supply = <&vddio>;
+ compatible = "invensense,icm42605";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
icm42602@0 {
- compatible = "invensense,icm42602";
- reg = <0>;
- spi-max-frequency = <24000000>;
- spi-cpha;
- spi-cpol;
- interrupt-parent = <&gpio1>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
- vdd-supply = <&vdd>;
- vddio-supply = <&vddio>;
+ compatible = "invensense,icm42602";
+ reg = <0>;
+ spi-max-frequency = <24000000>;
+ spi-cpha;
+ spi-cpol;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml
index 24416b5..688100b 100644
--- a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml
@@ -49,33 +49,33 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
fxos8700@1e {
- compatible = "nxp,fxos8700";
- reg = <0x1e>;
+ compatible = "nxp,fxos8700";
+ reg = <0x1e>;
- interrupt-parent = <&gpio2>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT1";
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
fxos8700@0 {
- compatible = "nxp,fxos8700";
- reg = <0>;
+ compatible = "nxp,fxos8700";
+ reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT2";
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
index 68b481c6..decf022 100644
--- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
@@ -63,7 +63,7 @@
description: if defined provides VDD IO power to the sensor.
st,drdy-int-pin:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
The pin on the package that will be used to signal data ready
enum:
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml
new file mode 100644
index 0000000..121d540
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/ti,tmag5273.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TMAG5273 Low-Power Linear 3D Hall-Effect Sensor
+
+maintainers:
+ - Gerald Loacker <gerald.loacker@wolfvision.net>
+
+description:
+ The TI TMAG5273 is a low-power linear 3D Hall-effect sensor. This device
+ integrates three independent Hall-effect sensors in the X, Y, and Z axes.
+ The device has an integrated temperature sensor available. The TMAG5273
+ can be configured through the I2C interface to enable any combination of
+ magnetic axes and temperature measurements. An integrated angle calculation
+ engine (CORDIC) provides full 360° angular position information for both
+ on-axis and off-axis angle measurement topologies. The angle calculation is
+ performed using two user-selected magnetic axes.
+
+properties:
+ compatible:
+ const: ti,tmag5273
+
+ reg:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 1
+
+ ti,angle-measurement:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Enables angle measurement in the selected plane.
+ If not specified, "x-y" will be anables as default.
+ enum:
+ - off
+ - x-y
+ - y-z
+ - x-z
+
+ vcc-supply:
+ description:
+ A regulator providing 1.7 V to 3.6 V supply voltage on the VCC pin,
+ typically 3.3 V.
+
+ interrupts:
+ description:
+ The low active interrupt can be configured to be fixed width or latched.
+ Interrupt events can be configured to be generated from magnetic
+ thresholds or when a conversion is completed.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@35 {
+ compatible = "ti,tmag5273";
+ reg = <0x35>;
+ #io-channel-cells = <1>;
+ ti,angle-measurement = "x-z";
+ vcc-supply = <&vcc3v3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml b/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml
index 9438fff..877226e9 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml
@@ -91,12 +91,12 @@
#size-cells = <0>;
magnetometer@2e {
- compatible = "yamaha,yas530";
- reg = <0x2e>;
- vdd-supply = <&ldo1_reg>;
- iovdd-supply = <&ldo2_reg>;
- reset-gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
- interrupts = <13 IRQ_TYPE_EDGE_RISING>;
+ compatible = "yamaha,yas530";
+ reg = <0x2e>;
+ vdd-supply = <&ldo1_reg>;
+ iovdd-supply = <&ldo2_reg>;
+ reset-gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+ interrupts = <13 IRQ_TYPE_EDGE_RISING>;
};
};
@@ -105,8 +105,8 @@
#size-cells = <0>;
magnetometer@2e {
- compatible = "yamaha,yas539";
- reg = <0x2e>;
- vdd-supply = <&ldo1_reg>;
+ compatible = "yamaha,yas539";
+ reg = <0x2e>;
+ vdd-supply = <&ldo1_reg>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml b/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
index 0ebb672..b8d7083 100644
--- a/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
+++ b/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
@@ -44,7 +44,7 @@
potentiometer@2f {
compatible = "adi,ad5272-020";
- reg = <0x2F>;
+ reg = <0x2f>;
reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
index 1f9fe15..9fb8d77 100644
--- a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
@@ -39,7 +39,7 @@
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
index 72cd2c2..63885af 100644
--- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
@@ -60,16 +60,16 @@
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- pressure@77 {
- compatible = "bosch,bmp085";
- reg = <0x77>;
- interrupt-parent = <&gpio0>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
- vddd-supply = <&foo>;
- vdda-supply = <&bar>;
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@77 {
+ compatible = "bosch,bmp085";
+ reg = <0x77>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
+ vddd-supply = <&foo>;
+ vdda-supply = <&bar>;
+ };
};
diff --git a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
index 710d3b9..c999994 100644
--- a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
@@ -60,7 +60,7 @@
#address-cells = <1>;
#size-cells = <0>;
- lightning@0 {
+ lightning@0 {
compatible = "ams,as3935";
reg = <0>;
spi-max-frequency = <400000>;
diff --git a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
index 00e3b59..d4e09d2 100644
--- a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
index f088c5d..ad0bb44 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
@@ -36,7 +36,7 @@
const: 1
semtech,resolution:
- $ref: /schemas/types.yaml#/definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [8, 16, 32, 64, 128, 256, 512, 1024]
description:
Capacitance measurement resolution. For both phases, "reference" and
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
index 250439b..c620197 100644
--- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -39,6 +39,7 @@
- st,lis3lv02dl-accel
- st,lng2dm-accel
- st,lsm303agr-accel
+ - st,lsm303c-accel
- st,lsm303dl-accel
- st,lsm303dlh-accel
- st,lsm303dlhc-accel
@@ -66,6 +67,7 @@
- st,lis2mdl
- st,lis3mdl-magn
- st,lsm303agr-magn
+ - st,lsm303c-magn
- st,lsm303dlh-magn
- st,lsm303dlhc-magn
- st,lsm303dlm-magn
diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
index b69813f..f44fc32 100644
--- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
@@ -472,75 +472,74 @@
#size-cells = <0>;
temperature-sensor@0 {
- compatible = "adi,ltc2983";
- reg = <0>;
+ compatible = "adi,ltc2983";
+ reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- interrupts = <20 IRQ_TYPE_EDGE_RISING>;
- interrupt-parent = <&gpio>;
+ interrupts = <20 IRQ_TYPE_EDGE_RISING>;
+ interrupt-parent = <&gpio>;
- thermocouple@18 {
- reg = <18>;
- adi,sensor-type = <8>; //Type B
- adi,sensor-oc-current-microamp = <10>;
- adi,cold-junction-handle = <&diode5>;
- };
+ thermocouple@18 {
+ reg = <18>;
+ adi,sensor-type = <8>; //Type B
+ adi,sensor-oc-current-microamp = <10>;
+ adi,cold-junction-handle = <&diode5>;
+ };
- diode5: diode@5 {
- reg = <5>;
- adi,sensor-type = <28>;
- };
+ diode5: diode@5 {
+ reg = <5>;
+ adi,sensor-type = <28>;
+ };
- rsense2: rsense@2 {
- reg = <2>;
- adi,sensor-type = <29>;
- adi,rsense-val-milli-ohms = <1200000>; //1.2Kohms
- };
+ rsense2: rsense@2 {
+ reg = <2>;
+ adi,sensor-type = <29>;
+ adi,rsense-val-milli-ohms = <1200000>; //1.2Kohms
+ };
- rtd@14 {
- reg = <14>;
- adi,sensor-type = <15>; //PT1000
- /*2-wire, internal gnd, no current rotation*/
- adi,number-of-wires = <2>;
- adi,rsense-share;
- adi,excitation-current-microamp = <500>;
- adi,rsense-handle = <&rsense2>;
- };
+ rtd@14 {
+ reg = <14>;
+ adi,sensor-type = <15>; //PT1000
+ /*2-wire, internal gnd, no current rotation*/
+ adi,number-of-wires = <2>;
+ adi,rsense-share;
+ adi,excitation-current-microamp = <500>;
+ adi,rsense-handle = <&rsense2>;
+ };
- adc@10 {
- reg = <10>;
- adi,sensor-type = <30>;
- adi,single-ended;
- };
+ adc@10 {
+ reg = <10>;
+ adi,sensor-type = <30>;
+ adi,single-ended;
+ };
- thermistor@12 {
- reg = <12>;
- adi,sensor-type = <26>; //Steinhart
- adi,rsense-handle = <&rsense2>;
- adi,custom-steinhart = <0x00F371EC 0x12345678
- 0x2C0F8733 0x10018C66 0xA0FEACCD
- 0x90021D99>; //6 entries
- };
+ thermistor@12 {
+ reg = <12>;
+ adi,sensor-type = <26>; //Steinhart
+ adi,rsense-handle = <&rsense2>;
+ adi,custom-steinhart = <0x00f371ec 0x12345678
+ 0x2c0f8733 0x10018c66 0xa0feaccd
+ 0x90021d99>; //6 entries
+ };
- thermocouple@20 {
- reg = <20>;
- adi,sensor-type = <9>; //custom thermocouple
- adi,single-ended;
- adi,custom-thermocouple =
- /bits/ 64 <(-50220000) 0>,
- /bits/ 64 <(-30200000) 99100000>,
- /bits/ 64 <(-5300000) 135400000>,
- /bits/ 64 <0 273150000>,
- /bits/ 64 <40200000 361200000>,
- /bits/ 64 <55300000 522100000>,
- /bits/ 64 <88300000 720300000>,
- /bits/ 64 <132200000 811200000>,
- /bits/ 64 <188700000 922500000>,
- /bits/ 64 <460400000 1000000000>; //10 pairs
- };
-
+ thermocouple@20 {
+ reg = <20>;
+ adi,sensor-type = <9>; //custom thermocouple
+ adi,single-ended;
+ adi,custom-thermocouple =
+ /bits/ 64 <(-50220000) 0>,
+ /bits/ 64 <(-30200000) 99100000>,
+ /bits/ 64 <(-5300000) 135400000>,
+ /bits/ 64 <0 273150000>,
+ /bits/ 64 <40200000 361200000>,
+ /bits/ 64 <55300000 522100000>,
+ /bits/ 64 <88300000 720300000>,
+ /bits/ 64 <132200000 811200000>,
+ /bits/ 64 <188700000 922500000>,
+ /bits/ 64 <460400000 1000000000>; //10 pairs
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml
index a2823ed..7cc365e 100644
--- a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml
@@ -43,12 +43,12 @@
#address-cells = <1>;
#size-cells = <0>;
- temp_sensor@0 {
- compatible = "maxim,max31865";
- reg = <0>;
- spi-max-frequency = <400000>;
- spi-cpha;
- maxim,3-wire;
+ temperature-sensor@0 {
+ compatible = "maxim,max31865";
+ reg = <0>;
+ spi-max-frequency = <400000>;
+ spi-cpha;
+ maxim,3-wire;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml
index 347bc16..c4f1c69 100644
--- a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/temperature/ti,tmp117.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/temperature/ti,tmp117.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: "TI TMP117 - Digital temperature sensor with integrated NV memory"
+title: TI TMP117 - Digital temperature sensor with integrated NV memory
description: |
TI TMP117 - Digital temperature sensor with integrated NV memory that supports
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
index 1c191bc..ce18d7d 100644
--- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
+++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
@@ -36,6 +36,13 @@
vdd-supply:
description: The 3.3V supply to the touchscreen.
+ mainboard-vddio-supply:
+ description:
+ The supply on the main board needed to power up IO signals going
+ to the touchscreen. This supply need not go to the touchscreen
+ itself as long as it allows the main board to make signals compatible
+ with what the touchscreen is expecting for its IO rails.
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/input/iqs626a.yaml b/Documentation/devicetree/bindings/input/iqs626a.yaml
index 7a275020..e424d67 100644
--- a/Documentation/devicetree/bindings/input/iqs626a.yaml
+++ b/Documentation/devicetree/bindings/input/iqs626a.yaml
@@ -564,16 +564,6 @@
2: Partial
3: Full
- azoteq,ati-base:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 6
- maxItems: 9
- items:
- minimum: 45
- maximum: 300
- default: [45, 45, 45, 45, 45, 45, 45, 45, 45]
- description: Specifies each individual trackpad channel's ATI base.
-
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 32
@@ -620,17 +610,6 @@
description:
Tightens the ATI band from 1/8 to 1/16 of the desired target.
- azoteq,thresh:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 6
- maxItems: 9
- items:
- minimum: 0
- maximum: 255
- default: [0, 0, 0, 0, 0, 0, 0, 0, 0]
- description:
- Specifies each individual trackpad channel's touch threshold.
-
azoteq,hyst:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
@@ -720,6 +699,28 @@
Specifies the number of points across which an axial gesture must
travel in order to be interpreted as a flick or swipe.
+ patternProperties:
+ "^channel-[0-8]$":
+ type: object
+ description: Represents a single trackpad channel.
+
+ properties:
+ azoteq,thresh:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ default: 0
+ description: Specifies the threshold for the channel.
+
+ azoteq,ati-base:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 45
+ maximum: 300
+ default: 45
+ description: Specifies the channel's ATI base.
+
+ additionalProperties: false
+
dependencies:
azoteq,gesture-swipe: ["linux,keycodes"]
azoteq,timeout-tap-ms: ["linux,keycodes"]
@@ -780,14 +781,8 @@
azoteq,filt-str-lp-cnt = <1>;
azoteq,hyst = <4>;
- azoteq,thresh = <35>, <40>, <40>,
- <38>, <33>, <38>,
- <35>, <35>, <35>;
azoteq,ati-mode = <3>;
- azoteq,ati-base = <195>, <195>, <195>,
- <195>, <195>, <195>,
- <195>, <195>, <195>;
azoteq,ati-target = <512>;
azoteq,proj-bias = <1>;
@@ -804,6 +799,51 @@
azoteq,timeout-swipe-ms = <800>;
azoteq,timeout-tap-ms = <400>;
azoteq,thresh-swipe = <40>;
+
+ channel-0 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-1 {
+ azoteq,thresh = <40>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-2 {
+ azoteq,thresh = <40>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-3 {
+ azoteq,thresh = <38>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-4 {
+ azoteq,thresh = <33>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-5 {
+ azoteq,thresh = <38>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-6 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-7 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-8 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
};
/*
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
index 2f72ec4..037c3ae 100644
--- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
+++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
@@ -26,6 +26,7 @@
enum:
- mediatek,mt6323-keys
- mediatek,mt6331-keys
+ - mediatek,mt6357-keys
- mediatek,mt6358-keys
- mediatek,mt6397-keys
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 67d4d8f..5fa625b 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -19,7 +19,10 @@
- microchip,cap1106
- microchip,cap1126
- microchip,cap1188
+ - microchip,cap1203
- microchip,cap1206
+ - microchip,cap1293
+ - microchip,cap1298
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
deleted file mode 100644
index 0a5d0cb..0000000
--- a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* ST-Microelectronics FingerTip touchscreen controller
-
-The ST-Microelectronics FingerTip device provides a basic touchscreen
-functionality. Along with it the user can enable the touchkey which can work as
-a basic HOME and BACK key for phones.
-
-The driver supports also hovering as an absolute single touch event with x, y, z
-coordinates.
-
-Required properties:
-- compatible : must be "st,stmfts"
-- reg : I2C slave address, (e.g. 0x49)
-- interrupts : interrupt specification
-- avdd-supply : analogic power supply
-- vdd-supply : power supply
-- touchscreen-size-x : see touchscreen.txt
-- touchscreen-size-y : see touchscreen.txt
-
-Optional properties:
-- touch-key-connected : specifies whether the touchkey feature is connected
-- ledvdd-supply : power supply to the touch key leds
-
-Example:
-
-i2c@00000000 {
-
- /* ... */
-
- touchscreen@49 {
- compatible = "st,stmfts";
- reg = <0x49>;
- interrupt-parent = <&gpa1>;
- interrupts = <1 IRQ_TYPE_NONE>;
- touchscreen-size-x = <1599>;
- touchscreen-size-y = <2559>;
- touch-key-connected;
- avdd-supply = <&ldo30_reg>;
- vdd-supply = <&ldo31_reg>;
- ledvdd-supply = <&ldo33_reg>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
new file mode 100644
index 0000000..c593ae6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/st,stmfts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST-Microelectronics FingerTip touchscreen controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+ The ST-Microelectronics FingerTip device provides a basic touchscreen
+ functionality. Along with it the user can enable the touchkey which can work
+ as a basic HOME and BACK key for phones.
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ const: st,stmfts
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogic power supply
+
+ interrupts:
+ maxItems: 1
+
+ ledvdd-supply:
+ description: Power supply to the touch key leds
+
+ touch-key-connected:
+ type: boolean
+ description: The touchkey feature is connected
+
+ vdd-supply:
+ description: Power supply
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - interrupts
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@49 {
+ compatible = "st,stmfts";
+ reg = <0x49>;
+ interrupt-parent = <&gpa1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ touchscreen-size-x = <1599>;
+ touchscreen-size-y = <2559>;
+ touch-key-connected;
+ avdd-supply = <&ldo30_reg>;
+ vdd-supply = <&ldo31_reg>;
+ ledvdd-supply = <&ldo33_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
index 0c720db..12a0d3e 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
@@ -27,11 +27,13 @@
- qcom,sc7280-cpu-bwmon
- qcom,sc8280xp-cpu-bwmon
- qcom,sdm845-bwmon
+ - qcom,sm8550-cpu-bwmon
- const: qcom,msm8998-bwmon
- const: qcom,msm8998-bwmon # BWMON v4
- items:
- enum:
- qcom,sc8280xp-llcc-bwmon
+ - qcom,sm8550-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon # BWMON v5
- const: qcom,sdm845-llcc-bwmon # BWMON v5
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
index aadae44..576992a 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
@@ -22,6 +22,7 @@
- qcom,sc7180-osm-l3
- qcom,sc8180x-osm-l3
- qcom,sdm845-osm-l3
+ - qcom,sm6350-osm-l3
- qcom,sm8150-osm-l3
- const: qcom,osm-l3
- items:
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml
new file mode 100644
index 0000000..0070b03
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,qdu1000-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on QDU1000
+
+maintainers:
+ - Georgi Djakov <djakov@kernel.org>
+ - Odelu Kukatla <quic_okukatla@quicinc.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+properties:
+ compatible:
+ enum:
+ - qcom,qdu1000-clk-virt
+ - qcom,qdu1000-gem-noc
+ - qcom,qdu1000-mc-virt
+ - qcom,qdu1000-system-noc
+
+ '#interconnect-cells': true
+
+ reg:
+ maxItems: 1
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qdu1000-clk-virt
+ - qcom,qdu1000-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/qcom,qdu1000-rpmh.h>
+
+ system_noc: interconnect@1640000 {
+ compatible = "qcom,qdu1000-system-noc";
+ reg = <0x1640000 0x45080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ clk_virt: interconnect-0 {
+ compatible = "qcom,qdu1000-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
index 5e6be4e..d9d243c 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
@@ -62,6 +62,37 @@
power-domains:
maxItems: 1
+# Child node's properties
+patternProperties:
+ '^interconnect-[a-z0-9]+$':
+ type: object
+ description:
+ snoc-mm is a child of snoc, sharing snoc's register address space.
+
+ properties:
+ compatible:
+ enum:
+ - qcom,msm8939-snoc-mm
+
+ '#interconnect-cells':
+ const: 1
+
+ clock-names:
+ items:
+ - const: bus
+ - const: bus_a
+
+ clocks:
+ items:
+ - description: Bus Clock
+ - description: Bus A Clock
+
+ required:
+ - compatible
+ - '#interconnect-cells'
+ - clock-names
+ - clocks
+
required:
- compatible
- reg
@@ -108,37 +139,6 @@
- description: Bus Clock
- description: Bus A Clock
- # Child node's properties
- patternProperties:
- '^interconnect-[a-z0-9]+$':
- type: object
- description:
- snoc-mm is a child of snoc, sharing snoc's register address space.
-
- properties:
- compatible:
- enum:
- - qcom,msm8939-snoc-mm
-
- '#interconnect-cells':
- const: 1
-
- clock-names:
- items:
- - const: bus
- - const: bus_a
-
- clocks:
- items:
- - description: Bus Clock
- - description: Bus A Clock
-
- required:
- - compatible
- - '#interconnect-cells'
- - clock-names
- - clocks
-
- if:
properties:
compatible:
@@ -237,6 +237,17 @@
- description: Aggregate2 USB3 AXI Clock.
- description: Config NoC USB2 AXI Clock.
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8939-snoc
+ then:
+ patternProperties:
+ '^interconnect-[a-z0-9]+$': false
+
examples:
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
index a429a1e..4d93ad41 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
@@ -39,18 +39,6 @@
- qcom,sc7180-npu-noc
- qcom,sc7180-qup-virt
- qcom,sc7180-system-noc
- - qcom,sc7280-aggre1-noc
- - qcom,sc7280-aggre2-noc
- - qcom,sc7280-clk-virt
- - qcom,sc7280-cnoc2
- - qcom,sc7280-cnoc3
- - qcom,sc7280-dc-noc
- - qcom,sc7280-gem-noc
- - qcom,sc7280-lpass-ag-noc
- - qcom,sc7280-mc-virt
- - qcom,sc7280-mmss-noc
- - qcom,sc7280-nsp-noc
- - qcom,sc7280-system-noc
- qcom,sc8180x-aggre1-noc
- qcom,sc8180x-aggre2-noc
- qcom,sc8180x-camnoc-virt
@@ -58,23 +46,18 @@
- qcom,sc8180x-config-noc
- qcom,sc8180x-dc-noc
- qcom,sc8180x-gem-noc
- - qcom,sc8180x-ipa-virt
- qcom,sc8180x-mc-virt
- qcom,sc8180x-mmss-noc
- qcom,sc8180x-qup-virt
- qcom,sc8180x-system-noc
- - qcom,sc8280xp-aggre1-noc
- - qcom,sc8280xp-aggre2-noc
- - qcom,sc8280xp-clk-virt
- - qcom,sc8280xp-config-noc
- - qcom,sc8280xp-dc-noc
- - qcom,sc8280xp-gem-noc
- - qcom,sc8280xp-lpass-ag-noc
- - qcom,sc8280xp-mc-virt
- - qcom,sc8280xp-mmss-noc
- - qcom,sc8280xp-nspa-noc
- - qcom,sc8280xp-nspb-noc
- - qcom,sc8280xp-system-noc
+ - qcom,sdm670-aggre1-noc
+ - qcom,sdm670-aggre2-noc
+ - qcom,sdm670-config-noc
+ - qcom,sdm670-dc-noc
+ - qcom,sdm670-gladiator-noc
+ - qcom,sdm670-mem-noc
+ - qcom,sdm670-mmss-noc
+ - qcom,sdm670-system-noc
- qcom,sdm845-aggre1-noc
- qcom,sdm845-aggre2-noc
- qcom,sdm845-config-noc
@@ -96,7 +79,6 @@
- qcom,sm8150-config-noc
- qcom,sm8150-dc-noc
- qcom,sm8150-gem-noc
- - qcom,sm8150-ipa-virt
- qcom,sm8150-mc-virt
- qcom,sm8150-mmss-noc
- qcom,sm8150-system-noc
@@ -106,7 +88,6 @@
- qcom,sm8250-config-noc
- qcom,sm8250-dc-noc
- qcom,sm8250-gem-noc
- - qcom,sm8250-ipa-virt
- qcom,sm8250-mc-virt
- qcom,sm8250-mmss-noc
- qcom,sm8250-npu-noc
@@ -121,17 +102,6 @@
- qcom,sm8350-mmss-noc
- qcom,sm8350-compute-noc
- qcom,sm8350-system-noc
- - qcom,sm8450-aggre1-noc
- - qcom,sm8450-aggre2-noc
- - qcom,sm8450-clk-virt
- - qcom,sm8450-config-noc
- - qcom,sm8450-gem-noc
- - qcom,sm8450-lpass-ag-noc
- - qcom,sm8450-mc-virt
- - qcom,sm8450-mmss-noc
- - qcom,sm8450-nsp-noc
- - qcom,sm8450-pcie-anoc
- - qcom,sm8450-system-noc
'#interconnect-cells': true
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml
new file mode 100644
index 0000000..2e0c0bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sa8775p-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SA8775P
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also:: include/dt-bindings/interconnect/qcom,sa8775p.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sa8775p-aggre1-noc
+ - qcom,sa8775p-aggre2-noc
+ - qcom,sa8775p-clk-virt
+ - qcom,sa8775p-config-noc
+ - qcom,sa8775p-dc-noc
+ - qcom,sa8775p-gem-noc
+ - qcom,sa8775p-gpdsp-anoc
+ - qcom,sa8775p-lpass-ag-noc
+ - qcom,sa8775p-mc-virt
+ - qcom,sa8775p-mmss-noc
+ - qcom,sa8775p-nspa-noc
+ - qcom,sa8775p-nspb-noc
+ - qcom,sa8775p-pcie-anoc
+ - qcom,sa8775p-system-noc
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ aggre1_noc: interconnect-aggre1-noc {
+ compatible = "qcom,sa8775p-aggre1-noc";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
new file mode 100644
index 0000000..b135597
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sc7280-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SC7280
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also:: include/dt-bindings/interconnect/qcom,sc7280.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7280-aggre1-noc
+ - qcom,sc7280-aggre2-noc
+ - qcom,sc7280-clk-virt
+ - qcom,sc7280-cnoc2
+ - qcom,sc7280-cnoc3
+ - qcom,sc7280-dc-noc
+ - qcom,sc7280-gem-noc
+ - qcom,sc7280-lpass-ag-noc
+ - qcom,sc7280-mc-virt
+ - qcom,sc7280-mmss-noc
+ - qcom,sc7280-nsp-noc
+ - qcom,sc7280-system-noc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-clk-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interconnect {
+ compatible = "qcom,sc7280-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ interconnect@9100000 {
+ reg = <0x9100000 0xe2200>;
+ compatible = "qcom,sc7280-gem-noc";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml
new file mode 100644
index 0000000..6c2da03
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sc8280xp-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SC8280XP
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also:: include/dt-bindings/interconnect/qcom,sc8280xp.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-aggre1-noc
+ - qcom,sc8280xp-aggre2-noc
+ - qcom,sc8280xp-clk-virt
+ - qcom,sc8280xp-config-noc
+ - qcom,sc8280xp-dc-noc
+ - qcom,sc8280xp-gem-noc
+ - qcom,sc8280xp-lpass-ag-noc
+ - qcom,sc8280xp-mc-virt
+ - qcom,sc8280xp-mmss-noc
+ - qcom,sc8280xp-nspa-noc
+ - qcom,sc8280xp-nspb-noc
+ - qcom,sc8280xp-system-noc
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interconnect-0 {
+ compatible = "qcom,sc8280xp-aggre1-noc";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml
new file mode 100644
index 0000000..3cff7e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm8450-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM8450
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also:: include/dt-bindings/interconnect/qcom,sm8450.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8450-aggre1-noc
+ - qcom,sm8450-aggre2-noc
+ - qcom,sm8450-clk-virt
+ - qcom,sm8450-config-noc
+ - qcom,sm8450-gem-noc
+ - qcom,sm8450-lpass-ag-noc
+ - qcom,sm8450-mc-virt
+ - qcom,sm8450-mmss-noc
+ - qcom,sm8450-nsp-noc
+ - qcom,sm8450-pcie-anoc
+ - qcom,sm8450-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-clk-virt
+ - qcom,sm8450-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe 0 AXI clock
+ - description: aggre-NOC PCIe 1 AXI clock
+ - description: aggre UFS PHY AXI clock
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-aggre1-noc
+ - qcom,sm8450-aggre2-noc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ interconnect-0 {
+ compatible = "qcom,sm8450-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ interconnect@1700000 {
+ compatible = "qcom,sm8450-aggre2-noc";
+ reg = <0x01700000 0x31080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc GCC_AGGRE_NOC_PCIE_0_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_1_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&rpmhcc RPMH_IPA_CLK>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml
new file mode 100644
index 0000000..716bd21
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm8550-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM8550
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also:: include/dt-bindings/interconnect/qcom,sm8550-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8550-aggre1-noc
+ - qcom,sm8550-aggre2-noc
+ - qcom,sm8550-clk-virt
+ - qcom,sm8550-cnoc-main
+ - qcom,sm8550-config-noc
+ - qcom,sm8550-gem-noc
+ - qcom,sm8550-lpass-ag-noc
+ - qcom,sm8550-lpass-lpiaon-noc
+ - qcom,sm8550-lpass-lpicx-noc
+ - qcom,sm8550-mc-virt
+ - qcom,sm8550-mmss-noc
+ - qcom,sm8550-nsp-noc
+ - qcom,sm8550-pcie-anoc
+ - qcom,sm8550-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-clk-virt
+ - qcom,sm8550-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-aggre1-noc
+ - qcom,sm8550-aggre2-noc
+ - qcom,sm8550-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+
+ clk_virt: interconnect-0 {
+ compatible = "qcom,sm8550-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e0000 {
+ compatible = "qcom,sm8550-aggre1-noc";
+ reg = <0x016e0000 0x14400>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
index ad9ed59..5e26e48 100644
--- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
+++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
@@ -196,6 +196,8 @@
maxItems: 2
operating-points-v2: true
+ opp-table:
+ type: object
samsung,data-clock-ratio:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -227,6 +229,31 @@
operating-points-v2 = <&bus_dmc_opp_table>;
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>;
+
+ bus_dmc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-50000000 {
+ opp-hz = /bits/ 64 <50000000>;
+ opp-microvolt = <800000>;
+ };
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <800000>;
+ };
+ opp-134000000 {
+ opp-hz = /bits/ 64 <134000000>;
+ opp-microvolt = <800000>;
+ };
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <825000>;
+ };
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <875000>;
+ };
+ };
};
ppmu_dmc0: ppmu@106a0000 {
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
index 46b2eb3..c680de1c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
@@ -109,7 +109,8 @@
for system suspend/resume.
brcm,int-fwd-mask:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: >
if present, a bit mask to configure the interrupts which have a mux gate,
typically UARTs. Setting these bits will make their respective interrupt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml
deleted file mode 100644
index 2a1cf88..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/interrupt-controller/loongarch,cpu-interrupt-controller.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: LoongArch CPU Interrupt Controller
-
-maintainers:
- - Liu Peibao <liupeibao@loongson.cn>
-
-properties:
- compatible:
- const: loongarch,cpu-interrupt-controller
-
- '#interrupt-cells':
- const: 1
-
- interrupt-controller: true
-
-additionalProperties: false
-
-required:
- - compatible
- - '#interrupt-cells'
- - interrupt-controller
-
-examples:
- - |
- interrupt-controller {
- compatible = "loongarch,cpu-interrupt-controller";
- #interrupt-cells = <1>;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml
new file mode 100644
index 0000000..adf98997
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,cpu-interrupt-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LoongArch CPU Interrupt Controller
+
+maintainers:
+ - Liu Peibao <liupeibao@loongson.cn>
+
+properties:
+ compatible:
+ const: loongson,cpu-interrupt-controller
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - interrupt-controller
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "loongson,cpu-interrupt-controller";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
deleted file mode 100644
index a63ed9f..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Loongson ls1x Interrupt Controller
-
-Required properties:
-
-- compatible : should be "loongson,ls1x-intc". Valid strings are:
-
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 2.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-intc: interrupt-controller@1fd01040 {
- compatible = "loongson,ls1x-intc";
- reg = <0x1fd01040 0x18>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- interrupt-parent = <&cpu_intc>;
- interrupts = <2>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml
new file mode 100644
index 0000000..c60125f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,ls1x-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 Interrupt Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ Loongson-1 interrupt controller is connected to the MIPS core interrupt
+ controller, which controls several groups of interrupts.
+
+properties:
+ compatible:
+ const: loongson,ls1x-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ intc0: interrupt-controller@1fd01040 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd01040 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
deleted file mode 100644
index c54c5a9..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Samsung S3C24XX Interrupt Controllers
-
-The S3C24XX SoCs contain a custom set of interrupt controllers providing a
-varying number of interrupt sources. The set consists of a main- and sub-
-controller and on newer SoCs even a second main controller.
-
-Required properties:
-- compatible: Compatible property value should be "samsung,s3c2410-irq"
- for machines before s3c2416 and "samsung,s3c2416-irq" for s3c2416 and later.
-
-- reg: Physical base address of the controller and length of memory mapped
- region.
-
-- interrupt-controller : Identifies the node as an interrupt controller
-
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 4 and interrupt descriptor shall
- have the following format:
- <ctrl_num parent_irq ctrl_irq type>
-
- ctrl_num contains the controller to use:
- - 0 ... main controller
- - 1 ... sub controller
- - 2 ... second main controller on s3c2416 and s3c2450
- parent_irq contains the parent bit in the main controller and will be
- ignored in main controllers
- ctrl_irq contains the interrupt bit of the controller
- type contains the trigger type to use
-
-Example:
-
- interrupt-controller@4a000000 {
- compatible = "samsung,s3c2410-irq";
- reg = <0x4a000000 0x100>;
- interrupt-controller;
- #interrupt-cells=<4>;
- };
-
- [...]
-
- serial@50000000 {
- compatible = "samsung,s3c2410-uart";
- reg = <0x50000000 0x4000>;
- interrupt-parent = <&subintc>;
- interrupts = <1 28 0 4>, <1 28 1 4>;
- };
-
- rtc@57000000 {
- compatible = "samsung,s3c2410-rtc";
- reg = <0x57000000 0x100>;
- interrupt-parent = <&intc>;
- interrupts = <0 30 0 3>, <0 8 0 3>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 99e01f4..63bc89e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -45,7 +45,6 @@
from S-mode. So add thead,c900-plic to distinguish them.
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
- Palmer Dabbelt <palmer@dabbelt.com>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt
deleted file mode 100644
index dac0846..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Socionext SynQuacer External Interrupt Unit (EXIU)
-
-The Socionext Synquacer SoC has an external interrupt unit (EXIU)
-that forwards a block of 32 configurable input lines to 32 adjacent
-level-high type GICv3 SPIs.
-
-Required properties:
-
-- compatible : Should be "socionext,synquacer-exiu".
-- reg : Specifies base physical address and size of the
- control registers.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 3.
-- socionext,spi-base : The SPI number of the first SPI of the 32 adjacent
- ones the EXIU forwards its interrups to.
-
-Notes:
-
-- Only SPIs can use the EXIU as an interrupt parent.
-
-Example:
-
- exiu: interrupt-controller@510c0000 {
- compatible = "socionext,synquacer-exiu";
- reg = <0x0 0x510c0000 0x0 0x20>;
- interrupt-controller;
- interrupt-parent = <&gic>;
- #interrupt-cells = <3>;
- socionext,spi-base = <112>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml
new file mode 100644
index 0000000..92cec22
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/socionext,synquacer-exiu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext SynQuacer External Interrupt Unit (EXIU)
+
+maintainers:
+ - Ard Biesheuvel <ardb@kernel.org>
+
+description: |+
+ The Socionext SynQuacer SoC has an external interrupt unit (EXIU)
+ that forwards a block of 32 configurable input lines to 32 adjacent
+ level-high type GICv3 SPIs.
+
+properties:
+ compatible:
+ const: socionext,synquacer-exiu
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 3
+
+ interrupt-controller: true
+
+ socionext,spi-base:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The SPI number of the first SPI of the 32 adjacent ones the
+ EXIU forwards its interrupts to.
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+ - socionext,spi-base
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interrupt-controller@510c0000 {
+ compatible = "socionext,synquacer-exiu";
+ reg = <0x510c0000 0x20>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ #interrupt-cells = <3>;
+ socionext,spi-base = <112>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml
index 06af2ba..903edf8 100644
--- a/Documentation/devicetree/bindings/iommu/apple,dart.yaml
+++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml
@@ -24,6 +24,7 @@
compatible:
enum:
- apple,t8103-dart
+ - apple,t8110-dart
- apple,t6000-dart
reg:
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index b28c5c2..807cb51 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -36,13 +36,17 @@
- enum:
- qcom,qcm2290-smmu-500
- qcom,qdu1000-smmu-500
+ - qcom,sa8775p-smmu-500
- qcom,sc7180-smmu-500
- qcom,sc7280-smmu-500
- qcom,sc8180x-smmu-500
- qcom,sc8280xp-smmu-500
- qcom,sdm670-smmu-500
- qcom,sdm845-smmu-500
+ - qcom,sdx55-smmu-500
+ - qcom,sdx65-smmu-500
- qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
- qcom,sm8150-smmu-500
@@ -52,14 +56,6 @@
- const: qcom,smmu-500
- const: arm,mmu-500
- - description: Qcom SoCs implementing "arm,mmu-500" (non-qcom implementation)
- deprecated: true
- items:
- - enum:
- - qcom,sdx55-smmu-500
- - qcom,sdx65-smmu-500
- - const: arm,mmu-500
-
- description: Qcom SoCs implementing "arm,mmu-500" (legacy binding)
deprecated: true
items:
@@ -84,6 +80,7 @@
items:
- enum:
- qcom,sc7280-smmu-500
+ - qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- const: qcom,adreno-smmu
- const: arm,mmu-500
@@ -201,7 +198,8 @@
maxItems: 7
power-domains:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
nvidia,memory-controller:
description: |
@@ -366,6 +364,56 @@
- description: interface clock required to access smmu's registers
through the TCU's programming interface.
+ # Disallow clocks for all other platforms with specific compatibles
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - cavium,smmu-v2
+ - marvell,ap806-smmu-500
+ - nvidia,smmu-500
+ - qcom,qcm2290-smmu-500
+ - qcom,qdu1000-smmu-500
+ - qcom,sa8775p-smmu-500
+ - qcom,sc7180-smmu-500
+ - qcom,sc8180x-smmu-500
+ - qcom,sc8280xp-smmu-500
+ - qcom,sdm670-smmu-500
+ - qcom,sdm845-smmu-500
+ - qcom,sdx55-smmu-500
+ - qcom,sdx65-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
+ - qcom,sm6350-smmu-500
+ - qcom,sm6375-smmu-500
+ - qcom,sm8350-smmu-500
+ - qcom,sm8450-smmu-500
+ then:
+ properties:
+ clock-names: false
+ clocks: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm6375-smmu-500
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: SNoC MMU TBU RT GDSC
+ - description: SNoC MMU TBU NRT GDSC
+ - description: SNoC TURING MMU TBU0 GDSC
+
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains:
+ maxItems: 1
+
examples:
- |+
/* SMMU with stream matching or stream indexing */
diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
index 059139a..e6cecfd 100644
--- a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
@@ -10,6 +10,7 @@
- compatible : Should be one of:
"qcom,msm8916-iommu"
+ "qcom,msm8953-iommu"
Followed by "qcom,msm-iommu-v1".
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 26d0a51..72308a4 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -49,6 +49,7 @@
- enum:
- renesas,ipmmu-r8a779a0 # R-Car V3U
- renesas,ipmmu-r8a779f0 # R-Car S4-8
+ - renesas,ipmmu-r8a779g0 # R-Car V4H
- const: renesas,rcar-gen4-ipmmu-vmsa # R-Car Gen4
reg:
diff --git a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
new file mode 100644
index 0000000..e119145
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTZ8866 backlight
+
+maintainers:
+ - Jianhua Lu <lujianhua000@gmail.com>
+
+description: |
+ The Kinetic Technologies KTZ8866 is a high efficiency 6-channels-current-sinks
+ led backlight with dual lcd bias power.
+ https://www.kinet-ic.com/ktz8866/
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ const: kinetic,ktz8866
+
+ vddpos-supply:
+ description: positive boost supply regulator.
+
+ vddneg-supply:
+ description: negative boost supply regulator.
+
+ enable-gpios:
+ description: GPIO to use to enable/disable the backlight (HWEN pin).
+ maxItems: 1
+
+ current-num-sinks:
+ description: number of the LED current sinks' channels.
+ enum: [1, 2, 3, 4, 5, 6]
+
+ kinetic,current-ramp-delay-ms:
+ description: |
+ LED current ramping delay time in milliseconds, note that the
+ case 1 will be mapped to 1μs.
+ enum: [1, 2, 4, 8, 16, 32, 64, 128, 192, 256, 320, 384, 448, 512, 576, 640]
+
+ kinetic,led-enable-ramp-delay-ms:
+ description: |
+ LED on/off ramping delay time in milliseconds, note that the case 0 will be
+ mapped to 512μs because ktz8866 can't ramp faster than it.
+ enum: [0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384]
+
+ kinetic,enable-lcd-bias:
+ description: Set if we want to output bias power supply for LCD.
+ type: boolean
+
+required:
+ - compatible
+ - vddpos-supply
+ - vddneg-supply
+ - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ backlight {
+ compatible = "kinetic,ktz8866";
+
+ vddpos-supply = <&bl_vddpos_5p5>;
+ vddneg-supply = <&bl_vddneg_5p5>;
+ enable-gpios = <&tlmm 139 GPIO_ACTIVE_HIGH>;
+ current-num-sinks = <5>;
+ kinetic,current-ramp-delay-ms = <128>;
+ kinetic,led-enable-ramp-delay-ms = <1>;
+ kinetic,enable-lcd-bias;
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
index 9acdb78..5f1849b 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
@@ -19,6 +19,7 @@
compatible:
enum:
- qcom,pm8941-wled
+ - qcom,pmi8950-wled
- qcom,pmi8994-wled
- qcom,pmi8998-wled
- qcom,pm660l-wled
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index f5c57a5..15e3f66 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -90,17 +90,22 @@
- heartbeat
# LED indicates disk activity
- disk-activity
- # LED indicates IDE disk activity (deprecated), in new implementations
- # use "disk-activity"
- - ide-disk
+ - disk-read
+ - disk-write
# LED flashes at a fixed, configurable rate
- timer
# LED alters the brightness for the specified duration with one software
# timer (requires "led-pattern" property)
- pattern
- # LED is triggered by SD/MMC activity
- - pattern: "^mmc[0-9]+$"
+ - usb-gadget
+ - usb-host
- pattern: "^cpu[0-9]*$"
+ - pattern: "^hci[0-9]+-power$"
+ # LED is triggered by Bluetooth activity
+ - pattern: "^mmc[0-9]+$"
+ # LED is triggered by SD/MMC activity
+ - pattern: "^phy[0-9]+tx$"
+ # LED is triggered by WLAN activity
led-pattern:
description: |
diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
index 45bf9f7..7335369 100644
--- a/Documentation/devicetree/bindings/leds/leds-mt6323.txt
+++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
@@ -9,7 +9,7 @@
For MT6323 MFD bindings see:
Documentation/devicetree/bindings/mfd/mt6397.txt
For MediaTek PMIC wrapper bindings see:
-Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
Required properties:
- compatible : Must be "mediatek,mt6323-led"
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
index 943f947..d888ead 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
@@ -18,9 +18,12 @@
oneOf:
- items:
- enum:
+ - qcom,ipq5332-apcs-apps-global
+ - const: qcom,ipq6018-apcs-apps-global
+ - items:
+ - enum:
- qcom,ipq6018-apcs-apps-global
- qcom,ipq8074-apcs-apps-global
- - qcom,msm8976-apcs-kpss-global
- qcom,msm8996-apcs-hmss-global
- qcom,msm8998-apcs-hmss-global
- qcom,qcm2290-apcs-hmss-global
@@ -37,8 +40,10 @@
- qcom,msm8916-apcs-kpss-global
- qcom,msm8939-apcs-kpss-global
- qcom,msm8953-apcs-kpss-global
+ - qcom,msm8976-apcs-kpss-global
- qcom,msm8994-apcs-kpss-global
- qcom,qcs404-apcs-apps-global
+ - qcom,sdx55-apcs-gcc
- const: syscon
reg:
maxItems: 1
@@ -71,15 +76,8 @@
compatible:
enum:
- qcom,msm8916-apcs-kpss-global
- - qcom,msm8994-apcs-kpss-global
- - qcom,msm8996-apcs-hmss-global
- - qcom,msm8998-apcs-hmss-global
+ - qcom,msm8939-apcs-kpss-global
- qcom,qcs404-apcs-apps-global
- - qcom,sc7180-apss-shared
- - qcom,sdm660-apcs-hmss-global
- - qcom,sdm845-apss-shared
- - qcom,sm6125-apcs-hmss-global
- - qcom,sm8150-apss-shared
then:
properties:
clocks:
@@ -110,9 +108,10 @@
- if:
properties:
compatible:
- enum:
- - qcom,ipq6018-apcs-apps-global
- - qcom,ipq8074-apcs-apps-global
+ contains:
+ enum:
+ - qcom,ipq6018-apcs-apps-global
+ - qcom,ipq8074-apcs-apps-global
then:
properties:
clocks:
@@ -123,12 +122,37 @@
items:
- const: pll
- const: xo
+
- if:
properties:
compatible:
enum:
- - qcom,ipq6018-apcs-apps-global
- - qcom,ipq8074-apcs-apps-global
+ - qcom,msm8953-apcs-kpss-global
+ - qcom,msm8976-apcs-kpss-global
+ - qcom,msm8994-apcs-kpss-global
+ - qcom,msm8996-apcs-hmss-global
+ - qcom,msm8998-apcs-hmss-global
+ - qcom,qcm2290-apcs-hmss-global
+ - qcom,sc7180-apss-shared
+ - qcom,sc8180x-apss-shared
+ - qcom,sdm660-apcs-hmss-global
+ - qcom,sdm845-apss-shared
+ - qcom,sm4250-apcs-hmss-global
+ - qcom,sm6115-apcs-hmss-global
+ - qcom,sm6125-apcs-hmss-global
+ - qcom,sm8150-apss-shared
+ then:
+ properties:
+ clocks: false
+ clock-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq6018-apcs-apps-global
+ - qcom,ipq8074-apcs-apps-global
then:
properties:
'#clock-cells':
@@ -148,6 +172,7 @@
reg = <0x9820000 0x1000>;
#mbox-cells = <1>;
+ #clock-cells = <0>;
};
rpm-glink {
@@ -155,7 +180,6 @@
interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
qcom,rpm-msg-ram = <&rpm_msg_ram>;
mboxes = <&apcs_glb 0>;
- mbox-names = "rpm_hlos";
};
# Example apcs with qcs404
diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
index f5c7343..cc6f66e 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
@@ -24,6 +24,8 @@
compatible:
items:
- enum:
+ - qcom,qdu1000-ipcc
+ - qcom,sa8775p-ipcc
- qcom,sc7280-ipcc
- qcom,sc8280xp-ipcc
- qcom,sm6350-ipcc
diff --git a/Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml
new file mode 100644
index 0000000..a023c28
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/st,sti-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics Mailbox Driver for STi platform
+
+description:
+ Each ST Mailbox IP currently consists of 4 instances of 32 channels.
+ Messages are passed between Application and Remote processors using
+ shared memory.
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+properties:
+ compatible:
+ const: st,stih407-mailbox
+
+ reg:
+ maxItems: 1
+
+ mbox-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: name of the mailbox IP
+
+ interrupts:
+ description: the irq line for the RX mailbox
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mailbox0: mailbox@8f00000 {
+ compatible = "st,stih407-mailbox";
+ reg = <0x8f00000 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <2>;
+ mbox-name = "a9";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
deleted file mode 100644
index 351f612..0000000
--- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-ST Microelectronics Mailbox Driver
-
-Each ST Mailbox IP currently consists of 4 instances of 32 channels. Messages
-are passed between Application and Remote processors using shared memory.
-
-Controller
-----------
-
-Required properties:
-- compatible : Should be "st,stih407-mailbox"
-- reg : Offset and length of the device's register set
-- mbox-name : Name of the mailbox
-- #mbox-cells: : Must be 2
- <&phandle instance channel direction>
- phandle : Label name of controller
- instance : Instance number
- channel : Channel number
-
-Optional properties
-- interrupts : Contains the IRQ line for a Rx mailbox
-
-Example:
-
-mailbox0: mailbox@0 {
- compatible = "st,stih407-mailbox";
- reg = <0x08f00000 0x1000>;
- interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
- #mbox-cells = <2>;
- mbox-name = "a9";
-};
-
-Client
-------
-
-Required properties:
-- compatible : Many (See the client docs)
-- reg : Shared (between Application and Remote) memory address
-- mboxes : Standard property to specify a Mailbox (See ./mailbox.txt)
- Cells must match 'mbox-cells' (See Controller docs above)
-
-Optional properties
-- mbox-names : Name given to channels seen in the 'mboxes' property.
-
-Example:
-
-mailbox_test {
- compatible = "mailbox-test";
- reg = <0x[shared_memory_address], [shared_memory_size]>;
- mboxes = <&mailbox2 0 1>, <&mailbox0 2 1>;
- mbox-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml
deleted file mode 100644
index 8d844f4..0000000
--- a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml
+++ /dev/null
@@ -1,95 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-# Copyright 2019 BayLibre, SAS
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/media/amlogic,meson-gx-ao-cec.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Amlogic Meson AO-CEC Controller
-
-maintainers:
- - Neil Armstrong <neil.armstrong@linaro.org>
-
-description: |
- The Amlogic Meson AO-CEC module is present is Amlogic SoCs and its purpose is
- to handle communication between HDMI connected devices over the CEC bus.
-
-properties:
- compatible:
- enum:
- - amlogic,meson-gx-ao-cec # GXBB, GXL, GXM, G12A and SM1 AO_CEC_A module
- - amlogic,meson-g12a-ao-cec # G12A AO_CEC_B module
- - amlogic,meson-sm1-ao-cec # SM1 AO_CEC_B module
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- clock-names:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- hdmi-phandle:
- description: phandle to the HDMI controller
- $ref: /schemas/types.yaml#/definitions/phandle
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - amlogic,meson-gx-ao-cec
-
- then:
- properties:
- clocks:
- items:
- - description: AO-CEC clock
-
- clock-names:
- items:
- - const: core
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - amlogic,meson-g12a-ao-cec
- - amlogic,meson-sm1-ao-cec
-
- then:
- properties:
- clocks:
- items:
- - description: AO-CEC clock generator source
-
- clock-names:
- items:
- - const: oscin
-
-required:
- - compatible
- - reg
- - interrupts
- - hdmi-phandle
- - clocks
- - clock-names
-
-additionalProperties: false
-
-examples:
- - |
- cec_AO: cec@100 {
- compatible = "amlogic,meson-gx-ao-cec";
- reg = <0x00100 0x14>;
- interrupts = <199>;
- clocks = <&clkc_cec>;
- clock-names = "core";
- hdmi-phandle = <&hdmi_tx>;
- };
diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt b/Documentation/devicetree/bindings/media/cec-gpio.txt
deleted file mode 100644
index 47e8d73..0000000
--- a/Documentation/devicetree/bindings/media/cec-gpio.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* HDMI CEC GPIO driver
-
-The HDMI CEC GPIO module supports CEC implementations where the CEC line
-is hooked up to a pull-up GPIO line and - optionally - the HPD line is
-hooked up to another GPIO line.
-
-Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
-5V lines it is 5.3V. So you may need some sort of level conversion circuitry
-when connecting them to a GPIO line.
-
-Required properties:
- - compatible: value must be "cec-gpio".
- - cec-gpios: gpio that the CEC line is connected to. The line should be
- tagged as open drain.
-
-If the CEC line is associated with an HDMI receiver/transmitter, then the
-following property is also required:
-
- - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
-
-If the CEC line is not associated with an HDMI receiver/transmitter, then
-the following property is optional and can be used for debugging HPD changes:
-
- - hpd-gpios: gpio that the HPD line is connected to.
-
-This property is optional and can be used for debugging changes on the 5V line:
-
- - v5-gpios: gpio that the 5V line is connected to.
-
-Example for the Raspberry Pi 3 where the CEC line is connected to
-pin 26 aka BCM7 aka CE1 on the GPIO pin header, the HPD line is
-connected to pin 11 aka BCM17 and the 5V line is connected to pin
-15 aka BCM22 (some level shifter is needed for the HPD and 5V lines!):
-
-#include <dt-bindings/gpio/gpio.h>
-
-cec-gpio {
- compatible = "cec-gpio";
- cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
- hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
- v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/media/cec.txt b/Documentation/devicetree/bindings/media/cec.txt
deleted file mode 100644
index 22d7aae..0000000
--- a/Documentation/devicetree/bindings/media/cec.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Common bindings for HDMI CEC adapters
-
-- hdmi-phandle: phandle to the HDMI controller.
-
-- needs-hpd: if present the CEC support is only available when the HPD
- is high. Some boards only let the CEC pin through if the HPD is high,
- for example if there is a level converter that uses the HPD to power
- up or down.
diff --git a/Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml b/Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml
new file mode 100644
index 0000000..b1fab53
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/amlogic,meson-gx-ao-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson AO-CEC Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ The Amlogic Meson AO-CEC module is present is Amlogic SoCs and its purpose is
+ to handle communication between HDMI connected devices over the CEC bus.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-ao-cec # GXBB, GXL, GXM, G12A and SM1 AO_CEC_A module
+ - amlogic,meson-g12a-ao-cec # G12A AO_CEC_B module
+ - amlogic,meson-sm1-ao-cec # SM1 AO_CEC_B module
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+allOf:
+ - $ref: cec-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson-gx-ao-cec
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: AO-CEC clock
+
+ clock-names:
+ items:
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson-g12a-ao-cec
+ - amlogic,meson-sm1-ao-cec
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: AO-CEC clock generator source
+
+ clock-names:
+ items:
+ - const: oscin
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - hdmi-phandle
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ cec_AO: cec@100 {
+ compatible = "amlogic,meson-gx-ao-cec";
+ reg = <0x00100 0x14>;
+ interrupts = <199>;
+ clocks = <&clkc_cec>;
+ clock-names = "core";
+ hdmi-phandle = <&hdmi_tx>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/cec-common.yaml b/Documentation/devicetree/bindings/media/cec/cec-common.yaml
new file mode 100644
index 0000000..af6ee5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/cec-common.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/cec-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HDMI CEC Adapters Common Properties
+
+maintainers:
+ - Hans Verkuil <hverkuil@xs4all.nl>
+
+properties:
+ $nodename:
+ pattern: "^cec(@[0-9a-f]+|-[0-9]+)?$"
+
+ hdmi-phandle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the HDMI controller.
+
+ needs-hpd:
+ type: boolean
+ description:
+ The CEC support is only available when the HPD is high. Some boards only
+ let the CEC pin through if the HPD is high, for example if there is a
+ level converter that uses the HPD to power up or down.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
new file mode 100644
index 0000000..64d7ec0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/cec-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HDMI CEC GPIO
+
+maintainers:
+ - Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+description: |
+ The HDMI CEC GPIO module supports CEC implementations where the CEC line is
+ hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
+ to another GPIO line.
+
+ Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
+ 5V lines it is 5.3V. So you may need some sort of level conversion
+ circuitry when connecting them to a GPIO line.
+
+properties:
+ compatible:
+ const: cec-gpio
+
+ cec-gpios:
+ maxItems: 1
+ description:
+ GPIO that the CEC line is connected to. The line should be tagged as open
+ drain.
+
+ hpd-gpios:
+ maxItems: 1
+ description:
+ GPIO that the HPD line is connected to. Used for debugging HPD changes
+ when the CEC line is not associated with an HDMI receiver/transmitter.
+
+ v5-gpios:
+ maxItems: 1
+ description:
+ GPIO that the 5V line is connected to. Used for debugging changes on the
+ 5V line.
+
+required:
+ - compatible
+ - cec-gpios
+
+allOf:
+ - $ref: cec-common.yaml#
+ - if:
+ required:
+ - hdmi-phandle
+ then:
+ properties:
+ hpd-gpios: false
+
+ - if:
+ required:
+ - hpd-gpios
+ then:
+ properties:
+ hdmi-phandle: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ cec {
+ compatible = "cec-gpio";
+ cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
new file mode 100644
index 0000000..369c48f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/nvidia,tegra114-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra HDMI CEC
+
+maintainers:
+ - Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+allOf:
+ - $ref: cec-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra114-cec
+ - nvidia,tegra124-cec
+ - nvidia,tegra210-cec
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cec
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - hdmi-phandle
+ - interrupts
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ cec@70015000 {
+ compatible = "nvidia,tegra124-cec";
+ reg = <0x70015000 0x00001000>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_CEC>;
+ clock-names = "cec";
+ status = "disabled";
+ hdmi-phandle = <&hdmi>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml b/Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml
new file mode 100644
index 0000000..016c8a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/samsung,s5p-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5PV210 and Exynos HDMI CEC
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+
+allOf:
+ - $ref: cec-common.yaml#
+
+properties:
+ compatible:
+ const: samsung,s5p-cec
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: hdmicec
+
+ interrupts:
+ maxItems: 1
+
+ samsung,syscon-phandle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to PMU system controller interface
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - hdmi-phandle
+ - interrupts
+ - samsung,syscon-phandle
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos5420.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ cec@101b0000 {
+ compatible = "samsung,s5p-cec";
+ reg = <0x101B0000 0x200>;
+
+ clocks = <&clock CLK_HDMI_CEC>;
+ clock-names = "hdmicec";
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ hdmi-phandle = <&hdmi>;
+ needs-hpd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml
new file mode 100644
index 0000000..aeddf16
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/st,stih-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STIH4xx HDMI CEC
+
+maintainers:
+ - Alain Volmat <alain.volmat@foss.st.com>
+
+allOf:
+ - $ref: cec-common.yaml#
+
+properties:
+ compatible:
+ const: st,stih-cec
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cec-clk
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: cec-irq
+
+ resets:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - hdmi-phandle
+ - interrupts
+ - resets
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/stih407-resets.h>
+
+ cec@94a087c {
+ compatible = "st,stih-cec";
+ reg = <0x94a087c 0x64>;
+
+ clocks = <&clk_sysin>;
+ clock-names = "cec-clk";
+ hdmi-phandle = <&sti_hdmi>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "cec-irq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cec0_default>;
+ resets = <&softreset STIH407_LPM_SOFTRESET>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
new file mode 100644
index 0000000..2314a9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/st,stm32-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 CEC
+
+maintainers:
+ - Yannick Fertre <yannick.fertre@foss.st.com>
+
+properties:
+ compatible:
+ const: st,stm32-cec
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Module Clock
+ - description: Bus Clock
+
+ clock-names:
+ items:
+ - const: cec
+ - const: hdmi-cec
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+ cec: cec@40006c00 {
+ compatible = "st,stm32-cec";
+ reg = <0x40006c00 0x400>;
+ interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc CEC_K>, <&clk_lse>;
+ clock-names = "cec", "hdmi-cec";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml b/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml
new file mode 100644
index 0000000..84a5e89
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx6ull-pxp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Pixel Pipeline
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+ - Michael Tretter <m.tretter@pengutronix.de>
+
+description:
+ The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine
+ that supports scaling, colorspace conversion, alpha blending, rotation, and
+ pixel conversion via lookup table. Different versions are present on various
+ i.MX SoCs from i.MX23 to i.MX7.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx6ul-pxp
+ - fsl,imx6ull-pxp
+ - fsl,imx7d-pxp
+ - items:
+ - enum:
+ - fsl,imx6sll-pxp
+ - fsl,imx6sx-pxp
+ - const: fsl,imx6ull-pxp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: axi
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sx-pxp
+ - fsl,imx6ul-pxp
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ else:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6ul-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pxp: pxp@21cc000 {
+ compatible = "fsl,imx6ull-pxp";
+ reg = <0x021cc000 0x4000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "axi";
+ clocks = <&clks IMX6UL_CLK_PXP>;
+ };
diff --git a/Documentation/devicetree/bindings/media/fsl-pxp.txt b/Documentation/devicetree/bindings/media/fsl-pxp.txt
deleted file mode 100644
index f8090e0..0000000
--- a/Documentation/devicetree/bindings/media/fsl-pxp.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Freescale Pixel Pipeline
-========================
-
-The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine
-that supports scaling, colorspace conversion, alpha blending, rotation, and
-pixel conversion via lookup table. Different versions are present on various
-i.MX SoCs from i.MX23 to i.MX7.
-
-Required properties:
-- compatible: should be "fsl,<soc>-pxp", where SoC can be one of imx23, imx28,
- imx6dl, imx6sl, imx6sll, imx6ul, imx6sx, imx6ull, or imx7d.
-- reg: the register base and size for the device registers
-- interrupts: the PXP interrupt, two interrupts for imx6ull and imx7d.
-- clock-names: should be "axi"
-- clocks: the PXP AXI clock
-
-Example:
-
-pxp@21cc000 {
- compatible = "fsl,imx6ull-pxp";
- reg = <0x021cc000 0x4000>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "axi";
- clocks = <&clks IMX6UL_CLK_PXP>;
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/ak7375.txt b/Documentation/devicetree/bindings/media/i2c/ak7375.txt
deleted file mode 100644
index aa3e24b..0000000
--- a/Documentation/devicetree/bindings/media/i2c/ak7375.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Asahi Kasei Microdevices AK7375 voice coil lens driver
-
-AK7375 is a camera voice coil lens.
-
-Mandatory properties:
-
-- compatible: "asahi-kasei,ak7375"
-- reg: I2C slave address
diff --git a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
new file mode 100644
index 0000000..22a810f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/asahi-kasei,ak7375.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asahi Kasei Microdevices AK7375 voice coil lens actuator
+
+maintainers:
+ - Tianshu Qiu <tian.shu.qiu@intel.com>
+
+description:
+ AK7375 is a voice coil motor (VCM) camera lens actuator that
+ is controlled over I2C.
+
+properties:
+ compatible:
+ const: asahi-kasei,ak7375
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: VDD supply
+
+ vio-supply:
+ description: I/O pull-up supply
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ak7375: camera-lens@c {
+ compatible = "asahi-kasei,ak7375";
+ reg = <0x0c>;
+
+ vdd-supply = <&vreg_l23a_2p8>;
+ vio-supply = <&vreg_lvs1a_1p8>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
index 63e5b89..af8ada5 100644
--- a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
@@ -13,6 +13,9 @@
The Chrontel CH7322 is a discrete HDMI-CEC controller. It is
programmable through I2C and drives a single CEC line.
+allOf:
+ - $ref: /schemas/media/cec/cec-common.yaml#
+
properties:
compatible:
const: chrontel,ch7322
@@ -40,16 +43,12 @@
if in auto mode.
maxItems: 1
- # see ../cec.txt
- hdmi-phandle:
- description: phandle to the HDMI controller
-
required:
- compatible
- reg
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -58,7 +57,7 @@
i2c {
#address-cells = <1>;
#size-cells = <0>;
- ch7322@75 {
+ cec@75 {
compatible = "chrontel,ch7322";
reg = <0x75>;
interrupts = <47 IRQ_TYPE_EDGE_RISING>;
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 90315e2..0c4213a 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -39,7 +39,7 @@
maxItems: 1
poc-supply:
- description: Regulator providing Power over Coax to the cameras
+ description: Regulator providing Power over Coax to all the ports
enable-gpios:
description: GPIO connected to the \#PWDN pin with inverted polarity
@@ -50,6 +50,21 @@
'#gpio-cells':
const: 2
+ maxim,bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 24, 27, 32 ]
+ description: |
+ The GMSL serial data bus width. This setting is normally controlled by
+ the BWS pin, but may be overridden with this property. The value must
+ match the configuration of the remote serializers.
+
+ maxim,i2c-remote-bus-hz:
+ enum: [ 8470, 28300, 84700, 105000, 173000, 339000, 533000, 837000 ]
+ default: 105000
+ description: |
+ The I2C clock frequency for the remote I2C buses. The value must match
+ the configuration of the remote serializers.
+
maxim,reverse-channel-microvolt:
minimum: 30000
maximum: 200000
@@ -182,21 +197,36 @@
additionalProperties: false
+patternProperties:
+ "^port[0-3]-poc-supply$":
+ description: Regulator providing Power over Coax for a particular port
+
required:
- compatible
- reg
- ports
- i2c-mux
-# If 'maxim,gpio-poc' is present, then 'poc-supply' and 'gpio-controller'
-# are not allowed.
-if:
- required:
- - maxim,gpio-poc
-then:
- properties:
- poc-supply: false
- gpio-controller: false
+allOf:
+ # Only one way of specifying power supplies is allowed: 'maxim,gpio-poc',
+ # 'poc-supply' or per-port poc-supply. Additionally, if 'maxim,gpio-poc' is
+ # present, then 'gpio-controller' isn't allowed.
+ - if:
+ required:
+ - maxim,gpio-poc
+ then:
+ properties:
+ poc-supply: false
+ gpio-controller: false
+ patternProperties:
+ "^port[0-3]-poc-supply$": false
+
+ - if:
+ required:
+ - poc-supply
+ then:
+ patternProperties:
+ "^port[0-3]-poc-supply$": false
additionalProperties: false
@@ -219,6 +249,7 @@
gpio-controller;
#gpio-cells = <2>;
+ maxim,i2c-remote-bus-hz = <339000>;
maxim,reverse-channel-microvolt = <170000>;
ports {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml
new file mode 100644
index 0000000..6e089fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5670.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV5670 5 Megapixels raw image sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+
+description: |-
+ The OV5670 is a 5 Megapixels raw image sensor which provides images in 10-bits
+ RAW BGGR Bayer format on a 2 data lanes MIPI CSI-2 serial interface and is
+ controlled through an I2C compatible control bus.
+
+properties:
+ compatible:
+ const: ovti,ov5670
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: System clock. From 6 to 27 MHz.
+ maxItems: 1
+
+ powerdown-gpios:
+ description: Reference to the GPIO connected to the PWDNB pin. Active low.
+
+ reset-gpios:
+ description: Reference to the GPIO connected to the XSHUTDOWN pin. Active low.
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog circuit power. Typically 2.8V.
+
+ dvdd-supply:
+ description: Digital circuit power. Typically 1.2V.
+
+ dovdd-supply:
+ description: Digital I/O circuit power. Typically 2.8V or 1.8V.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [1, 2]
+
+ clock-noncontinuous: true
+ remote-endpoint: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5670: sensor@36 {
+ compatible = "ovti,ov5670";
+ reg = <0x36>;
+
+ clocks = <&sensor_xclk>;
+
+ port {
+ ov5670_ep: endpoint {
+ remote-endpoint = <&csi_ep>;
+ data-lanes = <1 2>;
+ clock-noncontinuous;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
new file mode 100644
index 0000000..ad07204
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2022 Theobroma Systems Design und Consulting GmbH
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5675.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV5675 CMOS Sensor
+
+maintainers:
+ - Quentin Schulz <quentin.schulz@theobroma-systems.com>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+description: |
+ The Omnivision OV5675 is a high performance, 1/5-inch, 5 megapixel, CMOS
+ image sensor that delivers 2592x1944 at 30fps. It provides full-frame,
+ sub-sampled, and windowed 10-bit MIPI images in various formats via the
+ Serial Camera Control Bus (SCCB) interface.
+
+ This chip is programmable through I2C and two-wire SCCB. The sensor output
+ is available via CSI-2 serial data output (up to 2-lane).
+
+properties:
+ compatible:
+ const: ovti,ov5675
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description:
+ System input clock (aka XVCLK). From 6 to 27 MHz.
+ maxItems: 1
+
+ dovdd-supply:
+ description:
+ Digital I/O voltage supply, 1.8 volts.
+
+ avdd-supply:
+ description:
+ Analog voltage supply, 2.8 volts.
+
+ dvdd-supply:
+ description:
+ Digital core voltage supply, 1.2 volts.
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+ This corresponds to the hardware pin XSHUTDN which is physically
+ active low.
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+
+ # Supports max data transfer of 900 Mbps per lane
+ link-frequencies: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/px30-cru.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5675: camera@36 {
+ compatible = "ovti,ov5675";
+ reg = <0x36>;
+
+ reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cif_clkout_m0>;
+
+ clocks = <&cru SCLK_CIF_OUT>;
+ assigned-clocks = <&cru SCLK_CIF_OUT>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vcc_1v8>;
+ dvdd-supply = <&vcc_1v2>;
+ dovdd-supply = <&vcc_2v8>;
+
+ rotation = <90>;
+ orientation = <0>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <450000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml
new file mode 100644
index 0000000..a65f921
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov8858.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV8858 Image Sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+ - Nicholas Roth <nicholas@rothemail.net>
+
+description: |
+ The OmniVision OV8858 is a color CMOS 8 Megapixels (3264x2448) image sensor
+ controlled through an I2C-compatible SCCB bus. The sensor transmits images
+ on a MIPI CSI-2 output interface with up to 4 data lanes.
+
+properties:
+ compatible:
+ const: ovti,ov8858
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: XVCLK external clock
+
+ clock-names:
+ const: xvclk
+
+ dvdd-supply:
+ description: Digital Domain Power Supply
+
+ avdd-supply:
+ description: Analog Domain Power Supply
+
+ dovdd-supply:
+ description: I/O Domain Power Supply
+
+ powerdown-gpios:
+ description: PWDNB powerdown GPIO (active low)
+
+ reset-gpios:
+ maxItems: 1
+ description: XSHUTDN reset GPIO (active low)
+
+ port:
+ description: MIPI CSI-2 transmitter port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov8858: camera@36 {
+ compatible = "ovti,ov8858";
+ reg = <0x36>;
+
+ clocks = <&cru SCLK_CIF_OUT>;
+ clock-names = "xvclk";
+ assigned-clocks = <&cru SCLK_CIF_OUT>;
+ assigned-clock-rates = <24000000>;
+
+ dovdd-supply = <&vcc1v8_dvp>;
+
+ reset-gpios = <&gpio1 RK_PA4 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&gpio2 RK_PB4 GPIO_ACTIVE_LOW>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml
new file mode 100644
index 0000000..65ad9c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx296.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX296 1/2.8-Inch CMOS Image Sensor
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |-
+ The Sony IMX296 is a 1/2.9-Inch active pixel type CMOS Solid-state image
+ sensor with square pixel array and 1.58 M effective pixels. This chip
+ features a global shutter with variable charge-integration time. It is
+ programmable through I2C and 4-wire interfaces. The sensor output is
+ available via CSI-2 serial data output (1 Lane).
+
+properties:
+ compatible:
+ enum:
+ - sony,imx296
+ - sony,imx296ll
+ - sony,imx296lq
+ description:
+ The IMX296 sensor exists in two different models, a colour variant
+ (IMX296LQ) and a monochrome variant (IMX296LL). The device exposes the
+ model through registers, allowing for auto-detection with a common
+ "sony,imx296" compatible string. However, some camera modules disable the
+ ability to read the sensor model register, which disables this feature.
+ In those cases, the exact model needs to be specified as "sony,imx296ll"
+ or "sony,imx296lq".
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: Input clock (37.125 MHz, 54 MHz or 74.25 MHz)
+ items:
+ - const: inck
+
+ avdd-supply:
+ description: Analog power supply (3.3V)
+
+ dvdd-supply:
+ description: Digital power supply (1.2V)
+
+ ovdd-supply:
+ description: Interface power supply (1.8V)
+
+ reset-gpios:
+ description: Sensor reset (XCLR) GPIO
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - avdd-supply
+ - dvdd-supply
+ - ovdd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx296: camera-sensor@1a {
+ compatible = "sony,imx296";
+ reg = <0x1a>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&gcc 90>;
+ clock-names = "inck";
+
+ avdd-supply = <&camera_vdda_3v3>;
+ dvdd-supply = <&camera_vddd_1v2>;
+ ovdd-supply = <&camera_vddo_1v8>;
+
+ reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
+
+ port {
+ imx296_ep: endpoint {
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
new file mode 100644
index 0000000..ffccf5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx415.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX415 CMOS Image Sensor
+
+maintainers:
+ - Michael Riesch <michael.riesch@wolfvision.net>
+
+description: |-
+ The Sony IMX415 is a diagonal 6.4 mm (Type 1/2.8) CMOS active pixel type
+ solid-state image sensor with a square pixel array and 8.46 M effective
+ pixels. This chip operates with analog 2.9 V, digital 1.1 V, and interface
+ 1.8 V triple power supply, and has low power consumption.
+ The IMX415 is programmable through I2C interface. The sensor output is
+ available via CSI-2 serial data output (two or four lanes).
+
+allOf:
+ - $ref: ../video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: sony,imx415
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Input clock (24 MHz, 27 MHz, 37.125 MHz, 72 MHz or 74.25 MHz)
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog power supply (2.9 V)
+
+ dvdd-supply:
+ description: Digital power supply (1.1 V)
+
+ ovdd-supply:
+ description: Interface power supply (1.8 V)
+
+ reset-gpios:
+ description: Sensor reset (XCLR) GPIO
+ maxItems: 1
+
+ flash-leds: true
+
+ lens-focus: true
+
+ orientation: true
+
+ rotation: true
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - avdd-supply
+ - dvdd-supply
+ - ovdd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx415: camera-sensor@1a {
+ compatible = "sony,imx415";
+ reg = <0x1a>;
+ avdd-supply = <&vcc2v9_cam>;
+ clocks = <&clock_cam>;
+ dvdd-supply = <&vcc1v1_cam>;
+ lens-focus = <&vcm>;
+ orientation = <2>;
+ ovdd-supply = <&vcc1v8_cam>;
+ reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
+ rotation = <180>;
+
+ port {
+ imx415_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&mipi_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
index 4f7b782..358019e 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
@@ -37,6 +37,9 @@
items:
- const: mclk
+ power-domains:
+ maxItems: 1
+
port:
$ref: /schemas/graph.yaml#/properties/port
@@ -50,6 +53,18 @@
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mq-csi
+ - fsl,imx8mm-csi
+ then:
+ required:
+ - power-domains
+
examples:
- |
#include <dt-bindings/clock/imx7d-clock.h>
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt b/Documentation/devicetree/bindings/media/s5p-cec.txt
deleted file mode 100644
index e847291..0000000
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Samsung HDMI CEC driver
-
-The HDMI CEC module is present is Samsung SoCs and its purpose is to
-handle communication between HDMI connected devices over the CEC bus.
-
-Required properties:
- - compatible : value should be following
- "samsung,s5p-cec"
-
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
-
- - interrupts : HDMI CEC interrupt number to the CPU.
- - clocks : from common clock binding: handle to HDMI CEC clock.
- - clock-names : from common clock binding: must contain "hdmicec",
- corresponding to entry in the clocks property.
- - samsung,syscon-phandle - phandle to the PMU system controller
- - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
-
-Optional:
- - needs-hpd : if present the CEC support is only available when the HPD
- is high. See cec.txt for more details.
-
-Example:
-
-hdmicec: cec@100b0000 {
- compatible = "samsung,s5p-cec";
- reg = <0x100B0000 0x200>;
- interrupts = <0 114 0>;
- clocks = <&clock CLK_HDMI_CEC>;
- clock-names = "hdmicec";
- samsung,syscon-phandle = <&pmu_system_controller>;
- hdmi-phandle = <&hdmi>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_cec>;
-};
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt b/Documentation/devicetree/bindings/media/stih-cec.txt
deleted file mode 100644
index ece0832..0000000
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-STMicroelectronics STIH4xx HDMI CEC driver
-
-Required properties:
- - compatible : value should be "st,stih-cec"
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
- - clocks : from common clock binding: handle to HDMI CEC clock
- - interrupts : HDMI CEC interrupt number to the CPU.
- - pinctrl-names: Contains only one value - "default"
- - pinctrl-0: Specifies the pin control groups used for CEC hardware.
- - resets: Reference to a reset controller
- - hdmi-phandle: Phandle to the HDMI controller, see also cec.txt.
-
-Example for STIH407:
-
-sti-cec@94a087c {
- compatible = "st,stih-cec";
- reg = <0x94a087c 0x64>;
- clocks = <&clk_sysin>;
- clock-names = "cec-clk";
- interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
- interrupt-names = "cec-irq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_cec0_default>;
- resets = <&softreset STIH407_LPM_SOFTRESET>;
- hdmi-phandle = <&hdmi>;
-};
diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt b/Documentation/devicetree/bindings/media/tegra-cec.txt
deleted file mode 100644
index c503f06..0000000
--- a/Documentation/devicetree/bindings/media/tegra-cec.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Tegra HDMI CEC hardware
-
-The HDMI CEC module is present in Tegra SoCs and its purpose is to
-handle communication between HDMI connected devices over the CEC bus.
-
-Required properties:
- - compatible : value should be one of the following:
- "nvidia,tegra114-cec"
- "nvidia,tegra124-cec"
- "nvidia,tegra210-cec"
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
- - interrupts : HDMI CEC interrupt number to the CPU.
- - clocks : from common clock binding: handle to HDMI CEC clock.
- - clock-names : from common clock binding: must contain "cec",
- corresponding to the entry in the clocks property.
- - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
-
-Example:
-
-cec@70015000 {
- compatible = "nvidia,tegra124-cec";
- reg = <0x0 0x70015000 0x0 0x00001000>;
- interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA124_CLK_CEC>;
- clock-names = "cec";
-};
diff --git a/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml
new file mode 100644
index 0000000..188db82
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel IXP4xx Expansion Bus Controller
+
+description: |
+ The IXP4xx expansion bus controller handles access to devices on the
+ memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
+ including IXP42x, IXP43x, IXP45x and IXP46x.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ $nodename:
+ pattern: '^bus@[0-9a-f]+$'
+
+ compatible:
+ items:
+ - enum:
+ - intel,ixp42x-expansion-bus-controller
+ - intel,ixp43x-expansion-bus-controller
+ - intel,ixp45x-expansion-bus-controller
+ - intel,ixp46x-expansion-bus-controller
+ - const: syscon
+
+ reg:
+ description: Control registers for the expansion bus, these are not
+ inside the memory range handled by the expansion bus.
+ maxItems: 1
+
+ native-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: The IXP4xx has a peculiar MMIO access scheme, as it changes
+ the access pattern for words (swizzling) on the bus depending on whether
+ the SoC is running in big-endian or little-endian mode. Thus the
+ registers must always be accessed using native endianness.
+
+ "#address-cells":
+ description: |
+ The first cell is the chip select number.
+ The second cell is the address offset within the bank.
+ const: 2
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+ dma-ranges: true
+
+patternProperties:
+ "^.*@[0-7],[0-9a-f]+$":
+ description: Devices attached to chip selects are represented as
+ subnodes.
+ type: object
+ $ref: /schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
+
+required:
+ - compatible
+ - reg
+ - native-endian
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - dma-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ bus@50000000 {
+ compatible = "intel,ixp42x-expansion-bus-controller", "syscon";
+ reg = <0xc4000000 0x28>;
+ native-endian;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x50000000 0x01000000>,
+ <1 0x0 0x51000000 0x01000000>;
+ dma-ranges = <0 0x0 0x50000000 0x01000000>,
+ <1 0x0 0x51000000 0x01000000>;
+ flash@0,0 {
+ compatible = "intel,ixp4xx-flash", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 0x00000000 0x1000000>;
+ intel,ixp4xx-eb-t3 = <3>;
+ intel,ixp4xx-eb-cycle-type = <0>;
+ intel,ixp4xx-eb-byte-access-on-halfword = <1>;
+ intel,ixp4xx-eb-write-enable = <1>;
+ intel,ixp4xx-eb-byte-access = <0>;
+ };
+ serial@1,0 {
+ compatible = "exar,xr16l2551", "ns8250";
+ reg = <1 0x00000000 0x10>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <1843200>;
+ intel,ixp4xx-eb-t3 = <3>;
+ intel,ixp4xx-eb-cycle-type = <1>;
+ intel,ixp4xx-eb-write-enable = <1>;
+ intel,ixp4xx-eb-byte-access = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml
new file mode 100644
index 0000000..d1479a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral properties for Intel IXP4xx Expansion Bus
+
+description:
+ The IXP4xx expansion bus controller handles access to devices on the
+ memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
+ including IXP42x, IXP43x, IXP45x and IXP46x.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ intel,ixp4xx-eb-t1:
+ description: Address timing, extend address phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ intel,ixp4xx-eb-t2:
+ description: Setup chip select timing, extend setup phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ intel,ixp4xx-eb-t3:
+ description: Strobe timing, extend strobe phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+
+ intel,ixp4xx-eb-t4:
+ description: Hold timing, extend hold phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ intel,ixp4xx-eb-t5:
+ description: Recovery timing, extend recovery phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+
+ intel,ixp4xx-eb-cycle-type:
+ description: The type of cycles to use on the expansion bus for this
+ chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ intel,ixp4xx-eb-byte-access-on-halfword:
+ description: Allow byte read access on half word devices.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-hpi-hrdy-pol-high:
+ description: Set HPI HRDY polarity to active high when using HPI.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-mux-address-and-data:
+ description: Multiplex address and data on the data bus.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-ahb-split-transfers:
+ description: Enable AHB split transfers.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-write-enable:
+ description: Enable write cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-byte-access:
+ description: Expansion bus uses only 8 bits. The default is to use
+ 16 bits.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
index 53ae995..5acfcad1 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
@@ -34,5 +34,6 @@
# The controller specific properties go here.
allOf:
- $ref: st,stm32-fmc2-ebi-props.yaml#
+ - $ref: intel,ixp4xx-expansion-peripheral-props.yaml#
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
index 4f30173..bc94069 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
@@ -90,7 +90,7 @@
interrupt-controller:
description: |
- The GPMC driver implements and interrupt controller for
+ The GPMC driver implements an interrupt controller for
the NAND events "fifoevent" and "termcount" plus the
rising/falling edges on the GPMC_WAIT pins.
The interrupt number mapping is as follows
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml
new file mode 100644
index 0000000..ca9fc74
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynqmp OCM(On-Chip Memory) Controller
+
+maintainers:
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+description: |
+ The OCM supports 64-bit wide ECC functionality to detect multi-bit errors
+ and recover from a single-bit memory fault.On a write, if all bytes are
+ being written, the ECC is generated and written into the ECC RAM along with
+ the write-data that is written into the data RAM. If one or more bytes are
+ not written, then the read operation results in an correctable error or
+ uncorrectable error.
+
+properties:
+ compatible:
+ const: xlnx,zynqmp-ocmc-1.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ memory-controller@ff960000 {
+ compatible = "xlnx,zynqmp-ocmc-1.0";
+ reg = <0xff960000 0x1000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
index 3d5efa5..cdf1d71 100644
--- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
+++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
@@ -33,6 +33,9 @@
- description:
For implementations of the EC connected through RPMSG.
const: google,cros-ec-rpmsg
+ - description:
+ For implementations of the EC connected through UART.
+ const: google,cros-ec-uart
controller-data: true
@@ -187,6 +190,15 @@
properties:
mediatek,rpmsg-name: false
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - google,cros-ec-rpmsg
+ - google,cros-ec-uart
+ then:
required:
- reg
- interrupts
@@ -299,4 +311,12 @@
vdd-supply = <&pp3300_fp_mcu>;
};
};
+
+ # Example for UART
+ - |
+ serial {
+ cros-ec {
+ compatible = "google,cros-ec-uart";
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
new file mode 100644
index 0000000..837a770
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6357 PMIC
+
+maintainers:
+ - Flora Fu <flora.fu@mediatek.com>
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+description: |
+ MT6357 is a power management system chip containing 5 buck
+ converters and 29 LDOs. Supported features are audio codec,
+ USB battery charging, fuel gauge, RTC
+
+ This is a multifunction device with the following sub modules:
+ - Regulator
+ - RTC
+ - Keys
+
+ It is interfaced to host controller using SPI interface by a proprietary hardware
+ called PMIC wrapper or pwrap. This MFD is a child device of pwrap.
+ See the following for pwrap node definitions:
+ Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
+
+properties:
+ compatible:
+ const: mediatek,mt6357
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ regulators:
+ type: object
+ $ref: /schemas/regulator/mediatek,mt6357-regulator.yaml
+ description:
+ List of MT6357 BUCKs and LDOs regulators.
+
+ rtc:
+ type: object
+ $ref: /schemas/rtc/rtc.yaml#
+ description:
+ MT6357 Real Time Clock.
+ properties:
+ compatible:
+ const: mediatek,mt6357-rtc
+ start-year: true
+ required:
+ - compatible
+
+ keys:
+ type: object
+ $ref: /schemas/input/mediatek,pmic-keys.yaml
+ description:
+ MT6357 power and home keys.
+
+required:
+ - compatible
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pwrap {
+ pmic {
+ compatible = "mediatek,mt6357";
+
+ interrupt-parent = <&pio>;
+ interrupts = <145 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ mt6357_vproc_reg: buck-vproc {
+ regulator-name = "vproc";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+
+ // ...
+
+ mt6357_vusb33_reg: ldo-vusb33 {
+ regulator-name = "vusb33";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ };
+
+ rtc {
+ compatible = "mediatek,mt6357-rtc";
+ };
+
+ keys {
+ compatible = "mediatek,mt6357-keys";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
index 1d1fee1..8bd1abf 100644
--- a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
+++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
@@ -57,6 +57,15 @@
enum:
- mscc,ocelot-miim
+ "^ethernet-switch@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/net/mscc,vsc7514-switch.yaml
+ unevaluatedProperties: false
+ properties:
+ compatible:
+ enum:
+ - mscc,vsc7512-switch
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 518986c4..294693a 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -13,7 +13,7 @@
It is interfaced to host controller using SPI interface by a proprietary hardware
called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
See the following for pwarp node definitions:
-../soc/mediatek/pwrap.txt
+../soc/mediatek/mediatek,pwrap.yaml
This document describes the binding for MFD device and its sub module.
diff --git a/Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml b/Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml
new file mode 100644
index 0000000..b1ade64
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/nxp,bbnsm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Battery-Backed Non-Secure Module
+
+maintainers:
+ - Jacky Bai <ping.bai@nxp.com>
+
+description: |
+ NXP BBNSM serves as non-volatile logic and storage for the system.
+ it Intergrates RTC & ON/OFF control.
+ The RTC can retain its state and continues counting even when the
+ main chip is power down. A time alarm is generated once the most
+ significant 32 bits of the real-time counter match the value in the
+ Time Alarm register.
+ The ON/OFF logic inside the BBNSM allows for connecting directly to
+ a PMIC or other voltage regulator device. both smart PMIC mode and
+ Dumb PMIC mode supported.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nxp,imx93-bbnsm
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ rtc:
+ type: object
+ $ref: /schemas/rtc/rtc.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - nxp,imx93-bbnsm-rtc
+
+ interrupts:
+ maxItems: 1
+
+ start-year: true
+
+ required:
+ - compatible
+ - interrupts
+
+ additionalProperties: false
+
+ pwrkey:
+ type: object
+ $ref: /schemas/input/input.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - nxp,imx93-bbnsm-pwrkey
+
+ interrupts:
+ maxItems: 1
+
+ linux,code: true
+
+ required:
+ - compatible
+ - interrupts
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - rtc
+ - pwrkey
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/linux-event-codes.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bbnsm: bbnsm@44440000 {
+ compatible = "nxp,imx93-bbnsm", "syscon", "simple-mfd";
+ reg = <0x44440000 0x10000>;
+
+ bbnsm_rtc: rtc {
+ compatible = "nxp,imx93-bbnsm-rtc";
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ bbnsm_pwrkey: pwrkey {
+ compatible = "nxp,imx93-bbnsm-pwrkey";
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ linux,code = <KEY_POWER>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index aa1eaa5..a0d8c30 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -64,8 +64,8 @@
Properties for children:
The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
-See Documentation/devicetree/bindings/usb/ehci-omap.txt and
-Documentation/devicetree/bindings/usb/ohci-omap3.txt.
+See Documentation/devicetree/bindings/usb/generic-ehci.yaml and
+Documentation/devicetree/bindings/usb/generic-ohci.yaml.
Example for OMAP4:
@@ -78,14 +78,14 @@
ranges;
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 76 0x4>;
};
usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 77 0x4>;
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
index 37d16e1..adf8824 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -44,6 +44,7 @@
- qcom,pm8004
- qcom,pm8005
- qcom,pm8009
+ - qcom,pm8010
- qcom,pm8019
- qcom,pm8028
- qcom,pm8110
@@ -55,6 +56,10 @@
- qcom,pm8350
- qcom,pm8350b
- qcom,pm8350c
+ - qcom,pm8550
+ - qcom,pm8550b
+ - qcom,pm8550ve
+ - qcom,pm8550vs
- qcom,pm8841
- qcom,pm8909
- qcom,pm8916
@@ -71,10 +76,12 @@
- qcom,pmi8998
- qcom,pmk8002
- qcom,pmk8350
+ - qcom,pmk8550
- qcom,pmm8155au
- qcom,pmp8074
- qcom,pmr735a
- qcom,pmr735b
+ - qcom,pmr735d
- qcom,pms405
- qcom,pmx55
- qcom,pmx65
diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
index adcae6c..2eeebe9 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
@@ -28,9 +28,11 @@
- qcom,sm8150-tcsr
- qcom,tcsr-apq8064
- qcom,tcsr-apq8084
+ - qcom,tcsr-ipq5332
- qcom,tcsr-ipq6018
- qcom,tcsr-ipq8064
- qcom,tcsr-mdm9615
+ - qcom,tcsr-msm8226
- qcom,tcsr-msm8660
- qcom,tcsr-msm8916
- qcom,tcsr-msm8953
diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
deleted file mode 100644
index b823b86..0000000
--- a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-Qualcomm Resource Power Manager (RPM)
-
-This driver is used to interface with the Resource Power Manager (RPM) found in
-various Qualcomm platforms. The RPM allows each component in the system to vote
-for state of the system resources, such as clocks, regulators and bus
-frequencies.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,rpm-apq8064"
- "qcom,rpm-msm8660"
- "qcom,rpm-msm8960"
- "qcom,rpm-ipq8064"
- "qcom,rpm-mdm9615"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: base address and size of the RPM's message ram
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: three entries specifying the RPM's:
- 1. acknowledgement interrupt
- 2. error interrupt
- 3. wakeup interrupt
-
-- interrupt-names:
- Usage: required
- Value type: <string-array>
- Definition: must be the three strings "ack", "err" and "wakeup", in order
-
-- qcom,ipc:
- Usage: required
- Value type: <prop-encoded-array>
-
- Definition: three entries specifying the outgoing ipc bit used for
- signaling the RPM:
- - phandle to a syscon node representing the apcs registers
- - u32 representing offset to the register within the syscon
- - u32 representing the ipc bit within the register
-
-
-= SUBNODES
-
-The RPM exposes resources to its subnodes. The below bindings specify the set
-of valid subnodes that can operate on these resources.
-
-== Regulators
-
-Regulator nodes are identified by their compatible:
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,rpm-pm8058-regulators"
- "qcom,rpm-pm8901-regulators"
- "qcom,rpm-pm8921-regulators"
- "qcom,rpm-pm8018-regulators"
- "qcom,rpm-smb208-regulators"
-
-- vdd_l0_l1_lvs-supply:
-- vdd_l2_l11_l12-supply:
-- vdd_l3_l4_l5-supply:
-- vdd_l6_l7-supply:
-- vdd_l8-supply:
-- vdd_l9-supply:
-- vdd_l10-supply:
-- vdd_l13_l16-supply:
-- vdd_l14_l15-supply:
-- vdd_l17_l18-supply:
-- vdd_l19_l20-supply:
-- vdd_l21-supply:
-- vdd_l22-supply:
-- vdd_l23_l24_l25-supply:
-- vdd_ncp-supply:
-- vdd_s0-supply:
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
- Usage: optional (pm8058 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- lvs0_in-supply:
-- lvs1_in-supply:
-- lvs2_in-supply:
-- lvs3_in-supply:
-- mvs_in-supply:
-- vdd_l0-supply:
-- vdd_l1-supply:
-- vdd_l2-supply:
-- vdd_l3-supply:
-- vdd_l4-supply:
-- vdd_l5-supply:
-- vdd_l6-supply:
-- vdd_s0-supply:
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
- Usage: optional (pm8901 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- vdd_l1_l2_l12_l18-supply:
-- vdd_l3_l15_l17-supply:
-- vdd_l4_l14-supply:
-- vdd_l5_l8_l16-supply:
-- vdd_l6_l7-supply:
-- vdd_l9_l11-supply:
-- vdd_l10_l22-supply:
-- vdd_l21_l23_l29-supply:
-- vdd_l24-supply:
-- vdd_l25-supply:
-- vdd_l26-supply:
-- vdd_l27-supply:
-- vdd_l28-supply:
-- vdd_ncp-supply:
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s4-supply:
-- vdd_s5-supply:
-- vdd_s6-supply:
-- vdd_s7-supply:
-- vdd_s8-supply:
-- vin_5vs-supply:
-- vin_lvs1_3_6-supply:
-- vin_lvs2-supply:
-- vin_lvs4_5_7-supply:
- Usage: optional (pm8921 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- vin_lvs1-supply:
-- vdd_l7-supply:
-- vdd_l8-supply:
-- vdd_l9_l10_l11_l12-supply:
- Usage: optional (pm8018 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-The regulator node houses sub-nodes for each regulator within the device. Each
-sub-node is identified using the node's name, with valid values listed for each
-of the pmics below.
-
-pm8058:
- l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15,
- l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4,
- lvs0, lvs1, ncp
-
-pm8901:
- l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3,
- mvs
-
-pm8921:
- s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
- l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28,
- l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch,
- ncp
-
-pm8018:
- s1, s2, s3, s4, s5, , l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
- l12, l14, lvs1
-
-smb208:
- s1a, s1b, s2a, s2b
-
-The content of each sub-node is defined by the standard binding for regulators -
-see regulator.txt - with additional custom properties described below:
-
-=== Switch-mode Power Supply regulator custom properties
-
-- bias-pull-down:
- Usage: optional
- Value type: <empty>
- Definition: enable pull down of the regulator when inactive
-
-- qcom,switch-mode-frequency:
- Usage: required
- Value type: <u32>
- Definition: Frequency (Hz) of the switch-mode power supply;
- must be one of:
- 19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
- 2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
- 1480000, 1370000, 1280000, 1200000
-
-- qcom,force-mode:
- Usage: optional (default if no other qcom,force-mode is specified)
- Value type: <u32>
- Definition: indicates that the regulator should be forced to a
- particular mode, valid values are:
- QCOM_RPM_FORCE_MODE_NONE - do not force any mode
- QCOM_RPM_FORCE_MODE_LPM - force into low power mode
- QCOM_RPM_FORCE_MODE_HPM - force into high power mode
- QCOM_RPM_FORCE_MODE_AUTO - allow regulator to automatically
- select its own mode based on
- realtime current draw, only for:
- pm8921 smps and ftsmps
-
-- qcom,power-mode-hysteretic:
- Usage: optional
- Value type: <empty>
- Definition: select that the power supply should operate in hysteretic
- mode, instead of the default pwm mode
-
-=== Low-dropout regulator custom properties
-
-- bias-pull-down:
- Usage: optional
- Value type: <empty>
- Definition: enable pull down of the regulator when inactive
-
-- qcom,force-mode:
- Usage: optional
- Value type: <u32>
- Definition: indicates that the regulator should not be forced to any
- particular mode, valid values are:
- QCOM_RPM_FORCE_MODE_NONE - do not force any mode
- QCOM_RPM_FORCE_MODE_LPM - force into low power mode
- QCOM_RPM_FORCE_MODE_HPM - force into high power mode
- QCOM_RPM_FORCE_MODE_BYPASS - set regulator to use bypass
- mode, i.e. to act as a switch
- and not regulate, only for:
- pm8921 pldo, nldo and nldo1200
-
-=== Negative Charge Pump custom properties
-
-- qcom,switch-mode-frequency:
- Usage: required
- Value type: <u32>
- Definition: Frequency (Hz) of the switch mode power supply;
- must be one of:
- 19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
- 2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
- 1480000, 1370000, 1280000, 1200000
-
-= EXAMPLE
-
- #include <dt-bindings/mfd/qcom-rpm.h>
-
- rpm@108000 {
- compatible = "qcom,rpm-msm8960";
- reg = <0x108000 0x1000>;
- qcom,ipc = <&apcs 0x8 2>;
-
- interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
- interrupt-names = "ack", "err", "wakeup";
-
- regulators {
- compatible = "qcom,rpm-pm8921-regulators";
- vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
-
- s1 {
- regulator-min-microvolt = <1225000>;
- regulator-max-microvolt = <1225000>;
-
- bias-pull-down;
-
- qcom,switch-mode-frequency = <3200000>;
- };
-
- pm8921_s4: s4 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
-
- qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
- };
- };
- };
-
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 1b01bd0..c828c4f 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -38,6 +38,7 @@
- allwinner,sun8i-h3-system-controller
- allwinner,sun8i-v3s-system-controller
- allwinner,sun50i-a64-system-controller
+ - amd,pensando-elba-syscon
- brcm,cru-clkset
- freecom,fsg-cs2-system-controller
- fsl,imx93-aonmix-ns-syscfg
@@ -46,10 +47,12 @@
- hisilicon,hi6220-sramctrl
- hisilicon,pcie-sas-subctrl
- hisilicon,peri-subctrl
+ - hpe,gxp-sysreg
- intel,lgm-syscon
- marvell,armada-3700-usb2-host-misc
- mediatek,mt8135-pctl-a-syscfg
- mediatek,mt8135-pctl-b-syscfg
+ - mediatek,mt8365-syscfg
- microchip,lan966x-cpu-syscon
- microchip,sparx5-cpu-syscon
- mstar,msc313-pmsleep
@@ -64,12 +67,6 @@
- rockchip,rk3568-qos
- rockchip,rk3588-qos
- rockchip,rv1126-qos
- - samsung,exynos3-sysreg
- - samsung,exynos4-sysreg
- - samsung,exynos5-sysreg
- - samsung,exynos5433-sysreg
- - samsung,exynos850-sysreg
- - samsung,exynosautov9-sysreg
- const: syscon
@@ -87,6 +84,9 @@
on the device.
enum: [1, 2, 4, 8]
+ resets:
+ maxItems: 1
+
hwlocks:
maxItems: 1
description:
diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml
new file mode 100644
index 0000000..1b6020e
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,tmr-inject.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Triple Modular Redundancy(TMR) Inject IP
+
+maintainers:
+ - Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
+
+description: |
+ The Triple Modular Redundancy(TMR) Inject core provides functional fault
+ injection by changing selected MicroBlaze instructions, which provides the
+ possibility to verify that the TMR subsystem error detection and fault
+ recovery logic is working properly.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,tmr-inject-1.0
+
+ reg:
+ maxItems: 1
+
+ xlnx,magic:
+ minimum: 0
+ maximum: 255
+ description: |
+ Magic number, When configured it allows the controller to perform
+ recovery.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - xlnx,magic
+
+additionalProperties: false
+
+examples:
+ - |
+ fault-inject@44a30000 {
+ compatible = "xlnx,tmr-inject-1.0";
+ reg = <0x44a10000 0x10000>;
+ xlnx,magic = <0x46>;
+ };
diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml
new file mode 100644
index 0000000..27de121
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Triple Modular Redundancy(TMR) Manager IP
+
+maintainers:
+ - Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
+
+description: |
+ The Triple Modular Redundancy(TMR) Manager is responsible for handling the
+ TMR subsystem state, including fault detection and error recovery. The core
+ is triplicated in each of the sub-blocks in the TMR subsystem, and provides
+ majority voting of its internal state.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,tmr-manager-1.0
+
+ reg:
+ maxItems: 1
+
+ xlnx,magic1:
+ minimum: 0
+ maximum: 255
+ description:
+ Magic byte 1, When configured it allows the controller to perform
+ recovery.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - xlnx,magic1
+
+additionalProperties: false
+
+examples:
+ - |
+ tmr-manager@44a10000 {
+ compatible = "xlnx,tmr-manager-1.0";
+ reg = <0x44a10000 0x10000>;
+ xlnx,magic1 = <0x46>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
index 02ecc93..0ccd632 100644
--- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
@@ -7,7 +7,7 @@
title: Allwinner A10 MMC Controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
new file mode 100644
index 0000000..bc403ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic SD / eMMC controller for S905/GXBB family SoCs
+
+description:
+ The MMC 5.1 compliant host controller on Amlogic provides the
+ interface for SD, eMMC and SDIO devices
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-axg-mmc
+ - items:
+ - const: amlogic,meson-gx-mmc
+ - const: amlogic,meson-gxbb-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: mmc controller instance
+ - description: card detect
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: core
+ - const: clkin0
+ - const: clkin1
+
+ resets:
+ maxItems: 1
+
+ amlogic,dram-access-quirk:
+ type: boolean
+ description:
+ set when controller's internal DMA engine cannot access the DRAM memory,
+ like on the G12A dedicated SDIO controller.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mmc@70000 {
+ compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
+ reg = <0x70000 0x2000>;
+ interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clk_mmc>, <&xtal>, <&clk_div>;
+ clock-names = "core", "clkin0", "clkin1";
+ pinctrl-0 = <&emm_pins>;
+ resets = <&reset_mmc>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
deleted file mode 100644
index ccc5358..0000000
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Amlogic SD / eMMC controller for S905/GXBB family SoCs
-
-The MMC 5.1 compliant host controller on Amlogic provides the
-interface for SD, eMMC and SDIO devices.
-
-This file documents the properties in addition to those available in
-the MMC core bindings, documented by mmc.txt.
-
-Required properties:
-- compatible : contains one of:
- - "amlogic,meson-gx-mmc"
- - "amlogic,meson-gxbb-mmc"
- - "amlogic,meson-gxl-mmc"
- - "amlogic,meson-gxm-mmc"
- - "amlogic,meson-axg-mmc"
-- clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
-- clock-names: Should contain the following:
- "core" - Main peripheral bus clock
- "clkin0" - Parent clock of internal mux
- "clkin1" - Other parent clock of internal mux
- The driver has an internal mux clock which switches between clkin0 and clkin1 depending on the
- clock rate requested by the MMC core.
-- resets : phandle of the internal reset line
-
-Optional properties:
-- amlogic,dram-access-quirk: set when controller's internal DMA engine cannot access the
- DRAM memory, like on the G12A dedicated SDIO controller.
-
-Example:
-
- sd_emmc_a: mmc@70000 {
- compatible = "amlogic,meson-gxbb-mmc";
- reg = <0x0 0x70000 0x0 0x2000>;
- interrupts = < GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clkc CLKID_SD_EMMC_A>, <&xtal>, <&clkc CLKID_FCLK_DIV2>;
- clock-names = "core", "clkin0", "clkin1";
- pinctrl-0 = <&emmc_pins>;
- resets = <&reset RESET_SD_EMMC_A>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
index 1c391be..1a6cda8 100644
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
@@ -7,7 +7,7 @@
title: Amlogic Meson SDHC controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Martin Blumenstingl <martin.blumenstingl@googlemail.com>
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
index 4053de7..8296c34 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arasan SDHCI Controller
@@ -10,7 +10,7 @@
- Adrian Hunter <adrian.hunter@intel.com>
allOf:
- - $ref: "mmc-controller.yaml#"
+ - $ref: mmc-controller.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
index 8b1a0fd..adacd05 100644
--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -29,6 +29,9 @@
clocks:
maxItems: 1
+ resets:
+ maxItems: 1
+
# PHY DLL input delays:
# They are used to delay the data valid window, and align the window to
# sampling clock. The delay starts from 5ns (for delay parameter equal to 0)
@@ -36,43 +39,43 @@
cdns,phy-input-delay-sd-highspeed:
description: Value of the delay in the input path for SD high-speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-legacy:
description: Value of the delay in the input path for legacy timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-sdr12:
description: Value of the delay in the input path for SD UHS SDR12 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-sdr25:
description: Value of the delay in the input path for SD UHS SDR25 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-sdr50:
description: Value of the delay in the input path for SD UHS SDR50 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-ddr50:
description: Value of the delay in the input path for SD UHS DDR50 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-mmc-highspeed:
description: Value of the delay in the input path for MMC high-speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
@@ -83,7 +86,7 @@
# Each delay property represents the fraction of the clock period.
# The approximate delay value will be
# (<delay property value>/128)*sdmclk_clock_period.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
@@ -91,7 +94,7 @@
description: |
Value of the delay introduced on the sdclk output for all modes except
HS200, HS400 and HS400_ES.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7f
@@ -99,7 +102,7 @@
description: |
Value of the delay introduced on the sdclk output for HS200, HS400 and
HS400_ES speed modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7f
@@ -107,7 +110,7 @@
description: |
Value of the delay introduced on the dat_strobe input used in
HS400 / HS400_ES speed modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7f
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index dc6256f..7f721fb 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -10,7 +10,7 @@
- Shawn Guo <shawnguo@kernel.org>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
description: |
The Enhanced Secure Digital Host Controller on Freescale i.MX family
@@ -29,15 +29,24 @@
- fsl,imx53-esdhc
- fsl,imx6q-usdhc
- fsl,imx6sl-usdhc
- - fsl,imx6sll-usdhc
- fsl,imx6sx-usdhc
- - fsl,imx6ull-usdhc
- fsl,imx7d-usdhc
- fsl,imx7ulp-usdhc
- fsl,imx8mm-usdhc
- fsl,imxrt1050-usdhc
- nxp,s32g2-usdhc
- items:
+ - const: fsl,imx50-esdhc
+ - const: fsl,imx53-esdhc
+ - items:
+ - enum:
+ - fsl,imx6sll-usdhc
+ - fsl,imx6ull-usdhc
+ - const: fsl,imx6sx-usdhc
+ - items:
+ - const: fsl,imx7d-usdhc
+ - const: fsl,imx6sl-usdhc
+ - items:
- enum:
- fsl,imx8mq-usdhc
- const: fsl,imx7d-usdhc
@@ -98,12 +107,12 @@
Specify the number of delay cells for override mode.
This is used to set the clock delay for DLL(Delay Line) on override mode
to select a proper data sampling window in case the clock quality is not good
- due to signal path is too long on the board. Please refer to eSDHC/uSDHC
+ because the signal path is too long on the board. Please refer to eSDHC/uSDHC
chapter, DLL (Delay Line) section in RM for details.
default: 0
voltage-ranges:
- $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
description: |
Specify the voltage range in case there are software transparent level
shifters on the outputs of the controller. Two cells are required, first
@@ -127,7 +136,7 @@
Specify the increasing delay cell steps in tuning procedure.
The uSDHC use one delay cell as default increasing step to do tuning process.
This property allows user to change the tuning step to more than one delay
- cells which is useful for some special boards or cards when the default
+ cell which is useful for some special boards or cards when the default
tuning step can't find the proper delay window within limited tuning retries.
default: 0
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
index ffa1627..221f5bc 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
@@ -10,7 +10,7 @@
- Markus Pargmann <mpa@pengutronix.de>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
index fa6cfe0..1f63faf 100644
--- a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
@@ -7,7 +7,7 @@
title: Microchip Sparx5 Mobile Storage Host Controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Lars Povlsen <lars.povlsen@microchip.com>
@@ -35,7 +35,7 @@
microchip,clock-delay:
description: Delay clock to card to meet setup time requirements.
Each step increase by 1.25ns.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 15
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml
index 911a599..588be73 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml
@@ -41,7 +41,7 @@
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- sdhci0_pwrseq {
+ pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
};
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
index 3397dbf..b35e00e 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
@@ -35,7 +35,7 @@
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- wifi_pwrseq: wifi_pwrseq {
+ pwrseq {
compatible = "mmc-pwrseq-sd8787";
powerdown-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
reset-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
index 64e3644..00feaaf 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
@@ -55,7 +55,7 @@
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- sdhci0_pwrseq {
+ pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
clocks = <&clk_32768_ck>;
diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml
index c0662ce..36acc40 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml
@@ -10,7 +10,7 @@
- Ulf Hansson <ulf.hansson@linaro.org>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
- $ref: /schemas/spi/spi-peripheral-props.yaml
description: |
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
index bec8f8c..32e512a 100644
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
@@ -17,7 +17,7 @@
and the properties used by the mxsmmc driver.
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
index fe02702..72987f0 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
@@ -82,8 +82,7 @@
iommus:
maxItems: 1
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
@@ -100,53 +99,53 @@
The DQS trim values are only used on controllers which support HS400
timing. Only SDMMC4 on Tegra210 and Tegra186 supports HS400.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,default-trim:
description: Specify the default outbound clock trimmer value.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,dqs-trim:
description: Specify DQS trim value for HS400 timing.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-1v8:
description: Specify drive strength calibration offsets for 1.8 V
signaling modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-1v8-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 1.8 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-3v3:
description: Specify drive strength calibration offsets for 3.3 V
signaling modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-3v3-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 3.3 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-sdr104:
description: Specify drive strength calibration offsets for SDR104 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-hs400:
description: Specify drive strength calibration offsets for HS400 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-1v8:
description: Specify drive strength calibration offsets for 1.8 V
signaling modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-1v8-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 1.8 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-3v3:
description: Specify drive strength calibration offsets for 3.3 V
@@ -158,25 +157,25 @@
refer to the reference manual of the SoC for correct values. The SDR104
and HS400 timing specific values are used in corresponding modes if
specified.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-3v3-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 3.3 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-sdr104:
description: Specify drive strength calibration offsets for SDR104 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-hs400:
description: Specify drive strength calibration offsets for HS400 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,only-1-8v:
description: The presence of this property indicates that the controller
operates at a 1.8 V fixed I/O voltage.
- $ref: "/schemas/types.yaml#/definitions/flag"
+ $ref: /schemas/types.yaml#/definitions/flag
required:
- compatible
@@ -187,7 +186,7 @@
- reset-names
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
index b0d81ebe..1b7d88e 100644
--- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
@@ -7,7 +7,7 @@
title: Actions Semi Owl SoCs SD/MMC/SDIO controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml
index c36ba56..024313b 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml
+++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml
@@ -10,7 +10,7 @@
- Wolfram Sang <wsa+renesas@sang-engineering.com>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
index 7bfb10c..7756a86 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mmc/renesas,sdhi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mmc/renesas,sdhi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas SDHI SD/MMC controller
@@ -59,6 +59,7 @@
- renesas,sdhi-r9a07g043 # RZ/G2UL
- renesas,sdhi-r9a07g044 # RZ/G2{L,LC}
- renesas,sdhi-r9a07g054 # RZ/V2L
+ - renesas,sdhi-r9a09g011 # RZ/V2M
- const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2
- items:
- enum:
@@ -111,7 +112,7 @@
max-frequency: true
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
- if:
properties:
@@ -121,6 +122,7 @@
- renesas,sdhi-r9a07g043
- renesas,sdhi-r9a07g044
- renesas,sdhi-r9a07g054
+ - renesas,sdhi-r9a09g011
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
index c7e14b7..211cd0b 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -14,7 +14,7 @@
file and the Rockchip specific extensions.
allOf:
- - $ref: "synopsys-dw-mshc-common.yaml#"
+ - $ref: synopsys-dw-mshc-common.yaml#
maintainers:
- Heiko Stuebner <heiko@sntech.de>
@@ -39,6 +39,7 @@
- rockchip,rk3368-dw-mshc
- rockchip,rk3399-dw-mshc
- rockchip,rk3568-dw-mshc
+ - rockchip,rk3588-dw-mshc
- rockchip,rv1108-dw-mshc
- rockchip,rv1126-dw-mshc
- const: rockchip,rk3288-dw-mshc
diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
index fdaa184..6ee78a3 100644
--- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
@@ -112,7 +112,7 @@
- samsung,dw-mshc-sdr-timing
allOf:
- - $ref: "synopsys-dw-mshc-common.yaml#"
+ - $ref: synopsys-dw-mshc-common.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
deleted file mode 100644
index 5f68feb..0000000
--- a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
-
-Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
-with external MMC, SD and SDIO storage mediums.
-
-This file documents differences between the core mmc properties described by
-mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
-implementation.
-
-Required SoC Specific Properties:
-- compatible: should be one of the following
- - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
- - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
- - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
-- reg: register location and length
-- interrupts: mmc controller interrupt
-- clocks: Should reference the controller clock
-- clock-names: Should contain "sdi"
-
-Required Board Specific Properties:
-- pinctrl-0: Should specify pin control groups used for this controller.
-- pinctrl-names: Should contain only one value - "default".
-
-Optional Properties:
-- bus-width: number of data lines (see mmc.txt)
-- cd-gpios: gpio for card detection (see mmc.txt)
-- wp-gpios: gpio for write protection (see mmc.txt)
-
-Example:
-
- mmc0: mmc@5a000000 {
- compatible = "samsung,s3c2440-sdi";
- pinctrl-names = "default";
- pinctrl-0 = <&sdi_pins>;
- reg = <0x5a000000 0x100000>;
- interrupts = <0 0 21 3>;
- clocks = <&clocks PCLK_SDI>;
- clock-names = "sdi";
- bus-width = <4>;
- cd-gpios = <&gpg 8 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gph 8 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
index 6b89238..64df691 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
@@ -34,6 +34,8 @@
- const: qcom,sdhci-msm-v4 # for sdcc versions less than 5.0
- items:
- enum:
+ - qcom,ipq5332-sdhci
+ - qcom,ipq9574-sdhci
- qcom,qcs404-sdhci
- qcom,sc7180-sdhci
- qcom,sc7280-sdhci
@@ -125,11 +127,13 @@
phandle to apps_smmu node with sid mask.
interconnects:
+ minItems: 1
items:
- description: data path, sdhc to ddr
- description: config path, cpu to sdhc
interconnect-names:
+ minItems: 1
items:
- const: sdhc-ddr
- const: cpu-sdhc
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
index 3d46c25..09455f9 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/sdhci-pxa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell PXA SDHCI v2/v3
+title: Marvell PXA SDHCI v1/v2/v3
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -34,6 +34,7 @@
properties:
compatible:
enum:
+ - mrvl,pxav1-mmc
- mrvl,pxav2-mmc
- mrvl,pxav3-mmc
- marvell,armada-380-sdhci
@@ -61,6 +62,22 @@
- const: io
- const: core
+ pinctrl-names:
+ description:
+ Optional for supporting PXA168 SDIO IRQ errata to switch CMD pin between
+ SDIO CMD and GPIO mode.
+ items:
+ - const: default
+ - const: state_cmd_gpio
+
+ pinctrl-0:
+ description:
+ Should contain default pinctrl.
+
+ pinctrl-1:
+ description:
+ Should switch CMD pin to GPIO mode as a high output.
+
mrvl,clk-delay-cycles:
description: Specify a number of cycles to delay for tuning.
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
index a586fad..c71424a 100644
--- a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
+++ b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
@@ -55,6 +55,16 @@
minItems: 1
maxItems: 3
+ socionext,syscon-uhs-mode:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscon that configures UHS mode
+ - description: ID of SD instance
+ description:
+ A phandle to syscon with one argument that configures UHS mode.
+ The argument is the ID of SD instance.
+
allOf:
- $ref: mmc-controller.yaml
diff --git a/Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml b/Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml
new file mode 100644
index 0000000..51e1b04
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/starfive,jh7110-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive Designware Mobile Storage Host Controller
+
+description:
+ StarFive uses the Synopsys designware mobile storage host controller
+ to interface a SoC with storage medium such as eMMC or SD/MMC cards.
+
+allOf:
+ - $ref: synopsys-dw-mshc-common.yaml#
+
+maintainers:
+ - William Qiu <william.qiu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-mmc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: biu clock
+ - description: ciu clock
+
+ clock-names:
+ items:
+ - const: biu
+ - const: ciu
+
+ interrupts:
+ maxItems: 1
+
+ starfive,sysreg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller syscon node
+ - description: offset of SYS_SYSCONSAIF__SYSCFG register for MMC controller
+ - description: shift of SYS_SYSCONSAIF__SYSCFG register for MMC controller
+ - description: mask of SYS_SYSCONSAIF__SYSCFG register for MMC controller
+ description:
+ Should be four parameters, the phandle to System Register Controller
+ syscon node and the offset/shift/mask of SYS_SYSCONSAIF__SYSCFG register
+ for MMC controller.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - starfive,sysreg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@16010000 {
+ compatible = "starfive,jh7110-mmc";
+ reg = <0x16010000 0x10000>;
+ clocks = <&syscrg 91>,
+ <&syscrg 93>;
+ clock-names = "biu","ciu";
+ resets = <&syscrg 64>;
+ reset-names = "reset";
+ interrupts = <74>;
+ fifo-depth = <32>;
+ fifo-watermark-aligned;
+ data-addr = <0>;
+ starfive,sysreg = <&sys_syscon 0x14 0x1a 0x7c000000>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml b/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml
index 23aa8e6b..6116871 100644
--- a/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml
@@ -12,7 +12,7 @@
- Li-hao Kuo <lhjeff911@gmail.com>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
index 8dfad89..6f11b2a 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
@@ -7,7 +7,7 @@
title: Synopsys Designware Mobile Storage Host Controller Common Properties
allOf:
- - $ref: "mmc-controller.yaml#"
+ - $ref: mmc-controller.yaml#
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 3fe981b..5473636 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -76,6 +76,13 @@
If "broken-flash-reset" is present then having this property does not
make any difference.
+ spi-cpol: true
+ spi-cpha: true
+
+dependencies:
+ spi-cpol: [ spi-cpha ]
+ spi-cpha: [ spi-cpol ]
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
new file mode 100644
index 0000000..a6e7f12
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mediatek,mtk-nfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek(MTK) SoCs raw NAND FLASH controller (NFC)
+
+maintainers:
+ - Xiangsheng Hou <xiangsheng.hou@mediatek.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-nfc
+ - mediatek,mt2712-nfc
+ - mediatek,mt7622-nfc
+
+ reg:
+ items:
+ - description: Base physical address and size of NFI.
+
+ interrupts:
+ items:
+ - description: NFI interrupt
+
+ clocks:
+ items:
+ - description: clock used for the controller
+ - description: clock used for the pad
+
+ clock-names:
+ items:
+ - const: nfi_clk
+ - const: pad_clk
+
+ ecc-engine:
+ description: device-tree node of the required ECC engine.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ $ref: nand-chip.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ maximum: 1
+ nand-on-flash-bbt: true
+ nand-ecc-mode:
+ const: hw
+
+allOf:
+ - $ref: nand-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt2701-nfc
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-step-size:
+ enum: [ 512, 1024 ]
+ nand-ecc-strength:
+ enum: [4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 36,
+ 40, 44, 48, 52, 56, 60]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt2712-nfc
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-step-size:
+ enum: [ 512, 1024 ]
+ nand-ecc-strength:
+ enum: [4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 36,
+ 40, 44, 48, 52, 56, 60, 68, 72, 80]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7622-nfc
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-step-size:
+ const: 512
+ nand-ecc-strength:
+ enum: [4, 6, 8, 10, 12]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ecc-engine
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ nand-controller@1100d000 {
+ compatible = "mediatek,mt2701-nfc";
+ reg = <0 0x1100d000 0 0x1000>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI>,
+ <&pericfg CLK_PERI_NFI_PAD>;
+ clock-names = "nfi_clk", "pad_clk";
+ ecc-engine = <&bch>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ nand-ecc-step-size = <1024>;
+ nand-ecc-strength = <24>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ preloader@0 {
+ label = "pl";
+ read-only;
+ reg = <0x0 0x400000>;
+ };
+ android@400000 {
+ label = "android";
+ reg = <0x400000 0x12c00000>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml
new file mode 100644
index 0000000..505baf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mediatek,nand-ecc-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek(MTK) SoCs NAND ECC engine
+
+maintainers:
+ - Xiangsheng Hou <xiangsheng.hou@mediatek.com>
+
+description: |
+ MTK NAND ECC engine can cowork with MTK raw NAND and SPI NAND controller.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-ecc
+ - mediatek,mt2712-ecc
+ - mediatek,mt7622-ecc
+ - mediatek,mt7986-ecc
+
+ reg:
+ items:
+ - description: Base physical address and size of ECC.
+
+ interrupts:
+ items:
+ - description: ECC interrupt
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: nfiecc_clk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ bch: ecc@1100e000 {
+ compatible = "mediatek,mt2701-ecc";
+ reg = <0 0x1100e000 0 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI_ECC>;
+ clock-names = "nfiecc_clk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
index 5df9495..44cd447 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
@@ -15,6 +15,7 @@
allOf:
- $ref: "mtd.yaml#"
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mtd/mtk-nand.txt b/Documentation/devicetree/bindings/mtd/mtk-nand.txt
deleted file mode 100644
index 839ea2f..0000000
--- a/Documentation/devicetree/bindings/mtd/mtk-nand.txt
+++ /dev/null
@@ -1,176 +0,0 @@
-MTK SoCs NAND FLASH controller (NFC) DT binding
-
-This file documents the device tree bindings for MTK SoCs NAND controllers.
-The functional split of the controller requires two drivers to operate:
-the nand controller interface driver and the ECC engine driver.
-
-The hardware description for both devices must be captured as device
-tree nodes.
-
-1) NFC NAND Controller Interface (NFI):
-=======================================
-
-The first part of NFC is NAND Controller Interface (NFI) HW.
-Required NFI properties:
-- compatible: Should be one of
- "mediatek,mt2701-nfc",
- "mediatek,mt2712-nfc",
- "mediatek,mt7622-nfc".
-- reg: Base physical address and size of NFI.
-- interrupts: Interrupts of NFI.
-- clocks: NFI required clocks.
-- clock-names: NFI clocks internal name.
-- ecc-engine: Required ECC Engine node.
-- #address-cells: NAND chip index, should be 1.
-- #size-cells: Should be 0.
-
-Example:
-
- nandc: nfi@1100d000 {
- compatible = "mediatek,mt2701-nfc";
- reg = <0 0x1100d000 0 0x1000>;
- interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_NFI>,
- <&pericfg CLK_PERI_NFI_PAD>;
- clock-names = "nfi_clk", "pad_clk";
- ecc-engine = <&bch>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
-Platform related properties, should be set in {platform_name}.dts:
-- children nodes: NAND chips.
-
-Children nodes properties:
-- reg: Chip Select Signal, default 0.
- Set as reg = <0>, <1> when need 2 CS.
-Optional:
-- nand-on-flash-bbt: Store BBT on NAND Flash.
-- nand-ecc-mode: the NAND ecc mode (check driver for supported modes)
-- nand-ecc-step-size: Number of data bytes covered by a single ECC step.
- valid values:
- 512 and 1024 on mt2701 and mt2712.
- 512 only on mt7622.
- 1024 is recommended for large page NANDs.
-- nand-ecc-strength: Number of bits to correct per ECC step.
- The valid values that each controller supports:
- mt2701: 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28,
- 32, 36, 40, 44, 48, 52, 56, 60.
- mt2712: 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28,
- 32, 36, 40, 44, 48, 52, 56, 60, 68, 72, 80.
- mt7622: 4, 6, 8, 10, 12, 14, 16.
- The strength should be calculated as follows:
- E = (S - F) * 8 / B
- S = O / (P / Q)
- E : nand-ecc-strength.
- S : spare size per sector.
- F : FDM size, should be in the range [1,8].
- It is used to store free oob data.
- O : oob size.
- P : page size.
- Q : nand-ecc-step-size.
- B : number of parity bits needed to correct
- 1 bitflip.
- According to MTK NAND controller design,
- this number depends on max ecc step size
- that MTK NAND controller supports.
- If max ecc step size supported is 1024,
- then it should be always 14. And if max
- ecc step size is 512, then it should be
- always 13.
- If the result does not match any one of the listed
- choices above, please select the smaller valid value from
- the list.
- (otherwise the driver will do the adjustment at runtime)
-- pinctrl-names: Default NAND pin GPIO setting name.
-- pinctrl-0: GPIO setting node.
-
-Example:
- &pio {
- nand_pins_default: nanddefault {
- pins_dat {
- pinmux = <MT2701_PIN_111_MSDC0_DAT7__FUNC_NLD7>,
- <MT2701_PIN_112_MSDC0_DAT6__FUNC_NLD6>,
- <MT2701_PIN_114_MSDC0_DAT4__FUNC_NLD4>,
- <MT2701_PIN_118_MSDC0_DAT3__FUNC_NLD3>,
- <MT2701_PIN_121_MSDC0_DAT0__FUNC_NLD0>,
- <MT2701_PIN_120_MSDC0_DAT1__FUNC_NLD1>,
- <MT2701_PIN_113_MSDC0_DAT5__FUNC_NLD5>,
- <MT2701_PIN_115_MSDC0_RSTB__FUNC_NLD8>,
- <MT2701_PIN_119_MSDC0_DAT2__FUNC_NLD2>;
- input-enable;
- drive-strength = <MTK_DRIVE_8mA>;
- bias-pull-up;
- };
-
- pins_we {
- pinmux = <MT2701_PIN_117_MSDC0_CLK__FUNC_NWEB>;
- drive-strength = <MTK_DRIVE_8mA>;
- bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
- };
-
- pins_ale {
- pinmux = <MT2701_PIN_116_MSDC0_CMD__FUNC_NALE>;
- drive-strength = <MTK_DRIVE_8mA>;
- bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
- };
- };
- };
-
- &nandc {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nand_pins_default>;
- nand@0 {
- reg = <0>;
- nand-on-flash-bbt;
- nand-ecc-mode = "hw";
- nand-ecc-strength = <24>;
- nand-ecc-step-size = <1024>;
- };
- };
-
-NAND chip optional subnodes:
-- Partitions, see Documentation/devicetree/bindings/mtd/mtd.yaml
-
-Example:
- nand@0 {
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- preloader@0 {
- label = "pl";
- read-only;
- reg = <0x00000000 0x00400000>;
- };
- android@00400000 {
- label = "android";
- reg = <0x00400000 0x12c00000>;
- };
- };
- };
-
-2) ECC Engine:
-==============
-
-Required BCH properties:
-- compatible: Should be one of
- "mediatek,mt2701-ecc",
- "mediatek,mt2712-ecc",
- "mediatek,mt7622-ecc".
-- reg: Base physical address and size of ECC.
-- interrupts: Interrupts of ECC.
-- clocks: ECC required clocks.
-- clock-names: ECC clocks internal name.
-
-Example:
-
- bch: ecc@1100e000 {
- compatible = "mediatek,mt2701-ecc";
- reg = <0 0x1100e000 0 0x1000>;
- interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_NFI_ECC>;
- clock-names = "nfiecc_clk";
- };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
index 9aca4e6..2edc65e 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
@@ -32,7 +32,7 @@
enum: [1, 2]
patternProperties:
- "partition(-.+|@[0-9a-f]+)":
+ "^partition(-.+|@[0-9a-f]+)$":
$ref: partition.yaml
required:
diff --git a/Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml b/Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml
new file mode 100644
index 0000000..ec5c038
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/amlogic,g12a-mdio-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MDIO bus multiplexer/glue of Amlogic G12a SoC family
+
+description:
+ This is a special case of a MDIO bus multiplexer. It allows to choose between
+ the internal mdio bus leading to the embedded 10/100 PHY or the external
+ MDIO bus.
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: mdio-mux.yaml#
+
+properties:
+ compatible:
+ const: amlogic,g12a-mdio-mux
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: peripheral clock
+ - description: platform crytal
+ - description: SoC 50MHz MPLL
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: clkin0
+ - const: clkin1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mdio-multiplexer@4c000 {
+ compatible = "amlogic,g12a-mdio-mux";
+ reg = <0x4c000 0xa4>;
+ clocks = <&clkc_eth_phy>, <&xtal>, <&clkc_mpll>;
+ clock-names = "pclk", "clkin0", "clkin1";
+ mdio-parent-bus = <&mdio0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mdio@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@8 {
+ compatible = "ethernet-phy-id0180.3301",
+ "ethernet-phy-ieee802.3-c22";
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <8>;
+ max-speed = <100>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml b/Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml
new file mode 100644
index 0000000..27ae004
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/amlogic,gxl-mdio-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic GXL MDIO bus multiplexer
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+description:
+ This is a special case of a MDIO bus multiplexer. It allows to choose between
+ the internal mdio bus leading to the embedded 10/100 PHY or the external
+ MDIO bus on the Amlogic GXL SoC family.
+
+allOf:
+ - $ref: mdio-mux.yaml#
+
+properties:
+ compatible:
+ const: amlogic,gxl-mdio-mux
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ eth_phy_mux: mdio@558 {
+ compatible = "amlogic,gxl-mdio-mux";
+ reg = <0x558 0xc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&refclk>;
+ clock-names = "ref";
+ mdio-parent-bus = <&mdio0>;
+
+ external_mdio: mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ internal_mdio: mdio@1 {
+ reg = <0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
index 699ebf4..164d1ff 100644
--- a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
+++ b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
@@ -19,6 +19,7 @@
allOf:
- $ref: ethernet-controller.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
properties:
compatible:
@@ -39,8 +40,8 @@
it should be marked GPIO_ACTIVE_LOW.
maxItems: 1
+ controller-data: true
local-mac-address: true
-
mac-address: true
required:
diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index 1eb98c9..d3f45d2 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -30,13 +30,17 @@
- items:
- enum:
+ - renesas,r8a779a0-canfd # R-Car V3U
+ - renesas,r8a779g0-canfd # R-Car V4H
+ - const: renesas,rcar-gen4-canfd # R-Car Gen4
+
+ - items:
+ - enum:
- renesas,r9a07g043-canfd # RZ/G2UL and RZ/Five
- renesas,r9a07g044-canfd # RZ/G2{L,LC}
- renesas,r9a07g054-canfd # RZ/V2L
- const: renesas,rzg2l-canfd # RZ/G2L family
- - const: renesas,r8a779a0-canfd # R-Car V3U
-
reg:
maxItems: 1
@@ -60,7 +64,7 @@
$ref: /schemas/types.yaml#/definitions/flag
description:
The controller can operate in either CAN FD only mode (default) or
- Classical CAN only mode. The mode is global to both the channels.
+ Classical CAN only mode. The mode is global to all channels.
Specify this property to put the controller in Classical CAN only mode.
assigned-clocks:
@@ -80,6 +84,10 @@
The controller supports multiple channels and each is represented as a
child node. Each channel can be enabled/disabled individually.
+ properties:
+ phys:
+ maxItems: 1
+
additionalProperties: false
required:
@@ -159,7 +167,7 @@
properties:
compatible:
contains:
- const: renesas,r8a779a0-canfd
+ const: renesas,rcar-gen4-canfd
then:
patternProperties:
"^channel[2-7]$": false
diff --git a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
index 2a6d126..9565a74 100644
--- a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
@@ -7,7 +7,7 @@
title: Arrow SpeedChips XRS7000 Series Switch
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
maintainers:
- George McCollister <george.mccollister@gmail.com>
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
index 1219b83..5bef412 100644
--- a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
@@ -66,7 +66,7 @@
- reg
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
index d159ac7..eed16e2 100644
--- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
@@ -85,11 +85,16 @@
ports:
type: object
- properties:
- brcm,use-bcm-hdr:
- description: if present, indicates that the switch port has Broadcom
- tags enabled (per-packet metadata)
- type: boolean
+ patternProperties:
+ '^port@[0-9a-f]$':
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ brcm,use-bcm-hdr:
+ description: if present, indicates that the switch port has Broadcom
+ tags enabled (per-packet metadata)
+ type: boolean
required:
- reg
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
index b173fce..4801204 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
@@ -4,18 +4,19 @@
$id: http://devicetree.org/schemas/net/dsa/dsa-port.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ethernet Switch port
+title: Generic DSA Switch Port
maintainers:
- Andrew Lunn <andrew@lunn.ch>
- Florian Fainelli <f.fainelli@gmail.com>
- - Vivien Didelot <vivien.didelot@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
description:
- Ethernet switch port Description
+ A DSA switch port is a component of a switch that manages one MAC, and can
+ pass Ethernet frames. It can act as a stanadard Ethernet switch port, or have
+ DSA-specific functionality.
-allOf:
- - $ref: /schemas/net/ethernet-controller.yaml#
+$ref: /schemas/net/ethernet-switch-port.yaml#
properties:
reg:
@@ -58,25 +59,6 @@
- rtl8_4t
- seville
- phy-handle: true
-
- phy-mode: true
-
- fixed-link: true
-
- mac-address: true
-
- sfp: true
-
- managed: true
-
- rx-internal-delay-ps: true
-
- tx-internal-delay-ps: true
-
-required:
- - reg
-
# CPU and DSA ports must have phylink-compatible link descriptions
if:
oneOf:
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
index 5469ae8..8d97181 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
@@ -9,7 +9,7 @@
maintainers:
- Andrew Lunn <andrew@lunn.ch>
- Florian Fainelli <f.fainelli@gmail.com>
- - Vivien Didelot <vivien.didelot@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
description:
This binding represents Ethernet Switches which have a dedicated CPU
@@ -18,10 +18,9 @@
select: false
-properties:
- $nodename:
- pattern: "^(ethernet-)?switch(@.*)?$"
+$ref: /schemas/net/ethernet-switch.yaml#
+properties:
dsa,member:
minItems: 2
maxItems: 2
@@ -32,30 +31,28 @@
(single device hanging off a CPU port) must not specify this property
$ref: /schemas/types.yaml#/definitions/uint32-array
-patternProperties:
- "^(ethernet-)?ports$":
- type: object
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
+additionalProperties: true
+
+$defs:
+ ethernet-ports:
+ description: A DSA switch without any extra port properties
+ $ref: '#/'
patternProperties:
- "^(ethernet-)?port@[0-9]+$":
+ "^(ethernet-)?ports$":
type: object
- description: Ethernet switch ports
+ additionalProperties: false
- $ref: dsa-port.yaml#
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
- unevaluatedProperties: false
-
-oneOf:
- - required:
- - ports
- - required:
- - ethernet-ports
-
-additionalProperties: true
+ patternProperties:
+ "^(ethernet-)?port@[0-9]+$":
+ description: Ethernet switch ports
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
...
diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
index 447589b..4021b05 100644
--- a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
@@ -7,7 +7,7 @@
title: Hirschmann Hellcreek TSN Switch
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
maintainers:
- Andrew Lunn <andrew@lunn.ch>
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index f2e9ff3..449ee07 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -24,56 +24,46 @@
There is only the standalone version of MT7531.
- Port 5 on MT7530 has got various ways of configuration.
-
- For standalone MT7530:
+ Port 5 on MT7530 has got various ways of configuration:
- Port 5 can be used as a CPU port.
- - PHY 0 or 4 of the switch can be muxed to connect to the gmac of the SoC
- which port 5 is wired to. Usually used for connecting the wan port
- directly to the CPU to achieve 2 Gbps routing in total.
+ - PHY 0 or 4 of the switch can be muxed to gmac5 of the switch. Therefore,
+ the gmac of the SoC which is wired to port 5 can connect to the PHY.
+ This is usually used for connecting the wan port directly to the CPU to
+ achieve 2 Gbps routing in total.
- The driver looks up the reg on the ethernet-phy node which the phy-handle
- property refers to on the gmac node to mux the specified phy.
+ The driver looks up the reg on the ethernet-phy node, which the phy-handle
+ property on the gmac node refers to, to mux the specified phy.
The driver requires the gmac of the SoC to have "mediatek,eth-mac" as the
- compatible string and the reg must be 1. So, for now, only gmac1 of an
+ compatible string and the reg must be 1. So, for now, only gmac1 of a
MediaTek SoC can benefit this. Banana Pi BPI-R2 suits this.
- Check out example 5 for a similar configuration.
-
- - Port 5 can be wired to an external phy. Port 5 becomes a DSA slave.
- Check out example 7 for a similar configuration.
-
- For multi-chip module MT7530:
-
- - Port 5 can be used as a CPU port.
-
- - PHY 0 or 4 of the switch can be muxed to connect to gmac1 of the SoC.
- Usually used for connecting the wan port directly to the CPU to achieve 2
- Gbps routing in total.
-
- The driver looks up the reg on the ethernet-phy node which the phy-handle
- property refers to on the gmac node to mux the specified phy.
For the MT7621 SoCs, rgmii2 group must be claimed with rgmii2 function.
+
Check out example 5.
- - In case of an external phy wired to gmac1 of the SoC, port 5 must not be
- enabled.
+ - For the multi-chip module MT7530, in case of an external phy wired to
+ gmac1 of the SoC, port 5 must not be enabled.
In case of muxing PHY 0 or 4, the external phy must not be enabled.
For the MT7621 SoCs, rgmii2 group must be claimed with rgmii2 function.
+
Check out example 6.
- - Port 5 can be muxed to an external phy. Port 5 becomes a DSA slave.
- The external phy must be wired TX to TX to gmac1 of the SoC for this to
- work. Ubiquiti EdgeRouter X SFP is wired this way.
+ - Port 5 can be wired to an external phy. Port 5 becomes a DSA slave.
- Muxing PHY 0 or 4 won't work when the external phy is connected TX to TX.
+ For the multi-chip module MT7530, the external phy must be wired TX to TX
+ to gmac1 of the SoC for this to work. Ubiquiti EdgeRouter X SFP is wired
+ this way.
+
+ For the multi-chip module MT7530, muxing PHY 0 or 4 won't work when the
+ external phy is connected TX to TX.
For the MT7621 SoCs, rgmii2 group must be claimed with gpio function.
+
Check out example 7.
properties:
@@ -157,9 +147,6 @@
patternProperties:
"^(ethernet-)?port@[0-9]+$":
type: object
- description: Ethernet switch ports
-
- unevaluatedProperties: false
properties:
reg:
@@ -168,7 +155,6 @@
for user ports.
allOf:
- - $ref: dsa-port.yaml#
- if:
required: [ ethernet ]
then:
@@ -238,7 +224,7 @@
- sgmii
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- if:
required:
- mediatek,mcm
@@ -605,7 +591,7 @@
label = "lan4";
};
- /* Commented out, phy4 is muxed to gmac1.
+ /* Commented out, phy4 is connected to gmac1.
port@4 {
reg = <4>;
label = "wan";
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
index 4da75b1..a4b5343 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -11,7 +11,7 @@
- Woojung Huh <Woojung.Huh@microchip.com>
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
index b34de30..8d7e878 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
@@ -10,7 +10,7 @@
- UNGLinuxDriver@microchip.com
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml b/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
index 347a0e1..fe02d05 100644
--- a/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
@@ -78,7 +78,7 @@
- reg
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index df98a16..9a64ed6 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -13,7 +13,7 @@
depends on the SPI bus master driver.
allOf:
- - $ref: "dsa.yaml#"
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- $ref: /schemas/spi/spi-peripheral-props.yaml#
maintainers:
diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml
index 978162d..3898925 100644
--- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml
@@ -66,15 +66,11 @@
With the legacy mapping the reg corresponding to the internal
mdio is the switch reg with an offset of -1.
+$ref: "dsa.yaml#"
+
patternProperties:
"^(ethernet-)?ports$":
type: object
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
-
patternProperties:
"^(ethernet-)?port@[0-6]$":
type: object
@@ -116,7 +112,7 @@
- compatible
- reg
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
@@ -148,8 +144,6 @@
switch@10 {
compatible = "qca,qca8337";
- #address-cells = <1>;
- #size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
@@ -209,8 +203,6 @@
switch@10 {
compatible = "qca,qca8337";
- #address-cells = <1>;
- #size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
index 1a7d45a..cfd69c2 100644
--- a/Documentation/devicetree/bindings/net/dsa/realtek.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
@@ -7,7 +7,7 @@
title: Realtek switches for unmanaged switches
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
diff --git a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
index 0a0d62b..833d2f6 100644
--- a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
@@ -14,7 +14,7 @@
handles 4 ports + 1 CPU management port.
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/ethernet-switch-port.yaml b/Documentation/devicetree/bindings/net/ethernet-switch-port.yaml
new file mode 100644
index 0000000..d5cf7e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet-switch-port.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ethernet-switch-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Ethernet Switch Port
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
+
+description:
+ An Ethernet switch port is a component of a switch that manages one MAC, and
+ can pass Ethernet frames.
+
+$ref: ethernet-controller.yaml#
+
+properties:
+ reg:
+ description: Port number
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/net/ethernet-switch.yaml b/Documentation/devicetree/bindings/net/ethernet-switch.yaml
new file mode 100644
index 0000000..a04f8ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet-switch.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ethernet-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Ethernet Switch
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
+
+description:
+ Ethernet switches are multi-port Ethernet controllers. Each port has
+ its own number and is represented as its own Ethernet controller.
+ The minimum required functionality is to pass packets to software.
+ They may or may not be able to forward packets automonously between
+ ports.
+
+select: false
+
+properties:
+ $nodename:
+ pattern: "^(ethernet-)?switch(@.*)?$"
+
+patternProperties:
+ "^(ethernet-)?ports$":
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^(ethernet-)?port@[0-9]+$":
+ type: object
+ description: Ethernet switch ports
+
+oneOf:
+ - required:
+ - ports
+ - required:
+ - ethernet-ports
+
+additionalProperties: true
+
+$defs:
+ base:
+ description: An ethernet switch without any extra port properties
+ $ref: '#/'
+
+ patternProperties:
+ "^(ethernet-)?port@[0-9]+$":
+ description: Ethernet switch ports
+ $ref: ethernet-switch-port.yaml#
+ unevaluatedProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml
index 77e5f32..e6f2045 100644
--- a/Documentation/devicetree/bindings/net/fsl,fec.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml
@@ -51,6 +51,7 @@
- fsl,imx8mm-fec
- fsl,imx8mn-fec
- fsl,imx8mp-fec
+ - fsl,imx93-fec
- const: fsl,imx8mq-fec
- const: fsl,imx6sx-fec
- items:
diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
new file mode 100644
index 0000000..d71fa9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/maxlinear,gpy2xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxLinear GPY2xx PHY
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Michael Walle <michael@walle.cc>
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ maxlinear,use-broken-interrupts:
+ description: |
+ Interrupts are broken on some GPY2xx PHYs in that they keep the
+ interrupt line asserted even after the interrupt status register is
+ cleared. Thus it is blocking the interrupt line which is usually bad
+ for shared lines. By default interrupts are disabled for this PHY and
+ polling mode is used. If one can live with the consequences, this
+ property can be used to enable interrupt handling.
+
+ Affected PHYs (as far as known) are GPY215B and GPY215C.
+ type: boolean
+
+dependencies:
+ maxlinear,use-broken-interrupts: [ interrupts ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&intc 0>;
+ maxlinear,use-broken-interrupts;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt b/Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt
deleted file mode 100644
index 3a96cbe..0000000
--- a/Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Properties for the MDIO bus multiplexer/glue of Amlogic G12a SoC family.
-
-This is a special case of a MDIO bus multiplexer. It allows to choose between
-the internal mdio bus leading to the embedded 10/100 PHY or the external
-MDIO bus.
-
-Required properties in addition to the generic multiplexer properties:
-- compatible : amlogic,g12a-mdio-mux
-- reg: physical address and length of the multiplexer/glue registers
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "clkin0" : platform crytal
- * "clkin1" : SoC 50MHz MPLL
-
-Example :
-
-mdio_mux: mdio-multiplexer@4c000 {
- compatible = "amlogic,g12a-mdio-mux";
- reg = <0x0 0x4c000 0x0 0xa4>;
- clocks = <&clkc CLKID_ETH_PHY>,
- <&xtal>,
- <&clkc CLKID_MPLL_5OM>;
- clock-names = "pclk", "clkin0", "clkin1";
- mdio-parent-bus = <&mdio0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- ext_mdio: mdio@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
- int_mdio: mdio@1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- internal_ephy: ethernet-phy@8 {
- compatible = "ethernet-phy-id0180.3301",
- "ethernet-phy-ieee802.3-c22";
- interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- reg = <8>;
- max-speed = <100>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index df9e844..2681168 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -158,6 +158,7 @@
no link will be established.
KSZ9131:
+LAN8841:
All skew control options are specified in picoseconds. The increment
step is 100ps. Unlike KSZ9031, the values represent picoseccond delays.
diff --git a/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
new file mode 100644
index 0000000..157e3bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/motorcomm,yt8xxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MotorComm yt8xxx Ethernet PHY
+
+maintainers:
+ - Frank Sae <frank.sae@motor-comm.com>
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id4f51.e91a
+ - ethernet-phy-id4f51.e91b
+
+ rx-internal-delay-ps:
+ description: |
+ RGMII RX Clock Delay used only when PHY operates in RGMII mode with
+ internal delay (phy-mode is 'rgmii-id' or 'rgmii-rxid') in pico-seconds.
+ enum: [ 0, 150, 300, 450, 600, 750, 900, 1050, 1200, 1350, 1500, 1650,
+ 1800, 1900, 1950, 2050, 2100, 2200, 2250, 2350, 2500, 2650, 2800,
+ 2950, 3100, 3250, 3400, 3550, 3700, 3850, 4000, 4150 ]
+ default: 1950
+
+ tx-internal-delay-ps:
+ description: |
+ RGMII TX Clock Delay used only when PHY operates in RGMII mode with
+ internal delay (phy-mode is 'rgmii-id' or 'rgmii-txid') in pico-seconds.
+ enum: [ 0, 150, 300, 450, 600, 750, 900, 1050, 1200, 1350, 1500, 1650, 1800,
+ 1950, 2100, 2250 ]
+ default: 1950
+
+ motorcomm,clk-out-frequency-hz:
+ description: clock output on clock output pin.
+ enum: [0, 25000000, 125000000]
+ default: 0
+
+ motorcomm,keep-pll-enabled:
+ description: |
+ If set, keep the PLL enabled even if there is no link. Useful if you
+ want to use the clock output without an ethernet link.
+ type: boolean
+
+ motorcomm,auto-sleep-disabled:
+ description: |
+ If set, PHY will not enter sleep mode and close AFE after unplug cable
+ for a timer.
+ type: boolean
+
+ motorcomm,tx-clk-adj-enabled:
+ description: |
+ This configuration is mainly to adapt to VF2 with JH7110 SoC.
+ Useful if you want to use tx-clk-xxxx-inverted to adj the delay of tx clk.
+ type: boolean
+
+ motorcomm,tx-clk-10-inverted:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 10Mbps.
+ type: boolean
+
+ motorcomm,tx-clk-100-inverted:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 100Mbps.
+ type: boolean
+
+ motorcomm,tx-clk-1000-inverted:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 1000Mbps.
+ type: boolean
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy-mode = "rgmii-id";
+ ethernet-phy@4 {
+ /* Only needed to make DT lint tools work. Do not copy/paste
+ * into real DTS files.
+ */
+ compatible = "ethernet-phy-id4f51.e91a";
+
+ reg = <4>;
+ rx-internal-delay-ps = <2100>;
+ tx-internal-delay-ps = <150>;
+ motorcomm,clk-out-frequency-hz = <0>;
+ motorcomm,keep-pll-enabled;
+ motorcomm,auto-sleep-disabled;
+ };
+ };
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy-mode = "rgmii";
+ ethernet-phy@5 {
+ /* Only needed to make DT lint tools work. Do not copy/paste
+ * into real DTS files.
+ */
+ compatible = "ethernet-phy-id4f51.e91a";
+
+ reg = <5>;
+ motorcomm,clk-out-frequency-hz = <125000000>;
+ motorcomm,keep-pll-enabled;
+ motorcomm,auto-sleep-disabled;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml
index ee0a504..8ee2c7d 100644
--- a/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml
+++ b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml
@@ -18,14 +18,52 @@
packets using CPU. Additionally, PTP is supported as well as FDMA for faster
packet extraction/injection.
-properties:
- $nodename:
- pattern: "^switch@[0-9a-f]+$"
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: mscc,vsc7514-switch
+ then:
+ $ref: ethernet-switch.yaml#
+ required:
+ - interrupts
+ - interrupt-names
+ properties:
+ reg:
+ minItems: 21
+ reg-names:
+ minItems: 21
+ ethernet-ports:
+ patternProperties:
+ "^port@[0-9a-f]+$":
+ $ref: ethernet-switch-port.yaml#
+ unevaluatedProperties: false
+ - if:
+ properties:
+ compatible:
+ const: mscc,vsc7512-switch
+ then:
+ $ref: /schemas/net/dsa/dsa.yaml#
+ properties:
+ reg:
+ maxItems: 20
+ reg-names:
+ maxItems: 20
+ ethernet-ports:
+ patternProperties:
+ "^port@[0-9a-f]+$":
+ $ref: /schemas/net/dsa/dsa-port.yaml#
+ unevaluatedProperties: false
+
+properties:
compatible:
- const: mscc,vsc7514-switch
+ enum:
+ - mscc,vsc7512-switch
+ - mscc,vsc7514-switch
reg:
+ minItems: 20
items:
- description: system target
- description: rewriter target
@@ -50,6 +88,7 @@
- description: fdma target
reg-names:
+ minItems: 20
items:
- const: sys
- const: rew
@@ -87,59 +126,16 @@
- const: xtr
- const: fdma
- ethernet-ports:
- type: object
-
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
-
- additionalProperties: false
-
- patternProperties:
- "^port@[0-9a-f]+$":
- type: object
- description: Ethernet ports handled by the switch
-
- $ref: ethernet-controller.yaml#
-
- unevaluatedProperties: false
-
- properties:
- reg:
- description: Switch port number
-
- phy-handle: true
-
- phy-mode: true
-
- fixed-link: true
-
- mac-address: true
-
- required:
- - reg
- - phy-mode
-
- oneOf:
- - required:
- - phy-handle
- - required:
- - fixed-link
-
required:
- compatible
- reg
- reg-names
- - interrupts
- - interrupt-names
- ethernet-ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
+ # VSC7514 (Switchdev)
- |
switch@1010000 {
compatible = "mscc,vsc7514-switch";
@@ -187,5 +183,51 @@
};
};
};
+ # VSC7512 (DSA)
+ - |
+ ethernet-switch@1{
+ compatible = "mscc,vsc7512-switch";
+ reg = <0x71010000 0x10000>,
+ <0x71030000 0x10000>,
+ <0x71080000 0x100>,
+ <0x710e0000 0x10000>,
+ <0x711e0000 0x100>,
+ <0x711f0000 0x100>,
+ <0x71200000 0x100>,
+ <0x71210000 0x100>,
+ <0x71220000 0x100>,
+ <0x71230000 0x100>,
+ <0x71240000 0x100>,
+ <0x71250000 0x100>,
+ <0x71260000 0x100>,
+ <0x71270000 0x100>,
+ <0x71280000 0x100>,
+ <0x71800000 0x80000>,
+ <0x71880000 0x10000>,
+ <0x71040000 0x10000>,
+ <0x71050000 0x10000>,
+ <0x71060000 0x10000>;
+ reg-names = "sys", "rew", "qs", "ptp", "port0", "port1",
+ "port2", "port3", "port4", "port5", "port6",
+ "port7", "port8", "port9", "port10", "qsys",
+ "ana", "s0", "s1", "s2";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ethernet = <&mac_sw>;
+ phy-handle = <&phy0>;
+ phy-mode = "internal";
+ };
+ port@1 {
+ reg = <1>;
+ phy-handle = <&phy1>;
+ phy-mode = "internal";
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
index 04df496..63409cb 100644
--- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
+++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8 DWMAC glue layer
+title: NXP i.MX8/9 DWMAC glue layer
maintainers:
- Clark Wang <xiaoning.wang@nxp.com>
@@ -19,6 +19,7 @@
enum:
- nxp,imx8mp-dwmac-eqos
- nxp,imx8dxl-dwmac-eqos
+ - nxp,imx93-dwmac-eqos
required:
- compatible
@@ -32,6 +33,7 @@
- enum:
- nxp,imx8mp-dwmac-eqos
- nxp,imx8dxl-dwmac-eqos
+ - nxp,imx93-dwmac-eqos
- const: snps,dwmac-5.10a
clocks:
diff --git a/Documentation/devicetree/bindings/net/rfkill-gpio.yaml b/Documentation/devicetree/bindings/net/rfkill-gpio.yaml
new file mode 100644
index 0000000..9630c84
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/rfkill-gpio.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/rfkill-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO controlled rfkill switch
+
+maintainers:
+ - Johannes Berg <johannes@sipsolutions.net>
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+properties:
+ compatible:
+ const: rfkill-gpio
+
+ label:
+ description: rfkill switch name, defaults to node name
+
+ radio-type:
+ description: rfkill radio type
+ enum:
+ - bluetooth
+ - fm
+ - gps
+ - nfc
+ - ultrawideband
+ - wimax
+ - wlan
+ - wwan
+
+ shutdown-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - radio-type
+ - shutdown-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ rfkill {
+ compatible = "rfkill-gpio";
+ label = "rfkill-pcie-wlan";
+ radio-type = "wlan";
+ shutdown-gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 42fb72b..0493663 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -49,11 +49,11 @@
- rockchip,rk3368-gmac
- rockchip,rk3399-gmac
- rockchip,rv1108-gmac
- - rockchip,rv1126-gmac
- items:
- enum:
- rockchip,rk3568-gmac
- rockchip,rk3588-gmac
+ - rockchip,rv1126-gmac
- const: snps,dwmac-4.20a
clocks:
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index e88a866..16b7d29 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -552,7 +552,7 @@
dependencies:
snps,reset-active-low: ["snps,reset-gpio"]
- snps,reset-delay-us: ["snps,reset-gpio"]
+ snps,reset-delays-us: ["snps,reset-gpio"]
allOf:
- $ref: "ethernet-controller.yaml#"
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index 8219748..9000634 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -57,6 +57,7 @@
- ti,am654-cpsw-nuss
- ti,j7200-cpswxg-nuss
- ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
- ti,am642-cpsw-nuss
reg:
@@ -111,7 +112,7 @@
const: 0
patternProperties:
- "^port@[1-4]$":
+ "^port@[1-8]$":
type: object
description: CPSWxG NUSS external ports
@@ -121,7 +122,7 @@
properties:
reg:
minimum: 1
- maximum: 4
+ maximum: 8
description: CPSW port number
phys:
@@ -186,12 +187,36 @@
properties:
compatible:
contains:
- const: ti,j7200-cpswxg-nuss
+ const: ti,j721e-cpswxg-nuss
then:
properties:
ethernet-ports:
patternProperties:
- "^port@[3-4]$": false
+ "^port@[5-8]$": false
+ "^port@[1-4]$":
+ properties:
+ reg:
+ minimum: 1
+ maximum: 4
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,j721e-cpswxg-nuss
+ - ti,j7200-cpswxg-nuss
+ then:
+ properties:
+ ethernet-ports:
+ patternProperties:
+ "^port@[3-8]$": false
+ "^port@[1-2]$":
+ properties:
+ reg:
+ minimum: 1
+ maximum: 2
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
index 6230f57..3e910d3 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
@@ -93,6 +93,14 @@
description:
Number of timestamp Generator function outputs (TS_GENFx)
+ ti,pps:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+ description: |
+ The pair of HWx_TS_PUSH input and TS_GENFy output indexes used for
+ PPS events generation. Platform/board specific.
+
refclk-mux:
type: object
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
index 5557676..0ea84d6f 100644
--- a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
@@ -29,15 +29,15 @@
examples:
- |
- mmc {
- #address-cells = <1>;
- #size-cells = <0>;
+ mmc {
+ #address-cells = <1>;
+ #size-cells = <0>;
- wifi@1 {
- compatible = "esp,esp8089";
- reg = <1>;
- esp,crystal-26M-en = <2>;
- };
- };
+ wifi@1 {
+ compatible = "esp,esp8089";
+ reg = <1>;
+ esp,crystal-26M-en = <2>;
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
index e68ed94..d89f7a3 100644
--- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/ieee80211.yaml#
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 9bf9bba..cdc303c 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8978/8997 (sd8787/sd8897/sd8978/sd8997/pcie8997) SDIO/PCIE devices
------
This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
@@ -10,7 +10,9 @@
- compatible : should be one of the following:
* "marvell,sd8787"
* "marvell,sd8897"
+ * "marvell,sd8978"
* "marvell,sd8997"
+ * "nxp,iw416"
* "pci11ab,2b42"
* "pci1b4b,2b42"
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
index f0c78f9..7d526ff 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/mediatek,mt76.yaml#
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
index 556eb52..7d5f982 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/qcom,ath11k.yaml#
@@ -21,6 +20,7 @@
- qcom,ipq8074-wifi
- qcom,ipq6018-wifi
- qcom,wcn6750-wifi
+ - qcom,ipq5018-wifi
reg:
maxItems: 1
@@ -262,10 +262,10 @@
examples:
- |
- q6v5_wcss: q6v5_wcss@CD00000 {
+ q6v5_wcss: remoteproc@cd00000 {
compatible = "qcom,ipq8074-wcss-pil";
- reg = <0xCD00000 0x4040>,
- <0x4AB000 0x20>;
+ reg = <0xcd00000 0x4040>,
+ <0x4ab000 0x20>;
reg-names = "qdsp6",
"rmb";
};
@@ -386,7 +386,7 @@
#address-cells = <2>;
#size-cells = <2>;
- qcn9074_0: qcn9074_0@51100000 {
+ qcn9074_0: wifi@51100000 {
no-map;
reg = <0x0 0x51100000 0x0 0x03500000>;
};
@@ -463,6 +463,6 @@
qcom,smem-states = <&wlan_smp2p_out 0>;
qcom,smem-state-names = "wlan-smp2p-out";
wifi-firmware {
- iommus = <&apps_smmu 0x1c02 0x1>;
+ iommus = <&apps_smmu 0x1c02 0x1>;
};
};
diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
index 583db5d..84e5659 100644
--- a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
@@ -2,7 +2,6 @@
# Copyright (c) 2020, Silicon Laboratories, Inc.
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/net/wireless/silabs,wfx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml
index e314567..f799a1e 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml
@@ -90,47 +90,47 @@
// For wl12xx family:
spi1 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- wlcore1: wlcore@1 {
- compatible = "ti,wl1271";
- reg = <1>;
- spi-max-frequency = <48000000>;
- interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
- vwlan-supply = <&vwlan_fixed>;
- clock-xtal;
- ref-clock-frequency = <38400000>;
- };
+ wlcore1: wlcore@1 {
+ compatible = "ti,wl1271";
+ reg = <1>;
+ spi-max-frequency = <48000000>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ vwlan-supply = <&vwlan_fixed>;
+ clock-xtal;
+ ref-clock-frequency = <38400000>;
+ };
};
// For wl18xx family:
spi2 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- wlcore2: wlcore@0 {
- compatible = "ti,wl1835";
- reg = <0>;
- spi-max-frequency = <48000000>;
- interrupts = <27 IRQ_TYPE_EDGE_RISING>;
- vwlan-supply = <&vwlan_fixed>;
- };
+ wlcore2: wlcore@0 {
+ compatible = "ti,wl1835";
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ vwlan-supply = <&vwlan_fixed>;
+ };
};
// SDIO example:
mmc3 {
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
+ vmmc-supply = <&wlan_en_reg>;
+ bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- wlcore3: wlcore@2 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
- };
+ wlcore3: wlcore@2 {
+ compatible = "ti,wl1835";
+ reg = <2>;
+ interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 8e89b15..2173fe8 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -19,16 +19,21 @@
- qcom,apq8064-qfprom
- qcom,apq8084-qfprom
- qcom,ipq8064-qfprom
- - qcom,msm8974-qfprom
+ - qcom,ipq8074-qfprom
- qcom,msm8916-qfprom
+ - qcom,msm8974-qfprom
+ - qcom,msm8976-qfprom
- qcom,msm8996-qfprom
- qcom,msm8998-qfprom
- qcom,qcs404-qfprom
- qcom,sc7180-qfprom
- qcom,sc7280-qfprom
- qcom,sdm630-qfprom
+ - qcom,sdm670-qfprom
- qcom,sdm845-qfprom
- qcom,sm6115-qfprom
+ - qcom,sm8150-qfprom
+ - qcom,sm8250-qfprom
- const: qcom,qfprom
reg:
diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
index 73a0c65..dc790d2 100644
--- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
@@ -31,65 +31,56 @@
examples:
- |
- // The UniPhier eFuse should be a subnode of a "soc-glue" node.
+ efuse@100 {
+ compatible = "socionext,uniphier-efuse";
+ reg = <0x100 0x28>;
+ };
- soc-glue@5f900000 {
- compatible = "simple-mfd";
+ efuse@200 {
+ compatible = "socionext,uniphier-efuse";
+ reg = <0x200 0x68>;
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x5f900000 0x2000>;
- efuse@100 {
- compatible = "socionext,uniphier-efuse";
- reg = <0x100 0x28>;
+ /* Data cells */
+ usb_rterm0: trim@54,4 {
+ reg = <0x54 1>;
+ bits = <4 2>;
};
-
- efuse@200 {
- compatible = "socionext,uniphier-efuse";
- reg = <0x200 0x68>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- /* Data cells */
- usb_rterm0: trim@54,4 {
- reg = <0x54 1>;
- bits = <4 2>;
- };
- usb_rterm1: trim@55,4 {
- reg = <0x55 1>;
- bits = <4 2>;
- };
- usb_rterm2: trim@58,4 {
- reg = <0x58 1>;
- bits = <4 2>;
- };
- usb_rterm3: trim@59,4 {
- reg = <0x59 1>;
- bits = <4 2>;
- };
- usb_sel_t0: trim@54,0 {
- reg = <0x54 1>;
- bits = <0 4>;
- };
- usb_sel_t1: trim@55,0 {
- reg = <0x55 1>;
- bits = <0 4>;
- };
- usb_sel_t2: trim@58,0 {
- reg = <0x58 1>;
- bits = <0 4>;
- };
- usb_sel_t3: trim@59,0 {
- reg = <0x59 1>;
- bits = <0 4>;
- };
- usb_hs_i0: trim@56,0 {
- reg = <0x56 1>;
- bits = <0 4>;
- };
- usb_hs_i2: trim@5a,0 {
- reg = <0x5a 1>;
- bits = <0 4>;
- };
+ usb_rterm1: trim@55,4 {
+ reg = <0x55 1>;
+ bits = <4 2>;
+ };
+ usb_rterm2: trim@58,4 {
+ reg = <0x58 1>;
+ bits = <4 2>;
+ };
+ usb_rterm3: trim@59,4 {
+ reg = <0x59 1>;
+ bits = <4 2>;
+ };
+ usb_sel_t0: trim@54,0 {
+ reg = <0x54 1>;
+ bits = <0 4>;
+ };
+ usb_sel_t1: trim@55,0 {
+ reg = <0x55 1>;
+ bits = <0 4>;
+ };
+ usb_sel_t2: trim@58,0 {
+ reg = <0x58 1>;
+ bits = <0 4>;
+ };
+ usb_sel_t3: trim@59,0 {
+ reg = <0x59 1>;
+ bits = <0 4>;
+ };
+ usb_hs_i0: trim@56,0 {
+ reg = <0x56 1>;
+ bits = <0 4>;
+ };
+ usb_hs_i2: trim@5a,0 {
+ reg = <0x5a 1>;
+ bits = <0 4>;
};
};
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
index 60cf3cb..bbbad31 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
@@ -50,12 +50,22 @@
opp-supported-hw:
description: |
A single 32 bit bitmap value, representing compatible HW.
- Bitmap:
+ Bitmap for MSM8996 format:
0: MSM8996, speedbin 0
1: MSM8996, speedbin 1
2: MSM8996, speedbin 2
- 3-31: unused
- maximum: 0x7
+ 3: MSM8996, speedbin 3
+ 4-31: unused
+
+ Bitmap for MSM8996SG format (speedbin shifted of 4 left):
+ 0-3: unused
+ 4: MSM8996SG, speedbin 0
+ 5: MSM8996SG, speedbin 1
+ 6: MSM8996SG, speedbin 2
+ 7-31: unused
+ enum: [0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
+ 0x9, 0xd, 0xe, 0xf,
+ 0x10, 0x20, 0x30, 0x70]
clock-latency-ns: true
@@ -106,6 +116,7 @@
L2_0: l2-cache {
compatible = "cache";
cache-level = <2>;
+ cache-unified;
};
};
@@ -140,6 +151,7 @@
L2_1: l2-cache {
compatible = "cache";
cache-level = <2>;
+ cache-unified;
};
};
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
index b9ce2e0..a30ef93 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
@@ -30,7 +30,9 @@
this OPP node. Sometimes several corners/levels shares a certain fuse
corner/level. A fuse corner/level contains e.g. ref uV, min uV,
and max uV.
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
required:
- opp-level
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index bad9809..f13f87f 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -24,6 +24,9 @@
- fsl,imx8mq-pcie
- fsl,imx8mm-pcie
- fsl,imx8mp-pcie
+ - fsl,imx8mm-pcie-ep
+ - fsl,imx8mq-pcie-ep
+ - fsl,imx8mp-pcie-ep
reg:
items:
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
index 8d7eb51..89cfdee 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
@@ -47,8 +47,10 @@
enable registers
$ref: "/schemas/types.yaml#/definitions/phandle-array"
items:
- minItems: 3
- maxItems: 3
+ - items:
+ - description: Syscon to TCSR system registers
+ - description: Perst enable offset
+ - description: Perst separation enable offset
interrupts:
items:
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index a5859bb..fb32c43 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -16,25 +16,31 @@
properties:
compatible:
- enum:
- - qcom,pcie-ipq8064
- - qcom,pcie-ipq8064-v2
- - qcom,pcie-apq8064
- - qcom,pcie-apq8084
- - qcom,pcie-msm8996
- - qcom,pcie-ipq4019
- - qcom,pcie-ipq8074
- - qcom,pcie-qcs404
- - qcom,pcie-sa8540p
- - qcom,pcie-sc7280
- - qcom,pcie-sc8180x
- - qcom,pcie-sc8280xp
- - qcom,pcie-sdm845
- - qcom,pcie-sm8150
- - qcom,pcie-sm8250
- - qcom,pcie-sm8450-pcie0
- - qcom,pcie-sm8450-pcie1
- - qcom,pcie-ipq6018
+ oneOf:
+ - enum:
+ - qcom,pcie-apq8064
+ - qcom,pcie-apq8084
+ - qcom,pcie-ipq4019
+ - qcom,pcie-ipq6018
+ - qcom,pcie-ipq8064
+ - qcom,pcie-ipq8064-v2
+ - qcom,pcie-ipq8074
+ - qcom,pcie-ipq8074-gen3
+ - qcom,pcie-msm8996
+ - qcom,pcie-qcs404
+ - qcom,pcie-sa8540p
+ - qcom,pcie-sc7280
+ - qcom,pcie-sc8180x
+ - qcom,pcie-sc8280xp
+ - qcom,pcie-sdm845
+ - qcom,pcie-sm8150
+ - qcom,pcie-sm8250
+ - qcom,pcie-sm8350
+ - qcom,pcie-sm8450-pcie0
+ - qcom,pcie-sm8450-pcie1
+ - items:
+ - const: qcom,pcie-msm8998
+ - const: qcom,pcie-msm8996
reg:
minItems: 4
@@ -153,6 +159,7 @@
contains:
enum:
- qcom,pcie-ipq6018
+ - qcom,pcie-ipq8074-gen3
then:
properties:
reg:
@@ -195,6 +202,7 @@
- qcom,pcie-sc8180x
- qcom,pcie-sc8280xp
- qcom,pcie-sm8250
+ - qcom,pcie-sm8350
- qcom,pcie-sm8450-pcie0
- qcom,pcie-sm8450-pcie1
then:
@@ -312,27 +320,17 @@
enum:
- qcom,pcie-msm8996
then:
- oneOf:
- - properties:
- clock-names:
- items:
- - const: pipe # Pipe Clock driving internal logic
- - const: aux # Auxiliary (AUX) clock
- - const: cfg # Configuration clock
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - properties:
- clock-names:
- items:
- - const: pipe # Pipe Clock driving internal logic
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - const: cfg # Configuration clock
- - const: aux # Auxiliary (AUX) clock
properties:
clocks:
minItems: 5
maxItems: 5
+ clock-names:
+ items:
+ - const: pipe # Pipe Clock driving internal logic
+ - const: aux # Auxiliary (AUX) clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
resets: false
reset-names: false
@@ -373,6 +371,7 @@
contains:
enum:
- qcom,pcie-ipq6018
+ - qcom,pcie-ipq8074-gen3
then:
properties:
clocks:
@@ -555,6 +554,35 @@
compatible:
contains:
enum:
+ - qcom,pcie-sm8350
+ then:
+ properties:
+ clocks:
+ minItems: 8
+ maxItems: 9
+ clock-names:
+ minItems: 8
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: tbu # PCIe TBU clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - const: aggre1 # Aggre NoC PCIe1 AXI clock
+ - const: aggre0 # Aggre NoC PCIe0 AXI clock
+ resets:
+ maxItems: 1
+ reset-names:
+ items:
+ - const: pci # PCIe core reset
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pcie-sm8450-pcie0
then:
properties:
@@ -664,6 +692,7 @@
- qcom,pcie-ipq8064
- qcom,pcie-ipq8064v2
- qcom,pcie-ipq8074
+ - qcom,pcie-ipq8074-gen3
- qcom,pcie-qcs404
then:
required:
@@ -692,6 +721,7 @@
- qcom,pcie-sdm845
- qcom,pcie-sm8150
- qcom,pcie-sm8250
+ - qcom,pcie-sm8350
- qcom,pcie-sm8450-pcie0
- qcom,pcie-sm8450-pcie1
then:
@@ -746,6 +776,7 @@
- qcom,pcie-ipq8064
- qcom,pcie-ipq8064-v2
- qcom,pcie-ipq8074
+ - qcom,pcie-ipq8074-gen3
- qcom,pcie-qcs404
- qcom,pcie-sa8540p
then:
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml
new file mode 100644
index 0000000..a8574f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip,rk3399-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip AXI PCIe Bridge Common Properties
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+properties:
+ reg:
+ maxItems: 2
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: aclk-perf
+ - const: hclk
+ - const: pm
+
+ num-lanes:
+ maximum: 4
+
+ phys:
+ oneOf:
+ - maxItems: 1
+ - maxItems: 4
+
+ phy-names:
+ oneOf:
+ - const: pcie-phy
+ - items:
+ - const: pcie-phy-0
+ - const: pcie-phy-1
+ - const: pcie-phy-2
+ - const: pcie-phy-3
+
+ resets:
+ maxItems: 7
+
+ reset-names:
+ items:
+ - const: core
+ - const: mgmt
+ - const: mgmt-sticky
+ - const: pipe
+ - const: pm
+ - const: pclk
+ - const: aclk
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - phys
+ - phy-names
+ - resets
+ - reset-names
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
new file mode 100644
index 0000000..88386a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip,rk3399-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip AXI PCIe Endpoint
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-ep.yaml#
+ - $ref: rockchip,rk3399-pcie-common.yaml#
+
+properties:
+ compatible:
+ const: rockchip,rk3399-pcie-ep
+
+ reg: true
+
+ reg-names:
+ items:
+ - const: apb-base
+ - const: mem-base
+
+ rockchip,max-outbound-regions:
+ description: Maximum number of outbound regions
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 32
+ default: 32
+
+required:
+ - rockchip,max-outbound-regions
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/rk3399-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie-ep@f8000000 {
+ compatible = "rockchip,rk3399-pcie-ep";
+ reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0x80000000 0x0 0x20000>;
+ reg-names = "apb-base", "mem-base";
+ clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
+ <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
+ clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+ max-functions = /bits/ 8 <8>;
+ num-lanes = <4>;
+ resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
+ <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
+ <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
+ reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+ "pm", "pclk", "aclk";
+ phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
+ phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
+ rockchip,max-outbound-regions = <16>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
new file mode 100644
index 0000000..531008f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip,rk3399-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip AXI PCIe Root Port Bridge Host
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: rockchip,rk3399-pcie-common.yaml#
+
+properties:
+ compatible:
+ const: rockchip,rk3399-pcie
+
+ reg: true
+
+ reg-names:
+ items:
+ - const: axi-base
+ - const: apb-base
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: sys
+ - const: legacy
+ - const: client
+
+ aspm-no-l0s:
+ description: This property is needed if using 24MHz OSC for RC's PHY.
+
+ ep-gpios:
+ description: pre-reset GPIO
+
+ vpcie12v-supply:
+ description: The 12v regulator to use for PCIe.
+
+ vpcie3v3-supply:
+ description: The 3.3v regulator to use for PCIe.
+
+ vpcie1v8-supply:
+ description: The 1.8v regulator to use for PCIe.
+
+ vpcie0v9-supply:
+ description: The 0.9v regulator to use for PCIe.
+
+ interrupt-controller:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 0
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+required:
+ - ranges
+ - "#interrupt-cells"
+ - interrupts
+ - interrupt-controller
+ - interrupt-map
+ - interrupt-map-mask
+ - msi-map
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/rk3399-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@f8000000 {
+ compatible = "rockchip,rk3399-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
+ <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
+ clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "sys", "legacy", "client";
+ ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
+ 0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
+ num-lanes = <4>;
+ msi-map = <0x0 &its 0x0 0x1000>;
+ reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
+ reg-names = "axi-base", "apb-base";
+ resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
+ <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
+ <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
+ reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+ "pm", "pclk", "aclk";
+ /* deprecated legacy PHY model */
+ phys = <&pcie_phy>;
+ phy-names = "pcie-phy";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreq>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 0>,
+ <0 0 0 2 &pcie0_intc 1>,
+ <0 0 0 3 &pcie0_intc 2>,
+ <0 0 0 4 &pcie0_intc 3>;
+
+ pcie0_intc: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt
deleted file mode 100644
index 77846730..0000000
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* Rockchip AXI PCIe Endpoint Controller DT description
-
-Required properties:
-- compatible: Should contain "rockchip,rk3399-pcie-ep"
-- reg: Two register ranges as listed in the reg-names property
-- reg-names: Must include the following names
- - "apb-base"
- - "mem-base"
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - "aclk"
- - "aclk-perf"
- - "hclk"
- - "pm"
-- resets: Must contain seven entries for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following names
- - "core"
- - "mgmt"
- - "mgmt-sticky"
- - "pipe"
- - "pm"
- - "aclk"
- - "pclk"
-- pinctrl-names : The pin control state names
-- pinctrl-0: The "default" pinctrl state
-- phys: Must contain an phandle to a PHY for each entry in phy-names.
-- phy-names: Must include 4 entries for all 4 lanes even if some of
- them won't be used for your cases. Entries are of the form "pcie-phy-N":
- where N ranges from 0 to 3.
- (see example below and you MUST also refer to ../phy/rockchip-pcie-phy.txt
- for changing the #phy-cells of phy node to support it)
-- rockchip,max-outbound-regions: Maximum number of outbound regions
-
-Optional Property:
-- num-lanes: number of lanes to use
-- max-functions: Maximum number of functions that can be configured (default 1).
-
-pcie0-ep: pcie@f8000000 {
- compatible = "rockchip,rk3399-pcie-ep";
- #address-cells = <3>;
- #size-cells = <2>;
- rockchip,max-outbound-regions = <16>;
- clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
- <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
- clock-names = "aclk", "aclk-perf",
- "hclk", "pm";
- max-functions = /bits/ 8 <8>;
- num-lanes = <4>;
- reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0x80000000 0x0 0x20000>;
- reg-names = "apb-base", "mem-base";
- resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
- <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
- <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
- reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
- "pm", "pclk", "aclk";
- phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
- phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
- pinctrl-names = "default";
- pinctrl-0 = <&pcie_clkreq>;
-};
diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt
deleted file mode 100644
index af34c65..0000000
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt
+++ /dev/null
@@ -1,135 +0,0 @@
-* Rockchip AXI PCIe Root Port Bridge DT description
-
-Required properties:
-- #address-cells: Address representation for root ports, set to <3>
-- #size-cells: Size representation for root ports, set to <2>
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- compatible: Should contain "rockchip,rk3399-pcie"
-- reg: Two register ranges as listed in the reg-names property
-- reg-names: Must include the following names
- - "axi-base"
- - "apb-base"
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - "aclk"
- - "aclk-perf"
- - "hclk"
- - "pm"
-- msi-map: Maps a Requester ID to an MSI controller and associated
- msi-specifier data. See ./pci-msi.txt
-- interrupts: Three interrupt entries must be specified.
-- interrupt-names: Must include the following names
- - "sys"
- - "legacy"
- - "client"
-- resets: Must contain seven entries for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following names
- - "core"
- - "mgmt"
- - "mgmt-sticky"
- - "pipe"
- - "pm"
- - "aclk"
- - "pclk"
-- pinctrl-names : The pin control state names
-- pinctrl-0: The "default" pinctrl state
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- interrupt-map-mask and interrupt-map: standard PCI properties
-
-Required properties for legacy PHY model (deprecated):
-- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
-- phy-names: MUST be "pcie-phy".
-
-Required properties for per-lane PHY model (preferred):
-- phys: Must contain an phandle to a PHY for each entry in phy-names.
-- phy-names: Must include 4 entries for all 4 lanes even if some of
- them won't be used for your cases. Entries are of the form "pcie-phy-N":
- where N ranges from 0 to 3.
- (see example below and you MUST also refer to ../phy/rockchip-pcie-phy.txt
- for changing the #phy-cells of phy node to support it)
-
-Optional Property:
-- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if
- using 24MHz OSC for RC's PHY.
-- ep-gpios: contain the entry for pre-reset GPIO
-- num-lanes: number of lanes to use
-- vpcie12v-supply: The phandle to the 12v regulator to use for PCIe.
-- vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
-- vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
-- vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
-
-*Interrupt controller child node*
-The core controller provides a single interrupt for legacy INTx. The PCIe node
-should contain an interrupt controller node as a target for the PCI
-'interrupt-map' property. This node represents the domain at which the four
-INTx interrupts are decoded and routed.
-
-
-Required properties for Interrupt controller child node:
-- interrupt-controller: identifies the node as an interrupt controller
-- #address-cells: specifies the number of cells needed to encode an
- address. The value must be 0.
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-
-Example:
-
-pcie0: pcie@f8000000 {
- compatible = "rockchip,rk3399-pcie";
- #address-cells = <3>;
- #size-cells = <2>;
- clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
- <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
- clock-names = "aclk", "aclk-perf",
- "hclk", "pm";
- bus-range = <0x0 0x1>;
- interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "sys", "legacy", "client";
- assigned-clocks = <&cru SCLK_PCIEPHY_REF>;
- assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>;
- assigned-clock-rates = <100000000>;
- ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
- ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
- 0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
- num-lanes = <4>;
- msi-map = <0x0 &its 0x0 0x1000>;
- reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
- reg-names = "axi-base", "apb-base";
- resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
- <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
- <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
- reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
- "pm", "pclk", "aclk";
- /* deprecated legacy PHY model */
- phys = <&pcie_phy>;
- phy-names = "pcie-phy";
- pinctrl-names = "default";
- pinctrl-0 = <&pcie_clkreq>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie0_intc 0>,
- <0 0 0 2 &pcie0_intc 1>,
- <0 0 0 3 &pcie0_intc 2>,
- <0 0 0 4 &pcie0_intc 3>;
- pcie0_intc: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
-};
-
-pcie0: pcie@f8000000 {
- ...
-
- /* preferred per-lane PHY model */
- phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
- phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
index 437e616..f0d8e48 100644
--- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
@@ -15,9 +15,6 @@
maintainers:
- Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-allOf:
- - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
-
properties:
compatible:
enum:
@@ -29,40 +26,25 @@
maxItems: 5
reg-names:
- oneOf:
- - items:
- - const: dbi
- - const: dbi2
- - const: link
- - const: addr_space
- - items:
- - const: dbi
- - const: dbi2
- - const: link
- - const: addr_space
- - const: atu
+ minItems: 4
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: link
+ - const: addr_space
+ - const: atu
clocks:
minItems: 1
maxItems: 2
- clock-names:
- oneOf:
- - items: # for Pro5
- - const: gio
- - const: link
- - const: link # for NX1
+ clock-names: true
resets:
minItems: 1
maxItems: 2
- reset-names:
- oneOf:
- - items: # for Pro5
- - const: gio
- - const: link
- - const: link # for NX1
+ reset-names: true
num-ib-windows:
const: 16
@@ -78,6 +60,46 @@
phy-names:
const: pcie-phy
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-pro5-pcie-ep
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ reg-names:
+ maxItems: 4
+ clocks:
+ minItems: 2
+ clock-names:
+ items:
+ - const: gio
+ - const: link
+ resets:
+ minItems: 2
+ reset-names:
+ items:
+ - const: gio
+ - const: link
+ else:
+ properties:
+ reg:
+ minItems: 5
+ reg-names:
+ minItems: 5
+ clocks:
+ maxItems: 1
+ clock-names:
+ const: link
+ resets:
+ maxItems: 1
+ reset-names:
+ const: link
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
index b0513b1..3d7aee9 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
@@ -66,15 +66,11 @@
const: 0x104c
device-id:
- oneOf:
- - items:
- - const: 0xb00d
- - items:
- - const: 0xb00f
- - items:
- - const: 0xb010
- - items:
- - const: 0xb013
+ enum:
+ - 0xb00d
+ - 0xb00f
+ - 0xb010
+ - 0xb013
msi-map: true
diff --git a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
new file mode 100644
index 0000000..a55a4d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/riscv,pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V SBI PMU events
+
+maintainers:
+ - Atish Patra <atishp@rivosinc.com>
+
+description: |
+ The SBI PMU extension allows supervisor software to configure, start and
+ stop any performance counter at anytime. Thus, a user can leverage all
+ capabilities of performance analysis tools, such as perf, if the SBI PMU
+ extension is enabled. The following constraints apply:
+
+ The platform must provide information about PMU event to counter mappings
+ either via device tree or another way, specific to the platform.
+ Without the event to counter mappings, the SBI PMU extension cannot be used.
+
+ Platforms should provide information about the PMU event selector values
+ that should be encoded in the expected value of MHPMEVENTx while configuring
+ MHPMCOUNTERx for that specific event. The can either be done via device tree
+ or another way, specific to the platform.
+ The exact value to be written to MHPMEVENTx is completely dependent on the
+ platform.
+
+ For information on the SBI specification see the section "Performance
+ Monitoring Unit Extension" of:
+ https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc
+
+properties:
+ compatible:
+ const: riscv,pmu
+
+ riscv,event-to-mhpmevent:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Represents an ONE-to-ONE mapping between a PMU event and the event
+ selector value that the platform expects to be written to the MHPMEVENTx
+ CSR for that event.
+ The mapping is encoded in an matrix format where each element represents
+ an event.
+ This property shouldn't encode any raw hardware event.
+ items:
+ items:
+ - description: event_idx, a 20-bit wide encoding of the event type and
+ code. Refer to the SBI specification for a complete description of
+ the event types and codes.
+ - description: upper 32 bits of the event selector value for MHPMEVENTx
+ - description: lower 32 bits of the event selector value for MHPMEVENTx
+
+ riscv,event-to-mhpmcounters:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Represents a MANY-to-MANY mapping between a range of events and all the
+ MHPMCOUNTERx in a bitmap format that can be used to monitor these range
+ of events. The information is encoded in an matrix format where each
+ element represents a certain range of events and corresponding counters.
+ This property shouldn't encode any raw event.
+ items:
+ items:
+ - description: first event_idx of the range of events
+ - description: last event_idx of the range of events
+ - description: bitmap of MHPMCOUNTERx for this event
+
+ riscv,raw-event-to-mhpmcounters:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Represents an ONE-to-MANY or MANY-to-MANY mapping between the rawevent(s)
+ and all the MHPMCOUNTERx in a bitmap format that can be used to monitor
+ that raw event.
+ The encoding of the raw events are platform specific. The information is
+ encoded in a matrix format where each element represents the specific raw
+ event(s).
+ If a platform directly encodes each raw PMU event as a unique ID, the
+ value of variant must be 0xffffffff_ffffffff.
+ items:
+ items:
+ - description:
+ upper 32 invariant bits for the range of events
+ - description:
+ lower 32 invariant bits for the range of events
+ - description:
+ upper 32 bits of the variant bit mask for the range of events
+ - description:
+ lower 32 bits of the variant bit mask for the range of events
+ - description:
+ bitmap of all MHPMCOUNTERx that can monitor the range of events
+
+dependencies:
+ "riscv,event-to-mhpmevent": [ "riscv,event-to-mhpmcounters" ]
+ "riscv,event-to-mhpmcounters": [ "riscv,event-to-mhpmevent" ]
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pmu {
+ compatible = "riscv,pmu";
+ riscv,event-to-mhpmevent = <0x0000B 0x0000 0x0001>;
+ riscv,event-to-mhpmcounters = <0x00001 0x00001 0x00000001>,
+ <0x00002 0x00002 0x00000004>,
+ <0x00003 0x0000A 0x00000ff8>,
+ <0x10000 0x10033 0x000ff000>;
+ riscv,raw-event-to-mhpmcounters =
+ /* For event ID 0x0002 */
+ <0x0000 0x0002 0xffffffff 0xffffffff 0x00000f8>,
+ /* For event ID 0-4 */
+ <0x0 0x0 0xffffffff 0xfffffff0 0x00000ff0>,
+ /* For event ID 0xffffffff0000000f - 0xffffffff000000ff */
+ <0xffffffff 0x0 0xffffffff 0xffffff0f 0x00000ff0>;
+ };
+
+ - |
+ /*
+ * For HiFive Unmatched board the encodings can be found here
+ * https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf
+ *
+ * This example also binds standard SBI PMU hardware IDs to U74 PMU event
+ * codes, U74 uses a bitfield for events encoding, so several U74 events
+ * can be bound to a single perf ID.
+ * See SBI PMU hardware IDs in arch/riscv/include/asm/sbi.h
+ */
+ pmu {
+ compatible = "riscv,pmu";
+ riscv,event-to-mhpmevent =
+ /* SBI_PMU_HW_CACHE_REFERENCES -> Instruction or Data cache/ITIM busy */
+ <0x00003 0x00000000 0x1801>,
+ /* SBI_PMU_HW_CACHE_MISSES -> Instruction or Data cache miss or MMIO access */
+ <0x00004 0x00000000 0x0302>,
+ /* SBI_PMU_HW_BRANCH_INSTRUCTIONS -> Conditional branch retired */
+ <0x00005 0x00000000 0x4000>,
+ /* SBI_PMU_HW_BRANCH_MISSES -> Branch or jump misprediction */
+ <0x00006 0x00000000 0x6001>,
+ /* L1D_READ_MISS -> Data cache miss or MMIO access */
+ <0x10001 0x00000000 0x0202>,
+ /* L1D_WRITE_ACCESS -> Data cache write-back */
+ <0x10002 0x00000000 0x0402>,
+ /* L1I_READ_ACCESS -> Instruction cache miss */
+ <0x10009 0x00000000 0x0102>,
+ /* LL_READ_MISS -> UTLB miss */
+ <0x10011 0x00000000 0x2002>,
+ /* DTLB_READ_MISS -> Data TLB miss */
+ <0x10019 0x00000000 0x1002>,
+ /* ITLB_READ_MISS-> Instruction TLB miss */
+ <0x10021 0x00000000 0x0802>;
+ riscv,event-to-mhpmcounters = <0x00003 0x00006 0x18>,
+ <0x10001 0x10002 0x18>,
+ <0x10009 0x10009 0x18>,
+ <0x10011 0x10011 0x18>,
+ <0x10019 0x10019 0x18>,
+ <0x10021 0x10021 0x18>;
+ riscv,raw-event-to-mhpmcounters = <0x0 0x0 0xffffffff 0xfc0000ff 0x18>,
+ <0x0 0x1 0xffffffff 0xfff800ff 0x18>,
+ <0x0 0x2 0xffffffff 0xffffe0ff 0x18>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml
new file mode 100644
index 0000000..9488394
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/allwinner,suniv-f1c100s-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner F1C100s USB PHY
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <mripard@kernel.org>
+
+properties:
+ "#phy-cells":
+ const: 1
+
+ compatible:
+ const: allwinner,suniv-f1c100s-usb-phy
+
+ reg:
+ maxItems: 1
+ description: PHY Control registers
+
+ reg-names:
+ const: phy_ctrl
+
+ clocks:
+ maxItems: 1
+ description: USB OTG PHY bus clock
+
+ clock-names:
+ const: usb0_phy
+
+ resets:
+ maxItems: 1
+ description: USB OTG reset
+
+ reset-names:
+ const: usb0_reset
+
+ usb0_id_det-gpios:
+ maxItems: 1
+ description: GPIO to the USB OTG ID pin
+
+ usb0_vbus_det-gpios:
+ maxItems: 1
+ description: GPIO to the USB OTG VBUS detect pin
+
+ usb0_vbus_power-supply:
+ description: Power supply to detect the USB OTG VBUS
+
+ usb0_vbus-supply:
+ description: Regulator controlling USB OTG VBUS
+
+required:
+ - "#phy-cells"
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - reg-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/suniv-ccu-f1c100s.h>
+ #include <dt-bindings/reset/suniv-ccu-f1c100s.h>
+
+ phy@1c13400 {
+ compatible = "allwinner,suniv-f1c100s-usb-phy";
+ reg = <0x01c13400 0x10>;
+ reg-names = "phy_ctrl";
+ clocks = <&ccu CLK_USB_PHY0>;
+ clock-names = "usb0_phy";
+ resets = <&ccu RST_USB_PHY0>;
+ reset-names = "usb0_reset";
+ #phy-cells = <1>;
+ usb0_id_det-gpios = <&pio 4 2 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml
index 129d26e..3314711 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml
@@ -35,6 +35,11 @@
"#phy-cells":
const: 1
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml
new file mode 100644
index 0000000..c2f5c9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/amlogic,meson-gxl-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson GXL USB2 PHY
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ const: amlogic,meson-gxl-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: phy
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 0
+
+ phy-supply: true
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@78000 {
+ compatible = "amlogic,meson-gxl-usb2-phy";
+ reg = <0x78000 0x20>;
+ clocks = <&xtal>;
+ clock-names = "phy";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ phy-supply = <&usb2_supply>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
index 20b79e2..b11d987 100644
--- a/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
@@ -27,7 +27,8 @@
description: phandle of syscon used to control usb tcxo.
hisilicon,eye-diagram-param:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: Eye diagram for phy.
required:
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
index 1cb00db..3c69aca 100644
--- a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
@@ -32,7 +32,8 @@
description: phandle of syscon used to control phy deep sleep.
hisilicon,eye-diagram-param:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: Eye diagram for phy.
hisilicon,tx-vboost-lvl:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index 5613cc5..230a17f 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -79,6 +79,7 @@
- enum:
- mediatek,mt2712-tphy
- mediatek,mt7629-tphy
+ - mediatek,mt7986-tphy
- mediatek,mt8183-tphy
- mediatek,mt8186-tphy
- mediatek,mt8192-tphy
diff --git a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
deleted file mode 100644
index b84a02e..0000000
--- a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Amlogic Meson GXL and GXM USB2 PHY binding
-
-Required properties:
-- compatible: Should be "amlogic,meson-gxl-usb2-phy"
-- reg: The base address and length of the registers
-- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
-
-Optional properties:
-- clocks: a phandle to the clock of this PHY
-- clock-names: must be "phy"
-- resets: a phandle to the reset line of this PHY
-- reset-names: must be "phy"
-- phy-supply: see phy-bindings.txt in this directory
-
-
-Example:
- usb2_phy0: phy@78000 {
- compatible = "amlogic,meson-gxl-usb2-phy";
- #phy-cells = <0>;
- reg = <0x0 0x78000 0x0 0x20>;
- };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
deleted file mode 100644
index b62397d..0000000
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
+++ /dev/null
@@ -1,779 +0,0 @@
-Device tree binding for NVIDIA Tegra XUSB pad controller
-========================================================
-
-The Tegra XUSB pad controller manages a set of I/O lanes (with differential
-signals) which connect directly to pins/pads on the SoC package. Each lane
-is controlled by a HW block referred to as a "pad" in the Tegra hardware
-documentation. Each such "pad" may control either one or multiple lanes,
-and thus contains any logic common to all its lanes. Each lane can be
-separately configured and powered up.
-
-Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
-super-speed USB. Other lanes are for various types of low-speed, full-speed
-or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
-contains a software-configurable mux that sits between the I/O controller
-ports (e.g. PCIe) and the lanes.
-
-In addition to per-lane configuration, USB 3.0 ports may require additional
-settings on a per-board basis.
-
-Pads will be represented as children of the top-level XUSB pad controller
-device tree node. Each lane exposed by the pad will be represented by its
-own subnode and can be referenced by users of the lane using the standard
-PHY bindings, as described by the phy-bindings.txt file in this directory.
-
-The Tegra hardware documentation refers to the connection between the XUSB
-pad controller and the XUSB controller as "ports". This is confusing since
-"port" is typically used to denote the physical USB receptacle. The device
-tree binding in this document uses the term "port" to refer to the logical
-abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
-for the USB signal, the VBUS power supply, the USB 2.0 companion port for
-USB 3.0 receptacles, ...).
-
-Required properties:
---------------------
-- compatible: Must be:
- - Tegra124: "nvidia,tegra124-xusb-padctl"
- - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
- - Tegra210: "nvidia,tegra210-xusb-padctl"
- - Tegra186: "nvidia,tegra186-xusb-padctl"
- - Tegra194: "nvidia,tegra194-xusb-padctl"
-- reg: Physical base address and length of the controller's registers.
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must include the following entries:
- - "padctl"
-
-For Tegra124:
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- avdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
-
-For Tegra210:
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V.
-- nvidia,pmc: phandle and specifier referring to the Tegra210 PMC node.
-
-For Tegra186:
-- avdd-pll-erefeut-supply: UPHY brick and reference clock as well as UTMI PHY
- power supply. Must supply 1.8 V.
-- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
- 3.3 V.
-- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
-- vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V.
-
-For Tegra194:
-- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
- 3.3 V.
-- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
-
-Pad nodes:
-==========
-
-A required child node named "pads" contains a list of subnodes, one for each
-of the pads exposed by the XUSB pad controller. Each pad may need additional
-resources that can be referenced in its pad node.
-
-The "status" property is used to enable or disable the use of a pad. If set
-to "disabled", the pad will not be used on the given board. In order to use
-the pad and any of its lanes, this property must be set to "okay".
-
-For Tegra124 and Tegra132, the following pads exist: usb2, ulpi, hsic, pcie
-and sata. No extra resources are required for operation of these pads.
-
-For Tegra210, the following pads exist: usb2, hsic, pcie and sata. Below is
-a description of the properties of each pad.
-
-UTMI pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "trk": phandle and specifier referring to the USB2 tracking clock
-
-HSIC pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "trk": phandle and specifier referring to the HSIC tracking clock
-
-PCIe pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "pll": phandle and specifier referring to the PLLE
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must contain the following entries:
- - "phy": reset for the PCIe UPHY block
-
-SATA pad:
----------
-
-Required properties:
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must contain the following entries:
- - "phy": reset for the SATA UPHY block
-
-
-PHY nodes:
-==========
-
-Each pad node has a child named "lanes" that contains one or more children of
-its own, each representing one of the lanes controlled by the pad.
-
-Required properties:
---------------------
-- status: Defines the operation status of the PHY. Valid values are:
- - "disabled": the PHY is disabled
- - "okay": the PHY is enabled
-- #phy-cells: Should be 0. Since each lane represents a single PHY, there is
- no need for an additional specifier.
-- nvidia,function: The output function of the PHY. See below for a list of
- valid functions per SoC generation.
-
-For Tegra124 and Tegra132, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2
- - functions: "snps", "xusb", "uart"
-- ulpi: ulpi-0
- - functions: "snps", "xusb"
-- hsic: hsic-0, hsic-1
- - functions: "snps", "xusb"
-- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4
- - functions: "pcie", "usb3-ss"
-- sata: sata-0
- - functions: "usb3-ss", "sata"
-
-For Tegra210, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2, usb2-3
- - functions: "snps", "xusb", "uart"
-- hsic: hsic-0, hsic-1
- - functions: "snps", "xusb"
-- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6
- - functions: "pcie-x1", "usb3-ss", "pcie-x4"
-- sata: sata-0
- - functions: "usb3-ss", "sata"
-
-For Tegra194, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2, usb2-3
- - functions: "xusb"
-- usb3: usb3-0, usb3-1, usb3-2, usb3-3
- - functions: "xusb"
-
-Port nodes:
-===========
-
-A required child node named "ports" contains a list of all the ports exposed
-by the XUSB pad controller. Per-port configuration is only required for USB.
-
-USB2 ports:
------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- mode: A string that determines the mode in which to run the port. Valid
- values are:
- - "host": for USB host mode
- - "device": for USB device mode
- - "otg": for USB OTG mode
-
-Required properties for OTG/Peripheral capable USB2 ports:
-- usb-role-switch: Boolean property to indicate that the port support OTG or
- peripheral mode. If present, the port supports switching between USB host
- and peripheral roles. Connector should be added as subnode.
- See usb/usb-conn-gpio.txt.
-
-Optional properties:
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-ULPI ports:
------------
-
-Optional properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-HSIC ports:
------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-
-Optional properties:
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-Super-speed USB ports:
-----------------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- nvidia,usb2-companion: A single cell that specifies the physical port number
- to map this super-speed USB port to. The range of valid port numbers varies
- with the SoC generation:
- - 0-2: for Tegra124 and Tegra132
- - 0-3: for Tegra210
-
-Optional properties:
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-
-- maximum-speed: Only for Tegra194. A string property that specifies maximum
- supported speed of a usb3 port. Valid values are:
- - "super-speed-plus": default, the usb3 port supports USB 3.1 Gen 2 speed.
- - "super-speed": the usb3 port supports USB 3.1 Gen 1 speed only.
-
-For Tegra124 and Tegra132, the XUSB pad controller exposes the following
-ports:
-- 3x USB2: usb2-0, usb2-1, usb2-2
-- 1x ULPI: ulpi-0
-- 2x HSIC: hsic-0, hsic-1
-- 2x super-speed USB: usb3-0, usb3-1
-
-For Tegra210, the XUSB pad controller exposes the following ports:
-- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
-- 2x HSIC: hsic-0, hsic-1
-- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
-
-For Tegra194, the XUSB pad controller exposes the following ports:
-- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
-- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
-
-Examples:
-=========
-
-Tegra124 and Tegra132:
-----------------------
-
-SoC include:
-
- padctl@7009f000 {
- /* for Tegra124 */
- compatible = "nvidia,tegra124-xusb-padctl";
- /* for Tegra132 */
- compatible = "nvidia,tegra132-xusb-padctl",
- "nvidia,tegra124-xusb-padctl";
- reg = <0x0 0x7009f000 0x0 0x1000>;
- resets = <&tegra_car 142>;
- reset-names = "padctl";
-
- pads {
- usb2 {
- status = "disabled";
-
- lanes {
- usb2-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- ulpi {
- status = "disabled";
-
- lanes {
- ulpi-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- hsic {
- status = "disabled";
-
- lanes {
- hsic-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- hsic-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- pcie {
- status = "disabled";
-
- lanes {
- pcie-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-4 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- sata {
- status = "disabled";
-
- lanes {
- sata-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "disabled";
- };
-
- usb2-1 {
- status = "disabled";
- };
-
- usb2-2 {
- status = "disabled";
- };
-
- ulpi-0 {
- status = "disabled";
- };
-
- hsic-0 {
- status = "disabled";
- };
-
- hsic-1 {
- status = "disabled";
- };
-
- usb3-0 {
- status = "disabled";
- };
-
- usb3-1 {
- status = "disabled";
- };
- };
- };
-
-Board file:
-
- padctl@7009f000 {
- status = "okay";
-
- pads {
- usb2 {
- status = "okay";
-
- lanes {
- usb2-0 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-1 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-2 {
- nvidia,function = "xusb";
- status = "okay";
- };
- };
- };
-
- pcie {
- status = "okay";
-
- lanes {
- pcie-0 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
-
- pcie-2 {
- nvidia,function = "pcie";
- status = "okay";
- };
-
- pcie-4 {
- nvidia,function = "pcie";
- status = "okay";
- };
- };
- };
-
- sata {
- status = "okay";
-
- lanes {
- sata-0 {
- nvidia,function = "sata";
- status = "okay";
- };
- };
- };
- };
-
- ports {
- /* Micro A/B */
- usb2-0 {
- status = "okay";
- mode = "otg";
- };
-
- /* Mini PCIe */
- usb2-1 {
- status = "okay";
- mode = "host";
- };
-
- /* USB3 */
- usb2-2 {
- status = "okay";
- mode = "host";
-
- vbus-supply = <&vdd_usb3_vbus>;
- };
-
- usb3-0 {
- nvidia,port = <2>;
- status = "okay";
- };
- };
- };
-
-Tegra210:
----------
-
-SoC include:
-
- padctl@7009f000 {
- compatible = "nvidia,tegra210-xusb-padctl";
- reg = <0x0 0x7009f000 0x0 0x1000>;
- resets = <&tegra_car 142>;
- reset-names = "padctl";
-
- status = "disabled";
-
- pads {
- usb2 {
- clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>;
- clock-names = "trk";
- status = "disabled";
-
- lanes {
- usb2-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- hsic {
- clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>;
- clock-names = "trk";
- status = "disabled";
-
- lanes {
- hsic-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- hsic-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- pcie {
- clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
- clock-names = "pll";
- resets = <&tegra_car 205>;
- reset-names = "phy";
- status = "disabled";
-
- lanes {
- pcie-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-4 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-5 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-6 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- sata {
- clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
- clock-names = "pll";
- resets = <&tegra_car 204>;
- reset-names = "phy";
- status = "disabled";
-
- lanes {
- sata-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "disabled";
- };
-
- usb2-1 {
- status = "disabled";
- };
-
- usb2-2 {
- status = "disabled";
- };
-
- usb2-3 {
- status = "disabled";
- };
-
- hsic-0 {
- status = "disabled";
- };
-
- hsic-1 {
- status = "disabled";
- };
-
- usb3-0 {
- status = "disabled";
- };
-
- usb3-1 {
- status = "disabled";
- };
-
- usb3-2 {
- status = "disabled";
- };
-
- usb3-3 {
- status = "disabled";
- };
- };
- };
-
-Board file:
-
- padctl@7009f000 {
- status = "okay";
-
- pads {
- usb2 {
- status = "okay";
-
- lanes {
- usb2-0 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-1 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-2 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-3 {
- nvidia,function = "xusb";
- status = "okay";
- };
- };
- };
-
- pcie {
- status = "okay";
-
- lanes {
- pcie-0 {
- nvidia,function = "pcie-x1";
- status = "okay";
- };
-
- pcie-1 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-2 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-3 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-4 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-5 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
-
- pcie-6 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
- };
- };
-
- sata {
- status = "okay";
-
- lanes {
- sata-0 {
- nvidia,function = "sata";
- status = "okay";
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "okay";
- mode = "otg";
- };
-
- usb2-1 {
- status = "okay";
- vbus-supply = <&vdd_5v0_rtl>;
- mode = "host";
- };
-
- usb2-2 {
- status = "okay";
- vbus-supply = <&vdd_usb_vbus>;
- mode = "host";
- };
-
- usb2-3 {
- status = "okay";
- mode = "host";
- };
-
- usb3-0 {
- status = "okay";
- nvidia,lanes = "pcie-6";
- nvidia,port = <1>;
- };
-
- usb3-1 {
- status = "okay";
- nvidia,lanes = "pcie-5";
- nvidia,port = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
new file mode 100644
index 0000000..33b41b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
@@ -0,0 +1,654 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra124-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra124 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra124-xusb-padctl
+
+ - items:
+ - const: nvidia,tegra132-xusb-padctl
+ - const: nvidia,tegra124-xusb-padctl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-erefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ avdd-pex-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 3.3 V.
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or be absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ ulpi:
+ type: object
+ additionalProperties: false
+ properties:
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ ulpi-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ hsic:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ pcie:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: PLLE clock
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: reset for the PCIe UPHY block
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ pcie-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-4:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ sata:
+ type: object
+ additionalProperties: false
+ properties:
+ resets:
+ items:
+ - description: reset for the SATA UPHY block
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ sata-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ sata, usb3-ss ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ ulpi-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - avdd-pll-utmip-supply
+ - avdd-pll-erefe-supply
+ - avdd-pex-pll-supply
+ - hvdd-pex-pll-e-supply
+
+examples:
+ # Tegra124 and Tegra132
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ padctl@7009f000 {
+ compatible = "nvidia,tegra124-xusb-padctl";
+ reg = <0x7009f000 0x1000>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&tegra_car 142>;
+ reset-names = "padctl";
+
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-pex-pll-supply = <&vdd_1v05_run>;
+ hvdd-pex-pll-e-supply = <&vdd_3v3_lp0>;
+
+ pads {
+ usb2 {
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ ulpi {
+ lanes {
+ ulpi-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ hsic-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ pcie {
+ lanes {
+ pcie-0 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+
+ pcie-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ pcie-2 {
+ nvidia,function = "pcie";
+ #phy-cells = <0>;
+ };
+
+ pcie-3 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ pcie-4 {
+ nvidia,function = "pcie";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ sata {
+ lanes {
+ sata-0 {
+ nvidia,function = "sata";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ /* Micro A/B */
+ usb2-0 {
+ mode = "otg";
+ };
+
+ /* Mini PCIe */
+ usb2-1 {
+ mode = "host";
+ };
+
+ /* USB3 */
+ usb2-2 {
+ vbus-supply = <&vdd_usb3_vbus>;
+ mode = "host";
+ };
+
+ ulpi-0 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ hsic-1 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <2>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml
new file mode 100644
index 0000000..8b1d5a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml
@@ -0,0 +1,544 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra186-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra186 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ const: nvidia,tegra186-xusb-padctl
+
+ reg:
+ items:
+ - description: pad controller registers
+ - description: AO registers
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ reg-names:
+ items:
+ - const: padctl
+ - const: ao
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-pll-erefeut-supply:
+ description: UPHY brick and reference clock as well as UTMI PHY
+ power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must
+ supply 3.3 V.
+
+ vclamp-usb-supply:
+ description: Bias rail for USB pad. Must supply 1.8 V.
+
+ vddio-hsic-supply:
+ description: HSIC PHY power supply. Must supply 1.2 V.
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or be absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ hsic:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3:
+ type: object
+ additionalProperties: false
+ properties:
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ hsic-0:
+ type: object
+ additionalProperties: false
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - avdd-pll-erefeut-supply
+ - avdd-usb-supply
+ - vclamp-usb-supply
+ - vddio-hsic-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra186-clock.h>
+ #include <dt-bindings/gpio/tegra186-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+
+ padctl@3520000 {
+ compatible = "nvidia,tegra186-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+
+ resets = <&bpmp TEGRA186_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ avdd-pll-erefeut-supply = <&vdd_1v8_pll>;
+ avdd-usb-supply = <&vdd_3v3_sys>;
+ vclamp-usb-supply = <&vdd_1v8>;
+ vddio-hsic-supply = <&gnd>;
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA186_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = <&bpmp TEGRA186_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ mode = "otg";
+ vbus-supply = <&vdd_usb0>;
+ usb-role-switch;
+
+ connector {
+ compatible = "gpio-usb-b-connector",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpios = <&gpio TEGRA186_MAIN_GPIO(X, 7) GPIO_ACTIVE_LOW>;
+ id-gpios = <&pmic 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_usb1>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
new file mode 100644
index 0000000..6e33983
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
@@ -0,0 +1,632 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra194 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra194-xusb-padctl
+ - nvidia,tegra234-xusb-padctl
+
+ reg:
+ items:
+ - description: pad controller registers
+ - description: AO registers
+
+ reg-names:
+ items:
+ - const: padctl
+ - const: ao
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-usb-supply:
+ description: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must
+ supply 3.3 V.
+
+ vclamp-usb-supply:
+ description: Bias rail for USB pad. Must supply 1.8 V.
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3:
+ type: object
+ additionalProperties: false
+ properties:
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-3:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - avdd-usb-supply
+ - vclamp-usb-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra194-clock.h>
+ #include <dt-bindings/gpio/tegra194-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/tegra194-reset.h>
+
+ padctl@3520000 {
+ compatible = "nvidia,tegra194-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+
+ resets = <&bpmp TEGRA194_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ avdd-usb-supply = <&vdd_usb_3v3>;
+ vclamp-usb-supply = <&vdd_1v8ao>;
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA194_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ status = "disabled";
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_sys>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ usb2-3 {
+ vbus-supply = <&vdd_5v_sata>;
+ mode = "host";
+ };
+
+ usb3-0 {
+ vbus-supply = <&vdd_5v0_sys>;
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ maximum-speed = "super-speed";
+ vbus-supply = <&vdd_5v0_sys>;
+ nvidia,usb2-companion = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
new file mode 100644
index 0000000..d16bd6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
@@ -0,0 +1,786 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra210-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra210 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ const: nvidia,tegra210-xusb-padctl
+
+ reg:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-uerefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ dvdd-pex-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 1.8 V.
+
+ nvidia,pmc:
+ description: phandle to the Tegra Power Management Controller (PMC) node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or be absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ hsic:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ pcie:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: PCIe PLL clock source
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: PCIe PHY reset
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ pcie-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-4:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-5:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-6:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ sata:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: SATA PLL clock source
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: SATA PHY reset
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ sata-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ usb3-ss, sata ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-3:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - avdd-pll-utmip-supply
+ - avdd-pll-uerefe-supply
+ - dvdd-pex-pll-supply
+ - hvdd-pex-pll-e-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ padctl@7009f000 {
+ compatible = "nvidia,tegra210-xusb-padctl";
+ reg = <0x7009f000 0x1000>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&tegra_car 142>;
+ reset-names = "padctl";
+
+ avdd-pll-utmip-supply = <&vdd_1v8>;
+ avdd-pll-uerefe-supply = <&vdd_pex_1v05>;
+ dvdd-pex-pll-supply = <&vdd_pex_1v05>;
+ hvdd-pex-pll-e-supply = <&vdd_1v8>;
+
+ pads {
+ usb2 {
+ clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ hsic-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ pcie {
+ clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "pll";
+ resets = <&tegra_car 205>;
+ reset-names = "phy";
+
+ lanes {
+ pcie-0 {
+ nvidia,function = "pcie-x1";
+ #phy-cells = <0>;
+ };
+
+ pcie-1 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-2 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-3 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-4 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-5 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+
+ pcie-6 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ sata {
+ clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "pll";
+ resets = <&tegra_car 204>;
+ reset-names = "phy";
+
+ lanes {
+ sata-0 {
+ nvidia,function = "sata";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ mode = "peripheral";
+ usb-role-switch;
+
+ connector {
+ compatible = "gpio-usb-b-connector",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpios = <&gpio TEGRA_GPIO(CC, 4) GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_rtl>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ vbus-supply = <&vdd_usb_vbus>;
+ mode = "host";
+ };
+
+ usb2-3 {
+ mode = "host";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ hsic-1 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ nvidia,usb2-companion = <2>;
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ status = "disabled";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
deleted file mode 100644
index f719200..0000000
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
+++ /dev/null
@@ -1,188 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/phy/phy-rockchip-inno-usb2.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Rockchip USB2.0 phy with inno IP block
-
-maintainers:
- - Heiko Stuebner <heiko@sntech.de>
-
-properties:
- compatible:
- enum:
- - rockchip,px30-usb2phy
- - rockchip,rk3128-usb2phy
- - rockchip,rk3228-usb2phy
- - rockchip,rk3308-usb2phy
- - rockchip,rk3328-usb2phy
- - rockchip,rk3366-usb2phy
- - rockchip,rk3399-usb2phy
- - rockchip,rk3568-usb2phy
- - rockchip,rv1108-usb2phy
-
- reg:
- maxItems: 1
-
- clock-output-names:
- description:
- The usb 480m output clock name.
-
- "#clock-cells":
- const: 0
-
- clocks:
- maxItems: 1
-
- clock-names:
- const: phyclk
-
- assigned-clocks:
- description:
- Phandle of the usb 480m clock.
-
- assigned-clock-parents:
- description:
- Parent of the usb 480m clock.
- Select between usb-phy output 480m and xin24m.
- Refer to clk/clock-bindings.txt for generic clock consumer properties.
-
- extcon:
- description:
- Phandle to the extcon device providing the cable state for the otg phy.
-
- interrupts:
- description: Muxed interrupt for both ports
- maxItems: 1
-
- rockchip,usbgrf:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the syscon managing the 'usb general register files'.
- When set the driver will request its phandle as one companion-grf
- for some special SoCs (e.g rv1108).
-
- host-port:
- type: object
- additionalProperties: false
-
- properties:
- "#phy-cells":
- const: 0
-
- interrupts:
- description: host linestate interrupt
- maxItems: 1
-
- interrupt-names:
- const: linestate
-
- phy-supply:
- description:
- Phandle to a regulator that provides power to VBUS.
- See ./phy-bindings.txt for details.
-
- required:
- - "#phy-cells"
-
- otg-port:
- type: object
- additionalProperties: false
-
- properties:
- "#phy-cells":
- const: 0
-
- interrupts:
- minItems: 1
- maxItems: 3
-
- interrupt-names:
- oneOf:
- - const: linestate
- - const: otg-mux
- - items:
- - const: otg-bvalid
- - const: otg-id
- - const: linestate
-
- phy-supply:
- description:
- Phandle to a regulator that provides power to VBUS.
- See ./phy-bindings.txt for details.
-
- required:
- - "#phy-cells"
-
-required:
- - compatible
- - reg
- - clock-output-names
- - "#clock-cells"
- - host-port
- - otg-port
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- const: rockchip,rk3568-usb2phy
-
- then:
- properties:
- host-port:
- properties:
- interrupts: false
-
- otg-port:
- properties:
- interrupts: false
-
- required:
- - interrupts
-
- else:
- properties:
- interrupts: false
-
- host-port:
- required:
- - interrupts
- - interrupt-names
-
- otg-port:
- required:
- - interrupts
- - interrupt-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/rk3399-cru.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- u2phy0: usb2phy@e450 {
- compatible = "rockchip,rk3399-usb2phy";
- reg = <0xe450 0x10>;
- clocks = <&cru SCLK_USB2PHY0_REF>;
- clock-names = "phyclk";
- clock-output-names = "clk_usbphy0_480m";
- #clock-cells = <0>;
-
- u2phy0_host: host-port {
- interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "linestate";
- #phy-cells = <0>;
- };
-
- u2phy0_otg: otg-port {
- interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "otg-bvalid", "otg-id", "linestate";
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml
index fdb277e..0c8f03b 100644
--- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml
@@ -43,6 +43,9 @@
vddio-supply:
description: phandle to VDD I/O supply regulator
+ '#clock-cells':
+ const: 0
+
'#phy-cells':
const: 0
@@ -53,7 +56,6 @@
contains:
enum:
- qcom,hdmi-phy-8660
- - qcom,hdmi-phy-8960
then:
properties:
clocks:
@@ -68,6 +70,24 @@
compatible:
contains:
enum:
+ - qcom,hdmi-phy-8960
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+ clock-names:
+ minItems: 1
+ items:
+ - const: slave_iface
+ - const: pxo
+ vddio-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,hdmi-phy-8084
- qcom,hdmi-phy-8974
then:
@@ -96,9 +116,10 @@
"hdmi_pll";
reg = <0x4a00400 0x60>,
<0x4a00500 0x100>;
+ #clock-cells = <0>;
#phy-cells = <0>;
power-domains = <&mmcc 1>;
- clock-names = "slave_iface";
- clocks = <&clk 21>;
+ clock-names = "slave_iface", "pxo";
+ clocks = <&clk 21>, <&pxo_board>;
core-vdda-supply = <&pm8921_hdmi_mvs>;
};
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
index be41acb..80a5348 100644
--- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
@@ -75,6 +75,9 @@
minItems: 3
maxItems: 6
+ "#clock-cells":
+ const: 1
+
"#phy-cells":
const: 0
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
index 0c6b3ba..e81a382 100644
--- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
@@ -30,6 +30,7 @@
- qcom,sdm845-qmp-usb3-uni-phy
- qcom,sdx55-qmp-usb3-uni-phy
- qcom,sdx65-qmp-usb3-uni-phy
+ - qcom,sm6115-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-usb3-phy
@@ -253,6 +254,7 @@
contains:
enum:
- qcom,qcm2290-qmp-usb3-phy
+ - qcom,sm6115-qmp-usb3-phy
then:
properties:
clocks:
@@ -321,6 +323,7 @@
- qcom,sc8180x-qmp-usb3-phy
- qcom,sdx55-qmp-usb3-uni-phy
- qcom,sdx65-qmp-usb3-uni-phy
+ - qcom,sm6115-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-usb3-phy
then:
diff --git a/Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml
new file mode 100644
index 0000000..dbc4a4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,pcie2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PCIe2 PHY controller
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The Qualcomm PCIe2 PHY is a Synopsys based phy found in a number of Qualcomm
+ platforms.
+
+properties:
+ compatible:
+ items:
+ - const: qcom,qcs404-pcie2-phy
+ - const: qcom,pcie2-phy
+
+ reg:
+ items:
+ - description: PHY register set
+
+ clocks:
+ items:
+ - description: a clock-specifier pair for the "pipe" clock
+
+ clock-output-names:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ "#phy-cells":
+ const: 0
+
+ vdda-vp-supply:
+ description: low voltage regulator
+
+ vdda-vph-supply:
+ description: high voltage regulator
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: pipe
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-output-names
+ - "#clock-cells"
+ - "#phy-cells"
+ - vdda-vp-supply
+ - vdda-vph-supply
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-qcs404.h>
+ phy@7786000 {
+ compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
+ reg = <0x07786000 0xb8>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
+ resets = <&gcc GCC_PCIEPHY_0_PHY_BCR>,
+ <&gcc GCC_PCIE_0_PIPE_ARES>;
+ reset-names = "phy", "pipe";
+
+ vdda-vp-supply = <&vreg_l3_1p05>;
+ vdda-vph-supply = <&vreg_l5_1p8>;
+
+ clock-output-names = "pcie_0_pipe_clk";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 636ea43..7f403e7 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -82,81 +82,74 @@
Phandle to TCSR syscon register region.
$ref: /schemas/types.yaml#/definitions/phandle
-if:
- properties:
- compatible:
- contains:
- const: qcom,qusb2-v2-phy
-then:
- properties:
- qcom,imp-res-offset-value:
- description:
- It is a 6 bit value that specifies offset to be
- added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
- tuning parameter that may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 63
- default: 0
+ qcom,imp-res-offset-value:
+ description:
+ It is a 6 bit value that specifies offset to be
+ added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
+ tuning parameter that may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 63
+ default: 0
- qcom,bias-ctrl-value:
- description:
- It is a 6 bit value that specifies bias-ctrl-value. It is a PHY
- tuning parameter that may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 63
- default: 32
+ qcom,bias-ctrl-value:
+ description:
+ It is a 6 bit value that specifies bias-ctrl-value. It is a PHY
+ tuning parameter that may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 63
+ default: 32
- qcom,charge-ctrl-value:
- description:
- It is a 2 bit value that specifies charge-ctrl-value. It is a PHY
- tuning parameter that may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 3
- default: 0
+ qcom,charge-ctrl-value:
+ description:
+ It is a 2 bit value that specifies charge-ctrl-value. It is a PHY
+ tuning parameter that may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 0
- qcom,hstx-trim-value:
- description:
- It is a 4 bit value that specifies tuning for HSTX
- output current.
- Possible range is - 15mA to 24mA (stepsize of 600 uA).
- See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 15
- default: 3
+ qcom,hstx-trim-value:
+ description:
+ It is a 4 bit value that specifies tuning for HSTX
+ output current.
+ Possible range is - 15mA to 24mA (stepsize of 600 uA).
+ See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 3
- qcom,preemphasis-level:
- description:
- It is a 2 bit value that specifies pre-emphasis level.
- Possible range is 0 to 15% (stepsize of 5%).
- See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 3
- default: 2
+ qcom,preemphasis-level:
+ description:
+ It is a 2 bit value that specifies pre-emphasis level.
+ Possible range is 0 to 15% (stepsize of 5%).
+ See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 2
- qcom,preemphasis-width:
- description:
- It is a 1 bit value that specifies how long the HSTX
- pre-emphasis (specified using qcom,preemphasis-level) must be in
- effect. Duration could be half-bit of full-bit.
- See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 1
- default: 0
+ qcom,preemphasis-width:
+ description:
+ It is a 1 bit value that specifies how long the HSTX
+ pre-emphasis (specified using qcom,preemphasis-level) must be in
+ effect. Duration could be half-bit of full-bit.
+ See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 0
- qcom,hsdisc-trim-value:
- description:
- It is a 2 bit value tuning parameter that control disconnect
- threshold and may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 3
- default: 0
+ qcom,hsdisc-trim-value:
+ description:
+ It is a 2 bit value tuning parameter that control disconnect
+ threshold and may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 0
required:
- compatible
@@ -169,6 +162,23 @@
- vdda-phy-dpdm-supply
- resets
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: qcom,qusb2-v2-phy
+ then:
+ properties:
+ qcom,imp-res-offset-value: false
+ qcom,bias-ctrl-value: false
+ qcom,charge-ctrl-value: false
+ qcom,hstx-trim-value: false
+ qcom,preemphasis-level: false
+ qcom,preemphasis-width: false
+ qcom,hsdisc-trim-value: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
index d9d0ab9..2e19a434c 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
@@ -19,12 +19,17 @@
properties:
compatible:
- enum:
- - qcom,sc7180-qmp-usb3-dp-phy
- - qcom,sc7280-qmp-usb3-dp-phy
- - qcom,sc8180x-qmp-usb3-dp-phy
- - qcom,sdm845-qmp-usb3-dp-phy
- - qcom,sm8250-qmp-usb3-dp-phy
+ oneOf:
+ - enum:
+ - qcom,sc7180-qmp-usb3-dp-phy
+ - qcom,sc8180x-qmp-usb3-dp-phy
+ - qcom,sdm845-qmp-usb3-dp-phy
+ - qcom,sm8250-qmp-usb3-dp-phy
+ - items:
+ - enum:
+ - qcom,sc7280-qmp-usb3-dp-phy
+ - const: qcom,sm8250-qmp-usb3-dp-phy
+
reg:
items:
- description: Address and length of PHY's USB serdes block.
@@ -46,18 +51,12 @@
ranges: true
clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- - description: Phy common block aux clock.
+ minItems: 3
+ maxItems: 4
clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: com_aux
+ minItems: 3
+ maxItems: 4
power-domains:
maxItems: 1
@@ -166,6 +165,64 @@
- vdda-phy-supply
- vdda-pll-supply
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-qmp-usb3-dp-phy
+ - qcom,sdm845-qmp-usb3-dp-phy
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Phy aux clock
+ - description: Phy config clock
+ - description: 19.2 MHz ref clk
+ - description: Phy common block aux clock
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+ - const: com_aux
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-qmp-usb3-dp-phy
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Phy aux clock
+ - description: 19.2 MHz ref clk
+ - description: Phy common block aux clock
+ clock-names:
+ items:
+ - const: aux
+ - const: ref
+ - const: com_aux
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8250-qmp-usb3-dp-phy
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Phy aux clock
+ - description: Board XO source
+ - description: Phy common block aux clock
+ clock-names:
+ items:
+ - const: aux
+ - const: ref_clk_src
+ - const: com_aux
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 80aa8d2..ef49efb 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -19,15 +19,20 @@
- qcom,sc8280xp-qmp-gen3x1-pcie-phy
- qcom,sc8280xp-qmp-gen3x2-pcie-phy
- qcom,sc8280xp-qmp-gen3x4-pcie-phy
+ - qcom,sm8350-qmp-gen3x1-pcie-phy
+ - qcom,sm8550-qmp-gen3x2-pcie-phy
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
reg:
minItems: 1
maxItems: 2
clocks:
+ minItems: 5
maxItems: 6
clock-names:
+ minItems: 5
items:
- const: aux
- const: cfg_ahb
@@ -40,16 +45,21 @@
maxItems: 1
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
reset-names:
+ minItems: 1
items:
- const: phy
+ - const: phy_nocsr
vdda-phy-supply: true
vdda-pll-supply: true
+ vdda-qref-supply: true
+
qcom,4ln-config-sel:
description: PCIe 4-lane configuration
$ref: /schemas/types.yaml#/definitions/phandle-array
@@ -104,6 +114,46 @@
reg:
maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8350-qmp-gen3x1-pcie-phy
+ - qcom,sm8550-qmp-gen3x2-pcie-phy
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ maxItems: 5
+ else:
+ properties:
+ clocks:
+ minItems: 6
+ clock-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index dde86a1..64ed331 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -17,6 +17,8 @@
compatible:
enum:
- qcom,sc8280xp-qmp-ufs-phy
+ - qcom,sm6125-qmp-ufs-phy
+ - qcom,sm8550-qmp-ufs-phy
reg:
maxItems: 1
@@ -43,6 +45,9 @@
vdda-pll-supply: true
+ "#clock-cells":
+ const: 1
+
"#phy-cells":
const: 0
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 6f31693..3cd5fc3 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -17,6 +17,10 @@
compatible:
enum:
- qcom,sc8280xp-qmp-usb43dp-phy
+ - qcom,sm6350-qmp-usb3-dp-phy
+ - qcom,sm8350-qmp-usb3-dp-phy
+ - qcom,sm8450-qmp-usb3-dp-phy
+ - qcom,sm8550-qmp-usb3-dp-phy
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
new file mode 100644
index 0000000..c53bab1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,snps-eusb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SNPS eUSB2 phy controller
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ eUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+properties:
+ compatible:
+ const: qcom,sm8550-snps-eusb2-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: ref
+
+ clock-names:
+ items:
+ - const: ref
+
+ resets:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+ description:
+ Phandle to eUSB2 to USB 2.0 repeater
+
+ vdd-supply:
+ description:
+ Phandle to 0.88V regulator supply to PHY digital circuit.
+
+ vdda12-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+ - vdd-supply
+ - vdda12-supply
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm8550-tcsr.h>
+
+ usb_1_hsphy: phy@88e3000 {
+ compatible = "qcom,sm8550-snps-eusb2-phy";
+ reg = <0x88e3000 0x154>;
+ #phy-cells = <0>;
+
+ clocks = <&tcsrcc TCSR_USB2_CLKREF_EN>;
+ clock-names = "ref";
+
+ vdd-supply = <&vreg_l1e_0p88>;
+ vdda12-supply = <&vreg_l3e_1p2>;
+
+ resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
new file mode 100644
index 0000000..083fda5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,snps-eusb2-repeater.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Synopsis eUSB2 to USB 2.0 repeater
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ eUSB2 repeater converts between eUSB2 and USB 2.0 signaling levels and
+ allows a eUSB2 PHY to connect to legacy USB 2.0 products
+
+properties:
+ compatible:
+ const: qcom,pm8550b-eusb2-repeater
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ vdd18-supply: true
+
+ vdd3-supply: true
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@7 {
+ reg = <0x7 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8550b_eusb2_repeater: phy@fd00 {
+ compatible = "qcom,pm8550b-eusb2-repeater";
+ reg = <0xfd00>;
+ #phy-cells = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
deleted file mode 100644
index 3c7cb2b..0000000
--- a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Qualcomm's USB HSIC PHY
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Should contain "qcom,usb-hsic-phy" and more specifically one of the
- following:
-
- "qcom,usb-hsic-phy-mdm9615"
- "qcom,usb-hsic-phy-msm8974"
-
-- #phy-cells:
- Usage: required
- Value type: <u32>
- Definition: Should contain 0
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Should contain clock specifier for phy, calibration and
- a calibration sleep clock
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: Should contain "phy, "cal" and "cal_sleep"
-
-- pinctrl-names:
- Usage: required
- Value type: <stringlist>
- Definition: Should contain "init" and "default" in that order
-
-- pinctrl-0:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: List of pinctrl settings to apply to keep HSIC pins in a glitch
- free state
-
-- pinctrl-1:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: List of pinctrl settings to apply to mux out the HSIC pins
-
-EXAMPLE
-
-usb-controller {
- ulpi {
- phy {
- compatible = "qcom,usb-hsic-phy-msm8974",
- "qcom,usb-hsic-phy";
- #phy-cells = <0>;
- pinctrl-names = "init", "default";
- pinctrl-0 = <&hsic_sleep>;
- pinctrl-1 = <&hsic_default>;
- clocks = <&gcc GCC_USB_HSIC_CLK>,
- <&gcc GCC_USB_HSIC_IO_CAL_CLK>,
- <&gcc GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
- clock-names = "phy", "cal", "cal_sleep";
- assigned-clocks = <&gcc GCC_USB_HSIC_IO_CAL_CLK>;
- assigned-clock-rates = <960000>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml
new file mode 100644
index 0000000..077e13a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,usb-hsic-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm USB HSIC PHY Controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Vinod Koul <vkoul@kernel.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,usb-hsic-phy-mdm9615
+ - qcom,usb-hsic-phy-msm8974
+ - const: qcom,usb-hsic-phy
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: phy
+ - const: cal
+ - const: cal_sleep
+
+ "#phy-cells":
+ const: 0
+
+ pinctrl-0: true
+ pinctrl-1: true
+
+ pinctrl-names:
+ items:
+ - const: init
+ - const: default
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - "#phy-cells"
+ - pinctrl-0
+ - pinctrl-1
+ - pinctrl-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8974.h>
+
+ phy {
+ compatible = "qcom,usb-hsic-phy-msm8974",
+ "qcom,usb-hsic-phy";
+ clocks = <&gcc GCC_USB_HSIC_CLK>,
+ <&gcc GCC_USB_HSIC_IO_CAL_CLK>,
+ <&gcc GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
+ clock-names = "phy", "cal", "cal_sleep";
+ #phy-cells = <0>;
+ pinctrl-names = "init", "default";
+ pinctrl-0 = <&hsic_sleep>;
+ pinctrl-1 = <&hsic_default>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
index 68e7096..85d405e 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -14,18 +14,25 @@
properties:
compatible:
- enum:
- - qcom,usb-snps-hs-5nm-phy
- - qcom,usb-snps-hs-7nm-phy
- - qcom,sc7280-usb-hs-phy
- - qcom,sc8180x-usb-hs-phy
- - qcom,sc8280xp-usb-hs-phy
- - qcom,sm6375-usb-hs-phy
- - qcom,sm8150-usb-hs-phy
- - qcom,sm8250-usb-hs-phy
- - qcom,sm8350-usb-hs-phy
- - qcom,sm8450-usb-hs-phy
- - qcom,usb-snps-femto-v2-phy
+ oneOf:
+ - enum:
+ - qcom,sc8180x-usb-hs-phy
+ - qcom,usb-snps-femto-v2-phy
+ - items:
+ - enum:
+ - qcom,sc8280xp-usb-hs-phy
+ - const: qcom,usb-snps-hs-5nm-phy
+ - items:
+ - enum:
+ - qcom,sc7280-usb-hs-phy
+ - qcom,sdx55-usb-hs-phy
+ - qcom,sdx65-usb-hs-phy
+ - qcom,sm6375-usb-hs-phy
+ - qcom,sm8150-usb-hs-phy
+ - qcom,sm8250-usb-hs-phy
+ - qcom,sm8350-usb-hs-phy
+ - qcom,sm8450-usb-hs-phy
+ - const: qcom,usb-snps-hs-7nm-phy
reg:
maxItems: 1
@@ -160,7 +167,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sm8150.h>
phy@88e2000 {
- compatible = "qcom,sm8150-usb-hs-phy";
+ compatible = "qcom,sm8150-usb-hs-phy", "qcom,usb-snps-hs-7nm-phy";
reg = <0x088e2000 0x400>;
#phy-cells = <0>;
diff --git a/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt b/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
deleted file mode 100644
index 3006425..0000000
--- a/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Qualcomm PCIe2 PHY controller
-=============================
-
-The Qualcomm PCIe2 PHY is a Synopsys based phy found in a number of Qualcomm
-platforms.
-
-Required properties:
- - compatible: compatible list, should be:
- "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy"
-
- - reg: offset and length of the PHY register set.
- - #phy-cells: must be 0.
-
- - clocks: a clock-specifier pair for the "pipe" clock
-
- - vdda-vp-supply: phandle to low voltage regulator
- - vdda-vph-supply: phandle to high voltage regulator
-
- - resets: reset-specifier pairs for the "phy" and "pipe" resets
- - reset-names: list of resets, should contain:
- "phy" and "pipe"
-
- - clock-output-names: name of the outgoing clock signal from the PHY PLL
- - #clock-cells: must be 0
-
-Example:
- phy@7786000 {
- compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
- reg = <0x07786000 0xb8>;
-
- clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
- resets = <&gcc GCC_PCIEPHY_0_PHY_BCR>,
- <&gcc GCC_PCIE_0_PIPE_ARES>;
- reset-names = "phy", "pipe";
-
- vdda-vp-supply = <&vreg_l3_1p05>;
- vdda-vph-supply = <&vreg_l5_1p8>;
-
- clock-output-names = "pcie_0_pipe_clk";
- #clock-cells = <0>;
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
new file mode 100644
index 0000000..0d6b8c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
@@ -0,0 +1,188 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,inno-usb2phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip USB2.0 phy with inno IP block
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,px30-usb2phy
+ - rockchip,rk3128-usb2phy
+ - rockchip,rk3228-usb2phy
+ - rockchip,rk3308-usb2phy
+ - rockchip,rk3328-usb2phy
+ - rockchip,rk3366-usb2phy
+ - rockchip,rk3399-usb2phy
+ - rockchip,rk3568-usb2phy
+ - rockchip,rv1108-usb2phy
+
+ reg:
+ maxItems: 1
+
+ clock-output-names:
+ description:
+ The usb 480m output clock name.
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: phyclk
+
+ assigned-clocks:
+ description:
+ Phandle of the usb 480m clock.
+
+ assigned-clock-parents:
+ description:
+ Parent of the usb 480m clock.
+ Select between usb-phy output 480m and xin24m.
+ Refer to clk/clock-bindings.txt for generic clock consumer properties.
+
+ extcon:
+ description:
+ Phandle to the extcon device providing the cable state for the otg phy.
+
+ interrupts:
+ description: Muxed interrupt for both ports
+ maxItems: 1
+
+ rockchip,usbgrf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'usb general register files'.
+ When set the driver will request its phandle as one companion-grf
+ for some special SoCs (e.g rv1108).
+
+ host-port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#phy-cells":
+ const: 0
+
+ interrupts:
+ description: host linestate interrupt
+ maxItems: 1
+
+ interrupt-names:
+ const: linestate
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to VBUS.
+ See ./phy-bindings.txt for details.
+
+ required:
+ - "#phy-cells"
+
+ otg-port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#phy-cells":
+ const: 0
+
+ interrupts:
+ minItems: 1
+ maxItems: 3
+
+ interrupt-names:
+ oneOf:
+ - const: linestate
+ - const: otg-mux
+ - items:
+ - const: otg-bvalid
+ - const: otg-id
+ - const: linestate
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to VBUS.
+ See ./phy-bindings.txt for details.
+
+ required:
+ - "#phy-cells"
+
+required:
+ - compatible
+ - reg
+ - clock-output-names
+ - "#clock-cells"
+ - host-port
+ - otg-port
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-usb2phy
+
+ then:
+ properties:
+ host-port:
+ properties:
+ interrupts: false
+
+ otg-port:
+ properties:
+ interrupts: false
+
+ required:
+ - interrupts
+
+ else:
+ properties:
+ interrupts: false
+
+ host-port:
+ required:
+ - interrupts
+ - interrupt-names
+
+ otg-port:
+ required:
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ u2phy0: usb2phy@e450 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0xe450 0x10>;
+ clocks = <&cru SCLK_USB2PHY0_REF>;
+ clock-names = "phyclk";
+ clock-output-names = "clk_usbphy0_480m";
+ #clock-cells = <0>;
+
+ u2phy0_host: host-port {
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "linestate";
+ #phy-cells = <0>;
+ };
+
+ u2phy0_otg: otg-port {
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "otg-bvalid", "otg-id", "linestate";
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml
new file mode 100644
index 0000000..2538235
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3288-dp-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip specific extensions to the Analogix Display Port PHY
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3288-dp-phy
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: 24m
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3288-cru.h>
+ edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
deleted file mode 100644
index e3b4809..0000000
--- a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Rockchip specific extensions to the Analogix Display Port PHY
-------------------------------------
-
-Required properties:
-- compatible : should be one of the following supported values:
- - "rockchip.rk3288-dp-phy"
-- clocks: from common clock binding: handle to dp clock.
- of memory mapped region.
-- clock-names: from common clock binding:
- Required elements: "24m"
-- #phy-cells : from the generic PHY bindings, must be 0;
-
-Example:
-
-grf: syscon@ff770000 {
- compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
-
-...
-
- edp_phy: edp-phy {
- compatible = "rockchip,rk3288-dp-phy";
- clocks = <&cru SCLK_EDP_24M>;
- clock-names = "24m";
- #phy-cells = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml
index b03b2f00..3bee3f8 100644
--- a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml
@@ -22,13 +22,13 @@
samsung,pmu-syscon:
$ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
description:
- Phandle to PMU system controller interface.
+ Phandle to PMU system controller interface (if not a child of PMU).
required:
- compatible
- "#phy-cells"
- - samsung,pmu-syscon
additionalProperties: false
@@ -36,6 +36,5 @@
- |
phy {
compatible = "samsung,exynos5420-dp-video-phy";
- samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
index 415440a..b2250e4 100644
--- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
@@ -35,15 +35,18 @@
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
description:
Phandle to PMU system controller interface, valid only for
- samsung,s5pv210-mipi-video-phy and samsung,exynos5420-mipi-video-phy.
+ samsung,s5pv210-mipi-video-phy and samsung,exynos5420-mipi-video-phy (if
+ not a child of PMU).
samsung,pmu-syscon:
$ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
description:
Phandle to PMU system controller interface, valid for
- samsung,exynos5433-mipi-video-phy.
+ samsung,exynos5433-mipi-video-phy (if not a child of PMU).
samsung,disp-sysreg:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -81,13 +84,10 @@
samsung,disp-sysreg: false
samsung,cam0-sysreg: false
samsung,cam1-sysreg: false
- required:
- - syscon
else:
properties:
syscon: false
required:
- - samsung,pmu-syscon
- samsung,disp-sysreg
- samsung,cam0-sysreg
- samsung,cam1-sysreg
@@ -99,7 +99,6 @@
phy {
compatible = "samsung,exynos5433-mipi-video-phy";
#phy-cells = <1>;
- samsung,pmu-syscon = <&pmu_system_controller>;
samsung,cam0-sysreg = <&syscon_cam0>;
samsung,cam1-sysreg = <&syscon_cam1>;
samsung,disp-sysreg = <&syscon_disp>;
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
index a3cd45a..de3cffc 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
@@ -117,20 +117,12 @@
examples:
- |
- ahci-glue@65700000 {
- compatible = "socionext,uniphier-pxs3-ahci-glue",
- "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65700000 0x100>;
-
- ahci_phy: phy@10 {
- compatible = "socionext,uniphier-pxs3-ahci-phy";
- reg = <0x10 0x10>;
- #phy-cells = <0>;
- clock-names = "link", "phy";
- clocks = <&sys_clk 28>, <&sys_clk 30>;
- reset-names = "link", "phy";
- resets = <&sys_rst 28>, <&sys_rst 30>;
- };
+ ahci_phy: phy@10 {
+ compatible = "socionext,uniphier-pxs3-ahci-phy";
+ reg = <0x10 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 28>, <&sys_clk 30>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 28>, <&sys_rst 30>;
};
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
index 63dab91..19522c54 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
@@ -61,28 +61,23 @@
- |
// The UniPhier usb2-phy should be a subnode of a "syscon" compatible node.
- soc-glue@5f800000 {
- compatible = "socionext,uniphier-ld11-soc-glue", "simple-mfd", "syscon";
- reg = <0x5f800000 0x2000>;
+ usb-hub {
+ compatible = "socionext,uniphier-ld11-usb2-phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
- usb-controller {
- compatible = "socionext,uniphier-ld11-usb2-phy";
- #address-cells = <1>;
- #size-cells = <0>;
+ usb_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
- usb_phy0: phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- };
+ usb_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
- usb_phy1: phy@1 {
- reg = <1>;
- #phy-cells = <0>;
- };
-
- usb_phy2: phy@2 {
- reg = <2>;
- #phy-cells = <0>;
- };
+ usb_phy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
index 21e4414..2107d98 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
@@ -146,22 +146,15 @@
examples:
- |
- usb-glue@65b00000 {
- compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_hsphy0: hs-phy@200 {
- compatible = "socionext,uniphier-ld20-usb3-hsphy";
- reg = <0x200 0x10>;
- #phy-cells = <0>;
- clock-names = "link", "phy";
- clocks = <&sys_clk 14>, <&sys_clk 16>;
- reset-names = "link", "phy";
- resets = <&sys_rst 14>, <&sys_rst 16>;
- vbus-supply = <&usb_vbus0>;
- nvmem-cell-names = "rterm", "sel_t", "hs_i";
- nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, <&usb_hs_i0>;
- };
+ usb_hsphy0: phy@200 {
+ compatible = "socionext,uniphier-ld20-usb3-hsphy";
+ reg = <0x200 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 16>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 16>;
+ vbus-supply = <&usb_vbus0>;
+ nvmem-cell-names = "rterm", "sel_t", "hs_i";
+ nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, <&usb_hs_i0>;
};
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
index 4c26d2d..8f5aa62 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
@@ -131,21 +131,13 @@
examples:
- |
- usb-glue@65b00000 {
- compatible = "socionext,uniphier-ld20-dwc3-glue",
- "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_ssphy0: ss-phy@300 {
- compatible = "socionext,uniphier-ld20-usb3-ssphy";
- reg = <0x300 0x10>;
- #phy-cells = <0>;
- clock-names = "link", "phy";
- clocks = <&sys_clk 14>, <&sys_clk 16>;
- reset-names = "link", "phy";
- resets = <&sys_rst 14>, <&sys_rst 16>;
- vbus-supply = <&usb_vbus0>;
- };
+ usb_ssphy0: phy@300 {
+ compatible = "socionext,uniphier-ld20-usb3-ssphy";
+ reg = <0x300 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 16>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 16>;
+ vbus-supply = <&usb_vbus0>;
};
diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 02b76f1..237295b 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -15,6 +15,7 @@
compatible:
enum:
+ - nxp,tjr1443
- ti,tcan1042
- ti,tcan1043
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml
new file mode 100644
index 0000000..7ae0843
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/fsl,imx8m-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IMX8M IOMUX Controller
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description:
+ Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
+ for common binding part and usage.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8mm-iomuxc
+ - fsl,imx8mn-iomuxc
+ - fsl,imx8mp-iomuxc
+ - fsl,imx8mq-iomuxc
+
+ reg:
+ maxItems: 1
+
+# Client device subnode's properties
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ each entry consists of 6 integers and represents the mux and config
+ setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+ mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+ be found in <arch/arm64/boot/dts/freescale/imx8m[m,n,p,q]-pinfunc.h>.
+ The last integer CONFIG is the pad setting value like pull-up on this
+ pin. Please refer to i.MX8M Mini/Nano/Plus/Quad Reference Manual for
+ detailed CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_reg" indicates the offset of mux register.
+ - description: |
+ "conf_reg" indicates the offset of pad configuration register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_val" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ "pad_setting" indicates the pad configuration value to be
+ applied.
+
+ required:
+ - fsl,pins
+
+ additionalProperties: false
+
+allOf:
+ - $ref: "pinctrl.yaml#"
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ # Pinmux controller node
+ - |
+ iomuxc: pinctrl@30330000 {
+ compatible = "fsl,imx8mm-iomuxc";
+ reg = <0x30330000 0x10000>;
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins =
+ <0x23C 0x4A4 0x4FC 0x0 0x0 0x140>,
+ <0x240 0x4A8 0x000 0x0 0x0 0x140>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml
deleted file mode 100644
index 6717f16..0000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mm-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MM IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mm-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Mini Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mm-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart2: uart2grp {
- fsl,pins =
- <0x23C 0x4A4 0x4FC 0x0 0x0 0x140>,
- <0x240 0x4A8 0x000 0x0 0x0 0x140>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml
deleted file mode 100644
index b1cdbb56..0000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mn-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MN IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mn-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mn-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Nano Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mn-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart2: uart2grp {
- fsl,pins =
- <0x23C 0x4A4 0x4FC 0x0 0x0 0x140>,
- <0x240 0x4A8 0x000 0x0 0x0 0x140>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml
deleted file mode 100644
index 4eed3a4..0000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mp-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MP IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mp-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Plus Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mp-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart2: uart2grp {
- fsl,pins =
- <0x228 0x488 0x5F0 0x0 0x6 0x49>,
- <0x228 0x488 0x000 0x0 0x0 0x49>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml
deleted file mode 100644
index d4a8ea5..0000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mq-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MQ IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mq-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mq-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Quad Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mq-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart1: uart1grp {
- fsl,pins =
- <0x234 0x49C 0x4F4 0x0 0x0 0x49>,
- <0x238 0x4A0 0x4F4 0x0 0x0 0x49>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
index 1b44335..a55c8e4 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
@@ -70,11 +70,11 @@
- $ref: "pinctrl.yaml#"
patternProperties:
- '-[0-9]+$':
+ 'pins$':
type: object
additionalProperties: false
patternProperties:
- 'pins':
+ '(^pins|pins?$)':
type: object
additionalProperties: false
description: |
@@ -158,7 +158,7 @@
<GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- i2c0_pins_a: i2c0-0 {
+ i2c0_pins_a: i2c0-pins {
pins1 {
pinmux = <MT8135_PIN_100_SDA0__FUNC_SDA0>,
<MT8135_PIN_101_SCL0__FUNC_SCL0>;
@@ -166,7 +166,7 @@
};
};
- i2c1_pins_a: i2c1-0 {
+ i2c1_pins_a: i2c1-pins {
pins {
pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>,
<MT8135_PIN_196_SCL1__FUNC_SCL1>;
@@ -174,7 +174,7 @@
};
};
- i2c2_pins_a: i2c2-0 {
+ i2c2_pins_a: i2c2-pins {
pins1 {
pinmux = <MT8135_PIN_193_SDA2__FUNC_SDA2>;
bias-pull-down;
@@ -186,7 +186,7 @@
};
};
- i2c3_pins_a: i2c3-0 {
+ i2c3_pins_a: i2c3-pins {
pins1 {
pinmux = <MT8135_PIN_40_DAC_CLK__FUNC_GPIO40>,
<MT8135_PIN_41_DAC_WS__FUNC_GPIO41>;
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index c9ea0ca..ac93eb8 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -61,11 +61,11 @@
- "#interrupt-cells"
patternProperties:
- '-[0-9]+$':
+ '-pins(-[a-z]+)?$':
type: object
additionalProperties: false
patternProperties:
- 'mux':
+ '^mux(-|$)':
type: object
additionalProperties: false
description: |
@@ -244,7 +244,7 @@
groups:
enum: [wf0_2g, wf0_5g]
- 'conf':
+ '^conf(-|$)':
type: object
additionalProperties: false
description: |
@@ -348,7 +348,7 @@
gpio-controller;
#gpio-cells = <2>;
- pinctrl_eth_default: eth-0 {
+ pinctrl_eth_default: eth-pins {
mux-mdio {
groups = "mdc_mdio";
function = "eth";
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
new file mode 100644
index 0000000..74c66fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
@@ -0,0 +1,475 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7981-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT7981 Pin Controller
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ The MediaTek's MT7981 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7981-pinctrl
+
+ reg:
+ minItems: 9
+ maxItems: 9
+
+ reg-names:
+ items:
+ - const: gpio
+ - const: iocfg_rt
+ - const: iocfg_rm
+ - const: iocfg_rb
+ - const: iocfg_lb
+ - const: iocfg_bl
+ - const: iocfg_tm
+ - const: iocfg_tl
+ - const: eint
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: >
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+
+ gpio-ranges:
+ minItems: 1
+ maxItems: 5
+ description: GPIO valid number range.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - "#gpio-cells"
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^.*mux.*$':
+ type: object
+ additionalProperties: false
+ description: |
+ pinmux configuration nodes.
+
+ The following table shows the effective values of "group", "function"
+ properties and chip pinout pins
+
+ groups function pins (in pin#)
+ ---------------------------------------------------------------------
+ "wa_aice1" "wa_aice" 0, 1
+ "wa_aice2" "wa_aice" 0, 1
+ "wm_uart_0" "uart" 0, 1
+ "dfd" "dfd" 0, 1, 4, 5
+ "watchdog" "watchdog" 2
+ "pcie_pereset" "pcie" 3
+ "jtag" "jtag" 4, 5, 6, 7, 8
+ "wm_jtag_0" "jtag" 4, 5, 6, 7, 8
+ "wo0_jtag_0" "jtag" 9, 10, 11, 12, 13
+ "uart2_0" "uart" 4, 5, 6, 7
+ "gbe_led0" "led" 8
+ "pta_ext_0" "pta" 4, 5, 6
+ "pwm2" "pwm" 7
+ "net_wo0_uart_txd_0" "uart" 8
+ "spi1_0" "spi" 4, 5, 6, 7
+ "i2c0_0" "i2c" 6, 7
+ "dfd_ntrst" "dfd" 8
+ "wm_aice1" "wa_aice" 9, 10
+ "pwm0_0" "pwm" 13
+ "pwm0_1" "pwm" 15
+ "pwm1_0" "pwm" 14
+ "pwm1_1" "pwm" 15
+ "net_wo0_uart_txd_1" "uart" 14
+ "net_wo0_uart_txd_2" "uart" 15
+ "gbe_led1" "led" 13
+ "pcm" "pcm" 9, 10, 11, 12, 13, 25
+ "watchdog1" "watchdog" 13
+ "udi" "udi" 9, 10, 11, 12, 13
+ "drv_vbus" "usb" 14
+ "emmc_45" "flash" 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25
+ "snfi" "flash" 16, 17, 18, 19, 20, 21
+ "spi0" "spi" 16, 17, 18, 19
+ "spi0_wp_hold" "spi" 20, 21
+ "spi1_1" "spi" 22, 23, 24, 25
+ "spi2" "spi" 26, 27, 28, 29
+ "spi2_wp_hold" "spi" 30, 31
+ "uart1_0" "uart" 16, 17, 18, 19
+ "uart1_1" "uart" 26, 27, 28, 29
+ "uart2_1" "uart" 22, 23, 24, 25
+ "pta_ext_1" "pta" 22, 23, 24
+ "wm_aurt_1" "uart" 20, 21
+ "wm_aurt_2" "uart" 30, 31
+ "wm_jtag_1" "jtag" 20, 21, 22, 23, 24
+ "wo0_jtag_1" "jtag" 25, 26, 27, 28, 29
+ "wa_aice3" "wa_aice" 28, 20
+ "wm_aice2" "wa_aice" 30, 31
+ "i2c0_1" "i2c" 30, 31
+ "u2_phy_i2c" "i2c" 30, 31
+ "uart0" "uart" 32, 33
+ "sgmii1_phy_i2c" "i2c" 32, 33
+ "u3_phy_i2c" "i2c" 32, 33
+ "sgmii0_phy_i2c" "i2c" 32, 33
+ "pcie_clk" "pcie" 34
+ "pcie_wake" "pcie" 35
+ "i2c0_2" "i2c" 36, 37
+ "smi_mdc_mdio" "eth" 36, 37
+ "gbe_ext_mdc_mdio" "eth" 36, 37
+ "wf0_mode1" "eth" 40, 41, 42, 43, 44, 45, 46, 47, 48,
+ 49, 50, 51, 52, 53, 54, 55, 56
+
+ "wf0_mode3" "eth" 45, 46, 47, 48, 49, 51
+ "wf2g_led0" "led" 30
+ "wf2g_led1" "led" 34
+ "wf5g_led0" "led" 31
+ "wf5g_led1" "led" 35
+ "mt7531_int" "eth" 38
+ "ant_sel" "ant" 14, 15, 16, 17, 18, 19, 20, 21, 22
+ 23, 24, 25, 34, 35
+
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [wa_aice, dfd, jtag, pta, pcm, udi, usb, ant, eth, i2c, led,
+ pwm, spi, uart, watchdog, flash, pcie]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+
+ required:
+ - function
+ - groups
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: wa_aice
+ then:
+ properties:
+ groups:
+ enum: [wa_aice1, wa_aice2, wm_aice1_1, wa_aice3, wm_aice1_2]
+ - if:
+ properties:
+ function:
+ const: dfd
+ then:
+ properties:
+ groups:
+ enum: [dfd, dfd_ntrst]
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag, wm_jtag_0, wo0_jtag_0, wo0_jtag_1, wm_jtag_1]
+ - if:
+ properties:
+ function:
+ const: pta
+ then:
+ properties:
+ groups:
+ enum: [pta_ext_0, pta_ext_1]
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [pcm]
+ - if:
+ properties:
+ function:
+ const: udi
+ then:
+ properties:
+ groups:
+ enum: [udi]
+ - if:
+ properties:
+ function:
+ const: usb
+ then:
+ properties:
+ groups:
+ enum: [drv_vbus]
+ - if:
+ properties:
+ function:
+ const: ant
+ then:
+ properties:
+ groups:
+ enum: [ant_sel]
+ - if:
+ properties:
+ function:
+ const: eth
+ then:
+ properties:
+ groups:
+ enum: [smi_mdc_mdio, gbe_ext_mdc_mdio, wf0_mode1, wf0_mode3,
+ mt7531_int]
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c0_0, i2c0_1, u2_phy_i2c, sgmii1_phy_i2c, u3_phy_i2c,
+ sgmii0_phy_i2c, i2c0_2]
+ - if:
+ properties:
+ function:
+ const: led
+ then:
+ properties:
+ groups:
+ enum: [gbe_led0, gbe_led1, wf2g_led0, wf2g_led1, wf5g_led0, wf5g_led1]
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pwm2, pwm0_0, pwm0_1, pwm1_0, pwm1_1]
+ maxItems: 3
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [spi1_0, spi0, spi0_wp_hold, spi1_1, spi2, spi2_wp_hold]
+ maxItems: 4
+ - if:
+ properties:
+ function:
+ const: uart
+ then:
+ properties:
+ groups:
+ items:
+ enum: [wm_uart_0, uart2_0, net_wo0_uart_txd_0,
+ net_wo0_uart_txd_1, net_wo0_uart_txd_2, uart1_0,
+ uart1_1, uart2_1, wm_aurt_1, wm_aurt_2, uart0]
+ - if:
+ properties:
+ function:
+ const: watchdog
+ then:
+ properties:
+ groups:
+ enum: [watchdog]
+ - if:
+ properties:
+ function:
+ const: flash
+ then:
+ properties:
+ groups:
+ items:
+ enum: [emmc_45, snfi]
+ maxItems: 1
+ - if:
+ properties:
+ function:
+ const: pcie
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pcie_clk, pcie_wake, pcie_pereset]
+ maxItems: 3
+
+ '^.*conf.*$':
+ type: object
+ additionalProperties: false
+ description: pinconf configuration nodes.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ An array of strings. Each string contains the name of a pin.
+ items:
+ enum: [GPIO_WPS, GPIO_RESET, SYS_WATCHDOG, PCIE_PERESET_N,
+ JTAG_JTDO, JTAG_JTDI, JTAG_JTMS, JTAG_JTCLK, JTAG_JTRST_N,
+ WO_JTAG_JTDO, WO_JTAG_JTDI, WO_JTAG_JTMS, WO_JTAG_JTCLK,
+ WO_JTAG_JTRST_N, USB_VBUS, PWM0, SPI0_CLK, SPI0_MOSI,
+ SPI0_MISO, SPI0_CS, SPI0_HOLD, SPI0_WP, SPI1_CLK, SPI1_MOSI,
+ SPI1_MISO, SPI1_CS, SPI2_CLK, SPI2_MOSI, SPI2_MISO, SPI2_CS,
+ SPI2_HOLD, SPI2_WP, UART0_RXD, UART0_TXD, PCIE_CLK_REQ,
+ PCIE_WAKE_N, SMI_MDC, SMI_MDIO, GBE_INT, GBE_RESET,
+ WF_DIG_RESETB, WF_CBA_RESETB, WF_XO_REQ, WF_TOP_CLK,
+ WF_TOP_DATA, WF_HB1, WF_HB2, WF_HB3, WF_HB4, WF_HB0,
+ WF_HB0_B, WF_HB5, WF_HB6, WF_HB7, WF_HB8, WF_HB9, WF_HB10]
+ maxItems: 57
+
+ bias-disable: true
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ description: normal pull up.
+ - enum: [100, 101, 102, 103]
+ description: >
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ description: normal pull down.
+ - enum: [100, 101, 102, 103]
+ description: >
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ input-enable: true
+
+ input-disable: true
+
+ output-enable: true
+
+ output-low: true
+
+ output-high: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ mediatek,pull-up-adv:
+ description: |
+ Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
+ Pull up setings for 2 pull resistors, R0 and R1. Valid arguments
+ are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ description: |
+ Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
+ Pull down setings for 2 pull resistors, R0 and R1. Valid arguments
+ are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ required:
+ - pins
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt65xx.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pio: pinctrl@11d00000 {
+ compatible = "mediatek,mt7981-pinctrl";
+ reg = <0 0x11d00000 0 0x1000>,
+ <0 0x11c00000 0 0x1000>,
+ <0 0x11c10000 0 0x1000>,
+ <0 0x11d20000 0 0x1000>,
+ <0 0x11e00000 0 0x1000>,
+ <0 0x11e20000 0 0x1000>,
+ <0 0x11f00000 0 0x1000>,
+ <0 0x11f10000 0 0x1000>,
+ <0 0x1000b000 0 0x1000>;
+ reg-names = "gpio", "iocfg_rt", "iocfg_rm",
+ "iocfg_rb", "iocfg_lb", "iocfg_bl",
+ "iocfg_tm", "iocfg_tl", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 56>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ #interrupt-cells = <2>;
+
+ mdio_pins: mdio-pins {
+ mux {
+ function = "eth";
+ groups = "smi_mdc_mdio";
+ };
+ };
+
+ spi0_flash_pins: spi0-pins {
+ mux {
+ function = "spi";
+ groups = "spi0", "spi0_wp_hold";
+ };
+
+ conf-pu {
+ pins = "SPI0_CS", "SPI0_HOLD", "SPI0_WP";
+ drive-strength = <MTK_DRIVE_8mA>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_11>;
+ };
+
+ conf-pd {
+ pins = "SPI0_CLK", "SPI0_MOSI", "SPI0_MISO";
+ drive-strength = <MTK_DRIVE_8mA>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_11>;
+ };
+ };
+
+ pcie_pins: pcie-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_clk", "pcie_wake", "pcie_pereset";
+ };
+ };
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
index 0d24840..c30cd0d 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
@@ -67,11 +67,11 @@
- gpio-ranges
patternProperties:
- '-[0-9]+$':
+ '-pins(-[a-z]+)?$':
type: object
additionalProperties: false
patternProperties:
- 'pins':
+ '^pins':
type: object
additionalProperties: false
description: |
@@ -210,7 +210,7 @@
interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <2>;
- i2c0_pins_a: i2c-0 {
+ i2c0_pins_a: i2c0-pins {
pins1 {
pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
<PINMUX_GPIO49__FUNC_SDA5>;
@@ -219,7 +219,7 @@
};
};
- i2c1_pins_a: i2c-1 {
+ i2c1_pins_a: i2c1-pins {
pins {
pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
<PINMUX_GPIO51__FUNC_SDA3>;
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
new file mode 100644
index 0000000..4b96884
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
@@ -0,0 +1,197 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8365-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8365 Pin Controller
+
+maintainers:
+ - Zhiyong Tao <zhiyong.tao@mediatek.com>
+ - Bernhard Rosenkränzer <bero@baylibre.com>
+
+description: |
+ The MediaTek's MT8365 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8365-pinctrl
+
+ reg:
+ maxItems: 1
+
+ mediatek,pctl-regmap:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
+ minItems: 1
+ maxItems: 2
+ description: |
+ Should be phandles of the syscfg node.
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ Number of cells in GPIO specifier. Since the generic GPIO
+ binding is used, the amount of cells must be specified as 2. See the below
+ mentioned gpio binding representation for description of particular cells.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+patternProperties:
+ "-pins$":
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "pins$":
+ type: object
+ additionalProperties: false
+ description: |
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pinmux:
+ description:
+ integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in <soc>-pinfunc.h directly.
+
+ bias-disable: true
+
+ bias-pull-up:
+ description: |
+ Besides generic pinconfig options, it can be used as the pull up
+ settings for 2 pull resistors, R0 and R1. User can configure those
+ special pins.
+
+ bias-pull-down: true
+
+ input-enable: true
+
+ input-disable: true
+
+ output-low: true
+
+ output-high: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ mediatek,drive-strength-adv:
+ description: |
+ Describe the specific driving setup property.
+ For I2C pins, the existing generic driving setup can only support
+ 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they
+ can support 0.125/0.25/0.5/1mA adjustment. If we enable specific
+ driving setup, the existing generic setup will be disabled.
+ The specific driving setup is controlled by E1E0EN.
+ When E1=0/E0=0, the strength is 0.125mA.
+ When E1=0/E0=1, the strength is 0.25mA.
+ When E1=1/E0=0, the strength is 0.5mA.
+ When E1=1/E0=1, the strength is 1mA.
+ EN is used to enable or disable the specific driving setup.
+ Valid arguments are described as below:
+ 0: (E1, E0, EN) = (0, 0, 0)
+ 1: (E1, E0, EN) = (0, 0, 1)
+ 2: (E1, E0, EN) = (0, 1, 0)
+ 3: (E1, E0, EN) = (0, 1, 1)
+ 4: (E1, E0, EN) = (1, 0, 0)
+ 5: (E1, E0, EN) = (1, 0, 1)
+ 6: (E1, E0, EN) = (1, 1, 0)
+ 7: (E1, E0, EN) = (1, 1, 1)
+ So the valid arguments are from 0 to 7.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ mediatek,pull-up-adv:
+ description: |
+ Pull up setings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ description: |
+ Pull down settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,tdsel:
+ description: |
+ An integer describing the steps for output level shifter duty
+ cycle when asserted (high pulse width adjustment). Valid arguments
+ are from 0 to 15.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ mediatek,rdsel:
+ description: |
+ An integer describing the steps for input level shifter duty cycle
+ when asserted (high pulse width adjustment). Valid arguments are
+ from 0 to 63.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt8365-pinfunc.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pio: pinctrl@1000b000 {
+ compatible = "mediatek,mt8365-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+
+ pio-pins {
+ pins {
+ pinmux = <MT8365_PIN_59_SDA1__FUNC_SDA1_0>, <MT8365_PIN_60_SCL1__FUNC_SCL1_0>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ bias-pull-up;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml
new file mode 100644
index 0000000..3007472
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5332-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ5332 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ5332 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,ipq5332-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+ "#gpio-cells": true
+ gpio-ranges: true
+ wakeup-parent: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 27
+
+ gpio-line-names:
+ maxItems: 53
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq5332-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq5332-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq5332-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-4][0-9]|5[0-2])$"
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_char0, atest_char1, atest_char2, atest_char3,
+ atest_tic, audio_pri, audio_pri0, audio_pri1, audio_sec,
+ audio_sec0, audio_sec1, blsp0_i2c, blsp0_spi, blsp0_uart0,
+ blsp0_uart1, blsp1_i2c0, blsp1_i2c1, blsp1_spi0, blsp1_spi1,
+ blsp1_uart0, blsp1_uart1, blsp1_uart2, blsp2_i2c0, blsp2_i2c1,
+ blsp2_spi, blsp2_spi0, blsp2_spi1, core_voltage, cri_trng0,
+ cri_trng1, cri_trng2, cri_trng3, cxc_clk, cxc_data, dbg_out,
+ gcc_plltest, gcc_tlmm, gpio, lock_det, mac0, mac1, mdc0, mdc1,
+ mdio0, mdio1, pc, pcie0_clk, pcie0_wake, pcie1_clk, pcie1_wake,
+ pcie2_clk, pcie2_wake, pll_test, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, pta, pwm0, pwm1, pwm2, pwm3,
+ qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, qdss_cti_trig_in_b0,
+ qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
+ qdss_cti_trig_out_a1, qdss_cti_trig_out_b0,
+ qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_traceclk_b,
+ qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a,
+ qdss_tracedata_b, qspi_data, qspi_clk, qspi_cs, resout, rx0,
+ rx1, sdc_data, sdc_clk, sdc_cmd, tsens_max, wci_txd, wci_rxd,
+ wsi_clk, wsi_clk3, wsi_data, wsi_data3, wsis_reset, xfem ]
+
+ bias-pull-down: true
+ bias-pull-up: true
+ bias-disable: true
+ drive-strength: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq5332-tlmm";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ gpio-ranges = <&tlmm 0 0 53>;
+ interrupts = <GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+
+ serial0-state {
+ pins = "gpio18", "gpio19";
+ function = "blsp0_uart0";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
index 93f231c..28f1b6a 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
@@ -19,7 +19,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml
index 5687aca..3137db9 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml
index a0a1217..96b598b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml
index a4f6e4c..c7c94d7 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
'#interrupt-cells': true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
index 3b79f5b..6cb667f 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
@@ -20,7 +20,9 @@
description: Specifies the base address and size of the TLMM register space
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -54,7 +56,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-6])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
minItems: 1
maxItems: 36
@@ -66,8 +68,8 @@
enum: [ gpio, cci_i2c0, blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim5,
blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_spi1,
blsp_spi2, blsp_spi3, blsp_spi5, blsp_uart1, blsp_uart2,
- blsp_uart3, blsp_uart4, blsp_uart5, cam_mclk0, cam_mclk1, sdc3,
- wlan ]
+ blsp_uart3, blsp_uart4, blsp_uart5, cam_mclk0, cam_mclk1,
+ gp0_clk, gp1_clk, sdc3, wlan ]
bias-pull-down: true
bias-pull-up: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml
index ad0cad4..348d84c 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml
index cc6d0c9..85082ad 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -61,7 +63,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-7])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-2])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, qdsd_data1,
qdsd_data2, qdsd_data3 ]
@@ -125,7 +127,7 @@
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 117>;
+ gpio-ranges = <&tlmm 0 0 113>;
interrupt-controller;
#interrupt-cells = <2>;
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml
index 5495f58..633c9e5 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
index c9a4a79..ce21982 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
@@ -19,7 +19,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -51,7 +53,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[01])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0,
qdsd_data1, qdsd_data2, qdsd_data3 ]
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml
index 33d07d5..cf386f6 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml
index 9287cbb..afe4a80 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml
index 858f457..5dfcc3ea 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml
index 55d5439..0c4936f 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -32,10 +34,10 @@
gpio-reserved-ranges:
minItems: 1
- maxItems: 75
+ maxItems: 73
gpio-line-names:
- maxItems: 150
+ maxItems: 146
patternProperties:
"-state$":
@@ -61,7 +63,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-5])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
sdc2_cmd, sdc2_data, sdc3_clk, sdc3_cmd, sdc3_data ]
minItems: 1
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml
index 8e1cd4b..047b458 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml
index 21ba32c..c07ee98 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml
@@ -20,7 +20,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index 29dd503..db505fd 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -40,6 +40,10 @@
- qcom,pm8350b-gpio
- qcom,pm8350c-gpio
- qcom,pm8450-gpio
+ - qcom,pm8550-gpio
+ - qcom,pm8550b-gpio
+ - qcom,pm8550ve-gpio
+ - qcom,pm8550vs-gpio
- qcom,pm8916-gpio
- qcom,pm8917-gpio
- qcom,pm8921-gpio
@@ -52,10 +56,12 @@
- qcom,pmi8994-gpio
- qcom,pmi8998-gpio
- qcom,pmk8350-gpio
+ - qcom,pmk8550-gpio
- qcom,pmm8155au-gpio
- qcom,pmp8074-gpio
- qcom,pmr735a-gpio
- qcom,pmr735b-gpio
+ - qcom,pmr735d-gpio
- qcom,pms405-gpio
- qcom,pmx55-gpio
- qcom,pmx65-gpio
@@ -111,6 +117,7 @@
enum:
- qcom,pm8008-gpio
- qcom,pmi8950-gpio
+ - qcom,pmr735d-gpio
then:
properties:
gpio-line-names:
@@ -146,6 +153,8 @@
enum:
- qcom,pm8018-gpio
- qcom,pm8019-gpio
+ - qcom,pm8550vs-gpio
+ - qcom,pmk8550-gpio
then:
properties:
gpio-line-names:
@@ -162,6 +171,7 @@
enum:
- qcom,pm8226-gpio
- qcom,pm8350b-gpio
+ - qcom,pm8550ve-gpio
- qcom,pm8950-gpio
then:
properties:
@@ -236,6 +246,8 @@
- qcom,pm8038-gpio
- qcom,pm8150b-gpio
- qcom,pm8150l-gpio
+ - qcom,pm8550-gpio
+ - qcom,pm8550b-gpio
- qcom,pmc8180c-gpio
- qcom,pmp8074-gpio
- qcom,pms405-gpio
@@ -411,6 +423,10 @@
- gpio1-gpio8 for pm8350b
- gpio1-gpio9 for pm8350c
- gpio1-gpio4 for pm8450
+ - gpio1-gpio12 for pm8550
+ - gpio1-gpio12 for pm8550b
+ - gpio1-gpio8 for pm8550ve
+ - gpio1-gpio6 for pm8550vs
- gpio1-gpio38 for pm8917
- gpio1-gpio44 for pm8921
- gpio1-gpio36 for pm8941
@@ -421,10 +437,12 @@
- gpio1-gpio2 for pmi8950
- gpio1-gpio10 for pmi8994
- gpio1-gpio4 for pmk8350
+ - gpio1-gpio6 for pmk8550
- gpio1-gpio10 for pmm8155au
- gpio1-gpio12 for pmp8074 (holes on gpio1 and gpio12)
- gpio1-gpio4 for pmr735a
- gpio1-gpio4 for pmr735b
+ - gpio1-gpio2 for pmr735d
- gpio1-gpio12 for pms405 (holes on gpio1, gpio9
and gpio10)
- gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
index 72cce38..9412b93 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
@@ -74,7 +74,7 @@
oneOf:
- $ref: "#/$defs/qcom-pmic-mpp-state"
- patternProperties:
- "mpp":
+ '-pins$':
$ref: "#/$defs/qcom-pmic-mpp-state"
additionalProperties: false
@@ -179,7 +179,7 @@
};
default-state {
- gpio-mpp {
+ gpio-pins {
pins = "mpp1", "mpp2", "mpp3", "mpp4";
function = "digital";
input-enable;
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
index adf64bf..6271fd1 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
@@ -19,7 +19,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml
index 29d50c4..20bc967a 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml
@@ -26,7 +26,9 @@
- const: north
- const: east
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml
new file mode 100644
index 0000000..7e5fb9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,qdu1000-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QDU1000/QRU1000 TLMM block
+
+maintainers:
+ - Melody Olvera <quic_molvera@quicinc.com>
+
+description: |
+ Top Level Mode Multiplexer pin controller found in the QDU1000 and
+ QRU1000 SoCs.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qdu1000-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts: true
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 76
+
+ gpio-line-names:
+ maxItems: 151
+
+ "#gpio-cells": true
+ gpio-ranges: true
+ wakeup-parent: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-qdu1000-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-qdu1000-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-qdu1000-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|150)$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ atest_char, atest_usb, char_exec, CMO_PRI, cmu_rng,
+ dbg_out_clk, ddr_bist, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4,
+ ddr_pxi5, ddr_pxi6, ddr_pxi7, eth012_int_n, eth345_int_n,
+ gcc_gp1, gcc_gp2, gcc_gp3, gpio, gps_pps_in, hardsync_pps_in,
+ intr_c, jitter_bist_ref, pcie_clkreqn, phase_flag, pll_bist,
+ pll_clk, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable,
+ qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
+ qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss,
+ qlink3_enable, qlink3_request, qlink3_wmss, qlink4_enable,
+ qlink4_request, qlink4_wmss, qlink5_enable, qlink5_request,
+ qlink5_wmss, qlink6_enable, qlink6_request, qlink6_wmss,
+ qlink7_enable, qlink7_request, qlink7_wmss, qspi_clk, qspi_cs,
+ qspi0, qspi1, qspi2, qspi3, qup00, qup01, qup02, qup03, qup04,
+ qup05, qup06, qup07, qup08, qup10, qup11, qup12, qup13, qup14,
+ qup15, qup16, qup17, qup20, qup21, qup22, SI5518_INT, smb_alert,
+ smb_clk, smb_dat, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3,
+ tgu_ch4, tgu_ch5, tgu_ch6, tgu_ch7, tmess_prng0, tmess_prng1,
+ tmess_prng2, tmess_prng3, tod_pps_in, tsense_pwm1, tsense_pwm2,
+ usb2phy_ac, usb_con_det, usb_dfp_en, usb_phy, vfr_0, vfr_1,
+ vsense_trigger ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl@f000000 {
+ compatible = "qcom,qdu1000-tlmm";
+ reg = <0xf000000 0x1000000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 151>;
+ wakeup-parent = <&pdc>;
+
+ uart0-default-state {
+ pins = "gpio6", "gpio7", "gpio8", "gpio9";
+ function = "qup00";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
new file mode 100644
index 0000000..70d9106
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sa8775p-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SA8775P TLMM block
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm SA8775P SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sa8775p-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts: true
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+ "#gpio-cells": true
+ gpio-ranges: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 74
+
+ gpio-line-names:
+ maxItems: 148
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sa8775p-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sa8775p-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sa8775p-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-7])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, ufs_reset ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_usb2, audio_ref, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cci_timer5, cci_timer6, cci_timer7, cci_timer8, cci_timer9,
+ cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5, edp0_hot,
+ edp0_lcd, edp1_hot, edp1_lcd, edp2_hot, edp2_lcd, edp3_hot,
+ edp3_lcd, emac0_mcg0, emac0_mcg1, emac0_mcg2, emac0_mcg3,
+ emac0_mdc, emac0_mdio, emac0_ptp_aux, emac0_ptp_pps, emac1_mcg0,
+ emac1_mcg1, emac1_mcg2, emac1_mcg3, emac1_mdc, emac1_mdio,
+ emac1_ptp_aux, emac1_ptp_pps, gcc_gp1, gcc_gp2, gcc_gp3,
+ gcc_gp4, gcc_gp5, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c,
+ jitter_bist, mdp0_vsync0, mdp0_vsync1, mdp0_vsync2, mdp0_vsync3,
+ mdp0_vsync4, mdp0_vsync5, mdp0_vsync6, mdp0_vsync7, mdp0_vsync8,
+ mdp1_vsync0, mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4,
+ mdp1_vsync5, mdp1_vsync6, mdp1_vsync7, mdp1_vsync8, mdp_vsync,
+ mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws, mi2s2_data0,
+ mi2s2_data1, mi2s2_sck, mi2s2_ws, mi2s_mclk0, mi2s_mclk1,
+ pcie0_clkreq, pcie1_clkreq, phase_flag, pll_bist, pll_clk,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio, qup0_se0, qup0_se1, qup0_se2, qup0_se3, qup0_se4,
+ qup0_se5, qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4,
+ qup1_se5, qup1_se6, qup2_se0, qup2_se1, qup2_se2, qup2_se3,
+ qup2_se4, qup2_se5, qup2_se6, qup3_se0, sailss_emac0,
+ sailss_ospi, sail_top, sgmii_phy, tb_trig, tgu_ch0, tgu_ch1,
+ tgu_ch2, tgu_ch3, tgu_ch4, tgu_ch5, tsense_pwm1, tsense_pwm2,
+ tsense_pwm3, tsense_pwm4, usb2phy_ac, vsense_trigger ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@f000000 {
+ compatible = "qcom,sa8775p-tlmm";
+ reg = <0xf000000 0x1000000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 148>;
+
+ qup-uart10-state {
+ pins = "gpio46", "gpio47";
+ function = "qup1_se3";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml
index b40f6dc..f33792a 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml
@@ -26,7 +26,9 @@
- const: north
- const: south
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
index f7ec8a4..e51feb4 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
@@ -59,7 +59,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9])$"
+ - pattern: "^gpio([0-9]|1[0-4])$"
minItems: 1
maxItems: 15
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml
index 24191d5..0ace55c 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml
@@ -28,7 +28,9 @@
- const: east
- const: south
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
'#interrupt-cells': true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml
index 7d25893..200b3b6 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml
@@ -65,7 +65,7 @@
List of gpio pins affected by the properties specified in this
subnode.
items:
- pattern: "^gpio([0-1]|1[0-8])$"
+ pattern: "^gpio([0-9]|1[0-8])$"
function:
enum: [ swr_tx_clk, swr_tx_data, swr_rx_clk, swr_rx_data,
@@ -94,14 +94,12 @@
2: Lower Slew rate (slower edges)
3: Reserved (No adjustments)
+ bias-bus-hold: true
bias-pull-down: true
-
bias-pull-up: true
-
bias-disable: true
-
+ input-enable: true
output-high: true
-
output-low: true
required:
@@ -136,7 +134,7 @@
clock-names = "core", "audio";
gpio-controller;
#gpio-cells = <2>;
- gpio-ranges = <&lpi_tlmm 0 0 18>;
+ gpio-ranges = <&lpi_tlmm 0 0 19>;
dmic01-state {
dmic01-clk-pins {
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
index 4efde29..97b27d6 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml
index bd4fd84..ea6bd0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml
@@ -31,7 +31,9 @@
- const: center
- const: north
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml
index 7585117..f586b3a 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml
index c962777..23d7c03 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml
@@ -23,7 +23,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -48,6 +50,10 @@
$ref: "#/$defs/qcom-sdm845-tlmm-state"
additionalProperties: false
+ "-hog(-[0-9]+)?$":
+ required:
+ - gpio-hog
+
$defs:
qcom-sdm845-tlmm-state:
type: object
@@ -117,6 +123,7 @@
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pinctrl@3400000 {
@@ -130,6 +137,12 @@
gpio-ranges = <&tlmm 0 0 151>;
wakeup-parent = <&pdc_intc>;
+ ap-suspend-l-hog {
+ gpio-hog;
+ gpios = <126 GPIO_ACTIVE_LOW>;
+ output-low;
+ };
+
cci0-default-state {
pins = "gpio17", "gpio18";
function = "cci_i2c";
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
index a76117e..a401752 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
@@ -20,7 +20,9 @@
description: Specifies the base address and size of the TLMM register space
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -53,7 +55,7 @@
List of gpio pins affected by the properties specified in this subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-7])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
minItems: 1
maxItems: 36
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
index 2f53905..89c5562 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
@@ -19,7 +19,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml
index 164f24d..2932548 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml
@@ -26,7 +26,9 @@
- const: south
- const: east
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml
index e1dd54a..c9bc489 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml
@@ -27,7 +27,9 @@
- const: south
- const: east
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml
index 41e3e0a..d95935f 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml
@@ -22,11 +22,21 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ minItems: 9
+ maxItems: 9
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
- gpio-reserved-ranges: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 78
+
+ gpio-line-names:
+ maxItems: 156
+
"#gpio-cells": true
gpio-ranges: true
wakeup-parent: true
@@ -61,7 +71,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-7])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-5])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
minItems: 1
maxItems: 36
@@ -118,7 +128,16 @@
pinctrl@f100000 {
compatible = "qcom,sm6350-tlmm";
reg = <0x0f100000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
+
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml
index d54ebb2..66cef48 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -61,7 +63,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-6])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-5])$"
- enum: [ ufs_reset, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
sdc2_cmd, sdc2_data ]
minItems: 1
@@ -132,7 +134,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 157>;
+ gpio-ranges = <&tlmm 0 0 157>; /* GPIOs + ufs_reset */
gpio-wo-subnode-state {
pins = "gpio1";
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml
index 85adddb..4376a9b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml
@@ -27,7 +27,9 @@
- const: north
- const: south
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml
index bd45faa..de9d885 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml
@@ -64,7 +64,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9])$"
+ - pattern: "^gpio([0-9]|1[0-3])$"
minItems: 1
maxItems: 14
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
index c80f384..cf561df 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
@@ -25,7 +25,9 @@
- const: south
- const: north
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -129,6 +131,6 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 180>;
+ gpio-ranges = <&tlmm 0 0 181>; /* GPIOs + ufs_reset */
wakeup-parent = <&pdc>;
};
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml
index 0b1e4aa..797242f 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml
@@ -22,11 +22,20 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
- gpio-reserved-ranges: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 102
+
+ gpio-line-names:
+ maxItems: 203
+
"#gpio-cells": true
gpio-ranges: true
wakeup-parent: true
@@ -61,7 +70,7 @@
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-3])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-2])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
minItems: 1
maxItems: 36
@@ -100,6 +109,7 @@
bias-pull-down: true
bias-pull-up: true
drive-strength: true
+ input-disable: true
input-enable: true
output-high: true
output-low: true
@@ -120,7 +130,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 203>;
+ gpio-ranges = <&tlmm 0 0 204>; /* GPIOs + ufs_reset */
gpio-wo-subnode-state {
pins = "gpio1";
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml
index 01a0a4a..8bf51df 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml
@@ -65,7 +65,7 @@
List of gpio pins affected by the properties specified in this
subnode.
items:
- pattern: "^gpio([0-9]|[1-2][0-9])$"
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
function:
enum: [ swr_tx_clk, swr_tx_data, swr_rx_clk, swr_rx_data,
@@ -96,14 +96,12 @@
2: Lower Slew rate (slower edges)
3: Reserved (No adjustments)
+ bias-bus-hold: true
bias-pull-down: true
-
bias-pull-up: true
-
bias-disable: true
-
+ input-enable: true
output-high: true
-
output-low: true
required:
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml
index 4a1d10d..56c8046 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml
@@ -22,7 +22,9 @@
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells": true
gpio-controller: true
@@ -32,7 +34,7 @@
maxItems: 105
gpio-line-names:
- maxItems: 209
+ maxItems: 210
"#gpio-cells": true
gpio-ranges: true
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml
new file mode 100644
index 0000000..8f60a91
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 SoC LPASS LPI TLMM
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8550 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm8550-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI pins SLEW registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8550-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8550-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8550-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
+
+ function:
+ enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk,
+ dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b,
+ ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk,
+ i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk,
+ i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, i2s4_clk,
+ i2s4_data, i2s4_ws, slimbus_clk, slimbus_data, swr_rx_clk,
+ swr_rx_data, swr_tx_clk, swr_tx_data, wsa_swr_clk,
+ wsa_swr_data, wsa2_swr_clk, wsa2_swr_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ slew-rate:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ 0: No adjustments
+ 1: Higher Slew rate (faster edges)
+ 2: Lower Slew rate (slower edges)
+ 3: Reserved (No adjustments)
+
+ bias-bus-hold: true
+ bias-pull-down: true
+ bias-pull-up: true
+ bias-disable: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+
+ lpass_tlmm: pinctrl@6e80000 {
+ compatible = "qcom,sm8550-lpass-lpi-pinctrl";
+ reg = <0x06e80000 0x20000>,
+ <0x0725a000 0x10000>;
+
+ clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 23>;
+
+ tx-swr-sleep-clk-state {
+ pins = "gpio0";
+ function = "swr_tx_clk";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml
new file mode 100644
index 0000000..a457425
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml
@@ -0,0 +1,163 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8550-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8550 TLMM block
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8550 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8550-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts: true
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 105
+
+ gpio-line-names:
+ maxItems: 210
+
+ "#gpio-cells": true
+ gpio-ranges: true
+ wakeup-parent: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8550-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8550-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8550-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ aon_cci, aoss_cti, atest_char, atest_usb,
+ audio_ext_mclk0, audio_ext_mclk1, audio_ref_clk,
+ cam_aon_mclk4, cam_mclk, cci_async_in, cci_i2c_scl,
+ cci_i2c_sda, cci_timer, cmu_rng, coex_uart1_rx,
+ coex_uart1_tx, coex_uart2_rx, coex_uart2_tx,
+ cri_trng, dbg_out_clk, ddr_bist_complete,
+ ddr_bist_fail, ddr_bist_start, ddr_bist_stop,
+ ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, dp_hot,
+ gcc_gp1, gcc_gp2, gcc_gp3, gpio, i2chub0_se0,
+ i2chub0_se1, i2chub0_se2, i2chub0_se3, i2chub0_se4,
+ i2chub0_se5, i2chub0_se6, i2chub0_se7, i2chub0_se8,
+ i2chub0_se9, i2s0_data0, i2s0_data1, i2s0_sck,
+ i2s0_ws, i2s1_data0, i2s1_data1, i2s1_sck, i2s1_ws,
+ ibi_i3c, jitter_bist, mdp_vsync, mdp_vsync0_out,
+ mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2,
+ pcie0_clk_req_n, pcie1_clk_req_n, phase_flag,
+ pll_bist_sync, pll_clk_aux, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio,
+ qlink0_enable, qlink0_request, qlink0_wmss,
+ qlink1_enable, qlink1_request, qlink1_wmss,
+ qlink2_enable, qlink2_request, qlink2_wmss,
+ qspi0, qspi1, qspi2, qspi3, qspi_clk, qspi_cs,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4,
+ qup1_se5, qup1_se6, qup1_se7, qup2_se0,
+ qup2_se0_l0_mira, qup2_se0_l0_mirb, qup2_se0_l1_mira,
+ qup2_se0_l1_mirb, qup2_se0_l2_mira, qup2_se0_l2_mirb,
+ qup2_se0_l3_mira, qup2_se0_l3_mirb, qup2_se1,
+ qup2_se2, qup2_se3, qup2_se4, qup2_se5, qup2_se6,
+ qup2_se7, sd_write_protect, sdc40, sdc41, sdc42,
+ sdc43, sdc4_clk, sdc4_cmd, tb_trig_sdc2, tb_trig_sdc4,
+ tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout,
+ tgu_ch3_trigout, tmess_prng0, tmess_prng1, tmess_prng2,
+ tmess_prng3, tsense_pwm1, tsense_pwm2, tsense_pwm3,
+ uim0_clk, uim0_data, uim0_present, uim0_reset,
+ uim1_clk, uim1_data, uim1_present, uim1_reset,
+ usb1_hs, usb_phy, vfr_0, vfr_1, vsense_trigger_mirnat ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sm8550-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 211>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio26";
+ function = "qup2_se7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio27";
+ function = "qup2_se7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml
index e1354f0..cb5ba1b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml
@@ -16,8 +16,9 @@
properties:
interrupts:
description:
- Specifies the TLMM summary IRQ
- maxItems: 1
+ TLMM summary IRQ and dirconn interrupts.
+ minItems: 1
+ maxItems: 9
interrupt-controller: true
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml
index 6f17f39..1e63ea3 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml
@@ -29,47 +29,609 @@
$ref: pinmux-node.yaml#
properties:
- groups:
- description: The pin group to select.
- enum: [
- # common
- i2c, spi, wdt,
-
- # For MT7620 SoC
- ephy, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, spi refclk,
- uartf, uartlite, wled,
-
- # For MT7628 and MT7688 SoCs
- gpio, i2s, p0led_an, p0led_kn, p1led_an, p1led_kn, p2led_an,
- p2led_kn, p3led_an, p3led_kn, p4led_an, p4led_kn, perst, pwm0,
- pwm1, refclk, sdmode, spi cs1, spis, uart0, uart1, uart2,
- wled_an, wled_kn,
- ]
-
function:
- description: The mux function to select.
- enum: [
- # common
- gpio, i2c, refclk, spi,
+ description:
+ A string containing the name of the function to mux to the group.
+ anyOf:
+ - description: For MT7620 SoC
+ enum: [ephy, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, mdio, nand, pa,
+ pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf, refclk,
+ rgmii1, rgmii2, sd, spi, spi refclk, uartf, uartlite, wdt refclk,
+ wdt rst, wled]
- # For MT7620 SoC
- ephy, gpio i2s, gpio uartf, i2s uartf, mdio, nand, pa,
- pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf,
- rgmii1, rgmii2, sd, spi refclk, uartf, uartlite, wdt refclk,
- wdt rst, wled,
+ - description: For MT7628 and MT7688 SoCs
+ enum: [antenna, debug, gpio, i2c, i2s, jtag, p0led_an, p0led_kn,
+ p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn,
+ p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, pwm_uart2,
+ refclk, rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, spi, spi cs1,
+ spis, sw_r, uart0, uart1, uart2, utif, wdt, wled_an, wled_kn, -]
- # For MT7628 and MT7688 SoCs
- antenna, debug, i2s, jtag, p0led_an, p0led_kn,
- p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn,
- p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, pwm_uart2,
- rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, spi cs1,
- spis, sw_r, uart0, uart1, uart2, utif, wdt, wled_an, wled_kn, -,
- ]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
required:
- groups
- function
+ allOf:
+ - if:
+ properties:
+ function:
+ const: antenna
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+
+ - if:
+ properties:
+ function:
+ const: debug
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: ephy
+ then:
+ properties:
+ groups:
+ enum: [ephy]
+
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ anyOf:
+ - description: For MT7620 SoC
+ enum: [ephy, i2c, mdio, nd_sd, pa, pcie, rgmii1, rgmii2,
+ spi, spi refclk, uartf, uartlite, wdt, wled]
+
+ - description: For MT7628 and MT7688 SoCs
+ enum: [gpio, i2c, i2s, p0led_an, p0led_kn, p1led_an,
+ p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn,
+ p4led_an, p4led_kn, perst, pwm0, pwm1, refclk,
+ sdmode, spi, spi cs1, spis, uart0, uart1, uart2,
+ wdt, wled_an, wled_kn]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [p0led_an, p0led_kn, p1led_an, p1led_kn, p2led_an,
+ p2led_kn, p3led_an, p3led_kn, p4led_an, p4led_kn,
+ sdmode]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: nand
+ then:
+ properties:
+ groups:
+ enum: [nd_sd]
+
+ - if:
+ properties:
+ function:
+ const: p0led_an
+ then:
+ properties:
+ groups:
+ enum: [p0led_an]
+
+ - if:
+ properties:
+ function:
+ const: p0led_kn
+ then:
+ properties:
+ groups:
+ enum: [p0led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p1led_an
+ then:
+ properties:
+ groups:
+ enum: [p1led_an]
+
+ - if:
+ properties:
+ function:
+ const: p1led_kn
+ then:
+ properties:
+ groups:
+ enum: [p1led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p2led_an
+ then:
+ properties:
+ groups:
+ enum: [p2led_an]
+
+ - if:
+ properties:
+ function:
+ const: p2led_kn
+ then:
+ properties:
+ groups:
+ enum: [p2led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p3led_an
+ then:
+ properties:
+ groups:
+ enum: [p3led_an]
+
+ - if:
+ properties:
+ function:
+ const: p3led_kn
+ then:
+ properties:
+ groups:
+ enum: [p3led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p4led_an
+ then:
+ properties:
+ groups:
+ enum: [p4led_an]
+
+ - if:
+ properties:
+ function:
+ const: p4led_kn
+ then:
+ properties:
+ groups:
+ enum: [p4led_kn]
+
+ - if:
+ properties:
+ function:
+ const: pa
+ then:
+ properties:
+ groups:
+ enum: [pa]
+
+ - if:
+ properties:
+ function:
+ const: pcie
+ then:
+ properties:
+ groups:
+ enum: [gpio]
+
+ - if:
+ properties:
+ function:
+ const: pcie refclk
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcie rst
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: perst
+ then:
+ properties:
+ groups:
+ enum: [perst]
+
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ enum: [uart1, uart2]
+
+ - if:
+ properties:
+ function:
+ const: pwm0
+ then:
+ properties:
+ groups:
+ enum: [pwm0]
+
+ - if:
+ properties:
+ function:
+ const: pwm1
+ then:
+ properties:
+ groups:
+ enum: [pwm1]
+
+ - if:
+ properties:
+ function:
+ const: pwm_uart2
+ then:
+ properties:
+ groups:
+ enum: [spis]
+
+ - if:
+ properties:
+ function:
+ const: refclk
+ then:
+ properties:
+ groups:
+ anyOf:
+ - description: For MT7620 SoC
+ enum: [mdio]
+
+ - description: For MT7628 and MT7688 SoCs
+ enum: [gpio, refclk, spi cs1]
+
+ - if:
+ properties:
+ function:
+ const: rgmii1
+ then:
+ properties:
+ groups:
+ enum: [rgmii1]
+
+ - if:
+ properties:
+ function:
+ const: rgmii2
+ then:
+ properties:
+ groups:
+ enum: [rgmii2]
+
+ - if:
+ properties:
+ function:
+ const: rsvd
+ then:
+ properties:
+ groups:
+ enum: [p0led_an, p0led_kn, wled_an, wled_kn]
+
+ - if:
+ properties:
+ function:
+ const: sd
+ then:
+ properties:
+ groups:
+ enum: [nd_sd]
+
+ - if:
+ properties:
+ function:
+ const: sdxc
+ then:
+ properties:
+ groups:
+ enum: [sdmode]
+
+ - if:
+ properties:
+ function:
+ const: sdxc d5 d4
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: sdxc d6
+ then:
+ properties:
+ groups:
+ enum: [pwm1]
+
+ - if:
+ properties:
+ function:
+ const: sdxc d7
+ then:
+ properties:
+ groups:
+ enum: [pwm0]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: spi cs1
+ then:
+ properties:
+ groups:
+ enum: [spi cs1]
+
+ - if:
+ properties:
+ function:
+ const: spi refclk
+ then:
+ properties:
+ groups:
+ enum: [spi refclk]
+
+ - if:
+ properties:
+ function:
+ const: spis
+ then:
+ properties:
+ groups:
+ enum: [spis]
+
+ - if:
+ properties:
+ function:
+ const: sw_r
+ then:
+ properties:
+ groups:
+ enum: [uart1]
+
+ - if:
+ properties:
+ function:
+ const: uart0
+ then:
+ properties:
+ groups:
+ enum: [uart0]
+
+ - if:
+ properties:
+ function:
+ const: uart1
+ then:
+ properties:
+ groups:
+ enum: [uart1]
+
+ - if:
+ properties:
+ function:
+ const: uart2
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: utif
+ then:
+ properties:
+ groups:
+ enum: [p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an,
+ p3led_kn, p4led_an, p4led_kn, pwm0, pwm1, sdmode, spis]
+
+ - if:
+ properties:
+ function:
+ const: wdt
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wdt refclk
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wdt rst
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wled
+ then:
+ properties:
+ groups:
+ enum: [wled]
+
+ - if:
+ properties:
+ function:
+ const: wled_an
+ then:
+ properties:
+ groups:
+ enum: [wled_an]
+
+ - if:
+ properties:
+ function:
+ const: wled_kn
+ then:
+ properties:
+ groups:
+ enum: [wled_kn]
+
+ - if:
+ properties:
+ function:
+ const: "-"
+ then:
+ properties:
+ groups:
+ enum: [i2c, spi cs1, uart0]
+
additionalProperties: false
additionalProperties: false
@@ -83,7 +645,6 @@
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,mt7620-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml
index 61e5c84..1b1d37b 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml
@@ -29,21 +29,213 @@
$ref: pinmux-node.yaml#
properties:
- groups:
- description: The pin group to select.
- enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, uart1,
- uart2, uart3, wdt]
-
function:
- description: The mux function to select.
+ description:
+ A string containing the name of the function to mux to the group.
enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk,
pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, spi,
uart1, uart2, uart3, wdt refclk, wdt rst]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
required:
- groups
- function
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi,
+ uart1, uart2, uart3, wdt]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s
+ then:
+ properties:
+ groups:
+ enum: [uart3]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: nand1
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: nand2
+ then:
+ properties:
+ groups:
+ enum: [sdhci]
+
+ - if:
+ properties:
+ function:
+ const: pcie refclk
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcie rst
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: rgmii1
+ then:
+ properties:
+ groups:
+ enum: [rgmii1]
+
+ - if:
+ properties:
+ function:
+ const: rgmii2
+ then:
+ properties:
+ groups:
+ enum: [rgmii2]
+
+ - if:
+ properties:
+ function:
+ const: sdhci
+ then:
+ properties:
+ groups:
+ enum: [sdhci]
+
+ - if:
+ properties:
+ function:
+ const: spdif2
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: spdif3
+ then:
+ properties:
+ groups:
+ enum: [uart3]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uart1
+ then:
+ properties:
+ groups:
+ enum: [uart1]
+
+ - if:
+ properties:
+ function:
+ const: uart2
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: uart3
+ then:
+ properties:
+ groups:
+ enum: [uart3]
+
+ - if:
+ properties:
+ function:
+ const: wdt refclk
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wdt rst
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
additionalProperties: false
additionalProperties: false
@@ -57,7 +249,6 @@
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,mt7621-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml
index 56e5bec..7fd0df8 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml
@@ -29,18 +29,93 @@
$ref: pinmux-node.yaml#
properties:
- groups:
- description: The pin group to select.
- enum: [i2c, spi, uartlite, jtag, mdio, sdram, pci]
-
function:
- description: The mux function to select.
+ description:
+ A string containing the name of the function to mux to the group.
enum: [gpio, i2c, spi, uartlite, jtag, mdio, sdram, pci]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
required:
- groups
- function
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, spi, uartlite, jtag, mdio, sdram, pci]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: sdram
+ then:
+ properties:
+ groups:
+ enum: [sdram]
+
+ - if:
+ properties:
+ function:
+ const: pci
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
additionalProperties: false
additionalProperties: false
@@ -54,7 +129,6 @@
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,rt2880-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
index f602a5d..4d66ca7 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
@@ -30,38 +30,225 @@
$ref: pinmux-node.yaml#
properties:
- groups:
- description: The pin group to select.
- enum: [
- # common
- i2c, jtag, led, mdio, rgmii, spi, spi_cs1, uartf, uartlite,
-
- # For RT3050, RT3052 and RT3350 SoCs
- sdram,
-
- # For RT3352 SoC
- lna, pa
- ]
-
function:
- description: The mux function to select.
- enum: [
- # common
- gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, mdio,
- pcm gpio, pcm i2s, pcm uartf, rgmii, spi, spi_cs1, uartf,
- uartlite, wdg_cs1,
+ description:
+ A string containing the name of the function to mux to the group.
+ anyOf:
+ - description: For RT3050, RT3052 and RT3350 SoCs
+ enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, mdio,
+ pcm gpio, pcm i2s, pcm uartf, rgmii, sdram, spi, uartf,
+ uartlite]
- # For RT3050, RT3052 and RT3350 SoCs
- sdram,
+ - description: For RT3352 SoC
+ enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led,
+ lna, mdio, pa, pcm gpio, pcm i2s, pcm uartf, rgmii, spi,
+ spi_cs1, uartf, uartlite, wdg_cs1]
- # For RT3352 SoC
- lna, pa
- ]
+ - description: For RT5350 SoC
+ enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led,
+ pcm gpio, pcm i2s, pcm uartf, spi, spi_cs1, uartf,
+ uartlite, wdg_cs1]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
required:
- groups
- function
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ anyOf:
+ - description: For RT3050, RT3052 and RT3350 SoCs
+ enum: [i2c, jtag, mdio, rgmii, sdram, spi, uartf,
+ uartlite]
+
+ - description: For RT3352 SoC
+ enum: [i2c, jtag, led, lna, mdio, pa, rgmii, spi, spi_cs1,
+ uartf, uartlite]
+
+ - description: For RT5350 SoC
+ enum: [i2c, jtag, led, spi, spi_cs1, uartf, uartlite]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: led
+ then:
+ properties:
+ groups:
+ enum: [led]
+
+ - if:
+ properties:
+ function:
+ const: lna
+ then:
+ properties:
+ groups:
+ enum: [lna]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: pa
+ then:
+ properties:
+ groups:
+ enum: [pa]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: rgmii
+ then:
+ properties:
+ groups:
+ enum: [rgmii]
+
+ - if:
+ properties:
+ function:
+ const: sdram
+ then:
+ properties:
+ groups:
+ enum: [sdram]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: spi_cs1
+ then:
+ properties:
+ groups:
+ enum: [spi_cs1]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: wdg_cs1
+ then:
+ properties:
+ groups:
+ enum: [spi_cs1]
+
additionalProperties: false
additionalProperties: false
@@ -75,7 +262,6 @@
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,rt305x-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml
index feb6e66..008d9318 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml
@@ -29,21 +29,213 @@
$ref: pinmux-node.yaml#
properties:
- groups:
- description: The pin group to select.
- enum: [ge1, ge2, i2c, jtag, lna a, lna g, mdio, pci, spi, uartf,
- uartlite]
-
function:
- description: The mux function to select.
+ description:
+ A string containing the name of the function to mux to the group.
enum: [ge1, ge2, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag,
lna a, lna g, mdio, pci-dev, pci-fnc, pci-host1, pci-host2,
pcm gpio, pcm i2s, pcm uartf, spi, uartf, uartlite]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
required:
- groups
- function
+ allOf:
+ - if:
+ properties:
+ function:
+ const: ge1
+ then:
+ properties:
+ groups:
+ enum: [ge1]
+
+ - if:
+ properties:
+ function:
+ const: ge2
+ then:
+ properties:
+ groups:
+ enum: [ge2]
+
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [ge1, ge2, i2c, jtag, lna a, lna g, mdio, pci, spi,
+ uartf, uartlite]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: lna a
+ then:
+ properties:
+ groups:
+ enum: [lna a]
+
+ - if:
+ properties:
+ function:
+ const: lna g
+ then:
+ properties:
+ groups:
+ enum: [lna g]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: pci-dev
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pci-fnc
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pci-host1
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pci-host2
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
additionalProperties: false
additionalProperties: false
@@ -57,7 +249,6 @@
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,rt3883-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml
new file mode 100644
index 0000000..ab2d456
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/renesas,rzg2l-poeg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Port Output Enable for GPT (POEG)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The output pins(GTIOCxA and GTIOCxB) of the general PWM timer (GPT) can be
+ disabled by using the port output enabling function for the GPT (POEG).
+ Specifically, either of the following ways can be used.
+ * Input level detection of the GTETRGA to GTETRGD pins.
+ * Output-disable request from the GPT.
+ * SSF bit setting(ie, by setting POEGGn.SSF to 1)
+
+ The state of the GTIOCxA and the GTIOCxB pins when the output is disabled,
+ are controlled by the GPT module.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a07g044-poeg # RZ/G2{L,LC}
+ - renesas,r9a07g054-poeg # RZ/V2L
+ - const: renesas,rzg2l-poeg
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ renesas,gpt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to gpt instance that serves the pwm operation.
+
+ renesas,poeg-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ POEG group index. Valid values are:
+ <0> : POEG group A
+ <1> : POEG group B
+ <2> : POEG group C
+ <3> : POEG group D
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - power-domains
+ - resets
+ - renesas,poeg-id
+ - renesas,gpt
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ poeggd: poeg@10049400 {
+ compatible = "renesas,r9a07g044-poeg", "renesas,rzg2l-poeg";
+ reg = <0x10049400 0x400>;
+ interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A07G044_POEG_D_CLKP>;
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_POEG_D_RST>;
+ renesas,poeg-id = <3>;
+ renesas,gpt = <&gpt>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
index d653972..45b7679 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
@@ -76,15 +76,13 @@
required:
- compatible
- rockchip,grf
- - "#address-cells"
- - "#size-cells"
- - ranges
patternProperties:
"gpio@[0-9a-f]+$":
type: object
$ref: "/schemas/gpio/rockchip,gpio-bank.yaml#"
+ deprecated: true
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
index 14a8c02..bc34e2c 100644
--- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/socionext,uniphier-pinctrl.yaml#
@@ -69,11 +70,17 @@
- |
// The UniPhier pinctrl should be a subnode of a "syscon" compatible node.
- soc-glue@5f800000 {
- compatible = "socionext,uniphier-pro4-soc-glue", "simple-mfd", "syscon";
- reg = <0x5f800000 0x2000>;
+ pinctrl {
+ compatible = "socionext,uniphier-ld20-pinctrl";
- pinctrl: pinctrl {
- compatible = "socionext,uniphier-pro4-pinctrl";
+ pinctrl_ether_rgmii: ether-rgmii {
+ groups = "ether_rgmii";
+ function = "ether_rgmii";
+
+ tx {
+ pins = "RGMII_TXCLK", "RGMII_TXD0", "RGMII_TXD1",
+ "RGMII_TXD2", "RGMII_TXD3", "RGMII_TXCTL";
+ drive-strength = <9>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml
new file mode 100644
index 0000000..b470901
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh7110-aon-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 AON Pin Controller
+
+description: |
+ Bindings for the JH7110 RISC-V SoC from StarFive Technology Ltd.
+
+ Out of the SoC's many pins only the ones named PAD_RGPIO0 to PAD_RGPIO3
+ can be multiplexed and have configurable bias, drive strength,
+ schmitt trigger etc.
+ Some peripherals such as PWM have their I/O go through the 4 "GPIOs".
+
+maintainers:
+ - Jianlong Huang <jianlong.huang@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-aon-pinctrl
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+patternProperties:
+ '-[0-9]+$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '-pins$':
+ type: object
+ description: |
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to
+ muxer configuration, bias, input enable/disable, input schmitt
+ trigger enable/disable, slew-rate and drive strength.
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the GPIOMUX macro.
+
+ bias-disable: true
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ drive-strength:
+ enum: [ 2, 4, 8, 12 ]
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ slew-rate:
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@17020000 {
+ compatible = "starfive,jh7110-aon-pinctrl";
+ reg = <0x17020000 0x10000>;
+ resets = <&aoncrg 2>;
+ interrupts = <85>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ pwm-0 {
+ pwm-pins {
+ pinmux = <0xff030802>;
+ bias-disable;
+ drive-strength = <12>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml
new file mode 100644
index 0000000..222b9e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh7110-sys-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 SYS Pin Controller
+
+description: |
+ Bindings for the JH7110 RISC-V SoC from StarFive Technology Ltd.
+
+ Out of the SoC's many pins only the ones named PAD_GPIO0 to PAD_GPIO63
+ can be multiplexed and have configurable bias, drive strength,
+ schmitt trigger etc.
+ Some peripherals have their I/O go through the 64 "GPIOs". This also
+ includes a number of other UARTs, I2Cs, SPIs, PWMs etc.
+ All these peripherals are connected to all 64 GPIOs such that
+ any GPIO can be set up to be controlled by any of the peripherals.
+
+maintainers:
+ - Jianlong Huang <jianlong.huang@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-sys-pinctrl
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+patternProperties:
+ '-[0-9]+$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '-pins$':
+ type: object
+ description: |
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to
+ muxer configuration, bias, input enable/disable, input schmitt
+ trigger enable/disable, slew-rate and drive strength.
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the GPIOMUX or PINMUX
+ macros.
+
+ bias-disable: true
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ drive-strength:
+ enum: [ 2, 4, 8, 12 ]
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ slew-rate:
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@13040000 {
+ compatible = "starfive,jh7110-sys-pinctrl";
+ reg = <0x13040000 0x10000>;
+ clocks = <&syscrg 112>;
+ resets = <&syscrg 2>;
+ interrupts = <86>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ uart0-0 {
+ tx-pins {
+ pinmux = <0xff140005>;
+ bias-disable;
+ drive-strength = <12>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+
+ rx-pins {
+ pinmux = <0x0E000406>;
+ bias-pull-up;
+ drive-strength = <2>;
+ input-enable;
+ input-schmitt-enable;
+ slew-rate = <0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml
new file mode 100644
index 0000000..46e2647
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/allwinner,sun20i-d1-ppu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner SoCs PPU power domain controller
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ D1 and related SoCs contain a power domain controller for the CPUs, GPU, and
+ video-related hardware.
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun20i-d1-ppu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Bus Clock
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sun20i-d1-r-ccu.h>
+ #include <dt-bindings/reset/sun20i-d1-r-ccu.h>
+
+ ppu: power-controller@7001000 {
+ compatible = "allwinner,sun20i-d1-ppu";
+ reg = <0x7001000 0x1000>;
+ clocks = <&r_ccu CLK_BUS_R_PPU>;
+ resets = <&r_ccu RST_BUS_R_PPU>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
index 99b5b10..ba5865a 100644
--- a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
+++ b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
@@ -1,5 +1,5 @@
-Amlogic Meson Power Controller
-==============================
+Amlogic Meson Power Controller (deprecated)
+===========================================
The Amlogic Meson SoCs embeds an internal Power domain controller.
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
index 777e1d8..c21a664 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
@@ -23,11 +23,16 @@
properties:
compatible:
- enum:
- - fsl,imx6q-gpc
- - fsl,imx6qp-gpc
- - fsl,imx6sl-gpc
- - fsl,imx6sx-gpc
+ oneOf:
+ - enum:
+ - fsl,imx6q-gpc
+ - items:
+ - enum:
+ - fsl,imx6qp-gpc
+ - fsl,imx6sl-gpc
+ - fsl,imx6sx-gpc
+ - fsl,imx6ul-gpc
+ - const: fsl,imx6q-gpc
reg:
maxItems: 1
@@ -35,6 +40,10 @@
interrupts:
maxItems: 1
+ interrupt-controller: true
+ '#interrupt-cells':
+ const: 3
+
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
index 605ec7a..c9acef8 100644
--- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -28,6 +28,7 @@
- mediatek,mt8173-power-controller
- mediatek,mt8183-power-controller
- mediatek,mt8186-power-controller
+ - mediatek,mt8188-power-controller
- mediatek,mt8192-power-controller
- mediatek,mt8195-power-controller
@@ -84,6 +85,7 @@
"include/dt-bindings/power/mt8167-power.h" - for MT8167 type power domain.
"include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain.
"include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain.
+ "include/dt-bindings/power/mediatek,mt8188-power.h" - for MT8188 type power domain.
"include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain.
"include/dt-bindings/power/mt8195-power.h" - for MT8195 type power domain.
maxItems: 1
diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index 889091b..d1235e5 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -43,9 +43,6 @@
domain would be considered as capable of being powered-on or powered-off.
operating-points-v2:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- maxItems: 1
description:
Phandles to the OPP tables of power domains provided by a power domain
provider. If the provider provides a single power domain only or all
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 633d498..afad313 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -30,6 +30,7 @@
- qcom,qcs404-rpmpd
- qcom,qdu1000-rpmhpd
- qcom,sa8540p-rpmhpd
+ - qcom,sa8775p-rpmhpd
- qcom,sdm660-rpmpd
- qcom,sc7180-rpmhpd
- qcom,sc7280-rpmhpd
@@ -39,7 +40,6 @@
- qcom,sdm845-rpmhpd
- qcom,sdx55-rpmhpd
- qcom,sdx65-rpmhpd
- - qcom,sm4250-rpmpd
- qcom,sm6115-rpmpd
- qcom,sm6125-rpmpd
- qcom,sm6350-rpmhpd
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
index da25097..7506112 100644
--- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
@@ -42,6 +42,9 @@
$ref: /schemas/types.yaml#/definitions/uint32
description: The reset value written to the reboot register (32 bit access).
+ priority:
+ default: 192
+
required:
- compatible
- offset
@@ -49,6 +52,7 @@
additionalProperties: false
allOf:
+ - $ref: restart-handler.yaml#
- if:
not:
required:
diff --git a/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml
new file mode 100644
index 0000000..98eb8b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/starfive,jh7110-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Power Management Unit
+
+maintainers:
+ - Walker Chen <walker.chen@starfivetech.com>
+
+description: |
+ StarFive JH7110 SoC includes support for multiple power domains which can be
+ powered on/off by software based on different application scenes to save power.
+
+properties:
+ compatible:
+ enum:
+ - starfive,jh7110-pmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#power-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ pwrc: power-controller@17030000 {
+ compatible = "starfive,jh7110-pmu";
+ reg = <0x17030000 0x10000>;
+ interrupts = <111>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml
index 0450f4d..1d2405b 100644
--- a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml
+++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml
@@ -16,18 +16,30 @@
properties:
compatible:
- const: qcom,pm8941-coincell
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm8998-coincell
+ - const: qcom,pm8941-coincell
+
+ - const: qcom,pm8941-coincell
reg:
maxItems: 1
qcom,rset-ohms:
- description: resistance (in ohms) for current-limiting resistor
+ description: |
+ Resistance (in ohms) for current-limiting resistor. If unspecified,
+ inherit the previous configuration (e.g. from bootloader or hardware
+ default value).
enum: [ 800, 1200, 1700, 2100 ]
qcom,vset-millivolts:
$ref: /schemas/types.yaml#/definitions/uint32
- description: voltage (in millivolts) to apply for charging
+ description: |
+ Voltage (in millivolts) to apply for charging. If unspecified, inherit
+ the previous configuration (e.g. from bootloader or hardware default
+ value).
enum: [ 2500, 3000, 3100, 3200 ]
qcom,charger-disable:
@@ -37,8 +49,6 @@
required:
- compatible
- reg
- - qcom,rset-ohms
- - qcom,vset-millivolts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml
new file mode 100644
index 0000000..3723717
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt9467.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9467 Switching Battery Charger with Power Path Management
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+ - ChiaEn Wu <chiaen_wu@richtek.com>
+
+description: |
+ RT9467 is a switch-mode single cell Li-Ion/Li-Polymer battery charger for
+ portable applications. It integrates a synchronous PWM controller, power
+ MOSFETs, input current sensing and regulation, high-accuracy voltage
+ regulation, and charge termination. The charge current is regulated through
+ integrated sensing resistors.
+
+ The RT9467 also features USB On-The-Go (OTG) support. It also integrates
+ D+/D- pin for USB host/charging port detection.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT9467/DS9467-01.pdf
+
+properties:
+ compatible:
+ const: richtek,rt9467
+
+ reg:
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ charge-enable-gpios:
+ description: GPIO is used to turn on and off charging.
+ maxItems: 1
+
+ usb-otg-vbus-regulator:
+ type: object
+ description: OTG boost regulator.
+ unevaluatedProperties: false
+ $ref: /schemas/regulator/regulator.yaml#
+
+ properties:
+ enable-gpios: true
+
+required:
+ - compatible
+ - reg
+ - wakeup-source
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@5b {
+ compatible = "richtek,rt9467";
+ reg = <0x5b>;
+ wakeup-source;
+ interrupts-extended = <&gpio_intc 32 IRQ_TYPE_LEVEL_LOW>;
+ charge-enable-gpios = <&gpio26 1 GPIO_ACTIVE_LOW>;
+
+ rt9467_otg_vbus: usb-otg-vbus-regulator {
+ regulator-name = "rt9467-usb-otg-vbus";
+ regulator-min-microvolt = <4425000>;
+ regulator-max-microvolt = <5825000>;
+ regulator-min-microamp = <500000>;
+ regulator-max-microamp = <3000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml
new file mode 100644
index 0000000..fbb54cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt9471.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9471 3A Single Cell Switching Battery charger
+
+maintainers:
+ - Alina Yu <alina_yu@richtek.com>
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ RT9471 is a switch-mode single cell Li-Ion/Li-Polymer battery charger for
+ portable applications. It supports USB BC1.2 port detection, current and
+ voltage regulations in both charging and boost mode.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT9471=RT9471D/DS9471D-02.pdf
+
+properties:
+ compatible:
+ const: richtek,rt9471
+
+ reg:
+ maxItems: 1
+
+ charge-enable-gpios:
+ description: GPIO used to turn on and off charging.
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ usb-otg-vbus-regulator:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - wakeup-source
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@53 {
+ compatible = "richtek,rt9471";
+ reg = <0x53>;
+ charge-enable-gpios = <&gpio26 1 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ interrupts-extended = <&gpio_intc 32 IRQ_TYPE_EDGE_FALLING>;
+
+ usb-otg-vbus-regulator {
+ regulator-name = "usb-otg-vbus";
+ regulator-min-microvolt = <4850000>;
+ regulator-max-microvolt = <5300000>;
+ regulator-min-microamp = <500000>;
+ regulator-max-microamp = <1200000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index c4d78f2..3ff6ebb 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -97,16 +97,6 @@
- reg : should contain the EXI registers location and length
- interrupts : should contain the EXI interrupt
-1.g) The Open Host Controller Interface (OHCI) nodes
-
- Represent the USB 1.x Open Host Controller Interfaces.
-
- Required properties:
-
- - compatible : should be "nintendo,hollywood-usb-ohci","usb-ohci"
- - reg : should contain the OHCI registers location and length
- - interrupts : should contain the OHCI interrupt
-
1.h) The Enhanced Host Controller Interface (EHCI) node
Represents the USB 2.0 Enhanced Host Controller Interface.
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
new file mode 100644
index 0000000..dbc974b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/mediatek,mt2712-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek PWM Controller
+
+maintainers:
+ - John Crispin <john@phrozen.org>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2712-pwm
+ - mediatek,mt6795-pwm
+ - mediatek,mt7622-pwm
+ - mediatek,mt7623-pwm
+ - mediatek,mt7628-pwm
+ - mediatek,mt7629-pwm
+ - mediatek,mt8183-pwm
+ - mediatek,mt8365-pwm
+ - mediatek,mt8516-pwm
+ - items:
+ - enum:
+ - mediatek,mt8195-pwm
+ - const: mediatek,mt8183-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 10
+
+ clock-names:
+ description:
+ This controller needs two input clocks for its core and one
+ clock for each PWM output.
+ minItems: 2
+ items:
+ - const: top
+ - const: main
+ - const: pwm1
+ - const: pwm2
+ - const: pwm3
+ - const: pwm4
+ - const: pwm5
+ - const: pwm6
+ - const: pwm7
+ - const: pwm8
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt2712-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pwm0: pwm@11006000 {
+ compatible = "mediatek,mt2712-pwm";
+ reg = <0x11006000 0x1000>;
+ #pwm-cells = <2>;
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_PWM_SEL>, <&pericfg CLK_PERI_PWM>,
+ <&pericfg CLK_PERI_PWM0>, <&pericfg CLK_PERI_PWM1>,
+ <&pericfg CLK_PERI_PWM2>, <&pericfg CLK_PERI_PWM3>,
+ <&pericfg CLK_PERI_PWM4>, <&pericfg CLK_PERI_PWM5>,
+ <&pericfg CLK_PERI_PWM6>, <&pericfg CLK_PERI_PWM7>;
+ clock-names = "top", "main",
+ "pwm1", "pwm2",
+ "pwm3", "pwm4",
+ "pwm5", "pwm6",
+ "pwm7", "pwm8";
+ };
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
index 739d315..41cea49 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
@@ -63,8 +63,7 @@
pinctrl-1:
description: configuration for the sleep state
- operating-points-v2:
- $ref: /schemas/types.yaml#/definitions/phandle
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
deleted file mode 100644
index 554c96b..0000000
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-MediaTek PWM controller
-
-Required properties:
- - compatible: should be "mediatek,<name>-pwm":
- - "mediatek,mt2712-pwm": found on mt2712 SoC.
- - "mediatek,mt6795-pwm": found on mt6795 SoC.
- - "mediatek,mt7622-pwm": found on mt7622 SoC.
- - "mediatek,mt7623-pwm": found on mt7623 SoC.
- - "mediatek,mt7628-pwm": found on mt7628 SoC.
- - "mediatek,mt7629-pwm": found on mt7629 SoC.
- - "mediatek,mt8183-pwm": found on mt8183 SoC.
- - "mediatek,mt8195-pwm", "mediatek,mt8183-pwm": found on mt8195 SoC.
- - "mediatek,mt8365-pwm": found on mt8365 SoC.
- - "mediatek,mt8516-pwm": found on mt8516 SoC.
- - reg: physical base address and length of the controller's registers.
- - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of
- the cell format.
- - clocks: phandle and clock specifier of the PWM reference clock.
- - clock-names: must contain the following, except for MT7628 which
- has no clocks
- - "top": the top clock generator
- - "main": clock used by the PWM core
- - "pwm1-3": the three per PWM clocks for mt8365
- - "pwm1-8": the eight per PWM clocks for mt2712
- - "pwm1-6": the six per PWM clocks for mt7622
- - "pwm1-5": the five per PWM clocks for mt7623
- - "pwm1" : the PWM1 clock for mt7629
- - pinctrl-names: Must contain a "default" entry.
- - pinctrl-0: One property must exist for each entry in pinctrl-names.
- See pinctrl/pinctrl-bindings.txt for details of the property values.
-
-Optional properties:
-- assigned-clocks: Reference to the PWM clock entries.
-- assigned-clock-parents: The phandle of the parent clock of PWM clock.
-
-Example:
- pwm0: pwm@11006000 {
- compatible = "mediatek,mt7623-pwm";
- reg = <0 0x11006000 0 0x1000>;
- #pwm-cells = <2>;
- clocks = <&topckgen CLK_TOP_PWM_SEL>,
- <&pericfg CLK_PERI_PWM>,
- <&pericfg CLK_PERI_PWM1>,
- <&pericfg CLK_PERI_PWM2>,
- <&pericfg CLK_PERI_PWM3>,
- <&pericfg CLK_PERI_PWM4>,
- <&pericfg CLK_PERI_PWM5>;
- clock-names = "top", "main", "pwm1", "pwm2",
- "pwm3", "pwm4", "pwm5";
- pinctrl-names = "default";
- pinctrl-0 = <&pwm0_pins>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
index 605c1766..bae9931 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
@@ -8,7 +8,6 @@
title: SiFive PWM controller
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
description:
diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
new file mode 100644
index 0000000..9aabdb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/snps,dw-apb-timers-pwm2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DW-APB timers PWM controller
+
+maintainers:
+ - Ben Dooks <ben.dooks@sifive.com>
+
+description:
+ This describes the DesignWare APB timers module when used in the PWM
+ mode. The IP core can be generated with various options which can
+ control the functionality, the number of PWMs available and other
+ internal controls the designer requires.
+
+ The IP block has a version register so this can be used for detection
+ instead of having to encode the IP version number in the device tree
+ comaptible.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: snps,dw-apb-timers-pwm2
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ items:
+ - description: Interface bus clock
+ - description: PWM reference clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: timer
+
+ snps,pwm-number:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The number of PWM channels configured for this instance
+ enum: [1, 2, 3, 4, 5, 6, 7, 8]
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm: pwm@180000 {
+ compatible = "snps,dw-apb-timers-pwm2";
+ reg = <0x180000 0x200>;
+ #pwm-cells = <3>;
+ clocks = <&bus>, <&timer>;
+ clock-names = "bus", "timer";
+ };
diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
deleted file mode 100644
index b9f58e4..0000000
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-ACT88xx regulators
--------------------
-
-Required properties:
-- compatible: "active-semi,act8846" or "active-semi,act8865" or "active-semi,act8600"
-- reg: I2C slave address
-
-Optional properties:
-- system-power-controller: Telling whether or not this pmic is controlling
- the system power. See Documentation/devicetree/bindings/power/power-controller.txt .
-- active-semi,vsel-high: Indicates the VSEL pin is high.
- If this property is missing, assume the VSEL pin is low(0).
-
-Optional input supply properties:
-- for act8600:
- - vp1-supply: The input supply for DCDC_REG1
- - vp2-supply: The input supply for DCDC_REG2
- - vp3-supply: The input supply for DCDC_REG3
- - inl-supply: The input supply for LDO_REG5, LDO_REG6, LDO_REG7 and LDO_REG8
- SUDCDC_REG4, LDO_REG9 and LDO_REG10 do not have separate supplies.
-- for act8846:
- - vp1-supply: The input supply for REG1
- - vp2-supply: The input supply for REG2
- - vp3-supply: The input supply for REG3
- - vp4-supply: The input supply for REG4
- - inl1-supply: The input supply for REG5, REG6 and REG7
- - inl2-supply: The input supply for REG8 and LDO_REG9
- - inl3-supply: The input supply for REG10, REG11 and REG12
-- for act8865:
- - vp1-supply: The input supply for DCDC_REG1
- - vp2-supply: The input supply for DCDC_REG2
- - vp3-supply: The input supply for DCDC_REG3
- - inl45-supply: The input supply for LDO_REG1 and LDO_REG2
- - inl67-supply: The input supply for LDO_REG3 and LDO_REG4
-
-Any standard regulator properties can be used to configure the single regulator.
-regulator-initial-mode, regulator-allowed-modes and regulator-mode could be specified
-for act8865 using mode values from dt-bindings/regulator/active-semi,8865-regulator.h
-file.
-
-The valid names for regulators are:
- - for act8846:
- REG1, REG2, REG3, REG4, REG5, REG6, REG7, REG8, REG9, REG10, REG11, REG12
- - for act8865:
- DCDC_REG1, DCDC_REG2, DCDC_REG3, LDO_REG1, LDO_REG2, LDO_REG3, LDO_REG4.
- - for act8600:
- DCDC_REG1, DCDC_REG2, DCDC_REG3, SUDCDC_REG4, LDO_REG5, LDO_REG6, LDO_REG7,
- LDO_REG8, LDO_REG9, LDO_REG10,
-
-Example:
---------
-
-#include <dt-bindings/regulator/active-semi,8865-regulator.h>
-
- i2c1: i2c@f0018000 {
- pmic: act8865@5b {
- compatible = "active-semi,act8865";
- reg = <0x5b>;
- active-semi,vsel-high;
-
- regulators {
- vcc_1v8_reg: DCDC_REG1 {
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- vcc_1v2_reg: DCDC_REG2 {
- regulator-name = "VCC_1V2";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8865_REGULATOR_MODE_FIXED>,
- <ACT8865_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8865_REGULATOR_MODE_FIXED>;
-
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-min-microvolt = <1150000>;
- regulator-suspend-max-microvolt = <1150000>;
- regulator-changeable-in-suspend;
- regulator-mode = <ACT8865_REGULATOR_MODE_LOWPOWER>;
- };
- };
-
- vcc_3v3_reg: DCDC_REG3 {
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vddana_reg: LDO_REG1 {
- regulator-name = "VDDANA";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8865_REGULATOR_MODE_NORMAL>,
- <ACT8865_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8865_REGULATOR_MODE_NORMAL>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vddfuse_reg: LDO_REG2 {
- regulator-name = "FUSE_2V5";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt b/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
deleted file mode 100644
index 4017527..0000000
--- a/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
+++ /dev/null
@@ -1,113 +0,0 @@
-Device-Tree bindings for regulators of Active-semi ACT8945A Multi-Function Device
-
-Required properties:
- - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt.
-
-Optional properties:
-- active-semi,vsel-high: Indicates if the VSEL pin is set to logic-high.
- If this property is missing, assume the VSEL pin is set to logic-low.
-
-Optional input supply properties:
- - vp1-supply: The input supply for REG_DCDC1
- - vp2-supply: The input supply for REG_DCDC2
- - vp3-supply: The input supply for REG_DCDC3
- - inl45-supply: The input supply for REG_LDO1 and REG_LDO2
- - inl67-supply: The input supply for REG_LDO3 and REG_LDO4
-
-Any standard regulator properties can be used to configure the single regulator.
-regulator-initial-mode, regulator-allowed-modes and regulator-mode could be
-specified using mode values from dt-bindings/regulator/active-semi,8945a-regulator.h
-file.
-
-The valid names for regulators are:
- REG_DCDC1, REG_DCDC2, REG_DCDC3, REG_LDO1, REG_LDO2, REG_LDO3, REG_LDO4.
-
-Example:
-
-#include <dt-bindings/regulator/active-semi,8945a-regulator.h>
-
- pmic@5b {
- compatible = "active-semi,act8945a";
- reg = <0x5b>;
-
- active-semi,vsel-high;
-
- regulators {
- vdd_1v35_reg: REG_DCDC1 {
- regulator-name = "VDD_1V35";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
- <ACT8945A_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
-
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-min-microvolt=<1400000>;
- regulator-suspend-max-microvolt=<1400000>;
- regulator-changeable-in-suspend;
- regulator-mode=<ACT8945A_REGULATOR_MODE_LOWPOWER>;
- };
- };
-
- vdd_1v2_reg: REG_DCDC2 {
- regulator-name = "VDD_1V2";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
- <ACT8945A_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_3v3_reg: REG_DCDC3 {
- regulator-name = "VDD_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_fuse_reg: REG_LDO1 {
- regulator-name = "VDD_FUSE";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
- <ACT8945A_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_3v3_lp_reg: REG_LDO2 {
- regulator-name = "VDD_3V3_LP";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_led_reg: REG_LDO3 {
- regulator-name = "VDD_LED";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_sdhc_1v8_reg: REG_LDO4 {
- regulator-name = "VDD_SDHC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
new file mode 100644
index 0000000..b8ca967
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8600.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8600 regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8600
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8600 is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ DCDC1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ DCDC2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ DCDC3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ patternProperties:
+ "^(SUDCDC_REG4|LDO_REG9|LDO_REG10)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^LDO[5-8]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl-supply:
+ description: Handle to the INL input supply
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5a {
+ compatible = "active-semi,act8600";
+ reg = <0x5a>;
+
+ regulators {
+ SUDCDC_REG4 {
+ regulator-min-microvolt = <5300000>;
+ regulator-max-microvolt = <5300000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO5 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO6 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO7 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO8 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ inl-supply = <&vcc>;
+ };
+
+ LDO_REG9 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ inl-supply = <&vcc>;
+ };
+
+ LDO_REG10 {
+ inl-supply = <&vcc>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
new file mode 100644
index 0000000..3725348
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
@@ -0,0 +1,205 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8846.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8846 regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8846
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8846 is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ REG1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ REG2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ REG3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ REG4:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp4-supply:
+ description: Handle to the VP4 input supply
+
+ patternProperties:
+ "^REG[5-7]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl1-supply:
+ description: Handle to the INL1 input supply
+
+ "^REG[8-9]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl2-supply:
+ description: Handle to the INL2 input supply
+
+ "^REG1[0-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl3-supply:
+ description: Handle to the INL3 input supply
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5a {
+ compatible = "active-semi,act8846";
+ reg = <0x5a>;
+
+ system-power-controller;
+
+ regulators {
+ REG1 {
+ regulator-name = "VCC_DDR";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ REG2 {
+ regulator-name = "VCC_IO";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG3 {
+ regulator-name = "VDD_LOG";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ REG4 {
+ regulator-name = "VCC_20";
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-always-on;
+ };
+
+ REG5 {
+ regulator-name = "VCCIO_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG6 {
+ regulator-name = "VDD10_LCD";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ REG7 {
+ regulator-name = "VCC_WL";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG8 {
+ regulator-name = "VCCA_33";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG9 {
+ regulator-name = "VCC_LAN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG10 {
+ regulator-name = "VDD_10";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ REG11 {
+ regulator-name = "VCC_18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ REG12 {
+ regulator-name = "VCC18_LCD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
new file mode 100644
index 0000000..e8bf09f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8865.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8865 regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8865
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8865 is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ DCDC_REG1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ DCDC_REG2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ DCDC_REG3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ patternProperties:
+ "^LDO_REG[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl45-supply:
+ description: Handle to the INL45 input supply
+
+ "^LDO_REG[3-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl67-supply:
+ description: Handle to the INL67 input supply
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ #include <dt-bindings/regulator/active-semi,8865-regulator.h>
+
+ i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ active-semi,vsel-high;
+
+ regulators {
+ DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+
+ regulator-allowed-modes = <ACT8865_REGULATOR_MODE_FIXED>,
+ <ACT8865_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8865_REGULATOR_MODE_FIXED>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-min-microvolt = <1150000>;
+ regulator-suspend-max-microvolt = <1150000>;
+ regulator-changeable-in-suspend;
+ regulator-mode = <ACT8865_REGULATOR_MODE_LOWPOWER>;
+ };
+ };
+
+ DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+
+ regulator-allowed-modes = <ACT8865_REGULATOR_MODE_NORMAL>,
+ <ACT8865_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8865_REGULATOR_MODE_NORMAL>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
new file mode 100644
index 0000000..bdf3f7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
@@ -0,0 +1,258 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8945a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8945a regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8945a
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8945a is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ REG_DCDC1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ REG_DCDC2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ REG_DCDC3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ patternProperties:
+ "^REG_LDO[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl45-supply:
+ description: Handle to the INL45 input supply
+
+ "^REG_LDO[3-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl67-supply:
+ description: Handle to the INL67 input supply
+
+ charger:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: active-semi,act8945a-charger
+
+ interrupts:
+ maxItems: 1
+
+ active-semi,chglev-gpios:
+ description: CGHLEV GPIO
+ maxItems: 1
+
+ active-semi,lbo-gpios:
+ description: LBO GPIO
+ maxItems: 1
+
+ active-semi,input-voltage-threshold-microvolt:
+ description: Input voltage threshold
+ maxItems: 1
+
+ active-semi,precondition-timeout:
+ description: Precondition timeout
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ active-semi,total-timeout:
+ description: Total timeout
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/atmel-flexcom.h>
+ #include <dt-bindings/regulator/active-semi,8945a-regulator.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5b {
+ compatible = "active-semi,act8945a";
+ reg = <0x5b>;
+ active-semi,vsel-high;
+
+ regulators {
+ REG_DCDC1 {
+ regulator-name = "VDD_1V35";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-min-microvolt = <1400000>;
+ regulator-suspend-max-microvolt = <1400000>;
+ regulator-changeable-in-suspend;
+ regulator-mode = <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ };
+ };
+
+ REG_DCDC2 {
+ regulator-name = "VDD_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_DCDC3 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO1 {
+ regulator-name = "VDD_FUSE";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO2 {
+ regulator-name = "VDD_3V3_LP";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO3 {
+ regulator-name = "VDD_LED";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO4 {
+ regulator-name = "VDD_SDHC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+
+ charger {
+ compatible = "active-semi,act8945a-charger";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>;
+ interrupt-parent = <&pioA>;
+ interrupts = <45 IRQ_TYPE_EDGE_RISING>;
+
+ active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>;
+ active-semi,lbo-gpios = <&pioA 72 GPIO_ACTIVE_LOW>;
+ active-semi,input-voltage-threshold-microvolt = <6600>;
+ active-semi,precondition-timeout = <40>;
+ active-semi,total-timeout = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/fan53555.txt b/Documentation/devicetree/bindings/regulator/fan53555.txt
deleted file mode 100644
index 013f096..0000000
--- a/Documentation/devicetree/bindings/regulator/fan53555.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Binding for Fairchild FAN53555 regulators
-
-Required properties:
- - compatible: one of "fcs,fan53555", "fcs,fan53526", "silergy,syr827",
- "silergy,syr828" or "tcs,tcs4525".
- - reg: I2C address
-
-Optional properties:
- - fcs,suspend-voltage-selector: declare which of the two available
- voltage selector registers should be used for the suspend
- voltage. The other one is used for the runtime voltage setting
- Possible values are either <0> or <1>
- - vin-supply: regulator supplying the vin pin
-
-Example:
-
- regulator@40 {
- compatible = "fcs,fan53555";
- regulator-name = "fan53555";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&parent_reg>;
- fcs,suspend-voltage-selector = <1>;
- };
diff --git a/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml
new file mode 100644
index 0000000..c0dbba8
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/fcs,fan53555.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fairchild FAN53555 regulators
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - fcs,fan53555
+ - fcs,fan53526
+ - silergy,syr827
+ - silergy,syr828
+ - tcs,tcs4525
+
+ reg:
+ maxItems: 1
+
+ fcs,suspend-voltage-selector:
+ description: Declares which of the two available voltage selector
+ registers should be used for the suspend voltage. The other one is used
+ for the runtime voltage setting.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+
+ vin-supply:
+ description: Supply for the vin pin
+
+ vsel-gpios:
+ description: Voltage Select. When this pin is LOW, VOUT is set by the
+ VSEL0 register. When this pin is HIGH, VOUT is set by the VSEL1 register.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@40 {
+ compatible = "fcs,fan53555";
+ reg = <0x40>;
+ regulator-name = "fan53555";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&parent_reg>;
+ fcs,suspend-voltage-selector = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
index 84eeaef..48af7cb 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
@@ -35,6 +35,10 @@
required:
- power-domains
- required-opps
+ - not:
+ required:
+ - gpio
+ - gpios
properties:
compatible:
@@ -49,6 +53,9 @@
description: gpio to use for enable control
maxItems: 1
+ gpios:
+ maxItems: 1
+
clocks:
description:
clock to use for enable control. This binding is only available if
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max20411.yaml b/Documentation/devicetree/bindings/regulator/maxim,max20411.yaml
new file mode 100644
index 0000000..5b3a42d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/maxim,max20411.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/maxim,max20411.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX20411 Step-Down DC-DC Converter
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ The MAX20411 is a high-efficiency, DC-DC step-down converter. It provides
+ configurable output voltage in the range of 0.5V to 1.275V, configurable over
+ I2C.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ const: maxim,max20411
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO connected to the EN pin, active high
+
+ vdd-supply:
+ description: Input supply for the device (VDD pin, 3.0V to 5.5V)
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@39 {
+ compatible = "maxim,max20411";
+ reg = <0x39>;
+
+ enable-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1000000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml
new file mode 100644
index 0000000..2185cd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mps,mpq7932.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Monolithic Power System MPQ7932 PMIC
+
+maintainers:
+ - Saravanan Sekar <saravanan@linumiz.com>
+
+properties:
+ compatible:
+ enum:
+ - mps,mpq7932
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: |
+ list of regulators provided by this controller, must be named
+ after their hardware counterparts BUCK[1-6]
+
+ patternProperties:
+ "^buck[1-6]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3 {
+ compatible = "mps,mpq7932";
+ reg = <0x3>;
+
+ regulators {
+ buck1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+
+ buck2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
new file mode 100644
index 0000000..8a08698
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,rpm-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPM regulator
+
+description:
+ The Qualcomm RPM regulator is modelled as a subdevice of the RPM.
+
+ Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml
+ for information regarding the RPM node.
+
+ The regulator node houses sub-nodes for each regulator within the device.
+ Each sub-node is identified using the node's name, with valid values listed
+ for each of the pmics below.
+
+ For pm8058 l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15,
+ l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4,
+ lvs0, lvs1, ncp
+
+ For pm8901 l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3,
+ mvs
+
+ For pm8921 s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
+ l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28,
+ l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch,
+ ncp
+
+ For pm8018 s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
+ l12, l14, lvs1
+
+ For smb208 s1a, s1b, s2a, s2b
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,rpm-pm8058-regulators
+ - qcom,rpm-pm8901-regulators
+ - qcom,rpm-pm8921-regulators
+ - qcom,rpm-pm8018-regulators
+ - qcom,rpm-smb208-regulators
+
+patternProperties:
+ ".*-supply$":
+ description: Input supply phandle(s) for this node
+
+ "^((s|l|lvs)[0-9]*)|(s[1-2][a-b])|(ncp)|(mvs)|(usb-switch)|(hdmi-switch)$":
+ description: List of regulators and its properties
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ bias-pull-down:
+ description: enable pull down of the regulator when inactive
+ type: boolean
+
+ qcom,switch-mode-frequency:
+ description: Frequency (Hz) of the switch-mode power supply
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 19200000
+ - 9600000
+ - 6400000
+ - 4800000
+ - 3840000
+ - 3200000
+ - 2740000
+ - 2400000
+ - 2130000
+ - 1920000
+ - 1750000
+ - 1600000
+ - 1480000
+ - 1370000
+ - 1280000
+ - 1200000
+
+ qcom,force-mode:
+ description: Indicates that the regulator should be forced to a particular mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # QCOM_RPM_FORCE_MODE_NONE do not force any mode
+ - 1 # QCOM_RPM_FORCE_MODE_LPM force into low power mode
+ - 2 # QCOM_RPM_FORCE_MODE_HPM force into high power mode
+ - 3 # QCOM_RPM_FORCE_MODE_AUTO allow regulator to automatically select its own mode
+ # based on realtime current draw, only for pm8921 smps and ftsmps
+
+ qcom,power-mode-hysteretic:
+ description: select that the power supply should operate in hysteretic mode,
+ instead of the default pwm mode
+ type: boolean
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |
+ #include <dt-bindings/mfd/qcom-rpm.h>
+ regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+ vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+
+ s1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+
+ bias-pull-down;
+
+ qcom,switch-mode-frequency = <3200000>;
+ };
+
+ pm8921_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+
+ qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
index dbe78cd..b1cff3a 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -33,7 +33,7 @@
pm8150b {
#address-cells = <1>;
#size-cells = <0>;
- pm8150b_vbus: dcdc@1100 {
+ pm8150b_vbus: usb-vbus-regulator@1100 {
compatible = "qcom,pm8150b-vbus-reg";
reg = <0x1100>;
};
diff --git a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
index f97b808..e987c39 100644
--- a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -20,7 +20,8 @@
lab:
type: object
- additionalProperties: false
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
properties:
qcom,soft-start-us:
@@ -46,7 +47,8 @@
ibb:
type: object
- additionalProperties: false
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
properties:
qcom,discharge-resistor-kohms:
diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml
index c0acf94..a6949a5 100644
--- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml
@@ -89,18 +89,11 @@
examples:
- |
- usb-glue@65b00000 {
- compatible = "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_vbus0: regulators@100 {
- compatible = "socionext,uniphier-ld20-usb3-regulator";
- reg = <0x100 0x10>;
- clock-names = "link";
- clocks = <&sys_clk 14>;
- reset-names = "link";
- resets = <&sys_rst 14>;
- };
+ usb_vbus0: regulators@100 {
+ compatible = "socionext,uniphier-ld20-usb3-regulator";
+ reg = <0x100 0x10>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
};
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
index c1d9cbc..643ee78 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
@@ -17,201 +17,52 @@
compatible:
enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- qcom,msm8998-slpi-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-cdsp-pas
- - qcom,qcs404-wcss-pas
- - qcom,sc7180-mpss-pas
- - qcom,sc7280-mpss-pas
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8180x-mpss-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
- qcom,sdm660-adsp-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
- - qcom,sdx55-mpss-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm6350-cdsp-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-cdsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-cdsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-cdsp-pas
- - qcom,sm8450-mpss-pas
- - qcom,sm8450-slpi-pas
reg:
maxItems: 1
- clocks:
- minItems: 1
- maxItems: 8
-
- clock-names:
- minItems: 1
- maxItems: 8
-
- interconnects:
- maxItems: 1
-
- interrupts:
- minItems: 5
- items:
- - description: Watchdog interrupt
- - description: Fatal interrupt
- - description: Ready interrupt
- - description: Handover interrupt
- - description: Stop acknowledge interrupt
- - description: Shutdown acknowledge interrupt
-
- interrupt-names:
- minItems: 5
- items:
- - const: wdog
- - const: fatal
- - const: ready
- - const: handover
- - const: stop-ack
- - const: shutdown-ack
-
- resets:
- minItems: 1
- maxItems: 3
-
- reset-names:
- minItems: 1
- maxItems: 3
-
cx-supply:
description: Phandle to the CX regulator
px-supply:
description: Phandle to the PX regulator
- power-domains:
- minItems: 1
- maxItems: 3
-
- power-domain-names:
- minItems: 1
- maxItems: 3
-
- firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
- description: Firmware name for the Hexagon core
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
memory-region:
maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
- qcom,qmp:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: Reference to the AOSS side-channel message RAM.
-
- qcom,smem-states:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: States used by the AP to signal the Hexagon core
- items:
- - description: Stop the modem
-
- qcom,smem-state-names:
- description: The names of the state bits used for SMP2P output
- items:
- - const: stop
-
- qcom,halt-regs:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- - items:
- - description: Phandle reference to a syscon representing TCSR
- - description: offsets within syscon for q6 halt registers
- - description: offsets within syscon for modem halt registers
- - description: offsets within syscon for nc halt registers
- description:
- Phandle reference to a syscon representing TCSR followed by the
- three offsets within syscon for q6, modem and nc halt registers.
-
- smd-edge:
- $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
- description:
- Qualcomm Shared Memory subnode which represents communication edge,
- channels and devices related to the ADSP.
- unevaluatedProperties: false
-
- glink-edge:
- $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
- description:
- Qualcomm G-Link subnode which represents communication edge, channels
- and devices related to the ADSP.
-
required:
- compatible
- - clocks
- - clock-names
- - interrupts
- - interrupt-names
- - memory-region
- - qcom,smem-states
- - qcom,smem-state-names
-additionalProperties: false
+unevaluatedProperties: false
allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- - qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-wcss-pas
- - qcom,sc7280-mpss-pas
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8180x-mpss-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm6350-cdsp-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-cdsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-cdsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-cdsp-pas
- - qcom,sm8450-slpi-pas
- - qcom,sm8450-mpss-pas
then:
properties:
clocks:
@@ -226,6 +77,7 @@
compatible:
contains:
enum:
+ - qcom,msm8996-slpi-pil
- qcom,msm8998-slpi-pas
then:
properties:
@@ -243,90 +95,15 @@
compatible:
contains:
enum:
- - qcom,qcs404-cdsp-pas
- then:
- properties:
- clocks:
- items:
- - description: XO clock
- - description: SWAY clock
- - description: TBU clock
- - description: BIMC clock
- - description: AHB AON clock
- - description: Q6SS SLAVE clock
- - description: Q6SS MASTER clock
- - description: Q6 AXIM clock
- clock-names:
- items:
- - const: xo
- - const: sway
- - const: tbu
- - const: bimc
- - const: ahb_aon
- - const: q6ss_slave
- - const: q6ss_master
- - const: q6_axim
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc7180-mpss-pas
- then:
- properties:
- clocks:
- items:
- - description: XO clock
- - description: IFACE clock
- - description: BUS clock
- - description: NAC clock
- - description: SNOC AXI clock
- - description: MNOC AXI clock
- clock-names:
- items:
- - const: xo
- - const: iface
- - const: bus
- - const: nav
- - const: snoc_axi
- - const: mnoc_axi
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- qcom,msm8998-slpi-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-cdsp-pas
- - qcom,qcs404-wcss-pas
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm6350-cdsp-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-cdsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-cdsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-cdsp-pas
- - qcom,sm8450-slpi-pas
then:
properties:
interrupts:
@@ -339,26 +116,6 @@
compatible:
contains:
enum:
- - qcom,sc7180-mpss-pas
- - qcom,sc7280-mpss-pas
- - qcom,sc8180x-mpss-pas
- - qcom,sdx55-mpss-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-mpss-pas
- then:
- properties:
- interrupts:
- minItems: 6
- interrupt-names:
- minItems: 6
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8974-adsp-pil
then:
required:
@@ -370,10 +127,9 @@
contains:
enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8998-adsp-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
then:
properties:
power-domains:
@@ -406,169 +162,14 @@
compatible:
contains:
enum:
- - qcom,sc7180-mpss-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MX power domain
- - description: MSS power domain
- power-domain-names:
- items:
- - const: cx
- - const: mx
- - const: mss
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm6350-cdsp-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MX power domain
- power-domain-names:
- items:
- - const: cx
- - const: mx
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc7280-mpss-pas
- - qcom,sdx55-mpss-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-mpss-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MSS power domain
- power-domain-names:
- items:
- - const: cx
- - const: mss
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-slpi-pas
- then:
- properties:
- power-domains:
- items:
- - description: LCX power domain
- - description: LMX power domain
- power-domain-names:
- items:
- - const: lcx
- - const: lmx
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm8350-cdsp-pas
- - qcom,sm8450-cdsp-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MXC power domain
- power-domain-names:
- items:
- - const: cx
- - const: mxc
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
- then:
- properties:
- power-domains:
- items:
- - description: NSP power domain
- power-domain-names:
- items:
- - const: nsp
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,qcs404-cdsp-pas
- then:
- properties:
- resets:
- items:
- - description: CDSP restart
- reset-names:
- items:
- - const: restart
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc7180-mpss-pas
- - qcom,sc7280-mpss-pas
- then:
- properties:
- resets:
- items:
- - description: MSS restart
- - description: PDC reset
- reset-names:
- items:
- - const: mss_restart
- - const: pdc_reset
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- qcom,msm8998-slpi-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-cdsp-pas
- - qcom,qcs404-wcss-pas
- qcom,sdm660-adsp-pas
- - qcom,sdx55-mpss-pas
then:
properties:
qcom,qmp: false
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
index 25c2746..15e6851 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
@@ -22,7 +22,7 @@
required:
- qcom,glink-channels
description:
- Qualcomm APR/GPR (Asynchronous/Generic Packet Router)
+ Qualcomm APR (Asynchronous Packet Router)
fastrpc:
$ref: /schemas/misc/qcom,fastrpc.yaml#
@@ -31,11 +31,20 @@
description:
Qualcomm FastRPC
+ gpr:
+ $ref: /schemas/soc/qcom/qcom,apr.yaml#
+ required:
+ - qcom,glink-channels
+ description:
+ Qualcomm GPR (Generic Packet Router)
+
interrupts:
maxItems: 1
label:
- description: The names of the state bits used for SMP2P output
+ description:
+ Name of the edge, used for debugging and identification purposes. The
+ node name will be used if this is not present.
mboxes:
maxItems: 1
@@ -52,6 +61,21 @@
- mboxes
- qcom,remote-pid
+allOf:
+ - if:
+ required:
+ - apr
+ then:
+ properties:
+ gpr: false
+
+ - if:
+ required:
+ - gpr
+ then:
+ properties:
+ apr: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
new file mode 100644
index 0000000..f5a044e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,glink-rpm-edge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm G-Link RPM edge
+
+description: |
+ Qualcomm G-Link edge, a FIFO based mechanism for communication with Resource
+ Power Manager (RPM) on various Qualcomm platforms.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ const: qcom,glink-rpm
+
+ label:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Name of the edge, used for debugging and identification purposes. The
+ node name will be used if this is not present.
+
+ interrupts:
+ maxItems: 1
+
+ mboxes:
+ items:
+ - description: rpm_hlos mailbox in APCS
+
+ qcom,remote-pid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The identifier for the remote processor as known by the rest of the
+ system.
+
+ qcom,rpm-msg-ram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ RPM message memory resource (compatible: qcom,rpm-msg-ram).
+
+ rpm-requests:
+ type: object
+ $ref: /schemas/soc/qcom/qcom,smd-rpm.yaml#
+ unevaluatedProperties: false
+ description:
+ Qualcomm Resource Power Manager (RPM) over G-Link
+
+ properties:
+ qcom,intents:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 32
+ items:
+ items:
+ - description: size of each intent to preallocate
+ - description: amount of intents to preallocate
+ minimum: 1
+ description:
+ List of (size, amount) pairs describing what intents should be
+ preallocated for this virtual channel. This can be used to tweak the
+ default intents available for the channel to meet expectations of the
+ remote.
+
+ required:
+ - qcom,glink-channels
+
+required:
+ - compatible
+ - interrupts
+ - mboxes
+
+anyOf:
+ - required:
+ - qcom,remote-pid
+ - required:
+ - qcom,rpm-msg-ram
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rpm-glink {
+ compatible = "qcom,glink-rpm";
+ interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 0>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-msm8996";
+ qcom,glink-channels = "rpm_requests";
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
new file mode 100644
index 0000000..6e6e69a
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
@@ -0,0 +1,289 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,msm8916-mss-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8916 MSS Peripheral Image Loader (and similar)
+
+maintainers:
+ - Stephan Gerhold <stephan@gerhold.net>
+
+description:
+ This document describes the hardware for a component that loads and boots
+ firmware on the Qualcomm MSM8916 Modem Hexagon Core (and similar).
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,msm8909-mss-pil
+ - qcom,msm8916-mss-pil
+ - qcom,msm8953-mss-pil
+ - qcom,msm8974-mss-pil
+
+ - const: qcom,q6v5-pil
+ description: Deprecated, prefer using qcom,msm8916-mss-pil
+ deprecated: true
+
+ reg:
+ items:
+ - description: MSS QDSP6 registers
+ - description: RMB registers
+
+ reg-names:
+ items:
+ - const: qdsp6
+ - const: rmb
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+
+ clocks:
+ items:
+ - description: Configuration interface (AXI) clock
+ - description: Configuration bus (AHB) clock
+ - description: Boot ROM (AHB) clock
+ - description: XO proxy clock (control handed over after startup)
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: xo
+
+ power-domains:
+ items:
+ - description: CX proxy power domain (control handed over after startup)
+ - description: MX proxy power domain (control handed over after startup)
+ - description: MSS proxy power domain (control handed over after startup)
+ (only valid for qcom,msm8953-mss-pil)
+ minItems: 2
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+ - const: mss # only valid for qcom,msm8953-mss-pil
+ minItems: 2
+
+ pll-supply:
+ description: PLL proxy supply (control handed over after startup)
+
+ mss-supply:
+ description: MSS power domain supply (only valid for qcom,msm8974-mss-pil)
+
+ resets:
+ items:
+ - description: MSS restart control
+
+ reset-names:
+ items:
+ - const: mss_restart
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop modem
+
+ qcom,smem-state-names:
+ description: Names of the states used by the AP to signal the Hexagon core
+ items:
+ - const: stop
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Halt registers are used to halt transactions of various sub-components
+ within MSS.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
+ - description: offset to the modem halt register
+ - description: offset to the nc halt register
+
+ memory-region:
+ items:
+ - description: MBA reserved region
+ - description: MPSS reserved region
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Name of MBA firmware
+ - description: Name of modem firmware
+
+ bam-dmux:
+ $ref: /schemas/net/qcom,bam-dmux.yaml#
+ description:
+ Qualcomm BAM Data Multiplexer (provides network interface to the modem)
+
+ smd-edge:
+ $ref: qcom,smd-edge.yaml#
+ description:
+ Qualcomm SMD subnode which represents communication edge, channels
+ and devices related to the DSP.
+ properties:
+ label:
+ enum:
+ - modem
+ - hexagon
+ unevaluatedProperties: false
+
+ # Deprecated properties
+ cx-supply:
+ description: CX power domain regulator supply (prefer using power-domains)
+ deprecated: true
+
+ mx-supply:
+ description: MX power domain regulator supply (prefer using power-domains)
+ deprecated: true
+
+ mba:
+ type: object
+ description:
+ MBA reserved region (prefer using memory-region with two items)
+ properties:
+ memory-region: true
+ required:
+ - memory-region
+ deprecated: true
+
+ mpss:
+ type: object
+ description:
+ MPSS reserved region (prefer using memory-region with two items)
+ properties:
+ memory-region: true
+ required:
+ - memory-region
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - pll-supply
+ - resets
+ - reset-names
+ - qcom,halt-regs
+ - qcom,smem-states
+ - qcom,smem-state-names
+ - smd-edge
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8953-mss-pil
+ then:
+ properties:
+ power-domains:
+ minItems: 3
+ power-domain-names:
+ minItems: 3
+ required:
+ - power-domains
+ - power-domain-names
+ else:
+ properties:
+ power-domains:
+ maxItems: 2
+ power-domain-names:
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8974-mss-pil
+ then:
+ required:
+ - mss-supply
+ else:
+ properties:
+ mss-supply: false
+
+ # Fallbacks for deprecated properties
+ - oneOf:
+ - required:
+ - memory-region
+ - required:
+ - mba
+ - mpss
+ - oneOf:
+ - required:
+ - power-domains
+ - power-domain-names
+ - required:
+ - cx-supply
+ - mx-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,msm8916-mss-pil";
+ reg = <0x04080000 0x100>, <0x04020000 0x40>;
+ reg-names = "qdsp6", "rmb";
+
+ interrupts-extended = <&intc GIC_SPI 24 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+ qcom,smem-states = <&hexagon_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+ qcom,halt-regs = <&tcsr 0x18000 0x19000 0x1a000>;
+
+ clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+ <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
+ <&gcc GCC_BOOT_ROM_AHB_CLK>,
+ <&xo_board>;
+ clock-names = "iface", "bus", "mem", "xo";
+
+ power-domains = <&rpmpd MSM8916_VDDCX>, <&rpmpd MSM8916_VDDMX>;
+ power-domain-names = "cx", "mx";
+ pll-supply = <&pm8916_l7>;
+
+ resets = <&scm 0>;
+ reset-names = "mss_restart";
+
+ memory-region = <&mba_mem>, <&mpss_mem>;
+
+ smd-edge {
+ interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,smd-edge = <0>;
+ qcom,ipc = <&apcs 8 12>;
+ qcom,remote-pid = <1>;
+
+ label = "hexagon";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
new file mode 100644
index 0000000..c1ac6ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
@@ -0,0 +1,393 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,msm8996-mss-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8996 MSS Peripheral Image Loader (and similar)
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Sibi Sankar <quic_sibis@quicinc.com>
+
+description:
+ MSS Peripheral Image Loader loads and boots firmware on the
+ Qualcomm Technology Inc. MSM8996 Modem Hexagon Core (and similar).
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8996-mss-pil
+ - qcom,msm8998-mss-pil
+ - qcom,sdm845-mss-pil
+
+ reg:
+ items:
+ - description: MSS QDSP6 registers
+ - description: RMB registers
+
+ reg-names:
+ items:
+ - const: qdsp6
+ - const: rmb
+
+ iommus:
+ items:
+ - description: MSA Stream 1
+ - description: MSA Stream 2
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Shutdown acknowledge interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: shutdown-ack
+
+ clocks:
+ minItems: 8
+ maxItems: 9
+
+ clock-names:
+ minItems: 8
+ maxItems: 9
+
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ - description: MSS power domain (only valid for qcom,sdm845-mss-pil)
+ minItems: 2
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+ - const: mss # only valid for qcom,sdm845-mss-pil
+ minItems: 2
+
+ pll-supply:
+ description: PLL supply
+
+ resets:
+ items:
+ - description: AOSS restart
+ - description: PDC reset (only valid for qcom,sdm845-mss-pil)
+ minItems: 1
+
+ reset-names:
+ items:
+ - const: mss_restart
+ - const: pdc_reset # only valid for qcom,sdm845-mss-pil
+ minItems: 1
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop modem
+
+ qcom,smem-state-names:
+ description: Names of the states used by the AP to signal the Hexagon core
+ items:
+ - const: stop
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Halt registers are used to halt transactions of various sub-components
+ within MSS.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
+ - description: offset to the modem halt register
+ - description: offset to the nc halt register
+
+ memory-region:
+ items:
+ - description: MBA reserved region
+ - description: Modem reserved region
+ - description: Metadata reserved region
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Name of MBA firmware
+ - description: Name of modem firmware
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the Modem.
+ unevaluatedProperties: false
+
+ glink-edge:
+ $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
+ description:
+ Qualcomm G-Link subnode which represents communication edge, channels
+ and devices related to the Modem.
+ unevaluatedProperties: false
+
+ # Deprecated properties
+ mba:
+ type: object
+ description:
+ MBA reserved region
+
+ properties:
+ memory-region: true
+
+ required:
+ - memory-region
+
+ additionalProperties: false
+ deprecated: true
+
+ mpss:
+ type: object
+ description:
+ MPSS reserved region
+
+ properties:
+ memory-region: true
+
+ required:
+ - memory-region
+
+ additionalProperties: false
+ deprecated: true
+
+ metadata:
+ type: object
+ description:
+ Metadata reserved region
+
+ properties:
+ memory-region: true
+
+ required:
+ - memory-region
+
+ additionalProperties: false
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - power-domain-names
+ - resets
+ - reset-names
+ - qcom,halt-regs
+ - qcom,smem-states
+ - qcom,smem-state-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8996-mss-pil
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GCC MSS IFACE clock
+ - description: GCC MSS BUS clock
+ - description: GCC MSS MEM clock
+ - description: RPMH XO clock
+ - description: GCC MSS GPLL0 clock
+ - description: GCC MSS SNOC_AXI clock
+ - description: GCC MSS MNOC_AXI clock
+ - description: RPMH PNOC clock
+ - description: GCC MSS PRNG clock
+ - description: RPMH QDSS clock
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: xo
+ - const: gpll0_mss
+ - const: snoc_axi
+ - const: mnoc_axi
+ - const: pnoc
+ - const: qdss
+ glink-edge: false
+ required:
+ - pll-supply
+ - smd-edge
+ else:
+ properties:
+ pll-supply: false
+ smd-edge: false
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8998-mss-pil
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GCC MSS IFACE clock
+ - description: GCC MSS BUS clock
+ - description: GCC MSS MEM clock
+ - description: GCC MSS GPLL0 clock
+ - description: GCC MSS SNOC_AXI clock
+ - description: GCC MSS MNOC_AXI clock
+ - description: RPMH QDSS clock
+ - description: RPMH XO clock
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: gpll0_mss
+ - const: snoc_axi
+ - const: mnoc_axi
+ - const: qdss
+ - const: xo
+ required:
+ - glink-edge
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,sdm845-mss-pil
+ then:
+ properties:
+ power-domains:
+ minItems: 3
+ power-domain-names:
+ minItems: 3
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+ clocks:
+ items:
+ - description: GCC MSS IFACE clock
+ - description: GCC MSS BUS clock
+ - description: GCC MSS MEM clock
+ - description: GCC MSS GPLL0 clock
+ - description: GCC MSS SNOC_AXI clock
+ - description: GCC MSS MNOC_AXI clock
+ - description: GCC MSS PRNG clock
+ - description: RPMH XO clock
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: gpll0_mss
+ - const: snoc_axi
+ - const: mnoc_axi
+ - const: prng
+ - const: xo
+ required:
+ - qcom,qmp
+ - glink-edge
+ else:
+ properties:
+ iommus: false
+ power-domains:
+ maxItems: 2
+ power-domain-names:
+ maxItems: 2
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+ qcom,qmp: false
+
+ # Fallbacks for deprecated properties
+ - oneOf:
+ - required:
+ - memory-region
+ - required:
+ - mba
+ - mpss
+ - metadata
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/reset/qcom,sdm845-aoss.h>
+ #include <dt-bindings/reset/qcom,sdm845-pdc.h>
+
+ remoteproc@4080000 {
+ compatible = "qcom,sdm845-mss-pil";
+ reg = <0x04080000 0x408>, <0x04180000 0x48>;
+ reg-names = "qdsp6", "rmb";
+
+ interrupts-extended = <&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack",
+ "shutdown-ack";
+
+ clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+ <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+ <&gcc GCC_BOOT_ROM_AHB_CLK>,
+ <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+ <&gcc GCC_MSS_SNOC_AXI_CLK>,
+ <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+ <&gcc GCC_PRNG_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "bus", "mem", "gpll0_mss",
+ "snoc_axi", "mnoc_axi", "prng", "xo";
+
+ power-domains = <&rpmhpd SDM845_CX>,
+ <&rpmhpd SDM845_MX>,
+ <&rpmhpd SDM845_MSS>;
+ power-domain-names = "cx", "mx", "mss";
+
+ memory-region = <&mba_mem>, <&mpss_mem>, <&mdata_mem>;
+
+ resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+ <&pdc_reset PDC_MODEM_SYNC_RESET>;
+ reset-names = "mss_restart", "pdc_reset";
+
+ qcom,halt-regs = <&tcsr_regs_1 0x3000 0x5000 0x4000>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&modem_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+ label = "modem";
+ qcom,remote-pid = <1>;
+ mboxes = <&apss_shared 12>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
new file mode 100644
index 0000000..171ef85
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,pas-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Peripheral Authentication Service Common Properties
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Common properties of Qualcomm SoCs Peripheral Authentication Service.
+
+properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ interconnects:
+ maxItems: 1
+
+ interrupts:
+ minItems: 5
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Shutdown acknowledge interrupt
+
+ interrupt-names:
+ minItems: 5
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: shutdown-ack
+
+ power-domains:
+ minItems: 1
+ maxItems: 3
+
+ power-domain-names:
+ minItems: 1
+ maxItems: 3
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop the modem
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output
+ items:
+ - const: stop
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the ADSP.
+ unevaluatedProperties: false
+
+ glink-edge:
+ $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
+ description:
+ Qualcomm G-Link subnode which represents communication edge, channels
+ and devices related to the ADSP.
+ unevaluatedProperties: false
+
+required:
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - memory-region
+ - qcom,smem-states
+ - qcom,smem-state-names
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index d0ebd16..573a88b 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -7,14 +7,8 @@
Usage: required
Value type: <string>
Definition: must be one of:
- "qcom,q6v5-pil",
"qcom,ipq8074-wcss-pil"
"qcom,qcs404-wcss-pil"
- "qcom,msm8916-mss-pil",
- "qcom,msm8974-mss-pil"
- "qcom,msm8996-mss-pil"
- "qcom,msm8998-mss-pil"
- "qcom,sdm845-mss-pil"
- reg:
Usage: required
@@ -35,26 +29,7 @@
- interrupt-names:
Usage: required
Value type: <stringlist>
- Definition: The interrupts needed depends on the compatible
- string:
- qcom,q6v5-pil:
- qcom,ipq8074-wcss-pil:
- qcom,qcs404-wcss-pil:
- qcom,msm8916-mss-pil:
- qcom,msm8974-mss-pil:
- must be "wdog", "fatal", "ready", "handover", "stop-ack"
- qcom,msm8996-mss-pil:
- qcom,msm8998-mss-pil:
- qcom,sdm845-mss-pil:
- must be "wdog", "fatal", "ready", "handover", "stop-ack",
- "shutdown-ack"
-
-- firmware-name:
- Usage: optional
- Value type: <stringlist>
- Definition: must list the relative firmware image paths for mba and
- modem. They are used for booting and authenticating the
- Hexagon core.
+ Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
- clocks:
Usage: required
@@ -72,67 +47,23 @@
"gcc_axim_cbcr", "lcc_ahbfabric_cbc", "tcsr_lcc_cbc",
"lcc_abhs_cbc", "lcc_tcm_slave_cbc", "lcc_abhm_cbc",
"lcc_axim_cbc", "lcc_bcr_sleep"
- qcom,q6v5-pil:
- qcom,msm8916-mss-pil:
- qcom,msm8974-mss-pil:
- must be "iface", "bus", "mem", "xo"
- qcom,msm8996-mss-pil:
- must be "iface", "bus", "mem", "xo", "gpll0_mss",
- "snoc_axi", "mnoc_axi", "pnoc", "qdss"
- qcom,msm8998-mss-pil:
- must be "iface", "bus", "mem", "xo", "gpll0_mss",
- "snoc_axi", "mnoc_axi", "qdss"
- qcom,sdm845-mss-pil:
- must be "iface", "bus", "mem", "xo", "gpll0_mss",
- "snoc_axi", "mnoc_axi", "prng"
- resets:
Usage: required
Value type: <phandle>
- Definition: reference to the reset-controller for the modem sub-system
- reference to the list of 3 reset-controllers for the
+ Definition: reference to the list of 3 reset-controllers for the
wcss sub-system
- reference to the list of 2 reset-controllers for the modem
- sub-system on SDM845 SoCs
- reset-names:
Usage: required
Value type: <stringlist>
- Definition: must be "mss_restart" for the modem sub-system
- must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
+ Definition: must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
for the wcss sub-system
- must be "mss_restart", "pdc_reset" for the modem
- sub-system on SDM845 SoCs
-For devices where the mba and mpss sub-nodes are not specified, mba/mpss region
-should be referenced as follows:
- memory-region:
Usage: required
Value type: <phandle>
- Definition: reference to the reserved-memory for the mba region followed
- by the mpss region
-
-For the compatible strings below the following supplies are required:
- "qcom,q6v5-pil"
- "qcom,msm8916-mss-pil",
-- cx-supply: (deprecated, use power domain instead)
-- mx-supply: (deprecated, use power domain instead)
-- pll-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the Hexagon core
-
-For the compatible string below the following supplies are required:
- "qcom,msm8974-mss-pil"
-- cx-supply: (deprecated, use power domain instead)
-- mss-supply:
-- mx-supply: (deprecated, use power domain instead)
-- pll-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the Hexagon core
+ Definition: reference to wcss reserved-memory region.
For the compatible string below the following supplies are required:
"qcom,qcs404-wcss-pil"
@@ -142,39 +73,6 @@
Definition: reference to the regulators to be held on behalf of the
booting of the Hexagon core
-For the compatible string below the following supplies are required:
- "qcom,msm8996-mss-pil"
-- pll-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the Hexagon core
-
-- power-domains:
- Usage: required
- Value type: <phandle>
- Definition: reference to power-domains that match power-domain-names
-
-- power-domain-names:
- Usage: required
- Value type: <stringlist>
- Definition: The power-domains needed depend on the compatible string:
- qcom,ipq8074-wcss-pil:
- no power-domain names required
- qcom,q6v5-pil:
- qcom,msm8916-mss-pil:
- qcom,msm8974-mss-pil:
- qcom,msm8996-mss-pil:
- qcom,msm8998-mss-pil:
- must be "cx", "mx"
- qcom,sdm845-mss-pil:
- must be "cx", "mx", "mss"
-
-- qcom,qmp:
- Usage: optional
- Value type: <phandle>
- Definition: reference to the AOSS side-channel message RAM.
-
- qcom,smem-states:
Usage: required
Value type: <phandle>
@@ -190,16 +88,9 @@
Usage: required
Value type: <prop-encoded-array>
Definition: a phandle reference to a syscon representing TCSR followed
- by the three offsets within syscon for q6, modem and nc
+ by the three offsets within syscon for q6, wcss and nc
halt registers.
-The Hexagon node must contain iommus property as described in ../iommu/iommu.txt
-on platforms which do not have TrustZone.
-
-= SUBNODES:
-The Hexagon node must contain two subnodes, named "mba" and "mpss" representing
-the memory regions used by the Hexagon firmware. Each sub-node must contain:
-
- memory-region:
Usage: required
Value type: <phandle>
@@ -209,56 +100,3 @@
"glink-edge" that describes the communication edge, channels and devices
related to the Hexagon. See ../soc/qcom/qcom,smd.yaml and
../soc/qcom/qcom,glink.txt for details on how to describe these.
-
-= EXAMPLE
-The following example describes the resources needed to boot control the
-Hexagon, as it is found on MSM8974 boards.
-
- remoteproc@fc880000 {
- compatible = "qcom,msm8974-mss-pil";
- reg = <0xfc880000 0x100>, <0xfc820000 0x020>;
- reg-names = "qdsp6", "rmb";
-
- interrupts-extended = <&intc GIC_SPI 24 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
-
- clocks = <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
- <&gcc GCC_MSS_CFG_AHB_CLK>,
- <&gcc GCC_BOOT_ROM_AHB_CLK>,
- <&xo_board>;
- clock-names = "iface", "bus", "mem", "xo";
-
- resets = <&gcc GCC_MSS_RESTART>;
- reset-names = "mss_restart";
-
- cx-supply = <&pm8841_s2>;
- mss-supply = <&pm8841_s3>;
- mx-supply = <&pm8841_s1>;
- pll-supply = <&pm8941_l12>;
-
- qcom,halt-regs = <&tcsr_mutex_block 0x1180 0x1200 0x1280>;
-
- qcom,smem-states = <&modem_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- mba {
- memory-region = <&mba_region>;
- };
-
- mpss {
- memory-region = <&mpss_region>;
- };
-
- smd-edge {
- interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
-
- qcom,ipc = <&apcs 8 12>;
- qcom,smd-edge = <0>;
-
- label = "modem";
- };
- };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
new file mode 100644
index 0000000..5efa0e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,qcs404-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCS404 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm QCS404 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs404-adsp-pas
+ - qcom,qcs404-cdsp-pas
+ - qcom,qcs404-wcss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ maxItems: 5
+
+ interrupt-names:
+ maxItems: 5
+
+ power-domains: false
+ power-domain-names: false
+ smd-edge: false
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ remoteproc@c700000 {
+ compatible = "qcom,qcs404-adsp-pas";
+ reg = <0x0c700000 0x4040>;
+
+ clocks = <&xo_board>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 293 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_fw_mem>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 289 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,remote-pid = <2>;
+ mboxes = <&apcs_glb 8>;
+
+ label = "adsp";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
index e4a7da80..b1402be 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
@@ -95,6 +95,7 @@
items:
- description: MBA reserved region
- description: modem reserved region
+ - description: metadata reserved region
firmware-name:
$ref: /schemas/types.yaml#/definitions/string-array
@@ -223,7 +224,7 @@
<&rpmhpd SC7180_MSS>;
power-domain-names = "cx", "mx", "mss";
- memory-region = <&mba_mem>, <&mpss_mem>;
+ memory-region = <&mba_mem>, <&mpss_mem>, <&mdata_mem>;
qcom,qmp = <&aoss_qmp>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
new file mode 100644
index 0000000..5cefd2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc7180-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7180/SC7280 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SC7180/SC7280 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7180-mpss-pas
+ - qcom,sc7280-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ minItems: 6
+
+ interrupt-names:
+ minItems: 6
+
+ power-domains:
+ minItems: 2
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ - description: MSS power domain
+
+ power-domain-names:
+ minItems: 2
+ items:
+ - const: cx
+ - const: mx
+ - const: mss
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-mpss-pas
+ then:
+ properties:
+ power-domains:
+ minItems: 3
+ power-domain-names:
+ minItems: 3
+ else:
+ properties:
+ power-domains:
+ maxItems: 2
+ power-domain-names:
+ maxItems: 2
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@4080000 {
+ compatible = "qcom,sc7180-mpss-pas";
+ reg = <0x04080000 0x4040>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ memory-region = <&mpss_mem>;
+
+ power-domains = <&rpmhpd SC7180_CX>,
+ <&rpmhpd SC7180_MX>,
+ <&rpmhpd SC7180_MSS>;
+ power-domain-names = "cx", "mx", "mss";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&modem_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+ label = "modem";
+ qcom,remote-pid = <1>;
+ mboxes = <&apss_shared 12>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
new file mode 100644
index 0000000..94ca7a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-adsp-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7280 ADSP Peripheral Image Loader
+
+maintainers:
+ - Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
+
+description:
+ This document describes the hardware for a component that loads and boots firmware
+ on the Qualcomm Technology Inc. ADSP.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7280-adsp-pil
+
+ reg:
+ items:
+ - description: qdsp6ss register
+ - description: efuse q6ss register
+
+ iommus:
+ items:
+ - description: Phandle to apps_smmu node with sid mask
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Shutdown acknowledge interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: shutdown-ack
+
+ clocks:
+ items:
+ - description: XO clock
+ - description: GCC CFG NOC LPASS clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: gcc_cfg_noc_lpass
+
+ power-domains:
+ items:
+ - description: LCX power domain
+
+ resets:
+ items:
+ - description: PDC AUDIO SYNC RESET
+ - description: CC LPASS restart
+
+ reset-names:
+ items:
+ - const: pdc_sync
+ - const: cc_lpass
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Phandle reference to a syscon representing TCSR followed by the
+ four offsets within syscon for q6, modem, nc and qv6 halt registers.
+ items:
+ - items:
+ - description: phandle to TCSR_MUTEX registers
+ - description: offset to the Q6 halt register
+ - description: offset to the modem halt register
+ - description: offset to the nc halt register
+ - description: offset to the vq6 halt register
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop the modem
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output
+ const: stop
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ glink-edge:
+ $ref: qcom,glink-edge.yaml#
+ type: object
+ unevaluatedProperties: false
+ description: |
+ Qualcomm G-Link subnode which represents communication edge, channels
+ and devices related to the ADSP.
+
+ properties:
+ label:
+ const: lpass
+
+ gpr: true
+ apr: false
+ fastrpc: false
+
+ required:
+ - label
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+ - qcom,halt-regs
+ - memory-region
+ - qcom,smem-states
+ - qcom,smem-state-names
+ - qcom,qmp
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpass-sc7280.h>
+ #include <dt-bindings/reset/qcom,sdm845-aoss.h>
+ #include <dt-bindings/reset/qcom,sdm845-pdc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,sc7280-adsp-pil";
+ reg = <0x03000000 0x5000>,
+ <0x0355b000 0x10>;
+
+ interrupts-extended = <&pdc 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack", "shutdown-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_CFG_NOC_LPASS_CLK>;
+ clock-names = "xo", "gcc_cfg_noc_lpass";
+
+ power-domains = <&rpmhpd SC7280_LCX>;
+
+ resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>,
+ <&aoss_reset AOSS_CC_LPASS_RESTART>;
+ reset-names = "pdc_sync", "cc_lpass";
+
+ qcom,halt-regs = <&tcsr_mutex 0x23000 0x25000 0x28000 0x33000>;
+
+ memory-region = <&adsp_mem>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ qcom,qmp = <&aoss_qmp>;
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
index b4de0521..005cb217 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
@@ -95,6 +95,7 @@
items:
- description: MBA reserved region
- description: modem reserved region
+ - description: metadata reserved region
firmware-name:
$ref: /schemas/types.yaml#/definitions/string-array
@@ -240,7 +241,7 @@
<&rpmhpd SC7280_MSS>;
power-domain-names = "cx", "mss";
- memory-region = <&mba_mem>, <&mpss_mem>;
+ memory-region = <&mba_mem>, <&mpss_mem>, <&mdata_mem>;
qcom,qmp = <&aoss_qmp>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml
new file mode 100644
index 0000000..c1f8dd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc8180x-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8180X Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SC8180X SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-adsp-pas
+ - qcom,sc8180x-cdsp-pas
+ - qcom,sc8180x-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-adsp-pas
+ - qcom,sc8180x-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-adsp-pas
+ - qcom,sc8180x-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+ else:
+ properties:
+ # TODO: incomplete
+ power-domains: false
+ power-domain-names: false
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
new file mode 100644
index 0000000..f6fbc53
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc8280xp-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SC8280XP SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-adsp-pas
+ - qcom,sc8280xp-nsp0-pas
+ - qcom,sc8280xp-nsp1-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-nsp0-pas
+ - qcom,sc8280xp-nsp1-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+ else:
+ properties:
+ power-domains:
+ items:
+ - description: NSP power domain
+ power-domain-names:
+ items:
+ - const: nsp
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,sc8280xp-adsp-pas";
+ reg = <0x03000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sc8280xp/qcadsp8280.mbn";
+
+ interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack", "shutdown-ack";
+
+ memory-region = <&pil_adsp_mem>;
+
+ power-domains = <&rpmhpd SC8280XP_LCX>,
+ <&rpmhpd SC8280XP_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
new file mode 100644
index 0000000..c66e298
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sdx55-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDX55 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SDX55 SoC Peripheral Authentication Service loads and boots firmware
+ on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdx55-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ minItems: 6
+
+ interrupt-names:
+ minItems: 6
+
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@4080000 {
+ compatible = "qcom,sdx55-mpss-pas";
+ reg = <0x04080000 0x4040>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 250 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ memory-region = <&mpss_adsp_mem>;
+
+ power-domains = <&rpmhpd SDX55_CX>, <&rpmhpd SDX55_MSS>;
+ power-domain-names = "cx", "mss";
+
+ qcom,smem-states = <&modem_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 114 IRQ_TYPE_EDGE_RISING>;
+ label = "mpss";
+ mboxes = <&apcs 15>;
+ qcom,remote-pid = <1>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
new file mode 100644
index 0000000..f5d1fa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm6115-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6115 Peripheral Authentication Service
+
+maintainers:
+ - Bhupesh Sharma <bhupesh.sharma@linaro.org>
+
+description:
+ Qualcomm SM6115 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6115-adsp-pas
+ - qcom,sm6115-cdsp-pas
+ - qcom,sm6115-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-adsp-pas
+ - qcom,sm6115-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-cdsp-pas
+ - qcom,sm6115-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ power-domain-names:
+ items:
+ - const: cx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LPI CX power domain
+ - description: LPI MX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@ab00000 {
+ compatible = "qcom,sm6115-adsp-pas";
+ reg = <0x0ab00000 0x100>;
+
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sm6115/adsp.mdt";
+
+ interrupts-extended = <&intc GIC_SPI 282 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&pil_adsp_mem>;
+
+ power-domains = <&rpmpd SM6115_VDD_LPI_CX>,
+ <&rpmpd SM6115_VDD_LPI_MX>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>;
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ mboxes = <&apcs_glb 8>;
+
+ /* ... */
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
new file mode 100644
index 0000000..fee02fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm6350-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6350 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM6350 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6350-adsp-pas
+ - qcom,sm6350-cdsp-pas
+ - qcom,sm6350-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-adsp-pas
+ - qcom,sm6350-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,sm6350-adsp-pas";
+ reg = <0x03000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_LEVEL_HIGH>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&pil_adsp_mem>;
+
+ power-domains = <&rpmhpd SM6350_LCX>,
+ <&rpmhpd SM6350_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
new file mode 100644
index 0000000..2c085ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
@@ -0,0 +1,174 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm8150-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150/SM8250 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM8150/SM8250 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8150-adsp-pas
+ - qcom,sm8150-cdsp-pas
+ - qcom,sm8150-mpss-pas
+ - qcom,sm8150-slpi-pas
+ - qcom,sm8250-adsp-pas
+ - qcom,sm8250-cdsp-pas
+ - qcom,sm8250-slpi-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8150-adsp-pas
+ - qcom,sm8150-cdsp-pas
+ - qcom,sm8150-slpi-pas
+ - qcom,sm8250-adsp-pas
+ - qcom,sm8250-cdsp-pas
+ - qcom,sm8250-slpi-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8150-adsp-pas
+ - qcom,sm8150-cdsp-pas
+ - qcom,sm8250-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ power-domain-names:
+ items:
+ - const: cx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8150-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8150-slpi-pas
+ - qcom,sm8250-adsp-pas
+ - qcom,sm8250-slpi-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@17300000 {
+ compatible = "qcom,sm8150-adsp-pas";
+ reg = <0x17300000 0x4040>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sm8150/adsp.mbn";
+
+ interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_mem>;
+
+ power-domains = <&rpmhpd SM8150_CX>;
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>;
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ mboxes = <&apss_shared 8>;
+
+ /* ... */
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
new file mode 100644
index 0000000..af24f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
@@ -0,0 +1,182 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm8350-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350/SM8450 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM8350/SM8450 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8350-adsp-pas
+ - qcom,sm8350-cdsp-pas
+ - qcom,sm8350-slpi-pas
+ - qcom,sm8350-mpss-pas
+ - qcom,sm8450-adsp-pas
+ - qcom,sm8450-cdsp-pas
+ - qcom,sm8450-mpss-pas
+ - qcom,sm8450-slpi-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ memory-region:
+ minItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8350-adsp-pas
+ - qcom,sm8350-cdsp-pas
+ - qcom,sm8350-slpi-pas
+ - qcom,sm8450-adsp-pas
+ - qcom,sm8450-cdsp-pas
+ - qcom,sm8450-slpi-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8350-mpss-pas
+ - qcom,sm8450-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8350-adsp-pas
+ - qcom,sm8350-slpi-pas
+ - qcom,sm8450-adsp-pas
+ - qcom,sm8450-slpi-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8350-cdsp-pas
+ - qcom,sm8450-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MXC power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mxc
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@30000000 {
+ compatible = "qcom,sm8450-adsp-pas";
+ reg = <0x030000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sm8450/adsp.mbn";
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_mem>;
+
+ power-domains = <&rpmhpd SM8450_LCX>,
+ <&rpmhpd SM8450_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
new file mode 100644
index 0000000..fe216aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm8550-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM8550 SoC Peripheral Authentication Service loads and boots firmware
+ on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8550-adsp-pas
+ - qcom,sm8550-cdsp-pas
+ - qcom,sm8550-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Firmware name of the Hexagon core
+ - description: Firmware name of the Hexagon Devicetree
+
+ memory-region:
+ minItems: 2
+ items:
+ - description: Memory region for main Firmware authentication
+ - description: Memory region for Devicetree Firmware authentication
+ - description: DSM Memory region
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8550-adsp-pas
+ - qcom,sm8550-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ memory-region:
+ maxItems: 2
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+ memory-region:
+ minItems: 3
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8550-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8550-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8550-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MXC power domain
+ - description: NSP power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mxc
+ - const: nsp
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+
+ remoteproc@30000000 {
+ compatible = "qcom,sm8550-adsp-pas";
+ reg = <0x030000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_mem>, <&dtb_adsp_mem>;
+
+ firmware-name = "qcom/sm8550/adsp.mbn",
+ "qcom/sm8550/adsp_dtb.mbn";
+
+ power-domains = <&rpmhpd_sm8550_lcx>,
+ <&rpmhpd_sm8550_lmx>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
deleted file mode 100644
index ac423f4..0000000
--- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
+++ /dev/null
@@ -1,177 +0,0 @@
-Qualcomm WCNSS Peripheral Image Loader
-
-This document defines the binding for a component that loads and boots firmware
-on the Qualcomm WCNSS core.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,riva-pil",
- "qcom,pronto-v1-pil",
- "qcom,pronto-v2-pil"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: must specify the base address and size of the CCU, DXE and
- PMU register blocks
-
-- reg-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "ccu", "dxe", "pmu"
-
-- interrupts-extended:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: must list the watchdog and fatal IRQs and may specify the
- ready, handover and stop-ack IRQs
-
-- interrupt-names:
- Usage: required
- Value type: <stringlist>
- Definition: should be "wdog", "fatal", optionally followed by "ready",
- "handover", "stop-ack"
-
-- firmware-name:
- Usage: optional
- Value type: <string>
- Definition: must list the relative firmware image path for the
- WCNSS core. Defaults to "wcnss.mdt".
-
-- vddmx-supply: (deprecated for qcom,pronto-v1/2-pil)
-- vddcx-supply: (deprecated for qcom,pronto-v1/2-pil)
-- vddpx-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the WCNSS core
-
-- power-domains:
- Usage: required (for qcom,pronto-v1/2-pil)
- Value type: <phandle>
- Definition: reference to the power domains to be held on behalf of the
- booting of the WCNSS core
-
-- power-domain-names:
- Usage: required (for qcom,pronto-v1/2-pil)
- Value type: <stringlist>
- Definition: must be "cx", "mx"
-
-- qcom,smem-states:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: reference to the SMEM state used to indicate to WCNSS that
- it should shut down
-
-- qcom,smem-state-names:
- Usage: optional
- Value type: <stringlist>
- Definition: should be "stop"
-
-- memory-region:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to reserved-memory node for the remote processor
- see ../reserved-memory/reserved-memory.txt
-
-= SUBNODES
-A required subnode of the WCNSS PIL is used to describe the attached rf module
-and its resource dependencies. It is described by the following properties:
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,wcn3620",
- "qcom,wcn3660",
- "qcom,wcn3660b",
- "qcom,wcn3680"
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the xo clock and optionally the rf clock
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: should be "xo", optionally followed by "rf"
-
-- vddxo-supply:
-- vddrfa-supply:
-- vddpa-supply:
-- vdddig-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the WCNSS core
-
-
-The wcnss node can also have an subnode named "smd-edge" that describes the SMD
-edge, channels and devices related to the WCNSS.
-See ../soc/qcom/qcom,smd.yaml for details on how to describe the SMD edge.
-
-= EXAMPLE
-The following example describes the resources needed to boot control the WCNSS,
-with attached WCN3680, as it is commonly found on MSM8974 boards.
-
-pronto@fb204000 {
- compatible = "qcom,pronto-v2-pil";
- reg = <0xfb204000 0x2000>, <0xfb202000 0x1000>, <0xfb21b000 0x3000>;
- reg-names = "ccu", "dxe", "pmu";
-
- interrupts-extended = <&intc 0 149 1>,
- <&wcnss_smp2p_slave 0 0>,
- <&wcnss_smp2p_slave 1 0>,
- <&wcnss_smp2p_slave 2 0>,
- <&wcnss_smp2p_slave 3 0>;
- interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
-
- power-domains = <&rpmpd MSM8974_VDDCX>, <&rpmpd MSM8974_VDDMX>;
- power-domain-names = "cx", "mx";
-
- vddpx-supply = <&pm8941_s3>;
-
- qcom,smem-states = <&wcnss_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- memory-region = <&wcnss_region>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&wcnss_pin_a>;
-
- iris {
- compatible = "qcom,wcn3680";
-
- clocks = <&rpmcc RPM_CXO_CLK_SRC>, <&rpmcc RPM_CXO_A2>;
- clock-names = "xo", "rf";
-
- vddxo-supply = <&pm8941_l6>;
- vddrfa-supply = <&pm8941_l11>;
- vddpa-supply = <&pm8941_l19>;
- vdddig-supply = <&pm8941_s3>;
- };
-
- smd-edge {
- interrupts = <0 142 1>;
-
- qcom,ipc = <&apcs 8 17>;
- qcom,smd-edge = <6>;
- qcom,remote-pid = <4>;
-
- label = "pronto";
-
- wcnss {
- compatible = "qcom,wcnss";
- qcom,smd-channels = "WCNSS_CTRL";
-
- qcom,mmio = <&pronto>;
-
- bt {
- compatible = "qcom,wcnss-bt";
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
new file mode 100644
index 0000000..45eb42b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
@@ -0,0 +1,294 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,wcnss-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WCNSS Peripheral Image Loader
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ This document defines the binding for a component that loads and boots
+ firmware on the Qualcomm WCNSS core.
+
+properties:
+ compatible:
+ description:
+ Append "qcom,pronto" if the device is actually pronto, and not riva
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pronto-v1-pil
+ - qcom,pronto-v2-pil
+ - qcom,pronto-v3-pil
+ - const: qcom,pronto
+ - const: qcom,riva-pil
+
+ reg:
+ maxItems: 3
+ description:
+ The base address and size of the CCU, DXE and PMU register blocks
+
+ reg-names:
+ items:
+ - const: ccu
+ - const: dxe
+ - const: pmu
+
+ interrupts:
+ minItems: 2
+ maxItems: 5
+
+ interrupt-names:
+ minItems: 2
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Relative firmware image path for the WCNSS core. Defaults to
+ "wcnss.mdt".
+
+ vddpx-supply:
+ description:
+ PX regulator to be held on behalf of the booting of the WCNSS core
+
+ vddmx-supply:
+ description:
+ MX regulator to be held on behalf of the booting of the WCNSS core.
+
+ vddcx-supply:
+ description:
+ CX regulator to be held on behalf of the booting of the WCNSS core.
+
+ power-domains:
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ States used by the AP to signal the WCNSS core that it should shutdown
+ items:
+ - description: Stop the modem
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output
+ items:
+ - const: stop
+
+ memory-region:
+ maxItems: 1
+ description: reserved-memory for the WCNSS core
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the ADSP.
+
+ iris:
+ type: object
+ description:
+ The iris subnode of the WCNSS PIL is used to describe the attached RF module
+ and its resource dependencies.
+
+ properties:
+ compatible:
+ enum:
+ - qcom,wcn3620
+ - qcom,wcn3660
+ - qcom,wcn3660b
+ - qcom,wcn3680
+
+ clocks:
+ minItems: 1
+ items:
+ - description: XO clock
+ - description: RF clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: xo
+ - const: rf
+
+ vddxo-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ vddrfa-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ vddpa-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ vdddig-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ required:
+ - compatible
+ - clocks
+ - clock-names
+ - vddxo-supply
+ - vddrfa-supply
+ - vddpa-supply
+ - vdddig-supply
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - iris
+ - vddpx-supply
+ - memory-region
+ - smd-edge
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,riva-pil
+ then:
+ required:
+ - vddcx-supply
+ - vddmx-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pronto-v1-pil
+ - qcom,pronto-v2-pil
+ then:
+ properties:
+ vddmx-supply:
+ deprecated: true
+ description: Deprecated for qcom,pronto-v1/2-pil
+
+ vddcx-supply:
+ deprecated: true
+ description: Deprecated for qcom,pronto-v1/2-pil
+
+ oneOf:
+ - required:
+ - power-domains
+ - power-domain-names
+ - required:
+ - vddmx-supply
+ - vddcx-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pronto-v3-pil
+ then:
+ properties:
+ vddmx-supply: false
+ vddcx-supply: false
+
+ required:
+ - power-domains
+ - power-domain-names
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ pronto@a21b000 {
+ compatible = "qcom,pronto-v2-pil", "qcom,pronto";
+ reg = <0x0a204000 0x2000>, <0x0a202000 0x1000>, <0x0a21b000 0x3000>;
+ reg-names = "ccu", "dxe", "pmu";
+
+ interrupts-extended = <&intc GIC_SPI 149 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+ power-domains = <&rpmpd MSM8916_VDDCX>, <&rpmpd MSM8916_VDDMX>;
+ power-domain-names = "cx", "mx";
+
+ vddpx-supply = <&pm8916_l7>;
+
+ qcom,smem-states = <&wcnss_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ memory-region = <&wcnss_region>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wcnss_pin_a>;
+
+ iris {
+ compatible = "qcom,wcn3620";
+ vddxo-supply = <&pm8916_l7>;
+ vddrfa-supply = <&pm8916_s3>;
+ vddpa-supply = <&pm8916_l9>;
+ vdddig-supply = <&pm8916_l5>;
+
+ clocks = <&rpmcc RPM_SMD_RF_CLK2>;
+ clock-names = "xo";
+ };
+
+ smd-edge {
+ interrupts = <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,ipc = <&apcs 8 17>;
+ qcom,smd-edge = <6>;
+ qcom,remote-pid = <4>;
+
+ label = "pronto";
+
+ wcnss_ctrl: wcnss {
+ compatible = "qcom,wcnss";
+ qcom,smd-channels = "WCNSS_CTRL";
+
+ qcom,mmio = <&pronto>;
+
+ bluetooth {
+ compatible = "qcom,wcnss-bt";
+ };
+
+ wifi {
+ compatible = "qcom,wcnss-wlan";
+
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tx", "rx";
+
+ qcom,smem-states = <&apps_smsm 10>, <&apps_smsm 9>;
+ qcom,smem-state-names = "tx-enable", "tx-rings-empty";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index cedbc5e..f16e903 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -31,10 +31,12 @@
properties:
compatible:
enum:
+ - ti,am62a-c7xv-dsp
- ti,j721e-c66-dsp
- ti,j721e-c71-dsp
- ti,j721s2-c71-dsp
description:
+ Use "ti,am62a-c7xv-dsp" for AM62A Deep learning DSPs on K3 AM62A SoCs
Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
Use "ti,j721s2-c71-dsp" for C71x DSPs on K3 J721S2 SoCs
@@ -109,6 +111,7 @@
properties:
compatible:
enum:
+ - ti,am62a-c7xv-dsp
- ti,j721e-c71-dsp
- ti,j721s2-c71-dsp
then:
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
new file mode 100644
index 0000000..c6d8696
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common TI PRU Consumer Binding
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+
+description: |
+ A PRU application/consumer/user node typically uses one or more PRU device
+ nodes to implement a PRU application/functionality. Each application/client
+ node would need a reference to at least a PRU node, and optionally define
+ some properties needed for hardware/firmware configuration. The below
+ properties are a list of common properties supported by the PRU remoteproc
+ infrastructure.
+
+ The application nodes shall define their own bindings like regular platform
+ devices, so below are in addition to each node's bindings.
+
+properties:
+ ti,prus:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: phandles to the PRU, RTU or Tx_PRU nodes used
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ minItems: 1
+ maxItems: 6
+ description: |
+ firmwares for the PRU cores, the default firmware for the core from
+ the PRU node will be used if not provided. The firmware names should
+ correspond to the PRU cores listed in the 'ti,prus' property
+
+ ti,pruss-gp-mux-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 6
+ items:
+ enum: [0, 1, 2, 3, 4]
+ description: |
+ array of values for the GP_MUX_SEL under PRUSS_GPCFG register for a PRU.
+ This selects the internal muxing scheme for the PRU instance. Values
+ should correspond to the PRU cores listed in the 'ti,prus' property. The
+ GP_MUX_SEL setting is a per-slice setting (one setting for PRU0, RTU0,
+ and Tx_PRU0 on K3 SoCs). Use the same value for all cores within the
+ same slice in the associative array. If the array size is smaller than
+ the size of 'ti,prus' property, the default out-of-reset value (0) for the
+ PRU core is used.
+
+required:
+ - ti,prus
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
new file mode 100644
index 0000000..05b6648
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /reserved-memory framebuffer node bindings
+
+maintainers:
+ - devicetree-spec@vger.kernel.org
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+ const: framebuffer
+ description: >
+ This indicates a region of memory meant to be used as a framebuffer for
+ a set of display devices. It can be used by an operating system to keep
+ the framebuffer from being overwritten and use it as the backing memory
+ for a display device (such as simple-framebuffer).
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ / {
+ compatible = "foo";
+ model = "foo";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen {
+ framebuffer {
+ compatible = "simple-framebuffer";
+ memory-region = <&fb>;
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fb: framebuffer@80000000 {
+ compatible = "framebuffer";
+ reg = <0x80000000 0x007e9000>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
index 2998f1c..08eb10c 100644
--- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
@@ -27,9 +27,11 @@
identifier of the client to use this region for buffers
qcom,vmid:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: >
- vmid of the remote processor, to set up memory protection
+ Array of vmids of the remote processors, to set up memory protection
+ minItems: 1
+ maxItems: 2
required:
- qcom,client-id
diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
index 44f72bc..c680e39 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
@@ -31,17 +31,17 @@
reg: true
size:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 2
+ oneOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - $ref: /schemas/types.yaml#/definitions/uint64
description: >
Length based on parent's \#size-cells. Size in bytes of memory to
reserve.
alignment:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 2
+ oneOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - $ref: /schemas/types.yaml#/definitions/uint64
description: >
Length based on parent's \#size-cells. Address boundary for
alignment of allocation.
@@ -52,6 +52,30 @@
Address and Length pairs. Specifies regions of memory that are
acceptable to allocate from.
+ iommu-addresses:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: >
+ A list of phandle and specifier pairs that describe static IO virtual
+ address space mappings and carveouts associated with a given reserved
+ memory region. The phandle in the first cell refers to the device for
+ which the mapping or carveout is to be created.
+
+ The specifier consists of an address/size pair and denotes the IO
+ virtual address range of the region for the given device. The exact
+ format depends on the values of the "#address-cells" and "#size-cells"
+ properties of the device referenced via the phandle.
+
+ When used in combination with a "reg" property, an IOVA mapping is to
+ be established for this memory region. One example where this can be
+ useful is to create an identity mapping for physical memory that the
+ firmware has configured some hardware to access (such as a bootsplash
+ framebuffer).
+
+ If no "reg" property is specified, the "iommu-addresses" property
+ defines carveout regions in the IOVA space for the given device. This
+ can be useful if a certain memory region should not be mapped through
+ the IOMMU.
+
no-map:
type: boolean
description: >
@@ -89,12 +113,69 @@
- no-map
oneOf:
- - required:
- - reg
+ - oneOf:
+ - required:
+ - reg
- - required:
- - size
+ - required:
+ - size
+
+ - oneOf:
+ # IOMMU reservations
+ - required:
+ - iommu-addresses
+
+ # IOMMU mappings
+ - required:
+ - reg
+ - iommu-addresses
additionalProperties: true
+examples:
+ - |
+ / {
+ compatible = "foo";
+ model = "foo";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ adsp_resv: reservation-adsp {
+ /*
+ * Restrict IOVA mappings for ADSP buffers to the 512 MiB region
+ * from 0x40000000 - 0x5fffffff. Anything outside is reserved by
+ * the ADSP for I/O memory and private memory allocations.
+ */
+ iommu-addresses = <&adsp 0x0 0x00000000 0x00 0x40000000>,
+ <&adsp 0x0 0x60000000 0xff 0xa0000000>;
+ };
+
+ fb: framebuffer@90000000 {
+ reg = <0x0 0x90000000 0x0 0x00800000>;
+ iommu-addresses = <&dc0 0x0 0x90000000 0x0 0x00800000>;
+ };
+ };
+
+ bus@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x40000000>;
+
+ adsp: adsp@2990000 {
+ reg = <0x2990000 0x2000>;
+ memory-region = <&adsp_resv>;
+ };
+
+ dc0: display@15200000 {
+ reg = <0x15200000 0x10000>;
+ memory-region = <&fb>;
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml
index 0a2c13e..fa253c5 100644
--- a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml
@@ -95,19 +95,12 @@
examples:
- |
- usb-glue@65b00000 {
- compatible = "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_rst: reset@0 {
- compatible = "socionext,uniphier-ld20-usb3-reset";
- reg = <0x0 0x4>;
- #reset-cells = <1>;
- clock-names = "link";
- clocks = <&sys_clk 14>;
- reset-names = "link";
- resets = <&sys_rst 14>;
- };
+ usb_rst: reset-controller@0 {
+ compatible = "socionext,uniphier-ld20-usb3-reset";
+ reg = <0x0 0x4>;
+ #reset-cells = <1>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
};
diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
index 6566804..033b252 100644
--- a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
@@ -66,53 +66,7 @@
examples:
- |
- sysctrl@61840000 {
- compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon";
- reg = <0x61840000 0x4000>;
-
- reset {
- compatible = "socionext,uniphier-ld11-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- mioctrl@59810000 {
- compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon";
- reg = <0x59810000 0x800>;
-
- reset {
- compatible = "socionext,uniphier-ld11-mio-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- perictrl@59820000 {
- compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon";
- reg = <0x59820000 0x200>;
-
- reset {
- compatible = "socionext,uniphier-ld11-peri-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- adamv@57920000 {
- compatible = "socionext,uniphier-ld11-adamv", "simple-mfd", "syscon";
- reg = <0x57920000 0x1000>;
-
- reset {
- compatible = "socionext,uniphier-ld11-adamv-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
+ reset-controller {
+ compatible = "socionext,uniphier-ld11-reset";
+ #reset-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index a2884e3..001931d 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -114,6 +114,12 @@
List of phandles to idle state nodes supported
by this hart (see ./idle-states.yaml).
+ capacity-dmips-mhz:
+ description:
+ u32 value representing CPU capacity (see ../cpu/cpu-capacity.txt) in
+ DMIPS/MHz, relative to highest capacity-dmips-mhz
+ in the system.
+
required:
- riscv,isa
- interrupt-controller
diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml b/Documentation/devicetree/bindings/riscv/microchip.yaml
index 714d0fc..4a29c89 100644
--- a/Documentation/devicetree/bindings/riscv/microchip.yaml
+++ b/Documentation/devicetree/bindings/riscv/microchip.yaml
@@ -27,6 +27,7 @@
- items:
- enum:
+ - aldec,tysom-m-mpfs250t-rev2
- aries,m100pfsevp
- microchip,mpfs-sev-kit
- sundance,polarberry
diff --git a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml b/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml
index bf3f074..eb6ab73 100644
--- a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml
+++ b/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml
@@ -8,8 +8,7 @@
title: SiFive Composable Cache Controller
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- - Paul Walmsley <paul.walmsley@sifive.com>
+ - Paul Walmsley <paul.walmsley@sifive.com>
description:
The SiFive Composable Cache Controller is used to provide access to fast copies
@@ -39,6 +38,10 @@
- sifive,fu740-c000-ccache
- const: cache
- items:
+ - const: starfive,jh7110-ccache
+ - const: sifive,ccache0
+ - const: cache
+ - items:
- const: microchip,mpfs-ccache
- const: sifive,fu540-c000-ccache
- const: cache
@@ -85,6 +88,7 @@
contains:
enum:
- sifive,fu740-c000-ccache
+ - starfive,jh7110-ccache
- microchip,mpfs-ccache
then:
@@ -105,7 +109,9 @@
properties:
compatible:
contains:
- const: sifive,fu740-c000-ccache
+ enum:
+ - sifive,fu740-c000-ccache
+ - starfive,jh7110-ccache
then:
properties:
diff --git a/Documentation/devicetree/bindings/riscv/starfive.yaml b/Documentation/devicetree/bindings/riscv/starfive.yaml
index 5d3fcee..cc4d92f 100644
--- a/Documentation/devicetree/bindings/riscv/starfive.yaml
+++ b/Documentation/devicetree/bindings/riscv/starfive.yaml
@@ -24,6 +24,12 @@
- starfive,visionfive-v1
- const: starfive,jh7100
+ - items:
+ - enum:
+ - starfive,visionfive-2-v1.2a
+ - starfive,visionfive-2-v1.3b
+ - const: starfive,jh7110
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/riscv/sunxi.yaml b/Documentation/devicetree/bindings/riscv/sunxi.yaml
new file mode 100644
index 0000000..9edb5e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sunxi.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sunxi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner RISC-V SoC-based boards
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Jernej Skrabec <jernej.skrabec@gmail.com>
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ Allwinner RISC-V SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Dongshan Nezha STU SoM
+ items:
+ - const: 100ask,dongshan-nezha-stu
+ - const: allwinner,sun20i-d1
+
+ - description: D1 Nezha board
+ items:
+ - const: allwinner,d1-nezha
+ - const: allwinner,sun20i-d1
+
+ - description: ClockworkPi R-01 SoM and v3.14 board
+ items:
+ - const: clockwork,r-01-clockworkpi-v3.14
+ - const: allwinner,sun20i-d1
+
+ - description: ClockworkPi R-01 SoM, v3.14 board, and DevTerm expansion
+ items:
+ - const: clockwork,r-01-devterm-v3.14
+ - const: clockwork,r-01-clockworkpi-v3.14
+ - const: allwinner,sun20i-d1
+
+ - description: Lichee RV SoM
+ items:
+ - const: sipeed,lichee-rv
+ - const: allwinner,sun20i-d1
+
+ - description: Carrier boards for the Lichee RV SoM
+ items:
+ - enum:
+ - sipeed,lichee-rv-86-panel-480p
+ - sipeed,lichee-rv-86-panel-720p
+ - sipeed,lichee-rv-dock
+ - const: sipeed,lichee-rv
+ - const: allwinner,sun20i-d1
+
+ - description: MangoPi MQ board
+ items:
+ - const: widora,mangopi-mq
+ - const: allwinner,sun20i-d1s
+
+ - description: MangoPi MQ Pro board
+ items:
+ - const: widora,mangopi-mq-pro
+ - const: allwinner,sun20i-d1
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml b/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
new file mode 100644
index 0000000..2b76ce2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/starfive,jh7110-trng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive SoC TRNG Module
+
+maintainers:
+ - Jia Jie Ho <jiajie.ho@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-trng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Hardware reference clock
+ - description: AHB reference clock
+
+ clock-names:
+ items:
+ - const: hclk
+ - const: ahb
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ rng: rng@1600C000 {
+ compatible = "starfive,jh7110-trng";
+ reg = <0x1600C000 0x4000>;
+ clocks = <&clk 15>, <&clk 16>;
+ clock-names = "hclk", "ahb";
+ resets = <&reset 3>;
+ interrupts = <30>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml b/Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml
new file mode 100644
index 0000000..a89865f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/amlogic,meson-vrtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Virtual RTC (VRTC)
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ This is a Linux interface to an RTC managed by firmware, hence it's
+ virtual from a Linux perspective. The interface is 1 register where
+ an alarm time (in seconds) is to be written.
+ The alarm register is a simple scratch register shared between the
+ application processors (AP) and the secure co-processor (SCP.) When
+ the AP suspends, the SCP will use the value of this register to
+ program an always-on timer before going sleep. When the timer expires,
+ the SCP will wake up and will then wake the AP.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-vrtc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc@a8 {
+ compatible = "amlogic,meson-vrtc";
+ reg = <0x000a8 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml
index 9fe0799..c6c5763 100644
--- a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml
+++ b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml
@@ -11,7 +11,8 @@
description:
The Broadcom STB wake-up timer provides a 27Mhz resolution timer, with the
- ability to wake up the system from low-power suspend/standby modes.
+ ability to wake up the system from low-power suspend/standby modes and
+ optionally generate RTC alarm interrupts.
allOf:
- $ref: "rtc.yaml#"
@@ -24,8 +25,14 @@
maxItems: 1
interrupts:
- description: the TIMER interrupt
- maxItems: 1
+ minItems: 1
+ items:
+ - description: the TIMER interrupt
+ - description: the ALARM interrupt
+ description:
+ The TIMER interrupt wakes the system from low-power suspend/standby modes.
+ An ALARM interrupt may be specified to interrupt the CPU when an RTC alarm
+ is enabled.
clocks:
description: clock reference in the 27MHz domain
@@ -35,10 +42,10 @@
examples:
- |
- rtc@f0411580 {
+ rtc@f041a080 {
compatible = "brcm,brcmstb-waketimer";
- reg = <0xf0411580 0x14>;
- interrupts = <0x3>;
- interrupt-parent = <&aon_pm_l2_intc>;
+ reg = <0xf041a080 0x14>;
+ interrupts-extended = <&aon_pm_l2_intc 0x04>,
+ <&upg_aux_aon_intr2_intc 0x08>;
clocks = <&upg_fixed>;
};
diff --git a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
index af78b67..de9879bd 100644
--- a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
@@ -11,6 +11,17 @@
allOf:
- $ref: rtc.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ingenic,jz4770-rtc
+ - ingenic,jz4780-rtc
+ then:
+ properties:
+ "#clock-cells": false
properties:
compatible:
@@ -39,6 +50,9 @@
clock-names:
const: rtc
+ "#clock-cells":
+ const: 0
+
system-power-controller:
description: |
Indicates that the RTC is responsible for powering OFF
@@ -83,3 +97,18 @@
clocks = <&cgu JZ4740_CLK_RTC>;
clock-names = "rtc";
};
+
+ - |
+ #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
+ rtc: rtc@10003000 {
+ compatible = "ingenic,jz4780-rtc", "ingenic,jz4760-rtc";
+ reg = <0x10003000 0x4c>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <32>;
+
+ clocks = <&cgu JZ4780_CLK_RTCLK>;
+ clock-names = "rtc";
+
+ #clock-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
new file mode 100644
index 0000000..5ade5df
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/microcrystal,rv3028.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip RV-3028 RTC
+
+allOf:
+ - $ref: rtc.yaml#
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ const: microcrystal,rv3028
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ trickle-resistor-ohms:
+ enum:
+ - 3000
+ - 5000
+ - 9000
+ - 15000
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@51 {
+ compatible = "microcrystal,rv3028";
+ reg = <0x51>;
+ pinctrl-0 = <&rtc_nint_pins>;
+ interrupts-extended = <&gpio1 16 IRQ_TYPE_LEVEL_HIGH>;
+ trickle-resistor-ohms = <3000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
index c9d3ac1..1374df7 100644
--- a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
@@ -3,15 +3,15 @@
Required properties:
- compatible : Should be "moxa,moxart-rtc"
-- gpio-rtc-sclk : RTC sclk gpio, with zero flags
-- gpio-rtc-data : RTC data gpio, with zero flags
-- gpio-rtc-reset : RTC reset gpio, with zero flags
+- rtc-sclk-gpios : RTC sclk gpio, with zero flags
+- rtc-data-gpios : RTC data gpio, with zero flags
+- rtc-reset-gpios : RTC reset gpio, with zero flags
Example:
rtc: rtc {
compatible = "moxa,moxart-rtc";
- gpio-rtc-sclk = <&gpio 5 0>;
- gpio-rtc-data = <&gpio 6 0>;
- gpio-rtc-reset = <&gpio 7 0>;
+ rtc-sclk-gpios = <&gpio 5 0>;
+ rtc-data-gpios = <&gpio 6 0>;
+ rtc-reset-gpios = <&gpio 7 0>;
};
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
index cde7b16..a1148eb 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
@@ -14,7 +14,10 @@
properties:
compatible:
- const: nxp,pcf2127
+ enum:
+ - nxp,pca2129
+ - nxp,pcf2127
+ - nxp,pcf2129
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml
new file mode 100644
index 0000000..52aa3e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,pcf85363.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Philips PCF85263/PCF85363 Real Time Clock
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nxp,pcf85263
+ - nxp,pcf85363
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ quartz-load-femtofarads:
+ description:
+ The capacitive load of the quartz(x-tal).
+ enum: [6000, 7000, 12500]
+ default: 7000
+
+ start-year: true
+ wakeup-source: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@51 {
+ compatible = "nxp,pcf85363";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ quartz-load-femtofarads = <12500>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml
index a98b727..22909a9 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml
@@ -19,8 +19,6 @@
- microcrystal,rv8564
- nxp,pca8565
- nxp,pcf8563
- - nxp,pcf85263
- - nxp,pcf85363
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
index 21c8ea0..b95a69c 100644
--- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
@@ -40,6 +40,16 @@
description:
Indicates that the setting of RTC time is allowed by the host CPU.
+ nvmem-cells:
+ items:
+ - description:
+ four-byte nvmem cell holding a little-endian offset from the Unix
+ epoch representing the time when the RTC timer was last reset
+
+ nvmem-cell-names:
+ items:
+ - const: offset
+
wakeup-source: true
required:
@@ -69,6 +79,8 @@
compatible = "qcom,pm8921-rtc";
reg = <0x11d>;
interrupts = <0x27 0>;
+ nvmem-cells = <&rtc_offset>;
+ nvmem-cell-names = "offset";
};
};
};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
deleted file mode 100644
index c014f54..0000000
--- a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic Virtual RTC (VRTC)
-
-This is a Linux interface to an RTC managed by firmware, hence it's
-virtual from a Linux perspective. The interface is 1 register where
-an alarm time (in seconds) is to be written.
-
-Required properties:
-- compatible: should be "amlogic,meson-vrtc"
-- reg: physical address for the alarm register
-
-The alarm register is a simple scratch register shared between the
-application processors (AP) and the secure co-processor (SCP.) When
-the AP suspends, the SCP will use the value of this register to
-program an always-on timer before going sleep. When the timer expires,
-the SCP will wake up and will then wake the AP.
-
-Example:
-
- vrtc: rtc@0a8 {
- compatible = "amlogic,meson-vrtc";
- reg = <0x0 0x000a8 0x0 0x4>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index d9fc120..eb75861 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -47,14 +47,12 @@
- isil,isl1218
# Intersil ISL12022 Real-time Clock
- isil,isl12022
- # Real Time Clock Module with I2C-Bus
- - microcrystal,rv3028
+ # Loongson-2K Socs/LS7A bridge Real-time Clock
+ - loongson,ls2x-rtc
# Real Time Clock Module with I2C-Bus
- microcrystal,rv3029
# Real Time Clock
- microcrystal,rv8523
- - nxp,pca2129
- - nxp,pcf2129
# Real-time Clock Module
- pericom,pt7c4338
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 34b8e59..692aa05 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -11,6 +11,7 @@
allOf:
- $ref: serial.yaml#
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
- if:
anyOf:
- required:
@@ -62,7 +63,6 @@
- const: mrvl,pxa-uart
- const: nuvoton,wpcm450-uart
- const: nuvoton,npcm750-uart
- - const: nuvoton,npcm845-uart
- const: nvidia,tegra20-uart
- const: nxp,lpc3220-uart
- items:
@@ -94,6 +94,10 @@
- ns16550a
- items:
- enum:
+ - nuvoton,npcm845-uart
+ - const: nuvoton,npcm750-uart
+ - items:
+ - enum:
- ralink,mt7620a-uart
- ralink,rt3052-uart
- ralink,rt3883-uart
@@ -200,12 +204,13 @@
deprecated: true
aspeed,lpc-io-reg:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: |
The VUART LPC address. Only applicable to aspeed,ast2500-vuart.
aspeed,lpc-interrupts:
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
description: |
diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml
index 53dc121..eb3488d 100644
--- a/Documentation/devicetree/bindings/serial/8250_omap.yaml
+++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml
@@ -70,11 +70,6 @@
dsr-gpios: true
rng-gpios: true
dcd-gpios: true
- rs485-rts-delay: true
- rs485-rts-active-low: true
- rs485-rx-during-tx: true
- rs485-rts-active-high: true
- linux,rs485-enabled-at-boot-time: true
rts-gpio: true
power-domains: true
clock-frequency: true
@@ -109,12 +104,12 @@
examples:
- |
- serial@49042000 {
- compatible = "ti,omap3-uart";
- reg = <0x49042000 0x400>;
- interrupts = <80>;
- dmas = <&sdma 81 &sdma 82>;
- dma-names = "tx", "rx";
- ti,hwmods = "uart4";
- clock-frequency = <48000000>;
- };
+ serial@49042000 {
+ compatible = "ti,omap3-uart";
+ reg = <0x49042000 0x400>;
+ interrupts = <80>;
+ dmas = <&sdma 81 &sdma 82>;
+ dma-names = "tx", "rx";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
index 7822705..3cbdde8 100644
--- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
@@ -19,6 +19,9 @@
is active since power-on and does not need any clock gating and is usable
as very early serial console.
+allOf:
+ - $ref: serial.yaml#
+
properties:
compatible:
oneOf:
@@ -69,14 +72,14 @@
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
serial@84c0 {
- compatible = "amlogic,meson-gx-uart";
- reg = <0x84c0 0x14>;
- interrupts = <26>;
- clocks = <&xtal>, <&pclk>, <&xtal>;
- clock-names = "xtal", "pclk", "baud";
+ compatible = "amlogic,meson-gx-uart";
+ reg = <0x84c0 0x14>;
+ interrupts = <26>;
+ clocks = <&xtal>, <&pclk>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index 876b8cf..a8b323d 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -9,9 +9,6 @@
maintainers:
- Michal Simek <michal.simek@xilinx.com>
-allOf:
- - $ref: /schemas/serial.yaml#
-
properties:
compatible:
oneOf:
@@ -46,6 +43,9 @@
port does not use this pin.
type: boolean
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -53,14 +53,25 @@
- clocks
- clock-names
+allOf:
+ - $ref: serial.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: cdns,uart-r1p8
+ then:
+ properties:
+ power-domains: false
+
unevaluatedProperties: false
examples:
- |
uart0: serial@e0000000 {
- compatible = "xlnx,xuartps", "cdns,uart-r1p8";
- clocks = <&clkc 23>, <&clkc 40>;
- clock-names = "uart_clk", "pclk";
- reg = <0xE0000000 0x1000>;
- interrupts = <0 27 4>;
+ compatible = "xlnx,xuartps", "cdns,uart-r1p8";
+ clocks = <&clkc 23>, <&clkc 40>;
+ clock-names = "uart_clk", "pclk";
+ reg = <0xe0000000 0x1000>;
+ interrupts = <0 27 4>;
};
diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
index 8b643ba..9205399 100644
--- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
@@ -16,7 +16,7 @@
- Chester Lin <clin@suse.com>
allOf:
- - $ref: "serial.yaml"
+ - $ref: serial.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
index 9d94929..4cbe76e 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
@@ -10,8 +10,8 @@
- Fabio Estevam <festevam@gmail.com>
allOf:
- - $ref: "serial.yaml"
- - $ref: "rs485.yaml"
+ - $ref: serial.yaml#
+ - $ref: rs485.yaml#
properties:
compatible:
@@ -83,13 +83,6 @@
are sensible for most use cases. If you need low latency processing on
slow connections this needs to be configured appropriately.
- uart-has-rtscts: true
-
- rs485-rts-delay: true
- rs485-rts-active-low: true
- rs485-rx-during-tx: true
- linux,rs485-enabled-at-boot-time: true
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
index 74f75f6..ab81722 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
@@ -10,7 +10,8 @@
- Fugang Duan <fugang.duan@nxp.com>
allOf:
- - $ref: "rs485.yaml"
+ - $ref: rs485.yaml#
+ - $ref: serial.yaml#
properties:
compatible:
@@ -64,9 +65,6 @@
- const: rx
- const: tx
- rs485-rts-active-low: true
- linux,rs485-enabled-at-boot-time: true
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml
index 14c7594..6a400a5 100644
--- a/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml
@@ -10,7 +10,7 @@
- Fabio Estevam <festevam@gmail.com>
allOf:
- - $ref: "serial.yaml"
+ - $ref: serial.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml
index 80af728..95710410 100644
--- a/Documentation/devicetree/bindings/serial/pl011.yaml
+++ b/Documentation/devicetree/bindings/serial/pl011.yaml
@@ -10,6 +10,7 @@
- Rob Herring <robh@kernel.org>
allOf:
+ - $ref: /schemas/arm/primecell.yaml#
- $ref: serial.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt b/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt
deleted file mode 100644
index ce8c901..0000000
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* MSM Serial UART
-
-The MSM serial UART hardware is designed for low-speed use cases where a
-dma-engine isn't needed. From a software perspective it's mostly compatible
-with the MSM serial UARTDM except that it only supports reading and writing one
-character at a time.
-
-Required properties:
-- compatible: Should contain "qcom,msm-uart"
-- reg: Should contain UART register location and length.
-- interrupts: Should contain UART interrupt.
-- clocks: Should contain the core clock.
-- clock-names: Should be "core".
-
-Example:
-
-A uart device at 0xa9c00000 with interrupt 11.
-
-serial@a9c00000 {
- compatible = "qcom,msm-uart";
- reg = <0xa9c00000 0x1000>;
- interrupts = <11>;
- clocks = <&uart_cxc>;
- clock-names = "core";
-};
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml
new file mode 100644
index 0000000..a052aae
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/qcom,msm-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM SoC Serial UART
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+ The MSM serial UART hardware is designed for low-speed use cases where a
+ dma-engine isn't needed. From a software perspective it's mostly compatible
+ with the MSM serial UARTDM except that it only supports reading and writing
+ one character at a time.
+
+properties:
+ compatible:
+ const: qcom,msm-uart
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: core
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clock-names
+ - clocks
+ - interrupts
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+examples:
+ - |
+ serial@a9c00000 {
+ compatible = "qcom,msm-uart";
+ reg = <0xa9c00000 0x1000>;
+ interrupts = <11>;
+ clocks = <&uart_cxc>;
+ clock-names = "core";
+ };
diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
index b25aca7..12d0fa34 100644
--- a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
@@ -66,9 +66,9 @@
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
uart0: serial@e1020000 {
- compatible = "renesas,em-uart";
- reg = <0xe1020000 0x38>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&usia_u0_sclk>;
- clock-names = "sclk";
+ compatible = "renesas,em-uart";
+ reg = <0xe1020000 0x38>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usia_u0_sclk>;
+ clock-names = "sclk";
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
index 1957b9d..afedb6e 100644
--- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
@@ -131,20 +131,20 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7795-sysc.h>
aliases {
- serial1 = &hscif1;
+ serial1 = &hscif1;
};
hscif1: serial@e6550000 {
- compatible = "renesas,hscif-r8a7795", "renesas,rcar-gen3-hscif",
- "renesas,hscif";
- reg = <0xe6550000 96>;
- interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 519>, <&cpg CPG_CORE R8A7795_CLK_S3D1>,
- <&scif_clk>;
- clock-names = "fck", "brg_int", "scif_clk";
- dmas = <&dmac1 0x33>, <&dmac1 0x32>, <&dmac2 0x33>, <&dmac2 0x32>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
- resets = <&cpg 519>;
- uart-has-rtscts;
+ compatible = "renesas,hscif-r8a7795", "renesas,rcar-gen3-hscif",
+ "renesas,hscif";
+ reg = <0xe6550000 96>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 519>, <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac1 0x33>, <&dmac1 0x32>, <&dmac2 0x33>, <&dmac2 0x32>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 519>;
+ uart-has-rtscts;
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci.yaml b/Documentation/devicetree/bindings/serial/renesas,sci.yaml
index bf7708a..dc445b3 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,sci.yaml
@@ -91,19 +91,19 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
aliases {
- serial0 = &sci0;
+ serial0 = &sci0;
};
sci0: serial@1004d000 {
- compatible = "renesas,r9a07g044-sci", "renesas,sci";
- reg = <0x1004d000 0x400>;
- interrupts = <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "eri", "rxi", "txi", "tei";
- clocks = <&cpg CPG_MOD R9A07G044_SCI0_CLKP>;
- clock-names = "fck";
- power-domains = <&cpg>;
- resets = <&cpg R9A07G044_SCI0_RST>;
+ compatible = "renesas,r9a07g044-sci", "renesas,sci";
+ reg = <0x1004d000 0x400>;
+ interrupts = <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "eri", "rxi", "txi", "tei";
+ clocks = <&cpg CPG_MOD R9A07G044_SCI0_CLKP>;
+ clock-names = "fck";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_SCI0_RST>;
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index f81f2d6..54e4f41 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -92,7 +92,7 @@
- description: Error interrupt
- description: Receive buffer full interrupt
- description: Transmit buffer empty interrupt
- - description: Transmit End interrupt
+ - description: Break interrupt
- items:
- description: Error interrupt
- description: Receive buffer full interrupt
@@ -107,7 +107,7 @@
- const: eri
- const: rxi
- const: txi
- - const: tei
+ - const: bri
- items:
- const: eri
- const: rxi
@@ -180,19 +180,19 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7791-sysc.h>
aliases {
- serial0 = &scif0;
+ serial0 = &scif0;
};
scif0: serial@e6e60000 {
- compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
- "renesas,scif";
- reg = <0xe6e60000 64>;
- interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 721>, <&cpg CPG_CORE R8A7791_CLK_ZS>,
- <&scif_clk>;
- clock-names = "fck", "brg_int", "scif_clk";
- dmas = <&dmac0 0x29>, <&dmac0 0x2a>, <&dmac1 0x29>, <&dmac1 0x2a>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
- resets = <&cpg 721>;
+ compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+ "renesas,scif";
+ reg = <0xe6e60000 64>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 721>, <&cpg CPG_CORE R8A7791_CLK_ZS>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>, <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 721>;
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
index 3c67d320..4c3b5e7 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
@@ -95,18 +95,18 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7790-sysc.h>
aliases {
- serial0 = &scifa0;
+ serial0 = &scifa0;
};
scifa0: serial@e6c40000 {
- compatible = "renesas,scifa-r8a7790", "renesas,rcar-gen2-scifa",
- "renesas,scifa";
- reg = <0xe6c40000 64>;
- interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 204>;
- clock-names = "fck";
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 204>;
- dmas = <&dmac0 0x21>, <&dmac0 0x22>, <&dmac1 0x21>, <&dmac1 0x22>;
- dma-names = "tx", "rx", "tx", "rx";
+ compatible = "renesas,scifa-r8a7790", "renesas,rcar-gen2-scifa",
+ "renesas,scifa";
+ reg = <0xe6c40000 64>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 204>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 204>;
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>, <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
index d5571c7..2f7cbbb 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
@@ -94,10 +94,10 @@
#include <dt-bindings/clock/r8a7740-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
scifb: serial@e6c30000 {
- compatible = "renesas,scifb-r8a7740", "renesas,scifb";
- reg = <0xe6c30000 0x100>;
- interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
- clock-names = "fck";
- power-domains = <&pd_a3sp>;
+ compatible = "renesas,scifb-r8a7740", "renesas,scifb";
+ reg = <0xe6c30000 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
+ clock-names = "fck";
+ power-domains = <&pd_a3sp>;
};
diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
index 789763c..303a443 100644
--- a/Documentation/devicetree/bindings/serial/rs485.yaml
+++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@ -51,6 +51,12 @@
description: GPIO pin to enable RS485 bus termination.
maxItems: 1
+ rs485-rx-during-tx-gpios:
+ description: Output GPIO pin that sets the state of rs485-rx-during-tx. This
+ signal can be used to control the RX part of an RS485 transceiver. Thereby
+ the active state enables RX during TX.
+ maxItems: 1
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index 11e822b..c9231e5 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -96,7 +96,7 @@
rts-gpios: false
patternProperties:
- ".*":
+ "^bluetooth|gnss|gps|mcu$":
if:
type: object
then:
@@ -141,13 +141,13 @@
examples:
- |
serial@1234 {
- compatible = "ns16550a";
- reg = <0x1234 0x20>;
- interrupts = <1>;
+ compatible = "ns16550a";
+ reg = <0x1234 0x20>;
+ interrupts = <1>;
- bluetooth {
- compatible = "brcm,bcm4330-bt";
- interrupt-parent = <&gpio>;
- interrupts = <10>;
- };
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ interrupt-parent = <&gpio>;
+ interrupts = <10>;
+ };
};
diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
index b0a8871..b0df1ca 100644
--- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
@@ -53,13 +53,13 @@
examples:
- |
- #include <dt-bindings/clock/sifive-fu540-prci.h>
- serial@10010000 {
+ #include <dt-bindings/clock/sifive-fu540-prci.h>
+ serial@10010000 {
compatible = "sifive,fu540-c000-uart", "sifive,uart0";
interrupt-parent = <&plic0>;
interrupts = <80>;
reg = <0x10010000 0x1000>;
clocks = <&prci FU540_PRCI_CLK_TLCLK>;
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index b9c2287..2becdfa 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -67,6 +67,14 @@
- const: baudclk
- const: apb_pclk
+ dmas:
+ minItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
snps,uart-16550-compatible:
description: reflects the value of UART_16550_COMPATIBLE configuration
parameter. Define this if your UART does not implement the busy functionality.
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 85876c6..1df8ffe 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -35,8 +35,6 @@
description: enable hardware flow control (deprecated)
$ref: /schemas/types.yaml#/definitions/flag
- uart-has-rtscts: true
-
rx-tx-swap: true
dmas:
@@ -60,11 +58,6 @@
wakeup-source: true
- rs485-rts-delay: true
- rs485-rts-active-low: true
- linux,rs485-enabled-at-boot-time: true
- rs485-rx-during-tx: true
-
rx-threshold:
description:
If value is set to 1, RX FIFO threshold is disabled.
diff --git a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
index 2f4390e..08dcb27 100644
--- a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
+++ b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
@@ -63,7 +63,7 @@
- xlnx,use-parity
allOf:
- - $ref: /schemas/serial.yaml#
+ - $ref: serial.yaml#
- if:
properties:
xlnx,use-parity:
@@ -76,7 +76,7 @@
examples:
- |
- serial@800c0000 {
+ serial@800c0000 {
compatible = "xlnx,xps-uartlite-1.00.a";
reg = <0x800c0000 0x10000>;
interrupts = <0x0 0x6e 0x1>;
@@ -84,5 +84,5 @@
current-speed = <115200>;
xlnx,data-bits = <8>;
xlnx,use-parity = <0>;
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
new file mode 100644
index 0000000..1da1b75
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/imx/fsl,imx-iomuxc-gpr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IOMUX Controller General Purpose Registers
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description:
+ i.MX Processors have an IOMUXC General Purpose Register group for
+ various System Settings
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,imx8mq-iomuxc-gpr
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - fsl,imx8mm-iomuxc-gpr
+ - fsl,imx8mn-iomuxc-gpr
+ - fsl,imx8mp-iomuxc-gpr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ mux-controller:
+ type: object
+ $ref: /schemas/mux/reg-mux.yaml
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ # Pinmux controller node
+ - |
+ iomuxc_gpr: syscon@30340000 {
+ compatible = "fsl,imx8mq-iomuxc-gpr", "syscon", "simple-mfd";
+ reg = <0x30340000 0x10000>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x34 0x00000004>; /* MIPI_MUX_SEL */
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml
index c29181a..1fe68b5 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml
@@ -39,6 +39,9 @@
- const: pcie
- const: pcie-phy
+ '#clock-cells':
+ const: 0
+
clocks:
minItems: 2
maxItems: 2
@@ -85,4 +88,5 @@
power-domain-names = "bus", "usb", "usb-phy1",
"usb-phy2", "pcie", "pcie-phy";
#power-domain-cells = <1>;
+ #clock-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
index 9241e5f..15c133c 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
@@ -32,6 +32,7 @@
- mediatek,mt8183-disp-mutex
- mediatek,mt8186-disp-mutex
- mediatek,mt8186-mdp3-mutex
+ - mediatek,mt8188-disp-mutex
- mediatek,mt8192-disp-mutex
- mediatek,mt8195-disp-mutex
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
new file mode 100644
index 0000000..3fefd63
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,pwrap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek PMIC Wrapper
+
+maintainers:
+ - Flora Fu <flora.fu@mediatek.com>
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+description:
+ On MediaTek SoCs the PMIC is connected via SPI. The SPI master interface
+ is not directly visible to the CPU, but only through the PMIC wrapper
+ inside the SoC. The communication between the SoC and the PMIC can
+ optionally be encrypted. Also a non standard Dual IO SPI mode can be
+ used to increase speed.
+
+ IP Pairing
+
+ On MT8135 the pins of some SoC internal peripherals can be on the PMIC.
+ The signals of these pins are routed over the SPI bus using the pwrap
+ bridge. In the binding description below the properties needed for bridging
+ are marked with "IP Pairing". These are optional on SoCs which do not support
+ IP Pairing
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt2701-pwrap
+ - mediatek,mt6765-pwrap
+ - mediatek,mt6779-pwrap
+ - mediatek,mt6797-pwrap
+ - mediatek,mt6873-pwrap
+ - mediatek,mt7622-pwrap
+ - mediatek,mt8135-pwrap
+ - mediatek,mt8173-pwrap
+ - mediatek,mt8183-pwrap
+ - mediatek,mt8186-pwrap
+ - mediatek,mt8188-pwrap
+ - mediatek,mt8195-pwrap
+ - mediatek,mt8365-pwrap
+ - mediatek,mt8516-pwrap
+ - items:
+ - enum:
+ - mediatek,mt8186-pwrap
+ - mediatek,mt8195-pwrap
+ - const: syscon
+
+ reg:
+ minItems: 1
+ items:
+ - description: PMIC wrapper registers
+ - description: IP pairing registers
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: pwrap
+ - const: pwrap-bridge
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ items:
+ - description: SPI bus clock
+ - description: Main module clock
+ - description: System module clock
+ - description: Timer module clock
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: spi
+ - const: wrap
+ - const: sys
+ - const: tmr
+
+ resets:
+ minItems: 1
+ items:
+ - description: PMIC wrapper reset
+ - description: IP pairing reset
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: pwrap
+ - const: pwrap-bridge
+
+ pmic:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+
+dependentRequired:
+ resets: [reset-names]
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8365-pwrap
+ then:
+ properties:
+ clocks:
+ minItems: 4
+
+ clock-names:
+ minItems: 4
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/mt8135-resets.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pwrap@1000f000 {
+ compatible = "mediatek,mt8135-pwrap";
+ reg = <0 0x1000f000 0 0x1000>,
+ <0 0x11017000 0 0x1000>;
+ reg-names = "pwrap", "pwrap-bridge";
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk26m>, <&clk26m>;
+ clock-names = "spi", "wrap";
+ resets = <&infracfg MT8135_INFRA_PMIC_WRAP_RST>,
+ <&pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST>;
+ reset-names = "pwrap", "pwrap-bridge";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
deleted file mode 100644
index 12e4b42..0000000
--- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-MediaTek PMIC Wrapper Driver
-
-This document describes the binding for the MediaTek PMIC wrapper.
-
-On MediaTek SoCs the PMIC is connected via SPI. The SPI master interface
-is not directly visible to the CPU, but only through the PMIC wrapper
-inside the SoC. The communication between the SoC and the PMIC can
-optionally be encrypted. Also a non standard Dual IO SPI mode can be
-used to increase speed.
-
-IP Pairing
-
-on MT8135 the pins of some SoC internal peripherals can be on the PMIC.
-The signals of these pins are routed over the SPI bus using the pwrap
-bridge. In the binding description below the properties needed for bridging
-are marked with "IP Pairing". These are optional on SoCs which do not support
-IP Pairing
-
-Required properties in pwrap device node.
-- compatible:
- "mediatek,mt2701-pwrap" for MT2701/7623 SoCs
- "mediatek,mt6765-pwrap" for MT6765 SoCs
- "mediatek,mt6779-pwrap" for MT6779 SoCs
- "mediatek,mt6797-pwrap" for MT6797 SoCs
- "mediatek,mt6873-pwrap" for MT6873/8192 SoCs
- "mediatek,mt7622-pwrap" for MT7622 SoCs
- "mediatek,mt8135-pwrap" for MT8135 SoCs
- "mediatek,mt8173-pwrap" for MT8173 SoCs
- "mediatek,mt8183-pwrap" for MT8183 SoCs
- "mediatek,mt8186-pwrap" for MT8186 SoCs
- "mediatek,mt8188-pwrap", "mediatek,mt8195-pwrap" for MT8188 SoCs
- "mediatek,mt8195-pwrap" for MT8195 SoCs
- "mediatek,mt8365-pwrap" for MT8365 SoCs
- "mediatek,mt8516-pwrap" for MT8516 SoCs
-- interrupts: IRQ for pwrap in SOC
-- reg-names: "pwrap" is required; "pwrap-bridge" is optional.
- "pwrap": Main registers base
- "pwrap-bridge": bridge base (IP Pairing)
-- reg: Must contain an entry for each entry in reg-names.
-- clock-names: Must include the following entries:
- "spi": SPI bus clock
- "wrap": Main module clock
- "sys": Optional system module clock
- "tmr": Optional timer module clock
-- clocks: Must contain an entry for each entry in clock-names.
-
-Optional properities:
-- reset-names: Some SoCs include the following entries:
- "pwrap"
- "pwrap-bridge" (IP Pairing)
-- resets: Must contain an entry for each entry in reset-names.
-- pmic: Using either MediaTek PMIC MFD as the child device of pwrap
- See the following for child node definitions:
- Documentation/devicetree/bindings/mfd/mt6397.txt
- or the regulator-only device as the child device of pwrap, such as MT6380.
- See the following definitions for such kinds of devices.
- Documentation/devicetree/bindings/regulator/mt6380-regulator.txt
-
-Example:
- pwrap: pwrap@1000f000 {
- compatible = "mediatek,mt8135-pwrap";
- reg = <0 0x1000f000 0 0x1000>,
- <0 0x11017000 0 0x1000>;
- reg-names = "pwrap", "pwrap-bridge";
- interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
- resets = <&infracfg MT8135_INFRA_PMIC_WRAP_RST>,
- <&pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST>;
- reset-names = "pwrap", "pwrap-bridge";
- clocks = <&clk26m>, <&clk26m>;
- clock-names = "spi", "wrap";
-
- pmic {
- compatible = "mediatek,mt6397";
- };
- };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml
new file mode 100644
index 0000000..ce7e20d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,dcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Data Capture and Compare
+
+maintainers:
+ - Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+
+description: |
+ DCC (Data Capture and Compare) is a DMA engine which is used to save
+ configuration data or system memory contents during catastrophic failure
+ or SW trigger. DCC is used to capture and store data for debugging purpose
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,sm8150-dcc
+ - qcom,sc7280-dcc
+ - qcom,sc7180-dcc
+ - qcom,sdm845-dcc
+ - const: qcom,dcc
+
+ reg:
+ items:
+ - description: DCC base
+ - description: DCC RAM base
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ dma@10a2000{
+ compatible = "qcom,sm8150-dcc", "qcom,dcc";
+ reg = <0x010a2000 0x1000>,
+ <0x010ad000 0x2000>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
deleted file mode 100644
index 1214192..0000000
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Qualcomm GLINK edge binding
-
-This binding describes a Qualcomm GLINK edge, a fifo based mechanism for
-communication between subsystem-pairs on various Qualcomm platforms. Two types
-of edges can be described by the binding; the GLINK RPM edge and a SMEM based
-edge.
-
-- compatible:
- Usage: required for glink-rpm
- Value type: <stringlist>
- Definition: must be "qcom,glink-rpm"
-
-- label:
- Usage: optional
- Value type: <string>
- Definition: should specify the subsystem name this edge corresponds to.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the IRQ used by the remote processor to
- signal this processor about communication related events
-
-- qcom,remote-pid:
- Usage: required for glink-smem
- Value type: <u32>
- Definition: specifies the identifier of the remote endpoint of this edge
-
-- qcom,rpm-msg-ram:
- Usage: required for glink-rpm
- Value type: <prop-encoded-array>
- Definition: handle to RPM message memory resource
-
-- mboxes:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the "rpm_hlos" mailbox in APCS, as described
- in mailbox/mailbox.txt
-
-= GLINK DEVICES
-Each subnode of the GLINK node represent function tied to a virtual
-communication channel. The name of the nodes are not important. The properties
-of these nodes are defined by the individual bindings for the specific function
-- but must contain the following property:
-
-- qcom,glink-channels:
- Usage: required
- Value type: <stringlist>
- Definition: a list of channels tied to this function, used for matching
- the function to a set of virtual channels
-
-- qcom,intents:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: a list of size,amount pairs describing what intents should
- be preallocated for this virtual channel. This can be used
- to tweak the default intents available for the channel to
- meet expectations of the remote.
-
-= EXAMPLE
-The following example represents the GLINK RPM node on a MSM8996 device, with
-the function for the "rpm_request" channel defined, which is used for
-regulators and root clocks.
-
- apcs_glb: mailbox@9820000 {
- compatible = "qcom,msm8996-apcs-hmss-global";
- reg = <0x9820000 0x1000>;
-
- #mbox-cells = <1>;
- };
-
- rpm_msg_ram: memory@68000 {
- compatible = "qcom,rpm-msg-ram";
- reg = <0x68000 0x6000>;
- };
-
- rpm-glink {
- compatible = "qcom,glink-rpm";
-
- interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
-
- qcom,rpm-msg-ram = <&rpm_msg_ram>;
-
- mboxes = <&apcs_glb 0>;
-
- rpm-requests {
- compatible = "qcom,rpm-msm8996";
- qcom,glink-channels = "rpm_requests";
-
- qcom,intents = <0x400 5
- 0x800 1>;
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml
new file mode 100644
index 0000000..aae9cf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,msm8976-ramp-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Ramp Controller
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The Ramp Controller is used to program the sequence ID for pulse
+ swallowing, enable sequences and link Sequence IDs (SIDs) for the
+ CPU cores on some Qualcomm SoCs.
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8976-ramp-controller
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ cpu-power-controller@b014000 {
+ compatible = "qcom,msm8976-ramp-controller";
+ reg = <0x0b014000 0x68>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
new file mode 100644
index 0000000..cf86368
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,pmic-glink.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PMIC GLINK firmware interface for battery management, USB
+ Type-C and other things.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ The PMIC GLINK service, running on a coprocessor on some modern Qualcomm
+ platforms and implement USB Type-C handling and battery management. This
+ binding describes the component in the OS used to communicate with the
+ firmware and connect it's resources to those described in the Devicetree,
+ particularly the USB Type-C controllers relationship with USB and DisplayPort
+ components.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,sc8180x-pmic-glink
+ - qcom,sc8280xp-pmic-glink
+ - qcom,sm8350-pmic-glink
+ - const: qcom,pmic-glink
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^connector@\d$':
+ $ref: /schemas/connector/usb-connector.yaml#
+
+ properties:
+ reg: true
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |+
+ pmic-glink {
+ compatible = "qcom,sc8280xp-pmic-glink", "qcom,pmic-glink";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&usb_role>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&ss_phy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ endpoint {
+ remote-endpoint = <&sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml
new file mode 100644
index 0000000..b00be9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,rpm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Resource Power Manager (RPM)
+
+description:
+ This driver is used to interface with the Resource Power Manager (RPM) found
+ in various Qualcomm platforms. The RPM allows each component in the system
+ to vote for state of the system resources, such as clocks, regulators and bus
+ frequencies.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,rpm-apq8064
+ - qcom,rpm-msm8660
+ - qcom,rpm-msm8960
+ - qcom,rpm-ipq8064
+ - qcom,rpm-mdm9615
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: ack
+ - const: err
+ - const: wakeup
+
+ qcom,ipc:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to a syscon node representing the APCS registers
+ - description: u32 representing offset to the register within the syscon
+ - description: u32 representing the ipc bit within the register
+ description:
+ Three entries specifying the outgoing ipc bit used for signaling the RPM.
+
+patternProperties:
+ "^regulators(-[01])?$":
+ type: object
+ $ref: /schemas/regulator/qcom,rpm-regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - qcom,ipc
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/qcom-rpm.h>
+
+ rpm@108000 {
+ compatible = "qcom,rpm-msm8960";
+ reg = <0x108000 0x1000>;
+ qcom,ipc = <&apcs 0x8 2>;
+
+ interrupts = <GIC_SPI 19 IRQ_TYPE_NONE>, <GIC_SPI 21 IRQ_TYPE_NONE>, <GIC_SPI 22 IRQ_TYPE_NONE>;
+ interrupt-names = "ack", "err", "wakeup";
+
+ regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+ vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+
+ s1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+
+ bias-pull-down;
+
+ qcom,switch-mode-frequency = <3200000>;
+ };
+
+ pm8921_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+
+ qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
index b246500..a4046ba 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
@@ -112,8 +112,9 @@
$ref: /schemas/power/qcom,rpmpd.yaml#
patternProperties:
- '-regulators$':
+ '^regulators(-[0-9])?$':
$ref: /schemas/regulator/qcom,rpmh-regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
index 11c0f4d..16fd67c 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -80,6 +80,7 @@
enum:
- qcom,rpm-apq8084
- qcom,rpm-msm8916
+ - qcom,rpm-msm8936
- qcom,rpm-msm8974
- qcom,rpm-msm8976
- qcom,rpm-msm8953
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml
new file mode 100644
index 0000000..12df33f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas,rzv2m-pwc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M External Power Sequence Controller (PWC)
+
+description: |+
+ The PWC IP found in the RZ/V2M family of chips comes with the below
+ capabilities
+ - external power supply on/off sequence generation
+ - on/off signal generation for the LPDDR4 core power supply (LPVDD)
+ - key input signals processing
+ - general-purpose output pins
+
+maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a09g011-pwc # RZ/V2M
+ - renesas,r9a09g055-pwc # RZ/V2MA
+ - const: renesas,rzv2m-pwc
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ renesas,rzv2m-pwc-power:
+ description: The PWC is used to control the system power supplies.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pwc: pwc@a3700000 {
+ compatible = "renesas,r9a09g011-pwc", "renesas,rzv2m-pwc";
+ reg = <0xa3700000 0x800>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ renesas,rzv2m-pwc-power;
+ };
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 2ed8cca..e697c92 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -20,6 +20,11 @@
- rockchip,rk3568-pipe-grf
- rockchip,rk3568-pipe-phy-grf
- rockchip,rk3568-usb2phy-grf
+ - rockchip,rk3588-bigcore0-grf
+ - rockchip,rk3588-bigcore1-grf
+ - rockchip,rk3588-ioc
+ - rockchip,rk3588-php-grf
+ - rockchip,rk3588-sys-grf
- rockchip,rk3588-pcie3-phy-grf
- rockchip,rk3588-pcie3-pipe-grf
- rockchip,rv1108-usbgrf
@@ -92,8 +97,9 @@
then:
properties:
edp-phy:
- description:
- Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+ type: object
+ $ref: /schemas/phy/rockchip,rk3288-dp-phy.yaml#
+ unevaluatedProperties: false
- if:
properties:
@@ -200,7 +206,7 @@
"usb2phy@[0-9a-f]+$":
type: object
- $ref: "/schemas/phy/phy-rockchip-inno-usb2.yaml#"
+ $ref: /schemas/phy/rockchip,inno-usb2phy.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 13bb8df..f7c141d 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -31,20 +31,28 @@
properties:
compatible:
- items:
- - enum:
- - samsung,exynos3250-pmu
- - samsung,exynos4210-pmu
- - samsung,exynos4412-pmu
- - samsung,exynos5250-pmu
- - samsung,exynos5260-pmu
- - samsung,exynos5410-pmu
- - samsung,exynos5420-pmu
- - samsung,exynos5433-pmu
- - samsung,exynos7-pmu
- - samsung,exynos850-pmu
- - samsung-s5pv210-pmu
- - const: syscon
+ oneOf:
+ - items:
+ - enum:
+ - samsung,exynos3250-pmu
+ - samsung,exynos4210-pmu
+ - samsung,exynos4412-pmu
+ - samsung,exynos5250-pmu
+ - samsung,exynos5260-pmu
+ - samsung,exynos5410-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - samsung,exynos7-pmu
+ - samsung,exynos850-pmu
+ - samsung-s5pv210-pmu
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos5250-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - const: simple-mfd
+ - const: syscon
reg:
maxItems: 1
@@ -64,6 +72,10 @@
minItems: 1
maxItems: 32
+ dp-phy:
+ $ref: /schemas/phy/samsung,dp-video-phy.yaml
+ unevaluatedProperties: false
+
interrupt-controller:
description:
Some PMUs are capable of behaving as an interrupt controller (mostly
@@ -74,6 +86,10 @@
Must be identical to the that of the parent interrupt controller.
const: 3
+ mipi-phy:
+ $ref: /schemas/phy/samsung,mipi-video-phy.yaml
+ unevaluatedProperties: false
+
reboot-mode:
$ref: /schemas/power/reset/syscon-reboot-mode.yaml
type: object
@@ -117,6 +133,23 @@
- clock-names
- clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5250-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ then:
+ properties:
+ dp-phy: true
+ mipi-phy: true
+ else:
+ properties:
+ dp-phy: false
+ mipi-phy: false
+
examples:
- |
#include <dt-bindings/clock/exynos5250.h>
@@ -130,4 +163,14 @@
#clock-cells = <1>;
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
+
+ dp-phy {
+ compatible = "samsung,exynos5250-dp-video-phy";
+ #phy-cells = <0>;
+ };
+
+ mipi-phy {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ #phy-cells = <1>;
+ };
};
diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
new file mode 100644
index 0000000..163e912
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/samsung/samsung,exynos-sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series System Registers (SYSREG)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - samsung,exynos3-sysreg
+ - samsung,exynos4-sysreg
+ - samsung,exynos5-sysreg
+ - tesla,fsd-cam-sysreg
+ - tesla,fsd-fsys0-sysreg
+ - tesla,fsd-fsys1-sysreg
+ - tesla,fsd-peric-sysreg
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos5433-cam0-sysreg
+ - samsung,exynos5433-cam1-sysreg
+ - samsung,exynos5433-disp-sysreg
+ - samsung,exynos5433-fsys-sysreg
+ - const: samsung,exynos5433-sysreg
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos5433-sysreg
+ - samsung,exynos850-sysreg
+ - samsung,exynosautov9-sysreg
+ - const: syscon
+ deprecated: true
+ - items:
+ - enum:
+ - samsung,exynos850-cmgp-sysreg
+ - samsung,exynos850-peri-sysreg
+ - const: samsung,exynos850-sysreg
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynosautov9-fsys2-sysreg
+ - samsung,exynosautov9-peric0-sysreg
+ - samsung,exynosautov9-peric1-sysreg
+ - const: samsung,exynosautov9-sysreg
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos850-cmgp-sysreg
+ - samsung,exynos850-peri-sysreg
+ - samsung,exynos850-sysreg
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+additionalProperties: false
+
+examples:
+ - |
+ system-controller@10010000 {
+ compatible = "samsung,exynos4-sysreg", "syscon";
+ reg = <0x10010000 0x400>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml
new file mode 100644
index 0000000..32d9cc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-adamv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier ADAMV block
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ ADAMV block implemented on Socionext UniPhier SoCs is an analog signal
+ amplifier that is a part of the external video and audio I/O system.
+
+ This block is defined for controlling audio I/O reset only.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld11-adamv
+ - socionext,uniphier-ld20-adamv
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@57920000 {
+ compatible = "socionext,uniphier-ld20-adamv",
+ "simple-mfd", "syscon";
+ reg = <0x57920000 0x1000>;
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-adamv-reset";
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml
new file mode 100644
index 0000000..09f861c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-ahci-glue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC AHCI glue layer
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ AHCI glue layer implemented on Socionext UniPhier SoCs is a sideband
+ logic handling signals to AHCI host controller inside AHCI component.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-pro4-ahci-glue
+ - socionext,uniphier-pxs2-ahci-glue
+ - socionext,uniphier-pxs3-ahci-glue
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^reset-controller@[0-9a-f]+$":
+ $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml#
+
+ "phy@[0-9a-f]+$":
+ $ref: /schemas/phy/socionext,uniphier-ahci-phy.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ sata-controller@65700000 {
+ compatible = "socionext,uniphier-pxs3-ahci-glue", "simple-mfd";
+ reg = <0x65b00000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x65700000 0x100>;
+
+ reset-controller@0 {
+ compatible = "socionext,uniphier-pxs3-ahci-reset";
+ reg = <0x0 0x4>;
+ clock-names = "link";
+ clocks = <&sys_clk 28>;
+ reset-names = "link";
+ resets = <&sys_rst 28>;
+ #reset-cells = <1>;
+ };
+
+ phy@10 {
+ compatible = "socionext,uniphier-pxs3-ahci-phy";
+ reg = <0x10 0x10>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 28>, <&sys_clk 30>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 28>, <&sys_rst 30>;
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml
new file mode 100644
index 0000000..bd0def7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-dwc3-glue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC DWC3 USB3.0 glue layer
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ DWC3 USB3.0 glue layer implemented on Socionext UniPhier SoCs is
+ a sideband logic handling signals to DWC3 host controller inside
+ USB3.0 component.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-pro4-dwc3-glue
+ - socionext,uniphier-pro5-dwc3-glue
+ - socionext,uniphier-pxs2-dwc3-glue
+ - socionext,uniphier-ld20-dwc3-glue
+ - socionext,uniphier-pxs3-dwc3-glue
+ - socionext,uniphier-nx1-dwc3-glue
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^reset-controller@[0-9a-f]+$":
+ $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml#
+
+ "^regulator@[0-9a-f]+$":
+ $ref: /schemas/regulator/socionext,uniphier-regulator.yaml#
+
+ "^phy@[0-9a-f]+$":
+ oneOf:
+ - $ref: /schemas/phy/socionext,uniphier-usb3hs-phy.yaml#
+ - $ref: /schemas/phy/socionext,uniphier-usb3ss-phy.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@65b00000 {
+ compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd";
+ reg = <0x65b00000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x65b00000 0x400>;
+
+ reset-controller@0 {
+ compatible = "socionext,uniphier-ld20-usb3-reset";
+ reg = <0x0 0x4>;
+ #reset-cells = <1>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
+ };
+
+ regulator@100 {
+ compatible = "socionext,uniphier-ld20-usb3-regulator";
+ reg = <0x100 0x10>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
+ };
+
+ phy@200 {
+ compatible = "socionext,uniphier-ld20-usb3-hsphy";
+ reg = <0x200 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 16>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 16>;
+ };
+
+ phy@300 {
+ compatible = "socionext,uniphier-ld20-usb3-ssphy";
+ reg = <0x300 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 18>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 18>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml
new file mode 100644
index 0000000..2cc38bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-mioctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier media I/O block (MIO) controller
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ Media I/O block implemented on Socionext UniPhier SoCs is a legacy
+ integrated component of the stream type peripherals including USB2.0,
+ SD/eMMC, and MIO-DMAC.
+ Media I/O block has a common logic to control the component.
+
+ Recent SoCs have SD interface logic specialized only for SD functions
+ as a subset of media I/O block. See socionext,uniphier-sdctrl.yaml.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-mioctrl
+ - socionext,uniphier-pro4-mioctrl
+ - socionext,uniphier-sld8-mioctrl
+ - socionext,uniphier-ld11-mioctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@5b3e0000 {
+ compatible = "socionext,uniphier-ld11-mioctrl",
+ "simple-mfd", "syscon";
+ reg = <0x5b3e0000 0x800>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld11-mio-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld11-mio-reset";
+ #reset-cells = <1>;
+ resets = <&sys_rst 7>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml
new file mode 100644
index 0000000..0adcffe
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-perictrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier peripheral block controller
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ Peripheral block implemented on Socionext UniPhier SoCs is an integrated
+ component of the peripherals including UART, I2C/FI2C, and SCSSI.
+ Peripheral block controller is a logic to control the component.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-perictrl
+ - socionext,uniphier-pro4-perictrl
+ - socionext,uniphier-pro5-perictrl
+ - socionext,uniphier-pxs2-perictrl
+ - socionext,uniphier-sld8-perictrl
+ - socionext,uniphier-ld11-perictrl
+ - socionext,uniphier-ld20-perictrl
+ - socionext,uniphier-pxs3-perictrl
+ - socionext,uniphier-nx1-perictrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@59820000 {
+ compatible = "socionext,uniphier-ld20-perictrl",
+ "simple-mfd", "syscon";
+ reg = <0x59820000 0x200>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld20-peri-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-peri-reset";
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml
new file mode 100644
index 0000000..cb3b0d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-sdctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SD interface logic
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ SD interface logic implemented on Socionext UniPhier SoCs is
+ attached outside SDHC, and has some SD related functions such as
+ clock control, reset control, mode switch, and so on.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-pro5-sdctrl
+ - socionext,uniphier-pxs2-sdctrl
+ - socionext,uniphier-ld11-sdctrl
+ - socionext,uniphier-ld20-sdctrl
+ - socionext,uniphier-pxs3-sdctrl
+ - socionext,uniphier-nx1-sdctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@59810000 {
+ compatible = "socionext,uniphier-ld20-sdctrl",
+ "simple-mfd", "syscon";
+ reg = <0x59810000 0x400>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld20-sd-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-sd-reset";
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml
new file mode 100644
index 0000000..1341544
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue-debug.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC-glue logic debug part
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ SoC-glue logic debug part implemented on Socionext UniPhier SoCs is
+ a collection of miscellaneous function registers handling signals outside
+ system components for debug and monitor use.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-soc-glue-debug
+ - socionext,uniphier-pro4-soc-glue-debug
+ - socionext,uniphier-pro5-soc-glue-debug
+ - socionext,uniphier-pxs2-soc-glue-debug
+ - socionext,uniphier-sld8-soc-glue-debug
+ - socionext,uniphier-ld11-soc-glue-debug
+ - socionext,uniphier-ld20-soc-glue-debug
+ - socionext,uniphier-pxs3-soc-glue-debug
+ - socionext,uniphier-nx1-soc-glue-debug
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^efuse@[0-9a-f]+$":
+ $ref: /schemas/nvmem/socionext,uniphier-efuse.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@5f900000 {
+ compatible = "socionext,uniphier-pxs2-soc-glue-debug",
+ "simple-mfd", "syscon";
+ reg = <0x5f900000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x5f900000 0x2000>;
+
+ efuse@100 {
+ compatible = "socionext,uniphier-efuse";
+ reg = <0x100 0x28>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml
new file mode 100644
index 0000000..7845dcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC-glue logic
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ SoC-glue logic implemented on Socionext UniPhier SoCs is a collection of
+ miscellaneous function registers handling signals outside system components.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-soc-glue
+ - socionext,uniphier-pro4-soc-glue
+ - socionext,uniphier-pro5-soc-glue
+ - socionext,uniphier-pxs2-soc-glue
+ - socionext,uniphier-sld8-soc-glue
+ - socionext,uniphier-ld11-soc-glue
+ - socionext,uniphier-ld20-soc-glue
+ - socionext,uniphier-pxs3-soc-glue
+ - socionext,uniphier-nx1-soc-glue
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ pinctrl:
+ $ref: /schemas/pinctrl/socionext,uniphier-pinctrl.yaml#
+
+ usb-hub:
+ $ref: /schemas/phy/socionext,uniphier-usb2-phy.yaml#
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - socionext,uniphier-pro4-soc-glue
+ - socionext,uniphier-ld11-soc-glue
+ then:
+ properties:
+ usb-hub: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-pro4-soc-glue
+ then:
+ properties:
+ clock-controller: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@5f800000 {
+ compatible = "socionext,uniphier-pro4-soc-glue",
+ "simple-mfd", "syscon";
+ reg = <0x5f800000 0x2000>;
+
+ pinctrl {
+ compatible = "socionext,uniphier-pro4-pinctrl";
+ };
+
+ usb-hub {
+ compatible = "socionext,uniphier-pro4-usb2-phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ clock-controller {
+ compatible = "socionext,uniphier-pro4-sg-clock";
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml
new file mode 100644
index 0000000..3acb142
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-sysctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier system controller
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ System controller implemented on Socionext UniPhier SoCs has multiple
+ functions such as clock control, reset control, internal watchdog timer,
+ thermal management, and so on.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-sysctrl
+ - socionext,uniphier-pro4-sysctrl
+ - socionext,uniphier-pro5-sysctrl
+ - socionext,uniphier-pxs2-sysctrl
+ - socionext,uniphier-sld8-sysctrl
+ - socionext,uniphier-ld11-sysctrl
+ - socionext,uniphier-ld20-sysctrl
+ - socionext,uniphier-pxs3-sysctrl
+ - socionext,uniphier-nx1-sysctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+ watchdog:
+ $ref: /schemas/watchdog/socionext,uniphier-wdt.yaml#
+
+ thermal-sensor:
+ $ref: /schemas/thermal/socionext,uniphier-thermal.yaml#
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-ld4-sysctrl
+ then:
+ properties:
+ watchdog: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - socionext,uniphier-ld4-sysctrl
+ - socionext,uniphier-pro4-sysctrl
+ - socionext,uniphier-sld8-sysctrl
+ - socionext,uniphier-ld11-sysctrl
+ then:
+ properties:
+ thermal-sensor: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ syscon@61840000 {
+ compatible = "socionext,uniphier-ld20-sysctrl",
+ "simple-mfd", "syscon";
+ reg = <0x61840000 0x4000>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld20-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-reset";
+ #reset-cells = <1>;
+ };
+
+ watchdog {
+ compatible = "socionext,uniphier-wdt";
+ };
+
+ thermal-sensor {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ #thermal-sensor-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
index ddea3d4..22cf900 100644
--- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
@@ -25,6 +25,9 @@
The Ring Accelerator is a hardware module that is responsible for accelerating
management of the packet queues. The K3 SoCs can have more than one RA instances
+allOf:
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
properties:
compatible:
items:
@@ -54,14 +57,6 @@
$ref: /schemas/types.yaml#/definitions/uint32
description: TI-SCI RM subtype for GP ring range
- ti,sci:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: phandle on TI-SCI compatible System controller node
-
- ti,sci-dev-id:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TI-SCI device id of the ring accelerator
-
required:
- compatible
- reg
@@ -72,7 +67,7 @@
- ti,sci
- ti,sci-dev-id
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/adi,adau7002.txt b/Documentation/devicetree/bindings/sound/adi,adau7002.txt
deleted file mode 100644
index f144ee1..0000000
--- a/Documentation/devicetree/bindings/sound/adi,adau7002.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Analog Devices ADAU7002 Stereo PDM-to-I2S/TDM Converter
-
-Required properties:
-
- - compatible: Must be "adi,adau7002"
-
-Optional properties:
-
- - IOVDD-supply: Phandle and specifier for the power supply providing the IOVDD
- supply as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
- If this property is not present it is assumed that the supply pin is
- hardwired to always on.
-
-Example:
- adau7002: pdm-to-i2s {
- compatible = "adi,adau7002";
- IOVDD-supply = <&supply>;
- };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau7002.yaml b/Documentation/devicetree/bindings/sound/adi,adau7002.yaml
new file mode 100644
index 0000000..fcca0fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau7002.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau7002.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADAU7002 Stereo PDM-to-I2S/TDM Converter
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: adi,adau7002
+
+ IOVDD-supply:
+ description:
+ IOVDD power supply, if skipped then it is assumed that the supply pin is
+ hardwired to always on.
+
+ wakeup-delay-ms:
+ description:
+ Delay after power up needed for device to settle.
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ audio-codec {
+ compatible = "adi,adau7002";
+ IOVDD-supply = <&pp1800_l15a>;
+ #sound-dai-cells = <0>;
+ wakeup-delay-ms = <80>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/ak4613.yaml b/Documentation/devicetree/bindings/sound/ak4613.yaml
index 0105746..75e1341 100644
--- a/Documentation/devicetree/bindings/sound/ak4613.yaml
+++ b/Documentation/devicetree/bindings/sound/ak4613.yaml
@@ -25,6 +25,13 @@
"#sound-dai-cells":
const: 0
+ ports:
+ $ref: audio-graph-port.yaml#/definitions/ports
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
patternProperties:
"^asahi-kasei,in[1-2]-single-end$":
description: Input Pin 1 - 2.
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt
deleted file mode 100644
index fa4545e..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* Amlogic Audio FIFO controllers
-
-Required properties:
-- compatible: 'amlogic,axg-toddr' or
- 'amlogic,axg-toddr' or
- 'amlogic,g12a-frddr' or
- 'amlogic,g12a-toddr' or
- 'amlogic,sm1-frddr' or
- 'amlogic,sm1-toddr'
-- reg: physical base address of the controller and length of memory
- mapped region.
-- interrupts: interrupt specifier for the fifo.
-- clocks: phandle to the fifo peripheral clock provided by the audio
- clock controller.
-- resets: list of reset phandle, one for each entry reset-names.
-- reset-names: should contain the following:
- * "arb" : memory ARB line (required)
- * "rst" : dedicated device reset line (optional)
-- #sound-dai-cells: must be 0.
-- amlogic,fifo-depth: The size of the controller's fifo in bytes. This
- is useful for determining certain configuration such
- as the flush threshold of the fifo
-
-Example of FRDDR A on the A113 SoC:
-
-frddr_a: audio-controller@1c0 {
- compatible = "amlogic,axg-frddr";
- reg = <0x0 0x1c0 0x0 0x1c>;
- #sound-dai-cells = <0>;
- interrupts = <GIC_SPI 88 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clkc_audio AUD_CLKID_FRDDR_A>;
- resets = <&arb AXG_ARB_FRDDR_A>;
- fifo-depth = <512>;
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml
new file mode 100644
index 0000000..b1b48d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-fifo.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic AXG Audio FIFO controllers
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,axg-toddr
+ - amlogic,axg-frddr
+ - items:
+ - enum:
+ - amlogic,g12a-toddr
+ - amlogic,sm1-toddr
+ - const: amlogic,axg-toddr
+ - items:
+ - enum:
+ - amlogic,g12a-frddr
+ - amlogic,sm1-frddr
+ - const: amlogic,axg-frddr
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+
+ amlogic,fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Size of the controller's fifo in bytes
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - interrupts
+ - resets
+ - amlogic,fifo-depth
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-toddr
+ - amlogic,sm1-toddr
+ - amlogic,g12a-frddr
+ - amlogic,sm1-frddr
+
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ items:
+ - const: arb
+ - const: rst
+ required:
+ - reset-names
+
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ const: arb
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/amlogic,meson-axg-audio-arb.h>
+ #include <dt-bindings/reset/amlogic,meson-g12a-audio-reset.h>
+
+ audio-controller@1c0 {
+ compatible = "amlogic,g12a-frddr", "amlogic,axg-frddr";
+ reg = <0x1c0 0x1c>;
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_FRDDR_A>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_EDGE_RISING>;
+ resets = <&arb>, <&clkc_audio AUD_RESET_FRDDR_A>;
+ reset-names = "arb", "rst";
+ amlogic,fifo-depth = <512>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt
deleted file mode 100644
index 7168781..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Amlogic Audio PDM input
-
-Required properties:
-- compatible: 'amlogic,axg-pdm' or
- 'amlogic,g12a-pdm' or
- 'amlogic,sm1-pdm'
-- reg: physical base address of the controller and length of memory
- mapped region.
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "dclk" : pdm digital clock
- * "sysclk" : dsp system clock
-- #sound-dai-cells: must be 0.
-
-Optional property:
-- resets: phandle to the dedicated reset line of the pdm input.
-
-Example of PDM on the A113 SoC:
-
-pdm: audio-controller@ff632000 {
- compatible = "amlogic,axg-pdm";
- reg = <0x0 0xff632000 0x0 0x34>;
- #sound-dai-cells = <0>;
- clocks = <&clkc_audio AUD_CLKID_PDM>,
- <&clkc_audio AUD_CLKID_PDM_DCLK>,
- <&clkc_audio AUD_CLKID_PDM_SYSCLK>;
- clock-names = "pclk", "dclk", "sysclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml
new file mode 100644
index 0000000..df21dd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-pdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG PDM input
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12a-pdm
+ - amlogic,sm1-pdm
+ - const: amlogic,axg-pdm
+ - const: amlogic,axg-pdm
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: PDM digital clock
+ - description: DSP system clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: dclk
+ - const: sysclk
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-pdm
+ - amlogic,sm1-pdm
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+
+ audio-controller@ff632000 {
+ compatible = "amlogic,axg-pdm";
+ reg = <0xff632000 0x34>;
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_PDM>,
+ <&clkc_audio AUD_CLKID_PDM_DCLK>,
+ <&clkc_audio AUD_CLKID_PDM_SYSCLK>;
+ clock-names = "pclk", "dclk", "sysclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt
deleted file mode 100644
index 80b4112..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt
+++ /dev/null
@@ -1,124 +0,0 @@
-Amlogic AXG sound card:
-
-Required properties:
-
-- compatible: "amlogic,axg-sound-card"
-- model : User specified audio sound card name, one string
-
-Optional properties:
-
-- audio-aux-devs : List of phandles pointing to auxiliary devices
-- audio-widgets : Please refer to widgets.txt.
-- audio-routing : A list of the connections between audio components.
-
-Subnodes:
-
-- dai-link: Container for dai-link level properties and the CODEC
- sub-nodes. There should be at least one (and probably more)
- subnode of this type.
-
-Required dai-link properties:
-
-- sound-dai: phandle and port of the CPU DAI.
-
-Required TDM Backend dai-link properties:
-- dai-format : CPU/CODEC common audio format
-
-Optional TDM Backend dai-link properties:
-- dai-tdm-slot-rx-mask-{0,1,2,3}: Receive direction slot masks
-- dai-tdm-slot-tx-mask-{0,1,2,3}: Transmit direction slot masks
- When omitted, mask is assumed to have to no
- slots. A valid must have at one slot, so at
- least one these mask should be provided with
- an enabled slot.
-- dai-tdm-slot-num : Please refer to tdm-slot.txt.
- If omitted, slot number is set to accommodate the largest
- mask provided.
-- dai-tdm-slot-width : Please refer to tdm-slot.txt. default to 32 if omitted.
-- mclk-fs : Multiplication factor between stream rate and mclk
-
-Backend dai-link subnodes:
-
-- codec: dai-link representing backend links should have at least one subnode.
- One subnode for each codec of the dai-link.
- dai-link representing frontend links have no codec, therefore have no
- subnodes
-
-Required codec subnodes properties:
-
-- sound-dai: phandle and port of the CODEC DAI.
-
-Optional codec subnodes properties:
-
-- dai-tdm-slot-tx-mask : Please refer to tdm-slot.txt.
-- dai-tdm-slot-rx-mask : Please refer to tdm-slot.txt.
-
-Example:
-
-sound {
- compatible = "amlogic,axg-sound-card";
- model = "AXG-S420";
- audio-aux-devs = <&tdmin_a>, <&tdmout_c>;
- audio-widgets = "Line", "Lineout",
- "Line", "Linein",
- "Speaker", "Speaker1 Left",
- "Speaker", "Speaker1 Right";
- "Speaker", "Speaker2 Left",
- "Speaker", "Speaker2 Right";
- audio-routing = "TDMOUT_C IN 0", "FRDDR_A OUT 2",
- "SPDIFOUT IN 0", "FRDDR_A OUT 3",
- "TDM_C Playback", "TDMOUT_C OUT",
- "TDMIN_A IN 2", "TDM_C Capture",
- "TDMIN_A IN 5", "TDM_C Loopback",
- "TODDR_A IN 0", "TDMIN_A OUT",
- "Lineout", "Lineout AOUTL",
- "Lineout", "Lineout AOUTR",
- "Speaker1 Left", "SPK1 OUT_A",
- "Speaker2 Left", "SPK2 OUT_A",
- "Speaker1 Right", "SPK1 OUT_B",
- "Speaker2 Right", "SPK2 OUT_B",
- "Linein AINL", "Linein",
- "Linein AINR", "Linein";
-
- dai-link@0 {
- sound-dai = <&frddr_a>;
- };
-
- dai-link@1 {
- sound-dai = <&toddr_a>;
- };
-
- dai-link@2 {
- sound-dai = <&tdmif_c>;
- dai-format = "i2s";
- dai-tdm-slot-tx-mask-2 = <1 1>;
- dai-tdm-slot-tx-mask-3 = <1 1>;
- dai-tdm-slot-rx-mask-1 = <1 1>;
- mclk-fs = <256>;
-
- codec@0 {
- sound-dai = <&lineout>;
- };
-
- codec@1 {
- sound-dai = <&speaker_amp1>;
- };
-
- codec@2 {
- sound-dai = <&speaker_amp2>;
- };
-
- codec@3 {
- sound-dai = <&linein>;
- };
-
- };
-
- dai-link@3 {
- sound-dai = <&spdifout>;
-
- codec {
- sound-dai = <&spdif_dit>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
new file mode 100644
index 0000000..bf12345
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-sound-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic AXG sound card
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ const: amlogic,axg-sound-card
+
+ audio-aux-devs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: list of auxiliary devices
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+
+ audio-widgets:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list off component DAPM widget. Each entry is a pair of strings,
+ the first being the widget type, the second being the widget name
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+patternProperties:
+ "^dai-link-[0-9]+$":
+ type: object
+ additionalProperties: false
+ description:
+ Container for dai-link level properties and the CODEC sub-nodes.
+ There should be at least one (and probably more) subnode of this type
+
+ properties:
+ dai-format:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ i2s, left-j, dsp_a ]
+
+ dai-tdm-slot-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of slots in use. If omitted, slot number is set to
+ accommodate the largest mask provided.
+ maximum: 32
+
+ dai-tdm-slot-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Width in bits for each slot
+ enum: [ 8, 16, 20, 24, 32 ]
+ default: 32
+
+ mclk-fs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Multiplication factor between the frame rate and master clock
+ rate
+
+ sound-dai:
+ maxItems: 1
+ description: phandle of the CPU DAI
+
+ patternProperties:
+ "^dai-tdm-slot-(t|r)x-mask-[0-3]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 32
+ description:
+ Transmit and receive cpu slot masks of each TDM lane
+ When omitted, mask is assumed to have to no slots. A valid
+ interface must have at least one slot, so at least one these
+ mask should be provided with an enabled slot.
+
+ "^codec(-[0-9]+)?$":
+ type: object
+ additionalProperties: false
+ description:
+ dai-link representing backend links should have at least one subnode.
+ One subnode for each codec of the dai-link. dai-link representing
+ frontend links have no codec, therefore have no subnodes
+
+ properties:
+ sound-dai:
+ maxItems: 1
+ description: phandle of the codec DAI
+
+ patternProperties:
+ "^dai-tdm-slot-(t|r)x-mask$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 32
+ description: Transmit and receive codec slot masks
+
+ required:
+ - sound-dai
+
+ required:
+ - sound-dai
+
+required:
+ - model
+ - dai-link-0
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "AXG-S420";
+ audio-aux-devs = <&tdmin_a>, <&tdmout_c>;
+ audio-widgets = "Line", "Lineout",
+ "Line", "Linein",
+ "Speaker", "Speaker1 Left",
+ "Speaker", "Speaker1 Right",
+ "Speaker", "Speaker2 Left",
+ "Speaker", "Speaker2 Right";
+ audio-routing = "TDMOUT_C IN 0", "FRDDR_A OUT 2",
+ "SPDIFOUT IN 0", "FRDDR_A OUT 3",
+ "TDM_C Playback", "TDMOUT_C OUT",
+ "TDMIN_A IN 2", "TDM_C Capture",
+ "TDMIN_A IN 5", "TDM_C Loopback",
+ "TODDR_A IN 0", "TDMIN_A OUT",
+ "Lineout", "Lineout AOUTL",
+ "Lineout", "Lineout AOUTR",
+ "Speaker1 Left", "SPK1 OUT_A",
+ "Speaker2 Left", "SPK2 OUT_A",
+ "Speaker1 Right", "SPK1 OUT_B",
+ "Speaker2 Right", "SPK2 OUT_B",
+ "Linein AINL", "Linein",
+ "Linein AINR", "Linein";
+
+ dai-link-0 {
+ sound-dai = <&frddr_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&toddr_a>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&tdmif_c>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ dai-tdm-slot-rx-mask-1 = <1 1>;
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&lineout>;
+ };
+
+ codec-1 {
+ sound-dai = <&speaker_amp1>;
+ };
+
+ codec-2 {
+ sound-dai = <&speaker_amp2>;
+ };
+
+ codec-3 {
+ sound-dai = <&linein>;
+ };
+ };
+
+ dai-link-3 {
+ sound-dai = <&spdifout>;
+
+ codec {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt
deleted file mode 100644
index df92a4e..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Amlogic Audio SPDIF Input
-
-Required properties:
-- compatible: 'amlogic,axg-spdifin' or
- 'amlogic,g12a-spdifin' or
- 'amlogic,sm1-spdifin'
-- interrupts: interrupt specifier for the spdif input.
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "refclk" : spdif input reference clock
-- #sound-dai-cells: must be 0.
-
-Optional property:
-- resets: phandle to the dedicated reset line of the spdif input.
-
-Example on the A113 SoC:
-
-spdifin: audio-controller@400 {
- compatible = "amlogic,axg-spdifin";
- reg = <0x0 0x400 0x0 0x30>;
- #sound-dai-cells = <0>;
- interrupts = <GIC_SPI 87 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clkc_audio AUD_CLKID_SPDIFIN>,
- <&clkc_audio AUD_CLKID_SPDIFIN_CLK>;
- clock-names = "pclk", "refclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml
new file mode 100644
index 0000000..a0bd7a5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-spdifin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG SPDIF Input
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,axg-spdifin
+ - items:
+ - enum:
+ - amlogic,g12a-spdifin
+ - amlogic,sm1-spdifin
+ - const: amlogic,axg-spdifin
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: SPDIF input reference clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: refclk
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+ - interrupts
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-spdifin
+ - amlogic,sm1-spdifin
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ audio-controller@400 {
+ compatible = "amlogic,axg-spdifin";
+ reg = <0x400 0x30>;
+ #sound-dai-cells = <0>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc_audio AUD_CLKID_SPDIFIN>,
+ <&clkc_audio AUD_CLKID_SPDIFIN_CLK>;
+ clock-names = "pclk", "refclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt
deleted file mode 100644
index 28381dd..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Amlogic Audio SPDIF Output
-
-Required properties:
-- compatible: 'amlogic,axg-spdifout' or
- 'amlogic,g12a-spdifout' or
- 'amlogic,sm1-spdifout'
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "mclk" : master clock
-- #sound-dai-cells: must be 0.
-
-Optional property:
-- resets: phandle to the dedicated reset line of the spdif output.
-
-Example on the A113 SoC:
-
-spdifout: audio-controller@480 {
- compatible = "amlogic,axg-spdifout";
- reg = <0x0 0x480 0x0 0x50>;
- #sound-dai-cells = <0>;
- clocks = <&clkc_audio AUD_CLKID_SPDIFOUT>,
- <&clkc_audio AUD_CLKID_SPDIFOUT_CLK>;
- clock-names = "pclk", "mclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml
new file mode 100644
index 0000000..15be8da
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-spdifout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG SPDIF Output
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,axg-spdifout
+ - items:
+ - enum:
+ - amlogic,g12a-spdifout
+ - amlogic,sm1-spdifout
+ - const: amlogic,axg-spdifout
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: SPDIF output master clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: mclk
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-spdifout
+ - amlogic,sm1-spdifout
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+
+ audio-controller@480 {
+ compatible = "amlogic,axg-spdifout";
+ reg = <0x480 0x50>;
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_SPDIFOUT>,
+ <&clkc_audio AUD_CLKID_SPDIFOUT_CLK>;
+ clock-names = "pclk", "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt
deleted file mode 100644
index 5996c0c..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Amlogic Audio TDM formatters
-
-Required properties:
-- compatible: 'amlogic,axg-tdmin' or
- 'amlogic,axg-tdmout' or
- 'amlogic,g12a-tdmin' or
- 'amlogic,g12a-tdmout' or
- 'amlogic,sm1-tdmin' or
- 'amlogic,sm1-tdmout
-- reg: physical base address of the controller and length of memory
- mapped region.
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "sclk" : bit clock.
- * "sclk_sel" : bit clock input multiplexer.
- * "lrclk" : sample clock
- * "lrclk_sel": sample clock input multiplexer
-
-Optional property:
-- resets: phandle to the dedicated reset line of the tdm formatter.
-
-Example of TDMOUT_A on the S905X2 SoC:
-
-tdmout_a: audio-controller@500 {
- compatible = "amlogic,axg-tdmout";
- reg = <0x0 0x500 0x0 0x40>;
- resets = <&clkc_audio AUD_RESET_TDMOUT_A>;
- clocks = <&clkc_audio AUD_CLKID_TDMOUT_A>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK_SEL>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>;
- clock-names = "pclk", "sclk", "sclk_sel",
- "lrclk", "lrclk_sel";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml
new file mode 100644
index 0000000..719ca8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-tdm-formatters.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG TDM formatters
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,g12a-tdmout
+ - amlogic,sm1-tdmout
+ - amlogic,axg-tdmout
+ - amlogic,g12a-tdmin
+ - amlogic,sm1-tdmin
+ - amlogic,axg-tdmin
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: Bit clock
+ - description: Bit clock input multiplexer
+ - description: Sample clock
+ - description: Sample clock input multiplexer
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: sclk
+ - const: sclk_sel
+ - const: lrclk
+ - const: lrclk_sel
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: component-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-tdmin
+ - amlogic,sm1-tdmin
+ - amlogic,g12a-tdmout
+ - amlogic,sm1-tdmout
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ #include <dt-bindings/reset/amlogic,meson-g12a-audio-reset.h>
+
+ audio-controller@500 {
+ compatible = "amlogic,g12a-tdmout";
+ reg = <0x500 0x40>;
+ resets = <&clkc_audio AUD_RESET_TDMOUT_A>;
+ clocks = <&clkc_audio AUD_CLKID_TDMOUT_A>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK_SEL>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>;
+ clock-names = "pclk", "sclk", "sclk_sel",
+ "lrclk", "lrclk_sel";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt
deleted file mode 100644
index cabfb26..0000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic Audio TDM Interfaces
-
-Required properties:
-- compatible: 'amlogic,axg-tdm-iface'
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "sclk" : bit clock.
- * "lrclk": sample clock
- * "mclk" : master clock
- -> optional if the interface is in clock slave mode.
-- #sound-dai-cells: must be 0.
-
-Example of TDM_A on the A113 SoC:
-
-tdmif_a: audio-controller@0 {
- compatible = "amlogic,axg-tdm-iface";
- #sound-dai-cells = <0>;
- clocks = <&clkc_audio AUD_CLKID_MST_A_MCLK>,
- <&clkc_audio AUD_CLKID_MST_A_SCLK>,
- <&clkc_audio AUD_CLKID_MST_A_LRCLK>;
- clock-names = "mclk", "sclk", "lrclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml
new file mode 100644
index 0000000..320f000
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-tdm-iface.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio TDM Interfaces
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: amlogic,axg-tdm-iface
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ minItems: 2
+ items:
+ - description: Bit clock
+ - description: Sample clock
+ - description: Master clock #optional
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: sclk
+ - const: lrclk
+ - const: mclk
+
+required:
+ - compatible
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+
+ audio-controller {
+ compatible = "amlogic,axg-tdm-iface";
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_MST_A_SCLK>,
+ <&clkc_audio AUD_CLKID_MST_A_LRCLK>,
+ <&clkc_audio AUD_CLKID_MST_A_MCLK>;
+ clock-names = "sclk", "lrclk", "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
index 5b8d592..b358fd6 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
@@ -62,7 +62,7 @@
description: phandle of the CPU DAI
patternProperties:
- "^codec-[0-9]+$":
+ "^codec(-[0-9]+)?$":
type: object
additionalProperties: false
description: |-
diff --git a/Documentation/devicetree/bindings/sound/apple,mca.yaml b/Documentation/devicetree/bindings/sound/apple,mca.yaml
index 40e3a20..5c6ec08 100644
--- a/Documentation/devicetree/bindings/sound/apple,mca.yaml
+++ b/Documentation/devicetree/bindings/sound/apple,mca.yaml
@@ -23,6 +23,7 @@
- enum:
- apple,t6000-mca
- apple,t8103-mca
+ - apple,t8112-mca
- const: apple,mca
reg:
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
index f5b8b6d..6b4e02a 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
@@ -11,32 +11,24 @@
select: false
-allOf:
- - $ref: /schemas/graph.yaml#/$defs/port-base
+definitions:
+ port-base:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ properties:
+ convert-rate:
+ $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate"
+ convert-channels:
+ $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels"
+ convert-sample-format:
+ $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format"
+ mclk-fs:
+ $ref: "simple-card.yaml#/definitions/mclk-fs"
-properties:
- prefix:
- description: "device name prefix"
- $ref: /schemas/types.yaml#/definitions/string
- convert-rate:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate"
- convert-channels:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels"
- convert-sample-format:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format"
-
-patternProperties:
- "^endpoint(@[0-9a-f]+)?":
+ endpoint-base:
$ref: /schemas/graph.yaml#/$defs/endpoint-base
- unevaluatedProperties: false
-
properties:
mclk-fs:
- description: |
- Multiplication factor between stream rate and codec mclk.
- When defined, mclk-fs property defined in dai-link sub nodes are
- ignored.
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: "simple-card.yaml#/definitions/mclk-fs"
frame-inversion:
description: dai-link uses frame clock inversion
$ref: /schemas/types.yaml#/definitions/flag
@@ -53,6 +45,15 @@
oneOf:
- $ref: /schemas/types.yaml#/definitions/flag
- $ref: /schemas/types.yaml#/definitions/phandle
+ clocks:
+ description: Indicates system clock
+ $ref: /schemas/types.yaml#/definitions/phandle
+ system-clock-frequency:
+ $ref: "simple-card.yaml#/definitions/system-clock-frequency"
+ system-clock-direction-out:
+ $ref: "simple-card.yaml#/definitions/system-clock-direction-out"
+ system-clock-fixed:
+ $ref: "simple-card.yaml#/definitions/system-clock-fixed"
dai-format:
description: audio format.
@@ -100,4 +101,24 @@
minimum: 1
maximum: 64
+ ports:
+ $ref: "#/definitions/port-base"
+ unevaluatedProperties: false
+ patternProperties:
+ "^port(@[0-9a-f]+)?$":
+ $ref: "#/definitions/port-base"
+ unevaluatedProperties: false
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: "#/definitions/endpoint-base"
+ unevaluatedProperties: false
+
+allOf:
+ - $ref: "#/definitions/port-base"
+
+patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: "#/definitions/endpoint-base"
+ unevaluatedProperties: false
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
new file mode 100644
index 0000000..35eef7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/awinic,aw88395.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW88395 Smart Audio Amplifier
+
+maintainers:
+ - Weidong Wang <wangweidong.a@awinic.com>
+
+description:
+ The Awinic AW88395 is an I2S/TDM input, high efficiency
+ digital Smart K audio amplifier with an integrated 10.25V
+ smart boost convert.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: awinic,aw88395
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@34 {
+ compatible = "awinic,aw88395";
+ reg = <0x34>;
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml
index 82062d8..18fb471 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml
@@ -22,6 +22,9 @@
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
'#sound-dai-cells':
description:
The first cell indicating the audio interface.
@@ -42,7 +45,7 @@
Configures the peak current by monitoring the current through the boost FET.
Range starts at 1600 mA and goes to a maximum of 4500 mA with increments
of 50 mA. See section 4.3.6 of the datasheet for details.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1600
maximum: 4500
default: 4500
@@ -51,7 +54,7 @@
description:
Boost inductor value, expressed in nH. Valid
values include 1000, 1200, 1500 and 2200.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1000
maximum: 2200
@@ -60,7 +63,7 @@
Total equivalent boost capacitance on the VBST
and VAMP pins, derated at 11 volts DC. The value must be rounded to the
nearest integer and expressed in uF.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
cirrus,asp-sdout-hiz:
description:
@@ -70,7 +73,7 @@
1 = Hi-Z during unused slots but logic 0 while all transmit channels disabled
2 = (Default) Logic 0 during unused slots, but Hi-Z while all transmit channels disabled
3 = Hi-Z during unused slots and while all transmit channels disabled
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
default: 2
@@ -84,7 +87,7 @@
enable boost voltage.
0 = Internal Boost
1 = External Boost
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
@@ -109,7 +112,7 @@
1 = GPIO
2 = Sync
3 = MCLK input
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
@@ -136,7 +139,7 @@
3 = MCLK input
4 = Push-pull INTB (active low)
5 = Push-pull INT (active high)
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 5
@@ -176,21 +179,23 @@
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
+
spi {
#address-cells = <1>;
#size-cells = <0>;
- cs35l41: cs35l41@2 {
- #sound-dai-cells = <1>;
- compatible = "cirrus,cs35l41";
- reg = <2>;
- VA-supply = <&dummy_vreg>;
- VP-supply = <&dummy_vreg>;
- reset-gpios = <&gpio 110 0>;
+ cs35l41: speaker-amp@2 {
+ #sound-dai-cells = <1>;
+ compatible = "cirrus,cs35l41";
+ reg = <2>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ reset-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
- cirrus,boost-type = <0>;
- cirrus,boost-peak-milliamp = <4500>;
- cirrus,boost-ind-nanohenry = <1000>;
- cirrus,boost-cap-microfarad = <15>;
+ cirrus,boost-type = <0>;
+ cirrus,boost-peak-milliamp = <4500>;
+ cirrus,boost-ind-nanohenry = <1000>;
+ cirrus,boost-cap-microfarad = <15>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/component-common.yaml b/Documentation/devicetree/bindings/sound/component-common.yaml
new file mode 100644
index 0000000..37766c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/component-common.yaml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/component-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio Component Common Properties
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ sound-name-prefix:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Card implementing the routing property define the connection between
+ audio components as list of string pair. Component using the same
+ sink/source names may use this property to prepend the name of their
+ sinks/sources with the provided string.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/dai-common.yaml b/Documentation/devicetree/bindings/sound/dai-common.yaml
index d858eea..1aed2f0 100644
--- a/Documentation/devicetree/bindings/sound/dai-common.yaml
+++ b/Documentation/devicetree/bindings/sound/dai-common.yaml
@@ -9,15 +9,10 @@
maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
-properties:
- sound-name-prefix:
- $ref: /schemas/types.yaml#/definitions/string
- description: |
- Card implementing the routing property define the connection between
- audio components as list of string pair. Component using the same
- sink/source names may use this property to prepend the name of their
- sinks/sources with the provided string.
+allOf:
+ - $ref: component-common.yaml#
+properties:
'#sound-dai-cells': true
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml
index 7e56337..088c26b 100644
--- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml
@@ -76,10 +76,14 @@
minItems: 4
dmas:
- maxItems: 2
+ items:
+ - description: DMA controller phandle and request line for RX
+ - description: DMA controller phandle and request line for TX
dma-names:
- maxItems: 2
+ items:
+ - const: rx
+ - const: tx
interrupts:
items:
@@ -143,31 +147,6 @@
allOf:
- $ref: dai-common.yaml#
- if:
- properties:
- compatible:
- contains:
- const: fsl,vf610-sai
- then:
- properties:
- dmas:
- items:
- - description: DMA controller phandle and request line for TX
- - description: DMA controller phandle and request line for RX
- dma-names:
- items:
- - const: tx
- - const: rx
- else:
- properties:
- dmas:
- items:
- - description: DMA controller phandle and request line for RX
- - description: DMA controller phandle and request line for TX
- dma-names:
- items:
- - const: rx
- - const: tx
- - if:
required:
- fsl,sai-asynchronous
then:
@@ -199,9 +178,8 @@
<&clks VF610_CLK_SAI2>,
<&clks 0>, <&clks 0>;
clock-names = "bus", "mclk1", "mclk2", "mclk3";
- dma-names = "tx", "rx";
- dmas = <&edma0 0 21>,
- <&edma0 0 20>;
+ dma-names = "rx", "tx";
+ dmas = <&edma0 0 20>, <&edma0 0 21>;
big-endian;
lsb-first;
};
diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
index 223b8ea..799b362 100644
--- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
@@ -21,6 +21,7 @@
compatible:
enum:
- fsl,imx8mp-xcvr
+ - fsl,imx93-xcvr
reg:
items:
diff --git a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
index 869b403..0b1a01a 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
@@ -75,6 +75,18 @@
additionalProperties: false
+ platform:
+ description: Holds subnode which includes the phandle of q6apm platform device.
+ type: object
+ properties:
+ sound-dai:
+ maxItems: 1
+
+ required:
+ - sound-dai
+
+ additionalProperties: false
+
required:
- link-name
- cpu
diff --git a/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml b/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
new file mode 100644
index 0000000..66993d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/infineon,peb2466.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon PEB2466 codec
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ The Infineon PEB2466 codec is a programmable DSP-based four channels codec
+ with filters capabilities.
+
+ The time-slots used by the codec must be set and so, the properties
+ 'dai-tdm-slot-num', 'dai-tdm-slot-width', 'dai-tdm-slot-tx-mask' and
+ 'dai-tdm-slot-rx-mask' must be present in the sound card node for sub-nodes
+ that involve the codec. The codec uses one 8bit time-slot per channel.
+ 'dai-tdm-tdm-slot-with' must be set to 8.
+
+ The PEB2466 codec also supports 28 gpios (signaling pins).
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: infineon,peb2466
+
+ reg:
+ description:
+ SPI device address.
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ spi-max-frequency:
+ maximum: 8192000
+
+ reset-gpios:
+ description:
+ GPIO used to reset the device.
+ maxItems: 1
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Filters coefficients file to load. If this property is omitted, internal
+ filters are disabled.
+
+ '#sound-dai-cells':
+ const: 0
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@0 {
+ compatible = "infineon,peb2466";
+ reg = <0>;
+ spi-max-frequency = <8192000>;
+ reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml b/Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml
new file mode 100644
index 0000000..b36c35e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/irondevice,sma1303.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Iron Device SMA1303 Audio Amplifier
+
+maintainers:
+ - Kiseok Jo <kiseok.jo@irondevice.com>
+
+description:
+ SMA1303 digital class-D audio amplifier
+ with an integrated boost converter.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - irondevice,sma1303
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ amplifier@1e {
+ compatible = "irondevice,sma1303";
+ reg = <0x1e>;
+ #sound-dai-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt
deleted file mode 100644
index 39d6402..0000000
--- a/Documentation/devicetree/bindings/sound/max98090.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-MAX98090 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "maxim,max98090" or "maxim,max98091".
-
-- reg : The I2C address of the device.
-
-- interrupts : The CODEC's interrupt output.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-
-- clock-names: Should be "mclk"
-
-- #sound-dai-cells : should be 0.
-
-- maxim,dmic-freq: Frequency at which to clock DMIC
-
-- maxim,micbias: Micbias voltage applies to the analog mic, valid voltages value are:
- 0 - 2.2v
- 1 - 2.55v
- 2 - 2.4v
- 3 - 2.8v
-
-Pins on the device (for linking into audio routes):
-
- * MIC1
- * MIC2
- * DMICL
- * DMICR
- * IN1
- * IN2
- * IN3
- * IN4
- * IN5
- * IN6
- * IN12
- * IN34
- * IN56
- * HPL
- * HPR
- * SPKL
- * SPKR
- * RCVL
- * RCVR
- * MICBIAS
-
-Example:
-
-audio-codec@10 {
- compatible = "maxim,max98090";
- reg = <0x10>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(H, 4) IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max98095.txt b/Documentation/devicetree/bindings/sound/max98095.txt
deleted file mode 100644
index 318a4c8..0000000
--- a/Documentation/devicetree/bindings/sound/max98095.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-MAX98095 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "maxim,max98095".
-
-- reg : The I2C address of the device.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-
-- clock-names: Should be "mclk"
-
-Example:
-
-max98095: codec@11 {
- compatible = "maxim,max98095";
- reg = <0x11>;
-};
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98090.yaml b/Documentation/devicetree/bindings/sound/maxim,max98090.yaml
new file mode 100644
index 0000000..65e4c516
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98090.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98090.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98090/MAX98091 audio codecs
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description: |
+ Pins on the device (for linking into audio routes):
+ MIC1, MIC2, DMICL, DMICR, IN1, IN2, IN3, IN4, IN5, IN6, IN12, IN34, IN56,
+ HPL, HPR, SPKL, SPKR, RCVL, RCVR, MICBIAS
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98090
+ - maxim,max98091
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ interrupts:
+ maxItems: 1
+
+ maxim,dmic-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 2500000
+ description:
+ DMIC clock frequency
+
+ maxim,micbias:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ default: 3
+ description: |
+ Micbias voltage applied to the analog mic, valid voltages value are:
+ 0 - 2.2v
+ 1 - 2.55v
+ 2 - 2.4v
+ 3 - 2.8v
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ interrupt-parent = <&gpx3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&i2s0 0>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98095.yaml b/Documentation/devicetree/bindings/sound/maxim,max98095.yaml
new file mode 100644
index 0000000..77544a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98095.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98095.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98095 audio codec
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98095
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@11 {
+ compatible = "maxim,max98095";
+ reg = <0x11>;
+ clocks = <&i2s0 0>;
+ clock-names = "mclk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml b/Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml
deleted file mode 100644
index 6210228..0000000
--- a/Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml
+++ /dev/null
@@ -1,110 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mchp,i2s-mcc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip I2S Multi-Channel Controller
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The I2SMCC complies with the Inter-IC Sound (I2S) bus specification and
- supports a Time Division Multiplexed (TDM) interface with external
- multi-channel audio codecs. It consists of a receiver, a transmitter and a
- common clock generator that can be enabled separately to provide Adapter,
- Client or Controller modes with receiver and/or transmitter active.
- On later I2SMCC versions (starting with Microchip's SAMA7G5) I2S
- multi-channel is supported by using multiple data pins, output and
- input, without TDM.
-
-properties:
- "#sound-dai-cells":
- const: 0
-
- compatible:
- enum:
- - microchip,sam9x60-i2smcc
- - microchip,sama7g5-i2smcc
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock (Optional). Should be set mostly when Master
- Mode is required.
- minItems: 1
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
- minItems: 1
-
- dmas:
- items:
- - description: TX DMA Channel
- - description: RX DMA Channel
-
- dma-names:
- items:
- - const: tx
- - const: rx
-
- microchip,tdm-data-pair:
- description:
- Represents the DIN/DOUT pair pins that are used to receive/send
- TDM data. It is optional and it is only needed if the controller
- uses the TDM mode.
- $ref: /schemas/types.yaml#/definitions/uint8
- enum: [0, 1, 2, 3]
- default: 0
-
-allOf:
- - $ref: dai-common.yaml#
- - if:
- properties:
- compatible:
- const: microchip,sam9x60-i2smcc
- then:
- properties:
- microchip,tdm-data-pair: false
-
-required:
- - "#sound-dai-cells"
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
-
-unevaluatedProperties: false
-
-examples:
- - |
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- i2s@f001c000 {
- #sound-dai-cells = <0>;
- compatible = "microchip,sam9x60-i2smcc";
- reg = <0xf001c000 0x100>;
- interrupts = <34 IRQ_TYPE_LEVEL_HIGH 7>;
- dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
- AT91_XDMAC_DT_PERID(36))>,
- <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
- AT91_XDMAC_DT_PERID(37))>;
- dma-names = "tx", "rx";
- clocks = <&i2s_clk>, <&i2s_gclk>;
- clock-names = "pclk", "gclk";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2s_default>;
- };
diff --git a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml b/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
deleted file mode 100644
index 70a47c6..0000000
--- a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
+++ /dev/null
@@ -1,73 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mchp,spdifrx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip S/PDIF Rx Controller
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The Microchip Sony/Philips Digital Interface Receiver is a serial port
- compliant with the IEC-60958 standard.
-
-properties:
- "#sound-dai-cells":
- const: 0
-
- compatible:
- const: microchip,sama7g5-spdifrx
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
-
- dmas:
- description: RX DMA Channel
- maxItems: 1
-
- dma-names:
- const: rx
-
-required:
- - "#sound-dai-cells"
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- spdifrx: spdifrx@e1614000 {
- #sound-dai-cells = <0>;
- compatible = "microchip,sama7g5-spdifrx";
- reg = <0xe1614000 0x4000>;
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma0 AT91_XDMAC_DT_PERID(49)>;
- dma-names = "rx";
- clocks = <&pmc PMC_TYPE_PERIPHERAL 84>, <&pmc PMC_TYPE_GCK 84>;
- clock-names = "pclk", "gclk";
- };
diff --git a/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml b/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml
deleted file mode 100644
index c383162..0000000
--- a/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml
+++ /dev/null
@@ -1,78 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mchp,spdiftx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip S/PDIF Tx Controller
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The Microchip Sony/Philips Digital Interface Transmitter is a serial port
- compliant with the IEC-60958 standard.
-
-allOf:
- - $ref: dai-common.yaml#
-
-properties:
- "#sound-dai-cells":
- const: 0
-
- compatible:
- const: microchip,sama7g5-spdiftx
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
-
- dmas:
- description: TX DMA Channel
- maxItems: 1
-
- dma-names:
- const: tx
-
-required:
- - "#sound-dai-cells"
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
-
-unevaluatedProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- spdiftx@e1618000 {
- #sound-dai-cells = <0>;
- compatible = "microchip,sama7g5-spdiftx";
- reg = <0xe1618000 0x4000>;
- interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma0 AT91_XDMAC_DT_PERID(50)>;
- dma-names = "tx";
- clocks = <&pmc PMC_TYPE_PERIPHERAL 85>, <&pmc PMC_TYPE_GCK 85>;
- clock-names = "pclk", "gclk";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_spdiftx_default>;
- };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
new file mode 100644
index 0000000..82ccb32
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
@@ -0,0 +1,208 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8188-afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AFE PCM controller for mt8188
+
+maintainers:
+ - Trevor Wu <trevor.wu@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8188-afe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: audiosys
+
+ mediatek,topckgen:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the mediatek topckgen controller
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: 26M clock
+ - description: audio pll1 clock
+ - description: audio pll2 clock
+ - description: clock divider for i2si1_mck
+ - description: clock divider for i2si2_mck
+ - description: clock divider for i2so1_mck
+ - description: clock divider for i2so2_mck
+ - description: clock divider for dptx_mck
+ - description: a1sys hoping clock
+ - description: audio intbus clock
+ - description: audio hires clock
+ - description: audio local bus clock
+ - description: mux for dptx_mck
+ - description: mux for i2so1_mck
+ - description: mux for i2so2_mck
+ - description: mux for i2si1_mck
+ - description: mux for i2si2_mck
+ - description: audio 26m clock
+
+ clock-names:
+ items:
+ - const: clk26m
+ - const: apll1
+ - const: apll2
+ - const: apll12_div0
+ - const: apll12_div1
+ - const: apll12_div2
+ - const: apll12_div3
+ - const: apll12_div9
+ - const: a1sys_hp_sel
+ - const: aud_intbus_sel
+ - const: audio_h_sel
+ - const: audio_local_bus_sel
+ - const: dptx_m_sel
+ - const: i2so1_m_sel
+ - const: i2so2_m_sel
+ - const: i2si1_m_sel
+ - const: i2si2_m_sel
+ - const: adsp_audio_26m
+
+ mediatek,etdm-in1-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm in module.
+ enum:
+ - 1 # etdm2_in
+ - 2 # etdm1_out
+ - 3 # etdm2_out
+
+ mediatek,etdm-in2-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm in module.
+ enum:
+ - 0 # etdm1_in
+ - 2 # etdm1_out
+ - 3 # etdm2_out
+
+ mediatek,etdm-out1-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm out module.
+ enum:
+ - 0 # etdm1_in
+ - 1 # etdm2_in
+ - 3 # etdm2_out
+
+ mediatek,etdm-out2-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm out module.
+ enum:
+ - 0 # etdm1_in
+ - 1 # etdm2_in
+ - 2 # etdm1_out
+
+patternProperties:
+ "^mediatek,etdm-in[1-2]-chn-disabled$":
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 1
+ maxItems: 16
+ description:
+ This is a list of channel IDs which should be disabled.
+ By default, all data received from ETDM pins will be outputed to
+ memory. etdm in supports disable_out in direct mode(w/o interconn),
+ so user can disable the specified channels by the property.
+ uniqueItems: true
+ items:
+ minimum: 0
+ maximum: 15
+
+ "^mediatek,etdm-in[1-2]-multi-pin-mode$":
+ type: boolean
+ description: if present, the etdm data mode is I2S.
+
+ "^mediatek,etdm-out[1-3]-multi-pin-mode$":
+ type: boolean
+ description: if present, the etdm data mode is I2S.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+ - reset-names
+ - mediatek,topckgen
+ - power-domains
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ afe@10b10000 {
+ compatible = "mediatek,mt8188-afe";
+ reg = <0x10b10000 0x10000>;
+ interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>;
+ resets = <&watchdog 14>;
+ reset-names = "audiosys";
+ mediatek,topckgen = <&topckgen>;
+ power-domains = <&spm 13>; //MT8188_POWER_DOMAIN_AUDIO
+ mediatek,etdm-in2-cowork-source = <2>;
+ mediatek,etdm-out2-cowork-source = <0>;
+ mediatek,etdm-in1-multi-pin-mode;
+ mediatek,etdm-in1-chn-disabled = /bits/ 8 <0x0 0x2>;
+ clocks = <&clk26m>,
+ <&apmixedsys 9>, //CLK_APMIXED_APLL1
+ <&apmixedsys 10>, //CLK_APMIXED_APLL2
+ <&topckgen 186>, //CLK_TOP_APLL12_CK_DIV0
+ <&topckgen 187>, //CLK_TOP_APLL12_CK_DIV1
+ <&topckgen 188>, //CLK_TOP_APLL12_CK_DIV2
+ <&topckgen 189>, //CLK_TOP_APLL12_CK_DIV3
+ <&topckgen 191>, //CLK_TOP_APLL12_CK_DIV9
+ <&topckgen 83>, //CLK_TOP_A1SYS_HP
+ <&topckgen 31>, //CLK_TOP_AUD_INTBUS
+ <&topckgen 32>, //CLK_TOP_AUDIO_H
+ <&topckgen 69>, //CLK_TOP_AUDIO_LOCAL_BUS
+ <&topckgen 81>, //CLK_TOP_DPTX
+ <&topckgen 77>, //CLK_TOP_I2SO1
+ <&topckgen 78>, //CLK_TOP_I2SO2
+ <&topckgen 79>, //CLK_TOP_I2SI1
+ <&topckgen 80>, //CLK_TOP_I2SI2
+ <&adsp_audio26m 0>; //CLK_AUDIODSP_AUDIO26M
+ clock-names = "clk26m",
+ "apll1",
+ "apll2",
+ "apll12_div0",
+ "apll12_div1",
+ "apll12_div2",
+ "apll12_div3",
+ "apll12_div9",
+ "a1sys_hp_sel",
+ "aud_intbus_sel",
+ "audio_h_sel",
+ "audio_local_bus_sel",
+ "dptx_m_sel",
+ "i2so1_m_sel",
+ "i2so2_m_sel",
+ "i2si1_m_sel",
+ "i2si2_m_sel",
+ "adsp_audio_26m";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
new file mode 100644
index 0000000..6640272
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8188-mt6359.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8188 ASoC sound card
+
+maintainers:
+ - Trevor Wu <trevor.wu@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8188-mt6359-evb
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ sink/source pair of strings. Valid names could be the input or output
+ widgets of audio components, power supplies, MicBias of codec and the
+ software switch.
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT8188 ASoC platform.
+
+patternProperties:
+ "^dai-link-[0-9]+$":
+ type: object
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description:
+ This property corresponds to the name of the BE dai-link to which
+ we are going to update parameters in this node.
+ items:
+ enum:
+ - ADDA_BE
+ - DPTX_BE
+ - ETDM1_IN_BE
+ - ETDM2_IN_BE
+ - ETDM1_OUT_BE
+ - ETDM2_OUT_BE
+ - ETDM3_OUT_BE
+ - PCM1_BE
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ additionalProperties: false
+
+ required:
+ - link-name
+ - codec
+
+additionalProperties: false
+
+required:
+ - compatible
+ - mediatek,platform
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8188-mt6359-evb";
+ mediatek,platform = <&afe>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&aud_pins_default>;
+ audio-routing =
+ "Headphone", "Headphone L",
+ "Headphone", "Headphone R",
+ "AIN1", "Headset Mic";
+ dai-link-0 {
+ link-name = "ETDM3_OUT_BE";
+
+ codec {
+ sound-dai = <&hdmi0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml
deleted file mode 100644
index c37b89d..0000000
--- a/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml
+++ /dev/null
@@ -1,103 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/microchip,pdmc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip Pulse Density Microphone Controller
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The Microchip Pulse Density Microphone Controller (PDMC) interfaces up to 4
- digital microphones having Pulse Density Modulated (PDM) outputs.
-
-allOf:
- - $ref: dai-common.yaml#
-
-properties:
- compatible:
- const: microchip,sama7g5-pdmc
-
- reg:
- maxItems: 1
-
- "#sound-dai-cells":
- const: 0
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
-
- dmas:
- description: RX DMA Channel
- maxItems: 1
-
- dma-names:
- const: rx
-
- microchip,mic-pos:
- description: |
- Position of PDM microphones on the DS line and the sampling edge (rising
- or falling) of the CLK line. A microphone is represented as a pair of DS
- line and the sampling edge. The first microphone is mapped to channel 0,
- the second to channel 1, etc.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: value for DS line
- - description: value for sampling edge
- anyOf:
- - enum:
- - [0, 0]
- - [0, 1]
- - [1, 0]
- - [1, 1]
- minItems: 1
- maxItems: 4
- uniqueItems: true
-
-required:
- - compatible
- - reg
- - "#sound-dai-cells"
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
- - microchip,mic-pos
-
-unevaluatedProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/sound/microchip,pdmc.h>
-
- pdmc: sound@e1608000 {
- compatible = "microchip,sama7g5-pdmc";
- reg = <0xe1608000 0x4000>;
- #sound-dai-cells = <0>;
- interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma0 AT91_XDMAC_DT_PERID(37)>;
- dma-names = "rx";
- clocks = <&pmc PMC_TYPE_PERIPHERAL 68>, <&pmc PMC_TYPE_GCK 68>;
- clock-names = "pclk", "gclk";
- microchip,mic-pos = <MCHP_PDMC_DS0 MCHP_PDMC_CLK_POSITIVE>,
- <MCHP_PDMC_DS0 MCHP_PDMC_CLK_NEGATIVE>,
- <MCHP_PDMC_DS1 MCHP_PDMC_CLK_POSITIVE>,
- <MCHP_PDMC_DS1 MCHP_PDMC_CLK_NEGATIVE>;
- };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml
new file mode 100644
index 0000000..651f61c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-i2smcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip I2S Multi-Channel Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The I2SMCC complies with the Inter-IC Sound (I2S) bus specification and
+ supports a Time Division Multiplexed (TDM) interface with external
+ multi-channel audio codecs. It consists of a receiver, a transmitter and a
+ common clock generator that can be enabled separately to provide Adapter,
+ Client or Controller modes with receiver and/or transmitter active.
+ On later I2SMCC versions (starting with Microchip's SAMA7G5) I2S
+ multi-channel is supported by using multiple data pins, output and
+ input, without TDM.
+
+properties:
+ "#sound-dai-cells":
+ const: 0
+
+ compatible:
+ enum:
+ - microchip,sam9x60-i2smcc
+ - microchip,sama7g5-i2smcc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock (Optional). Should be set mostly when Master
+ Mode is required.
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+ minItems: 1
+
+ dmas:
+ items:
+ - description: TX DMA Channel
+ - description: RX DMA Channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ microchip,tdm-data-pair:
+ description:
+ Represents the DIN/DOUT pair pins that are used to receive/send
+ TDM data. It is optional and it is only needed if the controller
+ uses the TDM mode.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ enum: [0, 1, 2, 3]
+ default: 0
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ const: microchip,sam9x60-i2smcc
+ then:
+ properties:
+ microchip,tdm-data-pair: false
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2s@f001c000 {
+ #sound-dai-cells = <0>;
+ compatible = "microchip,sam9x60-i2smcc";
+ reg = <0xf001c000 0x100>;
+ interrupts = <34 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(36))>,
+ <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(37))>;
+ dma-names = "tx", "rx";
+ clocks = <&i2s_clk>, <&i2s_gclk>;
+ clock-names = "pclk", "gclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_default>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
new file mode 100644
index 0000000..9b40268
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-pdmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Pulse Density Microphone Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The Microchip Pulse Density Microphone Controller (PDMC) interfaces up to 4
+ digital microphones having Pulse Density Modulated (PDM) outputs.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: microchip,sama7g5-pdmc
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+
+ dmas:
+ description: RX DMA Channel
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+ microchip,mic-pos:
+ description: |
+ Position of PDM microphones on the DS line and the sampling edge (rising
+ or falling) of the CLK line. A microphone is represented as a pair of DS
+ line and the sampling edge. The first microphone is mapped to channel 0,
+ the second to channel 1, etc.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: value for DS line
+ - description: value for sampling edge
+ anyOf:
+ - enum:
+ - [0, 0]
+ - [0, 1]
+ - [1, 0]
+ - [1, 1]
+ minItems: 1
+ maxItems: 4
+ uniqueItems: true
+
+ microchip,startup-delay-us:
+ description: |
+ Specifies the delay in microseconds that needs to be applied after
+ enabling the PDMC microphones to avoid unwanted noise due to microphones
+ not being ready.
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+ - microchip,mic-pos
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/sound/microchip,pdmc.h>
+
+ pdmc: sound@e1608000 {
+ compatible = "microchip,sama7g5-pdmc";
+ reg = <0xe1608000 0x4000>;
+ #sound-dai-cells = <0>;
+ interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(37)>;
+ dma-names = "rx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 68>, <&pmc PMC_TYPE_GCK 68>;
+ clock-names = "pclk", "gclk";
+ microchip,mic-pos = <MCHP_PDMC_DS0 MCHP_PDMC_CLK_POSITIVE>,
+ <MCHP_PDMC_DS0 MCHP_PDMC_CLK_NEGATIVE>,
+ <MCHP_PDMC_DS1 MCHP_PDMC_CLK_POSITIVE>,
+ <MCHP_PDMC_DS1 MCHP_PDMC_CLK_NEGATIVE>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml
new file mode 100644
index 0000000..2f43c68
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-spdifrx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip S/PDIF Rx Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The Microchip Sony/Philips Digital Interface Receiver is a serial port
+ compliant with the IEC-60958 standard.
+
+properties:
+ "#sound-dai-cells":
+ const: 0
+
+ compatible:
+ const: microchip,sama7g5-spdifrx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+
+ dmas:
+ description: RX DMA Channel
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spdifrx: spdifrx@e1614000 {
+ #sound-dai-cells = <0>;
+ compatible = "microchip,sama7g5-spdifrx";
+ reg = <0xe1614000 0x4000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(49)>;
+ dma-names = "rx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 84>, <&pmc PMC_TYPE_GCK 84>;
+ clock-names = "pclk", "gclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml
new file mode 100644
index 0000000..4702c528
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-spdiftx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip S/PDIF Tx Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The Microchip Sony/Philips Digital Interface Transmitter is a serial port
+ compliant with the IEC-60958 standard.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ "#sound-dai-cells":
+ const: 0
+
+ compatible:
+ const: microchip,sama7g5-spdiftx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+
+ dmas:
+ description: TX DMA Channel
+ maxItems: 1
+
+ dma-names:
+ const: tx
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spdiftx@e1618000 {
+ #sound-dai-cells = <0>;
+ compatible = "microchip,sama7g5-spdiftx";
+ reg = <0xe1618000 0x4000>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(50)>;
+ dma-names = "tx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 85>, <&pmc PMC_TYPE_GCK 85>;
+ clock-names = "pclk", "gclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdiftx_default>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/nau8822.txt b/Documentation/devicetree/bindings/sound/nau8822.txt
deleted file mode 100644
index a471d16..0000000
--- a/Documentation/devicetree/bindings/sound/nau8822.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-NAU8822 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "nuvoton,nau8822"
-
- - reg : the I2C address of the device.
-
-Example:
-
-codec: nau8822@1a {
- compatible = "nuvoton,nau8822";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
new file mode 100644
index 0000000..6510540
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8822.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8822 audio CODEC
+
+description: |
+ 24 bit stereo audio codec with speaker driver.
+ This device supports I2C/SPI.
+
+maintainers:
+ - David Lin <CTLIN0@nuvoton.com>
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8822
+
+ reg:
+ maxItems: 1
+
+ nuvoton,spk-btl:
+ description:
+ If set, configure the two loudspeaker outputs as a Bridge Tied Load output
+ to drive a high power external loudspeaker.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "nuvoton,nau8822";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml
index 89f7805..c4abac8 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml
@@ -50,10 +50,10 @@
maxItems: 1
"#address-cells":
- const: 1
+ enum: [ 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
ranges: true
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml
index 5fc03b8..9017fb6 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml
@@ -34,10 +34,10 @@
maxItems: 1
"#address-cells":
- const: 1
+ enum: [ 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
ranges: true
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index bb42220..6cc8f86 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -35,7 +35,7 @@
clocks:
minItems: 3
- maxItems: 7
+ maxItems: 10
clock-names:
minItems: 1
@@ -65,6 +65,9 @@
power-domain-names:
maxItems: 1
+ required-opps:
+ maxItems: 1
+
'#sound-dai-cells':
const: 1
@@ -75,7 +78,7 @@
const: 0
patternProperties:
- "^dai-link@[0-9a-f]$":
+ "^dai-link@[0-9a-f]+$":
type: object
description: |
LPASS CPU dai node for each I2S device or Soundwire device. Bindings of each node
@@ -121,6 +124,8 @@
then:
properties:
+ clocks:
+ maxItems: 3
clock-names:
items:
- const: ahbix-clk
@@ -135,6 +140,9 @@
then:
properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
clock-names:
items:
- const: ahbix-clk
@@ -153,33 +161,31 @@
then:
properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
clock-names:
- oneOf:
- - items: #for I2S
- - const: pcnoc-sway-clk
- - const: audio-core
- - const: mclk0
- - const: pcnoc-mport-clk
- - const: mi2s-bit-clk0
- - const: mi2s-bit-clk1
- - items: #for HDMI
- - const: pcnoc-sway-clk
- - const: audio-core
- - const: pcnoc-mport-clk
+ items:
+ - const: pcnoc-sway-clk
+ - const: audio-core
+ - const: mclk0
+ - const: pcnoc-mport-clk
+ - const: mi2s-bit-clk0
+ - const: mi2s-bit-clk1
+ reg:
+ minItems: 2
+ maxItems: 2
reg-names:
- anyOf:
- - items: #for I2S
- - const: lpass-lpaif
- - items: #for I2S and HDMI
- - const: lpass-hdmiif
- - const: lpass-lpaif
+ items:
+ - const: lpass-hdmiif
+ - const: lpass-lpaif
+ interrupts:
+ minItems: 2
+ maxItems: 2
interrupt-names:
- anyOf:
- - items: #for I2S
- - const: lpass-irq-lpaif
- - items: #for I2S and HDMI
- - const: lpass-irq-lpaif
- - const: lpass-irq-hdmi
+ items:
+ - const: lpass-irq-lpaif
+ - const: lpass-irq-hdmi
required:
- iommus
- power-domains
@@ -192,54 +198,44 @@
then:
properties:
+ clocks:
+ minItems: 10
+ maxItems: 10
clock-names:
- oneOf:
- - items: #for I2S
- - const: aon_cc_audio_hm_h
- - const: audio_cc_ext_mclk0
- - const: core_cc_sysnoc_mport_core
- - const: core_cc_ext_if0_ibit
- - const: core_cc_ext_if1_ibit
- - items: #for Soundwire
- - const: aon_cc_audio_hm_h
- - const: audio_cc_codec_mem
- - const: audio_cc_codec_mem0
- - const: audio_cc_codec_mem1
- - const: audio_cc_codec_mem2
- - const: aon_cc_va_mem0
- - items: #for HDMI
- - const: core_cc_sysnoc_mport_core
-
+ items:
+ - const: aon_cc_audio_hm_h
+ - const: audio_cc_ext_mclk0
+ - const: core_cc_sysnoc_mport_core
+ - const: core_cc_ext_if0_ibit
+ - const: core_cc_ext_if1_ibit
+ - const: audio_cc_codec_mem
+ - const: audio_cc_codec_mem0
+ - const: audio_cc_codec_mem1
+ - const: audio_cc_codec_mem2
+ - const: aon_cc_va_mem0
+ reg:
+ minItems: 6
+ maxItems: 6
reg-names:
- anyOf:
- - items: #for I2S
- - const: lpass-lpaif
- - items: #for I2S and HDMI
- - const: lpass-hdmiif
- - const: lpass-lpaif
- - items: #for I2S, soundwire and HDMI
- - const: lpass-hdmiif
- - const: lpass-lpaif
- - const: lpass-rxtx-cdc-dma-lpm
- - const: lpass-rxtx-lpaif
- - const: lpass-va-lpaif
- - const: lpass-va-cdc-dma-lpm
+ items:
+ - const: lpass-hdmiif
+ - const: lpass-lpaif
+ - const: lpass-rxtx-cdc-dma-lpm
+ - const: lpass-rxtx-lpaif
+ - const: lpass-va-lpaif
+ - const: lpass-va-cdc-dma-lpm
+ interrupts:
+ minItems: 4
+ maxItems: 4
interrupt-names:
- anyOf:
- - items: #for I2S
- - const: lpass-irq-lpaif
- - items: #for I2S and HDMI
- - const: lpass-irq-lpaif
- - const: lpass-irq-hdmi
- - items: #for I2S, soundwire and HDMI
- - const: lpass-irq-lpaif
- - const: lpass-irq-hdmi
- - const: lpass-irq-vaif
- - const: lpass-irq-rxtxif
+ items:
+ - const: lpass-irq-lpaif
+ - const: lpass-irq-hdmi
+ - const: lpass-irq-vaif
+ - const: lpass-irq-rxtxif
power-domain-names:
- allOf:
- - items:
- - const: lcx
+ items:
+ - const: lcx
required:
- iommus
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
index 26f0343..0a3c688 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
@@ -36,7 +36,7 @@
oneOf:
- items: #for ADSP based platforms
- const: mclk
- - const: core
+ - const: macro
- const: dcodec
- items: #for ADSP bypass based platforms
- const: mclk
@@ -77,7 +77,7 @@
clocks = <&aoncc 0>,
<&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
<&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
- clock-names = "mclk", "core", "dcodec";
+ clock-names = "mclk", "macro", "dcodec";
clock-output-names = "fsgen";
qcom,dmic-sample-rate = <600000>;
vdd-micb-supply = <&vreg_s4a_1p8>;
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
index a53c9ef..cdbb409 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
@@ -17,7 +17,8 @@
const: qcom,q6apm-dais
iommus:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
index 70080d0..262de7a 100644
--- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -15,16 +15,20 @@
properties:
compatible:
- enum:
- - lenovo,yoga-c630-sndcard
- - qcom,apq8016-sbc-sndcard
- - qcom,db845c-sndcard
- - qcom,msm8916-qdsp6-sndcard
- - qcom,qrb5165-rb5-sndcard
- - qcom,sc8280xp-sndcard
- - qcom,sdm845-sndcard
- - qcom,sm8250-sndcard
- - qcom,sm8450-sndcard
+ oneOf:
+ - items:
+ - enum:
+ - lenovo,yoga-c630-sndcard
+ - qcom,db845c-sndcard
+ - const: qcom,sdm845-sndcard
+ - enum:
+ - qcom,apq8016-sbc-sndcard
+ - qcom,msm8916-qdsp6-sndcard
+ - qcom,qrb5165-rb5-sndcard
+ - qcom,sc8280xp-sndcard
+ - qcom,sdm845-sndcard
+ - qcom,sm8250-sndcard
+ - qcom,sm8450-sndcard
audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
index 184e8cc..ea09590 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
@@ -28,7 +28,9 @@
description: GPIO spec for reset line to use
maxItems: 1
- slim-ifc-dev: true
+ slim-ifc-dev:
+ description: IFC device interface
+ $ref: /schemas/types.yaml#/definitions/phandle
clocks:
maxItems: 1
@@ -147,21 +149,49 @@
required:
- compatible
- reg
- - reset-gpios
- - slim-ifc-dev
- - interrupts
- - interrupt-controller
- - clock-frequency
- - clock-output-names
- - qcom,micbias1-microvolt
- - qcom,micbias2-microvolt
- - qcom,micbias3-microvolt
- - qcom,micbias4-microvolt
- - "#interrupt-cells"
- - "#clock-cells"
- - "#sound-dai-cells"
- - "#address-cells"
- - "#size-cells"
+
+allOf:
+ - if:
+ required:
+ - slim-ifc-dev
+ then:
+ required:
+ - reset-gpios
+ - slim-ifc-dev
+ - interrupt-controller
+ - clock-frequency
+ - clock-output-names
+ - qcom,micbias1-microvolt
+ - qcom,micbias2-microvolt
+ - qcom,micbias3-microvolt
+ - qcom,micbias4-microvolt
+ - "#interrupt-cells"
+ - "#clock-cells"
+ - "#sound-dai-cells"
+ - "#address-cells"
+ - "#size-cells"
+ oneOf:
+ - required:
+ - interrupts-extended
+ - required:
+ - interrupts
+ else:
+ properties:
+ reset-gpios: false
+ slim-ifc-dev: false
+ interrupts: false
+ interrupt-controller: false
+ clock-frequency: false
+ clock-output-names: false
+ qcom,micbias1-microvolt: false
+ qcom,micbias2-microvolt: false
+ qcom,micbias3-microvolt: false
+ qcom,micbias4-microvolt: false
+ "#interrupt-cells": false
+ "#clock-cells": false
+ "#sound-dai-cells": false
+ "#address-cells": false
+ "#size-cells": false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml
index d702b48..ac03672 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml
@@ -15,6 +15,9 @@
Their primary operating mode uses a SoundWire digital audio
interface. This binding is for SoundWire interface.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: sdw10217201000
@@ -39,7 +42,7 @@
- "#thermal-sensor-cells"
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/renesas,idt821034.yaml b/Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
new file mode 100644
index 0000000..a2b92db
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/renesas,idt821034.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas IDT821034 codec device
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ The IDT821034 codec is a four channel PCM codec with onchip filters and
+ programmable gain setting.
+
+ The time-slots used by the codec must be set and so, the properties
+ 'dai-tdm-slot-num', 'dai-tdm-slot-width', 'dai-tdm-slot-tx-mask' and
+ 'dai-tdm-slot-rx-mask' must be present in the ALSA sound card node for
+ sub-nodes that involve the codec. The codec uses one 8bit time-slot per
+ channel.
+ 'dai-tdm-tdm-slot-with' must be set to 8.
+
+ The IDT821034 codec also supports 5 gpios (SLIC signals) per channel.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: renesas,idt821034
+
+ reg:
+ description:
+ SPI device address.
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 8192000
+
+ spi-cpha: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - spi-cpha
+ - '#sound-dai-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@0 {
+ compatible = "renesas,idt821034";
+ reg = <0>;
+ spi-max-frequency = <8192000>;
+ spi-cpha;
+ #sound-dai-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
index cb90463..12ccf29 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
@@ -18,8 +18,7 @@
- enum:
- renesas,rcar_sound-r8a7778 # R-Car M1A
- renesas,rcar_sound-r8a7779 # R-Car H1
- - enum:
- - renesas,rcar_sound-gen1
+ - const: renesas,rcar_sound-gen1
# for Gen2 SoC
- items:
- enum:
@@ -32,8 +31,7 @@
- renesas,rcar_sound-r8a7791 # R-Car M2-W
- renesas,rcar_sound-r8a7793 # R-Car M2-N
- renesas,rcar_sound-r8a7794 # R-Car E2
- - enum:
- - renesas,rcar_sound-gen2
+ - const: renesas,rcar_sound-gen2
# for Gen3 SoC
- items:
- enum:
@@ -47,14 +45,16 @@
- renesas,rcar_sound-r8a77965 # R-Car M3-N
- renesas,rcar_sound-r8a77990 # R-Car E3
- renesas,rcar_sound-r8a77995 # R-Car D3
- - enum:
- - renesas,rcar_sound-gen3
- # for Generic
+ - const: renesas,rcar_sound-gen3
+ # for Gen4 SoC
- items:
- - enum:
- - renesas,rcar_sound-gen1
- - renesas,rcar_sound-gen2
- - renesas,rcar_sound-gen3
+ - const: renesas,rcar_sound-r8a779g0 # R-Car V4H
+ - const: renesas,rcar_sound-gen4
+ # for Generic
+ - enum:
+ - renesas,rcar_sound-gen1
+ - renesas,rcar_sound-gen2
+ - renesas,rcar_sound-gen3
reg:
minItems: 1
@@ -68,6 +68,7 @@
description: |
it must be 0 if your system is using single DAI
it must be 1 if your system is using multi DAIs
+ This is used on simple-audio-card
enum: [0, 1]
"#clock-cells":
@@ -113,15 +114,34 @@
- pattern: '^clk_(a|b|c|i)$'
ports:
- $ref: /schemas/graph.yaml#/properties/ports
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ unevaluatedProperties: false
patternProperties:
'^port(@[0-9a-f]+)?$':
- $ref: audio-graph-port.yaml#
+ $ref: audio-graph-port.yaml#/definitions/port-base
unevaluatedProperties: false
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: audio-graph-port.yaml#/definitions/endpoint-base
+ properties:
+ playback:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ capture:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ unevaluatedProperties: false
port:
- $ref: audio-graph-port.yaml#
+ $ref: audio-graph-port.yaml#/definitions/port-base
unevaluatedProperties: false
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: audio-graph-port.yaml#/definitions/endpoint-base
+ properties:
+ playback:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ capture:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ unevaluatedProperties: false
rcar_sound,dvc:
description: DVC subnode.
@@ -178,10 +198,6 @@
enum:
- tx
- rx
- required:
- - interrupts
- - dmas
- - dma-names
additionalProperties: false
rcar_sound,ssiu:
@@ -240,8 +256,6 @@
$ref: /schemas/types.yaml#/definitions/flag
required:
- interrupts
- - dmas
- - dma-names
additionalProperties: false
# For DAI base
@@ -271,7 +285,6 @@
- reg-names
- clocks
- clock-names
- - "#sound-dai-cells"
allOf:
- $ref: dai-common.yaml#
@@ -285,7 +298,6 @@
reg:
maxItems: 3
reg-names:
- maxItems: 3
items:
enum:
- scu
@@ -294,9 +306,8 @@
else:
properties:
reg:
- maxItems: 5
+ minItems: 5
reg-names:
- maxItems: 5
items:
enum:
- scu
diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt
index ff12287..0c39858 100644
--- a/Documentation/devicetree/bindings/sound/rt5640.txt
+++ b/Documentation/devicetree/bindings/sound/rt5640.txt
@@ -20,6 +20,9 @@
- realtek,in3-differential
Boolean. Indicate MIC1/2/3 input are differential, rather than single-ended.
+- realtek,lout-differential
+ Boolean. Indicate LOUT output is differential, rather than stereo.
+
- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
- realtek,dmic1-data-pin
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
index 7b4e08d..7774543 100644
--- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
@@ -43,9 +43,10 @@
type: object
properties:
sound-dai:
+ minItems: 1
items:
- - description: phandle of the MAX98090 CODEC
- description: phandle of the HDMI IP block node
+ - description: phandle of the MAX98090 CODEC
samsung,audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
index 8d5dcf9..30b3b6e 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
@@ -37,12 +37,20 @@
samsung,exynos7-i2s1: I2S1 on previous samsung platforms supports
stereo channels. Exynos7 I2S1 upgraded to 5.1 multichannel with
slightly modified bit offsets.
+
+ tesla,fsd-i2s: for 8/16/24bit stereo channel I2S for playback and
+ capture, secondary FIFO using external DMA, s/w reset control,
+ internal mux for root clock source with all root clock sampling
+ frequencies supported by Exynos7 I2S and 7.1 channel TDM support
+ for playback and capture TDM (Time division multiplexing) to allow
+ transfer of multiple channel audio data on single data line.
enum:
- samsung,s3c6410-i2s
- samsung,s5pv210-i2s
- samsung,exynos5420-i2s
- samsung,exynos7-i2s
- samsung,exynos7-i2s1
+ - tesla,fsd-i2s
'#address-cells':
const: 1
@@ -67,9 +75,6 @@
- const: rx
- const: tx-sec
- assigned-clock-parents: true
- assigned-clocks: true
-
clocks:
minItems: 1
maxItems: 3
diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml
index ed19899..f0d81bf 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
@@ -205,6 +205,8 @@
$ref: "#/definitions/dai"
"^simple-audio-card,codec(@[0-9a-f]+)?$":
$ref: "#/definitions/dai"
+ "^simple-audio-card,plat(@[0-9a-f]+)?$":
+ $ref: "#/definitions/dai"
"^simple-audio-card,dai-link(@[0-9a-f]+)?$":
description: |
@@ -215,6 +217,10 @@
reg:
maxItems: 1
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
# common properties
frame-master:
$ref: "#/definitions/frame-master"
@@ -244,9 +250,9 @@
maxItems: 1
patternProperties:
- "^cpu(@[0-9a-f]+)?":
+ "^cpu(-[0-9]+)?$":
$ref: "#/definitions/dai"
- "^codec(@[0-9a-f]+)?":
+ "^codec(-[0-9]+)?$":
$ref: "#/definitions/dai"
additionalProperties: false
@@ -462,16 +468,16 @@
convert-channels = <8>; /* TDM Split */
- sndcpu1: cpu0 {
+ sndcpu1: cpu-0 {
sound-dai = <&rcar_sound 1>;
};
- cpu1 {
+ cpu-1 {
sound-dai = <&rcar_sound 2>;
};
- cpu2 {
+ cpu-2 {
sound-dai = <&rcar_sound 3>;
};
- cpu3 {
+ cpu-3 {
sound-dai = <&rcar_sound 4>;
};
codec {
diff --git a/Documentation/devicetree/bindings/sound/tas5720.txt b/Documentation/devicetree/bindings/sound/tas5720.txt
index df99ca9..7d851ae 100644
--- a/Documentation/devicetree/bindings/sound/tas5720.txt
+++ b/Documentation/devicetree/bindings/sound/tas5720.txt
@@ -6,11 +6,13 @@
https://www.ti.com/product/TAS5720L
https://www.ti.com/product/TAS5720M
+https://www.ti.com/product/TAS5720A-Q1
https://www.ti.com/product/TAS5722L
Required properties:
- compatible : "ti,tas5720",
+ "ti,tas5720a-q1",
"ti,tas5722"
- reg : I2C slave address
- dvdd-supply : phandle to a 3.3-V supply for the digital circuitry
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm3168a.txt b/Documentation/devicetree/bindings/sound/ti,pcm3168a.txt
deleted file mode 100644
index a02ecaa..0000000
--- a/Documentation/devicetree/bindings/sound/ti,pcm3168a.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Texas Instruments pcm3168a DT bindings
-
-This driver supports both SPI and I2C bus access for this codec
-
-Required properties:
-
- - compatible: "ti,pcm3168a"
-
- - clocks : Contains an entry for each entry in clock-names
-
- - clock-names : Includes the following entries:
- "scki" The system clock
-
- - VDD1-supply : Digital power supply regulator 1 (+3.3V)
-
- - VDD2-supply : Digital power supply regulator 2 (+3.3V)
-
- - VCCAD1-supply : ADC power supply regulator 1 (+5V)
-
- - VCCAD2-supply : ADC power supply regulator 2 (+5V)
-
- - VCCDA1-supply : DAC power supply regulator 1 (+5V)
-
- - VCCDA2-supply : DAC power supply regulator 2 (+5V)
-
-For required properties on SPI/I2C, consult SPI/I2C device tree documentation
-
-Optional properties:
-
- - reset-gpios : Optional reset gpio line connected to RST pin of the codec.
- The RST line is low active:
- RST = low: device power-down
- RST = high: device is enabled
-
-Examples:
-
-i2c0: i2c0@0 {
-
- ...
-
- pcm3168a: audio-codec@44 {
- compatible = "ti,pcm3168a";
- reg = <0x44>;
- reset-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
- clocks = <&clk_core CLK_AUDIO>;
- clock-names = "scki";
- VDD1-supply = <&supply3v3>;
- VDD2-supply = <&supply3v3>;
- VCCAD1-supply = <&supply5v0>;
- VCCAD2-supply = <&supply5v0>;
- VCCDA1-supply = <&supply5v0>;
- VCCDA2-supply = <&supply5v0>;
- pinctrl-names = "default";
- pinctrl-0 = <&dac_clk_pin>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml b/Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml
new file mode 100644
index 0000000..b6a4360
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm3168a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PCM3168A Audio Codec
+
+maintainers:
+ - Damien Horsley <Damien.Horsley@imgtec.com>
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+description:
+ The Texas Instruments PCM3168A is a 24-bit Multi-channel Audio CODEC with
+ 96/192kHz sampling rate, supporting both SPI and I2C bus access.
+
+properties:
+ compatible:
+ const: ti,pcm3168a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: System clock input
+
+ clock-names:
+ items:
+ - const: scki
+
+ reset-gpios:
+ items:
+ - description: |
+ GPIO line connected to the active-low RST pin of the codec.
+ RST = low: device power-down
+ RST = high: device is enabled
+
+ "#sound-dai-cells":
+ enum: [0, 1]
+
+ VDD1-supply:
+ description: Digital power supply regulator 1 (+3.3V)
+
+ VDD2-supply:
+ description: Digital power supply regulator 2 (+3.3V)
+
+ VCCAD1-supply:
+ description: ADC power supply regulator 1 (+5V)
+
+ VCCAD2-supply:
+ description: ADC power supply regulator 2 (+5V)
+
+ VCCDA1-supply:
+ description: DAC power supply regulator 1 (+5V)
+
+ VCCDA2-supply:
+ description: DAC power supply regulator 2 (+5V)
+
+ ports:
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ properties:
+ port@0:
+ $ref: audio-graph-port.yaml#
+ description: Audio input port.
+
+ port@1:
+ $ref: audio-graph-port.yaml#
+ description: Audio output port.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - VDD1-supply
+ - VDD2-supply
+ - VCCAD1-supply
+ - VCCAD2-supply
+ - VCCDA1-supply
+ - VCCDA2-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcm3168a: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ reset-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+ clocks = <&clk_core 42>;
+ clock-names = "scki";
+ VDD1-supply = <&supply3v3>;
+ VDD2-supply = <&supply3v3>;
+ VCCAD1-supply = <&supply5v0>;
+ VCCAD2-supply = <&supply5v0>;
+ VCCDA1-supply = <&supply5v0>;
+ VCCDA2-supply = <&supply5v0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
new file mode 100644
index 0000000..e8ca9f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
@@ -0,0 +1,165 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tlv320aic3x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TLV320AIC3x Codec
+
+description: |
+ TLV320AIC3x are a series of low-power stereo audio codecs with stereo
+ headphone amplifier, as well as multiple inputs and outputs programmable in
+ single-ended or fully differential configurations.
+
+ The serial control bus supports SPI or I2C protocols, while the serial audio
+ data bus is programmable for I2S, left/right-justified, DSP, or TDM modes.
+
+ The following pins can be referred in the sound node's audio routing property:
+
+ CODEC output pins:
+ LLOUT
+ RLOUT
+ MONO_LOUT
+ HPLOUT
+ HPROUT
+ HPLCOM
+ HPRCOM
+
+ CODEC input pins for TLV320AIC3104:
+ MIC2L
+ MIC2R
+ LINE1L
+ LINE1R
+
+ CODEC input pins for other compatible codecs:
+ MIC3L
+ MIC3R
+ LINE1L
+ LINE2L
+ LINE1R
+ LINE2R
+
+maintainers:
+ - Jai Luthra <j-luthra@ti.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,tlv320aic3x
+ - ti,tlv320aic33
+ - ti,tlv320aic3007
+ - ti,tlv320aic3106
+ - ti,tlv320aic3104
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO specification for the active low RESET input.
+
+ gpio-reset:
+ maxItems: 1
+ description:
+ Deprecated, please use reset-gpios instead.
+ deprecated: true
+
+ ai3x-gpio-func:
+ description: AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+
+ ai3x-micbias-vg:
+ description: MicBias required voltage. If node is omitted then MicBias is powered down.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - const: 1
+ description: MICBIAS output is powered to 2.0V.
+ - const: 2
+ description: MICBIAS output is powered to 2.5V.
+ - const: 3
+ description: MICBIAS output is connected to AVDD.
+
+ ai3x-ocmv:
+ description: Output Common-Mode Voltage selection.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - const: 0
+ description: 1.35V
+ - const: 1
+ description: 1.5V
+ - const: 2
+ description: 1.65V
+ - const: 3
+ description: 1.8V
+
+ AVDD-supply:
+ description: Analog DAC voltage.
+
+ IOVDD-supply:
+ description: I/O voltage.
+
+ DRVDD-supply:
+ description: ADC analog and output driver voltage.
+
+ DVDD-supply:
+ description: Digital core voltage.
+
+ '#sound-dai-cells':
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tlv320aic3x_i2c: audio-codec@1b {
+ compatible = "ti,tlv320aic3x";
+ reg = <0x1b>;
+
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+
+ AVDD-supply = <®ulator>;
+ IOVDD-supply = <®ulator>;
+ DRVDD-supply = <®ulator>;
+ DVDD-supply = <®ulator>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tlv320aic3x_spi: audio-codec@0 {
+ compatible = "ti,tlv320aic3x";
+ reg = <0>; /* CS number */
+ #sound-dai-cells = <0>;
+
+ AVDD-supply = <®ulator>;
+ IOVDD-supply = <®ulator>;
+ DRVDD-supply = <®ulator>;
+ DVDD-supply = <®ulator>;
+ ai3x-ocmv = <0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
deleted file mode 100644
index 20931a6..0000000
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Texas Instruments - tlv320aic3x Codec module
-
-The tlv320aic3x serial control bus communicates through both I2C and SPI bus protocols
-
-Required properties:
-
-- compatible - "string" - One of:
- "ti,tlv320aic3x" - Generic TLV320AIC3x device
- "ti,tlv320aic33" - TLV320AIC33
- "ti,tlv320aic3007" - TLV320AIC3007
- "ti,tlv320aic3106" - TLV320AIC3106
- "ti,tlv320aic3104" - TLV320AIC3104
-
-
-- reg - <int> - I2C slave address
-
-
-Optional properties:
-
-- reset-gpios - GPIO specification for the active low RESET input.
-- ai3x-gpio-func - <array of 2 int> - AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
- - Not supported on tlv320aic3104
-- ai3x-micbias-vg - MicBias Voltage required.
- 1 - MICBIAS output is powered to 2.0V,
- 2 - MICBIAS output is powered to 2.5V,
- 3 - MICBIAS output is connected to AVDD,
- If this node is not mentioned or if the value is incorrect, then MicBias
- is powered down.
-- ai3x-ocmv - Output Common-Mode Voltage selection:
- 0 - 1.35V,
- 1 - 1.5V,
- 2 - 1.65V,
- 3 - 1.8V
-- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the
- device as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
-Deprecated properties:
-
-- gpio-reset - gpio pin number used for codec reset
-
-CODEC output pins:
- * LLOUT
- * RLOUT
- * MONO_LOUT
- * HPLOUT
- * HPROUT
- * HPLCOM
- * HPRCOM
-
-CODEC input pins for TLV320AIC3104:
- * MIC2L
- * MIC2R
- * LINE1L
- * LINE1R
-
-CODEC input pins for other compatible codecs:
- * MIC3L
- * MIC3R
- * LINE1L
- * LINE2L
- * LINE1R
- * LINE2R
-
-The pins can be used in referring sound node's audio-routing property.
-
-I2C example:
-
-#include <dt-bindings/gpio/gpio.h>
-
-tlv320aic3x: tlv320aic3x@1b {
- compatible = "ti,tlv320aic3x";
- reg = <0x1b>;
-
- reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
-
- AVDD-supply = <®ulator>;
- IOVDD-supply = <®ulator>;
- DRVDD-supply = <®ulator>;
- DVDD-supply = <®ulator>;
-};
-
-SPI example:
-
-spi0: spi@f0000000 {
- tlv320aic3x: codec@0 {
- compatible = "ti,tlv320aic3x";
- reg = <0>; /* CS number */
- #sound-dai-cells = <0>;
- spi-max-frequency = <1000000>;
-
- AVDD-supply = <®ulator>;
- IOVDD-supply = <®ulator>;
- DRVDD-supply = <®ulator>;
- DVDD-supply = <®ulator>;
- ai3x-ocmv = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
index f1176a2..eb0567b 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
@@ -7,7 +7,7 @@
title: Allwinner A10 SPI Controller
allOf:
- - $ref: "spi-controller.yaml"
+ - $ref: spi-controller.yaml
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
index 58b7056..acf2185 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
@@ -7,7 +7,7 @@
title: Allwinner A31 SPI Controller
allOf:
- - $ref: "spi-controller.yaml"
+ - $ref: spi-controller.yaml
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
index 53eb656..4e28e6e 100644
--- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson SPI Communication Controller
@@ -41,7 +41,7 @@
maxItems: 2
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
- if:
properties:
compatible:
@@ -100,17 +100,17 @@
examples:
- |
spi@c1108d80 {
- compatible = "amlogic,meson-gx-spicc";
- reg = <0xc1108d80 0x80>;
- interrupts = <112>;
- clocks = <&clk81>;
- clock-names = "core";
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "amlogic,meson-gx-spicc";
+ reg = <0xc1108d80 0x80>;
+ interrupts = <112>;
+ clocks = <&clk81>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
- display@0 {
- compatible = "lg,lg4573";
- spi-max-frequency = <1000000>;
- reg = <0>;
- };
+ display@0 {
+ compatible = "lg,lg4573";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
index ac3b2ec..8e769cc 100644
--- a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson SPI Flash Controller
@@ -11,7 +11,7 @@
- Neil Armstrong <neil.armstrong@linaro.org>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
description: |
The Meson SPIFC is a controller optimized for communication with SPI
@@ -40,15 +40,15 @@
examples:
- |
spi@c1108c80 {
- compatible = "amlogic,meson6-spifc";
- reg = <0xc1108c80 0x80>;
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "amlogic,meson6-spifc";
+ reg = <0xc1108c80 0x80>;
+ clocks = <&clk81>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- flash: flash@0 {
- compatible = "spansion,m25p80", "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <40000000>;
- };
+ flash: flash@0 {
+ compatible = "spansion,m25p80", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
index e6c817d..57d932a 100644
--- a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
+++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
@@ -15,7 +15,7 @@
SPI) of the AST2400, AST2500 and AST2600 SOCs.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
@@ -60,23 +60,23 @@
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
flash@0 {
- reg = < 0 >;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <50000000>;
- spi-rx-bus-width = <2>;
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
};
flash@1 {
- reg = < 1 >;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <50000000>;
- spi-rx-bus-width = <2>;
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
};
flash@2 {
- reg = < 2 >;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <50000000>;
- spi-rx-bus-width = <2>;
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
};
};
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml
new file mode 100644
index 0000000..6554978
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/brcm,bcm63xx-hsspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Broadband SoC High Speed SPI controller
+
+maintainers:
+ - William Zhang <william.zhang@broadcom.com>
+ - Kursad Oney <kursad.oney@broadcom.com>
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+description: |
+ Broadcom Broadband SoC supports High Speed SPI master controller since the
+ early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0
+ controller was carried over to recent ARM based chips, such as BCM63138,
+ BCM4908 and BCM6858. The old MIPS based chip should continue to use the
+ brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to
+ use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as
+ defined below to match the specific chip along with ip revision info.
+
+ This rev 1.0 controller has a limitation that can not keep the chip select line
+ active between the SPI transfers within the same SPI message. This can
+ terminate the transaction to some SPI devices prematurely. The issue can be
+ worked around by either the controller's prepend mode or using the dummy chip
+ select workaround. Driver automatically picks the suitable mode based on
+ transfer type so it is transparent to the user.
+
+ The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI
+ controller rev 1.1 that add the capability to allow the driver to control chip
+ select explicitly. This solves the issue in the old controller.
+
+properties:
+ compatible:
+ oneOf:
+ - const: brcm,bcm6328-hsspi
+ - items:
+ - enum:
+ - brcm,bcm47622-hsspi
+ - brcm,bcm4908-hsspi
+ - brcm,bcm63138-hsspi
+ - brcm,bcm63146-hsspi
+ - brcm,bcm63148-hsspi
+ - brcm,bcm63158-hsspi
+ - brcm,bcm63178-hsspi
+ - brcm,bcm6846-hsspi
+ - brcm,bcm6856-hsspi
+ - brcm,bcm6858-hsspi
+ - brcm,bcm6878-hsspi
+ - const: brcm,bcmbca-hsspi-v1.0
+ - items:
+ - enum:
+ - brcm,bcm4912-hsspi
+ - brcm,bcm6756-hsspi
+ - brcm,bcm6813-hsspi
+ - brcm,bcm6855-hsspi
+ - const: brcm,bcmbca-hsspi-v1.1
+
+ reg:
+ items:
+ - description: main registers
+ - description: miscellaneous control registers
+ minItems: 1
+
+ reg-names:
+ items:
+ - const: hsspi
+ - const: spim-ctrl
+ minItems: 1
+
+ clocks:
+ items:
+ - description: SPI master reference clock
+ - description: SPI master pll clock
+
+ clock-names:
+ items:
+ - const: hsspi
+ - const: pll
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm6328-hsspi
+ - brcm,bcmbca-hsspi-v1.0
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
+ else:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+ reg-names:
+ minItems: 2
+ maxItems: 2
+ required:
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ spi@ff801000 {
+ compatible = "brcm,bcm6756-hsspi", "brcm,bcmbca-hsspi-v1.1";
+ reg = <0xff801000 0x1000>,
+ <0xff802610 0x4>;
+ reg-names = "hsspi", "spim-ctrl";
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&hsspi>, <&hsspi_pll>;
+ clock-names = "hsspi", "pll";
+ num-cs = <8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
index ec58739..28222aa 100644
--- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
@@ -99,98 +99,98 @@
examples:
- | # BRCMSTB SoC: SPI Master (MSPI+BSPI) for SPI-NOR access
spi@f03e3400 {
- compatible = "brcm,spi-brcmstb-qspi", "brcm,spi-bcm-qspi";
- reg = <0xf03e3400 0x188>, <0xf03e3200 0x50>, <0xf03e0920 0x4>;
- reg-names = "mspi", "bspi", "cs_reg";
- interrupts = <0x5>, <0x6>, <0x1>, <0x2>, <0x3>, <0x4>, <0x0>;
- interrupt-parent = <&gic>;
- interrupt-names = "mspi_done",
- "mspi_halted",
- "spi_lr_fullness_reached",
- "spi_lr_session_aborted",
- "spi_lr_impatient",
- "spi_lr_session_done",
- "spi_lr_overread";
- clocks = <&hif_spi>;
- #address-cells = <0x1>;
- #size-cells = <0x0>;
+ compatible = "brcm,spi-brcmstb-qspi", "brcm,spi-bcm-qspi";
+ reg = <0xf03e3400 0x188>, <0xf03e3200 0x50>, <0xf03e0920 0x4>;
+ reg-names = "mspi", "bspi", "cs_reg";
+ interrupts = <0x5>, <0x6>, <0x1>, <0x2>, <0x3>, <0x4>, <0x0>;
+ interrupt-parent = <&gic>;
+ interrupt-names = "mspi_done",
+ "mspi_halted",
+ "spi_lr_fullness_reached",
+ "spi_lr_session_aborted",
+ "spi_lr_impatient",
+ "spi_lr_session_done",
+ "spi_lr_overread";
+ clocks = <&hif_spi>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
- flash@0 {
- #size-cells = <0x2>;
- #address-cells = <0x2>;
- compatible = "m25p80";
- reg = <0x0>;
- spi-max-frequency = <0x2625a00>;
- spi-cpol;
- spi-cpha;
- };
+ flash@0 {
+ #size-cells = <0x2>;
+ #address-cells = <0x2>;
+ compatible = "m25p80";
+ reg = <0x0>;
+ spi-max-frequency = <0x2625a00>;
+ spi-cpol;
+ spi-cpha;
+ };
};
- | # BRCMSTB SoC: MSPI master for any SPI device
spi@f0416000 {
- clocks = <&upg_fixed>;
- compatible = "brcm,spi-brcmstb-mspi", "brcm,spi-bcm-qspi";
- reg = <0xf0416000 0x180>;
- reg-names = "mspi";
- interrupts = <0x14>;
- interrupt-parent = <&irq0_aon_intc>;
- interrupt-names = "mspi_done";
- #address-cells = <1>;
- #size-cells = <0>;
+ clocks = <&upg_fixed>;
+ compatible = "brcm,spi-brcmstb-mspi", "brcm,spi-bcm-qspi";
+ reg = <0xf0416000 0x180>;
+ reg-names = "mspi";
+ interrupts = <0x14>;
+ interrupt-parent = <&irq0_aon_intc>;
+ interrupt-names = "mspi_done";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
- | # iProc SoC
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@18027200 {
- compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
- reg = <0x18027200 0x184>,
- <0x18027000 0x124>,
- <0x1811c408 0x004>,
- <0x180273a0 0x01c>;
- reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
- interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "mspi_done",
- "mspi_halted",
- "spi_lr_fullness_reached",
- "spi_lr_session_aborted",
- "spi_lr_impatient",
- "spi_lr_session_done";
- clocks = <&iprocmed>;
- num-cs = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
+ reg = <0x18027200 0x184>,
+ <0x18027000 0x124>,
+ <0x1811c408 0x004>,
+ <0x180273a0 0x01c>;
+ reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mspi_done",
+ "mspi_halted",
+ "spi_lr_fullness_reached",
+ "spi_lr_session_aborted",
+ "spi_lr_impatient",
+ "spi_lr_session_done";
+ clocks = <&iprocmed>;
+ num-cs = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
- | # NS2 SoC
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@66470200 {
- compatible = "brcm,spi-ns2-qspi", "brcm,spi-bcm-qspi";
- reg = <0x66470200 0x184>,
- <0x66470000 0x124>,
- <0x67017408 0x004>,
- <0x664703a0 0x01c>;
- reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
- interrupts = <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "spi_l1_intr";
- clocks = <&iprocmed>;
- num-cs = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "brcm,spi-ns2-qspi", "brcm,spi-bcm-qspi";
+ reg = <0x66470200 0x184>,
+ <0x66470000 0x124>,
+ <0x67017408 0x004>,
+ <0x664703a0 0x01c>;
+ reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
+ interrupts = <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "spi_l1_intr";
+ clocks = <&iprocmed>;
+ num-cs = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "m25p80";
- reg = <0x0>;
- spi-max-frequency = <12500000>;
- spi-cpol;
- spi-cpha;
- };
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p80";
+ reg = <0x0>;
+ spi-max-frequency = <12500000>;
+ spi-cpol;
+ spi-cpha;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index 4707294..5c01db1 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -47,7 +47,7 @@
cdns,fifo-depth:
description:
Size of the data FIFO in words.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [ 128, 256 ]
default: 128
@@ -103,21 +103,21 @@
examples:
- |
qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa00000 0x1000>;
- interrupts = <0 151 4>;
- clocks = <&qspi_clk>;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x00000000>;
- resets = <&rst 0x1>, <&rst 0x2>;
- reset-names = "qspi", "qspi-ocp";
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff705000 0x1000>,
+ <0xffa00000 0x1000>;
+ interrupts = <0 151 4>;
+ clocks = <&qspi_clk>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ resets = <&rst 0x1>, <&rst 0x2>;
+ reset-names = "qspi", "qspi-ocp";
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0x0>;
- };
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
index b8bb8a3..eb0f924 100644
--- a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
@@ -2,8 +2,8 @@
# Copyright 2020-21 Cadence
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/cdns,xspi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/cdns,xspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence XSPI Controller
@@ -16,7 +16,7 @@
read/write access to slaves such as SPI-NOR flash.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
index e586445..f2dd203 100644
--- a/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
@@ -10,7 +10,7 @@
- Han Xu <han.xu@nxp.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
index 12cb767..2f593c7 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
@@ -10,7 +10,7 @@
- Shawn Guo <shawnguo@kernel.org>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
index 8d2a6c0..b624988 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
@@ -10,7 +10,7 @@
- Leilk Liu <leilk.liu@mediatek.com>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml
index 6e6e02c..1e5e89a 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml
@@ -18,14 +18,12 @@
using the accompanying ECC engine. There should be only one spi
slave device following generic spi bindings.
-allOf:
- - $ref: /schemas/spi/spi-controller.yaml#
-
properties:
compatible:
enum:
- mediatek,mt7622-snand
- mediatek,mt7629-snand
+ - mediatek,mt7986-snand
reg:
items:
@@ -36,19 +34,20 @@
- description: NFI interrupt
clocks:
- items:
- - description: clock used for the controller
- - description: clock used for the SPI bus
+ minItems: 2
+ maxItems: 3
clock-names:
- items:
- - const: nfi_clk
- - const: pad_clk
+ minItems: 2
+ maxItems: 3
nand-ecc-engine:
description: device-tree node of the accompanying ECC engine.
$ref: /schemas/types.yaml#/definitions/phandle
+ mediatek,rx-latch-latency-ns:
+ description: Data read latch latency, unit is nanoseconds.
+
required:
- compatible
- reg
@@ -57,6 +56,43 @@
- clock-names
- nand-ecc-engine
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt7622-snand
+ - mediatek,mt7629-snand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: clock used for the controller
+ - description: clock used for the SPI bus
+ clock-names:
+ items:
+ - const: nfi_clk
+ - const: pad_clk
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt7986-snand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: clock used for the controller
+ - description: clock used for the SPI bus
+ - description: clock used for the AHB bus
+ clock-names:
+ items:
+ - const: nfi_clk
+ - const: pad_clk
+ - const: nfi_hclk
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml
index 7977799..d19c9f7 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml
@@ -10,7 +10,7 @@
- Leilk Liu <leilk.liu@mediatek.com>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml b/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
index 3fd0a8a..303f6dc 100644
--- a/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
@@ -11,7 +11,7 @@
- Bert Vermeulen <bert@biot.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
index a3aa5e0..221fe6e 100644
--- a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
@@ -10,7 +10,7 @@
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.yaml b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
index 51f8c66..e251216 100644
--- a/Documentation/devicetree/bindings/spi/mxs-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
@@ -10,7 +10,7 @@
- Marek Vasut <marex@denx.de>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
index 899100e..9ae1611 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
@@ -11,7 +11,7 @@
- Jonathan Hunter <jonathanh@nvidia.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
@@ -74,25 +74,25 @@
#include <dt-bindings/reset/tegra210-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@70410000 {
- compatible = "nvidia,tegra210-qspi";
- reg = <0x70410000 0x1000>;
- interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car TEGRA210_CLK_QSPI>,
- <&tegra_car TEGRA210_CLK_QSPI_PM>;
- clock-names = "qspi", "qspi_out";
- resets = <&tegra_car 211>;
- dmas = <&apbdma 5>, <&apbdma 5>;
- dma-names = "rx", "tx";
+ compatible = "nvidia,tegra210-qspi";
+ reg = <0x70410000 0x1000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car TEGRA210_CLK_QSPI>,
+ <&tegra_car TEGRA210_CLK_QSPI_PM>;
+ clock-names = "qspi", "qspi_out";
+ resets = <&tegra_car 211>;
+ dmas = <&apbdma 5>, <&apbdma 5>;
+ dma-names = "rx", "tx";
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <104000000>;
- spi-tx-bus-width = <2>;
- spi-rx-bus-width = <2>;
- nvidia,tx-clk-tap-delay = <0>;
- nvidia,rx-clk-tap-delay = <0>;
- };
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <104000000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ nvidia,tx-clk-tap-delay = <0>;
+ nvidia,rx-clk-tap-delay = <0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
index b622bb7..ee8f7ea 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/qcom,spi-qcom-qspi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/qcom,spi-qcom-qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Quad Serial Peripheral Interface (QSPI)
@@ -53,6 +52,11 @@
- const: qspi-config
- const: qspi-memory
+ operating-points-v2: true
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -88,7 +92,6 @@
spi-tx-bus-width = <2>;
spi-rx-bus-width = <2>;
};
-
};
};
...
diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml
index 2f938c2..70330d9 100644
--- a/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml
@@ -11,7 +11,7 @@
- Birger Koblitz <mail@birger-koblitz.de>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
index f45d3b7..4d8ec69 100644
--- a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
@@ -141,15 +141,15 @@
#include <dt-bindings/power/r8a7791-sysc.h>
qspi: spi@e6b10000 {
- compatible = "renesas,qspi-r8a7791", "renesas,qspi";
- reg = <0xe6b10000 0x2c>;
- interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 917>;
- dmas = <&dmac0 0x17>, <&dmac0 0x18>, <&dmac1 0x17>, <&dmac1 0x18>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
- resets = <&cpg 917>;
- num-cs = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "renesas,qspi-r8a7791", "renesas,qspi";
+ reg = <0xe6b10000 0x2c>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 917>;
+ dmas = <&dmac0 0x17>, <&dmac0 0x18>, <&dmac1 0x17>, <&dmac1 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 917>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
index d33b72f..a132b5f 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -10,7 +10,7 @@
- Mark Brown <broonie@kernel.org>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt b/Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt
deleted file mode 100644
index 37b29ee..0000000
--- a/Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Binding for Broadcom BCM6328 High Speed SPI controller
-
-Required properties:
-- compatible: must contain of "brcm,bcm6328-hsspi".
-- reg: Base address and size of the controllers memory area.
-- interrupts: Interrupt for the SPI block.
-- clocks: phandles of the SPI clock and the PLL clock.
-- clock-names: must be "hsspi", "pll".
-- #address-cells: <1>, as required by generic SPI binding.
-- #size-cells: <0>, also as required by generic SPI binding.
-
-Optional properties:
-- num-cs: some controllers have less than 8 cs signals. Defaults to 8
- if absent.
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
- spi@10001000 {
- compatible = "brcm,bcm6328-hsspi";
- reg = <0x10001000 0x600>;
-
- interrupts = <29>;
-
- clocks = <&clkctl 9>, <&hsspi_pll>;
- clock-names = "hsspi", "pll";
-
- num-cs = <2>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
index 64bf4e6..b0f83b5 100644
--- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
@@ -10,7 +10,7 @@
- Michal Simek <michal.simek@xilinx.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
index 94caa2b..e914250 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
@@ -10,7 +10,7 @@
- Anson Huang <Anson.Huang@nxp.com>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.yaml b/Documentation/devicetree/bindings/spi/spi-gpio.yaml
index f29b890..9ce1df9 100644
--- a/Documentation/devicetree/bindings/spi/spi-gpio.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-gpio.yaml
@@ -14,7 +14,7 @@
dedicated GPIO lines.
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -41,7 +41,7 @@
num-chipselects:
description: Number of chipselect lines. Should be <0> if a single device
with no chip select is connected.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
# Deprecated properties
gpio-sck: false
diff --git a/Documentation/devicetree/bindings/spi/spi-mux.yaml b/Documentation/devicetree/bindings/spi/spi-mux.yaml
index 7ea79f6..fb2a603 100644
--- a/Documentation/devicetree/bindings/spi/spi-mux.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-mux.yaml
@@ -30,8 +30,8 @@
+------------+
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
- - $ref: "/schemas/spi/spi-peripheral-props.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
index 1b552c2..a813c97 100644
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
@@ -11,7 +11,7 @@
- Kuldeep Singh <singh.kuldeep87k@gmail.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
index 9a60c06..782a014 100644
--- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
@@ -49,6 +49,16 @@
Delay in nanoseconds to be introduced by the controller after CS is
asserted.
+ spi-cs-hold-delay-ns:
+ description:
+ Delay in nanoseconds to be introduced by the controller before CS is
+ de-asserted.
+
+ spi-cs-inactive-delay-ns:
+ description:
+ Delay in nanoseconds to be introduced by the controller after CS is
+ de-asserted.
+
spi-rx-bus-width:
description:
Bus width to the SPI bus used for read transfers.
diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
index 0e38211..91e540a 100644
--- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
@@ -10,7 +10,7 @@
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
@@ -45,7 +45,7 @@
description: delay in ms following transfer completion before the
runtime power management system suspends the device. A setting of 0
indicates no delay and the device will be suspended immediately.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
pl022,rt:
description: indicates the controller should run the message pump with realtime
@@ -81,7 +81,7 @@
properties:
pl022,interface:
description: SPI interface type
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum:
- 0 # SPI
- 1 # Texas Instruments Synchronous Serial Frame Format
@@ -89,7 +89,7 @@
pl022,com-mode:
description: Specifies the transfer mode
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum:
- 0 # interrupt mode
- 1 # polling mode
@@ -98,30 +98,30 @@
pl022,rx-level-trig:
description: Rx FIFO watermark level
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 4
pl022,tx-level-trig:
description: Tx FIFO watermark level
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 4
pl022,ctrl-len:
description: Microwire interface - Control length
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0x03
maximum: 0x1f
pl022,wait-state:
description: Microwire interface - Wait state
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
pl022,duplex:
description: Microwire interface - Full/Half duplex
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
required:
diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 66e4994..e4941e9 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -11,7 +11,7 @@
as flash and display controllers using the SPI communication interface.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
maintainers:
- Heiko Stuebner <heiko@sntech.de>
diff --git a/Documentation/devicetree/bindings/spi/spi-sifive.yaml b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
index 6e7e394..5bffefb 100644
--- a/Documentation/devicetree/bindings/spi/spi-sifive.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
@@ -12,7 +12,7 @@
- Palmer Dabbelt <palmer@sifive.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
@@ -51,14 +51,14 @@
sifive,fifo-depth:
description:
Depth of hardware queues; defaults to 8
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [8]
default: 8
sifive,max-bits-per-word:
description:
Maximum bits per word; defaults to 8
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4, 5, 6, 7, 8]
default: 8
diff --git a/Documentation/devicetree/bindings/spi/spi-st-ssc.txt b/Documentation/devicetree/bindings/spi/spi-st-ssc.txt
deleted file mode 100644
index 1bdc470..0000000
--- a/Documentation/devicetree/bindings/spi/spi-st-ssc.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-STMicroelectronics SSC (SPI) Controller
----------------------------------------
-
-Required properties:
-- compatible : "st,comms-ssc4-spi"
-- reg : Offset and length of the device's register set
-- interrupts : The interrupt specifier
-- clock-names : Must contain "ssc"
-- clocks : Must contain an entry for each name in clock-names
- See ../clk/*
-- pinctrl-names : Uses "default", can use "sleep" if provided
- See ../pinctrl/pinctrl-bindings.txt
-
-Optional properties:
-- cs-gpios : List of GPIO chip selects
- See ../spi/spi-bus.txt
-
-Child nodes represent devices on the SPI bus
- See ../spi/spi-bus.txt
-
-Example:
- spi@9840000 {
- compatible = "st,comms-ssc4-spi";
- reg = <0x9840000 0x110>;
- interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>;
- clock-names = "ssc";
- pinctrl-0 = <&pinctrl_spi0_default>;
- pinctrl-names = "default";
- cs-gpios = <&pio17 5 0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- st95hf@0{
- compatible = "st,st95hf";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml
index 3a58cf0..edb5ba7 100644
--- a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml
@@ -8,7 +8,7 @@
title: Sunplus sp7021 SPI controller
allOf:
- - $ref: "spi-controller.yaml"
+ - $ref: spi-controller.yaml
maintainers:
- Li-hao Kuo <lhjeff911@gmail.com>
@@ -59,9 +59,9 @@
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi@9C002D80 {
+ spi@9c002d80 {
compatible = "sunplus,sp7021-spi";
- reg = <0x9C002D80 0x80>, <0x9C002E00 0x80>;
+ reg = <0x9c002d80 0x80>, <0x9c002e00 0x80>;
reg-names = "master", "slave";
interrupt-parent = <&intc>;
interrupt-names = "dma_w",
diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
index bbb7356..6bd8383 100644
--- a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
@@ -10,7 +10,7 @@
- Michal Simek <michal.simek@xilinx.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
index 546c416..20f7724 100644
--- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
@@ -10,7 +10,7 @@
- Michal Simek <michal.simek@xilinx.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml
index a3ab1a1..903b06f 100644
--- a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml
+++ b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/sprd,spi-adi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/sprd,spi-adi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Spreadtrum ADI controller
diff --git a/Documentation/devicetree/bindings/spi/st,ssc-spi.yaml b/Documentation/devicetree/bindings/spi/st,ssc-spi.yaml
new file mode 100644
index 0000000..6a77cd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/st,ssc-spi.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/st,ssc-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SSC SPI Controller
+
+description: |
+ The STMicroelectronics SSC SPI controller can be found on STi platforms
+ and it used to communicate with external devices using the
+ Serial Peripheral Interface.
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: st,comms-ssc4-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ssc
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ spi@9840000 {
+ compatible = "st,comms-ssc4-spi";
+ reg = <0x9840000 0x110>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+ clock-names = "ssc";
+ pinctrl-0 = <&pinctrl_spi0_default>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
index 1eb17f7..8bba965 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
@@ -11,7 +11,7 @@
- Patrice Chotard <patrice.chotard@foss.st.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
index 1cda15f..9ca1a84 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
@@ -17,7 +17,7 @@
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
- if:
properties:
compatible:
@@ -84,18 +84,17 @@
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
spi@4000b000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "st,stm32h7-spi";
- reg = <0x4000b000 0x400>;
- interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&rcc SPI2_K>;
- resets = <&rcc SPI2_R>;
- dmas = <&dmamux1 0 39 0x400 0x05>,
- <&dmamux1 1 40 0x400 0x05>;
- dma-names = "rx", "tx";
- cs-gpios = <&gpioa 11 0>;
-
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32h7-spi";
+ reg = <0x4000b000 0x400>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc SPI2_K>;
+ resets = <&rcc SPI2_R>;
+ dmas = <&dmamux1 0 39 0x400 0x05>,
+ <&dmamux1 1 40 0x400 0x05>;
+ dma-names = "rx", "tx";
+ cs-gpios = <&gpioa 11 0>;
};
...
diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
index 1f1c40a..83e8fb4 100644
--- a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
@@ -11,7 +11,7 @@
memory devices.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
maintainers:
- Michal Simek <michal.simek@xilinx.com>
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 665c06e..ba694ce 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -26,6 +26,7 @@
- qcom,sdm845-imem
- qcom,sdx55-imem
- qcom,sdx65-imem
+ - qcom,sm8450-imem
- const: syscon
- const: simple-mfd
diff --git a/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml b/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml
new file mode 100644
index 0000000..fe9ae4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/mediatek,lvts-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SoC Low Voltage Thermal Sensor (LVTS)
+
+maintainers:
+ - Balsam CHIHI <bchihi@baylibre.com>
+
+description: |
+ LVTS is a thermal management architecture composed of three subsystems,
+ a Sensing device - Thermal Sensing Micro Circuit Unit (TSMCU),
+ a Converter - Low Voltage Thermal Sensor converter (LVTS), and
+ a Digital controller (LVTS_CTRL).
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8192-lvts-ap
+ - mediatek,mt8192-lvts-mcu
+ - mediatek,mt8195-lvts-ap
+ - mediatek,mt8195-lvts-mcu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+ description: LVTS reset for clearing temporary data on AP/MCU.
+
+ nvmem-cells:
+ minItems: 1
+ items:
+ - description: Calibration eFuse data 1 for LVTS
+ - description: Calibration eFuse data 2 for LVTS
+
+ nvmem-cell-names:
+ minItems: 1
+ items:
+ - const: lvts-calib-data-1
+ - const: lvts-calib-data-2
+
+ "#thermal-sensor-cells":
+ const: 1
+
+allOf:
+ - $ref: thermal-sensor.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8192-lvts-ap
+ - mediatek,mt8192-lvts-mcu
+ then:
+ properties:
+ nvmem-cells:
+ maxItems: 1
+
+ nvmem-cell-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8195-lvts-ap
+ - mediatek,mt8195-lvts-mcu
+ then:
+ properties:
+ nvmem-cells:
+ minItems: 2
+
+ nvmem-cell-names:
+ minItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - nvmem-cells
+ - nvmem-cell-names
+ - "#thermal-sensor-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/reset/mt8195-resets.h>
+ #include <dt-bindings/thermal/mediatek,lvts-thermal.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ lvts_mcu: thermal-sensor@11278000 {
+ compatible = "mediatek,mt8195-lvts-mcu";
+ reg = <0 0x11278000 0 0x1000>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&infracfg_ao CLK_INFRA_AO_THERM>;
+ resets = <&infracfg_ao MT8195_INFRA_RST4_THERM_CTRL_MCU_SWRST>;
+ nvmem-cells = <&lvts_efuse_data1 &lvts_efuse_data2>;
+ nvmem-cell-names = "lvts-calib-data-1", "lvts-calib-data-2";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
+ thermal_zones: thermal-zones {
+ cpu0-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&lvts_mcu MT8195_MCU_LITTLE_CPU0>;
+
+ trips {
+ cpu0_alert: trip-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu0_crit: trip-crit {
+ temperature = <100000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
index d20569b..52ec18c 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
@@ -13,6 +13,7 @@
enum:
- qcom,spmi-adc-tm5
- qcom,spmi-adc-tm5-gen2
+ - qcom,adc-tm7 # Incomplete / subject to change
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 0231f18..926e9c5 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -37,6 +37,7 @@
- description: v1 of TSENS
items:
- enum:
+ - qcom,msm8956-tsens
- qcom,msm8976-tsens
- qcom,qcs404-tsens
- const: qcom,tsens-v1
@@ -80,18 +81,120 @@
maxItems: 2
nvmem-cells:
- minItems: 1
- maxItems: 2
- description:
- Reference to an nvmem node for the calibration data
+ oneOf:
+ - minItems: 1
+ maxItems: 2
+ description:
+ Reference to an nvmem node for the calibration data
+ - minItems: 5
+ maxItems: 35
+ description: |
+ Reference to nvmem cells for the calibration mode, two calibration
+ bases and two cells per each sensor
+ # special case for msm8974 / apq8084
+ - maxItems: 51
+ description: |
+ Reference to nvmem cells for the calibration mode, two calibration
+ bases and two cells per each sensor, main and backup copies, plus use_backup cell
nvmem-cell-names:
- minItems: 1
- items:
- - const: calib
- - enum:
- - calib_backup
- - calib_sel
+ oneOf:
+ - minItems: 1
+ items:
+ - const: calib
+ - enum:
+ - calib_backup
+ - calib_sel
+ - minItems: 5
+ items:
+ - const: mode
+ - const: base1
+ - const: base2
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ # special case for msm8974 / apq8084
+ - items:
+ - const: mode
+ - const: base1
+ - const: base2
+ - const: use_backup
+ - const: mode_backup
+ - const: base1_backup
+ - const: base2_backup
+ - const: s0_p1
+ - const: s0_p2
+ - const: s1_p1
+ - const: s1_p2
+ - const: s2_p1
+ - const: s2_p2
+ - const: s3_p1
+ - const: s3_p2
+ - const: s4_p1
+ - const: s4_p2
+ - const: s5_p1
+ - const: s5_p2
+ - const: s6_p1
+ - const: s6_p2
+ - const: s7_p1
+ - const: s7_p2
+ - const: s8_p1
+ - const: s8_p2
+ - const: s9_p1
+ - const: s9_p2
+ - const: s10_p1
+ - const: s10_p2
+ - const: s0_p1_backup
+ - const: s0_p2_backup
+ - const: s1_p1_backup
+ - const: s1_p2_backup
+ - const: s2_p1_backup
+ - const: s2_p2_backup
+ - const: s3_p1_backup
+ - const: s3_p2_backup
+ - const: s4_p1_backup
+ - const: s4_p2_backup
+ - const: s5_p1_backup
+ - const: s5_p2_backup
+ - const: s6_p1_backup
+ - const: s6_p2_backup
+ - const: s7_p1_backup
+ - const: s7_p2_backup
+ - const: s8_p1_backup
+ - const: s8_p2_backup
+ - const: s9_p1_backup
+ - const: s9_p2_backup
+ - const: s10_p1_backup
+ - const: s10_p2_backup
"#qcom,sensors":
description:
@@ -222,6 +325,36 @@
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ // Example 1 (new calbiration data: for pre v1 IP):
+ thermal-sensor@900000 {
+ compatible = "qcom,msm8916-tsens", "qcom,tsens-v0_1";
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
+
+ nvmem-cells = <&tsens_mode>,
+ <&tsens_base1>, <&tsens_base2>,
+ <&tsens_s0_p1>, <&tsens_s0_p2>,
+ <&tsens_s1_p1>, <&tsens_s1_p2>,
+ <&tsens_s2_p1>, <&tsens_s2_p2>,
+ <&tsens_s4_p1>, <&tsens_s4_p2>,
+ <&tsens_s5_p1>, <&tsens_s5_p2>;
+ nvmem-cell-names = "mode",
+ "base1", "base2",
+ "s0_p1", "s0_p2",
+ "s1_p1", "s1_p2",
+ "s2_p1", "s2_p2",
+ "s4_p1", "s4_p2",
+ "s5_p1", "s5_p2";
+
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow";
+
+ #qcom,sensors = <5>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
// Example 1 (legacy: for pre v1 IP):
tsens1: thermal-sensor@900000 {
compatible = "qcom,msm8916-tsens", "qcom,tsens-v0_1";
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
index 0f05f5c..ecf276f 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
@@ -28,6 +28,7 @@
- renesas,r8a77980-thermal # R-Car V3H
- renesas,r8a779a0-thermal # R-Car V3U
- renesas,r8a779f0-thermal # R-Car S4-8
+ - renesas,r8a779g0-thermal # R-Car V4H
reg: true
@@ -80,6 +81,7 @@
- description: TSC1 registers
- description: TSC2 registers
- description: TSC3 registers
+ - description: TSC4 registers
if:
not:
properties:
@@ -87,6 +89,7 @@
contains:
enum:
- renesas,r8a779f0-thermal
+ - renesas,r8a779g0-thermal
then:
required:
- interrupts
diff --git a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
index c5b25ce..6f97582 100644
--- a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
@@ -46,14 +46,9 @@
- |
// The UniPhier thermal should be a subnode of a "syscon" compatible node.
- sysctrl@61840000 {
- compatible = "socionext,uniphier-ld20-sysctrl",
- "simple-mfd", "syscon";
- reg = <0x61840000 0x10000>;
-
- pvtctl: thermal {
- compatible = "socionext,uniphier-ld20-thermal";
- interrupts = <0 3 1>;
- #thermal-sensor-cells = <0>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pvtctl: thermal-sensor {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ #thermal-sensor-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
index 8bbb6e94..b3e797e 100644
--- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
@@ -33,6 +33,7 @@
For those SoCs that use CPUX
* "mediatek,mt6795-systimer" for MT6795 compatible timers (CPUX)
+ * "mediatek,mt8365-systimer" for MT8365 compatible timers (CPUX)
- reg: Should contain location and length for timer register.
- clocks: Should contain system clock.
diff --git a/Documentation/devicetree/bindings/timer/qcom,msm-timer.txt b/Documentation/devicetree/bindings/timer/qcom,msm-timer.txt
deleted file mode 100644
index 5e10c34..0000000
--- a/Documentation/devicetree/bindings/timer/qcom,msm-timer.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* MSM Timer
-
-Properties:
-
-- compatible : Should at least contain "qcom,msm-timer". More specific
- properties specify which subsystem the timers are paired with.
-
- "qcom,kpss-timer" - krait subsystem
- "qcom,scss-timer" - scorpion subsystem
-
-- interrupts : Interrupts for the debug timer, the first general purpose
- timer, and optionally a second general purpose timer, and
- optionally as well, 2 watchdog interrupts, in that order.
-
-- reg : Specifies the base address of the timer registers.
-
-- clocks: Reference to the parent clocks, one per output clock. The parents
- must appear in the same order as the clock names.
-
-- clock-names: The name of the clocks as free-form strings. They should be in
- the same order as the clocks.
-
-- clock-frequency : The frequency of the debug timer and the general purpose
- timer(s) in Hz in that order.
-
-Optional:
-
-- cpu-offset : per-cpu offset used when the timer is accessed without the
- CPU remapping facilities. The offset is
- cpu-offset + (0x10000 * cpu-nr).
-
-Example:
-
- timer@200a000 {
- compatible = "qcom,scss-timer", "qcom,msm-timer";
- interrupts = <1 1 0x301>,
- <1 2 0x301>,
- <1 3 0x301>,
- <1 4 0x301>,
- <1 5 0x301>;
- reg = <0x0200a000 0x100>;
- clock-frequency = <19200000>,
- <32768>;
- clocks = <&sleep_clk>;
- clock-names = "sleep";
- cpu-offset = <0x40000>;
- };
diff --git a/Documentation/devicetree/bindings/timer/riscv,timer.yaml b/Documentation/devicetree/bindings/timer/riscv,timer.yaml
new file mode 100644
index 0000000..38d67e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/riscv,timer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/riscv,timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V timer
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |+
+ RISC-V platforms always have a RISC-V timer device for the supervisor-mode
+ based on the time CSR defined by the RISC-V privileged specification. The
+ timer interrupts of this device are configured using the RISC-V SBI Time
+ extension or the RISC-V Sstc extension.
+
+ The clock frequency of RISC-V timer device is specified via the
+ "timebase-frequency" DT property of "/cpus" DT node which is described
+ in Documentation/devicetree/bindings/riscv/cpus.yaml
+
+properties:
+ compatible:
+ enum:
+ - riscv,timer
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4096 # Should be enough?
+
+ riscv,timer-cannot-wake-cpu:
+ type: boolean
+ description:
+ If present, the timer interrupt cannot wake up the CPU from one or
+ more suspend/idle states.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - interrupts-extended
+
+examples:
+ - |
+ timer {
+ compatible = "riscv,timer";
+ interrupts-extended = <&cpu1intc 5>,
+ <&cpu2intc 5>,
+ <&cpu3intc 5>,
+ <&cpu4intc 5>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
index b61ed1a..65e5983 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
@@ -17,6 +17,7 @@
- items:
- enum:
- rockchip,rv1108-timer
+ - rockchip,rv1126-timer
- rockchip,rk3036-timer
- rockchip,rk3128-timer
- rockchip,rk3188-timer
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index bbad241..aada695 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -20,6 +20,10 @@
property of "/cpus" DT node. The "timebase-frequency" DT property is
described in Documentation/devicetree/bindings/riscv/cpus.yaml
+ T-Head C906/C910 CPU cores include an implementation of CLINT too, however
+ their implementation lacks a memory-mapped MTIME register, thus not
+ compatible with SiFive ones.
+
properties:
compatible:
oneOf:
@@ -30,6 +34,10 @@
- canaan,k210-clint
- const: sifive,clint0
- items:
+ - enum:
+ - allwinner,sun20i-d1-clint
+ - const: thead,c900-clint
+ - items:
- const: sifive,clint0
- const: riscv,clint0
deprecated: true
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index f5c0a62..6f482a2 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -65,6 +65,8 @@
- capella,cm3232
# CM3323: Ambient Light Sensor
- capella,cm3323
+ # Cisco SPI Petra
+ - cisco,spi-petra
# High-Precision Digital Thermometer
- dallas,ds1631
# Total-Elapsed-Time Recorder with Alarm
@@ -141,6 +143,8 @@
- infineon,slb9645tt
# Infineon SLB9673 I2C TPM 2.0
- infineon,slb9673
+ # Infineon TDA38640 Voltage Regulator
+ - infineon,tda38640
# Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
- infineon,tlv493d-a1b6
# Infineon Multi-phase Digital VR Controller xdpe11280
@@ -169,6 +173,8 @@
- isil,isl29030
# Intersil ISL68137 Digital Output Configurable PWM Controller
- isil,isl68137
+ # Linear Technology LTC2488
+ - lineartechnology,ltc2488
# 5 Bit Programmable, Pulse-Width Modulator
- maxim,ds1050
# 10 kOhm digital potentiometer with I2C interface
@@ -227,6 +233,8 @@
- memsic,mxc6655
# Menlo on-board CPLD trivial SPI device
- menlo,m53cpld
+ # Micron SPI NOR Authenta
+ - micron,spi-authenta
# Microchip differential I2C ADC, 1 Channel, 18 bit
- microchip,mcp3421
# Microchip differential I2C ADC, 2 Channel, 18 bit
@@ -305,10 +313,14 @@
- pulsedlight,lidar-lite-v2
# Renesas ISL29501 time-of-flight sensor
- renesas,isl29501
+ # Rohm DH2228FV
+ - rohm,dh2228fv
# S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
- samsung,24ad0xd1
# Samsung Exynos SoC SATA PHY I2C device
- samsung,exynos-sataphy-i2c
+ # Semtech sx1301 baseband processor
+ - semtech,sx1301
# Sensirion low power multi-pixel gas sensor with I2C interface
- sensirion,sgpc3
# Sensirion multi-pixel gas sensor with I2C interface
@@ -323,6 +335,10 @@
- sensortek,stk8ba50
# SGX Sensortech VZ89X Sensors
- sgx,vz89x
+ # Silicon Labs EM3581 Zigbee SoC with SPI interface
+ - silabs,em3581
+ # Silicon Labs SI3210 Programmable CMOS SLIC/CODEC with SPI interface
+ - silabs,si3210
# Relative Humidity and Temperature Sensors
- silabs,si7020
# Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index f2d6298..c5a06c0 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -33,6 +33,7 @@
- qcom,sm8250-ufshc
- qcom,sm8350-ufshc
- qcom,sm8450-ufshc
+ - qcom,sm8550-ufshc
- const: qcom,ufshc
- const: jedec,ufs-2.0
@@ -44,6 +45,8 @@
minItems: 8
maxItems: 11
+ dma-coherent: true
+
interconnects:
minItems: 2
maxItems: 2
@@ -71,6 +74,9 @@
minItems: 1
maxItems: 2
+ required-opps:
+ maxItems: 1
+
resets:
maxItems: 1
@@ -103,6 +109,7 @@
- qcom,sm8250-ufshc
- qcom,sm8350-ufshc
- qcom,sm8450-ufshc
+ - qcom,sm8550-ufshc
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml b/Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml
new file mode 100644
index 0000000..36a8ae7
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/sprd,ums9620-ufs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc Universal Flash Storage (UFS) Controller
+
+maintainers:
+ - Zhe Wang <zhe.wang1@unisoc.com>
+
+allOf:
+ - $ref: ufs-common.yaml
+
+properties:
+ compatible:
+ const: sprd,ums9620-ufs
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: controller_eb
+ - const: cfg_eb
+ - const: core
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: controller
+ - const: device
+
+ vdd-mphy-supply:
+ description:
+ Phandle to vdd-mphy supply regulator node.
+
+ sprd,ufs-anlg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of syscon used to control ufs analog regs.
+
+ sprd,aon-apb-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of syscon used to control always-on regs.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ufs: ufs@22000000 {
+ compatible = "sprd,ums9620-ufs";
+ reg = <0x22000000 0x3000>;
+ interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+ vcc-supply = <&vddemmccore>;
+ vdd-mphy-supply = <&vddufs1v2>;
+ clocks = <&apahb_gate 5>, <&apahb_gate 22>, <&aonapb_clk 52>;
+ clock-names = "controller_eb", "cfg_eb", "core";
+ assigned-clocks = <&aonapb_clk 52>;
+ assigned-clock-parents = <&g5l_pll 12>;
+ resets = <&apahb_gate 4>, <&aonapb_gate 69>;
+ reset-names = "controller", "device";
+ sprd,ufs-anlg-syscon = <&anlg_phy_g12_regs>;
+ sprd,aon-apb-syscon = <&aon_apb_regs>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index 8992eff..f972ce9 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -13,10 +13,12 @@
properties:
compatible:
oneOf:
- - const: allwinner,sun4i-a10-musb
- - const: allwinner,sun6i-a31-musb
- - const: allwinner,sun8i-a33-musb
- - const: allwinner,sun8i-h3-musb
+ - enum:
+ - allwinner,sun4i-a10-musb
+ - allwinner,sun6i-a31-musb
+ - allwinner,sun8i-a33-musb
+ - allwinner,sun8i-h3-musb
+ - allwinner,suniv-f1c100s-musb
- items:
- enum:
- allwinner,sun8i-a83t-musb
diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
index daf2a85..f38a2be 100644
--- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
+++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
@@ -108,6 +108,7 @@
then:
properties:
phy-names:
+ minItems: 2
items:
- const: usb2-phy0 # USB2 PHY0 if USBHOST_A port is used
- const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used
diff --git a/Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt b/Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt
deleted file mode 100644
index 452c45c..0000000
--- a/Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* Broadcom USB controllers
-
-Required properties:
-- compatible: "brcm,bcm3384-ohci", "brcm,bcm3384-ehci"
-
- These currently use the generic-ohci and generic-ehci drivers. On some
- systems, special handling may be needed in the following cases:
-
- - Restoring state after systemwide power save modes
- - Sharing PHYs with the USBD (UDC) hardware
- - Figuring out which controllers are disabled on ASIC bondout variants
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index ba51fb1..72ceea5 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -11,6 +11,7 @@
"fsl,imx6ul-usb"
"fsl,imx7d-usb"
"fsl,imx7ulp-usb"
+ "fsl,imx8mm-usb"
"lsi,zevio-usb"
"qcom,ci-hdrc"
"chipidea,usb2"
diff --git a/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
new file mode 100644
index 0000000..75eec4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/cypress,cypd4226.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress cypd4226 Type-C Controller
+
+maintainers:
+ - Wayne Chang <waynec@nvidia.com>
+
+description:
+ The Cypress cypd4226 is a dual Type-C controller that is controlled
+ via an I2C interface.
+
+properties:
+ compatible:
+ const: cypress,cypd4226
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ const: 0x08
+
+ interrupts:
+ items:
+ - description: cypd4226 host interrupt
+
+ firmware-name:
+ enum:
+ - nvidia,gpu
+ - nvidia,jetson-agx-xavier
+ description: |
+ The name of the CCGx firmware built for product series.
+ should be set one of following:
+ - "nvidia,gpu" for the NVIDIA RTX product series
+ - "nvidia,jetson-agx-xavier" for the NVIDIA Jetson product series
+
+patternProperties:
+ '^connector@[01]$':
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+anyOf:
+ - required:
+ - connector@0
+ - required:
+ - connector@1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/tegra194-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+
+ typec@8 {
+ compatible = "cypress,cypd4226";
+ reg = <0x08>;
+ interrupt-parent = <&gpio_aon>;
+ interrupts = <TEGRA194_AON_GPIO(BB, 2) IRQ_TYPE_LEVEL_LOW>;
+ firmware-name = "nvidia,jetson-agx-xavier";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ label = "USB-C";
+ data-role = "dual";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&usb_role_switch0>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt
deleted file mode 100644
index d77e11a..0000000
--- a/Documentation/devicetree/bindings/usb/ehci-omap.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OMAP HS USB EHCI controller
-
-This device is usually the child of the omap-usb-host
-Documentation/devicetree/bindings/mfd/omap-usb-host.txt
-
-Required properties:
-
-- compatible: should be "ti,ehci-omap"
-- reg: should contain one register range i.e. start and length
-- interrupts: description of the interrupt line
-
-Optional properties:
-
-- phys: list of phandles to PHY nodes.
- This property is required if at least one of the ports are in
- PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
-
-To specify the port mode, see
-Documentation/devicetree/bindings/mfd/omap-usb-host.txt
-
-Example for OMAP4:
-
-usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap";
- reg = <0x4a064c00 0x400>;
- interrupts = <0 77 0x4>;
-};
-
-&usbhsehci {
- phys = <&hsusb1_phy 0 &hsusb3_phy>;
-};
diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt b/Documentation/devicetree/bindings/usb/ehci-orion.txt
deleted file mode 100644
index 2855bae..0000000
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* EHCI controller, Orion Marvell variants
-
-Required properties:
-- compatible: must be one of the following
- "marvell,orion-ehci"
- "marvell,armada-3700-ehci"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The EHCI interrupt
-
-Optional properties:
-- clocks: reference to the clock
-- phys: reference to the USB PHY
-- phy-names: name of the USB PHY, should be "usb"
-
-Example:
-
- ehci@50000 {
- compatible = "marvell,orion-ehci";
- reg = <0x50000 0x1000>;
- interrupts = <19>;
- };
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml b/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml
index 84b3b692..3fe4d15 100644
--- a/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/usb/faraday,fotg210.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Faraday Technology FOTG210 HS OTG USB 2.0 controller
+title: Faraday Technology FOTG200 series HS OTG USB 2.0 controller
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -17,10 +17,11 @@
properties:
compatible:
oneOf:
+ - const: faraday,fotg200
- const: faraday,fotg210
- items:
- const: cortina,gemini-usb
- - const: faraday,fotg210
+ - const: faraday,fotg200
reg:
maxItems: 1
@@ -66,7 +67,7 @@
#include <dt-bindings/clock/cortina,gemini-clock.h>
#include <dt-bindings/reset/cortina,gemini-reset.h>
usb0: usb@68000000 {
- compatible = "cortina,gemini-usb", "faraday,fotg210";
+ compatible = "cortina,gemini-usb", "faraday,fotg200";
reg = <0x68000000 0x1000>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
resets = <&syscon GEMINI_RESET_USB0>;
diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
index 9473f26..51120fe 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
+++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
@@ -51,7 +51,7 @@
#address-cells = <1>;
#size-cells = <0>;
- fsa4480@42 {
+ typec-mux@42 {
compatible = "fcs,fsa4480";
reg = <0x42>;
diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
deleted file mode 100644
index 60e4654..0000000
--- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Fairchild FUSB302 Type-C Port controllers
-
-Required properties :
-- compatible : "fcs,fusb302"
-- reg : I2C slave address
-- interrupts : Interrupt specifier
-
-Required sub-node:
-- connector : The "usb-c-connector" attached to the FUSB302 IC. The bindings
- of the connector node are specified in:
-
- Documentation/devicetree/bindings/connector/usb-connector.yaml
-
-
-Example:
-
-fusb302: typec-portc@54 {
- compatible = "fcs,fusb302";
- reg = <0x54>;
- interrupt-parent = <&nmi_intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- power-role = "dual";
- try-power-role = "sink";
- source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
- PDO_VAR(3000, 12000, 3000)
- PDO_PPS_APDO(3000, 11000, 3000)>;
- op-sink-microwatt = <10000000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.yaml b/Documentation/devicetree/bindings/usb/fcs,fusb302.yaml
new file mode 100644
index 0000000..b396ea0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fcs,fusb302.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fairchild FUSB302 Type-C Port controller
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+properties:
+ compatible:
+ const: fcs,fusb302
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vbus-supply:
+ description: VBUS power supply
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vbus-supply
+ - connector
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/usb/pd.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-portc@54 {
+ compatible = "fcs,fusb302";
+ reg = <0x54>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ vbus-supply = <&vbus_typec>;
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(3000, 12000, 3000)
+ PDO_PPS_APDO(3000, 11000, 3000)>;
+ op-sink-microwatt = <10000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index 01ab0f922..3fb4feb 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -71,6 +71,9 @@
description:
Power pad (PWR) polarity is active low.
+ power-domains:
+ maxItems: 1
+
# Required child node:
patternProperties:
@@ -87,12 +90,14 @@
- clocks
- clock-names
- interrupts
+ - power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/power/imx8mp-power.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
usb3_0: usb@32f10100 {
compatible = "fsl,imx8mp-dwc3";
@@ -102,6 +107,7 @@
<&clk IMX8MP_CLK_USB_ROOT>;
clock-names = "hsio", "suspend";
interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB>;
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x40000000 0x40000000 0xc0000000>;
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 994818c..050cfd5 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -74,6 +74,11 @@
- const: usb-ehci
- enum:
- generic-ehci
+ - marvell,armada-3700-ehci
+ - marvell,orion-ehci
+ - nuvoton,npcm750-ehci
+ - nuvoton,npcm845-ehci
+ - ti,ehci-omap
- usb-ehci
reg:
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index 4fcbd0a..a9ba725 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -6,9 +6,6 @@
title: USB OHCI Controller
-allOf:
- - $ref: "usb-hcd.yaml"
-
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -49,7 +46,16 @@
- ingenic,jz4740-ohci
- snps,hsdk-v1.0-ohci
- const: generic-ohci
- - const: generic-ohci
+ - enum:
+ - generic-ohci
+ - ti,ohci-omap3
+ - items:
+ - enum:
+ - cavium,octeon-6335-ohci
+ - nintendo,hollywood-usb-ohci
+ - nxp,ohci-nxp
+ - st,spear600-ohci
+ - const: usb-ohci
reg:
maxItems: 1
@@ -119,11 +125,29 @@
- host
- otg
+ transceiver:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The associated ISP1301 device. Necessary for the UDC controller for
+ connecting to the USB physical layer.
+
required:
- compatible
- reg
- interrupts
+allOf:
+ - $ref: usb-hcd.yaml
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: nxp,ohci-nxp
+ then:
+ properties:
+ transceiver: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
index a9f8314..cc4cf92 100644
--- a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
+++ b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
@@ -16,6 +16,7 @@
compatible:
enum:
- usb5e3,608
+ - usb5e3,610
reg: true
diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
new file mode 100644
index 0000000..bf4b1d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: GPIO-based SBU mux
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ In USB Type-C applications the SBU lines needs to be connected, disconnected
+ and swapped depending on the altmode and orientation. This binding describes
+ a family of hardware solutions which switches between these modes using GPIO
+ signals.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - onnn,fsusb43l10x
+ - pericom,pi3usb102
+ - const: gpio-sbu-mux
+
+ enable-gpios:
+ description: Switch enable GPIO
+
+ select-gpios:
+ description: Orientation select
+
+ vcc-supply:
+ description: power supply
+
+ mode-switch:
+ description: Flag the port as possible handle of altmode switching
+ type: boolean
+
+ orientation-switch:
+ description: Flag the port as possible handler of orientation switching
+ type: boolean
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the SBU mux to a TypeC controller for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - enable-gpios
+ - select-gpios
+ - mode-switch
+ - orientation-switch
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ tcpm {
+ connector {
+ compatible = "usb-c-connector";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tcpm_hs_out: endpoint {
+ remote-endpoint = <&usb_hs_phy_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ tcpm_ss_out: endpoint {
+ remote-endpoint = <&usb_ss_phy_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ tcpm_sbu_out: endpoint {
+ remote-endpoint = <&sbu_mux_in>;
+ };
+ };
+ };
+ };
+ };
+
+ sbu-mux {
+ compatible = "pericom,pi3usb102", "gpio-sbu-mux";
+
+ enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
+ select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ sbu_mux_in: endpoint {
+ remote-endpoint = <&tcpm_sbu_out>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index a3c3794..c119caa 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -35,6 +35,7 @@
- mediatek,mt8188-xhci
- mediatek,mt8192-xhci
- mediatek,mt8195-xhci
+ - mediatek,mt8365-xhci
- const: mediatek,mtk-xhci
reg:
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
index 7168110..d265517 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
@@ -28,6 +28,7 @@
- mediatek,mt8188-mtu3
- mediatek,mt8192-mtu3
- mediatek,mt8195-mtu3
+ - mediatek,mt8365-mtu3
- const: mediatek,mtu3
reg:
diff --git a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
deleted file mode 100644
index 352a0a1..0000000
--- a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Nuvoton NPCM7XX SoC USB controllers:
------------------------------
-
-EHCI:
------
-
-Required properties:
-- compatible: should be one of
- "nuvoton,npcm750-ehci"
- "nuvoton,npcm845-ehci"
-- interrupts: Should contain the EHCI interrupt
-- reg: Physical address and length of the register set for the device
-
-Example:
-
- ehci1: usb@f0806000 {
- compatible = "nuvoton,npcm750-ehci";
- reg = <0xf0806000 0x1000>;
- interrupts = <0 61 4>;
- };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
index f6cb19e..e638f77 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
@@ -22,6 +22,7 @@
- nvidia,tegra210-xudc # For Tegra210
- nvidia,tegra186-xudc # For Tegra186
- nvidia,tegra194-xudc # For Tegra194
+ - nvidia,tegra234-xudc # For Tegra234
reg:
minItems: 2
@@ -112,6 +113,8 @@
hvdd-usb-supply:
description: USB controller power supply. Must supply 3.3 V.
+ dma-coherent: true
+
required:
- compatible
- reg
@@ -153,6 +156,7 @@
enum:
- nvidia,tegra186-xudc
- nvidia,tegra194-xudc
+ - nvidia,tegra234-xudc
then:
properties:
reg:
@@ -164,6 +168,17 @@
clock-names:
maxItems: 4
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-xudc
+ - nvidia,tegra234-xudc
+ then:
+ required:
+ - dma-coherent
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
new file mode 100644
index 0000000..db761dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra234-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by
+ the Tegra XUSB pad controller. The xHCI controller controls up to eight
+ ports; there are four USB 2.0 ports and four USB 3.2 Gen1 x1 ports.
+
+properties:
+ compatible:
+ const: nvidia,tegra234-xusb
+
+ reg:
+ items:
+ - description: xHCI host registers
+ - description: XUSB FPCI registers
+ - description: XUSB bar2 registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+ - const: bar2
+
+ interrupts:
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+
+ clocks:
+ items:
+ - description: XUSB host clock
+ - description: XUSB Falcon source clock
+ - description: XUSB SuperSpeed clock
+ - description: XUSB SuperSpeed source clock
+ - description: XUSB HighSpeed clock source
+ - description: XUSB FullSpeed clock source
+ - description: USB PLL
+ - description: reference clock
+ - description: I/O PLL
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ interconnects:
+ items:
+ - description: read client
+ - description: write client
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
+
+ iommus:
+ maxItems: 1
+
+ nvidia,xusb-padctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+
+ phys:
+ minItems: 1
+ maxItems: 8
+
+ phy-names:
+ minItems: 1
+ maxItems: 8
+ items:
+ enum:
+ - usb2-0
+ - usb2-1
+ - usb2-2
+ - usb2-3
+ - usb3-0
+ - usb3-1
+ - usb3-2
+ - usb3-3
+
+ power-domains:
+ items:
+ - description: XUSBC power domain (for Host and USB 2.0)
+ - description: XUSBA power domain (for SuperSpeed)
+
+ power-domain-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+
+ dma-coherent: true
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra234-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/power/tegra234-powergate.h>
+
+ usb@3610000 {
+ compatible = "nvidia,tegra234-xusb";
+ reg = <0x03610000 0x40000>,
+ <0x03600000 0x10000>,
+ <0x03650000 0x10000>;
+ reg-names = "hcd", "fpci", "bar2";
+
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&bpmp TEGRA234_CLK_XUSB_CORE_HOST>,
+ <&bpmp TEGRA234_CLK_XUSB_FALCON>,
+ <&bpmp TEGRA234_CLK_XUSB_CORE_SS>,
+ <&bpmp TEGRA234_CLK_XUSB_SS>,
+ <&bpmp TEGRA234_CLK_CLK_M>,
+ <&bpmp TEGRA234_CLK_XUSB_FS>,
+ <&bpmp TEGRA234_CLK_UTMIP_PLL>,
+ <&bpmp TEGRA234_CLK_CLK_M>,
+ <&bpmp TEGRA234_CLK_PLLE>;
+ clock-names = "xusb_host", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_src", "xusb_hs_src",
+ "xusb_fs_src", "pll_u_480m", "clk_m",
+ "pll_e";
+ interconnects = <&mc TEGRA234_MEMORY_CLIENT_XUSB_HOSTR &emc>,
+ <&mc TEGRA234_MEMORY_CLIENT_XUSB_HOSTW &emc>;
+ interconnect-names = "dma-mem", "write";
+ iommus = <&smmu_niso1 TEGRA234_SID_XUSB_HOST>;
+
+ power-domains = <&bpmp TEGRA234_POWER_DOMAIN_XUSBC>,
+ <&bpmp TEGRA234_POWER_DOMAIN_XUSBA>;
+ power-domain-names = "xusb_host", "xusb_ss";
+
+ nvidia,xusb-padctl = <&xusb_padctl>;
+
+ phys = <&pad_lanes_usb2_0>;
+ phy-names = "usb2-0";
+ };
diff --git a/Documentation/devicetree/bindings/usb/ohci-nxp.txt b/Documentation/devicetree/bindings/usb/ohci-nxp.txt
deleted file mode 100644
index 71e28c1..0000000
--- a/Documentation/devicetree/bindings/usb/ohci-nxp.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* OHCI controller, NXP ohci-nxp variant
-
-Required properties:
-- compatible: must be "nxp,ohci-nxp"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The OHCI interrupt
-- transceiver: phandle of the associated ISP1301 device - this is necessary for
- the UDC controller for connecting to the USB physical layer
-
-Example (LPC32xx):
-
- isp1301: usb-transceiver@2c {
- compatible = "nxp,isp1301";
- reg = <0x2c>;
- };
-
- ohci@31020000 {
- compatible = "nxp,ohci-nxp";
- reg = <0x31020000 0x300>;
- interrupt-parent = <&mic>;
- interrupts = <0x3b 0>;
- transceiver = <&isp1301>;
- };
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
deleted file mode 100644
index ce8c47cff..0000000
--- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-OMAP HS USB OHCI controller (OMAP3 and later)
-
-Required properties:
-
-- compatible: should be "ti,ohci-omap3"
-- reg: should contain one register range i.e. start and length
-- interrupts: description of the interrupt line
-
-Example for OMAP4:
-
-usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3";
- reg = <0x4a064800 0x400>;
- interrupts = <0 76 0x4>;
-};
diff --git a/Documentation/devicetree/bindings/usb/pxa-usb.txt b/Documentation/devicetree/bindings/usb/pxa-usb.txt
index 9c33179..53fdae4 100644
--- a/Documentation/devicetree/bindings/usb/pxa-usb.txt
+++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt
@@ -22,7 +22,7 @@
Example:
usb0: ohci@4c000000 {
- compatible = "marvell,pxa-ohci", "usb-ohci";
+ compatible = "marvell,pxa-ohci";
reg = <0x4c000000 0x100000>;
interrupts = <18>;
marvell,enable-port1;
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index a3f8a3f..4875c5b 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -58,6 +58,9 @@
description: specifies a phandle to PM domain provider node
maxItems: 1
+ required-opps:
+ maxItems: 1
+
clocks:
description: |
Several clocks are used, depending on the variant. Typical ones are::
diff --git a/Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml b/Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml
new file mode 100644
index 0000000..b6e84a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/renesas,rzn1-usbf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/N1 SoCs USBF (USB Function) controller
+
+description: |
+ The Renesas USBF controller is an USB2.0 device
+ controller (UDC).
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a06g032-usbf
+ - const: renesas,rzn1-usbf
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Internal bus clock (AHB) for Function
+ - description: Internal bus clock (AHB) for Power Management
+
+ clock-names:
+ items:
+ - const: hclkf
+ - const: hclkpm
+
+ power-domains:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: The USBF EPC interrupt
+ - description: The USBF AHB-EPC interrupt
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+
+ usb@4001e000 {
+ compatible = "renesas,r9a06g032-usbf", "renesas,rzn1-usbf";
+ reg = <0x4001e000 0x2000>;
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_HCLK_USBF>,
+ <&sysctrl R9A06G032_HCLK_USBPM>;
+ clock-names = "hclkf", "hclkpm";
+ power-domains = <&sysctrl>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml b/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml
new file mode 100644
index 0000000..ff62560
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/renesas,rzv2m-usb3drd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M USB 3.1 DRD controller
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The RZ/V2{M, MA} USB3.1 DRD module supports the following functions
+ * Role swapping function by the ID pin of the Micro-AB receptacle
+ * Battery Charging Specification Revision 1.2
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a09g011-usb3drd # RZ/V2M
+ - renesas,r9a09g055-usb3drd # RZ/V2MA
+ - const: renesas,rzv2m-usb3drd
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Dual Role Device (DRD)
+ - description: Battery Charging
+ - description: Global Purpose Input
+
+ interrupt-names:
+ items:
+ - const: drd
+ - const: bc
+ - const: gpi
+
+ clocks:
+ items:
+ - description: Peripheral AXI clock
+ - description: APB clock
+
+ clock-names:
+ items:
+ - const: axi
+ - const: reg
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ enum: [ 1, 2 ]
+
+ '#size-cells':
+ enum: [ 1, 2 ]
+
+patternProperties:
+ "^usb3peri@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/usb/renesas,usb3-peri.yaml
+
+ "^usb@[0-9a-f]+$":
+ type: object
+ $ref: renesas,usb-xhci.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a09g011-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb3drd: usb@85070400 {
+ compatible = "renesas,r9a09g011-usb3drd", "renesas,rzv2m-usb3drd";
+ reg = <0x85070400 0x100>;
+ interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "drd", "bc", "gpi";
+ clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_P>,
+ <&cpg CPG_MOD R9A09G011_USB_PCLK>;
+ clock-names = "axi", "reg";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A09G011_USB_DRD_RESET>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usb3host: usb@85060000 {
+ compatible = "renesas,r9a09g011-xhci",
+ "renesas,rzv2m-xhci";
+ reg = <0x85060000 0x2000>;
+ interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_H>,
+ <&cpg CPG_MOD R9A09G011_USB_PCLK>;
+ clock-names = "axi", "reg";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A09G011_USB_ARESETN_H>;
+ };
+
+ usb3peri: usb3peri@85070000 {
+ compatible = "renesas,r9a09g011-usb3-peri",
+ "renesas,rzv2m-usb3-peri";
+ reg = <0x85070000 0x400>;
+ interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_P>,
+ <&cpg CPG_MOD R9A09G011_USB_PCLK>;
+ clock-names = "axi", "reg";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A09G011_USB_ARESETN_P>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
index 4c5efaf..1a07c0d 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
@@ -10,9 +10,6 @@
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
-allOf:
- - $ref: "usb-xhci.yaml"
-
properties:
compatible:
oneOf:
@@ -37,6 +34,11 @@
- renesas,xhci-r8a77965 # R-Car M3-N
- renesas,xhci-r8a77990 # R-Car E3
- const: renesas,rcar-gen3-xhci # R-Car Gen3 and RZ/G2
+ - items:
+ - enum:
+ - renesas,r9a09g011-xhci # RZ/V2M
+ - renesas,r9a09g055-xhci # RZ/V2MA
+ - const: renesas,rzv2m-xhci # RZ/{V2M, V2MA}
reg:
maxItems: 1
@@ -45,7 +47,16 @@
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Main clock for host
+ - description: Register access clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: axi
+ - const: reg
phys:
maxItems: 1
@@ -68,6 +79,28 @@
- power-domains
- resets
+allOf:
+ - $ref: usb-xhci.yaml
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rzv2m-xhci
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ required:
+ - clock-names
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
index 55dfd12..b2b811a 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
@@ -28,26 +28,14 @@
- items:
- enum:
- renesas,r9a09g011-usb3-peri # RZ/V2M
+ - renesas,r9a09g055-usb3-peri # RZ/V2MA
- const: renesas,rzv2m-usb3-peri
reg:
maxItems: 1
interrupts:
- minItems: 1
- items:
- - description: Combined interrupt for DMA, SYS and ERR
- - description: Dual Role Device (DRD)
- - description: Battery Charging
- - description: Global Purpose Input
-
- interrupt-names:
- minItems: 1
- items:
- - const: all_p
- - const: drd
- - const: bc
- - const: gpi
+ maxItems: 1
clocks:
minItems: 1
@@ -58,7 +46,7 @@
clock-names:
minItems: 1
items:
- - const: aclk
+ - const: axi
- const: reg
phys:
@@ -71,15 +59,7 @@
maxItems: 1
resets:
- minItems: 1
- items:
- - description: Peripheral reset
- - description: DRD reset
-
- reset-names:
- items:
- - const: aresetn_p
- - const: drd_reset
+ maxItems: 1
usb-role-switch:
$ref: /schemas/types.yaml#/definitions/flag
@@ -127,25 +107,13 @@
minItems: 2
clock-names:
minItems: 2
- interrupts:
- minItems: 4
- interrupt-names:
- minItems: 4
- resets:
- minItems: 2
required:
- clock-names
- - interrupt-names
- resets
- - reset-names
else:
properties:
clocks:
maxItems: 1
- interrupts:
- maxItems: 1
- resets:
- maxItems: 1
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
index b3798d9..291844c 100644
--- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
@@ -29,7 +29,6 @@
contains:
enum:
- rockchip,rk3328-dwc3
- - rockchip,rk3399-dwc3
- rockchip,rk3568-dwc3
required:
- compatible
@@ -39,7 +38,6 @@
items:
- enum:
- rockchip,rk3328-dwc3
- - rockchip,rk3399-dwc3
- rockchip,rk3568-dwc3
- const: snps,dwc3
@@ -90,7 +88,7 @@
examples:
- |
- #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/clock/rk3328-cru.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
bus {
@@ -98,11 +96,11 @@
#size-cells = <2>;
usbdrd3_0: usb@fe800000 {
- compatible = "rockchip,rk3399-dwc3", "snps,dwc3";
+ compatible = "rockchip,rk3328-dwc3", "snps,dwc3";
reg = <0x0 0xfe800000 0x0 0x100000>;
interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
- <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
+ <&cru ACLK_USB3OTG>;
clock-names = "ref_clk", "suspend_clk",
"bus_clk", "grf_clk";
dr_mode = "otg";
diff --git a/Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml
new file mode 100644
index 0000000..3159f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/rockchip,rk3399-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3399 SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-dwc3
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ ranges: true
+
+ clocks:
+ items:
+ - description:
+ Controller reference clock, must to be 24 MHz
+ - description:
+ Controller suspend clock, must to be 24 MHz or 32 KHz
+ - description:
+ Master/Core clock, must to be >= 62.5 MHz for SS
+ operation and >= 30MHz for HS operation
+ - description:
+ USB3 aclk peri
+ - description:
+ USB3 aclk
+ - description:
+ Controller grf clock
+
+ clock-names:
+ items:
+ - const: ref_clk
+ - const: suspend_clk
+ - const: bus_clk
+ - const: aclk_usb3_rksoc_axi_perf
+ - const: aclk_usb3
+ - const: grf_clk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: usb3-otg
+
+patternProperties:
+ '^usb@':
+ $ref: snps,dwc3.yaml#
+
+additionalProperties: false
+
+required:
+ - compatible
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/power/rk3399-power.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb {
+ compatible = "rockchip,rk3399-dwc3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "grf_clk";
+ resets = <&cru SRST_A_USB3_OTG0>;
+ reset-names = "usb3-otg";
+
+ usb@fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru ACLK_USB3OTG0>,
+ <&cru SCLK_USB3OTG0_SUSPEND>;
+ clock-names = "ref", "bus_early", "suspend";
+ dr_mode = "otg";
+ phys = <&u2phy0_otg>, <&tcphy0_usb3>;
+ phy-names = "usb2-phy", "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,dis-tx-ipgap-linecheck-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
index 6b9a3bc..42ceaf1 100644
--- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
@@ -108,19 +108,19 @@
#include <dt-bindings/clock/exynos5420.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- usb {
+ usb@12000000 {
compatible = "samsung,exynos5250-dwusb3";
#address-cells = <1>;
#size-cells = <1>;
- ranges;
+ ranges = <0x0 0x12000000 0x10000>;
clocks = <&clock CLK_USBD300>;
clock-names = "usbdrd30";
vdd33-supply = <&ldo9_reg>;
vdd10-supply = <&ldo11_reg>;
- usb@12000000 {
+ usb@0 {
compatible = "snps,dwc3";
- reg = <0x12000000 0x10000>;
+ reg = <0x0 0x10000>;
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
phy-names = "usb2-phy", "usb3-phy";
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 6d78048..be36956 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -91,6 +91,16 @@
- usb2-phy
- usb3-phy
+ power-domains:
+ description:
+ The DWC3 has 2 power-domains. The power management unit (PMU) and
+ everything else. The PMU is typically always powered and may not have an
+ entry.
+ minItems: 1
+ items:
+ - description: Core
+ - description: Power management unit
+
resets:
minItems: 1
diff --git a/Documentation/devicetree/bindings/usb/spear-usb.txt b/Documentation/devicetree/bindings/usb/spear-usb.txt
deleted file mode 100644
index 1dc91cc..0000000
--- a/Documentation/devicetree/bindings/usb/spear-usb.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-ST SPEAr SoC USB controllers:
------------------------------
-
-EHCI:
------
-
-Required properties:
-- compatible: "st,spear600-ehci"
-- interrupts: Should contain the EHCI interrupt
-
-Example:
-
- ehci@e1800000 {
- compatible = "st,spear600-ehci", "usb-ehci";
- reg = <0xe1800000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <27>;
- };
-
-
-OHCI:
------
-
-Required properties:
-- compatible: "st,spear600-ohci"
-- interrupts: Should contain the OHCI interrupt
-
-Example:
-
- ohci@e1900000 {
- compatible = "st,spear600-ohci", "usb-ohci";
- reg = <0xe1800000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <26>;
- };
diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
index b86bf6b..a1cffb7 100644
--- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
@@ -46,7 +46,6 @@
required:
- compatible
- reg
- - interrupts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
index fef4acd..348a715 100644
--- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
@@ -23,6 +23,8 @@
reg:
maxItems: 1
+ wakeup-source: true
+
interrupts:
maxItems: 1
@@ -48,6 +50,7 @@
tps6598x: tps6598x@38 {
compatible = "ti,tps6598x";
reg = <0x38>;
+ wakeup-source;
interrupt-parent = <&msmgpio>;
interrupts = <107 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml
index 326131d..921b986 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml
@@ -35,7 +35,7 @@
maxItems: 1
vbus-regulator:
- description: Should specifiy the regulator supplying current drawn from
+ description: Should specify the regulator supplying current drawn from
the VBus line.
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
index b796836..29b8f65 100644
--- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
@@ -8,6 +8,7 @@
"fsl,imx6sx-usbmisc" for imx6sx
"fsl,imx7d-usbmisc" for imx7d
"fsl,imx7ulp-usbmisc" for imx7ulp
+ "fsl,imx8mm-usbmisc" for imx8mm
- reg: Should contain registers location and length
Examples:
diff --git a/Documentation/devicetree/bindings/usb/vialab,vl817.yaml b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
new file mode 100644
index 0000000..23a13e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/vialab,vl817.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Via labs VL817 USB 3.1 hub controller
+
+maintainers:
+ - Anand Moon <linux.amoon@gmail.com>
+
+allOf:
+ - $ref: usb-device.yaml#
+
+properties:
+ compatible:
+ enum:
+ - usb2109,2817
+ - usb2109,817
+
+ reg: true
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the RESET# pin.
+
+ vdd-supply:
+ description:
+ phandle to the regulator that provides power to the hub.
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd-supply
+ - peer-hub
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb2109,2817";
+ reg = <1>;
+ vdd-supply = <&vcc_5v>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.1 hub on port 4 */
+ hub_3_0: hub@2 {
+ compatible = "usb2109,817";
+ reg = <2>;
+ vdd-supply = <&vcc_5v>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 70ffb37..ed64e06 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -69,6 +69,8 @@
description: Annapurna Labs
"^alcatel,.*":
description: Alcatel
+ "^aldec,.*":
+ description: Aldec, Inc.
"^alfa-network,.*":
description: ALFA Network Inc.
"^allegro,.*":
@@ -264,6 +266,8 @@
description: Cirrus Logic, Inc.
"^cisco,.*":
description: Cisco Systems, Inc.
+ "^clockwork,.*":
+ description: Clockwork Tech LLC
"^cloos,.*":
description: Carl Cloos Schweisstechnik GmbH.
"^cloudengines,.*":
@@ -374,6 +378,8 @@
description: EBV Elektronik
"^eckelmann,.*":
description: Eckelmann AG
+ "^edgeble,.*":
+ description: Edgeble AI Technologies Pvt. Ltd.
"^edimax,.*":
description: EDIMAX Technology Co., Ltd
"^edt,.*":
@@ -396,6 +402,8 @@
description: Elimo Engineering Ltd.
"^elpida,.*":
description: Elpida Memory, Inc.
+ "^embedfire,.*":
+ description: Dongguan EmbedFire Electronic Technology Co., Ltd.
"^embest,.*":
description: Shenzhen Embest Technology Co., Ltd.
"^emlid,.*":
@@ -512,6 +520,8 @@
description: Shenzhen Huiding Technology Co., Ltd.
"^google,.*":
description: Google, Inc.
+ "^gplus,.*":
+ description: GPLUS
"^grinn,.*":
description: Grinn
"^grmn,.*":
@@ -635,6 +645,8 @@
description: Inverse Path
"^iom,.*":
description: Iomega Corporation
+ "^irondevice,.*":
+ description: Iron Device Corporation
"^isee,.*":
description: ISEE 2007 S.L.
"^isil,.*":
@@ -729,6 +741,8 @@
description: Lichee Pi
"^linaro,.*":
description: Linaro Limited
+ "^lineartechnology,.*":
+ description: Linear Technology
"^linksprite,.*":
description: LinkSprite Technologies, Inc.
"^linksys,.*":
@@ -775,6 +789,8 @@
description: MaxBotix Inc.
"^maxim,.*":
description: Maxim Integrated Products
+ "^maxlinear,.*":
+ description: MaxLinear Inc.
"^mbvl,.*":
description: Mobiveil Inc.
"^mcube,.*":
@@ -845,6 +861,8 @@
description: Moortec Semiconductor Ltd.
"^mosaixtech,.*":
description: Mosaix Technologies, Inc.
+ "^motorcomm,.*":
+ description: MotorComm, Inc.
"^motorola,.*":
description: Motorola, Inc.
"^moxa,.*":
@@ -1025,6 +1043,8 @@
description: PocketBook International SA
"^polaroid,.*":
description: Polaroid Corporation
+ "^polyhex,.*":
+ description: Polyhex Technology Co. Ltd.
"^portwell,.*":
description: Portwell Inc.
"^poslab,.*":
@@ -1246,6 +1266,8 @@
description: Starry Electronic Technology (ShenZhen) Co., LTD
"^startek,.*":
description: Startek
+ "^starterkit,.*":
+ description: Starterkit
"^ste,.*":
description: ST-Ericsson
deprecated: true
@@ -1319,6 +1341,8 @@
description: thingy.jp
"^thundercomm,.*":
description: Thundercomm Technology Co., Ltd.
+ "^thwc,.*":
+ description: Shenzhen Tong Heng Wei Chuang Technology Co., Ltd.
"^ti,.*":
description: Texas Instruments
"^tianma,.*":
@@ -1372,6 +1396,8 @@
description: uCRobotics
"^udoo,.*":
description: Udoo
+ "^ufispace,.*":
+ description: Ufi Space Co., Ltd.
"^ugoos,.*":
description: Ugoos Industrial Co., Ltd.
"^uniwest,.*":
@@ -1398,6 +1424,8 @@
description: Vertexcom Technologies, Inc.
"^via,.*":
description: VIA Technologies, Inc.
+ "^vialab,.*":
+ description: VIA Labs, Inc.
"^vicor,.*":
description: Vicor Corporation
"^videostrong,.*":
@@ -1444,6 +1472,8 @@
description: Shenzhen whwave Electronics, Inc.
"^wi2wi,.*":
description: Wi2Wi, Inc.
+ "^widora,.*":
+ description: Beijing Widora Technology Co., Ltd.
"^wiligear,.*":
description: Wiligear, Ltd.
"^willsemi,.*":
diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml
new file mode 100644
index 0000000..84732cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/amlogic,meson6-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson6 SoCs Watchdog timer
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson6-wdt
+ - amlogic,meson8-wdt
+ - amlogic,meson8b-wdt
+ - items:
+ - const: amlogic,meson8m2-wdt
+ - const: amlogic,meson8b-wdt
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ wdt: watchdog@c1109900 {
+ compatible = "amlogic,meson6-wdt";
+ reg = <0xc1109900 0x8>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_EDGE_RISING>;
+ timeout-sec = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
index fb76955..181f0cc 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
@@ -9,9 +9,6 @@
maintainers:
- Anson Huang <Anson.Huang@nxp.com>
-allOf:
- - $ref: "watchdog.yaml#"
-
properties:
compatible:
oneOf:
@@ -55,11 +52,45 @@
If present, the watchdog device is configured to assert its
external reset (WDOG_B) instead of issuing a software reset.
+ fsl,suspend-in-wait:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ If present, the watchdog device is suspended in WAIT mode
+ (Suspend-to-Idle). Only supported on certain devices.
+
required:
- compatible
- interrupts
- reg
+allOf:
+ - $ref: watchdog.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx25-wdt
+ - fsl,imx35-wdt
+ - fsl,imx50-wdt
+ - fsl,imx51-wdt
+ - fsl,imx53-wdt
+ - fsl,imx6q-wdt
+ - fsl,imx6sl-wdt
+ - fsl,imx6sll-wdt
+ - fsl,imx6sx-wdt
+ - fsl,imx6ul-wdt
+ - fsl,imx7d-wdt
+ - fsl,imx8mm-wdt
+ - fsl,imx8mn-wdt
+ - fsl,imx8mp-wdt
+ - fsl,imx8mq-wdt
+ - fsl,vf610-wdt
+ then:
+ properties:
+ fsl,suspend-in-wait: false
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.yaml b/Documentation/devicetree/bindings/watchdog/gpio-wdt.yaml
new file mode 100644
index 0000000..155dc79
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/gpio-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO controlled watchdog
+
+maintainers:
+ - Robert Marko <robert.marko@sartura.hr>
+
+properties:
+ compatible:
+ const: linux,wdt-gpio
+
+ gpios:
+ maxItems: 1
+ description: GPIO connected to the WDT reset pin
+
+ hw_algo:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Algorithm used by the driver
+ oneOf:
+ - description:
+ Either a high-to-low or a low-to-high transition clears the WDT counter.
+ The watchdog timer is disabled when GPIO is left floating or connected
+ to a three-state buffer.
+ const: toggle
+ - description:
+ Low or high level starts counting WDT timeout, the opposite level
+ disables the WDT.
+ Active level is determined by the GPIO flags.
+ const: level
+
+ hw_margin_ms:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Maximum time to reset watchdog circuit (in milliseconds)
+ minimum: 2
+ maximum: 65535
+
+ always-running:
+ type: boolean
+ description:
+ If the watchdog timer cannot be disabled, add this flag to have the driver
+ keep toggling the signal without a client.
+ It will only cease to toggle the signal when the device is open and the
+ timeout elapsed.
+
+required:
+ - compatible
+ - gpios
+ - hw_algo
+ - hw_margin_ms
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
index ab9641e..38079e1 100644
--- a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
+++ b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
@@ -8,6 +8,7 @@
allOf:
- $ref: "watchdog.yaml#"
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
maintainers:
- Marc Zyngier <maz@kernel.org>
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml
index b2b17fd..a668d0c 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml
@@ -19,6 +19,12 @@
reg:
maxItems: 1
+ mediatek,sysctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to system controller 'sysc' syscon node which
+ controls system registers
+
required:
- compatible
- reg
@@ -30,4 +36,5 @@
watchdog@100 {
compatible = "mediatek,mt7621-wdt";
reg = <0x100 0x100>;
+ mediatek,sysctl = <&sysc>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index b360560..55b3446 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -52,6 +52,12 @@
description: Disable sending output reset signal
type: boolean
+ mediatek,reset-by-toprgu:
+ description: The Top Reset Generation Unit (TOPRGU) generates reset signals
+ and distributes them to each IP. If present, the watchdog timer will be
+ reset by TOPRGU once system resets.
+ type: boolean
+
'#reset-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/watchdog/meson-wdt.txt b/Documentation/devicetree/bindings/watchdog/meson-wdt.txt
deleted file mode 100644
index 7588cc3..0000000
--- a/Documentation/devicetree/bindings/watchdog/meson-wdt.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Meson SoCs Watchdog timer
-
-Required properties:
-
-- compatible : depending on the SoC this should be one of:
- "amlogic,meson6-wdt" on Meson6 SoCs
- "amlogic,meson8-wdt" and "amlogic,meson6-wdt" on Meson8 SoCs
- "amlogic,meson8b-wdt" on Meson8b SoCs
- "amlogic,meson8m2-wdt" and "amlogic,meson8b-wdt" on Meson8m2 SoCs
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-- timeout-sec: contains the watchdog timeout in seconds.
-
-Example:
-
-wdt: watchdog@c1109900 {
- compatible = "amlogic,meson6-wdt";
- reg = <0xc1109900 0x8>;
- timeout-sec = <10>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
index d8ac0be..6448b63 100644
--- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
@@ -9,15 +9,18 @@
maintainers:
- Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
-allOf:
- - $ref: watchdog.yaml#
-
properties:
+ $nodename:
+ pattern: "^(watchdog|timer)@[0-9a-f]+$"
+
compatible:
oneOf:
- items:
- enum:
+ - qcom,kpss-wdt-ipq4019
+ - qcom,apss-wdt-msm8994
- qcom,apss-wdt-qcs404
+ - qcom,apss-wdt-sa8775p
- qcom,apss-wdt-sc7180
- qcom,apss-wdt-sc7280
- qcom,apss-wdt-sc8180x
@@ -29,15 +32,19 @@
- qcom,apss-wdt-sm8150
- qcom,apss-wdt-sm8250
- const: qcom,kpss-wdt
+ - const: qcom,kpss-wdt
+ deprecated: true
+ - items:
+ - const: qcom,scss-timer
+ - const: qcom,msm-timer
- items:
- enum:
- - qcom,kpss-wdt
- - qcom,kpss-timer
- qcom,kpss-wdt-apq8064
- - qcom,kpss-wdt-ipq4019
- qcom,kpss-wdt-ipq8064
+ - qcom,kpss-wdt-mdm9615
- qcom,kpss-wdt-msm8960
- - qcom,scss-timer
+ - const: qcom,kpss-timer
+ - const: qcom,msm-timer
reg:
maxItems: 1
@@ -45,18 +52,87 @@
clocks:
maxItems: 1
+ clock-names:
+ items:
+ - const: sleep
+
+ clock-frequency:
+ description:
+ The frequency of the general purpose timer in Hz.
+
+ cpu-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Per-CPU offset used when the timer is accessed without the CPU remapping
+ facilities. The offset is cpu-offset + (0x10000 * cpu-nr).
+
+ interrupts:
+ minItems: 1
+ maxItems: 5
+
required:
- compatible
- reg
- clocks
+allOf:
+ - $ref: watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,kpss-wdt
+ then:
+ properties:
+ clock-frequency: false
+ cpu-offset: false
+ interrupts:
+ minItems: 1
+ items:
+ - description: Bark
+ - description: Bite
+
+ else:
+ properties:
+ interrupts:
+ minItems: 3
+ items:
+ - description: Debug
+ - description: First general purpose timer
+ - description: Second general purpose timer
+ - description: First watchdog
+ - description: Second watchdog
+ required:
+ - clock-frequency
+
unevaluatedProperties: false
examples:
- |
- watchdog@208a038 {
- compatible = "qcom,kpss-wdt-ipq8064";
- reg = <0x0208a038 0x40>;
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@17c10000 {
+ compatible = "qcom,apss-wdt-sm8150", "qcom,kpss-wdt";
+ reg = <0x17c10000 0x1000>;
clocks = <&sleep_clk>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
timeout-sec = <10>;
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@200a000 {
+ compatible = "qcom,kpss-wdt-ipq8064", "qcom,kpss-timer", "qcom,msm-timer";
+ interrupts = <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 5 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
+ reg = <0x0200a000 0x100>;
+ clock-frequency = <25000000>;
+ clocks = <&sleep_clk>;
+ clock-names = "sleep";
+ cpu-offset = <0x80000>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
index 26b1815..e2c9bf1 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
@@ -26,7 +26,7 @@
- items:
- enum:
- - renesas,r9a07g043-wdt # RZ/G2UL
+ - renesas,r9a07g043-wdt # RZ/G2UL and RZ/Five
- renesas,r9a07g044-wdt # RZ/G2{L,LC}
- renesas,r9a07g054-wdt # RZ/V2L
- const: renesas,rzg2l-wdt
diff --git a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
index 90698cf..70c005f 100644
--- a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
@@ -25,12 +25,6 @@
- |
// The UniPhier watchdog should be a subnode of a "syscon" compatible node.
- sysctrl@61840000 {
- compatible = "socionext,uniphier-ld11-sysctrl",
- "simple-mfd", "syscon";
- reg = <0x61840000 0x10000>;
-
- watchdog {
- compatible = "socionext,uniphier-wdt";
- };
+ watchdog {
+ compatible = "socionext,uniphier-wdt";
};
diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
index fccae0d..519b488 100644
--- a/Documentation/devicetree/bindings/watchdog/watchdog.yaml
+++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
@@ -14,9 +14,14 @@
This document describes generic bindings which can be used to
describe watchdog devices in a device tree.
+select:
+ properties:
+ $nodename:
+ pattern: "^watchdog(@.*|-[0-9a-f])?$"
+
properties:
$nodename:
- pattern: "^watchdog(@.*|-[0-9a-f])?$"
+ pattern: "^(timer|watchdog)(@.*|-[0-9a-f])?$"
timeout-sec:
description:
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 352ff53..3c399f1 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -91,7 +91,6 @@
autoconf.h*
av_permissions.h
bbootsect
-bin2c
binkernel.spec
bootsect
bounds.h
diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 622b815..2e8dfd1 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -1,5 +1,5 @@
-Buffer Sharing and Synchronization
-==================================
+Buffer Sharing and Synchronization (dma-buf)
+============================================
The dma-buf subsystem provides the framework for sharing buffers for
hardware (DMA) access across multiple device drivers and subsystems, and
@@ -264,7 +264,7 @@
randomly hangs workloads until the timeout kicks in. Workloads, which from
userspace's perspective, do not contain a deadlock. In such a mixed fencing
architecture there is no single entity with knowledge of all dependencies.
-Thefore preventing such deadlocks from within the kernel is not possible.
+Therefore preventing such deadlocks from within the kernel is not possible.
The only solution to avoid dependencies loops is by not allowing indefinite
fences in the kernel. This means:
diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
index bfd057b..ecf139f7 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -175,7 +175,7 @@
driver can ask for the pointer, maximum size and the currently used size of
the metadata and can directly update or read it.
- Becasue the DMA driver manages the memory area containing the metadata,
+ Because the DMA driver manages the memory area containing the metadata,
clients must make sure that they do not try to access or get the pointer
after their transfer completion callback has run for the descriptor.
If no completion callback has been defined for the transfer, then the
diff --git a/Documentation/driver-api/dmaengine/dmatest.rst b/Documentation/driver-api/dmaengine/dmatest.rst
index cf9859c..e2a63ce 100644
--- a/Documentation/driver-api/dmaengine/dmatest.rst
+++ b/Documentation/driver-api/dmaengine/dmatest.rst
@@ -89,7 +89,7 @@
% cat /sys/module/dmatest/parameters/run
-To wait for test completion userpace can poll 'run' until it is false, or use
+To wait for test completion userspace can poll 'run' until it is false, or use
the wait parameter. Specifying 'wait=1' when loading the module causes module
initialization to pause until a test run has completed, while reading
/sys/module/dmatest/parameters/wait waits for any running test to complete
diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst
index e17910c..a0559d9 100644
--- a/Documentation/driver-api/gpio/legacy.rst
+++ b/Documentation/driver-api/gpio/legacy.rst
@@ -387,9 +387,6 @@
/* map GPIO numbers to IRQ numbers */
int gpio_to_irq(unsigned gpio);
- /* map IRQ numbers to GPIO numbers (avoid using this) */
- int irq_to_gpio(unsigned irq);
-
Those return either the corresponding number in the other namespace, or
else a negative errno code if the mapping can't be done. (For example,
some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO
@@ -405,11 +402,6 @@
options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
system wakeup capabilities.
-Non-error values returned from irq_to_gpio() would most commonly be used
-with gpio_get_value(), for example to initialize or update driver state
-when the IRQ is edge-triggered. Note that some platforms don't support
-this reverse mapping, so you should avoid using it.
-
Emulating Open Drain Signals
----------------------------
@@ -735,10 +727,6 @@
/* reverse gpio_export() */
void gpio_unexport();
- /* create a sysfs link to an exported GPIO node */
- int gpio_export_link(struct device *dev, const char *name,
- unsigned gpio)
-
After a kernel driver requests a GPIO, it may only be made available in
the sysfs interface by gpio_export(). The driver can control whether the
signal direction may change. This helps drivers prevent userspace code
@@ -748,11 +736,6 @@
of experiments easier), or can provide an always-there interface that's
suitable for documenting as part of a board support package.
-After the GPIO has been exported, gpio_export_link() allows creating
-symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can
-use this to provide the interface under their own device in sysfs with
-a descriptive name.
-
API Reference
=============
diff --git a/Documentation/driver-api/hsi.rst b/Documentation/driver-api/hsi.rst
index f9cec02..01b6beb 100644
--- a/Documentation/driver-api/hsi.rst
+++ b/Documentation/driver-api/hsi.rst
@@ -4,7 +4,7 @@
Introduction
---------------
-High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol,
+High Speed Synchronous Interface (HSI) is a full duplex, low latency protocol,
that is optimized for die-level interconnect between an Application Processor
and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
implemented by multiple vendors since then.
@@ -52,7 +52,7 @@
------------------
Each port automatically registers a generic client driver called hsi_char,
-which provides a charecter device for userspace representing the HSI port.
+which provides a character device for userspace representing the HSI port.
It can be used to communicate via HSI from userspace. Userspace may
configure the hsi_char device using the following ioctl commands:
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index d3a58f7..ff9aa1a 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -1,6 +1,8 @@
-========================================
-The Linux driver implementer's API guide
-========================================
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Driver implementer's API guide
+==============================
The kernel offers a wide variety of interfaces to support the development
of device drivers. This document is an only somewhat organized collection
@@ -106,6 +108,7 @@
vfio-mediated-device
vfio
vfio-pci-device-specific-driver-acceptance
+ virtio/index
xilinx/index
xillybus
zorro
diff --git a/Documentation/driver-api/io-mapping.rst b/Documentation/driver-api/io-mapping.rst
index a0cfb15..7274204 100644
--- a/Documentation/driver-api/io-mapping.rst
+++ b/Documentation/driver-api/io-mapping.rst
@@ -44,7 +44,7 @@
used with mappings created by io_mapping_create_wc()
Temporary mappings are only valid in the context of the caller. The mapping
-is not guaranteed to be globaly visible.
+is not guaranteed to be globally visible.
io_mapping_map_local_wc() has a side effect on X86 32bit as it disables
migration to make the mapping code work. No caller can rely on this side
@@ -78,7 +78,7 @@
unsigned long offset)
This works like io_mapping_map_atomic/local_wc() except it has no side
-effects and the pointer is globaly visible.
+effects and the pointer is globally visible.
The mappings are released with::
diff --git a/Documentation/driver-api/md/md-cluster.rst b/Documentation/driver-api/md/md-cluster.rst
index 96eb52c..e93f35e 100644
--- a/Documentation/driver-api/md/md-cluster.rst
+++ b/Documentation/driver-api/md/md-cluster.rst
@@ -65,7 +65,7 @@
2.3 new-device management
-------------------------
- A single lock: "no-new-dev" is used to co-ordinate the addition of
+ A single lock: "no-new-dev" is used to coordinate the addition of
new devices - this must be synchronized across the array.
Normally all nodes hold a concurrent-read lock on this device.
diff --git a/Documentation/driver-api/md/raid5-cache.rst b/Documentation/driver-api/md/raid5-cache.rst
index d7a15f4..5f947cb 100644
--- a/Documentation/driver-api/md/raid5-cache.rst
+++ b/Documentation/driver-api/md/raid5-cache.rst
@@ -81,7 +81,7 @@
is organized as a simple write log. The log consists of 'meta data' and 'data'
pairs. The meta data describes the data. It also includes checksum and sequence
ID for recovery identification. Data can be IO data and parity data. Data is
-checksumed too. The checksum is stored in the meta data ahead of the data. The
+checksummed too. The checksum is stored in the meta data ahead of the data. The
checksum is an optimization because MD can write meta and data freely without
worry about the order. MD superblock has a field pointed to the valid meta data
of log head.
diff --git a/Documentation/driver-api/media/drivers/cpia2_devel.rst b/Documentation/driver-api/media/drivers/cpia2_devel.rst
deleted file mode 100644
index decaa47..0000000
--- a/Documentation/driver-api/media/drivers/cpia2_devel.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The cpia2 driver
-================
-
-Authors: Peter Pregler <Peter_Pregler@email.com>,
-Scott J. Bertin <scottbertin@yahoo.com>, and
-Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
-this one was modelled from.
-
-
-Notes to developers
-~~~~~~~~~~~~~~~~~~~
-
- - This is a driver version stripped of the 2.4 back compatibility
- and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
-
-Programmer's overview of cpia2 driver
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
-division of ST Microelectronics). There are two versions. The first is the
-STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
-up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version,
-which can handle up to 30 fps VGA. Both coprocessors can be attached to two
-CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will
-be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
-
-The two chipsets operate almost identically. The core is an 8051 processor,
-running two different versions of firmware. The 672 runs the VP4 video
-processor code, the 676 runs VP5. There are a few differences in register
-mappings for the two chips. In these cases, the symbols defined in the
-header files are marked with VP4 or VP5 as part of the symbol name.
-
-The cameras appear externally as three sets of registers. Setting register
-values is the only way to control the camera. Some settings are
-interdependant, such as the sequence required to power up the camera. I will
-try to make note of all of these cases.
-
-The register sets are called blocks. Block 0 is the system block. This
-section is always powered on when the camera is plugged in. It contains
-registers that control housekeeping functions such as powering up the video
-processor. The video processor is the VP block. These registers control
-how the video from the sensor is processed. Examples are timing registers,
-user mode (vga, qvga), scaling, cropping, framerates, and so on. The last
-block is the video compressor (VC). The video stream sent from the camera is
-compressed as Motion JPEG (JPEGA). The VC controls all of the compression
-parameters. Looking at the file cpia2_registers.h, you can get a full view
-of these registers and the possible values for most of them.
-
-One or more registers can be set or read by sending a usb control message to
-the camera. There are three modes for this. Block mode requests a number
-of contiguous registers. Random mode reads or writes random registers with
-a tuple structure containing address/value pairs. The repeat mode is only
-used by VP4 to load a firmware patch. It contains a starting address and
-a sequence of bytes to be written into a gpio port.
diff --git a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst
deleted file mode 100644
index 4e87bdb..0000000
--- a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The VPBE V4L2 driver design
-===========================
-
-File partitioning
------------------
-
- V4L2 display device driver
- drivers/media/platform/ti/davinci/vpbe_display.c
- drivers/media/platform/ti/davinci/vpbe_display.h
-
- VPBE display controller
- drivers/media/platform/ti/davinci/vpbe.c
- drivers/media/platform/ti/davinci/vpbe.h
-
- VPBE venc sub device driver
- drivers/media/platform/ti/davinci/vpbe_venc.c
- drivers/media/platform/ti/davinci/vpbe_venc.h
- drivers/media/platform/ti/davinci/vpbe_venc_regs.h
-
- VPBE osd driver
- drivers/media/platform/ti/davinci/vpbe_osd.c
- drivers/media/platform/ti/davinci/vpbe_osd.h
- drivers/media/platform/ti/davinci/vpbe_osd_regs.h
-
-To be done
-----------
-
-vpbe display controller
- - Add support for external encoders.
- - add support for selecting external encoder as default at probe time.
-
-vpbe venc sub device
- - add timings for supporting ths8200
- - add support for LogicPD LCD.
-
-FB drivers
- - Add support for fbdev drivers.- Ready and part of subsequent patches.
diff --git a/Documentation/driver-api/media/drivers/index.rst b/Documentation/driver-api/media/drivers/index.rst
index 3240649..c4123a1 100644
--- a/Documentation/driver-api/media/drivers/index.rst
+++ b/Documentation/driver-api/media/drivers/index.rst
@@ -13,10 +13,8 @@
:maxdepth: 5
bttv-devel
- cpia2_devel
cx2341x-devel
cx88-devel
- davinci-vpbe-devel
fimc-devel
pvrusb2
pxa_camera
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index 673bdff..54f269f 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -28,7 +28,7 @@
takes parameters at initialization that will dictate how the simulation
behaves.
-- Code reponsible for encoding a valid MPEG Transport Stream, which is then
+- Code responsible for encoding a valid MPEG Transport Stream, which is then
passed to the bridge driver. This fake stream contains some hardcoded content.
For now, we have a single, audio-only channel containing a single MPEG
Elementary Stream, which in turn contains a SMPTE 302m encoded sine-wave.
diff --git a/Documentation/driver-api/media/dtv-demux.rst b/Documentation/driver-api/media/dtv-demux.rst
index c0ae5de..1441241 100644
--- a/Documentation/driver-api/media/dtv-demux.rst
+++ b/Documentation/driver-api/media/dtv-demux.rst
@@ -24,7 +24,7 @@
The demux kABI only controls front-ends regarding to their connections with
demuxes; the kABI used to set the other front-end parameters, such as
-tuning, are devined via the Digital TV Frontend kABI.
+tuning, are defined via the Digital TV Frontend kABI.
The functions that implement the abstract interface demux should be defined
static or module private and registered to the Demux core for external
diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst
index 400b8ca..2456950 100644
--- a/Documentation/driver-api/media/mc-core.rst
+++ b/Documentation/driver-api/media/mc-core.rst
@@ -232,12 +232,10 @@
The function will mark all the pads which are part of the pipeline as streaming.
-The struct media_pipeline instance pointed to by
-the pipe argument will be stored in every pad in the pipeline.
-Drivers should embed the struct media_pipeline
-in higher-level pipeline structures and can then access the
-pipeline through the struct media_pad
-pipe field.
+The struct media_pipeline instance pointed to by the pipe argument will be
+stored in every pad in the pipeline. Drivers should embed the struct
+media_pipeline in higher-level pipeline structures and can then access the
+pipeline through the struct media_pad pipe field.
Calls to :c:func:`media_pipeline_start()` can be nested.
The pipeline pointer must be identical for all nested calls to the function.
diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst
index 6f8d799..602dada 100644
--- a/Documentation/driver-api/media/v4l2-subdev.rst
+++ b/Documentation/driver-api/media/v4l2-subdev.rst
@@ -321,7 +321,7 @@
hardware from applications. For complex devices, finer-grained control of the
device than what the video nodes offer may be required. In those cases, bridge
drivers that implement :ref:`the media controller API <media_controller>` may
-opt for making the subdevice operations directly accessible from userpace.
+opt for making the subdevice operations directly accessible from userspace.
Device nodes named ``v4l-subdev``\ *X* can be created in ``/dev`` to access
sub-devices directly. If a sub-device supports direct userspace configuration
@@ -574,7 +574,7 @@
as they expect to receive the appropriate state as a parameter. To help the
conversion of subdevice drivers to a managed active state without having to
convert all callers at the same time, an additional wrapper layer has been
-added to v4l2_subdev_call(), which handles the NULL case by geting and locking
+added to v4l2_subdev_call(), which handles the NULL case by getting and locking
the callee's active state with :c:func:`v4l2_subdev_lock_and_get_active_state()`,
and unlocking the state after the call.
@@ -593,6 +593,14 @@
This shares the driver's private mutex between the controls and the states.
+Streams, multiplexed media pads and internal routing
+----------------------------------------------------
+
+A subdevice driver can implement support for multiplexed streams by setting
+the V4L2_SUBDEV_FL_STREAMS subdev flag and implementing support for
+centrally managed subdev active state, routing and stream based
+configuration.
+
V4L2 sub-device functions and data structures
---------------------------------------------
diff --git a/Documentation/driver-api/mei/nfc.rst b/Documentation/driver-api/mei/nfc.rst
index b5b6fc9..8fe8664 100644
--- a/Documentation/driver-api/mei/nfc.rst
+++ b/Documentation/driver-api/mei/nfc.rst
@@ -3,7 +3,7 @@
MEI NFC
-------
-Some Intel 8 and 9 Serieses chipsets supports NFC devices connected behind
+Some Intel 8 and 9 Series chipsets support NFC devices connected behind
the Intel Management Engine controller.
MEI client bus exposes the NFC chips as NFC phy devices and enables
binding with Microread and NXP PN544 NFC device driver from the Linux NFC
diff --git a/Documentation/driver-api/nfc/nfc-hci.rst b/Documentation/driver-api/nfc/nfc-hci.rst
index f10fe53..486aa64 100644
--- a/Documentation/driver-api/nfc/nfc-hci.rst
+++ b/Documentation/driver-api/nfc/nfc-hci.rst
@@ -150,7 +150,7 @@
Communication between the CPU and the chip often requires some link layer
protocol. Those are isolated as modules managed by the HCI layer. There are
-currently two modules : nop (raw transfert) and shdlc.
+currently two modules : nop (raw transfer) and shdlc.
A new llc must implement the following functions::
struct nfc_llc_ops {
diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst
index be8587a..ca16b5a 100644
--- a/Documentation/driver-api/nvdimm/nvdimm.rst
+++ b/Documentation/driver-api/nvdimm/nvdimm.rst
@@ -82,7 +82,7 @@
Metadata stored on a DIMM device that partitions and identifies
(persistently names) capacity allocated to different PMEM namespaces. It
also indicates whether an address abstraction like a BTT is applied to
- the namepsace. Note that traditional partition tables, GPT/MBR, are
+ the namespace. Note that traditional partition tables, GPT/MBR, are
layered on top of a PMEM namespace, or an address abstraction like BTT
if present, but partition support is deprecated going forward.
diff --git a/Documentation/driver-api/nvdimm/security.rst b/Documentation/driver-api/nvdimm/security.rst
index 7aab715..eb3d35e 100644
--- a/Documentation/driver-api/nvdimm/security.rst
+++ b/Documentation/driver-api/nvdimm/security.rst
@@ -83,7 +83,7 @@
6. Freeze
---------
The freeze operation does not require any keys. The security config can be
-frozen by a user with root privelege.
+frozen by a user with root privilege.
7. Disable
----------
diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
index 8e8b3e8..81785c0 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -103,27 +103,31 @@
::
struct phy *phy_get(struct device *dev, const char *string);
- struct phy *phy_optional_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
struct phy *devm_phy_optional_get(struct device *dev,
const char *string);
+ struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
+ const char *con_id);
+ struct phy *devm_of_phy_optional_get(struct device *dev,
+ struct device_node *np,
+ const char *con_id);
struct phy *devm_of_phy_get_by_index(struct device *dev,
struct device_node *np,
int index);
-phy_get, phy_optional_get, devm_phy_get and devm_phy_optional_get can
-be used to get the PHY. In the case of dt boot, the string arguments
+phy_get, devm_phy_get and devm_phy_optional_get can be used to get the PHY.
+In the case of dt boot, the string arguments
should contain the phy name as given in the dt data and in the case of
non-dt boot, it should contain the label of the PHY. The two
devm_phy_get associates the device with the PHY using devres on
successful PHY get. On driver detach, release function is invoked on
-the devres data and devres data is freed. phy_optional_get and
-devm_phy_optional_get should be used when the phy is optional. These
-two functions will never return -ENODEV, but instead returns NULL when
-the phy cannot be found.Some generic drivers, such as ehci, may use multiple
-phys and for such drivers referencing phy(s) by name(s) does not make sense. In
-this case, devm_of_phy_get_by_index can be used to get a phy reference based on
-the index.
+the devres data and devres data is freed.
+The _optional_get variants should be used when the phy is optional. These
+functions will never return -ENODEV, but instead return NULL when
+the phy cannot be found.
+Some generic drivers, such as ehci, may use multiple phys. In this case,
+devm_of_phy_get or devm_of_phy_get_by_index can be used to get a phy
+reference based on name or index.
It should be noted that NULL is a valid phy reference. All phy
consumer calls on the NULL phy become NOPs. That is the release calls,
diff --git a/Documentation/driver-api/pin-control.rst b/Documentation/driver-api/pin-control.rst
index 0022e93..4639912 100644
--- a/Documentation/driver-api/pin-control.rst
+++ b/Documentation/driver-api/pin-control.rst
@@ -11,20 +11,18 @@
- Multiplexing of pins, pads, fingers (etc) see below for details
- Configuration of pins, pads, fingers (etc), such as software-controlled
- biasing and driving mode specific pins, such as pull-up/down, open drain,
+ biasing and driving mode specific pins, such as pull-up, pull-down, open drain,
load capacitance etc.
Top-level interface
===================
-Definition of PIN CONTROLLER:
+Definitions:
-- A pin controller is a piece of hardware, usually a set of registers, that
+- A PIN CONTROLLER is a piece of hardware, usually a set of registers, that
can control PINs. It may be able to multiplex, bias, set load capacitance,
set drive strength, etc. for individual pins or groups of pins.
-Definition of PIN:
-
- PINS are equal to pads, fingers, balls or whatever packaging input or
output line you want to control and these are denoted by unsigned integers
in the range 0..maxpin. This numberspace is local to each PIN CONTROLLER, so
@@ -57,7 +55,9 @@
1 o o o o o o o o
To register a pin controller and name all the pins on this package we can do
-this in our driver::
+this in our driver:
+
+.. code-block:: c
#include <linux/pinctrl/pinctrl.h>
@@ -78,14 +78,13 @@
.owner = THIS_MODULE,
};
- int __init foo_probe(void)
+ int __init foo_init(void)
{
int error;
struct pinctrl_dev *pctl;
- error = pinctrl_register_and_init(&foo_desc, <PARENT>,
- NULL, &pctl);
+ error = pinctrl_register_and_init(&foo_desc, <PARENT>, NULL, &pctl);
if (error)
return error;
@@ -95,20 +94,20 @@
To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and
selected drivers, you need to select them from your machine's Kconfig entry,
since these are so tightly integrated with the machines they are used on.
-See for example arch/arm/mach-ux500/Kconfig for an example.
+See ``arch/arm/mach-ux500/Kconfig`` for an example.
Pins usually have fancier names than this. You can find these in the datasheet
for your chip. Notice that the core pinctrl.h file provides a fancy macro
-called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
-the pins from 0 in the upper left corner to 63 in the lower right corner.
+called ``PINCTRL_PIN()`` to create the struct entries. As you can see the pins are
+enumerated from 0 in the upper left corner to 63 in the lower right corner.
This enumeration was arbitrarily chosen, in practice you need to think
through your numbering system so that it matches the layout of registers
and such things in your driver, or the code may become complicated. You must
also consider matching of offsets to the GPIO ranges that may be handled by
the pin controller.
-For a padring with 467 pads, as opposed to actual pins, I used an enumeration
-like this, walking around the edge of the chip, which seems to be industry
+For a padding with 467 pads, as opposed to actual pins, the enumeration will
+be like this, walking around the edge of the chip, which seems to be industry
standard too (all these pads had names, too)::
@@ -132,50 +131,38 @@
on { 24, 25 }.
These two groups are presented to the pin control subsystem by implementing
-some generic pinctrl_ops like this::
+some generic ``pinctrl_ops`` like this:
+
+.. code-block:: c
#include <linux/pinctrl/pinctrl.h>
- struct foo_group {
- const char *name;
- const unsigned int *pins;
- const unsigned num_pins;
- };
-
static const unsigned int spi0_pins[] = { 0, 8, 16, 24 };
static const unsigned int i2c0_pins[] = { 24, 25 };
- static const struct foo_group foo_groups[] = {
- {
- .name = "spi0_grp",
- .pins = spi0_pins,
- .num_pins = ARRAY_SIZE(spi0_pins),
- },
- {
- .name = "i2c0_grp",
- .pins = i2c0_pins,
- .num_pins = ARRAY_SIZE(i2c0_pins),
- },
+ static const struct pingroup foo_groups[] = {
+ PINCTRL_PINGROUP("spi0_grp", spi0_pins, ARRAY_SIZE(spi0_pins)),
+ PINCTRL_PINGROUP("i2c0_grp", i2c0_pins, ARRAY_SIZE(i2c0_pins)),
};
-
static int foo_get_groups_count(struct pinctrl_dev *pctldev)
{
return ARRAY_SIZE(foo_groups);
}
static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
- unsigned selector)
+ unsigned int selector)
{
return foo_groups[selector].name;
}
- static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
- const unsigned **pins,
- unsigned *num_pins)
+ static int foo_get_group_pins(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ const unsigned int **pins,
+ unsigned int *npins)
{
- *pins = (unsigned *) foo_groups[selector].pins;
- *num_pins = foo_groups[selector].num_pins;
+ *pins = foo_groups[selector].pins;
+ *npins = foo_groups[selector].npins;
return 0;
}
@@ -185,13 +172,12 @@
.get_group_pins = foo_get_group_pins,
};
-
static struct pinctrl_desc foo_desc = {
- ...
- .pctlops = &foo_pctrl_ops,
+ ...
+ .pctlops = &foo_pctrl_ops,
};
-The pin control subsystem will call the .get_groups_count() function to
+The pin control subsystem will call the ``.get_groups_count()`` function to
determine the total number of legal selectors, then it will call the other functions
to retrieve the name and pins of the group. Maintaining the data structure of
the groups is up to the driver, this is just a simple example - in practice you
@@ -204,59 +190,62 @@
Pins can sometimes be software-configured in various ways, mostly related
to their electronic properties when used as inputs or outputs. For example you
-may be able to make an output pin high impedance, or "tristate" meaning it is
+may be able to make an output pin high impedance (Hi-Z), or "tristate" meaning it is
effectively disconnected. You may be able to connect an input pin to VDD or GND
using a certain resistor value - pull up and pull down - so that the pin has a
stable value when nothing is driving the rail it is connected to, or when it's
unconnected.
Pin configuration can be programmed by adding configuration entries into the
-mapping table; see section "Board/machine configuration" below.
+mapping table; see section `Board/machine configuration`_ below.
The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP
above, is entirely defined by the pin controller driver.
The pin configuration driver implements callbacks for changing pin
-configuration in the pin controller ops like this::
+configuration in the pin controller ops like this:
- #include <linux/pinctrl/pinctrl.h>
+.. code-block:: c
+
#include <linux/pinctrl/pinconf.h>
+ #include <linux/pinctrl/pinctrl.h>
+
#include "platform_x_pindefs.h"
static int foo_pin_config_get(struct pinctrl_dev *pctldev,
- unsigned offset,
- unsigned long *config)
+ unsigned int offset,
+ unsigned long *config)
{
struct my_conftype conf;
- ... Find setting for pin @ offset ...
+ /* ... Find setting for pin @ offset ... */
*config = (unsigned long) conf;
}
static int foo_pin_config_set(struct pinctrl_dev *pctldev,
- unsigned offset,
- unsigned long config)
+ unsigned int offset,
+ unsigned long config)
{
struct my_conftype *conf = (struct my_conftype *) config;
switch (conf) {
case PLATFORM_X_PULL_UP:
...
- }
+ break;
}
}
- static int foo_pin_config_group_get (struct pinctrl_dev *pctldev,
- unsigned selector,
- unsigned long *config)
+ static int foo_pin_config_group_get(struct pinctrl_dev *pctldev,
+ unsigned selector,
+ unsigned long *config)
{
...
}
- static int foo_pin_config_group_set (struct pinctrl_dev *pctldev,
- unsigned selector,
- unsigned long config)
+ static int foo_pin_config_group_set(struct pinctrl_dev *pctldev,
+ unsigned selector,
+ unsigned long config)
{
...
}
@@ -281,8 +270,8 @@
physical pins that are also registered as pin controller pins.
First and foremost, the two subsystems can be used as completely orthogonal,
-see the section named "pin control requests from drivers" and
-"drivers needing both pin control and GPIOs" below for details. But in some
+see the section named `Pin control requests from drivers`_ and
+`Drivers needing both pin control and GPIOs`_ below for details. But in some
situations a cross-subsystem mapping between pins and GPIOs is needed.
Since the pin controller subsystem has its pinspace local to the pin controller
@@ -291,7 +280,13 @@
may be muxing several GPIO ranges (typically SoCs that have one set of pins,
but internally several GPIO silicon blocks, each modelled as a struct
gpio_chip) any number of GPIO ranges can be added to a pin controller instance
-like this::
+like this:
+
+.. code-block:: c
+
+ #include <linux/gpio/driver.h>
+
+ #include <linux/pinctrl/pinctrl.h>
struct gpio_chip chip_a;
struct gpio_chip chip_b;
@@ -302,7 +297,7 @@
.base = 32,
.pin_base = 32,
.npins = 16,
- .gc = &chip_a;
+ .gc = &chip_a,
};
static struct pinctrl_gpio_range gpio_range_b = {
@@ -314,16 +309,18 @@
.gc = &chip_b;
};
+ int __init foo_init(void)
{
struct pinctrl_dev *pctl;
...
pinctrl_add_gpio_range(pctl, &gpio_range_a);
pinctrl_add_gpio_range(pctl, &gpio_range_b);
+ ...
}
So this complex system has one pin controller handling two different
GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
-"chip b" have different .pin_base, which means a start pin number of the
+"chip b" have different ``pin_base``, which means a start pin number of the
GPIO range.
The GPIO range of "chip a" starts from the GPIO base of 32 and actual
@@ -331,7 +328,7 @@
offset for the GPIO range and pin range. The GPIO range of "chip b" starts
from GPIO number 48, while the pin range of "chip b" starts from 64.
-We can convert a gpio number to actual pin number using this "pin_base".
+We can convert a gpio number to actual pin number using this ``pin_base``.
They are mapped in the global GPIO pin space at:
chip a:
@@ -343,9 +340,11 @@
The above examples assume the mapping between the GPIOs and pins is
linear. If the mapping is sparse or haphazard, an array of arbitrary pin
-numbers can be encoded in the range like this::
+numbers can be encoded in the range like this:
- static const unsigned range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
+.. code-block:: c
+
+ static const unsigned int range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
static struct pinctrl_gpio_range gpio_range = {
.name = "chip",
@@ -353,16 +352,17 @@
.base = 32,
.pins = &range_pins,
.npins = ARRAY_SIZE(range_pins),
- .gc = &chip;
+ .gc = &chip,
};
-In this case the pin_base property will be ignored. If the name of a pin
+In this case the ``pin_base`` property will be ignored. If the name of a pin
group is known, the pins and npins elements of the above structure can be
-initialised using the function pinctrl_get_group_pins(), e.g. for pin
-group "foo"::
+initialised using the function ``pinctrl_get_group_pins()``, e.g. for pin
+group "foo":
- pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins,
- &gpio_range.npins);
+.. code-block:: c
+
+ pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins, &gpio_range.npins);
When GPIO-specific functions in the pin control subsystem are called, these
ranges will be used to look up the appropriate pin controller by inspecting
@@ -378,8 +378,8 @@
the range ID value, so that the pin controller knows which range it should
deal with.
-Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see
-section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind
+Calling ``pinctrl_add_gpio_range()`` from pinctrl driver is DEPRECATED. Please see
+section 2.1 of ``Documentation/devicetree/bindings/gpio/gpio.txt`` on how to bind
pinctrl and gpio drivers.
@@ -466,10 +466,10 @@
subsystems, so devices will request their mux setting, but it's also possible
to request a single pin for e.g. GPIO.
-Definitions:
+The conventions are:
- FUNCTIONS can be switched in and out by a driver residing with the pin
- control subsystem in the drivers/pinctrl/* directory of the kernel. The
+ control subsystem in the ``drivers/pinctrl`` directory of the kernel. The
pin control driver knows the possible functions. In the example above you can
identify three pinmux functions, one for spi, one for i2c and one for mmc.
@@ -515,11 +515,13 @@
In the example case we can define that this particular machine shall
use device spi0 with pinmux function fspi0 group gspi0 and i2c0 on function
fi2c0 group gi2c0, on the primary pin controller, we get mappings
- like these::
+ like these:
+
+ .. code-block:: c
{
{"map-spi0", spi0, pinctrl0, fspi0, gspi0},
- {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0}
+ {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0},
}
Every map must be assigned a state name, pin controller, device and
@@ -569,80 +571,51 @@
this happens.
Pinmux drivers are required to supply a few callback functions, some are
-optional. Usually the set_mux() function is implemented, writing values into
+optional. Usually the ``.set_mux()`` function is implemented, writing values into
some certain registers to activate a certain mux setting for a certain pin.
-A simple driver for the above example will work by setting bits 0, 1, 2, 3 or 4
+A simple driver for the above example will work by setting bits 0, 1, 2, 3, 4, or 5
into some register named MUX to select a certain function with a certain
-group of pins would work something like this::
+group of pins would work something like this:
+
+.. code-block:: c
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
- struct foo_group {
- const char *name;
- const unsigned int *pins;
- const unsigned num_pins;
+ static const unsigned int spi0_0_pins[] = { 0, 8, 16, 24 };
+ static const unsigned int spi0_1_pins[] = { 38, 46, 54, 62 };
+ static const unsigned int i2c0_pins[] = { 24, 25 };
+ static const unsigned int mmc0_1_pins[] = { 56, 57 };
+ static const unsigned int mmc0_2_pins[] = { 58, 59 };
+ static const unsigned int mmc0_3_pins[] = { 60, 61, 62, 63 };
+
+ static const struct pingroup foo_groups[] = {
+ PINCTRL_PINGROUP("spi0_0_grp", spi0_0_pins, ARRAY_SIZE(spi0_0_pins)),
+ PINCTRL_PINGROUP("spi0_1_grp", spi0_1_pins, ARRAY_SIZE(spi0_1_pins)),
+ PINCTRL_PINGROUP("i2c0_grp", i2c0_pins, ARRAY_SIZE(i2c0_pins)),
+ PINCTRL_PINGROUP("mmc0_1_grp", mmc0_1_pins, ARRAY_SIZE(mmc0_1_pins)),
+ PINCTRL_PINGROUP("mmc0_2_grp", mmc0_2_pins, ARRAY_SIZE(mmc0_2_pins)),
+ PINCTRL_PINGROUP("mmc0_3_grp", mmc0_3_pins, ARRAY_SIZE(mmc0_3_pins)),
};
- static const unsigned spi0_0_pins[] = { 0, 8, 16, 24 };
- static const unsigned spi0_1_pins[] = { 38, 46, 54, 62 };
- static const unsigned i2c0_pins[] = { 24, 25 };
- static const unsigned mmc0_1_pins[] = { 56, 57 };
- static const unsigned mmc0_2_pins[] = { 58, 59 };
- static const unsigned mmc0_3_pins[] = { 60, 61, 62, 63 };
-
- static const struct foo_group foo_groups[] = {
- {
- .name = "spi0_0_grp",
- .pins = spi0_0_pins,
- .num_pins = ARRAY_SIZE(spi0_0_pins),
- },
- {
- .name = "spi0_1_grp",
- .pins = spi0_1_pins,
- .num_pins = ARRAY_SIZE(spi0_1_pins),
- },
- {
- .name = "i2c0_grp",
- .pins = i2c0_pins,
- .num_pins = ARRAY_SIZE(i2c0_pins),
- },
- {
- .name = "mmc0_1_grp",
- .pins = mmc0_1_pins,
- .num_pins = ARRAY_SIZE(mmc0_1_pins),
- },
- {
- .name = "mmc0_2_grp",
- .pins = mmc0_2_pins,
- .num_pins = ARRAY_SIZE(mmc0_2_pins),
- },
- {
- .name = "mmc0_3_grp",
- .pins = mmc0_3_pins,
- .num_pins = ARRAY_SIZE(mmc0_3_pins),
- },
- };
-
-
static int foo_get_groups_count(struct pinctrl_dev *pctldev)
{
return ARRAY_SIZE(foo_groups);
}
static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
- unsigned selector)
+ unsigned int selector)
{
return foo_groups[selector].name;
}
- static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
- const unsigned ** pins,
- unsigned * num_pins)
+ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned int selector,
+ const unsigned int **pins,
+ unsigned int *npins)
{
- *pins = (unsigned *) foo_groups[selector].pins;
- *num_pins = foo_groups[selector].num_pins;
+ *pins = foo_groups[selector].pins;
+ *npins = foo_groups[selector].npins;
return 0;
}
@@ -652,33 +625,14 @@
.get_group_pins = foo_get_group_pins,
};
- struct foo_pmx_func {
- const char *name;
- const char * const *groups;
- const unsigned num_groups;
- };
-
static const char * const spi0_groups[] = { "spi0_0_grp", "spi0_1_grp" };
static const char * const i2c0_groups[] = { "i2c0_grp" };
- static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp",
- "mmc0_3_grp" };
+ static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp", "mmc0_3_grp" };
- static const struct foo_pmx_func foo_functions[] = {
- {
- .name = "spi0",
- .groups = spi0_groups,
- .num_groups = ARRAY_SIZE(spi0_groups),
- },
- {
- .name = "i2c0",
- .groups = i2c0_groups,
- .num_groups = ARRAY_SIZE(i2c0_groups),
- },
- {
- .name = "mmc0",
- .groups = mmc0_groups,
- .num_groups = ARRAY_SIZE(mmc0_groups),
- },
+ static const struct pinfunction foo_functions[] = {
+ PINCTRL_PINFUNCTION("spi0", spi0_groups, ARRAY_SIZE(spi0_groups)),
+ PINCTRL_PINFUNCTION("i2c0", i2c0_groups, ARRAY_SIZE(i2c0_groups)),
+ PINCTRL_PINFUNCTION("mmc0", mmc0_groups, ARRAY_SIZE(mmc0_groups)),
};
static int foo_get_functions_count(struct pinctrl_dev *pctldev)
@@ -686,26 +640,26 @@
return ARRAY_SIZE(foo_functions);
}
- static const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector)
+ static const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned int selector)
{
return foo_functions[selector].name;
}
- static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
- const char * const **groups,
- unsigned * const num_groups)
+ static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned int selector,
+ const char * const **groups,
+ unsigned int * const ngroups)
{
*groups = foo_functions[selector].groups;
- *num_groups = foo_functions[selector].num_groups;
+ *ngroups = foo_functions[selector].ngroups;
return 0;
}
- static int foo_set_mux(struct pinctrl_dev *pctldev, unsigned selector,
- unsigned group)
+ static int foo_set_mux(struct pinctrl_dev *pctldev, unsigned int selector,
+ unsigned int group)
{
- u8 regbit = (1 << selector + group);
+ u8 regbit = BIT(group);
- writeb((readb(MUX)|regbit), MUX);
+ writeb((readb(MUX) | regbit), MUX);
return 0;
}
@@ -724,16 +678,17 @@
.pmxops = &foo_pmxops,
};
-In the example activating muxing 0 and 1 at the same time setting bits
-0 and 1, uses one pin in common so they would collide.
+In the example activating muxing 0 and 2 at the same time setting bits
+0 and 2, uses pin 24 in common so they would collide. All the same for
+the muxes 1 and 5, which have pin 62 in common.
The beauty of the pinmux subsystem is that since it keeps track of all
pins and who is using them, it will already have denied an impossible
request like that, so the driver does not need to worry about such
things - when it gets a selector passed in, the pinmux subsystem makes
sure no other device or GPIO assignment is already using the selected
-pins. Thus bits 0 and 1 in the control register will never be set at the
-same time.
+pins. Thus bits 0 and 2, or 1 and 5 in the control register will never
+be set at the same time.
All the above functions are mandatory to implement for a pinmux driver.
@@ -742,18 +697,18 @@
===============================================
Note that the following implies that the use case is to use a certain pin
-from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
+from the Linux kernel using the API in ``<linux/gpio/consumer.h>`` with gpiod_get()
and similar functions. There are cases where you may be using something
that your datasheet calls "GPIO mode", but actually is just an electrical
configuration for a certain device. See the section below named
-"GPIO mode pitfalls" for more details on this scenario.
+`GPIO mode pitfalls`_ for more details on this scenario.
-The public pinmux API contains two functions named pinctrl_gpio_request()
-and pinctrl_gpio_free(). These two functions shall *ONLY* be called from
-gpiolib-based drivers as part of their gpio_request() and
-gpio_free() semantics. Likewise the pinctrl_gpio_direction_[input|output]
-shall only be called from within respective gpio_direction_[input|output]
-gpiolib implementation.
+The public pinmux API contains two functions named ``pinctrl_gpio_request()``
+and ``pinctrl_gpio_free()``. These two functions shall *ONLY* be called from
+gpiolib-based drivers as part of their ``.request()`` and ``.free()`` semantics.
+Likewise the ``pinctrl_gpio_direction_input()`` / ``pinctrl_gpio_direction_output()``
+shall only be called from within respective ``.direction_input()`` /
+``.direction_output()`` gpiolib implementation.
NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
controlled e.g. muxed in. Instead, implement a proper gpiolib driver and have
@@ -767,8 +722,8 @@
setting and then the device functions.
For this reason there are two functions a pin control driver can implement
-to enable only GPIO on an individual pin: .gpio_request_enable() and
-.gpio_disable_free().
+to enable only GPIO on an individual pin: ``.gpio_request_enable()`` and
+``.gpio_disable_free()``.
This function will pass in the affected GPIO range identified by the pin
controller core, so you know which GPIO pins are being affected by the request
@@ -776,12 +731,12 @@
If your driver needs to have an indication from the framework of whether the
GPIO pin shall be used for input or output you can implement the
-.gpio_set_direction() function. As described this shall be called from the
+``.gpio_set_direction()`` function. As described this shall be called from the
gpiolib driver and the affected GPIO range, pin offset and desired direction
will be passed along to this function.
Alternatively to using these special functions, it is fully allowed to use
-named functions for each GPIO pin, the pinctrl_gpio_request() will attempt to
+named functions for each GPIO pin, the ``pinctrl_gpio_request()`` will attempt to
obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered.
@@ -794,7 +749,7 @@
may be confused by a datasheet talking about a pin being possible to set
into "GPIO mode". It appears that what hardware engineers mean with
"GPIO mode" is not necessarily the use case that is implied in the kernel
-interface <linux/gpio.h>: a pin that you grab from kernel code and then
+interface ``<linux/gpio/consumer.h>``: a pin that you grab from kernel code and then
either listen for input or drive high/low to assert/deassert some
external line.
@@ -805,9 +760,10 @@
The GPIO portions of a pin and its relation to a certain pin controller
configuration and muxing logic can be constructed in several ways. Here
-are two examples::
+are two examples.
- (A)
+Example **(A)**::
+
pin config
logic regs
| +- SPI
@@ -836,9 +792,7 @@
consumers on hardware of this type. The pinctrl driver should set this flag
accordingly.
-::
-
- (B)
+Example **(B)**::
pin config
logic regs
@@ -882,7 +836,7 @@
Depending on the exact HW register design, some functions exposed by the
GPIO subsystem may call into the pinctrl subsystem in order to
-co-ordinate register settings across HW modules. In particular, this may
+coordinate register settings across HW modules. In particular, this may
be needed for HW with separate GPIO and pin controller HW modules, where
e.g. GPIO direction is determined by a register in the pin controller HW
module rather than the GPIO HW module.
@@ -899,14 +853,14 @@
to think that you need to come up with something really complex, that the
pin shall be used for UART TX and GPIO at the same time, that you will grab
a pin control handle and set it to a certain state to enable UART TX to be
-muxed in, then twist it over to GPIO mode and use gpio_direction_output()
+muxed in, then twist it over to GPIO mode and use gpiod_direction_output()
to drive it low during sleep, then mux it over to UART TX again when you
-wake up and maybe even gpio_request/gpio_free as part of this cycle. This
+wake up and maybe even gpiod_get() / gpiod_put() as part of this cycle. This
all gets very complicated.
The solution is to not think that what the datasheet calls "GPIO mode"
-has to be handled by the <linux/gpio.h> interface. Instead view this as
-a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
+has to be handled by the ``<linux/gpio/consumer.h>`` interface. Instead view this as
+a certain pin config setting. Look in e.g. ``<linux/pinctrl/pinconf-generic.h>``
and you find this in the documentation:
PIN_CONFIG_OUTPUT:
@@ -915,7 +869,9 @@
So it is perfectly possible to push a pin into "GPIO mode" and drive the
line low as part of the usual pin control map. So for example your UART
-driver may look like this::
+driver may look like this:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
@@ -928,13 +884,13 @@
/* Normal mode */
retval = pinctrl_select_state(pinctrl, pins_default);
+
/* Sleep mode */
retval = pinctrl_select_state(pinctrl, pins_sleep);
And your machine configuration may look like this:
---------------------------------------------------
-::
+.. code-block:: c
static unsigned long uart_default_mode[] = {
PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
@@ -946,16 +902,17 @@
static struct pinctrl_map pinmap[] __initdata = {
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
- "u0_group", "u0"),
+ "u0_group", "u0"),
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
- "UART_TX_PIN", uart_default_mode),
+ "UART_TX_PIN", uart_default_mode),
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
- "u0_group", "gpio-mode"),
+ "u0_group", "gpio-mode"),
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
- "UART_TX_PIN", uart_sleep_mode),
+ "UART_TX_PIN", uart_sleep_mode),
};
- foo_init(void) {
+ foo_init(void)
+ {
pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
}
@@ -995,7 +952,9 @@
A pin controller configuration for a machine looks pretty much like a simple
regulator configuration, so for the example array above we want to enable i2c
-and spi on the second function mapping::
+and spi on the second function mapping:
+
+.. code-block:: c
#include <linux/pinctrl/machine.h>
@@ -1030,13 +989,17 @@
As you can see we may have several pin controllers on the system and thus
we need to specify which one of them contains the functions we wish to map.
-You register this pinmux mapping to the pinmux subsystem by simply::
+You register this pinmux mapping to the pinmux subsystem by simply:
+
+.. code-block:: c
ret = pinctrl_register_mappings(mapping, ARRAY_SIZE(mapping));
Since the above construct is pretty common there is a helper macro to make
it even more compact which assumes you want to use pinctrl-foo and position
-0 for mapping, for example::
+0 for mapping, for example:
+
+.. code-block:: c
static struct pinctrl_map mapping[] __initdata = {
PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT,
@@ -1046,7 +1009,9 @@
The mapping table may also contain pin configuration entries. It's common for
each pin/group to have a number of configuration entries that affect it, so
the table entries for configuration reference an array of config parameters
-and values. An example using the convenience macros is shown below::
+and values. An example using the convenience macros is shown below:
+
+.. code-block:: c
static unsigned long i2c_grp_configs[] = {
FOO_PIN_DRIVEN,
@@ -1073,8 +1038,10 @@
named states. When running on hardware that doesn't need any pin controller
configuration, the mapping table must still contain those named states, in
order to explicitly indicate that the states were provided and intended to
-be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining
-a named state without causing any pin controller to be programmed::
+be empty. Table entry macro ``PIN_MAP_DUMMY_STATE()`` serves the purpose of defining
+a named state without causing any pin controller to be programmed:
+
+.. code-block:: c
static struct pinctrl_map mapping[] __initdata = {
PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT),
@@ -1085,7 +1052,9 @@
================
As it is possible to map a function to different groups of pins an optional
-.group can be specified like this::
+.group can be specified like this:
+
+.. code-block:: c
...
{
@@ -1107,13 +1076,15 @@
...
This example mapping is used to switch between two positions for spi0 at
-runtime, as described further below under the heading "Runtime pinmuxing".
+runtime, as described further below under the heading `Runtime pinmuxing`_.
Further it is possible for one named state to affect the muxing of several
groups of pins, say for example in the mmc0 example above, where you can
additively expand the mmc0 bus from 2 to 4 to 8 pins. If we want to use all
-three groups for a total of 2+2+4 = 8 pins (for an 8-bit MMC bus as is the
-case), we define a mapping like this::
+three groups for a total of 2 + 2 + 4 = 8 pins (for an 8-bit MMC bus as is the
+case), we define a mapping like this:
+
+.. code-block:: c
...
{
@@ -1167,13 +1138,17 @@
...
The result of grabbing this mapping from the device with something like
-this (see next paragraph)::
+this (see next paragraph):
+
+.. code-block:: c
p = devm_pinctrl_get(dev);
s = pinctrl_lookup_state(p, "8bit");
ret = pinctrl_select_state(p, s);
-or more simply::
+or more simply:
+
+.. code-block:: c
p = devm_pinctrl_get_select(dev, "8bit");
@@ -1188,7 +1163,7 @@
=================================
When a device driver is about to probe the device core will automatically
-attempt to issue pinctrl_get_select_default() on these devices.
+attempt to issue ``pinctrl_get_select_default()`` on these devices.
This way driver writers do not need to add any of the boilerplate code
of the type found below. However when doing fine-grained state selection
and not using the "default" state, you may have to do some device driver
@@ -1206,12 +1181,14 @@
at runtime this is not possible.
A typical case is if a driver needs to switch bias of pins from normal
-operation and going to sleep, moving from the PINCTRL_STATE_DEFAULT to
-PINCTRL_STATE_SLEEP at runtime, re-biasing or even re-muxing pins to save
+operation and going to sleep, moving from the ``PINCTRL_STATE_DEFAULT`` to
+``PINCTRL_STATE_SLEEP`` at runtime, re-biasing or even re-muxing pins to save
current in sleep mode.
A driver may request a certain control state to be activated, usually just the
-default state like this::
+default state like this:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
@@ -1251,49 +1228,49 @@
The semantics of the pinctrl APIs are:
-- pinctrl_get() is called in process context to obtain a handle to all pinctrl
+- ``pinctrl_get()`` is called in process context to obtain a handle to all pinctrl
information for a given client device. It will allocate a struct from the
kernel memory to hold the pinmux state. All mapping table parsing or similar
slow operations take place within this API.
-- devm_pinctrl_get() is a variant of pinctrl_get() that causes pinctrl_put()
+- ``devm_pinctrl_get()`` is a variant of pinctrl_get() that causes ``pinctrl_put()``
to be called automatically on the retrieved pointer when the associated
device is removed. It is recommended to use this function over plain
- pinctrl_get().
+ ``pinctrl_get()``.
-- pinctrl_lookup_state() is called in process context to obtain a handle to a
+- ``pinctrl_lookup_state()`` is called in process context to obtain a handle to a
specific state for a client device. This operation may be slow, too.
-- pinctrl_select_state() programs pin controller hardware according to the
+- ``pinctrl_select_state()`` programs pin controller hardware according to the
definition of the state as given by the mapping table. In theory, this is a
fast-path operation, since it only involved blasting some register settings
into hardware. However, note that some pin controllers may have their
registers on a slow/IRQ-based bus, so client devices should not assume they
- can call pinctrl_select_state() from non-blocking contexts.
+ can call ``pinctrl_select_state()`` from non-blocking contexts.
-- pinctrl_put() frees all information associated with a pinctrl handle.
+- ``pinctrl_put()`` frees all information associated with a pinctrl handle.
-- devm_pinctrl_put() is a variant of pinctrl_put() that may be used to
- explicitly destroy a pinctrl object returned by devm_pinctrl_get().
+- ``devm_pinctrl_put()`` is a variant of ``pinctrl_put()`` that may be used to
+ explicitly destroy a pinctrl object returned by ``devm_pinctrl_get()``.
However, use of this function will be rare, due to the automatic cleanup
that will occur even without calling it.
- pinctrl_get() must be paired with a plain pinctrl_put().
- pinctrl_get() may not be paired with devm_pinctrl_put().
- devm_pinctrl_get() can optionally be paired with devm_pinctrl_put().
- devm_pinctrl_get() may not be paired with plain pinctrl_put().
+ ``pinctrl_get()`` must be paired with a plain ``pinctrl_put()``.
+ ``pinctrl_get()`` may not be paired with ``devm_pinctrl_put()``.
+ ``devm_pinctrl_get()`` can optionally be paired with ``devm_pinctrl_put()``.
+ ``devm_pinctrl_get()`` may not be paired with plain ``pinctrl_put()``.
Usually the pin control core handled the get/put pair and call out to the
device drivers bookkeeping operations, like checking available functions and
-the associated pins, whereas select_state pass on to the pin controller
+the associated pins, whereas ``pinctrl_select_state()`` pass on to the pin controller
driver which takes care of activating and/or deactivating the mux setting by
quickly poking some registers.
-The pins are allocated for your device when you issue the devm_pinctrl_get()
+The pins are allocated for your device when you issue the ``devm_pinctrl_get()``
call, after this you should be able to see this in the debugfs listing of all
pins.
-NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the
+NOTE: the pinctrl system will return ``-EPROBE_DEFER`` if it cannot find the
requested pinctrl handles, for example if the pinctrl driver has not yet
registered. Thus make sure that the error path in your driver gracefully
cleans up and is ready to retry the probing later in the startup process.
@@ -1305,18 +1282,20 @@
Again, it is discouraged to let drivers lookup and select pin control states
themselves, but again sometimes this is unavoidable.
-So say that your driver is fetching its resources like this::
+So say that your driver is fetching its resources like this:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
- #include <linux/gpio.h>
+ #include <linux/gpio/consumer.h>
struct pinctrl *pinctrl;
- int gpio;
+ struct gpio_desc *gpio;
pinctrl = devm_pinctrl_get_select_default(&dev);
- gpio = devm_gpio_request(&dev, 14, "foo");
+ gpio = devm_gpiod_get(&dev, "foo");
-Here we first request a certain pin state and then request GPIO 14 to be
+Here we first request a certain pin state and then request GPIO "foo" to be
used. If you're using the subsystems orthogonally like this, you should
nominally always get your pinctrl handle and select the desired pinctrl
state BEFORE requesting the GPIO. This is a semantic convention to avoid
@@ -1331,9 +1310,9 @@
But there are also situations where it makes sense for the GPIO subsystem
to communicate directly with the pinctrl subsystem, using the latter as a
back-end. This is when the GPIO driver may call out to the functions
-described in the section "Pin control interaction with the GPIO subsystem"
+described in the section `Pin control interaction with the GPIO subsystem`_
above. This only involves per-pin multiplexing, and will be completely
-hidden behind the gpio_*() function namespace. In this case, the driver
+hidden behind the gpiod_*() function namespace. In this case, the driver
need not interact with the pin control subsystem at all.
If a pin control driver and a GPIO driver is dealing with the same pins
@@ -1348,12 +1327,14 @@
==========================
Pin control map entries can be hogged by the core when the pin controller
-is registered. This means that the core will attempt to call pinctrl_get(),
-lookup_state() and select_state() on it immediately after the pin control
-device has been registered.
+is registered. This means that the core will attempt to call ``pinctrl_get()``,
+``pinctrl_lookup_state()`` and ``pinctrl_select_state()`` on it immediately after
+the pin control device has been registered.
This occurs for mapping table entries where the client device name is equal
-to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT::
+to the pin controller device name, and the state name is ``PINCTRL_STATE_DEFAULT``:
+
+.. code-block:: c
{
.dev_name = "pinctrl-foo",
@@ -1365,7 +1346,9 @@
Since it may be common to request the core to hog a few always-applicable
mux settings on the primary pin controller, there is a convenience macro for
-this::
+this:
+
+.. code-block:: c
PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */,
"power_func")
@@ -1385,7 +1368,9 @@
This snippet first initializes a state object for both groups (in foo_probe()),
then muxes the function in the pins defined by group A, and finally muxes it in
-on the pins defined by group B::
+on the pins defined by group B:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
@@ -1413,14 +1398,14 @@
/* Enable on position A */
ret = pinctrl_select_state(p, s1);
if (ret < 0)
- ...
+ ...
...
/* Enable on position B */
ret = pinctrl_select_state(p, s2);
if (ret < 0)
- ...
+ ...
...
}
@@ -1432,6 +1417,7 @@
Debugfs files
=============
+
These files are created in ``/sys/kernel/debug/pinctrl``:
- ``pinctrl-devices``: prints each pin controller device along with columns to
@@ -1440,7 +1426,7 @@
- ``pinctrl-handles``: prints each configured pin controller handle and the
corresponding pinmux maps
-- ``pinctrl-maps``: print all pinctrl maps
+- ``pinctrl-maps``: prints all pinctrl maps
A sub-directory is created inside of ``/sys/kernel/debug/pinctrl`` for each pin
controller device containing these files:
@@ -1448,20 +1434,22 @@
- ``pins``: prints a line for each pin registered on the pin controller. The
pinctrl driver may add additional information such as register contents.
-- ``gpio-ranges``: print ranges that map gpio lines to pins on the controller
+- ``gpio-ranges``: prints ranges that map gpio lines to pins on the controller
-- ``pingroups``: print all pin groups registered on the pin controller
+- ``pingroups``: prints all pin groups registered on the pin controller
-- ``pinconf-pins``: print pin config settings for each pin
+- ``pinconf-pins``: prints pin config settings for each pin
-- ``pinconf-groups``: print pin config settings per pin group
+- ``pinconf-groups``: prints pin config settings per pin group
-- ``pinmux-functions``: print each pin function along with the pin groups that
+- ``pinmux-functions``: prints each pin function along with the pin groups that
map to the pin function
-- ``pinmux-pins``: iterate through all pins and print mux owner, gpio owner
+- ``pinmux-pins``: iterates through all pins and prints mux owner, gpio owner
and if the pin is a hog
-- ``pinmux-select``: write to this file to activate a pin function for a group::
+- ``pinmux-select``: write to this file to activate a pin function for a group:
+
+ .. code-block:: sh
echo "<group-name function-name>" > pinmux-select
diff --git a/Documentation/driver-api/pldmfw/index.rst b/Documentation/driver-api/pldmfw/index.rst
index ad2c33e..fd871b8 100644
--- a/Documentation/driver-api/pldmfw/index.rst
+++ b/Documentation/driver-api/pldmfw/index.rst
@@ -20,7 +20,7 @@
The ``pldmfw`` library is intended to be used by device drivers for
implementing device flash update based on firmware files following the PLDM
-firwmare file format.
+firmware file format.
It is implemented using an ops table that allows device drivers to provide
the underlying device specific functionality.
diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst
index 98d2685..84b4306 100644
--- a/Documentation/driver-api/serial/driver.rst
+++ b/Documentation/driver-api/serial/driver.rst
@@ -24,7 +24,7 @@
Console Support
---------------
-The serial core provides a few helper functions. This includes identifing
+The serial core provides a few helper functions. This includes identifying
the correct port structure (via uart_get_console()) and decoding command line
arguments (uart_parse_options()).
diff --git a/Documentation/driver-api/surface_aggregator/client.rst b/Documentation/driver-api/surface_aggregator/client.rst
index 27f95ab..e100ab0 100644
--- a/Documentation/driver-api/surface_aggregator/client.rst
+++ b/Documentation/driver-api/surface_aggregator/client.rst
@@ -19,7 +19,7 @@
.. |ssam_notifier_unregister| replace:: :c:func:`ssam_notifier_unregister`
.. |ssam_device_notifier_register| replace:: :c:func:`ssam_device_notifier_register`
.. |ssam_device_notifier_unregister| replace:: :c:func:`ssam_device_notifier_unregister`
-.. |ssam_request_sync| replace:: :c:func:`ssam_request_sync`
+.. |ssam_request_do_sync| replace:: :c:func:`ssam_request_do_sync`
.. |ssam_event_mask| replace:: :c:type:`enum ssam_event_mask <ssam_event_mask>`
@@ -191,7 +191,7 @@
* they do not correspond to an actual SAM/EC request.
*/
rqst.target_category = SSAM_SSH_TC_SAM;
- rqst.target_id = 0x01;
+ rqst.target_id = SSAM_SSH_TID_SAM;
rqst.command_id = 0x02;
rqst.instance_id = 0x03;
rqst.flags = SSAM_REQUEST_HAS_RESPONSE;
@@ -209,12 +209,12 @@
* with the SSAM_REQUEST_HAS_RESPONSE flag set in the specification
* above.
*/
- status = ssam_request_sync(ctrl, &rqst, &resp);
+ status = ssam_request_do_sync(ctrl, &rqst, &resp);
/*
* Alternatively use
*
- * ssam_request_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
+ * ssam_request_do_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
*
* to perform the request, allocating the message buffer directly
* on the stack as opposed to allocation via kzalloc().
@@ -230,7 +230,7 @@
return status;
}
-Note that |ssam_request_sync| in its essence is a wrapper over lower-level
+Note that |ssam_request_do_sync| in its essence is a wrapper over lower-level
request primitives, which may also be used to perform requests. Refer to its
implementation and documentation for more details.
@@ -241,7 +241,7 @@
SSAM_DEFINE_SYNC_REQUEST_W(__ssam_tmp_perf_mode_set, __le32, {
.target_category = SSAM_SSH_TC_TMP,
- .target_id = 0x01,
+ .target_id = SSAM_SSH_TID_SAM,
.command_id = 0x03,
.instance_id = 0x00,
});
diff --git a/Documentation/driver-api/surface_aggregator/ssh.rst b/Documentation/driver-api/surface_aggregator/ssh.rst
index bf007d6c..b955b67 100644
--- a/Documentation/driver-api/surface_aggregator/ssh.rst
+++ b/Documentation/driver-api/surface_aggregator/ssh.rst
@@ -13,6 +13,7 @@
.. |DATA_NSQ| replace:: ``DATA_NSQ``
.. |TC| replace:: ``TC``
.. |TID| replace:: ``TID``
+.. |SID| replace:: ``SID``
.. |IID| replace:: ``IID``
.. |RQID| replace:: ``RQID``
.. |CID| replace:: ``CID``
@@ -76,7 +77,7 @@
its own CRC (over all payload bytes). If the payload is not present (i.e.
the frame has ``LEN=0``), the CRC of the payload is still present and will
evaluate to ``0xffff``. The |LEN| field does not include any of the CRCs, it
-equals the number of bytes inbetween the CRC of the frame and the CRC of the
+equals the number of bytes between the CRC of the frame and the CRC of the
payload.
Additionally, the following fixed two-byte sequences are used:
@@ -219,13 +220,13 @@
- |u8|
- Target category.
- * - |TID| (out)
+ * - |TID|
- |u8|
- - Target ID for outgoing (host to EC) commands.
+ - Target ID for commands/messages.
- * - |TID| (in)
+ * - |SID|
- |u8|
- - Target ID for incoming (EC to host) commands.
+ - Source ID for commands/messages.
* - |IID|
- |u8|
@@ -286,19 +287,20 @@
event request ID.
Furthermore, requests, responses, and events have an associated target ID
-(``TID``). This target ID is split into output (host to EC) and input (EC to
-host) fields, with the respecting other field (e.g. output field on incoming
-messages) set to zero. Two ``TID`` values are known: Primary (``0x01``) and
-secondary (``0x02``). In general, the response to a request should have the
-same ``TID`` value, however, the field (output vs. input) should be used in
-accordance to the direction in which the response is sent (i.e. on the input
-field, as responses are generally sent from the EC to the host).
+(``TID``) and source ID (``SID``). These two fields indicate where a message
+originates from (``SID``) and what the intended target of the message is
+(``TID``). Note that a response to a specific request therefore has the source
+and target IDs swapped when compared to the original request (i.e. the request
+target is the response source and the request source is the response target).
+See (:c:type:`enum ssh_request_id <ssh_request_id>`) for possible values of
+both.
-Note that, even though requests and events should be uniquely identifiable
-by target category and command ID alone, the EC may require specific
-target ID and instance ID values to accept a command. A command that is
-accepted for ``TID=1``, for example, may not be accepted for ``TID=2``
-and vice versa.
+Note that, even though requests and events should be uniquely identifiable by
+target category and command ID alone, the EC may require specific target ID and
+instance ID values to accept a command. A command that is accepted for
+``TID=1``, for example, may not be accepted for ``TID=2`` and vice versa. While
+this may not always hold in reality, you can think of different target/source
+IDs indicating different physical ECs with potentially different feature sets.
Limitations and Observations
diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst
index 030306f..a886028 100644
--- a/Documentation/driver-api/thermal/index.rst
+++ b/Documentation/driver-api/thermal/index.rst
@@ -14,7 +14,6 @@
exynos_thermal
exynos_thermal_emulation
- intel_powerclamp
nouveau_thermal
x86_pkg_temperature_thermal
intel_dptf
diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst
index 372bdb4..f5c193cc 100644
--- a/Documentation/driver-api/thermal/intel_dptf.rst
+++ b/Documentation/driver-api/thermal/intel_dptf.rst
@@ -84,6 +84,9 @@
https:/github.com/intel/thermal_daemon for decoding
thermal table.
+``production_mode`` (RO)
+ When different from zero, manufacturer locked thermal configuration
+ from further changes.
ACPI Thermal Relationship table interface
------------------------------------------
diff --git a/Documentation/driver-api/thermal/intel_powerclamp.rst b/Documentation/driver-api/thermal/intel_powerclamp.rst
deleted file mode 100644
index 3f6dfb0..0000000
--- a/Documentation/driver-api/thermal/intel_powerclamp.rst
+++ /dev/null
@@ -1,320 +0,0 @@
-=======================
-Intel Powerclamp Driver
-=======================
-
-By:
- - Arjan van de Ven <arjan@linux.intel.com>
- - Jacob Pan <jacob.jun.pan@linux.intel.com>
-
-.. Contents:
-
- (*) Introduction
- - Goals and Objectives
-
- (*) Theory of Operation
- - Idle Injection
- - Calibration
-
- (*) Performance Analysis
- - Effectiveness and Limitations
- - Power vs Performance
- - Scalability
- - Calibration
- - Comparison with Alternative Techniques
-
- (*) Usage and Interfaces
- - Generic Thermal Layer (sysfs)
- - Kernel APIs (TBD)
-
-INTRODUCTION
-============
-
-Consider the situation where a system’s power consumption must be
-reduced at runtime, due to power budget, thermal constraint, or noise
-level, and where active cooling is not preferred. Software managed
-passive power reduction must be performed to prevent the hardware
-actions that are designed for catastrophic scenarios.
-
-Currently, P-states, T-states (clock modulation), and CPU offlining
-are used for CPU throttling.
-
-On Intel CPUs, C-states provide effective power reduction, but so far
-they’re only used opportunistically, based on workload. With the
-development of intel_powerclamp driver, the method of synchronizing
-idle injection across all online CPU threads was introduced. The goal
-is to achieve forced and controllable C-state residency.
-
-Test/Analysis has been made in the areas of power, performance,
-scalability, and user experience. In many cases, clear advantage is
-shown over taking the CPU offline or modulating the CPU clock.
-
-
-THEORY OF OPERATION
-===================
-
-Idle Injection
---------------
-
-On modern Intel processors (Nehalem or later), package level C-state
-residency is available in MSRs, thus also available to the kernel.
-
-These MSRs are::
-
- #define MSR_PKG_C2_RESIDENCY 0x60D
- #define MSR_PKG_C3_RESIDENCY 0x3F8
- #define MSR_PKG_C6_RESIDENCY 0x3F9
- #define MSR_PKG_C7_RESIDENCY 0x3FA
-
-If the kernel can also inject idle time to the system, then a
-closed-loop control system can be established that manages package
-level C-state. The intel_powerclamp driver is conceived as such a
-control system, where the target set point is a user-selected idle
-ratio (based on power reduction), and the error is the difference
-between the actual package level C-state residency ratio and the target idle
-ratio.
-
-Injection is controlled by high priority kernel threads, spawned for
-each online CPU.
-
-These kernel threads, with SCHED_FIFO class, are created to perform
-clamping actions of controlled duty ratio and duration. Each per-CPU
-thread synchronizes its idle time and duration, based on the rounding
-of jiffies, so accumulated errors can be prevented to avoid a jittery
-effect. Threads are also bound to the CPU such that they cannot be
-migrated, unless the CPU is taken offline. In this case, threads
-belong to the offlined CPUs will be terminated immediately.
-
-Running as SCHED_FIFO and relatively high priority, also allows such
-scheme to work for both preemptable and non-preemptable kernels.
-Alignment of idle time around jiffies ensures scalability for HZ
-values. This effect can be better visualized using a Perf timechart.
-The following diagram shows the behavior of kernel thread
-kidle_inject/cpu. During idle injection, it runs monitor/mwait idle
-for a given "duration", then relinquishes the CPU to other tasks,
-until the next time interval.
-
-The NOHZ schedule tick is disabled during idle time, but interrupts
-are not masked. Tests show that the extra wakeups from scheduler tick
-have a dramatic impact on the effectiveness of the powerclamp driver
-on large scale systems (Westmere system with 80 processors).
-
-::
-
- CPU0
- ____________ ____________
- kidle_inject/0 | sleep | mwait | sleep |
- _________| |________| |_______
- duration
- CPU1
- ____________ ____________
- kidle_inject/1 | sleep | mwait | sleep |
- _________| |________| |_______
- ^
- |
- |
- roundup(jiffies, interval)
-
-Only one CPU is allowed to collect statistics and update global
-control parameters. This CPU is referred to as the controlling CPU in
-this document. The controlling CPU is elected at runtime, with a
-policy that favors BSP, taking into account the possibility of a CPU
-hot-plug.
-
-In terms of dynamics of the idle control system, package level idle
-time is considered largely as a non-causal system where its behavior
-cannot be based on the past or current input. Therefore, the
-intel_powerclamp driver attempts to enforce the desired idle time
-instantly as given input (target idle ratio). After injection,
-powerclamp monitors the actual idle for a given time window and adjust
-the next injection accordingly to avoid over/under correction.
-
-When used in a causal control system, such as a temperature control,
-it is up to the user of this driver to implement algorithms where
-past samples and outputs are included in the feedback. For example, a
-PID-based thermal controller can use the powerclamp driver to
-maintain a desired target temperature, based on integral and
-derivative gains of the past samples.
-
-
-
-Calibration
------------
-During scalability testing, it is observed that synchronized actions
-among CPUs become challenging as the number of cores grows. This is
-also true for the ability of a system to enter package level C-states.
-
-To make sure the intel_powerclamp driver scales well, online
-calibration is implemented. The goals for doing such a calibration
-are:
-
-a) determine the effective range of idle injection ratio
-b) determine the amount of compensation needed at each target ratio
-
-Compensation to each target ratio consists of two parts:
-
- a) steady state error compensation
- This is to offset the error occurring when the system can
- enter idle without extra wakeups (such as external interrupts).
-
- b) dynamic error compensation
- When an excessive amount of wakeups occurs during idle, an
- additional idle ratio can be added to quiet interrupts, by
- slowing down CPU activities.
-
-A debugfs file is provided for the user to examine compensation
-progress and results, such as on a Westmere system::
-
- [jacob@nex01 ~]$ cat
- /sys/kernel/debug/intel_powerclamp/powerclamp_calib
- controlling cpu: 0
- pct confidence steady dynamic (compensation)
- 0 0 0 0
- 1 1 0 0
- 2 1 1 0
- 3 3 1 0
- 4 3 1 0
- 5 3 1 0
- 6 3 1 0
- 7 3 1 0
- 8 3 1 0
- ...
- 30 3 2 0
- 31 3 2 0
- 32 3 1 0
- 33 3 2 0
- 34 3 1 0
- 35 3 2 0
- 36 3 1 0
- 37 3 2 0
- 38 3 1 0
- 39 3 2 0
- 40 3 3 0
- 41 3 1 0
- 42 3 2 0
- 43 3 1 0
- 44 3 1 0
- 45 3 2 0
- 46 3 3 0
- 47 3 0 0
- 48 3 2 0
- 49 3 3 0
-
-Calibration occurs during runtime. No offline method is available.
-Steady state compensation is used only when confidence levels of all
-adjacent ratios have reached satisfactory level. A confidence level
-is accumulated based on clean data collected at runtime. Data
-collected during a period without extra interrupts is considered
-clean.
-
-To compensate for excessive amounts of wakeup during idle, additional
-idle time is injected when such a condition is detected. Currently,
-we have a simple algorithm to double the injection ratio. A possible
-enhancement might be to throttle the offending IRQ, such as delaying
-EOI for level triggered interrupts. But it is a challenge to be
-non-intrusive to the scheduler or the IRQ core code.
-
-
-CPU Online/Offline
-------------------
-Per-CPU kernel threads are started/stopped upon receiving
-notifications of CPU hotplug activities. The intel_powerclamp driver
-keeps track of clamping kernel threads, even after they are migrated
-to other CPUs, after a CPU offline event.
-
-
-Performance Analysis
-====================
-This section describes the general performance data collected on
-multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P).
-
-Effectiveness and Limitations
------------------------------
-The maximum range that idle injection is allowed is capped at 50
-percent. As mentioned earlier, since interrupts are allowed during
-forced idle time, excessive interrupts could result in less
-effectiveness. The extreme case would be doing a ping -f to generated
-flooded network interrupts without much CPU acknowledgement. In this
-case, little can be done from the idle injection threads. In most
-normal cases, such as scp a large file, applications can be throttled
-by the powerclamp driver, since slowing down the CPU also slows down
-network protocol processing, which in turn reduces interrupts.
-
-When control parameters change at runtime by the controlling CPU, it
-may take an additional period for the rest of the CPUs to catch up
-with the changes. During this time, idle injection is out of sync,
-thus not able to enter package C- states at the expected ratio. But
-this effect is minor, in that in most cases change to the target
-ratio is updated much less frequently than the idle injection
-frequency.
-
-Scalability
------------
-Tests also show a minor, but measurable, difference between the 4P/8P
-Ivy Bridge system and the 80P Westmere server under 50% idle ratio.
-More compensation is needed on Westmere for the same amount of
-target idle ratio. The compensation also increases as the idle ratio
-gets larger. The above reason constitutes the need for the
-calibration code.
-
-On the IVB 8P system, compared to an offline CPU, powerclamp can
-achieve up to 40% better performance per watt. (measured by a spin
-counter summed over per CPU counting threads spawned for all running
-CPUs).
-
-Usage and Interfaces
-====================
-The powerclamp driver is registered to the generic thermal layer as a
-cooling device. Currently, it’s not bound to any thermal zones::
-
- jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
- cur_state:0
- max_state:50
- type:intel_powerclamp
-
-cur_state allows user to set the desired idle percentage. Writing 0 to
-cur_state will stop idle injection. Writing a value between 1 and
-max_state will start the idle injection. Reading cur_state returns the
-actual and current idle percentage. This may not be the same value
-set by the user in that current idle percentage depends on workload
-and includes natural idle. When idle injection is disabled, reading
-cur_state returns value -1 instead of 0 which is to avoid confusing
-100% busy state with the disabled state.
-
-Example usage:
-- To inject 25% idle time::
-
- $ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
-
-If the system is not busy and has more than 25% idle time already,
-then the powerclamp driver will not start idle injection. Using Top
-will not show idle injection kernel threads.
-
-If the system is busy (spin test below) and has less than 25% natural
-idle time, powerclamp kernel threads will do idle injection. Forced
-idle time is accounted as normal idle in that common code path is
-taken as the idle task.
-
-In this example, 24.1% idle is shown. This helps the system admin or
-user determine the cause of slowdown, when a powerclamp driver is in action::
-
-
- Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie
- Cpu(s): 71.2%us, 4.7%sy, 0.0%ni, 24.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
- Mem: 3943228k total, 1689632k used, 2253596k free, 74960k buffers
- Swap: 4087804k total, 0k used, 4087804k free, 945336k cached
-
- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
- 3352 jacob 20 0 262m 644 428 S 286 0.0 0:17.16 spin
- 3341 root -51 0 0 0 0 D 25 0.0 0:01.62 kidle_inject/0
- 3344 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/3
- 3342 root -51 0 0 0 0 D 25 0.0 0:01.61 kidle_inject/1
- 3343 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/2
- 2935 jacob 20 0 696m 125m 35m S 5 3.3 0:31.11 firefox
- 1546 root 20 0 158m 20m 6640 S 3 0.5 0:26.97 Xorg
- 2100 jacob 20 0 1223m 88m 30m S 3 2.3 0:23.68 compiz
-
-Tests have shown that by using the powerclamp driver as a cooling
-device, a PID based userspace thermal controller can manage to
-control CPU temperature effectively, when no other thermal influence
-is added. For example, a UltraBook user can compile the kernel under
-certain temperature (below most active trip points).
diff --git a/Documentation/driver-api/tty/n_gsm.rst b/Documentation/driver-api/tty/n_gsm.rst
index 35d7381..9447b8a 100644
--- a/Documentation/driver-api/tty/n_gsm.rst
+++ b/Documentation/driver-api/tty/n_gsm.rst
@@ -25,6 +25,8 @@
#. Switch the serial line to using the n_gsm line discipline by using
``TIOCSETD`` ioctl.
+#. Configure the mux using ``GSMIOC_GETCONF_EXT``/``GSMIOC_SETCONF_EXT`` ioctl if needed.
+
#. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl.
#. Obtain base gsmtty number for the used serial port.
@@ -42,6 +44,7 @@
int ldisc = N_GSM0710;
struct gsm_config c;
+ struct gsm_config_ext ce;
struct termios configuration;
uint32_t first;
@@ -62,6 +65,12 @@
/* use n_gsm line discipline */
ioctl(fd, TIOCSETD, &ldisc);
+ /* get n_gsm extended configuration */
+ ioctl(fd, GSMIOC_GETCONF_EXT, &ce);
+ /* use keep-alive once every 5s for modem connection supervision */
+ ce.keep_alive = 500;
+ /* set the new extended configuration */
+ ioctl(fd, GSMIOC_SETCONF_EXT, &ce);
/* get n_gsm configuration */
ioctl(fd, GSMIOC_GETCONF, &c);
/* we are initiator and need encoding 0 (basic) */
@@ -106,6 +115,9 @@
#. Switch the serial line to using the *n_gsm* line discipline by using
``TIOCSETD`` ioctl.
+#. Configure the mux using ``GSMIOC_GETCONF_EXT``/``GSMIOC_SETCONF_EXT``
+ ioctl if needed.
+
#. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl.
#. Obtain base gsmtty number for the used serial port::
@@ -119,6 +131,7 @@
int ldisc = N_GSM0710;
struct gsm_config c;
+ struct gsm_config_ext ce;
struct termios configuration;
uint32_t first;
@@ -132,6 +145,12 @@
/* use n_gsm line discipline */
ioctl(fd, TIOCSETD, &ldisc);
+ /* get n_gsm extended configuration */
+ ioctl(fd, GSMIOC_GETCONF_EXT, &ce);
+ /* use keep-alive once every 5s for peer connection supervision */
+ ce.keep_alive = 500;
+ /* set the new extended configuration */
+ ioctl(fd, GSMIOC_SETCONF_EXT, &ce);
/* get n_gsm configuration */
ioctl(fd, GSMIOC_GETCONF, &c);
/* we are requester and need encoding 0 (basic) */
diff --git a/Documentation/driver-api/usb/dwc3.rst b/Documentation/driver-api/usb/dwc3.rst
index 8b36ff1..e3d6a62 100644
--- a/Documentation/driver-api/usb/dwc3.rst
+++ b/Documentation/driver-api/usb/dwc3.rst
@@ -18,7 +18,7 @@
4. Hub configuration
Linux currently supports several versions of this controller. In all
-likelyhood, the version in your SoC is already supported. At the time
+likelihood, the version in your SoC is already supported. At the time
of this writing, known tested versions range from 2.02a to 3.10a. As a
rule of thumb, anything above 2.02a should work reliably well.
diff --git a/Documentation/driver-api/usb/usb3-debug-port.rst b/Documentation/driver-api/usb/usb3-debug-port.rst
index b9fd131..d4610457 100644
--- a/Documentation/driver-api/usb/usb3-debug-port.rst
+++ b/Documentation/driver-api/usb/usb3-debug-port.rst
@@ -48,7 +48,7 @@
"earlyprintk=xdbc"
If there are multiple xHCI controllers in your system, you can
-append a host contoller index to this kernel parameter. This
+append a host controller index to this kernel parameter. This
index starts from 0.
Current design doesn't support DbC runtime suspend/resume. As
diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
index fdf7d69..bbd548b 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -60,7 +60,7 @@
| mdev.ko |
| +-----------+ | mdev_register_parent() +--------------+
| | | +<------------------------+ |
- | | | | | nvidia.ko |<-> physical
+ | | | | | ccw_device.ko|<-> physical
| | | +------------------------>+ | device
| | | | callbacks +--------------+
| | Physical | |
@@ -69,12 +69,6 @@
| | | | | i915.ko |<-> physical
| | | +------------------------>+ | device
| | | | callbacks +--------------+
- | | | |
- | | | | mdev_register_parent() +--------------+
- | | | +<------------------------+ |
- | | | | | ccw_device.ko|<-> physical
- | | | +------------------------>+ | device
- | | | | callbacks +--------------+
| +-----------+ |
+---------------+
@@ -270,106 +264,6 @@
other IOMMU backend modules, such as PPC64 sPAPR module, they need to provide
these two callback functions.
-Using the Sample Code
-=====================
-
-mtty.c in samples/vfio-mdev/ directory is a sample driver program to
-demonstrate how to use the mediated device framework.
-
-The sample driver creates an mdev device that simulates a serial port over a PCI
-card.
-
-1. Build and load the mtty.ko module.
-
- This step creates a dummy device, /sys/devices/virtual/mtty/mtty/
-
- Files in this device directory in sysfs are similar to the following::
-
- # tree /sys/devices/virtual/mtty/mtty/
- /sys/devices/virtual/mtty/mtty/
- |-- mdev_supported_types
- | |-- mtty-1
- | | |-- available_instances
- | | |-- create
- | | |-- device_api
- | | |-- devices
- | | `-- name
- | `-- mtty-2
- | |-- available_instances
- | |-- create
- | |-- device_api
- | |-- devices
- | `-- name
- |-- mtty_dev
- | `-- sample_mtty_dev
- |-- power
- | |-- autosuspend_delay_ms
- | |-- control
- | |-- runtime_active_time
- | |-- runtime_status
- | `-- runtime_suspended_time
- |-- subsystem -> ../../../../class/mtty
- `-- uevent
-
-2. Create a mediated device by using the dummy device that you created in the
- previous step::
-
- # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \
- /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/create
-
-3. Add parameters to qemu-kvm::
-
- -device vfio-pci,\
- sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
-
-4. Boot the VM.
-
- In the Linux guest VM, with no hardware on the host, the device appears
- as follows::
-
- # lspci -s 00:05.0 -xxvv
- 00:05.0 Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
- Subsystem: Device 4348:3253
- Physical Slot: 5
- Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
- Stepping- SERR- FastB2B- DisINTx-
- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
- <TAbort- <MAbort- >SERR- <PERR- INTx-
- Interrupt: pin A routed to IRQ 10
- Region 0: I/O ports at c150 [size=8]
- Region 1: I/O ports at c158 [size=8]
- Kernel driver in use: serial
- 00: 48 43 53 32 01 00 00 02 10 02 00 07 00 00 00 00
- 10: 51 c1 00 00 59 c1 00 00 00 00 00 00 00 00 00 00
- 20: 00 00 00 00 00 00 00 00 00 00 00 00 48 43 53 32
- 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
-
- In the Linux guest VM, dmesg output for the device is as follows:
-
- serial 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, high) -> IRQ 10
- 0000:00:05.0: ttyS1 at I/O 0xc150 (irq = 10) is a 16550A
- 0000:00:05.0: ttyS2 at I/O 0xc158 (irq = 10) is a 16550A
-
-
-5. In the Linux guest VM, check the serial ports::
-
- # setserial -g /dev/ttyS*
- /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
- /dev/ttyS1, UART: 16550A, Port: 0xc150, IRQ: 10
- /dev/ttyS2, UART: 16550A, Port: 0xc158, IRQ: 10
-
-6. Using minicom or any terminal emulation program, open port /dev/ttyS1 or
- /dev/ttyS2 with hardware flow control disabled.
-
-7. Type data on the minicom terminal or send data to the terminal emulation
- program and read the data.
-
- Data is loop backed from hosts mtty driver.
-
-8. Destroy the mediated device that you created::
-
- # echo 1 > /sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001/remove
-
References
==========
diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst
index c663b6f..68abc08 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -242,26 +242,28 @@
VFIO User API
-------------------------------------------------------------------------------
-Please see include/linux/vfio.h for complete API documentation.
+Please see include/uapi/linux/vfio.h for complete API documentation.
VFIO bus driver API
-------------------------------------------------------------------------------
VFIO bus drivers, such as vfio-pci make use of only a few interfaces
into VFIO core. When devices are bound and unbound to the driver,
-the driver should call vfio_register_group_dev() and
-vfio_unregister_group_dev() respectively::
+Following interfaces are called when devices are bound to and
+unbound from the driver::
- void vfio_init_group_dev(struct vfio_device *device,
- struct device *dev,
- const struct vfio_device_ops *ops);
- void vfio_uninit_group_dev(struct vfio_device *device);
int vfio_register_group_dev(struct vfio_device *device);
+ int vfio_register_emulated_iommu_dev(struct vfio_device *device);
void vfio_unregister_group_dev(struct vfio_device *device);
-The driver should embed the vfio_device in its own structure and call
-vfio_init_group_dev() to pre-configure it before going to registration
-and call vfio_uninit_group_dev() after completing the un-registration.
+The driver should embed the vfio_device in its own structure and use
+vfio_alloc_device() to allocate the structure, and can register
+@init/@release callbacks to manage any private state wrapping the
+vfio_device::
+
+ vfio_alloc_device(dev_struct, member, dev, ops);
+ void vfio_put_device(struct vfio_device *device);
+
vfio_register_group_dev() indicates to the core to begin tracking the
iommu_group of the specified dev and register the dev as owned by a VFIO bus
driver. Once vfio_register_group_dev() returns it is possible for userspace to
@@ -270,28 +272,64 @@
similar to a file operations structure::
struct vfio_device_ops {
- int (*open)(struct vfio_device *vdev);
+ char *name;
+ int (*init)(struct vfio_device *vdev);
void (*release)(struct vfio_device *vdev);
+ int (*bind_iommufd)(struct vfio_device *vdev,
+ struct iommufd_ctx *ictx, u32 *out_device_id);
+ void (*unbind_iommufd)(struct vfio_device *vdev);
+ int (*attach_ioas)(struct vfio_device *vdev, u32 *pt_id);
+ int (*open_device)(struct vfio_device *vdev);
+ void (*close_device)(struct vfio_device *vdev);
ssize_t (*read)(struct vfio_device *vdev, char __user *buf,
size_t count, loff_t *ppos);
- ssize_t (*write)(struct vfio_device *vdev,
- const char __user *buf,
- size_t size, loff_t *ppos);
+ ssize_t (*write)(struct vfio_device *vdev, const char __user *buf,
+ size_t count, loff_t *size);
long (*ioctl)(struct vfio_device *vdev, unsigned int cmd,
unsigned long arg);
- int (*mmap)(struct vfio_device *vdev,
- struct vm_area_struct *vma);
+ int (*mmap)(struct vfio_device *vdev, struct vm_area_struct *vma);
+ void (*request)(struct vfio_device *vdev, unsigned int count);
+ int (*match)(struct vfio_device *vdev, char *buf);
+ void (*dma_unmap)(struct vfio_device *vdev, u64 iova, u64 length);
+ int (*device_feature)(struct vfio_device *device, u32 flags,
+ void __user *arg, size_t argsz);
};
Each function is passed the vdev that was originally registered
-in the vfio_register_group_dev() call above. This allows the bus driver
-to obtain its private data using container_of(). The open/release
-callbacks are issued when a new file descriptor is created for a
-device (via VFIO_GROUP_GET_DEVICE_FD). The ioctl interface provides
-a direct pass through for VFIO_DEVICE_* ioctls. The read/write/mmap
-interfaces implement the device region access defined by the device's
-own VFIO_DEVICE_GET_REGION_INFO ioctl.
+in the vfio_register_group_dev() or vfio_register_emulated_iommu_dev()
+call above. This allows the bus driver to obtain its private data using
+container_of().
+::
+
+ - The init/release callbacks are issued when vfio_device is initialized
+ and released.
+
+ - The open/close device callbacks are issued when the first
+ instance of a file descriptor for the device is created (eg.
+ via VFIO_GROUP_GET_DEVICE_FD) for a user session.
+
+ - The ioctl callback provides a direct pass through for some VFIO_DEVICE_*
+ ioctls.
+
+ - The [un]bind_iommufd callbacks are issued when the device is bound to
+ and unbound from iommufd.
+
+ - The attach_ioas callback is issued when the device is attached to an
+ IOAS managed by the bound iommufd. The attached IOAS is automatically
+ detached when the device is unbound from iommufd.
+
+ - The read/write/mmap callbacks implement the device region access defined
+ by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl.
+
+ - The request callback is issued when device is going to be unregistered,
+ such as when trying to unbind the device from the vfio bus driver.
+
+ - The dma_unmap callback is issued when a range of iovas are unmapped
+ in the container or IOAS attached by the device. Drivers which make
+ use of the vfio page pinning interface must implement this callback in
+ order to unpin pages within the dma_unmap range. Drivers must tolerate
+ this callback even before calls to open_device().
PPC64 sPAPR implementation note
-------------------------------
diff --git a/Documentation/driver-api/virtio/index.rst b/Documentation/driver-api/virtio/index.rst
new file mode 100644
index 0000000..528b14b
--- /dev/null
+++ b/Documentation/driver-api/virtio/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======
+Virtio
+======
+
+.. toctree::
+ :maxdepth: 1
+
+ virtio
+ writing_virtio_drivers
diff --git a/Documentation/driver-api/virtio/virtio.rst b/Documentation/driver-api/virtio/virtio.rst
new file mode 100644
index 0000000..7947b4c
--- /dev/null
+++ b/Documentation/driver-api/virtio/virtio.rst
@@ -0,0 +1,145 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _virtio:
+
+===============
+Virtio on Linux
+===============
+
+Introduction
+============
+
+Virtio is an open standard that defines a protocol for communication
+between drivers and devices of different types, see Chapter 5 ("Device
+Types") of the virtio spec (`[1]`_). Originally developed as a standard
+for paravirtualized devices implemented by a hypervisor, it can be used
+to interface any compliant device (real or emulated) with a driver.
+
+For illustrative purposes, this document will focus on the common case
+of a Linux kernel running in a virtual machine and using paravirtualized
+devices provided by the hypervisor, which exposes them as virtio devices
+via standard mechanisms such as PCI.
+
+
+Device - Driver communication: virtqueues
+=========================================
+
+Although the virtio devices are really an abstraction layer in the
+hypervisor, they're exposed to the guest as if they are physical devices
+using a specific transport method -- PCI, MMIO or CCW -- that is
+orthogonal to the device itself. The virtio spec defines these transport
+methods in detail, including device discovery, capabilities and
+interrupt handling.
+
+The communication between the driver in the guest OS and the device in
+the hypervisor is done through shared memory (that's what makes virtio
+devices so efficient) using specialized data structures called
+virtqueues, which are actually ring buffers [#f1]_ of buffer descriptors
+similar to the ones used in a network device:
+
+.. kernel-doc:: include/uapi/linux/virtio_ring.h
+ :identifiers: struct vring_desc
+
+All the buffers the descriptors point to are allocated by the guest and
+used by the host either for reading or for writing but not for both.
+
+Refer to Chapter 2.5 ("Virtqueues") of the virtio spec (`[1]`_) for the
+reference definitions of virtqueues and "Virtqueues and virtio ring: How
+the data travels" blog post (`[2]`_) for an illustrated overview of how
+the host device and the guest driver communicate.
+
+The :c:type:`vring_virtqueue` struct models a virtqueue, including the
+ring buffers and management data. Embedded in this struct is the
+:c:type:`virtqueue` struct, which is the data structure that's
+ultimately used by virtio drivers:
+
+.. kernel-doc:: include/linux/virtio.h
+ :identifiers: struct virtqueue
+
+The callback function pointed by this struct is triggered when the
+device has consumed the buffers provided by the driver. More
+specifically, the trigger will be an interrupt issued by the hypervisor
+(see vring_interrupt()). Interrupt request handlers are registered for
+a virtqueue during the virtqueue setup process (transport-specific).
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: vring_interrupt
+
+
+Device discovery and probing
+============================
+
+In the kernel, the virtio core contains the virtio bus driver and
+transport-specific drivers like `virtio-pci` and `virtio-mmio`. Then
+there are individual virtio drivers for specific device types that are
+registered to the virtio bus driver.
+
+How a virtio device is found and configured by the kernel depends on how
+the hypervisor defines it. Taking the `QEMU virtio-console
+<https://gitlab.com/qemu-project/qemu/-/blob/master/hw/char/virtio-console.c>`__
+device as an example. When using PCI as a transport method, the device
+will present itself on the PCI bus with vendor 0x1af4 (Red Hat, Inc.)
+and device id 0x1003 (virtio console), as defined in the spec, so the
+kernel will detect it as it would do with any other PCI device.
+
+During the PCI enumeration process, if a device is found to match the
+virtio-pci driver (according to the virtio-pci device table, any PCI
+device with vendor id = 0x1af4)::
+
+ /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF. */
+ static const struct pci_device_id virtio_pci_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
+ { 0 }
+ };
+
+then the virtio-pci driver is probed and, if the probing goes well, the
+device is registered to the virtio bus::
+
+ static int virtio_pci_probe(struct pci_dev *pci_dev,
+ const struct pci_device_id *id)
+ {
+ ...
+
+ if (force_legacy) {
+ rc = virtio_pci_legacy_probe(vp_dev);
+ /* Also try modern mode if we can't map BAR0 (no IO space). */
+ if (rc == -ENODEV || rc == -ENOMEM)
+ rc = virtio_pci_modern_probe(vp_dev);
+ if (rc)
+ goto err_probe;
+ } else {
+ rc = virtio_pci_modern_probe(vp_dev);
+ if (rc == -ENODEV)
+ rc = virtio_pci_legacy_probe(vp_dev);
+ if (rc)
+ goto err_probe;
+ }
+
+ ...
+
+ rc = register_virtio_device(&vp_dev->vdev);
+
+When the device is registered to the virtio bus the kernel will look
+for a driver in the bus that can handle the device and call that
+driver's ``probe`` method.
+
+At this point, the virtqueues will be allocated and configured by
+calling the appropriate ``virtio_find`` helper function, such as
+virtio_find_single_vq() or virtio_find_vqs(), which will end up calling
+a transport-specific ``find_vqs`` method.
+
+
+References
+==========
+
+_`[1]` Virtio Spec v1.2:
+https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html
+
+.. Check for later versions of the spec as well.
+
+_`[2]` Virtqueues and virtio ring: How the data travels
+https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
+
+.. rubric:: Footnotes
+
+.. [#f1] that's why they may be also referred to as virtrings.
diff --git a/Documentation/driver-api/virtio/writing_virtio_drivers.rst b/Documentation/driver-api/virtio/writing_virtio_drivers.rst
new file mode 100644
index 0000000..e14c5879
--- /dev/null
+++ b/Documentation/driver-api/virtio/writing_virtio_drivers.rst
@@ -0,0 +1,197 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _writing_virtio_drivers:
+
+======================
+Writing Virtio Drivers
+======================
+
+Introduction
+============
+
+This document serves as a basic guideline for driver programmers that
+need to hack a new virtio driver or understand the essentials of the
+existing ones. See :ref:`Virtio on Linux <virtio>` for a general
+overview of virtio.
+
+
+Driver boilerplate
+==================
+
+As a bare minimum, a virtio driver needs to register in the virtio bus
+and configure the virtqueues for the device according to its spec, the
+configuration of the virtqueues in the driver side must match the
+virtqueue definitions in the device. A basic driver skeleton could look
+like this::
+
+ #include <linux/virtio.h>
+ #include <linux/virtio_ids.h>
+ #include <linux/virtio_config.h>
+ #include <linux/module.h>
+
+ /* device private data (one per device) */
+ struct virtio_dummy_dev {
+ struct virtqueue *vq;
+ };
+
+ static void virtio_dummy_recv_cb(struct virtqueue *vq)
+ {
+ struct virtio_dummy_dev *dev = vq->vdev->priv;
+ char *buf;
+ unsigned int len;
+
+ while ((buf = virtqueue_get_buf(dev->vq, &len)) != NULL) {
+ /* process the received data */
+ }
+ }
+
+ static int virtio_dummy_probe(struct virtio_device *vdev)
+ {
+ struct virtio_dummy_dev *dev = NULL;
+
+ /* initialize device data */
+ dev = kzalloc(sizeof(struct virtio_dummy_dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ /* the device has a single virtqueue */
+ dev->vq = virtio_find_single_vq(vdev, virtio_dummy_recv_cb, "input");
+ if (IS_ERR(dev->vq)) {
+ kfree(dev);
+ return PTR_ERR(dev->vq);
+
+ }
+ vdev->priv = dev;
+
+ /* from this point on, the device can notify and get callbacks */
+ virtio_device_ready(vdev);
+
+ return 0;
+ }
+
+ static void virtio_dummy_remove(struct virtio_device *vdev)
+ {
+ struct virtio_dummy_dev *dev = vdev->priv;
+
+ /*
+ * disable vq interrupts: equivalent to
+ * vdev->config->reset(vdev)
+ */
+ virtio_reset_device(vdev);
+
+ /* detach unused buffers */
+ while ((buf = virtqueue_detach_unused_buf(dev->vq)) != NULL) {
+ kfree(buf);
+ }
+
+ /* remove virtqueues */
+ vdev->config->del_vqs(vdev);
+
+ kfree(dev);
+ }
+
+ static const struct virtio_device_id id_table[] = {
+ { VIRTIO_ID_DUMMY, VIRTIO_DEV_ANY_ID },
+ { 0 },
+ };
+
+ static struct virtio_driver virtio_dummy_driver = {
+ .driver.name = KBUILD_MODNAME,
+ .driver.owner = THIS_MODULE,
+ .id_table = id_table,
+ .probe = virtio_dummy_probe,
+ .remove = virtio_dummy_remove,
+ };
+
+ module_virtio_driver(virtio_dummy_driver);
+ MODULE_DEVICE_TABLE(virtio, id_table);
+ MODULE_DESCRIPTION("Dummy virtio driver");
+ MODULE_LICENSE("GPL");
+
+The device id ``VIRTIO_ID_DUMMY`` here is a placeholder, virtio drivers
+should be added only for devices that are defined in the spec, see
+include/uapi/linux/virtio_ids.h. Device ids need to be at least reserved
+in the virtio spec before being added to that file.
+
+If your driver doesn't have to do anything special in its ``init`` and
+``exit`` methods, you can use the module_virtio_driver() helper to
+reduce the amount of boilerplate code.
+
+The ``probe`` method does the minimum driver setup in this case
+(memory allocation for the device data) and initializes the
+virtqueue. virtio_device_ready() is used to enable the virtqueue and to
+notify the device that the driver is ready to manage the device
+("DRIVER_OK"). The virtqueues are anyway enabled automatically by the
+core after ``probe`` returns.
+
+.. kernel-doc:: include/linux/virtio_config.h
+ :identifiers: virtio_device_ready
+
+In any case, the virtqueues need to be enabled before adding buffers to
+them.
+
+Sending and receiving data
+==========================
+
+The virtio_dummy_recv_cb() callback in the code above will be triggered
+when the device notifies the driver after it finishes processing a
+descriptor or descriptor chain, either for reading or writing. However,
+that's only the second half of the virtio device-driver communication
+process, as the communication is always started by the driver regardless
+of the direction of the data transfer.
+
+To configure a buffer transfer from the driver to the device, first you
+have to add the buffers -- packed as `scatterlists` -- to the
+appropriate virtqueue using any of the virtqueue_add_inbuf(),
+virtqueue_add_outbuf() or virtqueue_add_sgs(), depending on whether you
+need to add one input `scatterlist` (for the device to fill in), one
+output `scatterlist` (for the device to consume) or multiple
+`scatterlists`, respectively. Then, once the virtqueue is set up, a call
+to virtqueue_kick() sends a notification that will be serviced by the
+hypervisor that implements the device::
+
+ struct scatterlist sg[1];
+ sg_init_one(sg, buffer, BUFLEN);
+ virtqueue_add_inbuf(dev->vq, sg, 1, buffer, GFP_ATOMIC);
+ virtqueue_kick(dev->vq);
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_add_inbuf
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_add_outbuf
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_add_sgs
+
+Then, after the device has read or written the buffers prepared by the
+driver and notifies it back, the driver can call virtqueue_get_buf() to
+read the data produced by the device (if the virtqueue was set up with
+input buffers) or simply to reclaim the buffers if they were already
+consumed by the device:
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_get_buf_ctx
+
+The virtqueue callbacks can be disabled and re-enabled using the
+virtqueue_disable_cb() and the family of virtqueue_enable_cb() functions
+respectively. See drivers/virtio/virtio_ring.c for more details:
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_disable_cb
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_enable_cb
+
+But note that some spurious callbacks can still be triggered under
+certain scenarios. The way to disable callbacks reliably is to reset the
+device or the virtqueue (virtio_reset_device()).
+
+
+References
+==========
+
+_`[1]` Virtio Spec v1.2:
+https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html
+
+Check for later versions of the spec as well.
diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst
index 5f6454b..08e420e 100644
--- a/Documentation/fault-injection/fault-injection.rst
+++ b/Documentation/fault-injection/fault-injection.rst
@@ -231,6 +231,71 @@
This feature is intended for systematic testing of faults in a single
system call. See an example below.
+
+Error Injectable Functions
+--------------------------
+
+This part is for the kenrel developers considering to add a function to
+ALLOW_ERROR_INJECTION() macro.
+
+Requirements for the Error Injectable Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Since the function-level error injection forcibly changes the code path
+and returns an error even if the input and conditions are proper, this can
+cause unexpected kernel crash if you allow error injection on the function
+which is NOT error injectable. Thus, you (and reviewers) must ensure;
+
+- The function returns an error code if it fails, and the callers must check
+ it correctly (need to recover from it).
+
+- The function does not execute any code which can change any state before
+ the first error return. The state includes global or local, or input
+ variable. For example, clear output address storage (e.g. `*ret = NULL`),
+ increments/decrements counter, set a flag, preempt/irq disable or get
+ a lock (if those are recovered before returning error, that will be OK.)
+
+The first requirement is important, and it will result in that the release
+(free objects) functions are usually harder to inject errors than allocate
+functions. If errors of such release functions are not correctly handled
+it will cause a memory leak easily (the caller will confuse that the object
+has been released or corrupted.)
+
+The second one is for the caller which expects the function should always
+does something. Thus if the function error injection skips whole of the
+function, the expectation is betrayed and causes an unexpected error.
+
+Type of the Error Injectable Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each error injectable functions will have the error type specified by the
+ALLOW_ERROR_INJECTION() macro. You have to choose it carefully if you add
+a new error injectable function. If the wrong error type is chosen, the
+kernel may crash because it may not be able to handle the error.
+There are 4 types of errors defined in include/asm-generic/error-injection.h
+
+EI_ETYPE_NULL
+ This function will return `NULL` if it fails. e.g. return an allocateed
+ object address.
+
+EI_ETYPE_ERRNO
+ This function will return an `-errno` error code if it fails. e.g. return
+ -EINVAL if the input is wrong. This will include the functions which will
+ return an address which encodes `-errno` by ERR_PTR() macro.
+
+EI_ETYPE_ERRNO_NULL
+ This function will return an `-errno` or `NULL` if it fails. If the caller
+ of this function checks the return value with IS_ERR_OR_NULL() macro, this
+ type will be appropriate.
+
+EI_ETYPE_TRUE
+ This function will return `true` (non-zero positive value) if it fails.
+
+If you specifies a wrong type, for example, EI_TYPE_ERRNO for the function
+which returns an allocated object, it may cause a problem because the returned
+value is not an object address and the caller can not access to the address.
+
+
How to add new fault injection capability
-----------------------------------------
diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index e533750..bb2889c 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -29,7 +29,10 @@
Valid names are::
- NSTC: 480i output, with the CCIR System-M TV mode and NTSC color encoding
+ - NTSC-J: 480i output, with the CCIR System-M TV mode, the NTSC color
+ encoding, and a black level equal to the blanking level.
- PAL: 576i output, with the CCIR System-B TV mode and PAL color encoding
+ - PAL-M: 480i output, with the CCIR System-M TV mode and PAL color encoding
If 'M' is specified in the mode_option argument (after <yres> and before
<bpp> and <refresh>, if specified) the timings will be calculated using
@@ -70,6 +73,8 @@
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
degrees. Valid values are 0, 90, 180 and 270.
+ - tv_mode: Analog TV mode. One of "NTSC", "NTSC-443", "NTSC-J", "PAL",
+ "PAL-M", "PAL-N", or "SECAM".
- panel_orientation, one of "normal", "upside_down", "left_side_up", or
"right_side_up". For KMS drivers only, this sets the "panel orientation"
property on the kms connector as hint for kms users.
diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
index dc71bf7..3a7237b 100644
--- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt
+++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
@@ -14,7 +14,7 @@
| hexagon: | TODO |
| ia64: | TODO |
| loongarch: | ok |
- | m68k: | TODO |
+ | m68k: | ok |
| microblaze: | TODO |
| mips: | ok |
| nios2: | TODO |
diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst
index 46d78f8..ed5a5ca 100644
--- a/Documentation/filesystems/ext4/blockgroup.rst
+++ b/Documentation/filesystems/ext4/blockgroup.rst
@@ -105,9 +105,9 @@
block is placed at the beginning of the first, second, and last block
groups in a meta-block group. A meta-block group is a collection of
block groups which can be described by a single block group descriptor
-block. Since the size of the block group descriptor structure is 32
-bytes, a meta-block group contains 32 block groups for filesystems with
-a 1KB block size, and 128 block groups for filesystems with a 4KB
+block. Since the size of the block group descriptor structure is 64
+bytes, a meta-block group contains 16 block groups for filesystems with
+a 1KB block size, and 64 block groups for filesystems with a 4KB
blocksize. Filesystems can either be created using this new block group
descriptor layout, or existing filesystems can be resized on-line, and
the field s_first_meta_bg in the superblock will indicate the first
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 220f3e0..2055e72 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -158,7 +158,7 @@
If this option is set, no cache_flush commands are issued
but f2fs still guarantees the write ordering of all the
data writes.
-barrier If this option is set, cache_flush commands are allowed to be
+barrier If this option is set, cache_flush commands are allowed to be
issued.
fastboot This option is used when a system wants to reduce mount
time as much as possible, even though normal performance
diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index ef18338..eccd327 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -1277,8 +1277,8 @@
For the read path (->read_folio()) of regular files, filesystems can
read the ciphertext into the page cache and decrypt it in-place. The
-page lock must be held until decryption has finished, to prevent the
-page from becoming visible to userspace prematurely.
+folio lock must be held until decryption has finished, to prevent the
+folio from becoming visible to userspace prematurely.
For the write path (->writepage()) of regular files, filesystems
cannot encrypt data in-place in the page cache, since the cached
diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index cb8e757..ede672d 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -118,10 +118,11 @@
- ``hash_algorithm`` must be the identifier for the hash algorithm to
use for the Merkle tree, such as FS_VERITY_HASH_ALG_SHA256. See
``include/uapi/linux/fsverity.h`` for the list of possible values.
-- ``block_size`` must be the Merkle tree block size. Currently, this
- must be equal to the system page size, which is usually 4096 bytes.
- Other sizes may be supported in the future. This value is not
- necessarily the same as the filesystem block size.
+- ``block_size`` is the Merkle tree block size, in bytes. In Linux
+ v6.3 and later, this can be any power of 2 between (inclusively)
+ 1024 and the minimum of the system page size and the filesystem
+ block size. In earlier versions, the page size was the only allowed
+ value.
- ``salt_size`` is the size of the salt in bytes, or 0 if no salt is
provided. The salt is a value that is prepended to every hashed
block; it can be used to personalize the hashing for a particular
@@ -161,6 +162,7 @@
- ``EBUSY``: this ioctl is already running on the file
- ``EEXIST``: the file already has verity enabled
- ``EFAULT``: the caller provided inaccessible memory
+- ``EFBIG``: the file is too large to enable verity on
- ``EINTR``: the operation was interrupted by a fatal signal
- ``EINVAL``: unsupported version, hash algorithm, or block size; or
reserved bits are set; or the file descriptor refers to neither a
@@ -495,9 +497,11 @@
been formatted with ``-O verity`` or had ``tune2fs -O verity`` run on
it. "verity" is an RO_COMPAT filesystem feature, so once set, old
kernels will only be able to mount the filesystem readonly, and old
-versions of e2fsck will be unable to check the filesystem. Moreover,
-currently ext4 only supports mounting a filesystem with the "verity"
-feature when its block size is equal to PAGE_SIZE (often 4096 bytes).
+versions of e2fsck will be unable to check the filesystem.
+
+Originally, an ext4 filesystem with the "verity" feature could only be
+mounted when its block size was equal to the system page size
+(typically 4096 bytes). In Linux v6.3, this limitation was removed.
ext4 sets the EXT4_VERITY_FL on-disk inode flag on verity files. It
can only be set by `FS_IOC_ENABLE_VERITY`_, and it cannot be cleared.
@@ -518,9 +522,7 @@
encrypting xattrs. Note that the verity metadata *must* be encrypted
when the file is, since it contains hashes of the plaintext data.
-Currently, ext4 verity only supports the case where the Merkle tree
-block size, filesystem block size, and page size are all the same. It
-also only supports extent-based files.
+ext4 only allows verity on extent-based files.
f2fs
----
@@ -538,11 +540,10 @@
fsverity_descriptor) past the end of the file, starting at the first
64K boundary beyond i_size. See explanation for ext4 above.
Moreover, f2fs supports at most 4096 bytes of xattr entries per inode
-which wouldn't be enough for even a single Merkle tree block.
+which usually wouldn't be enough for even a single Merkle tree block.
-Currently, f2fs verity only supports a Merkle tree block size of 4096.
-Also, f2fs doesn't support enabling verity on files that currently
-have atomic or volatile writes pending.
+f2fs doesn't support enabling verity on files that currently have
+atomic or volatile writes pending.
btrfs
-----
@@ -567,51 +568,48 @@
~~~~~~~~~
For filesystems using Linux's pagecache, the ``->read_folio()`` and
-``->readahead()`` methods must be modified to verify pages before they
-are marked Uptodate. Merely hooking ``->read_iter()`` would be
+``->readahead()`` methods must be modified to verify folios before
+they are marked Uptodate. Merely hooking ``->read_iter()`` would be
insufficient, since ``->read_iter()`` is not used for memory maps.
-Therefore, fs/verity/ provides a function fsverity_verify_page() which
-verifies a page that has been read into the pagecache of a verity
-inode, but is still locked and not Uptodate, so it's not yet readable
-by userspace. As needed to do the verification,
-fsverity_verify_page() will call back into the filesystem to read
-Merkle tree pages via fsverity_operations::read_merkle_tree_page().
+Therefore, fs/verity/ provides the function fsverity_verify_blocks()
+which verifies data that has been read into the pagecache of a verity
+inode. The containing folio must still be locked and not Uptodate, so
+it's not yet readable by userspace. As needed to do the verification,
+fsverity_verify_blocks() will call back into the filesystem to read
+hash blocks via fsverity_operations::read_merkle_tree_page().
-fsverity_verify_page() returns false if verification failed; in this
-case, the filesystem must not set the page Uptodate. Following this,
+fsverity_verify_blocks() returns false if verification failed; in this
+case, the filesystem must not set the folio Uptodate. Following this,
as per the usual Linux pagecache behavior, attempts by userspace to
-read() from the part of the file containing the page will fail with
-EIO, and accesses to the page within a memory map will raise SIGBUS.
+read() from the part of the file containing the folio will fail with
+EIO, and accesses to the folio within a memory map will raise SIGBUS.
-fsverity_verify_page() currently only supports the case where the
-Merkle tree block size is equal to PAGE_SIZE (often 4096 bytes).
-
-In principle, fsverity_verify_page() verifies the entire path in the
-Merkle tree from the data page to the root hash. However, for
-efficiency the filesystem may cache the hash pages. Therefore,
-fsverity_verify_page() only ascends the tree reading hash pages until
-an already-verified hash page is seen, as indicated by the PageChecked
-bit being set. It then verifies the path to that page.
+In principle, verifying a data block requires verifying the entire
+path in the Merkle tree from the data block to the root hash.
+However, for efficiency the filesystem may cache the hash blocks.
+Therefore, fsverity_verify_blocks() only ascends the tree reading hash
+blocks until an already-verified hash block is seen. It then verifies
+the path to that block.
This optimization, which is also used by dm-verity, results in
excellent sequential read performance. This is because usually (e.g.
-127 in 128 times for 4K blocks and SHA-256) the hash page from the
+127 in 128 times for 4K blocks and SHA-256) the hash block from the
bottom level of the tree will already be cached and checked from
-reading a previous data page. However, random reads perform worse.
+reading a previous data block. However, random reads perform worse.
Block device based filesystems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Block device based filesystems (e.g. ext4 and f2fs) in Linux also use
the pagecache, so the above subsection applies too. However, they
-also usually read many pages from a file at once, grouped into a
+also usually read many data blocks from a file at once, grouped into a
structure called a "bio". To make it easier for these types of
filesystems to support fs-verity, fs/verity/ also provides a function
-fsverity_verify_bio() which verifies all pages in a bio.
+fsverity_verify_bio() which verifies all data blocks in a bio.
ext4 and f2fs also support encryption. If a verity file is also
-encrypted, the pages must be decrypted before being verified. To
+encrypted, the data must be decrypted before being verified. To
support this, these filesystems allocate a "post-read context" for
each bio and store it in ``->bi_private``::
@@ -626,14 +624,14 @@
verity, or both is enabled. After the bio completes, for each needed
postprocessing step the filesystem enqueues the bio_post_read_ctx on a
workqueue, and then the workqueue work does the decryption or
-verification. Finally, pages where no decryption or verity error
-occurred are marked Uptodate, and the pages are unlocked.
+verification. Finally, folios where no decryption or verity error
+occurred are marked Uptodate, and the folios are unlocked.
On many filesystems, files can contain holes. Normally,
-``->readahead()`` simply zeroes holes and sets the corresponding pages
-Uptodate; no bios are issued. To prevent this case from bypassing
-fs-verity, these filesystems use fsverity_verify_page() to verify hole
-pages.
+``->readahead()`` simply zeroes hole blocks and considers the
+corresponding data to be up-to-date; no bios are issued. To prevent
+this case from bypassing fs-verity, filesystems use
+fsverity_verify_blocks() to verify hole blocks.
Filesystems also disable direct I/O on verity files, since otherwise
direct I/O would bypass fs-verity.
@@ -644,7 +642,7 @@
This document focuses on the kernel, but a userspace utility for
fs-verity can be found at:
- https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git
+ https://git.kernel.org/pub/scm/fs/fsverity/fsverity-utils.git
See the README.md file in the fsverity-utils source tree for details,
including examples of setting up fs-verity protected files.
@@ -793,9 +791,9 @@
:A: There are many reasons why this is not possible or would be very
difficult, including the following:
- - To prevent bypassing verification, pages must not be marked
+ - To prevent bypassing verification, folios must not be marked
Uptodate until they've been verified. Currently, each
- filesystem is responsible for marking pages Uptodate via
+ filesystem is responsible for marking folios Uptodate via
``->readahead()``. Therefore, currently it's not possible for
the VFS to do the verification on its own. Changing this would
require significant changes to the VFS and all filesystems.
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index 36fa2a8..7de7a72 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -56,35 +56,35 @@
prototypes::
- int (*create) (struct inode *,struct dentry *,umode_t, bool);
+ int (*create) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t, bool);
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
- int (*symlink) (struct inode *,struct dentry *,const char *);
- int (*mkdir) (struct inode *,struct dentry *,umode_t);
+ int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *);
+ int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
- int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
- int (*rename) (struct inode *, struct dentry *,
+ int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t);
+ int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *,
struct inode *, struct dentry *, unsigned int);
int (*readlink) (struct dentry *, char __user *,int);
const char *(*get_link) (struct dentry *, struct inode *, struct delayed_call *);
void (*truncate) (struct inode *);
- int (*permission) (struct inode *, int, unsigned int);
+ int (*permission) (struct mnt_idmap *, struct inode *, int, unsigned int);
struct posix_acl * (*get_inode_acl)(struct inode *, int, bool);
- int (*setattr) (struct dentry *, struct iattr *);
- int (*getattr) (const struct path *, struct kstat *, u32, unsigned int);
+ int (*setattr) (struct mnt_idmap *, struct dentry *, struct iattr *);
+ int (*getattr) (struct mnt_idmap *, const struct path *, struct kstat *, u32, unsigned int);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *,
struct file *, unsigned open_flag,
umode_t create_mode);
- int (*tmpfile) (struct user_namespace *, struct inode *,
+ int (*tmpfile) (struct mnt_idmap *, struct inode *,
struct file *, umode_t);
- int (*fileattr_set)(struct user_namespace *mnt_userns,
+ int (*fileattr_set)(struct mnt_idmap *idmap,
struct dentry *dentry, struct fileattr *fa);
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
- struct posix_acl * (*get_acl)(struct user_namespace *, struct dentry *, int);
+ struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
locking rules:
all may block
@@ -135,7 +135,7 @@
struct inode *inode, const char *name, void *buffer,
size_t size);
int (*set)(const struct xattr_handler *handler,
- struct user_namespace *mnt_userns,
+ struct mnt_idmap *idmap,
struct dentry *dentry, struct inode *inode, const char *name,
const void *buffer, size_t size, int flags);
diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst
index 5147e15..a94c7a9 100644
--- a/Documentation/filesystems/nfs/client-identifier.rst
+++ b/Documentation/filesystems/nfs/client-identifier.rst
@@ -152,7 +152,7 @@
via the kernel command line, or when the "nfs" module is
loaded.
- /sys/fs/nfs/client/net/identifier
+ /sys/fs/nfs/net/nfs_client/identifier
This virtual file, available since Linux 5.3, is local to the
network namespace in which it is accessed and so can provide
distinction between network namespaces (containers) when the
@@ -164,7 +164,7 @@
be formed at boot using the container's internal identifier:
sha256sum /etc/machine-id | awk '{print $1}' \\
- > /sys/fs/nfs/client/net/identifier
+ > /sys/fs/nfs/net/nfs_client/identifier
Security considerations
-----------------------
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index e224b6d..9d5fd94 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -1284,6 +1284,7 @@
rt_cache Routing cache
snmp SNMP data
sockstat Socket statistics
+ softnet_stat Per-CPU incoming packets queues statistics of online CPUs
tcp TCP sockets
udp UDP sockets
unix UNIX domain sockets
diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst
index 2c15e70..f3b344f 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -421,31 +421,31 @@
.. code-block:: c
struct inode_operations {
- int (*create) (struct user_namespace *, struct inode *,struct dentry *, umode_t, bool);
+ int (*create) (struct mnt_idmap *, struct inode *,struct dentry *, umode_t, bool);
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
- int (*symlink) (struct user_namespace *, struct inode *,struct dentry *,const char *);
- int (*mkdir) (struct user_namespace *, struct inode *,struct dentry *,umode_t);
+ int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *);
+ int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
- int (*mknod) (struct user_namespace *, struct inode *,struct dentry *,umode_t,dev_t);
- int (*rename) (struct user_namespace *, struct inode *, struct dentry *,
+ int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t);
+ int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *,
struct inode *, struct dentry *, unsigned int);
int (*readlink) (struct dentry *, char __user *,int);
const char *(*get_link) (struct dentry *, struct inode *,
struct delayed_call *);
- int (*permission) (struct user_namespace *, struct inode *, int);
+ int (*permission) (struct mnt_idmap *, struct inode *, int);
struct posix_acl * (*get_inode_acl)(struct inode *, int, bool);
- int (*setattr) (struct user_namespace *, struct dentry *, struct iattr *);
- int (*getattr) (struct user_namespace *, const struct path *, struct kstat *, u32, unsigned int);
+ int (*setattr) (struct mnt_idmap *, struct dentry *, struct iattr *);
+ int (*getattr) (struct mnt_idmap *, const struct path *, struct kstat *, u32, unsigned int);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *, struct file *,
unsigned open_flag, umode_t create_mode);
- int (*tmpfile) (struct user_namespace *, struct inode *, struct file *, umode_t);
- struct posix_acl * (*get_acl)(struct user_namespace *, struct dentry *, int);
- int (*set_acl)(struct user_namespace *, struct dentry *, struct posix_acl *, int);
- int (*fileattr_set)(struct user_namespace *mnt_userns,
+ int (*tmpfile) (struct mnt_idmap *, struct inode *, struct file *, umode_t);
+ struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
+ int (*set_acl)(struct mnt_idmap *, struct dentry *, struct posix_acl *, int);
+ int (*fileattr_set)(struct mnt_idmap *idmap,
struct dentry *dentry, struct fileattr *fa);
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
};
@@ -1222,7 +1222,7 @@
return
-ECHILD and it will be called again in ref-walk mode.
-``_weak_revalidate``
+``d_weak_revalidate``
called when the VFS needs to revalidate a "jumped" dentry. This
is called when a path-walk ends at dentry that was not acquired
by doing a lookup in the parent directory. This includes "/",
diff --git a/Documentation/firmware-guide/acpi/acpi-lid.rst b/Documentation/firmware-guide/acpi/acpi-lid.rst
index 71b9af1..03cbad6 100644
--- a/Documentation/firmware-guide/acpi/acpi-lid.rst
+++ b/Documentation/firmware-guide/acpi/acpi-lid.rst
@@ -34,7 +34,7 @@
_LID control method is evaluated during the runtime, the problem is its
initial returning value. When the AML tables implement this control method
with cached value, the initial returning value is likely not reliable.
-There are platforms always retun "closed" as initial lid state.
+There are platforms always return "closed" as initial lid state.
Restrictions of the lid state change notifications
==================================================
diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index b9dc0c6..56d9913 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -19,7 +19,7 @@
platform devices.
- Devices behind real busses where there is a connector resource
- are represented as struct spi_device or struct i2c_device. Note
+ are represented as struct spi_device or struct i2c_client. Note
that standard UARTs are not busses so there is no struct uart_device,
although some of them may be represented by struct serdev_device.
diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
index eaec732..db0c0b1 100644
--- a/Documentation/firmware-guide/acpi/gpio-properties.rst
+++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
@@ -67,17 +67,30 @@
Linux tries to use common sense here and derives the state from the bias
and polarity settings. The table below shows the expectations:
-========= ============= ==============
-Pull Bias Polarity Requested...
-========= ============= ==============
-Implicit x AS IS (assumed firmware configured for us)
-Explicit x (no _DSD) as Pull Bias (Up == High, Down == Low),
- assuming non-active (Polarity = !Pull Bias)
-Down Low as low, assuming active
-Down High as low, assuming non-active
-Up Low as high, assuming non-active
-Up High as high, assuming active
-========= ============= ==============
++-------------+-------------+-----------------------------------------------+
+| Pull Bias | Polarity | Requested... |
++=============+=============+===============================================+
+| Implicit |
++-------------+-------------+-----------------------------------------------+
+| **Default** | x | AS IS (assumed firmware configured it for us) |
++-------------+-------------+-----------------------------------------------+
+| Explicit |
++-------------+-------------+-----------------------------------------------+
+| **None** | x | AS IS (assumed firmware configured it for us) |
+| | | with no Pull Bias |
++-------------+-------------+-----------------------------------------------+
+| **Up** | x (no _DSD) | |
+| +-------------+ as high, assuming non-active |
+| | Low | |
+| +-------------+-----------------------------------------------+
+| | High | as high, assuming active |
++-------------+-------------+-----------------------------------------------+
+| **Down** | x (no _DSD) | |
+| +-------------+ as low, assuming non-active |
+| | High | |
+| +-------------+-----------------------------------------------+
+| | Low | as low, assuming active |
++-------------+-------------+-----------------------------------------------+
That said, for our above example the both GPIOs, since the bias setting
is explicit and _DSD is present, will be treated as active with a high
diff --git a/Documentation/firmware-guide/acpi/namespace.rst b/Documentation/firmware-guide/acpi/namespace.rst
index 6193582..4ef9636 100644
--- a/Documentation/firmware-guide/acpi/namespace.rst
+++ b/Documentation/firmware-guide/acpi/namespace.rst
@@ -31,7 +31,7 @@
Description Table) using its first entry, the data within the FADT
includes various fixed-length entries that describe fixed ACPI features
of the hardware. The FADT contains a pointer to the DSDT
-(Differentiated System Descripition Table). The XSDT also contains
+(Differentiated System Description Table). The XSDT also contains
entries pointing to possibly multiple SSDTs (Secondary System
Description Table).
diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 15b6709..80255e2 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -75,6 +75,125 @@
and can be implemented in register regions of any FPGA device.
+Device Feature Header - Version 0
+=================================
+Version 0 (DFHv0) is the original version of the Device Feature Header.
+All multi-byte quantities in DFHv0 are little-endian.
+The format of DFHv0 is shown below::
+
+ +-----------------------------------------------------------------------+
+ |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
+ +-----------------------------------------------------------------------+
+ |63 GUID_L 0| 0x08
+ +-----------------------------------------------------------------------+
+ |63 GUID_H 0| 0x10
+ +-----------------------------------------------------------------------+
+
+- Offset 0x00
+
+ * Type - The type of DFH (e.g. FME, AFU, or private feature).
+ * DFH VER - The version of the DFH.
+ * Rsvd - Currently unused.
+ * EOL - Set if the DFH is the end of the Device Feature List (DFL).
+ * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
+ and the start of a DFH must be aligned to an 8 byte boundary.
+ If EOL is set, Next is the size of MMIO of the last feature in the list.
+ * REV - The revision of the feature associated with this header.
+ * ID - The feature ID if Type is private feature.
+
+- Offset 0x08
+
+ * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier
+ (present only if Type is FME or AFU).
+
+- Offset 0x10
+
+ * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier
+ (present only if Type is FME or AFU).
+
+
+Device Feature Header - Version 1
+=================================
+Version 1 (DFHv1) of the Device Feature Header adds the following functionality:
+
+* Provides a standardized mechanism for features to describe
+ parameters/capabilities to software.
+* Standardize the use of a GUID for all DFHv1 types.
+* Decouples the DFH location from the register space of the feature itself.
+
+All multi-byte quantities in DFHv1 are little-endian.
+The format of Version 1 of the Device Feature Header (DFH) is shown below::
+
+ +-----------------------------------------------------------------------+
+ |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
+ +-----------------------------------------------------------------------+
+ |63 GUID_L 0| 0x08
+ +-----------------------------------------------------------------------+
+ |63 GUID_H 0| 0x10
+ +-----------------------------------------------------------------------+
+ |63 Reg Address/Offset 1| Rel 0| 0x18
+ +-----------------------------------------------------------------------+
+ |63 Reg Size 32|Params 31|30 Group 16|15 Instance 0| 0x20
+ +-----------------------------------------------------------------------+
+ |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0| 0x28
+ +-----------------------------------------------------------------------+
+ |63 Parameter Data 0| 0x30
+ +-----------------------------------------------------------------------+
+
+ ...
+
+ +-----------------------------------------------------------------------+
+ |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0|
+ +-----------------------------------------------------------------------+
+ |63 Parameter Data 0|
+ +-----------------------------------------------------------------------+
+
+- Offset 0x00
+
+ * Type - The type of DFH (e.g. FME, AFU, or private feature).
+ * DFH VER - The version of the DFH.
+ * Rsvd - Currently unused.
+ * EOL - Set if the DFH is the end of the Device Feature List (DFL).
+ * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
+ and the start of a DFH must be aligned to an 8 byte boundary.
+ If EOL is set, Next is the size of MMIO of the last feature in the list.
+ * REV - The revision of the feature associated with this header.
+ * ID - The feature ID if Type is private feature.
+
+- Offset 0x08
+
+ * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier.
+
+- Offset 0x10
+
+ * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier.
+
+- Offset 0x18
+
+ * Reg Address/Offset - If Rel bit is set, then the value is the high 63 bits
+ of a 16-bit aligned absolute address of the feature's registers. Otherwise
+ the value is the offset from the start of the DFH of the feature's registers.
+
+- Offset 0x20
+
+ * Reg Size - Size of feature's register set in bytes.
+ * Params - Set if DFH has a list of parameter blocks.
+ * Group - Id of group if feature is part of a group.
+ * Instance - Id of feature instance within a group.
+
+- Offset 0x28 if feature has parameters
+
+ * Next - Offset to the next parameter block in 8 byte words. If EOP set,
+ size in 8 byte words of last parameter.
+ * Param Version - Version of Param ID.
+ * Param ID - ID of parameter.
+
+- Offset 0x30
+
+ * Parameter Data - Parameter data whose size and format is defined by
+ version and ID of the parameter.
+
+
FIU - FME (FPGA Management Engine)
==================================
The FPGA Management Engine performs reconfiguration and other infrastructure
diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv
index 98c6988..395a7b7 100644
--- a/Documentation/gpu/amdgpu/apu-asic-info-table.csv
+++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv
@@ -1,8 +1,10 @@
-Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN version, SDMA version
-Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3
-Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0
-Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2
-Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1
-SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1
-Ryzen 5000 series, GREEN SARDINE, DCN 2.1, 9.3, VCN 2.2, 4.1.1
-Ryzen 6000 Zen, YELLOW CARP, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3
+Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN version, SDMA version, MP0 version
+Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3, n/a
+Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0, 10.0.0
+Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2, 11.0.3
+Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1, 10.0.1
+SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1, 11.5.0
+Ryzen 5000 series / Ryzen 7x30 series, GREEN SARDINE / Cezanne / Barcelo / Barcelo-R, DCN 2.1, 9.3, VCN 2.2, 4.1.1, 12.0.1
+Ryzen 6000 series / Ryzen 7x35 series, YELLOW CARP / Rembrandt / Rembrandt+, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3
+Ryzen 7000 series (AM5), Raphael, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5
+Ryzen 7x20 series, Mendocino, 3.1.6, 10.3.7, 3.1.1, 5.2.7, 13.0.8
diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv
index 84617aa..882d251 100644
--- a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv
+++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv
@@ -22,3 +22,5 @@
AMD Radeon RX 6700 XT / 6800M / 6700M, NAVY_FLOUNDER, DCN 3.0.0, 10.3.2, VCN 3.0.0, 5.2.2
AMD Radeon RX 6600(XT) /6600M /W6600 /W6600M, DIMGREY_CAVEFISH, DCN 3.0.2, 10.3.4, VCN 3.0.16, 5.2.4
AMD Radeon RX 6500M /6300M /W6500M /W6300M, BEIGE_GOBY, DCN 3.0.3, 10.3.5, VCN 3.0.33, 5.2.5
+AMD Radeon RX 7900 XT /XTX, , DCN 3.2.0, 11.0.0, VCN 4.0.0, 6.0.0
+AMD Radeon RX 7600M (XT) /7700S /7600S, , DCN 3.2.1, 11.0.2, VCN 4.0.4, 6.0.2
diff --git a/Documentation/gpu/amdgpu/driver-misc.rst b/Documentation/gpu/amdgpu/driver-misc.rst
index 1800543..be131e9 100644
--- a/Documentation/gpu/amdgpu/driver-misc.rst
+++ b/Documentation/gpu/amdgpu/driver-misc.rst
@@ -37,7 +37,7 @@
.. csv-table::
:header-rows: 1
- :widths: 3, 2, 2, 1, 1, 1
+ :widths: 3, 2, 2, 1, 1, 1, 1
:file: ./apu-asic-info-table.csv
Discrete GPU Info
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index a4860ff..b8ab05e 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -188,6 +188,13 @@
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:
+MIPI-DSI bridge operation
+-------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+ :doc: dsi bridge operations
+
+
Bridge Connector Helper Reference
---------------------------------
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index b4377a54..c92d425 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -520,6 +520,12 @@
.. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: HDMI connector properties
+Analog TV Specific Connector Properties
+---------------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: Analog TV Connector Properties
+
Standard CRTC Properties
------------------------
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index ce47b42..65fb303 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -402,19 +402,19 @@
1. Use IGT inside a VM
2. Use IGT from the host machine and write the results in a shared directory.
-As follow, there is an example of using a VM with a shared directory with
-the host machine to run igt-tests. As an example it's used virtme::
+Following is an example of using a VM with a shared directory with
+the host machine to run igt-tests. This example uses virtme::
$ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto
-Run the igt-tests in the guest machine, as example it's ran the 'kms_flip'
+Run the igt-tests in the guest machine. This example runs the 'kms_flip'
tests::
$ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v
-In this example, instead of build the igt_runner, Piglit is used
-(-p option); it's created html summary of the tests results and it's saved
-in the folder "igt-gpu-tools/results"; it's executed only the igt-tests
+In this example, instead of building the igt_runner, Piglit is used
+(-p option). It creates an HTML summary of the test results and saves
+them in the folder "igt-gpu-tools/results". It executes only the igt-tests
matching the -t option.
Display CRC Support
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index b99dede..eee5996 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -1,6 +1,6 @@
-==================================
-Linux GPU Driver Developer's Guide
-==================================
+============================
+GPU Driver Developer's Guide
+============================
.. toctree::
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b2c6aaf..1f8a5eb 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -508,17 +508,18 @@
There's a bunch of issues with it:
-- The drm_info_list ->show() function doesn't even bother to cast to the drm
- structure for you. This is lazy.
+- Convert drivers to support the drm_debugfs_add_files() function instead of
+ the drm_debugfs_create_files() function.
+
+- Improve late-register debugfs by rolling out the same debugfs pre-register
+ infrastructure for connector and crtc too. That way, the drivers won't need to
+ split their setup code into init and register anymore.
- We probably want to have some support for debugfs files on crtc/connectors and
maybe other kms objects directly in core. There's even drm_print support in
the funcs for these objects to dump kms state, so it's all there. And then the
->show() functions should obviously give you a pointer to the right object.
-- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
- anything we want to print drm_device (or maybe drm_file) is the right thing.
-
- The drm_driver->debugfs_init hooks we have is just an artifact of the old
midlayered load sequence. DRM debugfs should work more like sysfs, where you
can create properties/files for an object anytime you want, and the core
@@ -527,8 +528,6 @@
this (together with the drm_minor->drm_device move) would allow us to remove
debugfs_init.
-Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/
-
Contact: Daniel Vetter
Level: Intermediate
diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst
index 5df1d98..5e5e92e4 100644
--- a/Documentation/gpu/vc4.rst
+++ b/Documentation/gpu/vc4.rst
@@ -54,6 +54,25 @@
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_vec.c
:doc: VC4 SDTV module
+KUnit Tests
+===========
+
+The VC4 Driver uses KUnit to perform driver-specific unit and
+integration tests.
+
+These tests are using a mock driver and can be ran using the
+command below, on either arm or arm64 architectures,
+
+.. code-block:: bash
+
+ $ ./tools/testing/kunit/kunit.py run \
+ --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \
+ --cross_compile aarch64-linux-gnu- --arch arm64
+
+Parts of the driver that are currently covered by tests are:
+ * The HVS to PixelValve dynamic FIFO assignment, for the BCM2835-7
+ and BCM2711.
+
Memory Management and 3D Command Submission
===========================================
diff --git a/Documentation/hid/hid-alps.rst b/Documentation/hid/hid-alps.rst
index 767c96b..94382bb 100644
--- a/Documentation/hid/hid-alps.rst
+++ b/Documentation/hid/hid-alps.rst
@@ -9,7 +9,7 @@
U1 device basic information.
========== ======
-Vender ID 0x044E
+Vendor ID 0x044E
Product ID 0x120B
Version ID 0x0121
========== ======
diff --git a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-bpf.rst
new file mode 100644
index 0000000..4fad83a
--- /dev/null
+++ b/Documentation/hid/hid-bpf.rst
@@ -0,0 +1,522 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======
+HID-BPF
+=======
+
+HID is a standard protocol for input devices but some devices may require
+custom tweaks, traditionally done with a kernel driver fix. Using the eBPF
+capabilities instead speeds up development and adds new capabilities to the
+existing HID interfaces.
+
+.. contents::
+ :local:
+ :depth: 2
+
+
+When (and why) to use HID-BPF
+=============================
+
+There are several use cases when using HID-BPF is better
+than standard kernel driver fix:
+
+Dead zone of a joystick
+-----------------------
+
+Assuming you have a joystick that is getting older, it is common to see it
+wobbling around its neutral point. This is usually filtered at the application
+level by adding a *dead zone* for this specific axis.
+
+With HID-BPF, we can apply this filtering in the kernel directly so userspace
+does not get woken up when nothing else is happening on the input controller.
+
+Of course, given that this dead zone is specific to an individual device, we
+can not create a generic fix for all of the same joysticks. Adding a custom
+kernel API for this (e.g. by adding a sysfs entry) does not guarantee this new
+kernel API will be broadly adopted and maintained.
+
+HID-BPF allows the userspace program to load the program itself, ensuring we
+only load the custom API when we have a user.
+
+Simple fixup of report descriptor
+---------------------------------
+
+In the HID tree, half of the drivers only fix one key or one byte
+in the report descriptor. These fixes all require a kernel patch and the
+subsequent shepherding into a release, a long and painful process for users.
+
+We can reduce this burden by providing an eBPF program instead. Once such a
+program has been verified by the user, we can embed the source code into the
+kernel tree and ship the eBPF program and load it directly instead of loading
+a specific kernel module for it.
+
+Note: distribution of eBPF programs and their inclusion in the kernel is not
+yet fully implemented
+
+Add a new feature that requires a new kernel API
+------------------------------------------------
+
+An example for such a feature are the Universal Stylus Interface (USI) pens.
+Basically, USI pens require a new kernel API because there are new
+channels of communication that our HID and input stack do not support.
+Instead of using hidraw or creating new sysfs entries or ioctls, we can rely
+on eBPF to have the kernel API controlled by the consumer and to not
+impact the performances by waking up userspace every time there is an
+event.
+
+Morph a device into something else and control that from userspace
+------------------------------------------------------------------
+
+The kernel has a relatively static mapping of HID items to evdev bits.
+It cannot decide to dynamically transform a given device into something else
+as it does not have the required context and any such transformation cannot be
+undone (or even discovered) by userspace.
+
+However, some devices are useless with that static way of defining devices. For
+example, the Microsoft Surface Dial is a pushbutton with haptic feedback that
+is barely usable as of today.
+
+With eBPF, userspace can morph that device into a mouse, and convert the dial
+events into wheel events. Also, the userspace program can set/unset the haptic
+feedback depending on the context. For example, if a menu is visible on the
+screen we likely need to have a haptic click every 15 degrees. But when
+scrolling in a web page the user experience is better when the device emits
+events at the highest resolution.
+
+Firewall
+--------
+
+What if we want to prevent other users to access a specific feature of a
+device? (think a possibly broken firmware update entry point)
+
+With eBPF, we can intercept any HID command emitted to the device and
+validate it or not.
+
+This also allows to sync the state between the userspace and the
+kernel/bpf program because we can intercept any incoming command.
+
+Tracing
+-------
+
+The last usage is tracing events and all the fun we can do we BPF to summarize
+and analyze events.
+
+Right now, tracing relies on hidraw. It works well except for a couple
+of issues:
+
+1. if the driver doesn't export a hidraw node, we can't trace anything
+ (eBPF will be a "god-mode" there, so this may raise some eyebrows)
+2. hidraw doesn't catch other processes' requests to the device, which
+ means that we have cases where we need to add printks to the kernel
+ to understand what is happening.
+
+High-level view of HID-BPF
+==========================
+
+The main idea behind HID-BPF is that it works at an array of bytes level.
+Thus, all of the parsing of the HID report and the HID report descriptor
+must be implemented in the userspace component that loads the eBPF
+program.
+
+For example, in the dead zone joystick from above, knowing which fields
+in the data stream needs to be set to ``0`` needs to be computed by userspace.
+
+A corollary of this is that HID-BPF doesn't know about the other subsystems
+available in the kernel. *You can not directly emit input event through the
+input API from eBPF*.
+
+When a BPF program needs to emit input events, it needs to talk with the HID
+protocol, and rely on the HID kernel processing to translate the HID data into
+input events.
+
+Available types of programs
+===========================
+
+HID-BPF is built "on top" of BPF, meaning that we use tracing method to
+declare our programs.
+
+HID-BPF has the following attachment types available:
+
+1. event processing/filtering with ``SEC("fmod_ret/hid_bpf_device_event")`` in libbpf
+2. actions coming from userspace with ``SEC("syscall")`` in libbpf
+3. change of the report descriptor with ``SEC("fmod_ret/hid_bpf_rdesc_fixup")`` in libbpf
+
+A ``hid_bpf_device_event`` is calling a BPF program when an event is received from
+the device. Thus we are in IRQ context and can act on the data or notify userspace.
+And given that we are in IRQ context, we can not talk back to the device.
+
+A ``syscall`` means that userspace called the syscall ``BPF_PROG_RUN`` facility.
+This time, we can do any operations allowed by HID-BPF, and talking to the device is
+allowed.
+
+Last, ``hid_bpf_rdesc_fixup`` is different from the others as there can be only one
+BPF program of this type. This is called on ``probe`` from the driver and allows to
+change the report descriptor from the BPF program. Once a ``hid_bpf_rdesc_fixup``
+program has been loaded, it is not possible to overwrite it unless the program which
+inserted it allows us by pinning the program and closing all of its fds pointing to it.
+
+Developer API:
+==============
+
+User API data structures available in programs:
+-----------------------------------------------
+
+.. kernel-doc:: include/linux/hid_bpf.h
+
+Available tracing functions to attach a HID-BPF program:
+--------------------------------------------------------
+
+.. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
+ :functions: hid_bpf_device_event hid_bpf_rdesc_fixup
+
+Available API that can be used in all HID-BPF programs:
+-------------------------------------------------------
+
+.. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
+ :functions: hid_bpf_get_data
+
+Available API that can be used in syscall HID-BPF programs:
+-----------------------------------------------------------
+
+.. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
+ :functions: hid_bpf_attach_prog hid_bpf_hw_request hid_bpf_allocate_context hid_bpf_release_context
+
+General overview of a HID-BPF program
+=====================================
+
+Accessing the data attached to the context
+------------------------------------------
+
+The ``struct hid_bpf_ctx`` doesn't export the ``data`` fields directly and to access
+it, a bpf program needs to first call :c:func:`hid_bpf_get_data`.
+
+``offset`` can be any integer, but ``size`` needs to be constant, known at compile
+time.
+
+This allows the following:
+
+1. for a given device, if we know that the report length will always be of a certain value,
+ we can request the ``data`` pointer to point at the full report length.
+
+ The kernel will ensure we are using a correct size and offset and eBPF will ensure
+ the code will not attempt to read or write outside of the boundaries::
+
+ __u8 *data = hid_bpf_get_data(ctx, 0 /* offset */, 256 /* size */);
+
+ if (!data)
+ return 0; /* ensure data is correct, now the verifier knows we
+ * have 256 bytes available */
+
+ bpf_printk("hello world: %02x %02x %02x", data[0], data[128], data[255]);
+
+2. if the report length is variable, but we know the value of ``X`` is always a 16-bit
+ integer, we can then have a pointer to that value only::
+
+ __u16 *x = hid_bpf_get_data(ctx, offset, sizeof(*x));
+
+ if (!x)
+ return 0; /* something went wrong */
+
+ *x += 1; /* increment X by one */
+
+Effect of a HID-BPF program
+---------------------------
+
+For all HID-BPF attachment types except for :c:func:`hid_bpf_rdesc_fixup`, several eBPF
+programs can be attached to the same device.
+
+Unless ``HID_BPF_FLAG_INSERT_HEAD`` is added to the flags while attaching the
+program, the new program is appended at the end of the list.
+``HID_BPF_FLAG_INSERT_HEAD`` will insert the new program at the beginning of the
+list which is useful for e.g. tracing where we need to get the unprocessed events
+from the device.
+
+Note that if there are multiple programs using the ``HID_BPF_FLAG_INSERT_HEAD`` flag,
+only the most recently loaded one is actually the first in the list.
+
+``SEC("fmod_ret/hid_bpf_device_event")``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Whenever a matching event is raised, the eBPF programs are called one after the other
+and are working on the same data buffer.
+
+If a program changes the data associated with the context, the next one will see
+the modified data but it will have *no* idea of what the original data was.
+
+Once all the programs are run and return ``0`` or a positive value, the rest of the
+HID stack will work on the modified data, with the ``size`` field of the last hid_bpf_ctx
+being the new size of the input stream of data.
+
+A BPF program returning a negative error discards the event, i.e. this event will not be
+processed by the HID stack. Clients (hidraw, input, LEDs) will **not** see this event.
+
+``SEC("syscall")``
+~~~~~~~~~~~~~~~~~~
+
+``syscall`` are not attached to a given device. To tell which device we are working
+with, userspace needs to refer to the device by its unique system id (the last 4 numbers
+in the sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``).
+
+To retrieve a context associated with the device, the program must call
+:c:func:`hid_bpf_allocate_context` and must release it with :c:func:`hid_bpf_release_context`
+before returning.
+Once the context is retrieved, one can also request a pointer to kernel memory with
+:c:func:`hid_bpf_get_data`. This memory is big enough to support all input/output/feature
+reports of the given device.
+
+``SEC("fmod_ret/hid_bpf_rdesc_fixup")``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``hid_bpf_rdesc_fixup`` program works in a similar manner to
+``.report_fixup`` of ``struct hid_driver``.
+
+When the device is probed, the kernel sets the data buffer of the context with the
+content of the report descriptor. The memory associated with that buffer is
+``HID_MAX_DESCRIPTOR_SIZE`` (currently 4kB).
+
+The eBPF program can modify the data buffer at-will and the kernel uses the
+modified content and size as the report descriptor.
+
+Whenever a ``SEC("fmod_ret/hid_bpf_rdesc_fixup")`` program is attached (if no
+program was attached before), the kernel immediately disconnects the HID device
+and does a reprobe.
+
+In the same way, when the ``SEC("fmod_ret/hid_bpf_rdesc_fixup")`` program is
+detached, the kernel issues a disconnect on the device.
+
+There is no ``detach`` facility in HID-BPF. Detaching a program happens when
+all the user space file descriptors pointing at a program are closed.
+Thus, if we need to replace a report descriptor fixup, some cooperation is
+required from the owner of the original report descriptor fixup.
+The previous owner will likely pin the program in the bpffs, and we can then
+replace it through normal bpf operations.
+
+Attaching a bpf program to a device
+===================================
+
+``libbpf`` does not export any helper to attach a HID-BPF program.
+Users need to use a dedicated ``syscall`` program which will call
+``hid_bpf_attach_prog(hid_id, program_fd, flags)``.
+
+``hid_id`` is the unique system ID of the HID device (the last 4 numbers in the
+sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``)
+
+``progam_fd`` is the opened file descriptor of the program to attach.
+
+``flags`` is of type ``enum hid_bpf_attach_flags``.
+
+We can not rely on hidraw to bind a BPF program to a HID device. hidraw is an
+artefact of the processing of the HID device, and is not stable. Some drivers
+even disable it, so that removes the tracing capabilities on those devices
+(where it is interesting to get the non-hidraw traces).
+
+On the other hand, the ``hid_id`` is stable for the entire life of the HID device,
+even if we change its report descriptor.
+
+Given that hidraw is not stable when the device disconnects/reconnects, we recommend
+accessing the current report descriptor of the device through the sysfs.
+This is available at ``/sys/bus/hid/devices/BUS:VID:PID.000N/report_descriptor`` as a
+binary stream.
+
+Parsing the report descriptor is the responsibility of the BPF programmer or the userspace
+component that loads the eBPF program.
+
+An (almost) complete example of a BPF enhanced HID device
+=========================================================
+
+*Foreword: for most parts, this could be implemented as a kernel driver*
+
+Let's imagine we have a new tablet device that has some haptic capabilities
+to simulate the surface the user is scratching on. This device would also have
+a specific 3 positions switch to toggle between *pencil on paper*, *cray on a wall*
+and *brush on a painting canvas*. To make things even better, we can control the
+physical position of the switch through a feature report.
+
+And of course, the switch is relying on some userspace component to control the
+haptic feature of the device itself.
+
+Filtering events
+----------------
+
+The first step consists in filtering events from the device. Given that the switch
+position is actually reported in the flow of the pen events, using hidraw to implement
+that filtering would mean that we wake up userspace for every single event.
+
+This is OK for libinput, but having an external library that is just interested in
+one byte in the report is less than ideal.
+
+For that, we can create a basic skeleton for our BPF program::
+
+ #include "vmlinux.h"
+ #include <bpf/bpf_helpers.h>
+ #include <bpf/bpf_tracing.h>
+
+ /* HID programs need to be GPL */
+ char _license[] SEC("license") = "GPL";
+
+ /* HID-BPF kfunc API definitions */
+ extern __u8 *hid_bpf_get_data(struct hid_bpf_ctx *ctx,
+ unsigned int offset,
+ const size_t __sz) __ksym;
+ extern int hid_bpf_attach_prog(unsigned int hid_id, int prog_fd, u32 flags) __ksym;
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_RINGBUF);
+ __uint(max_entries, 4096 * 64);
+ } ringbuf SEC(".maps");
+
+ struct attach_prog_args {
+ int prog_fd;
+ unsigned int hid;
+ unsigned int flags;
+ int retval;
+ };
+
+ SEC("syscall")
+ int attach_prog(struct attach_prog_args *ctx)
+ {
+ ctx->retval = hid_bpf_attach_prog(ctx->hid,
+ ctx->prog_fd,
+ ctx->flags);
+ return 0;
+ }
+
+ __u8 current_value = 0;
+
+ SEC("?fmod_ret/hid_bpf_device_event")
+ int BPF_PROG(filter_switch, struct hid_bpf_ctx *hid_ctx)
+ {
+ __u8 *data = hid_bpf_get_data(hid_ctx, 0 /* offset */, 192 /* size */);
+ __u8 *buf;
+
+ if (!data)
+ return 0; /* EPERM check */
+
+ if (current_value != data[152]) {
+ buf = bpf_ringbuf_reserve(&ringbuf, 1, 0);
+ if (!buf)
+ return 0;
+
+ *buf = data[152];
+
+ bpf_ringbuf_commit(buf, 0);
+
+ current_value = data[152];
+ }
+
+ return 0;
+ }
+
+To attach ``filter_switch``, userspace needs to call the ``attach_prog`` syscall
+program first::
+
+ static int attach_filter(struct hid *hid_skel, int hid_id)
+ {
+ int err, prog_fd;
+ int ret = -1;
+ struct attach_prog_args args = {
+ .hid = hid_id,
+ };
+ DECLARE_LIBBPF_OPTS(bpf_test_run_opts, tattrs,
+ .ctx_in = &args,
+ .ctx_size_in = sizeof(args),
+ );
+
+ args.prog_fd = bpf_program__fd(hid_skel->progs.filter_switch);
+
+ prog_fd = bpf_program__fd(hid_skel->progs.attach_prog);
+
+ err = bpf_prog_test_run_opts(prog_fd, &tattrs);
+ if (err)
+ return err;
+
+ return args.retval; /* the fd of the created bpf_link */
+ }
+
+Our userspace program can now listen to notifications on the ring buffer, and
+is awaken only when the value changes.
+
+When the userspace program doesn't need to listen to events anymore, it can just
+close the returned fd from :c:func:`attach_filter`, which will tell the kernel to
+detach the program from the HID device.
+
+Of course, in other use cases, the userspace program can also pin the fd to the
+BPF filesystem through a call to :c:func:`bpf_obj_pin`, as with any bpf_link.
+
+Controlling the device
+----------------------
+
+To be able to change the haptic feedback from the tablet, the userspace program
+needs to emit a feature report on the device itself.
+
+Instead of using hidraw for that, we can create a ``SEC("syscall")`` program
+that talks to the device::
+
+ /* some more HID-BPF kfunc API definitions */
+ extern struct hid_bpf_ctx *hid_bpf_allocate_context(unsigned int hid_id) __ksym;
+ extern void hid_bpf_release_context(struct hid_bpf_ctx *ctx) __ksym;
+ extern int hid_bpf_hw_request(struct hid_bpf_ctx *ctx,
+ __u8* data,
+ size_t len,
+ enum hid_report_type type,
+ enum hid_class_request reqtype) __ksym;
+
+
+ struct hid_send_haptics_args {
+ /* data needs to come at offset 0 so we can do a memcpy into it */
+ __u8 data[10];
+ unsigned int hid;
+ };
+
+ SEC("syscall")
+ int send_haptic(struct hid_send_haptics_args *args)
+ {
+ struct hid_bpf_ctx *ctx;
+ int ret = 0;
+
+ ctx = hid_bpf_allocate_context(args->hid);
+ if (!ctx)
+ return 0; /* EPERM check */
+
+ ret = hid_bpf_hw_request(ctx,
+ args->data,
+ 10,
+ HID_FEATURE_REPORT,
+ HID_REQ_SET_REPORT);
+
+ hid_bpf_release_context(ctx);
+
+ return ret;
+ }
+
+And then userspace needs to call that program directly::
+
+ static int set_haptic(struct hid *hid_skel, int hid_id, __u8 haptic_value)
+ {
+ int err, prog_fd;
+ int ret = -1;
+ struct hid_send_haptics_args args = {
+ .hid = hid_id,
+ };
+ DECLARE_LIBBPF_OPTS(bpf_test_run_opts, tattrs,
+ .ctx_in = &args,
+ .ctx_size_in = sizeof(args),
+ );
+
+ args.data[0] = 0x02; /* report ID of the feature on our device */
+ args.data[1] = haptic_value;
+
+ prog_fd = bpf_program__fd(hid_skel->progs.set_haptic);
+
+ err = bpf_prog_test_run_opts(prog_fd, &tattrs);
+ return err;
+ }
+
+Now our userspace program is aware of the haptic state and can control it. The
+program could make this state further available to other userspace programs
+(e.g. via a DBus API).
+
+The interesting bit here is that we did not created a new kernel API for this.
+Which means that if there is a bug in our implementation, we can change the
+interface with the kernel at-will, because the userspace application is
+responsible for its own usage.
diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
index caebc62..9b82c7f 100644
--- a/Documentation/hid/hiddev.rst
+++ b/Documentation/hid/hiddev.rst
@@ -8,7 +8,7 @@
In addition to the normal input type HID devices, USB also uses the
human interface device protocols for things that are not really human
interfaces, but have similar sorts of communication needs. The two big
-examples for this are power devices (especially uninterruptable power
+examples for this are power devices (especially uninterruptible power
supplies) and monitor control on higher end monitors.
To support these disparate requirements, the Linux USB system provides
diff --git a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst
index b717ee5..14d0767 100644
--- a/Documentation/hid/hidraw.rst
+++ b/Documentation/hid/hidraw.rst
@@ -163,7 +163,7 @@
Get an Output Report
This ioctl will request an output report from the device using the control
-endpoint. Typically, this is used to retrive the initial state of
+endpoint. Typically, this is used to retrieve the initial state of
an output report of a device, before an application updates it as necessary either
via a HIDIOCSOUTPUT request, or the regular device write() interface. The format
of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst
index e50f513..b2028f3 100644
--- a/Documentation/hid/index.rst
+++ b/Documentation/hid/index.rst
@@ -11,6 +11,7 @@
hidraw
hid-sensor
hid-transport
+ hid-bpf
uhid
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 7a85125..42dc77b 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -199,7 +199,7 @@
DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message
(that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK.
Additionally to DMA address communication, this sequence checks capabilities:
-if thw host doesn't support DMA, then it won't send DMA allocation, so FW can't
+if the host doesn't support DMA, then it won't send DMA allocation, so FW can't
send DMA; if FW doesn't support DMA then it won't respond with
DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers.
Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER,
@@ -344,8 +344,8 @@
To debug ISH, event tracing mechanism is used. To enable debug logs::
- echo 1 > /sys/kernel/debug/tracing/events/intel_ish/enable
- cat /sys/kernel/debug/tracing/trace
+ echo 1 > /sys/kernel/tracing/events/intel_ish/enable
+ cat /sys/kernel/tracing/trace
3.8 ISH IIO sysfs Example on Lenovo thinkpad Yoga 260
-----------------------------------------------------
diff --git a/Documentation/hwmon/aht10.rst b/Documentation/hwmon/aht10.rst
index 482262c..4e198c5 100644
--- a/Documentation/hwmon/aht10.rst
+++ b/Documentation/hwmon/aht10.rst
@@ -38,7 +38,7 @@
-------------
=============== ============================================
-temp1_input Measured temperature in millidegrees Celcius
+temp1_input Measured temperature in millidegrees Celsius
humidity1_input Measured humidity in %H
update_interval The minimum interval for polling the sensor,
in milliseconds. Writable. Must be at
diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst
index 637bdbc..7d0d015 100644
--- a/Documentation/hwmon/aquacomputer_d5next.rst
+++ b/Documentation/hwmon/aquacomputer_d5next.rst
@@ -5,12 +5,15 @@
Supported devices:
+* Aquacomputer Aquaero 5/6 fan controllers
* Aquacomputer D5 Next watercooling pump
* Aquacomputer Farbwerk RGB controller
* Aquacomputer Farbwerk 360 RGB controller
* Aquacomputer Octo fan controller
* Aquacomputer Quadro fan controller
* Aquacomputer High Flow Next sensor
+* Aquacomputer Aquastream Ultimate watercooling pump
+* Aquacomputer Poweradjust 3 fan controller
Author: Aleksa Savic
@@ -20,6 +23,10 @@
This driver exposes hardware sensors of listed Aquacomputer devices, which
communicate through proprietary USB HID protocols.
+The Aquaero devices expose eight physical, eight virtual and four calculated
+virtual temperature sensors, as well as two flow sensors. The fans expose their
+speed (in RPM), power, voltage and current.
+
For the D5 Next pump, available sensors are pump and fan speed, power, voltage
and current, as well as coolant temperature and eight virtual temp sensors. Also
available through debugfs are the serial number, firmware version and power-on
@@ -48,6 +55,12 @@
A temperature sensor can be connected to it, in which case it provides its reading
and an estimation of the dissipated/absorbed power in the liquid cooling loop.
+The Aquastream Ultimate pump exposes coolant temp and an external temp sensor, along
+with speed, power, voltage and current of both the pump and optionally connected fan.
+It also exposes pressure and flow speed readings.
+
+The Poweradjust 3 controller exposes a single external temperature sensor.
+
Depending on the device, not all sysfs and debugfs entries will be available.
Writing to virtual temperature sensors is not currently supported.
diff --git a/Documentation/hwmon/aspeed-pwm-tacho.rst b/Documentation/hwmon/aspeed-pwm-tacho.rst
index 6dcec84..f7bbe96 100644
--- a/Documentation/hwmon/aspeed-pwm-tacho.rst
+++ b/Documentation/hwmon/aspeed-pwm-tacho.rst
@@ -10,7 +10,7 @@
Description:
------------
This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
-controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller. The PWM controller supports up to 8 PWM outputs. The Fan tacho
controller supports up to 16 tachometer inputs.
The driver provides the following sensor accesses in sysfs:
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 02f4ad3..a4039f2 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -23,6 +23,7 @@
* ROG STRIX X570-I GAMING
* ROG STRIX Z690-A GAMING WIFI D4
* ROG ZENITH II EXTREME
+ * ROG ZENITH II EXTREME ALPHA
Authors:
- Eugene Shalygin <eugene.shalygin@gmail.com>
diff --git a/Documentation/hwmon/corsair-psu.rst b/Documentation/hwmon/corsair-psu.rst
index 6a03edb..c389bd2 100644
--- a/Documentation/hwmon/corsair-psu.rst
+++ b/Documentation/hwmon/corsair-psu.rst
@@ -40,7 +40,7 @@
interface of the HXi and RMi series.
These power supplies provide access to a micro-controller with 2 attached
temperature sensors, 1 fan rpm sensor, 4 sensors for volt levels, 4 sensors for
-power usage and 4 sensors for current levels and addtional non-sensor information
+power usage and 4 sensors for current levels and additional non-sensor information
like uptimes.
Sysfs entries
diff --git a/Documentation/hwmon/ftsteutates.rst b/Documentation/hwmon/ftsteutates.rst
index 58a2483..b3bfec3 100644
--- a/Documentation/hwmon/ftsteutates.rst
+++ b/Documentation/hwmon/ftsteutates.rst
@@ -22,6 +22,15 @@
8 fans. It also contains an integrated watchdog which is currently
implemented in this driver.
+The ``pwmX_auto_channels_temp`` attributes show which temperature sensor
+is currently driving which fan channel. This value might dynamically change
+during runtime depending on the temperature sensor selected by
+the fan control circuit.
+
+The 4 voltages require a board-specific multiplier, since the BMC can
+only measure voltages up to 3.3V and thus relies on voltage dividers.
+Consult your motherboard manual for details.
+
To clear a temperature or fan alarm, execute the following command with the
correct path to the alarm file::
diff --git a/Documentation/hwmon/gsc-hwmon.rst b/Documentation/hwmon/gsc-hwmon.rst
index ffac392..e9ab279 100644
--- a/Documentation/hwmon/gsc-hwmon.rst
+++ b/Documentation/hwmon/gsc-hwmon.rst
@@ -31,7 +31,7 @@
Temperatures are measured with 12-bit or 10-bit resolution and are scaled
either internally or by the driver depending on the GSC version and firmware.
-The values returned by the driver reflect millidegree Celcius:
+The values returned by the driver reflect millidegree Celsius:
tempX_input Measured temperature.
tempX_label Name of temperature input.
@@ -41,8 +41,8 @@
------------------
The GSC features 1 PWM output that operates in automatic mode where the
-PWM value will be scalled depending on 6 temperature boundaries.
-The tempeature boundaries are read-write and in millidegree Celcius and the
+PWM value will be scaled depending on 6 temperature boundaries.
+The tempeature boundaries are read-write and in millidegree Celsius and the
read-only PWM values range from 0 (off) to 255 (full speed).
Fan speed will be set to minimum (off) when the temperature sensor reads
less than pwm1_auto_point1_temp and maximum when the temperature sensor
diff --git a/Documentation/hwmon/gxp-fan-ctrl.rst b/Documentation/hwmon/gxp-fan-ctrl.rst
new file mode 100644
index 0000000..ae3397e
--- /dev/null
+++ b/Documentation/hwmon/gxp-fan-ctrl.rst
@@ -0,0 +1,28 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver gxp-fan-ctrl
+==========================
+
+Supported chips:
+
+ * HPE GXP SOC
+
+Author: Nick Hawkins <nick.hawkins@hpe.com>
+
+
+Description
+-----------
+
+gxp-fan-ctrl is a driver which provides fan control for the hpe gxp soc.
+The driver allows the gathering of fan status and the use of fan
+PWM control.
+
+
+Sysfs attributes
+----------------
+
+======================= ===========================================================
+pwm[0-7] Fan 0 to 7 respective PWM value (0-255)
+fan[0-7]_fault Fan 0 to 7 respective fault status: 1 fail, 0 ok
+fan[0-7]_enable Fan 0 to 7 respective enabled status: 1 enabled, 0 disabled
+======================= ===========================================================
diff --git a/Documentation/hwmon/hwmon-kernel-api.rst b/Documentation/hwmon/hwmon-kernel-api.rst
index f3276b3..5451a6d 100644
--- a/Documentation/hwmon/hwmon-kernel-api.rst
+++ b/Documentation/hwmon/hwmon-kernel-api.rst
@@ -57,7 +57,7 @@
hwmon_device_register_with_groups registers a hardware monitoring device.
The first parameter of this function is a pointer to the parent device.
The name parameter is a pointer to the hwmon device name. The registration
-function wil create a name sysfs attribute pointing to this name.
+function will create a name sysfs attribute pointing to this name.
The drvdata parameter is the pointer to the local driver data.
hwmon_device_register_with_groups will attach this pointer to the newly
allocated hwmon device. The pointer can be retrieved by the driver using
@@ -299,7 +299,7 @@
Return value:
The file mode for this attribute. Typically, this will be 0 (the
- attribute will not be created), S_IRUGO, or 'S_IRUGO | S_IWUSR'.
+ attribute will not be created), 0444, or 0644.
::
@@ -360,7 +360,7 @@
The header file linux/hwmon-sysfs.h provides a number of useful macros to
declare and use hardware monitoring sysfs attributes.
-In many cases, you can use the exsting define DEVICE_ATTR or its variants
+In many cases, you can use the existing define DEVICE_ATTR or its variants
DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an
attribute has no additional context. However, in many cases there will be
additional information such as a sensor index which will need to be passed
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fe2cc6b..f1fe75f 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -1,6 +1,8 @@
-=========================
-Linux Hardware Monitoring
-=========================
+.. SPDX-License-Identifier: GPL-2.0
+
+===================
+Hardware Monitoring
+===================
.. toctree::
:maxdepth: 1
@@ -73,6 +75,7 @@
g762
gsc-hwmon
gl518sm
+ gxp-fan-ctrl
hih6130
ibmaem
ibm-cffps
@@ -144,6 +147,7 @@
max6697
max8688
mc13783-adc
+ mc34vr500
mcp3021
menf21bmc
mlxreg-fan
diff --git a/Documentation/hwmon/it87.rst b/Documentation/hwmon/it87.rst
index 2d83f23..5cef4f2 100644
--- a/Documentation/hwmon/it87.rst
+++ b/Documentation/hwmon/it87.rst
@@ -145,6 +145,22 @@
Datasheet: Not publicly available
+ * IT8792E/IT8795E
+
+ Prefix: 'it8792'
+
+ Addresses scanned: from Super I/O config space (8 I/O ports)
+
+ Datasheet: Not publicly available
+
+ * IT87952E
+
+ Prefix: 'it87952'
+
+ Addresses scanned: from Super I/O config space (8 I/O ports)
+
+ Datasheet: Not publicly available
+
* SiS950 [clone of IT8705F]
Prefix: 'it87'
@@ -162,7 +178,7 @@
Module Parameters
-----------------
-* update_vbat: int
+* update_vbat bool
0 if vbat should report power on value, 1 if vbat should be updated after
each read. Default is 0. On some boards the battery voltage is provided
by either the battery or the onboard power supply. Only the first reading
@@ -171,11 +187,31 @@
the chip so can be read at any time. Excessive reading may decrease
battery life but no information is given in the datasheet.
-* fix_pwm_polarity int
+* fix_pwm_polarity bool
Force PWM polarity to active high (DANGEROUS). Some chips are
misconfigured by BIOS - PWM values would be inverted. This option tries
to fix this. Please contact your BIOS manufacturer and ask him for fix.
+* force_id short, short
+
+ Force multiple chip ID to specified value, separated by ','.
+ For example "force_id=0x8689,0x8633". A value of 0 is ignored
+ for that chip.
+ Note: A single force_id value (e.g. "force_id=0x8689") is used for
+ all chips, to only set the first chip use "force_id=0x8689,0".
+ Should only be used for testing.
+
+* ignore_resource_conflict bool
+
+ Similar to acpi_enforce_resources=lax, but only affects this driver.
+ ACPI resource conflicts are ignored if this parameter is provided and
+ set to 1.
+ Provided since there are reports that system-wide acpi_enfore_resources=lax
+ can result in boot failures on some systems.
+ Note: This is inherently risky since it means that both ACPI and this driver
+ may access the chip at the same time. This can result in race conditions and,
+ worst case, result in unexpected system reboots.
+
Hardware Interfaces
-------------------
@@ -193,8 +229,8 @@
This driver implements support for the IT8603E, IT8620E, IT8623E, IT8628E,
IT8705F, IT8712F, IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8732F,
-IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, IT8786E, IT8790E, and
-SiS950 chips.
+IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, IT8786E, IT8790E,
+IT8792E/IT8795E, IT87952E and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -238,7 +274,8 @@
The IT8620E and IT8628E are custom designs, hardware monitoring part is similar
to IT8728F. It only supports 16-bit fan mode. Both chips support up to 6 fans.
-The IT8790E supports up to 3 fans. 16-bit fan mode is always enabled.
+The IT8790E, IT8792E/IT8795E and IT87952E support up to 3 fans. 16-bit fan
+mode is always enabled.
The IT8732F supports a closed-loop mode for fan control, but this is not
currently implemented by the driver.
diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst
index b99a639..edf24e5 100644
--- a/Documentation/hwmon/ltc2978.rst
+++ b/Documentation/hwmon/ltc2978.rst
@@ -333,7 +333,7 @@
- On LTC3883, temp1 reports an external temperature,
and temp2 reports the chip temperature.
-temp[N]_min Mimimum temperature.
+temp[N]_min Minimum temperature.
LTC2972, LTC2974, LCT2977, LTM2980, LTC2978,
LTC2979, and LTM2987 only.
diff --git a/Documentation/hwmon/max16601.rst b/Documentation/hwmon/max16601.rst
index 6a4eef8..c8c63a0 100644
--- a/Documentation/hwmon/max16601.rst
+++ b/Documentation/hwmon/max16601.rst
@@ -13,6 +13,14 @@
Datasheet: Not published
+ * Maxim MAX16600
+
+ Prefix: 'max16600'
+
+ Addresses scanned: -
+
+ Datasheet: Not published
+
* Maxim MAX16601
Prefix: 'max16601'
@@ -36,7 +44,8 @@
-----------
This driver supports the MAX16508 VR13 Dual-Output Voltage Regulator
-as well as the MAX16601 VR13.HC Dual-Output Voltage Regulator chipsets.
+as well as the MAX16600, MAX16601, and MAX16602 VR13.HC Dual-Output
+Voltage Regulator chipsets.
The driver is a client driver to the core PMBus driver.
Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
diff --git a/Documentation/hwmon/max6697.rst b/Documentation/hwmon/max6697.rst
index ffc5a7d..90ca224 100644
--- a/Documentation/hwmon/max6697.rst
+++ b/Documentation/hwmon/max6697.rst
@@ -73,7 +73,7 @@
This driver implements support for several MAX6697 compatible temperature sensor
chips. The chips support one local temperature sensor plus four, six, or seven
remote temperature sensors. Remote temperature sensors are diode-connected
-thermal transitors, except for MAX6698 which supports three diode-connected
+thermal transistors, except for MAX6698 which supports three diode-connected
thermal transistors plus three thermistors in addition to the local temperature
sensor.
diff --git a/Documentation/hwmon/mc34vr500.rst b/Documentation/hwmon/mc34vr500.rst
new file mode 100644
index 0000000..f82d872
--- /dev/null
+++ b/Documentation/hwmon/mc34vr500.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver mc34vr500
+=======================
+
+Supported Chips:
+
+ * NXP MC34VR500
+
+ Prefix: 'mc34vr500'
+
+ Datasheet: https://www.nxp.com/docs/en/data-sheet/MC34VR500.pdf
+
+Author: Mario Kicherer <dev@kicherer.org>
+
+Description
+-----------
+
+This driver implements initial support for the NXP MC34VR500 PMIC. The MC34VR500
+monitors the temperature, input voltage and output currents and provides
+corresponding alarms. For the temperature, the chip can send interrupts if
+the temperature rises above one of the following values: 110°, 120°, 125° and
+130° Celsius. For the input voltage, an interrupt is sent when the voltage
+drops below 2.8V.
+
+Currently, this driver only implements the input voltage and temperature
+alarms. The interrupts are mapped as follows:
+
+<= 2.8V -> in0_min_alarm
+>110°c -> temp1_max_alarm
+>120°c -> temp1_crit_alarm
+>130°c -> temp1_emergency_alarm
diff --git a/Documentation/hwmon/menf21bmc.rst b/Documentation/hwmon/menf21bmc.rst
index 978691d..e7f3f67 100644
--- a/Documentation/hwmon/menf21bmc.rst
+++ b/Documentation/hwmon/menf21bmc.rst
@@ -7,7 +7,7 @@
Prefix: 'menf21bmc_hwmon'
- Adresses scanned: -
+ Addresses scanned: -
Author: Andreas Werner <andreas.werner@men.de>
diff --git a/Documentation/hwmon/oxp-sensors.rst b/Documentation/hwmon/oxp-sensors.rst
index 39c588e..566a8d5 100644
--- a/Documentation/hwmon/oxp-sensors.rst
+++ b/Documentation/hwmon/oxp-sensors.rst
@@ -3,18 +3,21 @@
Kernel driver oxp-sensors
=========================
-Author:
+Authors:
+ - Derek John Clark <derekjohn.clark@gmail.com>
- Joaquín Ignacio Aramendía <samsagax@gmail.com>
Description:
------------
-One X Player devices from One Netbook provide fan readings and fan control
-through its Embedded Controller.
+Handheld devices from One Netbook and Aya Neo provide fan readings and fan
+control through their embedded controllers.
-Currently only supports AMD boards from the One X Player and AOK ZOE lineup.
-Intel boards could be supported if we could figure out the EC registers and
-values to write to since the EC layout and model is different.
+Currently only supports AMD boards from One X Player, AOK ZOE, and some Aya
+Neo devices. One X Player Intel boards could be supported if we could figure
+out the EC registers and values to write to since the EC layout and model is
+different. Aya Neo devices preceding the AIR may not be supportable as the EC
+model is different and do not appear to have manual control capabilities.
Supported devices
-----------------
@@ -22,6 +25,8 @@
Currently the driver supports the following handhelds:
- AOK ZOE A1
+ - Aya Neo AIR
+ - Aya Neo AIR Pro
- OneXPlayer AMD
- OneXPlayer mini AMD
- OneXPlayer mini AMD PRO
diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst
index 84c5a4e..cff93ad 100644
--- a/Documentation/hwmon/pmbus-core.rst
+++ b/Documentation/hwmon/pmbus-core.rst
@@ -174,7 +174,7 @@
int (*read_word_data)(struct i2c_client *client, int page, int phase,
int reg);
-Read word from page <page>, phase <pase>, register <reg>. If the chip does not
+Read word from page <page>, phase <phase>, register <reg>. If the chip does not
support multiple phases, the phase parameter can be ignored. If the chip
supports multiple phases, a phase value of 0xff indicates all phases.
diff --git a/Documentation/hwmon/sht4x.rst b/Documentation/hwmon/sht4x.rst
index c318e558..daf21e7 100644
--- a/Documentation/hwmon/sht4x.rst
+++ b/Documentation/hwmon/sht4x.rst
@@ -37,7 +37,7 @@
-------------
=============== ============================================
-temp1_input Measured temperature in millidegrees Celcius
+temp1_input Measured temperature in millidegrees Celsius
humidity1_input Measured humidity in %H
update_interval The minimum interval for polling the sensor,
in milliseconds. Writable. Must be at least
diff --git a/Documentation/hwmon/smm665.rst b/Documentation/hwmon/smm665.rst
index a0e27f6..481e69d 100644
--- a/Documentation/hwmon/smm665.rst
+++ b/Documentation/hwmon/smm665.rst
@@ -180,7 +180,7 @@
in10_crit_alarm AIN2 critical alarm
temp1_input Chip temperature
-temp1_min Mimimum chip temperature
+temp1_min Minimum chip temperature
temp1_max Maximum chip temperature
temp1_crit Critical chip temperature
temp1_crit_alarm Temperature critical alarm
diff --git a/Documentation/hwmon/stpddc60.rst b/Documentation/hwmon/stpddc60.rst
index 7f7ce7f..0c31f78 100644
--- a/Documentation/hwmon/stpddc60.rst
+++ b/Documentation/hwmon/stpddc60.rst
@@ -39,7 +39,7 @@
in 50mV steps. This means that the absolute values of the limits will change
when the commanded output voltage changes. Also, care should be taken when
writing to those limits since in the worst case the commanded output voltage
-could change at the same time as the limit is written to, wich will lead to
+could change at the same time as the limit is written to, which will lead to
unpredictable results.
diff --git a/Documentation/hwmon/submitting-patches.rst b/Documentation/hwmon/submitting-patches.rst
index d953ee7..6482c4f 100644
--- a/Documentation/hwmon/submitting-patches.rst
+++ b/Documentation/hwmon/submitting-patches.rst
@@ -126,7 +126,7 @@
* Use devm_hwmon_device_register_with_info() or, if your driver needs a remove
function, hwmon_device_register_with_info() to register your driver with the
hwmon subsystem. Try using devm_add_action() instead of a remove function if
- possible. Do not use hwmon_device_register().
+ possible. Do not use any of the deprecated registration functions.
* Your driver should be buildable as module. If not, please be prepared to
explain why it has to be built into the kernel.
diff --git a/Documentation/hwmon/vexpress.rst b/Documentation/hwmon/vexpress.rst
index 8c861c8..7fc99f7 100644
--- a/Documentation/hwmon/vexpress.rst
+++ b/Documentation/hwmon/vexpress.rst
@@ -27,7 +27,7 @@
reference & prototyping system for ARM Ltd. processors. It can be set up
from a wide range of boards, each of them containing (apart of the main
chip/FPGA) a number of microcontrollers responsible for platform
-configuration and control. Theses microcontrollers can also monitor the
+configuration and control. These microcontrollers can also monitor the
board and its environment by a number of internal and external sensors,
providing information about power lines voltages and currents, board
temperature and power usage. Some of them also calculate consumed energy
diff --git a/Documentation/hwmon/via686a.rst b/Documentation/hwmon/via686a.rst
index 7ab9dde..8c52a92 100644
--- a/Documentation/hwmon/via686a.rst
+++ b/Documentation/hwmon/via686a.rst
@@ -58,7 +58,7 @@
Voltage sensors (also known as IN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum
-or maximum limit. Voltages are internally scalled, so each voltage channel
+or maximum limit. Voltages are internally scaled, so each voltage channel
has a different resolution and range.
If an alarm triggers, it will remain triggered until the hardware register
diff --git a/Documentation/i2c/gpio-fault-injection.rst b/Documentation/i2c/gpio-fault-injection.rst
index 9dca6ec..91d2388 100644
--- a/Documentation/i2c/gpio-fault-injection.rst
+++ b/Documentation/i2c/gpio-fault-injection.rst
@@ -93,7 +93,7 @@
------------------
This file is write only and you need to write the duration of the arbitration
-intereference (in µs, maximum is 100ms). The calling process will then sleep
+interference (in µs, maximum is 100ms). The calling process will then sleep
and wait for the next bus clock. The process is interruptible, though.
Arbitration lost is achieved by waiting for SCL going down by the master under
diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst
index 4942c4c..adc8745 100644
--- a/Documentation/i2c/smbus-protocol.rst
+++ b/Documentation/i2c/smbus-protocol.rst
@@ -238,7 +238,7 @@
* I2C bus drivers trigger SMBus Host Notify by a call to
i2c_handle_smbus_host_notify().
* I2C drivers for devices which can trigger SMBus Host Notify will have
- client->irq assigned to a Host Notify IRQ if noone else specified an other.
+ client->irq assigned to a Host Notify IRQ if no one else specified another.
There is currently no way to retrieve the data parameter from the client.
diff --git a/Documentation/index.rst b/Documentation/index.rst
index bf6aa68..76d1a3e 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -2,6 +2,7 @@
.. _linux_doc:
+==============================
The Linux Kernel documentation
==============================
@@ -13,7 +14,7 @@
you want to help out.
Working with the development community
---------------------------------------
+======================================
The essential guides for interacting with the kernel's development
community and getting your work upstream.
@@ -29,7 +30,7 @@
Internal API manuals
---------------------
+====================
Manuals for use by developers working to interface with the rest of the
kernel.
@@ -43,7 +44,7 @@
Locking in the kernel <locking/index>
Development tools and processes
--------------------------------
+===============================
Various other manuals with useful information for all kernel developers.
@@ -62,7 +63,7 @@
User-oriented documentation
----------------------------
+===========================
The following manuals are written for *users* of the kernel — those who are
trying to get it to work optimally on a given system and application
@@ -81,7 +82,7 @@
which are kept separately from the kernel's own documentation.
Firmware-related documentation
-------------------------------
+==============================
The following holds information on the kernel's expectations regarding the
platform firmwares.
@@ -93,7 +94,7 @@
Architecture-specific documentation
------------------------------------
+===================================
.. toctree::
:maxdepth: 2
@@ -102,7 +103,7 @@
Other documentation
--------------------
+===================
There are several unsorted documents that don't seem to fit on other parts
of the documentation body, or may require some adjustments and/or conversion
@@ -115,7 +116,7 @@
Translations
-------------
+============
.. toctree::
:maxdepth: 2
diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 9888f5c..35581cd 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -1,6 +1,6 @@
-=============================
-The Linux Input Documentation
-=============================
+===================
+Input Documentation
+===================
Contents:
diff --git a/Documentation/isdn/interface_capi.rst b/Documentation/isdn/interface_capi.rst
index fe24214..4d63b34 100644
--- a/Documentation/isdn/interface_capi.rst
+++ b/Documentation/isdn/interface_capi.rst
@@ -323,7 +323,7 @@
application up and down events.
In addition, every registered CAPI controller has an associated traceflag
-parameter controlling how CAPI messages sent from and to tha controller are
+parameter controlling how CAPI messages sent from and to the controller are
logged. The traceflag parameter is initialized with the value of the
showcapimsgs parameter when the controller is registered, but can later be
changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE.
diff --git a/Documentation/isdn/m_isdn.rst b/Documentation/isdn/m_isdn.rst
index 9957de3..5847a16 100644
--- a/Documentation/isdn/m_isdn.rst
+++ b/Documentation/isdn/m_isdn.rst
@@ -3,7 +3,7 @@
============
mISDN is a new modular ISDN driver, in the long term it should replace
-the old I4L driver architecture for passiv ISDN cards.
+the old I4L driver architecture for passive ISDN cards.
It was designed to allow a broad range of applications and interfaces
but only have the basic function in kernel, the interface to the user
space is based on sockets with a own address family AF_ISDN.
diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst
index 08f575e..5202186 100644
--- a/Documentation/kbuild/kbuild.rst
+++ b/Documentation/kbuild/kbuild.rst
@@ -278,6 +278,13 @@
$ make ALLSOURCE_ARCHS=all tags
+IGNORE_DIRS
+-----------
+For tags/TAGS/cscope targets, you can choose which directories won't
+be included in the databases, separated by blank space. E.g.::
+
+ $ make IGNORE_DIRS="drivers/gpu/drm/radeon tools" cscope
+
KBUILD_BUILD_TIMESTAMP
----------------------
Setting this to a date string overrides the timestamp used in the
diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index 6b2bac8..c3851fe 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -15,12 +15,15 @@
<https://clang.llvm.org/>`_ and `LLVM <https://llvm.org/>`_ utilities to be
used as viable substitutes. Distributions such as `Android
<https://www.android.com/>`_, `ChromeOS
-<https://www.chromium.org/chromium-os>`_, and `OpenMandriva
-<https://www.openmandriva.org/>`_ use Clang built kernels. `LLVM is a
-collection of toolchain components implemented in terms of C++ objects
-<https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM that
-supports C and the GNU C extensions required by the kernel, and is pronounced
-"klang," not "see-lang."
+<https://www.chromium.org/chromium-os>`_, `OpenMandriva
+<https://www.openmandriva.org/>`_, and `Chimera Linux
+<https://chimera-linux.org/>`_ use Clang built kernels. Google's and Meta's
+datacenter fleets also run kernels built with Clang.
+
+`LLVM is a collection of toolchain components implemented in terms of C++
+objects <https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM
+that supports C and the GNU C extensions required by the kernel, and is
+pronounced "klang," not "see-lang."
Clang
-----
@@ -168,6 +171,10 @@
Getting LLVM
-------------
+We provide prebuilt stable versions of LLVM on `kernel.org <https://kernel.org/pub/tools/llvm/>`_.
+Below are links that may be useful for building LLVM from source or procuring
+it through a distribution's package manager.
+
- https://releases.llvm.org/download.html
- https://github.com/llvm/llvm-project
- https://llvm.org/docs/GettingStarted.html
diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
index 38bc74e..e67eb26 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -4,69 +4,8 @@
This document describes the Linux kernel Makefiles.
-.. Table of Contents
-
- === 1 Overview
- === 2 Who does what
- === 3 The kbuild files
- --- 3.1 Goal definitions
- --- 3.2 Built-in object goals - obj-y
- --- 3.3 Loadable module goals - obj-m
- --- 3.4 <deleted>
- --- 3.5 Library file goals - lib-y
- --- 3.6 Descending down in directories
- --- 3.7 Non-builtin vmlinux targets - extra-y
- --- 3.8 Always built goals - always-y
- --- 3.9 Compilation flags
- --- 3.10 Dependency tracking
- --- 3.11 Custom Rules
- --- 3.12 Command change detection
- --- 3.13 $(CC) support functions
- --- 3.14 $(LD) support functions
- --- 3.15 Script Invocation
-
- === 4 Host Program support
- --- 4.1 Simple Host Program
- --- 4.2 Composite Host Programs
- --- 4.3 Using C++ for host programs
- --- 4.4 Using Rust for host programs
- --- 4.5 Controlling compiler options for host programs
- --- 4.6 When host programs are actually built
-
- === 5 Userspace Program support
- --- 5.1 Simple Userspace Program
- --- 5.2 Composite Userspace Programs
- --- 5.3 Controlling compiler options for userspace programs
- --- 5.4 When userspace programs are actually built
-
- === 6 Kbuild clean infrastructure
-
- === 7 Architecture Makefiles
- --- 7.1 Set variables to tweak the build to the architecture
- --- 7.2 Add prerequisites to archheaders
- --- 7.3 Add prerequisites to archprepare
- --- 7.4 List directories to visit when descending
- --- 7.5 Architecture-specific boot images
- --- 7.6 Building non-kbuild targets
- --- 7.7 Commands useful for building a boot image
- --- 7.8 <deleted>
- --- 7.9 Preprocessing linker scripts
- --- 7.10 Generic header files
- --- 7.11 Post-link pass
-
- === 8 Kbuild syntax for exported headers
- --- 8.1 no-export-headers
- --- 8.2 generic-y
- --- 8.3 generated-y
- --- 8.4 mandatory-y
-
- === 9 Kbuild Variables
- === 10 Makefile language
- === 11 Credits
- === 12 TODO
-
-1 Overview
-==========
+Overview
+========
The Makefiles have five parts::
@@ -83,6 +22,7 @@
(the resident kernel image) and modules (any module files).
It builds these goals by recursively descending into the subdirectories of
the kernel source tree.
+
The list of subdirectories which are visited depends upon the kernel
configuration. The top Makefile textually includes an arch Makefile
with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies
@@ -96,14 +36,13 @@
scripts/Makefile.* contains all the definitions/rules etc. that
are used to build the kernel based on the kbuild makefiles.
-
-2 Who does what
-===============
+Who does what
+=============
People have four different relationships with the kernel Makefiles.
*Users* are people who build kernels. These people type commands such as
-"make menuconfig" or "make". They usually do not read or edit
+``make menuconfig`` or ``make``. They usually do not read or edit
any kernel Makefiles (or any other source files).
*Normal developers* are people who work on features such as device
@@ -123,1402 +62,1429 @@
This document is aimed towards normal developers and arch developers.
-3 The kbuild files
-==================
+The kbuild files
+================
Most Makefiles within the kernel are kbuild Makefiles that use the
kbuild infrastructure. This chapter introduces the syntax used in the
kbuild makefiles.
-The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can
-be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild'
+
+The preferred name for the kbuild files are ``Makefile`` but ``Kbuild`` can
+be used and if both a ``Makefile`` and a ``Kbuild`` file exists, then the ``Kbuild``
file will be used.
-Section 3.1 "Goal definitions" is a quick intro; further chapters provide
+Section `Goal definitions`_ is a quick intro; further chapters provide
more details, with real examples.
-3.1 Goal definitions
---------------------
+Goal definitions
+----------------
- Goal definitions are the main part (heart) of the kbuild Makefile.
- These lines define the files to be built, any special compilation
- options, and any subdirectories to be entered recursively.
+Goal definitions are the main part (heart) of the kbuild Makefile.
+These lines define the files to be built, any special compilation
+options, and any subdirectories to be entered recursively.
- The most simple kbuild makefile contains one line:
+The most simple kbuild makefile contains one line:
- Example::
+Example::
- obj-y += foo.o
+ obj-y += foo.o
- This tells kbuild that there is one object in that directory, named
- foo.o. foo.o will be built from foo.c or foo.S.
+This tells kbuild that there is one object in that directory, named
+foo.o. foo.o will be built from foo.c or foo.S.
- If foo.o shall be built as a module, the variable obj-m is used.
- Therefore the following pattern is often used:
+If foo.o shall be built as a module, the variable obj-m is used.
+Therefore the following pattern is often used:
- Example::
+Example::
- obj-$(CONFIG_FOO) += foo.o
+ obj-$(CONFIG_FOO) += foo.o
- $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).
- If CONFIG_FOO is neither y nor m, then the file will not be compiled
- nor linked.
+$(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).
+If CONFIG_FOO is neither y nor m, then the file will not be compiled
+nor linked.
-3.2 Built-in object goals - obj-y
----------------------------------
-
- The kbuild Makefile specifies object files for vmlinux
- in the $(obj-y) lists. These lists depend on the kernel
- configuration.
-
- Kbuild compiles all the $(obj-y) files. It then calls
- "$(AR) rcSTP" to merge these files into one built-in.a file.
- This is a thin archive without a symbol table. It will be later
- linked into vmlinux by scripts/link-vmlinux.sh
-
- The order of files in $(obj-y) is significant. Duplicates in
- the lists are allowed: the first instance will be linked into
- built-in.a and succeeding instances will be ignored.
-
- Link order is significant, because certain functions
- (module_init() / __initcall) will be called during boot in the
- order they appear. So keep in mind that changing the link
- order may e.g. change the order in which your SCSI
- controllers are detected, and thus your disks are renumbered.
-
- Example::
-
- #drivers/isdn/i4l/Makefile
- # Makefile for the kernel ISDN subsystem and device drivers.
- # Each configuration option enables a list of files.
- obj-$(CONFIG_ISDN_I4L) += isdn.o
- obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
-
-3.3 Loadable module goals - obj-m
----------------------------------
-
- $(obj-m) specifies object files which are built as loadable
- kernel modules.
-
- A module may be built from one source file or several source
- files. In the case of one source file, the kbuild makefile
- simply adds the file to $(obj-m).
-
- Example::
-
- #drivers/isdn/i4l/Makefile
- obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
-
- Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
-
- If a kernel module is built from several source files, you specify
- that you want to build a module in the same way as above; however,
- kbuild needs to know which object files you want to build your
- module from, so you have to tell it by setting a $(<module_name>-y)
- variable.
-
- Example::
-
- #drivers/isdn/i4l/Makefile
- obj-$(CONFIG_ISDN_I4L) += isdn.o
- isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
-
- In this example, the module name will be isdn.o. Kbuild will
- compile the objects listed in $(isdn-y) and then run
- "$(LD) -r" on the list of these files to generate isdn.o.
-
- Due to kbuild recognizing $(<module_name>-y) for composite objects,
- you can use the value of a `CONFIG_` symbol to optionally include an
- object file as part of a composite object.
-
- Example::
-
- #fs/ext2/Makefile
- obj-$(CONFIG_EXT2_FS) += ext2.o
- ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
- namei.o super.o symlink.o
- ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
- xattr_trusted.o
-
- In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
- part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
- evaluates to 'y'.
-
- Note: Of course, when you are building objects into the kernel,
- the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
- kbuild will build an ext2.o file for you out of the individual
- parts and then link this into built-in.a, as you would expect.
-
-3.5 Library file goals - lib-y
-------------------------------
-
- Objects listed with obj-* are used for modules, or
- combined in a built-in.a for that specific directory.
- There is also the possibility to list objects that will
- be included in a library, lib.a.
- All objects listed with lib-y are combined in a single
- library for that directory.
- Objects that are listed in obj-y and additionally listed in
- lib-y will not be included in the library, since they will
- be accessible anyway.
- For consistency, objects listed in lib-m will be included in lib.a.
-
- Note that the same kbuild makefile may list files to be built-in
- and to be part of a library. Therefore the same directory
- may contain both a built-in.a and a lib.a file.
-
- Example::
-
- #arch/x86/lib/Makefile
- lib-y := delay.o
-
- This will create a library lib.a based on delay.o. For kbuild to
- actually recognize that there is a lib.a being built, the directory
- shall be listed in libs-y.
-
- See also "7.4 List directories to visit when descending".
-
- Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
-
-3.6 Descending down in directories
-----------------------------------
-
- A Makefile is only responsible for building objects in its own
- directory. Files in subdirectories should be taken care of by
- Makefiles in these subdirs. The build system will automatically
- invoke make recursively in subdirectories, provided you let it know of
- them.
-
- To do so, obj-y and obj-m are used.
- ext2 lives in a separate directory, and the Makefile present in fs/
- tells kbuild to descend down using the following assignment.
-
- Example::
-
- #fs/Makefile
- obj-$(CONFIG_EXT2_FS) += ext2/
-
- If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular)
- the corresponding obj- variable will be set, and kbuild will descend
- down in the ext2 directory.
-
- Kbuild uses this information not only to decide that it needs to visit
- the directory, but also to decide whether or not to link objects from
- the directory into vmlinux.
-
- When Kbuild descends into the directory with 'y', all built-in objects
- from that directory are combined into the built-in.a, which will be
- eventually linked into vmlinux.
-
- When Kbuild descends into the directory with 'm', in contrast, nothing
- from that directory will be linked into vmlinux. If the Makefile in
- that directory specifies obj-y, those objects will be left orphan.
- It is very likely a bug of the Makefile or of dependencies in Kconfig.
-
- Kbuild also supports dedicated syntax, subdir-y and subdir-m, for
- descending into subdirectories. It is a good fit when you know they
- do not contain kernel-space objects at all. A typical usage is to let
- Kbuild descend into subdirectories to build tools.
-
- Examples::
-
- # scripts/Makefile
- subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
- subdir-$(CONFIG_MODVERSIONS) += genksyms
- subdir-$(CONFIG_SECURITY_SELINUX) += selinux
-
- Unlike obj-y/m, subdir-y/m does not need the trailing slash since this
- syntax is always used for directories.
-
- It is good practice to use a `CONFIG_` variable when assigning directory
- names. This allows kbuild to totally skip the directory if the
- corresponding `CONFIG_` option is neither 'y' nor 'm'.
-
-3.7 Non-builtin vmlinux targets - extra-y
------------------------------------------
-
- extra-y specifies targets which are needed for building vmlinux,
- but not combined into built-in.a.
-
- Examples are:
-
- 1) vmlinux linker script
-
- The linker script for vmlinux is located at
- arch/$(SRCARCH)/kernel/vmlinux.lds
-
- Example::
-
- # arch/x86/kernel/Makefile
- extra-y += vmlinux.lds
-
- $(extra-y) should only contain targets needed for vmlinux.
-
- Kbuild skips extra-y when vmlinux is apparently not a final goal.
- (e.g. 'make modules', or building external modules)
-
- If you intend to build targets unconditionally, always-y (explained
- in the next section) is the correct syntax to use.
-
-3.8 Always built goals - always-y
----------------------------------
-
- always-y specifies targets which are literally always built when
- Kbuild visits the Makefile.
-
- Example::
- # ./Kbuild
- offsets-file := include/generated/asm-offsets.h
- always-y += $(offsets-file)
-
-3.9 Compilation flags
----------------------
-
- ccflags-y, asflags-y and ldflags-y
- These three flags apply only to the kbuild makefile in which they
- are assigned. They are used for all the normal cc, as and ld
- invocations happening during a recursive build.
- Note: Flags with the same behaviour were previously named:
- EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
- They are still supported but their usage is deprecated.
-
- ccflags-y specifies options for compiling with $(CC).
-
- Example::
-
- # drivers/acpi/acpica/Makefile
- ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
- ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
-
- This variable is necessary because the top Makefile owns the
- variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
- entire tree.
-
- asflags-y specifies assembler options.
-
- Example::
-
- #arch/sparc/kernel/Makefile
- asflags-y := -ansi
-
- ldflags-y specifies options for linking with $(LD).
-
- Example::
-
- #arch/cris/boot/compressed/Makefile
- ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
-
- subdir-ccflags-y, subdir-asflags-y
- The two flags listed above are similar to ccflags-y and asflags-y.
- The difference is that the subdir- variants have effect for the kbuild
- file where they are present and all subdirectories.
- Options specified using subdir-* are added to the commandline before
- the options specified using the non-subdir variants.
-
- Example::
-
- subdir-ccflags-y := -Werror
-
- ccflags-remove-y, asflags-remove-y
- These flags are used to remove particular flags for the compiler,
- assembler invocations.
-
- Example::
-
- ccflags-remove-$(CONFIG_MCOUNT) += -pg
-
- CFLAGS_$@, AFLAGS_$@
- CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
- kbuild makefile.
-
- $(CFLAGS_$@) specifies per-file options for $(CC). The $@
- part has a literal value which specifies the file that it is for.
-
- CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@
- can re-add compiler flags that were removed by ccflags-remove-y.
-
- Example::
-
- # drivers/scsi/Makefile
- CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
-
- This line specify compilation flags for aha152x.o.
-
- $(AFLAGS_$@) is a similar feature for source files in assembly
- languages.
-
- AFLAGS_$@ has the higher priority than asflags-remove-y; AFLAGS_$@
- can re-add assembler flags that were removed by asflags-remove-y.
-
- Example::
-
- # arch/arm/kernel/Makefile
- AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
- AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
- AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
-
-
-3.10 Dependency tracking
-------------------------
-
- Kbuild tracks dependencies on the following:
-
- 1) All prerequisite files (both `*.c` and `*.h`)
- 2) `CONFIG_` options used in all prerequisite files
- 3) Command-line used to compile target
-
- Thus, if you change an option to $(CC) all affected files will
- be re-compiled.
-
-3.11 Custom Rules
------------------
-
- Custom rules are used when the kbuild infrastructure does
- not provide the required support. A typical example is
- header files generated during the build process.
- Another example are the architecture-specific Makefiles which
- need custom rules to prepare boot images etc.
-
- Custom rules are written as normal Make rules.
- Kbuild is not executing in the directory where the Makefile is
- located, so all custom rules shall use a relative
- path to prerequisite files and target files.
-
- Two variables are used when defining custom rules:
-
- $(src)
- $(src) is a relative path which points to the directory
- where the Makefile is located. Always use $(src) when
- referring to files located in the src tree.
-
- $(obj)
- $(obj) is a relative path which points to the directory
- where the target is saved. Always use $(obj) when
- referring to generated files.
-
- Example::
-
- #drivers/scsi/Makefile
- $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
- $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
-
- This is a custom rule, following the normal syntax
- required by make.
-
- The target file depends on two prerequisite files. References
- to the target file are prefixed with $(obj), references
- to prerequisites are referenced with $(src) (because they are not
- generated files).
-
- $(kecho)
- echoing information to user in a rule is often a good practice
- but when execution "make -s" one does not expect to see any output
- except for warnings/errors.
- To support this kbuild defines $(kecho) which will echo out the
- text following $(kecho) to stdout except if "make -s" is used.
-
- Example::
-
- # arch/arm/Makefile
- $(BOOT_TARGETS): vmlinux
- $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
- @$(kecho) ' Kernel: $(boot)/$@ is ready'
-
- When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
- of a command is normally displayed.
- To enable this behaviour for custom commands kbuild requires
- two variables to be set::
-
- quiet_cmd_<command> - what shall be echoed
- cmd_<command> - the command to execute
-
- Example::
-
- # lib/Makefile
- quiet_cmd_crc32 = GEN $@
- cmd_crc32 = $< > $@
-
- $(obj)/crc32table.h: $(obj)/gen_crc32table
- $(call cmd,crc32)
-
- When updating the $(obj)/crc32table.h target, the line:
-
- GEN lib/crc32table.h
-
- will be displayed with "make KBUILD_VERBOSE=0".
-
-3.12 Command change detection
+Built-in object goals - obj-y
-----------------------------
- When the rule is evaluated, timestamps are compared between the target
- and its prerequisite files. GNU Make updates the target when any of the
- prerequisites is newer than that.
+The kbuild Makefile specifies object files for vmlinux
+in the $(obj-y) lists. These lists depend on the kernel
+configuration.
- The target should be rebuilt also when the command line has changed
- since the last invocation. This is not supported by Make itself, so
- Kbuild achieves this by a kind of meta-programming.
+Kbuild compiles all the $(obj-y) files. It then calls
+``$(AR) rcSTP`` to merge these files into one built-in.a file.
+This is a thin archive without a symbol table. It will be later
+linked into vmlinux by scripts/link-vmlinux.sh
- if_changed is the macro used for this purpose, in the following form::
+The order of files in $(obj-y) is significant. Duplicates in
+the lists are allowed: the first instance will be linked into
+built-in.a and succeeding instances will be ignored.
- quiet_cmd_<command> = ...
- cmd_<command> = ...
+Link order is significant, because certain functions
+(module_init() / __initcall) will be called during boot in the
+order they appear. So keep in mind that changing the link
+order may e.g. change the order in which your SCSI
+controllers are detected, and thus your disks are renumbered.
- <target>: <source(s)> FORCE
- $(call if_changed,<command>)
+Example::
- Any target that utilizes if_changed must be listed in $(targets),
- otherwise the command line check will fail, and the target will
- always be built.
+ #drivers/isdn/i4l/Makefile
+ # Makefile for the kernel ISDN subsystem and device drivers.
+ # Each configuration option enables a list of files.
+ obj-$(CONFIG_ISDN_I4L) += isdn.o
+ obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
- If the target is already listed in the recognized syntax such as
- obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild
- automatically adds it to $(targets). Otherwise, the target must be
- explicitly added to $(targets).
+Loadable module goals - obj-m
+-----------------------------
- Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
- used in conjunction with custom rules as defined in "3.11 Custom Rules".
+$(obj-m) specifies object files which are built as loadable
+kernel modules.
- Note: It is a typical mistake to forget the FORCE prerequisite.
- Another common pitfall is that whitespace is sometimes significant; for
- instance, the below will fail (note the extra space after the comma)::
+A module may be built from one source file or several source
+files. In the case of one source file, the kbuild makefile
+simply adds the file to $(obj-m).
- target: source(s) FORCE
+Example::
- **WRONG!** $(call if_changed, objcopy)
+ #drivers/isdn/i4l/Makefile
+ obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
- Note:
- if_changed should not be used more than once per target.
- It stores the executed command in a corresponding .cmd
- file and multiple calls would result in overwrites and
- unwanted results when the target is up to date and only the
- tests on changed commands trigger execution of commands.
+Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to "m"
-3.13 $(CC) support functions
-----------------------------
+If a kernel module is built from several source files, you specify
+that you want to build a module in the same way as above; however,
+kbuild needs to know which object files you want to build your
+module from, so you have to tell it by setting a $(<module_name>-y)
+variable.
- The kernel may be built with several different versions of
- $(CC), each supporting a unique set of features and options.
- kbuild provides basic support to check for valid options for $(CC).
- $(CC) is usually the gcc compiler, but other alternatives are
- available.
+Example::
- as-option
- as-option is used to check if $(CC) -- when used to compile
- assembler (`*.S`) files -- supports the given option. An optional
- second option may be specified if the first option is not supported.
+ #drivers/isdn/i4l/Makefile
+ obj-$(CONFIG_ISDN_I4L) += isdn.o
+ isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
- Example::
+In this example, the module name will be isdn.o. Kbuild will
+compile the objects listed in $(isdn-y) and then run
+``$(LD) -r`` on the list of these files to generate isdn.o.
- #arch/sh/Makefile
- cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
+Due to kbuild recognizing $(<module_name>-y) for composite objects,
+you can use the value of a ``CONFIG_`` symbol to optionally include an
+object file as part of a composite object.
- In the above example, cflags-y will be assigned the option
- -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
- The second argument is optional, and if supplied will be used
- if first argument is not supported.
+Example::
- as-instr
- as-instr checks if the assembler reports a specific instruction
- and then outputs either option1 or option2
- C escapes are supported in the test instruction
- Note: as-instr-option uses KBUILD_AFLAGS for assembler options
+ #fs/ext2/Makefile
+ obj-$(CONFIG_EXT2_FS) += ext2.o
+ ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
+ namei.o super.o symlink.o
+ ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
+ xattr_trusted.o
- cc-option
- cc-option is used to check if $(CC) supports a given option, and if
- not supported to use an optional second option.
+In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
+part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
+evaluates to "y".
- Example::
+Note: Of course, when you are building objects into the kernel,
+the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
+kbuild will build an ext2.o file for you out of the individual
+parts and then link this into built-in.a, as you would expect.
- #arch/x86/Makefile
- cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
+Library file goals - lib-y
+--------------------------
- In the above example, cflags-y will be assigned the option
- -march=pentium-mmx if supported by $(CC), otherwise -march=i586.
- The second argument to cc-option is optional, and if omitted,
- cflags-y will be assigned no value if first option is not supported.
- Note: cc-option uses KBUILD_CFLAGS for $(CC) options
+Objects listed with obj-* are used for modules, or
+combined in a built-in.a for that specific directory.
+There is also the possibility to list objects that will
+be included in a library, lib.a.
+All objects listed with lib-y are combined in a single
+library for that directory.
+Objects that are listed in obj-y and additionally listed in
+lib-y will not be included in the library, since they will
+be accessible anyway.
+For consistency, objects listed in lib-m will be included in lib.a.
- cc-option-yn
- cc-option-yn is used to check if gcc supports a given option
- and return 'y' if supported, otherwise 'n'.
+Note that the same kbuild makefile may list files to be built-in
+and to be part of a library. Therefore the same directory
+may contain both a built-in.a and a lib.a file.
- Example::
+Example::
- #arch/ppc/Makefile
- biarch := $(call cc-option-yn, -m32)
- aflags-$(biarch) += -a32
- cflags-$(biarch) += -m32
+ #arch/x86/lib/Makefile
+ lib-y := delay.o
- In the above example, $(biarch) is set to y if $(CC) supports the -m32
- option. When $(biarch) equals 'y', the expanded variables $(aflags-y)
- and $(cflags-y) will be assigned the values -a32 and -m32,
- respectively.
- Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
+This will create a library lib.a based on delay.o. For kbuild to
+actually recognize that there is a lib.a being built, the directory
+shall be listed in libs-y.
- cc-disable-warning
- cc-disable-warning checks if gcc supports a given warning and returns
- the commandline switch to disable it. This special function is needed,
- because gcc 4.4 and later accept any unknown -Wno-* option and only
- warn about it if there is another warning in the source file.
+See also `List directories to visit when descending`_.
- Example::
+Use of lib-y is normally restricted to ``lib/`` and ``arch/*/lib``.
- KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+Descending down in directories
+------------------------------
- In the above example, -Wno-unused-but-set-variable will be added to
- KBUILD_CFLAGS only if gcc really accepts it.
+A Makefile is only responsible for building objects in its own
+directory. Files in subdirectories should be taken care of by
+Makefiles in these subdirs. The build system will automatically
+invoke make recursively in subdirectories, provided you let it know of
+them.
- gcc-min-version
- gcc-min-version tests if the value of $(CONFIG_GCC_VERSION) is greater than
- or equal to the provided value and evaluates to y if so.
+To do so, obj-y and obj-m are used.
+ext2 lives in a separate directory, and the Makefile present in fs/
+tells kbuild to descend down using the following assignment.
- Example::
+Example::
- cflags-$(call gcc-min-version, 70100) := -foo
+ #fs/Makefile
+ obj-$(CONFIG_EXT2_FS) += ext2/
- In this example, cflags-y will be assigned the value -foo if $(CC) is gcc and
- $(CONFIG_GCC_VERSION) is >= 7.1.
+If CONFIG_EXT2_FS is set to either "y" (built-in) or "m" (modular)
+the corresponding obj- variable will be set, and kbuild will descend
+down in the ext2 directory.
- clang-min-version
- clang-min-version tests if the value of $(CONFIG_CLANG_VERSION) is greater
- than or equal to the provided value and evaluates to y if so.
+Kbuild uses this information not only to decide that it needs to visit
+the directory, but also to decide whether or not to link objects from
+the directory into vmlinux.
- Example::
+When Kbuild descends into the directory with "y", all built-in objects
+from that directory are combined into the built-in.a, which will be
+eventually linked into vmlinux.
- cflags-$(call clang-min-version, 110000) := -foo
+When Kbuild descends into the directory with "m", in contrast, nothing
+from that directory will be linked into vmlinux. If the Makefile in
+that directory specifies obj-y, those objects will be left orphan.
+It is very likely a bug of the Makefile or of dependencies in Kconfig.
- In this example, cflags-y will be assigned the value -foo if $(CC) is clang
- and $(CONFIG_CLANG_VERSION) is >= 11.0.0.
+Kbuild also supports dedicated syntax, subdir-y and subdir-m, for
+descending into subdirectories. It is a good fit when you know they
+do not contain kernel-space objects at all. A typical usage is to let
+Kbuild descend into subdirectories to build tools.
- cc-cross-prefix
- cc-cross-prefix is used to check if there exists a $(CC) in path with
- one of the listed prefixes. The first prefix where there exist a
- prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found
- then nothing is returned.
- Additional prefixes are separated by a single space in the
- call of cc-cross-prefix.
- This functionality is useful for architecture Makefiles that try
- to set CROSS_COMPILE to well-known values but may have several
- values to select between.
- It is recommended only to try to set CROSS_COMPILE if it is a cross
- build (host arch is different from target arch). And if CROSS_COMPILE
- is already set then leave it with the old value.
+Examples::
- Example::
+ # scripts/Makefile
+ subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
+ subdir-$(CONFIG_MODVERSIONS) += genksyms
+ subdir-$(CONFIG_SECURITY_SELINUX) += selinux
- #arch/m68k/Makefile
- ifneq ($(SUBARCH),$(ARCH))
- ifeq ($(CROSS_COMPILE),)
- CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
- endif
- endif
+Unlike obj-y/m, subdir-y/m does not need the trailing slash since this
+syntax is always used for directories.
-3.14 $(LD) support functions
-----------------------------
+It is good practice to use a ``CONFIG_`` variable when assigning directory
+names. This allows kbuild to totally skip the directory if the
+corresponding ``CONFIG_`` option is neither "y" nor "m".
- ld-option
- ld-option is used to check if $(LD) supports the supplied option.
- ld-option takes two options as arguments.
- The second argument is an optional option that can be used if the
- first option is not supported by $(LD).
+Non-builtin vmlinux targets - extra-y
+-------------------------------------
- Example::
+extra-y specifies targets which are needed for building vmlinux,
+but not combined into built-in.a.
- #Makefile
- LDFLAGS_vmlinux += $(call ld-option, -X)
+Examples are:
-3.15 Script invocation
-----------------------
+1) vmlinux linker script
- Make rules may invoke scripts to build the kernel. The rules shall
- always provide the appropriate interpreter to execute the script. They
- shall not rely on the execute bits being set, and shall not invoke the
- script directly. For the convenience of manual script invocation, such
- as invoking ./scripts/checkpatch.pl, it is recommended to set execute
- bits on the scripts nonetheless.
+ The linker script for vmlinux is located at
+ arch/$(SRCARCH)/kernel/vmlinux.lds
- Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL),
- and $(PYTHON3) to refer to interpreters for the respective
- scripts.
+Example::
- Example::
+ # arch/x86/kernel/Makefile
+ extra-y += vmlinux.lds
- #Makefile
- cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
- $(KERNELRELEASE)
+$(extra-y) should only contain targets needed for vmlinux.
-4 Host Program support
-======================
+Kbuild skips extra-y when vmlinux is apparently not a final goal.
+(e.g. ``make modules``, or building external modules)
+
+If you intend to build targets unconditionally, always-y (explained
+in the next section) is the correct syntax to use.
+
+Always built goals - always-y
+-----------------------------
+
+always-y specifies targets which are literally always built when
+Kbuild visits the Makefile.
+
+Example::
+
+ # ./Kbuild
+ offsets-file := include/generated/asm-offsets.h
+ always-y += $(offsets-file)
+
+Compilation flags
+-----------------
+
+ccflags-y, asflags-y and ldflags-y
+ These three flags apply only to the kbuild makefile in which they
+ are assigned. They are used for all the normal cc, as and ld
+ invocations happening during a recursive build.
+ Note: Flags with the same behaviour were previously named:
+ EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
+ They are still supported but their usage is deprecated.
+
+ ccflags-y specifies options for compiling with $(CC).
+
+ Example::
+
+ # drivers/acpi/acpica/Makefile
+ ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
+ ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
+
+ This variable is necessary because the top Makefile owns the
+ variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
+ entire tree.
+
+ asflags-y specifies assembler options.
+
+ Example::
+
+ #arch/sparc/kernel/Makefile
+ asflags-y := -ansi
+
+ ldflags-y specifies options for linking with $(LD).
+
+ Example::
+
+ #arch/cris/boot/compressed/Makefile
+ ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
+
+subdir-ccflags-y, subdir-asflags-y
+ The two flags listed above are similar to ccflags-y and asflags-y.
+ The difference is that the subdir- variants have effect for the kbuild
+ file where they are present and all subdirectories.
+ Options specified using subdir-* are added to the commandline before
+ the options specified using the non-subdir variants.
+
+ Example::
+
+ subdir-ccflags-y := -Werror
+
+ccflags-remove-y, asflags-remove-y
+ These flags are used to remove particular flags for the compiler,
+ assembler invocations.
+
+ Example::
+
+ ccflags-remove-$(CONFIG_MCOUNT) += -pg
+
+CFLAGS_$@, AFLAGS_$@
+ CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
+ kbuild makefile.
+
+ $(CFLAGS_$@) specifies per-file options for $(CC). The $@
+ part has a literal value which specifies the file that it is for.
+
+ CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@
+ can re-add compiler flags that were removed by ccflags-remove-y.
+
+ Example::
+
+ # drivers/scsi/Makefile
+ CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
+
+ This line specify compilation flags for aha152x.o.
+
+ $(AFLAGS_$@) is a similar feature for source files in assembly
+ languages.
+
+ AFLAGS_$@ has the higher priority than asflags-remove-y; AFLAGS_$@
+ can re-add assembler flags that were removed by asflags-remove-y.
+
+ Example::
+
+ # arch/arm/kernel/Makefile
+ AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
+ AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
+ AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
+
+Dependency tracking
+-------------------
+
+Kbuild tracks dependencies on the following:
+
+1) All prerequisite files (both ``*.c`` and ``*.h``)
+2) ``CONFIG_`` options used in all prerequisite files
+3) Command-line used to compile target
+
+Thus, if you change an option to $(CC) all affected files will
+be re-compiled.
+
+Custom Rules
+------------
+
+Custom rules are used when the kbuild infrastructure does
+not provide the required support. A typical example is
+header files generated during the build process.
+Another example are the architecture-specific Makefiles which
+need custom rules to prepare boot images etc.
+
+Custom rules are written as normal Make rules.
+Kbuild is not executing in the directory where the Makefile is
+located, so all custom rules shall use a relative
+path to prerequisite files and target files.
+
+Two variables are used when defining custom rules:
+
+$(src)
+ $(src) is a relative path which points to the directory
+ where the Makefile is located. Always use $(src) when
+ referring to files located in the src tree.
+
+$(obj)
+ $(obj) is a relative path which points to the directory
+ where the target is saved. Always use $(obj) when
+ referring to generated files.
+
+ Example::
+
+ #drivers/scsi/Makefile
+ $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
+ $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
+
+ This is a custom rule, following the normal syntax
+ required by make.
+
+ The target file depends on two prerequisite files. References
+ to the target file are prefixed with $(obj), references
+ to prerequisites are referenced with $(src) (because they are not
+ generated files).
+
+$(kecho)
+ echoing information to user in a rule is often a good practice
+ but when execution ``make -s`` one does not expect to see any output
+ except for warnings/errors.
+ To support this kbuild defines $(kecho) which will echo out the
+ text following $(kecho) to stdout except if ``make -s`` is used.
+
+ Example::
+
+ # arch/arm/Makefile
+ $(BOOT_TARGETS): vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+ @$(kecho) ' Kernel: $(boot)/$@ is ready'
+
+ When kbuild is executing with KBUILD_VERBOSE unset, then only a shorthand
+ of a command is normally displayed.
+ To enable this behaviour for custom commands kbuild requires
+ two variables to be set::
+
+ quiet_cmd_<command> - what shall be echoed
+ cmd_<command> - the command to execute
+
+ Example::
+
+ # lib/Makefile
+ quiet_cmd_crc32 = GEN $@
+ cmd_crc32 = $< > $@
+
+ $(obj)/crc32table.h: $(obj)/gen_crc32table
+ $(call cmd,crc32)
+
+ When updating the $(obj)/crc32table.h target, the line::
+
+ GEN lib/crc32table.h
+
+ will be displayed with ``make KBUILD_VERBOSE=``.
+
+Command change detection
+------------------------
+
+When the rule is evaluated, timestamps are compared between the target
+and its prerequisite files. GNU Make updates the target when any of the
+prerequisites is newer than that.
+
+The target should be rebuilt also when the command line has changed
+since the last invocation. This is not supported by Make itself, so
+Kbuild achieves this by a kind of meta-programming.
+
+if_changed is the macro used for this purpose, in the following form::
+
+ quiet_cmd_<command> = ...
+ cmd_<command> = ...
+
+ <target>: <source(s)> FORCE
+ $(call if_changed,<command>)
+
+Any target that utilizes if_changed must be listed in $(targets),
+otherwise the command line check will fail, and the target will
+always be built.
+
+If the target is already listed in the recognized syntax such as
+obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild
+automatically adds it to $(targets). Otherwise, the target must be
+explicitly added to $(targets).
+
+Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
+used in conjunction with custom rules as defined in `Custom Rules`_.
+
+Note: It is a typical mistake to forget the FORCE prerequisite.
+Another common pitfall is that whitespace is sometimes significant; for
+instance, the below will fail (note the extra space after the comma)::
+
+ target: source(s) FORCE
+
+**WRONG!** $(call if_changed, objcopy)
+
+Note:
+ if_changed should not be used more than once per target.
+ It stores the executed command in a corresponding .cmd
+ file and multiple calls would result in overwrites and
+ unwanted results when the target is up to date and only the
+ tests on changed commands trigger execution of commands.
+
+$(CC) support functions
+-----------------------
+
+The kernel may be built with several different versions of
+$(CC), each supporting a unique set of features and options.
+kbuild provides basic support to check for valid options for $(CC).
+$(CC) is usually the gcc compiler, but other alternatives are
+available.
+
+as-option
+ as-option is used to check if $(CC) -- when used to compile
+ assembler (``*.S``) files -- supports the given option. An optional
+ second option may be specified if the first option is not supported.
+
+ Example::
+
+ #arch/sh/Makefile
+ cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
+
+ In the above example, cflags-y will be assigned the option
+ -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
+ The second argument is optional, and if supplied will be used
+ if first argument is not supported.
+
+as-instr
+ as-instr checks if the assembler reports a specific instruction
+ and then outputs either option1 or option2
+ C escapes are supported in the test instruction
+ Note: as-instr-option uses KBUILD_AFLAGS for assembler options
+
+cc-option
+ cc-option is used to check if $(CC) supports a given option, and if
+ not supported to use an optional second option.
+
+ Example::
+
+ #arch/x86/Makefile
+ cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
+
+ In the above example, cflags-y will be assigned the option
+ -march=pentium-mmx if supported by $(CC), otherwise -march=i586.
+ The second argument to cc-option is optional, and if omitted,
+ cflags-y will be assigned no value if first option is not supported.
+ Note: cc-option uses KBUILD_CFLAGS for $(CC) options
+
+cc-option-yn
+ cc-option-yn is used to check if gcc supports a given option
+ and return "y" if supported, otherwise "n".
+
+ Example::
+
+ #arch/ppc/Makefile
+ biarch := $(call cc-option-yn, -m32)
+ aflags-$(biarch) += -a32
+ cflags-$(biarch) += -m32
+
+ In the above example, $(biarch) is set to y if $(CC) supports the -m32
+ option. When $(biarch) equals "y", the expanded variables $(aflags-y)
+ and $(cflags-y) will be assigned the values -a32 and -m32,
+ respectively.
+
+ Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
+
+cc-disable-warning
+ cc-disable-warning checks if gcc supports a given warning and returns
+ the commandline switch to disable it. This special function is needed,
+ because gcc 4.4 and later accept any unknown -Wno-* option and only
+ warn about it if there is another warning in the source file.
+
+ Example::
+
+ KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+
+ In the above example, -Wno-unused-but-set-variable will be added to
+ KBUILD_CFLAGS only if gcc really accepts it.
+
+gcc-min-version
+ gcc-min-version tests if the value of $(CONFIG_GCC_VERSION) is greater than
+ or equal to the provided value and evaluates to y if so.
+
+ Example::
+
+ cflags-$(call gcc-min-version, 70100) := -foo
+
+ In this example, cflags-y will be assigned the value -foo if $(CC) is gcc and
+ $(CONFIG_GCC_VERSION) is >= 7.1.
+
+clang-min-version
+ clang-min-version tests if the value of $(CONFIG_CLANG_VERSION) is greater
+ than or equal to the provided value and evaluates to y if so.
+
+ Example::
+
+ cflags-$(call clang-min-version, 110000) := -foo
+
+ In this example, cflags-y will be assigned the value -foo if $(CC) is clang
+ and $(CONFIG_CLANG_VERSION) is >= 11.0.0.
+
+cc-cross-prefix
+ cc-cross-prefix is used to check if there exists a $(CC) in path with
+ one of the listed prefixes. The first prefix where there exist a
+ prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found
+ then nothing is returned.
+
+ Additional prefixes are separated by a single space in the
+ call of cc-cross-prefix.
+
+ This functionality is useful for architecture Makefiles that try
+ to set CROSS_COMPILE to well-known values but may have several
+ values to select between.
+
+ It is recommended only to try to set CROSS_COMPILE if it is a cross
+ build (host arch is different from target arch). And if CROSS_COMPILE
+ is already set then leave it with the old value.
+
+ Example::
+
+ #arch/m68k/Makefile
+ ifneq ($(SUBARCH),$(ARCH))
+ ifeq ($(CROSS_COMPILE),)
+ CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
+ endif
+ endif
+
+$(LD) support functions
+-----------------------
+
+ld-option
+ ld-option is used to check if $(LD) supports the supplied option.
+ ld-option takes two options as arguments.
+
+ The second argument is an optional option that can be used if the
+ first option is not supported by $(LD).
+
+ Example::
+
+ #Makefile
+ LDFLAGS_vmlinux += $(call ld-option, -X)
+
+Script invocation
+-----------------
+
+Make rules may invoke scripts to build the kernel. The rules shall
+always provide the appropriate interpreter to execute the script. They
+shall not rely on the execute bits being set, and shall not invoke the
+script directly. For the convenience of manual script invocation, such
+as invoking ./scripts/checkpatch.pl, it is recommended to set execute
+bits on the scripts nonetheless.
+
+Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL),
+and $(PYTHON3) to refer to interpreters for the respective
+scripts.
+
+Example::
+
+ #Makefile
+ cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
+ $(KERNELRELEASE)
+
+Host Program support
+====================
Kbuild supports building executables on the host for use during the
compilation stage.
+
Two steps are required in order to use a host executable.
The first step is to tell kbuild that a host program exists. This is
-done utilising the variable "hostprogs".
+done utilising the variable ``hostprogs``.
The second step is to add an explicit dependency to the executable.
This can be done in two ways. Either add the dependency in a rule,
-or utilise the variable "always-y".
+or utilise the variable ``always-y``.
Both possibilities are described in the following.
-4.1 Simple Host Program
+Simple Host Program
+-------------------
+
+In some cases there is a need to compile and run a program on the
+computer where the build is running.
+
+The following line tells kbuild that the program bin2hex shall be
+built on the build host.
+
+Example::
+
+ hostprogs := bin2hex
+
+Kbuild assumes in the above example that bin2hex is made from a single
+c-source file named bin2hex.c located in the same directory as
+the Makefile.
+
+Composite Host Programs
-----------------------
- In some cases there is a need to compile and run a program on the
- computer where the build is running.
- The following line tells kbuild that the program bin2hex shall be
- built on the build host.
+Host programs can be made up based on composite objects.
+The syntax used to define composite objects for host programs is
+similar to the syntax used for kernel objects.
+$(<executable>-objs) lists all objects used to link the final
+executable.
- Example::
+Example::
- hostprogs := bin2hex
+ #scripts/lxdialog/Makefile
+ hostprogs := lxdialog
+ lxdialog-objs := checklist.o lxdialog.o
- Kbuild assumes in the above example that bin2hex is made from a single
- c-source file named bin2hex.c located in the same directory as
- the Makefile.
+Objects with extension .o are compiled from the corresponding .c
+files. In the above example, checklist.c is compiled to checklist.o
+and lxdialog.c is compiled to lxdialog.o.
-4.2 Composite Host Programs
+Finally, the two .o files are linked to the executable, lxdialog.
+Note: The syntax <executable>-y is not permitted for host-programs.
+
+Using C++ for host programs
---------------------------
- Host programs can be made up based on composite objects.
- The syntax used to define composite objects for host programs is
- similar to the syntax used for kernel objects.
- $(<executable>-objs) lists all objects used to link the final
- executable.
+kbuild offers support for host programs written in C++. This was
+introduced solely to support kconfig, and is not recommended
+for general use.
- Example::
+Example::
- #scripts/lxdialog/Makefile
- hostprogs := lxdialog
- lxdialog-objs := checklist.o lxdialog.o
+ #scripts/kconfig/Makefile
+ hostprogs := qconf
+ qconf-cxxobjs := qconf.o
- Objects with extension .o are compiled from the corresponding .c
- files. In the above example, checklist.c is compiled to checklist.o
- and lxdialog.c is compiled to lxdialog.o.
+In the example above the executable is composed of the C++ file
+qconf.cc - identified by $(qconf-cxxobjs).
- Finally, the two .o files are linked to the executable, lxdialog.
- Note: The syntax <executable>-y is not permitted for host-programs.
+If qconf is composed of a mixture of .c and .cc files, then an
+additional line can be used to identify this.
-4.3 Using C++ for host programs
--------------------------------
+Example::
- kbuild offers support for host programs written in C++. This was
- introduced solely to support kconfig, and is not recommended
- for general use.
+ #scripts/kconfig/Makefile
+ hostprogs := qconf
+ qconf-cxxobjs := qconf.o
+ qconf-objs := check.o
- Example::
+Using Rust for host programs
+----------------------------
- #scripts/kconfig/Makefile
- hostprogs := qconf
- qconf-cxxobjs := qconf.o
+Kbuild offers support for host programs written in Rust. However,
+since a Rust toolchain is not mandatory for kernel compilation,
+it may only be used in scenarios where Rust is required to be
+available (e.g. when ``CONFIG_RUST`` is enabled).
- In the example above the executable is composed of the C++ file
- qconf.cc - identified by $(qconf-cxxobjs).
+Example::
- If qconf is composed of a mixture of .c and .cc files, then an
- additional line can be used to identify this.
+ hostprogs := target
+ target-rust := y
- Example::
+Kbuild will compile ``target`` using ``target.rs`` as the crate root,
+located in the same directory as the ``Makefile``. The crate may
+consist of several source files (see ``samples/rust/hostprogs``).
- #scripts/kconfig/Makefile
- hostprogs := qconf
- qconf-cxxobjs := qconf.o
- qconf-objs := check.o
+Controlling compiler options for host programs
+----------------------------------------------
-4.4 Using Rust for host programs
---------------------------------
+When compiling host programs, it is possible to set specific flags.
+The programs will always be compiled utilising $(HOSTCC) passed
+the options specified in $(KBUILD_HOSTCFLAGS).
- Kbuild offers support for host programs written in Rust. However,
- since a Rust toolchain is not mandatory for kernel compilation,
- it may only be used in scenarios where Rust is required to be
- available (e.g. when ``CONFIG_RUST`` is enabled).
+To set flags that will take effect for all host programs created
+in that Makefile, use the variable HOST_EXTRACFLAGS.
- Example::
+Example::
- hostprogs := target
- target-rust := y
+ #scripts/lxdialog/Makefile
+ HOST_EXTRACFLAGS += -I/usr/include/ncurses
- Kbuild will compile ``target`` using ``target.rs`` as the crate root,
- located in the same directory as the ``Makefile``. The crate may
- consist of several source files (see ``samples/rust/hostprogs``).
+To set specific flags for a single file the following construction
+is used:
-4.5 Controlling compiler options for host programs
---------------------------------------------------
+Example::
- When compiling host programs, it is possible to set specific flags.
- The programs will always be compiled utilising $(HOSTCC) passed
- the options specified in $(KBUILD_HOSTCFLAGS).
- To set flags that will take effect for all host programs created
- in that Makefile, use the variable HOST_EXTRACFLAGS.
+ #arch/ppc64/boot/Makefile
+ HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
- Example::
+It is also possible to specify additional options to the linker.
- #scripts/lxdialog/Makefile
- HOST_EXTRACFLAGS += -I/usr/include/ncurses
+Example::
- To set specific flags for a single file the following construction
- is used:
+ #scripts/kconfig/Makefile
+ HOSTLDLIBS_qconf := -L$(QTDIR)/lib
- Example::
+When linking qconf, it will be passed the extra option
+``-L$(QTDIR)/lib``.
- #arch/ppc64/boot/Makefile
- HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
+When host programs are actually built
+-------------------------------------
- It is also possible to specify additional options to the linker.
+Kbuild will only build host-programs when they are referenced
+as a prerequisite.
- Example::
+This is possible in two ways:
- #scripts/kconfig/Makefile
- HOSTLDLIBS_qconf := -L$(QTDIR)/lib
+(1) List the prerequisite explicitly in a custom rule.
- When linking qconf, it will be passed the extra option
- "-L$(QTDIR)/lib".
+ Example::
-4.6 When host programs are actually built
------------------------------------------
+ #drivers/pci/Makefile
+ hostprogs := gen-devlist
+ $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
+ ( cd $(obj); ./gen-devlist ) < $<
- Kbuild will only build host-programs when they are referenced
- as a prerequisite.
- This is possible in two ways:
+ The target $(obj)/devlist.h will not be built before
+ $(obj)/gen-devlist is updated. Note that references to
+ the host programs in custom rules must be prefixed with $(obj).
- (1) List the prerequisite explicitly in a custom rule.
+(2) Use always-y
- Example::
+ When there is no suitable custom rule, and the host program
+ shall be built when a makefile is entered, the always-y
+ variable shall be used.
- #drivers/pci/Makefile
- hostprogs := gen-devlist
- $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
- ( cd $(obj); ./gen-devlist ) < $<
+ Example::
- The target $(obj)/devlist.h will not be built before
- $(obj)/gen-devlist is updated. Note that references to
- the host programs in custom rules must be prefixed with $(obj).
+ #scripts/lxdialog/Makefile
+ hostprogs := lxdialog
+ always-y := $(hostprogs)
- (2) Use always-y
+ Kbuild provides the following shorthand for this::
- When there is no suitable custom rule, and the host program
- shall be built when a makefile is entered, the always-y
- variable shall be used.
+ hostprogs-always-y := lxdialog
- Example::
+ This will tell kbuild to build lxdialog even if not referenced in
+ any rule.
- #scripts/lxdialog/Makefile
- hostprogs := lxdialog
- always-y := $(hostprogs)
-
- Kbuild provides the following shorthand for this:
-
- hostprogs-always-y := lxdialog
-
- This will tell kbuild to build lxdialog even if not referenced in
- any rule.
-
-5 Userspace Program support
-===========================
+Userspace Program support
+=========================
Just like host programs, Kbuild also supports building userspace executables
for the target architecture (i.e. the same architecture as you are building
the kernel for).
-The syntax is quite similar. The difference is to use "userprogs" instead of
-"hostprogs".
+The syntax is quite similar. The difference is to use ``userprogs`` instead of
+``hostprogs``.
-5.1 Simple Userspace Program
+Simple Userspace Program
+------------------------
+
+The following line tells kbuild that the program bpf-direct shall be
+built for the target architecture.
+
+Example::
+
+ userprogs := bpf-direct
+
+Kbuild assumes in the above example that bpf-direct is made from a
+single C source file named bpf-direct.c located in the same directory
+as the Makefile.
+
+Composite Userspace Programs
----------------------------
- The following line tells kbuild that the program bpf-direct shall be
- built for the target architecture.
+Userspace programs can be made up based on composite objects.
+The syntax used to define composite objects for userspace programs is
+similar to the syntax used for kernel objects.
+$(<executable>-objs) lists all objects used to link the final
+executable.
- Example::
+Example::
- userprogs := bpf-direct
+ #samples/seccomp/Makefile
+ userprogs := bpf-fancy
+ bpf-fancy-objs := bpf-fancy.o bpf-helper.o
- Kbuild assumes in the above example that bpf-direct is made from a
- single C source file named bpf-direct.c located in the same directory
- as the Makefile.
+Objects with extension .o are compiled from the corresponding .c
+files. In the above example, bpf-fancy.c is compiled to bpf-fancy.o
+and bpf-helper.c is compiled to bpf-helper.o.
-5.2 Composite Userspace Programs
---------------------------------
+Finally, the two .o files are linked to the executable, bpf-fancy.
+Note: The syntax <executable>-y is not permitted for userspace programs.
- Userspace programs can be made up based on composite objects.
- The syntax used to define composite objects for userspace programs is
- similar to the syntax used for kernel objects.
- $(<executable>-objs) lists all objects used to link the final
- executable.
+Controlling compiler options for userspace programs
+---------------------------------------------------
- Example::
+When compiling userspace programs, it is possible to set specific flags.
+The programs will always be compiled utilising $(CC) passed
+the options specified in $(KBUILD_USERCFLAGS).
- #samples/seccomp/Makefile
- userprogs := bpf-fancy
- bpf-fancy-objs := bpf-fancy.o bpf-helper.o
+To set flags that will take effect for all userspace programs created
+in that Makefile, use the variable userccflags.
- Objects with extension .o are compiled from the corresponding .c
- files. In the above example, bpf-fancy.c is compiled to bpf-fancy.o
- and bpf-helper.c is compiled to bpf-helper.o.
+Example::
- Finally, the two .o files are linked to the executable, bpf-fancy.
- Note: The syntax <executable>-y is not permitted for userspace programs.
+ # samples/seccomp/Makefile
+ userccflags += -I usr/include
-5.3 Controlling compiler options for userspace programs
--------------------------------------------------------
+To set specific flags for a single file the following construction
+is used:
- When compiling userspace programs, it is possible to set specific flags.
- The programs will always be compiled utilising $(CC) passed
- the options specified in $(KBUILD_USERCFLAGS).
- To set flags that will take effect for all userspace programs created
- in that Makefile, use the variable userccflags.
+Example::
- Example::
+ bpf-helper-userccflags += -I user/include
- # samples/seccomp/Makefile
- userccflags += -I usr/include
+It is also possible to specify additional options to the linker.
- To set specific flags for a single file the following construction
- is used:
+Example::
- Example::
+ # net/bpfilter/Makefile
+ bpfilter_umh-userldflags += -static
- bpf-helper-userccflags += -I user/include
+When linking bpfilter_umh, it will be passed the extra option -static.
- It is also possible to specify additional options to the linker.
+From command line, :ref:`USERCFLAGS and USERLDFLAGS <userkbuildflags>` will also be used.
- Example::
+When userspace programs are actually built
+------------------------------------------
- # net/bpfilter/Makefile
- bpfilter_umh-userldflags += -static
+Kbuild builds userspace programs only when told to do so.
+There are two ways to do this.
- When linking bpfilter_umh, it will be passed the extra option -static.
+(1) Add it as the prerequisite of another file
- From command line, :ref:`USERCFLAGS and USERLDFLAGS <userkbuildflags>` will also be used.
+ Example::
-5.4 When userspace programs are actually built
-----------------------------------------------
+ #net/bpfilter/Makefile
+ userprogs := bpfilter_umh
+ $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
- Kbuild builds userspace programs only when told to do so.
- There are two ways to do this.
+ $(obj)/bpfilter_umh is built before $(obj)/bpfilter_umh_blob.o
- (1) Add it as the prerequisite of another file
+(2) Use always-y
- Example::
+ Example::
- #net/bpfilter/Makefile
- userprogs := bpfilter_umh
- $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
+ userprogs := binderfs_example
+ always-y := $(userprogs)
- $(obj)/bpfilter_umh is built before $(obj)/bpfilter_umh_blob.o
+ Kbuild provides the following shorthand for this::
- (2) Use always-y
+ userprogs-always-y := binderfs_example
- Example::
+ This will tell Kbuild to build binderfs_example when it visits this
+ Makefile.
- userprogs := binderfs_example
- always-y := $(userprogs)
+Kbuild clean infrastructure
+===========================
- Kbuild provides the following shorthand for this:
-
- userprogs-always-y := binderfs_example
-
- This will tell Kbuild to build binderfs_example when it visits this
- Makefile.
-
-6 Kbuild clean infrastructure
-=============================
-
-"make clean" deletes most generated files in the obj tree where the kernel
+``make clean`` deletes most generated files in the obj tree where the kernel
is compiled. This includes generated files such as host programs.
Kbuild knows targets listed in $(hostprogs), $(always-y), $(always-m),
$(always-), $(extra-y), $(extra-) and $(targets). They are all deleted
-during "make clean". Files matching the patterns "*.[oas]", "*.ko", plus
+during ``make clean``. Files matching the patterns ``*.[oas]``, ``*.ko``, plus
some additional files generated by kbuild are deleted all over the kernel
-source tree when "make clean" is executed.
+source tree when ``make clean`` is executed.
Additional files or directories can be specified in kbuild makefiles by use of
$(clean-files).
- Example::
+Example::
- #lib/Makefile
- clean-files := crc32table.h
+ #lib/Makefile
+ clean-files := crc32table.h
-When executing "make clean", the file "crc32table.h" will be deleted.
+When executing ``make clean``, the file ``crc32table.h`` will be deleted.
Kbuild will assume files to be in the same relative directory as the
Makefile.
To exclude certain files or directories from make clean, use the
$(no-clean-files) variable.
-Usually kbuild descends down in subdirectories due to "obj-* := dir/",
+Usually kbuild descends down in subdirectories due to ``obj-* := dir/``,
but in the architecture makefiles where the kbuild infrastructure
is not sufficient this sometimes needs to be explicit.
- Example::
+Example::
- #arch/x86/boot/Makefile
- subdir- := compressed
+ #arch/x86/boot/Makefile
+ subdir- := compressed
The above assignment instructs kbuild to descend down in the
-directory compressed/ when "make clean" is executed.
+directory compressed/ when ``make clean`` is executed.
-Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is
+Note 1: arch/$(SRCARCH)/Makefile cannot use ``subdir-``, because that file is
included in the top level makefile. Instead, arch/$(SRCARCH)/Kbuild can use
-"subdir-".
+``subdir-``.
Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will
-be visited during "make clean".
+be visited during ``make clean``.
-7 Architecture Makefiles
-========================
+Architecture Makefiles
+======================
The top level Makefile sets up the environment and does the preparation,
before starting to descend down in the individual directories.
+
The top level makefile contains the generic part, whereas
arch/$(SRCARCH)/Makefile contains what is required to set up kbuild
for said architecture.
+
To do so, arch/$(SRCARCH)/Makefile sets up a number of variables and defines
a few targets.
When kbuild executes, the following steps are followed (roughly):
1) Configuration of the kernel => produce .config
+
2) Store kernel version in include/linux/version.h
+
3) Updating all other prerequisites to the target prepare:
+
- Additional prerequisites are specified in arch/$(SRCARCH)/Makefile
+
4) Recursively descend down in all directories listed in
init-* core* drivers-* net-* libs-* and build all targets.
+
- The values of the above variables are expanded in arch/$(SRCARCH)/Makefile.
+
5) All object files are then linked and the resulting file vmlinux is
located at the root of the obj tree.
The very first objects linked are listed in scripts/head-object-list.txt.
+
6) Finally, the architecture-specific part does any required post processing
and builds the final bootimage.
+
- This includes building boot records
- Preparing initrd images and the like
+Set variables to tweak the build to the architecture
+----------------------------------------------------
-7.1 Set variables to tweak the build to the architecture
---------------------------------------------------------
+KBUILD_LDFLAGS
+ Generic $(LD) options
- KBUILD_LDFLAGS
- Generic $(LD) options
+ Flags used for all invocations of the linker.
+ Often specifying the emulation is sufficient.
- Flags used for all invocations of the linker.
- Often specifying the emulation is sufficient.
+ Example::
- Example::
+ #arch/s390/Makefile
+ KBUILD_LDFLAGS := -m elf_s390
- #arch/s390/Makefile
- KBUILD_LDFLAGS := -m elf_s390
+ Note: ldflags-y can be used to further customise
+ the flags used. See `Non-builtin vmlinux targets - extra-y`_.
- Note: ldflags-y can be used to further customise
- the flags used. See section 3.7.
+LDFLAGS_vmlinux
+ Options for $(LD) when linking vmlinux
- LDFLAGS_vmlinux
- Options for $(LD) when linking vmlinux
+ LDFLAGS_vmlinux is used to specify additional flags to pass to
+ the linker when linking the final vmlinux image.
- LDFLAGS_vmlinux is used to specify additional flags to pass to
- the linker when linking the final vmlinux image.
- LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
+ LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
- Example::
+ Example::
- #arch/x86/Makefile
- LDFLAGS_vmlinux := -e stext
+ #arch/x86/Makefile
+ LDFLAGS_vmlinux := -e stext
- OBJCOPYFLAGS
- objcopy flags
+OBJCOPYFLAGS
+ objcopy flags
- When $(call if_changed,objcopy) is used to translate a .o file,
- the flags specified in OBJCOPYFLAGS will be used.
- $(call if_changed,objcopy) is often used to generate raw binaries on
- vmlinux.
+ When $(call if_changed,objcopy) is used to translate a .o file,
+ the flags specified in OBJCOPYFLAGS will be used.
- Example::
+ $(call if_changed,objcopy) is often used to generate raw binaries on
+ vmlinux.
- #arch/s390/Makefile
- OBJCOPYFLAGS := -O binary
+ Example::
- #arch/s390/boot/Makefile
- $(obj)/image: vmlinux FORCE
- $(call if_changed,objcopy)
+ #arch/s390/Makefile
+ OBJCOPYFLAGS := -O binary
- In this example, the binary $(obj)/image is a binary version of
- vmlinux. The usage of $(call if_changed,xxx) will be described later.
+ #arch/s390/boot/Makefile
+ $(obj)/image: vmlinux FORCE
+ $(call if_changed,objcopy)
- KBUILD_AFLAGS
- Assembler flags
+ In this example, the binary $(obj)/image is a binary version of
+ vmlinux. The usage of $(call if_changed,xxx) will be described later.
- Default value - see top level Makefile
- Append or modify as required per architecture.
+KBUILD_AFLAGS
+ Assembler flags
- Example::
+ Default value - see top level Makefile.
- #arch/sparc64/Makefile
- KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
+ Append or modify as required per architecture.
- KBUILD_CFLAGS
- $(CC) compiler flags
+ Example::
- Default value - see top level Makefile
- Append or modify as required per architecture.
+ #arch/sparc64/Makefile
+ KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
- Often, the KBUILD_CFLAGS variable depends on the configuration.
+KBUILD_CFLAGS
+ $(CC) compiler flags
- Example::
+ Default value - see top level Makefile.
- #arch/x86/boot/compressed/Makefile
- cflags-$(CONFIG_X86_32) := -march=i386
- cflags-$(CONFIG_X86_64) := -mcmodel=small
- KBUILD_CFLAGS += $(cflags-y)
+ Append or modify as required per architecture.
- Many arch Makefiles dynamically run the target C compiler to
- probe supported options::
+ Often, the KBUILD_CFLAGS variable depends on the configuration.
- #arch/x86/Makefile
+ Example::
- ...
- cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
+ #arch/x86/boot/compressed/Makefile
+ cflags-$(CONFIG_X86_32) := -march=i386
+ cflags-$(CONFIG_X86_64) := -mcmodel=small
+ KBUILD_CFLAGS += $(cflags-y)
+
+ Many arch Makefiles dynamically run the target C compiler to
+ probe supported options::
+
+ #arch/x86/Makefile
+
+ ...
+ cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
-march=pentium2,-march=i686)
- ...
- # Disable unit-at-a-time mode ...
- KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time)
- ...
+ ...
+ # Disable unit-at-a-time mode ...
+ KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time)
+ ...
- The first example utilises the trick that a config option expands
- to 'y' when selected.
+ The first example utilises the trick that a config option expands
+ to "y" when selected.
- KBUILD_RUSTFLAGS
- $(RUSTC) compiler flags
+KBUILD_RUSTFLAGS
+ $(RUSTC) compiler flags
- Default value - see top level Makefile
- Append or modify as required per architecture.
+ Default value - see top level Makefile.
- Often, the KBUILD_RUSTFLAGS variable depends on the configuration.
+ Append or modify as required per architecture.
- Note that target specification file generation (for ``--target``)
- is handled in ``scripts/generate_rust_target.rs``.
+ Often, the KBUILD_RUSTFLAGS variable depends on the configuration.
- KBUILD_AFLAGS_KERNEL
- Assembler options specific for built-in
+ Note that target specification file generation (for ``--target``)
+ is handled in ``scripts/generate_rust_target.rs``.
- $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
- resident kernel code.
+KBUILD_AFLAGS_KERNEL
+ Assembler options specific for built-in
- KBUILD_AFLAGS_MODULE
- Assembler options specific for modules
+ $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
+ resident kernel code.
- $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
- are used for assembler.
+KBUILD_AFLAGS_MODULE
+ Assembler options specific for modules
- From commandline AFLAGS_MODULE shall be used (see kbuild.rst).
+ $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
+ are used for assembler.
- KBUILD_CFLAGS_KERNEL
- $(CC) options specific for built-in
+ From commandline AFLAGS_MODULE shall be used (see kbuild.rst).
- $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
- resident kernel code.
+KBUILD_CFLAGS_KERNEL
+ $(CC) options specific for built-in
- KBUILD_CFLAGS_MODULE
- Options for $(CC) when building modules
+ $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
+ resident kernel code.
- $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that
- are used for $(CC).
- From commandline CFLAGS_MODULE shall be used (see kbuild.rst).
+KBUILD_CFLAGS_MODULE
+ Options for $(CC) when building modules
- KBUILD_RUSTFLAGS_KERNEL
- $(RUSTC) options specific for built-in
+ $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that
+ are used for $(CC).
- $(KBUILD_RUSTFLAGS_KERNEL) contains extra Rust compiler flags used to
- compile resident kernel code.
+ From commandline CFLAGS_MODULE shall be used (see kbuild.rst).
- KBUILD_RUSTFLAGS_MODULE
- Options for $(RUSTC) when building modules
+KBUILD_RUSTFLAGS_KERNEL
+ $(RUSTC) options specific for built-in
- $(KBUILD_RUSTFLAGS_MODULE) is used to add arch-specific options that
- are used for $(RUSTC).
- From commandline RUSTFLAGS_MODULE shall be used (see kbuild.rst).
+ $(KBUILD_RUSTFLAGS_KERNEL) contains extra Rust compiler flags used to
+ compile resident kernel code.
- KBUILD_LDFLAGS_MODULE
- Options for $(LD) when linking modules
+KBUILD_RUSTFLAGS_MODULE
+ Options for $(RUSTC) when building modules
- $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
- used when linking modules. This is often a linker script.
+ $(KBUILD_RUSTFLAGS_MODULE) is used to add arch-specific options that
+ are used for $(RUSTC).
- From commandline LDFLAGS_MODULE shall be used (see kbuild.rst).
+ From commandline RUSTFLAGS_MODULE shall be used (see kbuild.rst).
- KBUILD_LDS
+KBUILD_LDFLAGS_MODULE
+ Options for $(LD) when linking modules
- The linker script with full path. Assigned by the top-level Makefile.
+ $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
+ used when linking modules. This is often a linker script.
- KBUILD_LDS_MODULE
+ From commandline LDFLAGS_MODULE shall be used (see kbuild.rst).
- The module linker script with full path. Assigned by the top-level
- Makefile and additionally by the arch Makefile.
+KBUILD_LDS
+ The linker script with full path. Assigned by the top-level Makefile.
- KBUILD_VMLINUX_OBJS
+KBUILD_VMLINUX_OBJS
+ All object files for vmlinux. They are linked to vmlinux in the same
+ order as listed in KBUILD_VMLINUX_OBJS.
- All object files for vmlinux. They are linked to vmlinux in the same
- order as listed in KBUILD_VMLINUX_OBJS.
+ The objects listed in scripts/head-object-list.txt are exceptions;
+ they are placed before the other objects.
- The objects listed in scripts/head-object-list.txt are exceptions;
- they are placed before the other objects.
+KBUILD_VMLINUX_LIBS
+ All .a ``lib`` files for vmlinux. KBUILD_VMLINUX_OBJS and
+ KBUILD_VMLINUX_LIBS together specify all the object files used to
+ link vmlinux.
- KBUILD_VMLINUX_LIBS
-
- All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and
- KBUILD_VMLINUX_LIBS together specify all the object files used to
- link vmlinux.
-
-7.2 Add prerequisites to archheaders
-------------------------------------
-
- The archheaders: rule is used to generate header files that
- may be installed into user space by "make header_install".
-
- It is run before "make archprepare" when run on the
- architecture itself.
-
-
-7.3 Add prerequisites to archprepare
-------------------------------------
-
- The archprepare: rule is used to list prerequisites that need to be
- built before starting to descend down in the subdirectories.
- This is usually used for header files containing assembler constants.
-
- Example::
-
- #arch/arm/Makefile
- archprepare: maketools
-
- In this example, the file target maketools will be processed
- before descending down in the subdirectories.
- See also chapter XXX-TODO that describes how kbuild supports
- generating offset header files.
-
-
-7.4 List directories to visit when descending
----------------------------------------------
-
- An arch Makefile cooperates with the top Makefile to define variables
- which specify how to build the vmlinux file. Note that there is no
- corresponding arch-specific section for modules; the module-building
- machinery is all architecture-independent.
-
-
- core-y, libs-y, drivers-y
-
- $(libs-y) lists directories where a lib.a archive can be located.
-
- The rest list directories where a built-in.a object file can be
- located.
-
- Then the rest follows in this order:
-
- $(core-y), $(libs-y), $(drivers-y)
-
- The top level Makefile defines values for all generic directories,
- and arch/$(SRCARCH)/Makefile only adds architecture-specific
- directories.
-
- Example::
-
- # arch/sparc/Makefile
- core-y += arch/sparc/
-
- libs-y += arch/sparc/prom/
- libs-y += arch/sparc/lib/
-
- drivers-$(CONFIG_PM) += arch/sparc/power/
-
-7.5 Architecture-specific boot images
--------------------------------------
-
- An arch Makefile specifies goals that take the vmlinux file, compress
- it, wrap it in bootstrapping code, and copy the resulting files
- somewhere. This includes various kinds of installation commands.
- The actual goals are not standardized across architectures.
-
- It is common to locate any additional processing in a boot/
- directory below arch/$(SRCARCH)/.
-
- Kbuild does not provide any smart way to support building a
- target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall
- call make manually to build a target in boot/.
-
- The recommended approach is to include shortcuts in
- arch/$(SRCARCH)/Makefile, and use the full path when calling down
- into the arch/$(SRCARCH)/boot/Makefile.
-
- Example::
-
- #arch/x86/Makefile
- boot := arch/x86/boot
- bzImage: vmlinux
- $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
-
- "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke
- make in a subdirectory.
-
- There are no rules for naming architecture-specific targets,
- but executing "make help" will list all relevant targets.
- To support this, $(archhelp) must be defined.
-
- Example::
-
- #arch/x86/Makefile
- define archhelp
- echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
- endif
-
- When make is executed without arguments, the first goal encountered
- will be built. In the top level Makefile the first goal present
- is all:.
- An architecture shall always, per default, build a bootable image.
- In "make help", the default goal is highlighted with a '*'.
- Add a new prerequisite to all: to select a default goal different
- from vmlinux.
-
- Example::
-
- #arch/x86/Makefile
- all: bzImage
-
- When "make" is executed without arguments, bzImage will be built.
-
-7.7 Commands useful for building a boot image
----------------------------------------------
-
- Kbuild provides a few macros that are useful when building a
- boot image.
-
- ld
- Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
-
- Example::
-
- #arch/x86/boot/Makefile
- LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
- LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
-
- targets += setup setup.o bootsect bootsect.o
- $(obj)/setup $(obj)/bootsect: %: %.o FORCE
- $(call if_changed,ld)
-
- In this example, there are two possible targets, requiring different
- options to the linker. The linker options are specified using the
- LDFLAGS_$@ syntax - one for each potential target.
- $(targets) are assigned all potential targets, by which kbuild knows
- the targets and will:
-
- 1) check for commandline changes
- 2) delete target during make clean
-
- The ": %: %.o" part of the prerequisite is a shorthand that
- frees us from listing the setup.o and bootsect.o files.
-
- Note:
- It is a common mistake to forget the "targets :=" assignment,
- resulting in the target file being recompiled for no
- obvious reason.
-
- objcopy
- Copy binary. Uses OBJCOPYFLAGS usually specified in
- arch/$(SRCARCH)/Makefile.
- OBJCOPYFLAGS_$@ may be used to set additional options.
-
- gzip
- Compress target. Use maximum compression to compress target.
-
- Example::
-
- #arch/x86/boot/compressed/Makefile
- $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,gzip)
-
- dtc
- Create flattened device tree blob object suitable for linking
- into vmlinux. Device tree blobs linked into vmlinux are placed
- in an init section in the image. Platform code *must* copy the
- blob to non-init memory prior to calling unflatten_device_tree().
-
- To use this command, simply add `*.dtb` into obj-y or targets, or make
- some other target depend on `%.dtb`
-
- A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`;
- architecture Makefiles do no need to explicitly write out that rule.
-
- Example::
-
- targets += $(dtb-y)
- DTC_FLAGS ?= -p 1024
-
-7.9 Preprocessing linker scripts
+Add prerequisites to archheaders
--------------------------------
- When the vmlinux image is built, the linker script
- arch/$(SRCARCH)/kernel/vmlinux.lds is used.
- The script is a preprocessed variant of the file vmlinux.lds.S
- located in the same directory.
- kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`.
+The archheaders: rule is used to generate header files that
+may be installed into user space by ``make header_install``.
- Example::
+It is run before ``make archprepare`` when run on the
+architecture itself.
- #arch/x86/kernel/Makefile
- extra-y := vmlinux.lds
+Add prerequisites to archprepare
+--------------------------------
- The assignment to extra-y is used to tell kbuild to build the
- target vmlinux.lds.
- The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
- specified options when building the target vmlinux.lds.
+The archprepare: rule is used to list prerequisites that need to be
+built before starting to descend down in the subdirectories.
- When building the `*.lds` target, kbuild uses the variables::
+This is usually used for header files containing assembler constants.
- KBUILD_CPPFLAGS : Set in top-level Makefile
- cppflags-y : May be set in the kbuild makefile
- CPPFLAGS_$(@F) : Target-specific flags.
- Note that the full filename is used in this
- assignment.
+Example::
- The kbuild infrastructure for `*lds` files is used in several
- architecture-specific files.
+ #arch/arm/Makefile
+ archprepare: maketools
-7.10 Generic header files
--------------------------
+In this example, the file target maketools will be processed
+before descending down in the subdirectories.
- The directory include/asm-generic contains the header files
- that may be shared between individual architectures.
- The recommended approach how to use a generic header file is
- to list the file in the Kbuild file.
- See "8.2 generic-y" for further info on syntax etc.
+See also chapter XXX-TODO that describes how kbuild supports
+generating offset header files.
-7.11 Post-link pass
--------------------
+List directories to visit when descending
+-----------------------------------------
- If the file arch/xxx/Makefile.postlink exists, this makefile
- will be invoked for post-link objects (vmlinux and modules.ko)
- for architectures to run post-link passes on. Must also handle
- the clean target.
+An arch Makefile cooperates with the top Makefile to define variables
+which specify how to build the vmlinux file. Note that there is no
+corresponding arch-specific section for modules; the module-building
+machinery is all architecture-independent.
- This pass runs after kallsyms generation. If the architecture
- needs to modify symbol locations, rather than manipulate the
- kallsyms, it may be easier to add another postlink target for
- .tmp_vmlinux? targets to be called from link-vmlinux.sh.
+core-y, libs-y, drivers-y
+ $(libs-y) lists directories where a lib.a archive can be located.
- For example, powerpc uses this to check relocation sanity of
- the linked vmlinux file.
+ The rest list directories where a built-in.a object file can be
+ located.
-8 Kbuild syntax for exported headers
-------------------------------------
+ Then the rest follows in this order:
+
+ $(core-y), $(libs-y), $(drivers-y)
+
+ The top level Makefile defines values for all generic directories,
+ and arch/$(SRCARCH)/Makefile only adds architecture-specific
+ directories.
+
+ Example::
+
+ # arch/sparc/Makefile
+ core-y += arch/sparc/
+
+ libs-y += arch/sparc/prom/
+ libs-y += arch/sparc/lib/
+
+ drivers-$(CONFIG_PM) += arch/sparc/power/
+
+Architecture-specific boot images
+---------------------------------
+
+An arch Makefile specifies goals that take the vmlinux file, compress
+it, wrap it in bootstrapping code, and copy the resulting files
+somewhere. This includes various kinds of installation commands.
+The actual goals are not standardized across architectures.
+
+It is common to locate any additional processing in a boot/
+directory below arch/$(SRCARCH)/.
+
+Kbuild does not provide any smart way to support building a
+target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall
+call make manually to build a target in boot/.
+
+The recommended approach is to include shortcuts in
+arch/$(SRCARCH)/Makefile, and use the full path when calling down
+into the arch/$(SRCARCH)/boot/Makefile.
+
+Example::
+
+ #arch/x86/Makefile
+ boot := arch/x86/boot
+ bzImage: vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+
+``$(Q)$(MAKE) $(build)=<dir>`` is the recommended way to invoke
+make in a subdirectory.
+
+There are no rules for naming architecture-specific targets,
+but executing ``make help`` will list all relevant targets.
+To support this, $(archhelp) must be defined.
+
+Example::
+
+ #arch/x86/Makefile
+ define archhelp
+ echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
+ endif
+
+When make is executed without arguments, the first goal encountered
+will be built. In the top level Makefile the first goal present
+is all:.
+
+An architecture shall always, per default, build a bootable image.
+In ``make help``, the default goal is highlighted with a ``*``.
+
+Add a new prerequisite to all: to select a default goal different
+from vmlinux.
+
+Example::
+
+ #arch/x86/Makefile
+ all: bzImage
+
+When ``make`` is executed without arguments, bzImage will be built.
+
+Commands useful for building a boot image
+-----------------------------------------
+
+Kbuild provides a few macros that are useful when building a
+boot image.
+
+ld
+ Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
+
+ Example::
+
+ #arch/x86/boot/Makefile
+ LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
+ LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
+
+ targets += setup setup.o bootsect bootsect.o
+ $(obj)/setup $(obj)/bootsect: %: %.o FORCE
+ $(call if_changed,ld)
+
+ In this example, there are two possible targets, requiring different
+ options to the linker. The linker options are specified using the
+ LDFLAGS_$@ syntax - one for each potential target.
+
+ $(targets) are assigned all potential targets, by which kbuild knows
+ the targets and will:
+
+ 1) check for commandline changes
+ 2) delete target during make clean
+
+ The ``: %: %.o`` part of the prerequisite is a shorthand that
+ frees us from listing the setup.o and bootsect.o files.
+
+ Note:
+ It is a common mistake to forget the ``targets :=`` assignment,
+ resulting in the target file being recompiled for no
+ obvious reason.
+
+objcopy
+ Copy binary. Uses OBJCOPYFLAGS usually specified in
+ arch/$(SRCARCH)/Makefile.
+
+ OBJCOPYFLAGS_$@ may be used to set additional options.
+
+gzip
+ Compress target. Use maximum compression to compress target.
+
+ Example::
+
+ #arch/x86/boot/compressed/Makefile
+ $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
+ $(call if_changed,gzip)
+
+dtc
+ Create flattened device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ To use this command, simply add ``*.dtb`` into obj-y or targets, or make
+ some other target depend on ``%.dtb``
+
+ A central rule exists to create ``$(obj)/%.dtb`` from ``$(src)/%.dts``;
+ architecture Makefiles do no need to explicitly write out that rule.
+
+ Example::
+
+ targets += $(dtb-y)
+ DTC_FLAGS ?= -p 1024
+
+Preprocessing linker scripts
+----------------------------
+
+When the vmlinux image is built, the linker script
+arch/$(SRCARCH)/kernel/vmlinux.lds is used.
+
+The script is a preprocessed variant of the file vmlinux.lds.S
+located in the same directory.
+
+kbuild knows .lds files and includes a rule ``*lds.S`` -> ``*lds``.
+
+Example::
+
+ #arch/x86/kernel/Makefile
+ extra-y := vmlinux.lds
+
+The assignment to extra-y is used to tell kbuild to build the
+target vmlinux.lds.
+
+The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
+specified options when building the target vmlinux.lds.
+
+When building the ``*.lds`` target, kbuild uses the variables::
+
+ KBUILD_CPPFLAGS : Set in top-level Makefile
+ cppflags-y : May be set in the kbuild makefile
+ CPPFLAGS_$(@F) : Target-specific flags.
+ Note that the full filename is used in this
+ assignment.
+
+The kbuild infrastructure for ``*lds`` files is used in several
+architecture-specific files.
+
+Generic header files
+--------------------
+
+The directory include/asm-generic contains the header files
+that may be shared between individual architectures.
+
+The recommended approach how to use a generic header file is
+to list the file in the Kbuild file.
+
+See `generic-y`_ for further info on syntax etc.
+
+Post-link pass
+--------------
+
+If the file arch/xxx/Makefile.postlink exists, this makefile
+will be invoked for post-link objects (vmlinux and modules.ko)
+for architectures to run post-link passes on. Must also handle
+the clean target.
+
+This pass runs after kallsyms generation. If the architecture
+needs to modify symbol locations, rather than manipulate the
+kallsyms, it may be easier to add another postlink target for
+.tmp_vmlinux? targets to be called from link-vmlinux.sh.
+
+For example, powerpc uses this to check relocation sanity of
+the linked vmlinux file.
+
+Kbuild syntax for exported headers
+==================================
The kernel includes a set of headers that is exported to userspace.
Many headers can be exported as-is but other headers require a
minimal pre-processing before they are ready for user-space.
+
The pre-processing does:
- drop kernel-specific annotations
- drop include of compiler.h
-- drop all sections that are kernel internal (guarded by `ifdef __KERNEL__`)
+- drop all sections that are kernel internal (guarded by ``ifdef __KERNEL__``)
All headers under include/uapi/, include/generated/uapi/,
arch/<arch>/include/uapi/ and arch/<arch>/include/generated/uapi/
@@ -1526,139 +1492,139 @@
A Kbuild file may be defined under arch/<arch>/include/uapi/asm/ and
arch/<arch>/include/asm/ to list asm files coming from asm-generic.
+
See subsequent chapter for the syntax of the Kbuild file.
-8.1 no-export-headers
----------------------
+no-export-headers
+-----------------
- no-export-headers is essentially used by include/uapi/linux/Kbuild to
- avoid exporting specific headers (e.g. kvm.h) on architectures that do
- not support it. It should be avoided as much as possible.
+no-export-headers is essentially used by include/uapi/linux/Kbuild to
+avoid exporting specific headers (e.g. kvm.h) on architectures that do
+not support it. It should be avoided as much as possible.
-8.2 generic-y
--------------
+generic-y
+---------
- If an architecture uses a verbatim copy of a header from
- include/asm-generic then this is listed in the file
- arch/$(SRCARCH)/include/asm/Kbuild like this:
+If an architecture uses a verbatim copy of a header from
+include/asm-generic then this is listed in the file
+arch/$(SRCARCH)/include/asm/Kbuild like this:
- Example::
+Example::
- #arch/x86/include/asm/Kbuild
- generic-y += termios.h
- generic-y += rtc.h
+ #arch/x86/include/asm/Kbuild
+ generic-y += termios.h
+ generic-y += rtc.h
- During the prepare phase of the build a wrapper include
- file is generated in the directory::
+During the prepare phase of the build a wrapper include
+file is generated in the directory::
- arch/$(SRCARCH)/include/generated/asm
+ arch/$(SRCARCH)/include/generated/asm
- When a header is exported where the architecture uses
- the generic header a similar wrapper is generated as part
- of the set of exported headers in the directory::
+When a header is exported where the architecture uses
+the generic header a similar wrapper is generated as part
+of the set of exported headers in the directory::
- usr/include/asm
+ usr/include/asm
- The generated wrapper will in both cases look like the following:
+The generated wrapper will in both cases look like the following:
- Example: termios.h::
+Example: termios.h::
- #include <asm-generic/termios.h>
+ #include <asm-generic/termios.h>
-8.3 generated-y
----------------
+generated-y
+-----------
- If an architecture generates other header files alongside generic-y
- wrappers, generated-y specifies them.
+If an architecture generates other header files alongside generic-y
+wrappers, generated-y specifies them.
- This prevents them being treated as stale asm-generic wrappers and
- removed.
+This prevents them being treated as stale asm-generic wrappers and
+removed.
- Example::
+Example::
- #arch/x86/include/asm/Kbuild
- generated-y += syscalls_32.h
+ #arch/x86/include/asm/Kbuild
+ generated-y += syscalls_32.h
-8.4 mandatory-y
----------------
+mandatory-y
+-----------
- mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild
- to define the minimum set of ASM headers that all architectures must have.
+mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild
+to define the minimum set of ASM headers that all architectures must have.
- This works like optional generic-y. If a mandatory header is missing
- in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically
- generate a wrapper of the asm-generic one.
+This works like optional generic-y. If a mandatory header is missing
+in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically
+generate a wrapper of the asm-generic one.
-9 Kbuild Variables
-==================
+Kbuild Variables
+================
The top Makefile exports the following variables:
- VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
- These variables define the current kernel version. A few arch
- Makefiles actually use these values directly; they should use
- $(KERNELRELEASE) instead.
+VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
+ These variables define the current kernel version. A few arch
+ Makefiles actually use these values directly; they should use
+ $(KERNELRELEASE) instead.
- $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic
- three-part version number, such as "2", "4", and "0". These three
- values are always numeric.
+ $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic
+ three-part version number, such as "2", "4", and "0". These three
+ values are always numeric.
- $(EXTRAVERSION) defines an even tinier sublevel for pre-patches
- or additional patches. It is usually some non-numeric string
- such as "-pre4", and is often blank.
+ $(EXTRAVERSION) defines an even tinier sublevel for pre-patches
+ or additional patches. It is usually some non-numeric string
+ such as "-pre4", and is often blank.
- KERNELRELEASE
- $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable
- for constructing installation directory names or showing in
- version strings. Some arch Makefiles use it for this purpose.
+KERNELRELEASE
+ $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable
+ for constructing installation directory names or showing in
+ version strings. Some arch Makefiles use it for this purpose.
- ARCH
- This variable defines the target architecture, such as "i386",
- "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to
- determine which files to compile.
+ARCH
+ This variable defines the target architecture, such as "i386",
+ "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to
+ determine which files to compile.
- By default, the top Makefile sets $(ARCH) to be the same as the
- host system architecture. For a cross build, a user may
- override the value of $(ARCH) on the command line::
+ By default, the top Makefile sets $(ARCH) to be the same as the
+ host system architecture. For a cross build, a user may
+ override the value of $(ARCH) on the command line::
- make ARCH=m68k ...
+ make ARCH=m68k ...
- SRCARCH
- This variable specifies the directory in arch/ to build.
+SRCARCH
+ This variable specifies the directory in arch/ to build.
- ARCH and SRCARCH may not necessarily match. A couple of arch
- directories are biarch, that is, a single `arch/*/` directory supports
- both 32-bit and 64-bit.
+ ARCH and SRCARCH may not necessarily match. A couple of arch
+ directories are biarch, that is, a single ``arch/*/`` directory supports
+ both 32-bit and 64-bit.
- For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86.
- For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and
- x86_64.
+ For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86.
+ For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and
+ x86_64.
- INSTALL_PATH
- This variable defines a place for the arch Makefiles to install
- the resident kernel image and System.map file.
- Use this for architecture-specific install targets.
+INSTALL_PATH
+ This variable defines a place for the arch Makefiles to install
+ the resident kernel image and System.map file.
+ Use this for architecture-specific install targets.
- INSTALL_MOD_PATH, MODLIB
- $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module
- installation. This variable is not defined in the Makefile but
- may be passed in by the user if desired.
+INSTALL_MOD_PATH, MODLIB
+ $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module
+ installation. This variable is not defined in the Makefile but
+ may be passed in by the user if desired.
- $(MODLIB) specifies the directory for module installation.
- The top Makefile defines $(MODLIB) to
- $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may
- override this value on the command line if desired.
+ $(MODLIB) specifies the directory for module installation.
+ The top Makefile defines $(MODLIB) to
+ $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may
+ override this value on the command line if desired.
- INSTALL_MOD_STRIP
- If this variable is specified, it will cause modules to be stripped
- after they are installed. If INSTALL_MOD_STRIP is '1', then the
- default option --strip-debug will be used. Otherwise, the
- INSTALL_MOD_STRIP value will be used as the option(s) to the strip
- command.
+INSTALL_MOD_STRIP
+ If this variable is specified, it will cause modules to be stripped
+ after they are installed. If INSTALL_MOD_STRIP is "1", then the
+ default option --strip-debug will be used. Otherwise, the
+ INSTALL_MOD_STRIP value will be used as the option(s) to the strip
+ command.
-
-10 Makefile language
-====================
+Makefile language
+=================
The kernel Makefiles are designed to be run with GNU Make. The Makefiles
use only the documented features of GNU Make, but they do use many
@@ -1666,27 +1632,27 @@
GNU Make supports elementary list-processing functions. The kernel
Makefiles use a novel style of list building and manipulation with few
-"if" statements.
+``if`` statements.
-GNU Make has two assignment operators, ":=" and "=". ":=" performs
+GNU Make has two assignment operators, ``:=`` and ``=``. ``:=`` performs
immediate evaluation of the right-hand side and stores an actual string
-into the left-hand side. "=" is like a formula definition; it stores the
+into the left-hand side. ``=`` is like a formula definition; it stores the
right-hand side in an unevaluated form and then evaluates this form each
time the left-hand side is used.
-There are some cases where "=" is appropriate. Usually, though, ":="
+There are some cases where ``=`` is appropriate. Usually, though, ``:=``
is the right choice.
-11 Credits
-==========
+Credits
+=======
- Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
- Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
- Updates by Sam Ravnborg <sam@ravnborg.org>
- Language QA by Jan Engelhardt <jengelh@gmx.de>
-12 TODO
-=======
+TODO
+====
- Describe how kbuild supports shipped files with _shipped.
- Generating offset header files.
diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index c756786..dff0646 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -1277,11 +1277,11 @@
is very occasionally accessed in user context or softirqs/tasklets. The
irq handler doesn't use a lock, and all other accesses are done as so::
- spin_lock(&lock);
+ mutex_lock(&lock);
disable_irq(irq);
...
enable_irq(irq);
- spin_unlock(&lock);
+ mutex_unlock(&lock);
The disable_irq() prevents the irq handler from running
(and waits for it to finish if it's currently running on other CPUs).
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index e5d63b9..b9ca081 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -26,3 +26,4 @@
leds-lp55xx
leds-mlxcpld
leds-sc27xx
+ leds-qcom-lpg
diff --git a/Documentation/leds/leds-qcom-lpg.rst b/Documentation/leds/leds-qcom-lpg.rst
index de7ceea..d6a76c3 100644
--- a/Documentation/leds/leds-qcom-lpg.rst
+++ b/Documentation/leds/leds-qcom-lpg.rst
@@ -34,7 +34,7 @@
The pattern is a series of brightness and hold-time pairs, with the hold-time
expressed in milliseconds. The hold time is a property of the pattern and must
-therefor be identical for each element in the pattern (except for the pauses
+therefore be identical for each element in the pattern (except for the pauses
described below). As the LPG hardware is not able to perform the linear
transitions expected by the leds-trigger-pattern format, each entry in the
pattern must be followed a zero-length entry of the same brightness.
@@ -66,7 +66,7 @@
+----------------------------->
0 5 10 15 20 25 time (100ms)
-Similarily, the last entry can be stretched by using a higher hold-time on the
+Similarly, the last entry can be stretched by using a higher hold-time on the
last entry.
In order to save space in the shared lookup table the LPG supports "ping-pong"
diff --git a/Documentation/livepatch/module-elf-format.rst b/Documentation/livepatch/module-elf-format.rst
index 7347638..d48f530 100644
--- a/Documentation/livepatch/module-elf-format.rst
+++ b/Documentation/livepatch/module-elf-format.rst
@@ -298,12 +298,5 @@
Since apply_relocate_add() requires access to a module's section headers,
symbol table, and relocation section indices, Elf information is preserved for
livepatch modules and is made accessible by the module loader through
-module->klp_info, which is a klp_modinfo struct. When a livepatch module loads,
-this struct is filled in by the module loader. Its fields are documented below::
-
- struct klp_modinfo {
- Elf_Ehdr hdr; /* Elf header */
- Elf_Shdr *sechdrs; /* Section header table */
- char *secstrings; /* String table for the section headers */
- unsigned int symndx; /* The symbol table section index */
- };
+module->klp_info, which is a :c:type:`klp_modinfo` struct. When a livepatch module
+loads, this struct is filled in by the module loader.
diff --git a/Documentation/locking/locktorture.rst b/Documentation/locking/locktorture.rst
index dfaf9fc..7f56fc0 100644
--- a/Documentation/locking/locktorture.rst
+++ b/Documentation/locking/locktorture.rst
@@ -5,7 +5,7 @@
CONFIG_LOCK_TORTURE_TEST
========================
-The CONFIG LOCK_TORTURE_TEST config option provides a kernel module
+The CONFIG_LOCK_TORTURE_TEST config option provides a kernel module
that runs torture tests on core kernel locking primitives. The kernel
module, 'locktorture', may be built after the fact on the running
kernel to be tested, if desired. The tests periodically output status
@@ -67,7 +67,7 @@
- "rtmutex_lock":
rtmutex_lock() and rtmutex_unlock() pairs.
- Kernel must have CONFIG_RT_MUTEX=y.
+ Kernel must have CONFIG_RT_MUTEXES=y.
- "rwsem_lock":
read/write down() and up() semaphore pairs.
diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst
index 09f988e..85800ce 100644
--- a/Documentation/maintainer/rebasing-and-merging.rst
+++ b/Documentation/maintainer/rebasing-and-merging.rst
@@ -213,11 +213,7 @@
emptied entirely into the mainline during the merge window, you can pull it
forward with a command like::
- git merge v5.2-rc1^0
-
-The "^0" will cause Git to do a fast-forward merge (which should be
-possible in this situation), thus avoiding the addition of a spurious merge
-commit.
+ git merge --ff-only v5.2-rc1
The guidelines laid out above are just that: guidelines. There will always
be situations that call out for a different solution, and these guidelines
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index cc621de..06e14ef 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1910,7 +1910,8 @@
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
- DMA capable device.
+ DMA capable device. See Documentation/core-api/dma-api.rst file for more
+ information about consistent memory.
For example, consider a device driver that shares memory with a device
and uses a descriptor status value to indicate if the descriptor belongs
@@ -1931,22 +1932,21 @@
/* assign ownership */
desc->status = DEVICE_OWN;
- /* notify device of new descriptors */
+ /* Make descriptor status visible to the device followed by
+ * notify device of new descriptor
+ */
writel(DESC_NOTIFY, doorbell);
}
- The dma_rmb() allows us guarantee the device has released ownership
+ The dma_rmb() allows us to guarantee that the device has released ownership
before we read the data from the descriptor, and the dma_wmb() allows
us to guarantee the data is written to the descriptor before the device
can see it now has ownership. The dma_mb() implies both a dma_rmb() and
- a dma_wmb(). Note that, when using writel(), a prior wmb() is not needed
- to guarantee that the cache coherent memory writes have completed before
- writing to the MMIO region. The cheaper writel_relaxed() does not provide
- this guarantee and must not be used here.
+ a dma_wmb().
- See the subsection "Kernel I/O barrier effects" for more information on
- relaxed I/O accessors and the Documentation/core-api/dma-api.rst file for
- more information on consistent memory.
+ Note that the dma_*() barriers do not provide any ordering guarantees for
+ accesses to MMIO regions. See the later "KERNEL I/O BARRIER EFFECTS"
+ subsection for more information about I/O accessors and MMIO ordering.
(*) pmem_wmb();
diff --git a/Documentation/mm/active_mm.rst b/Documentation/mm/active_mm.rst
index 6f8269c..45d89f8 100644
--- a/Documentation/mm/active_mm.rst
+++ b/Documentation/mm/active_mm.rst
@@ -1,5 +1,3 @@
-.. _active_mm:
-
=========
Active MM
=========
diff --git a/Documentation/mm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst
index fd2a19d..30d9a09 100644
--- a/Documentation/mm/arch_pgtable_helpers.rst
+++ b/Documentation/mm/arch_pgtable_helpers.rst
@@ -1,7 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _arch_page_table_helpers:
-
===============================
Architecture Page Table Helpers
===============================
diff --git a/Documentation/mm/balance.rst b/Documentation/mm/balance.rst
index 6a1fadf..abaa785 100644
--- a/Documentation/mm/balance.rst
+++ b/Documentation/mm/balance.rst
@@ -1,12 +1,10 @@
-.. _balance:
-
================
Memory Balancing
================
Started Jan 2000 by Kanoj Sarcar <kanoj@sgi.com>
-Memory balancing is needed for !__GFP_ATOMIC and !__GFP_KSWAPD_RECLAIM as
+Memory balancing is needed for !__GFP_HIGH and !__GFP_KSWAPD_RECLAIM as
well as for non __GFP_IO allocations.
The first reason why a caller may avoid reclaim is that the caller can not
diff --git a/Documentation/mm/damon/index.rst b/Documentation/mm/damon/index.rst
index 48c0bbf..5e0a505 100644
--- a/Documentation/mm/damon/index.rst
+++ b/Documentation/mm/damon/index.rst
@@ -4,8 +4,9 @@
DAMON: Data Access MONitor
==========================
-DAMON is a data access monitoring framework subsystem for the Linux kernel.
-The core mechanisms of DAMON (refer to :doc:`design` for the detail) make it
+DAMON is a Linux kernel subsystem that provides a framework for data access
+monitoring and the monitoring results based system operations. The core
+monitoring mechanisms of DAMON (refer to :doc:`design` for the detail) make it
- *accurate* (the monitoring output is useful enough for DRAM level memory
management; It might not appropriate for CPU Cache levels, though),
@@ -14,12 +15,16 @@
- *scalable* (the upper-bound of the overhead is in constant range regardless
of the size of target workloads).
-Using this framework, therefore, the kernel's memory management mechanisms can
-make advanced decisions. Experimental memory management optimization works
-that incurring high data accesses monitoring overhead could implemented again.
-In user space, meanwhile, users who have some special workloads can write
-personalized applications for better understanding and optimizations of their
-workloads and systems.
+Using this framework, therefore, the kernel can operate system in an
+access-aware fashion. Because the features are also exposed to the user space,
+users who have special information about their workloads can write personalized
+applications for better understanding and optimizations of their workloads and
+systems.
+
+For easier development of such systems, DAMON provides a feature called DAMOS
+(DAMon-based Operation Schemes) in addition to the monitoring. Using the
+feature, DAMON users in both kernel and user spaces can do access-aware system
+operations with no code but simple configurations.
.. toctree::
:maxdepth: 2
@@ -27,3 +32,4 @@
faq
design
api
+ maintainer-profile
diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
new file mode 100644
index 0000000..24a202f
--- /dev/null
+++ b/Documentation/mm/damon/maintainer-profile.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+DAMON Maintainer Entry Profile
+==============================
+
+The DAMON subsystem covers the files that listed in 'DATA ACCESS MONITOR'
+section of 'MAINTAINERS' file.
+
+The mailing lists for the subsystem are damon@lists.linux.dev and
+linux-mm@kvack.org. Patches should be made against the mm-unstable tree [1]_
+whenever possible and posted to the mailing lists.
+
+SCM Trees
+---------
+
+There are multiple Linux trees for DAMON development. Patches under
+development or testing are queued in damon/next [2]_ by the DAMON maintainer.
+Suffieicntly reviewed patches will be queued in mm-unstable [1]_ by the memory
+management subsystem maintainer. After more sufficient tests, the patches will
+be queued in mm-stable [3]_ , and finally pull-requested to the mainline by the
+memory management subsystem maintainer.
+
+Note again the patches for review should be made against the mm-unstable
+tree[1] whenever possible. damon/next is only for preview of others' works in
+progress.
+
+Submit checklist addendum
+-------------------------
+
+When making DAMON changes, you should do below.
+
+- Build changes related outputs including kernel and documents.
+- Ensure the builds introduce no new errors or warnings.
+- Run and ensure no new failures for DAMON selftests [4]_ and kunittests [5]_ .
+
+Further doing below and putting the results will be helpful.
+
+- Run damon-tests/corr [6]_ for normal changes.
+- Run damon-tests/perf [7]_ for performance changes.
+
+Key cycle dates
+---------------
+
+Patches can be sent anytime. Key cycle dates of the mm-unstable[1] and
+mm-stable[3] trees depend on the memory management subsystem maintainer.
+
+Review cadence
+--------------
+
+The DAMON maintainer does the work on the usual work hour (09:00 to 17:00,
+Mon-Fri) in PST. The response to patches will occasionally be slow. Do not
+hesitate to send a ping if you have not heard back within a week of sending a
+patch.
+
+
+.. [1] https://git.kernel.org/akpm/mm/h/mm-unstable
+.. [2] https://git.kernel.org/sj/h/damon/next
+.. [3] https://git.kernel.org/akpm/mm/h/mm-stable
+.. [4] https://github.com/awslabs/damon-tests/blob/master/corr/run.sh#L49
+.. [5] https://github.com/awslabs/damon-tests/blob/master/corr/tests/kunit.sh
+.. [6] https://github.com/awslabs/damon-tests/tree/master/corr
+.. [7] https://github.com/awslabs/damon-tests/tree/master/perf
diff --git a/Documentation/mm/free_page_reporting.rst b/Documentation/mm/free_page_reporting.rst
index 8c05e62..1468f71 100644
--- a/Documentation/mm/free_page_reporting.rst
+++ b/Documentation/mm/free_page_reporting.rst
@@ -1,5 +1,3 @@
-.. _free_page_reporting:
-
=====================
Free Page Reporting
=====================
diff --git a/Documentation/mm/frontswap.rst b/Documentation/mm/frontswap.rst
index feecc5e..c892412 100644
--- a/Documentation/mm/frontswap.rst
+++ b/Documentation/mm/frontswap.rst
@@ -1,5 +1,3 @@
-.. _frontswap:
-
=========
Frontswap
=========
diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
index 0f731d9..c964e08 100644
--- a/Documentation/mm/highmem.rst
+++ b/Documentation/mm/highmem.rst
@@ -1,5 +1,3 @@
-.. _highmem:
-
====================
High Memory Handling
====================
@@ -57,7 +55,8 @@
It can be invoked from any context (including interrupts) but the mappings
can only be used in the context which acquired them.
- This function should be preferred, where feasible, over all the others.
+ This function should always be used, whereas kmap_atomic() and kmap() have
+ been deprecated.
These mappings are thread-local and CPU-local, meaning that the mapping
can only be accessed from within this thread and the thread is bound to the
@@ -82,7 +81,7 @@
for pages which are known to not come from ZONE_HIGHMEM. However, it is
always safe to use kmap_local_page() / kunmap_local().
- While it is significantly faster than kmap(), for the higmem case it
+ While it is significantly faster than kmap(), for the highmem case it
comes with restrictions about the pointers validity. Contrary to kmap()
mappings, the local mappings are only valid in the context of the caller
and cannot be handed to other contexts. This implies that users must
@@ -100,10 +99,21 @@
(included in the "Functions" section) for details on how to manage nested
mappings.
-* kmap_atomic(). This permits a very short duration mapping of a single
- page. Since the mapping is restricted to the CPU that issued it, it
- performs well, but the issuing task is therefore required to stay on that
- CPU until it has finished, lest some other task displace its mappings.
+* kmap_atomic(). This function has been deprecated; use kmap_local_page().
+
+ NOTE: Conversions to kmap_local_page() must take care to follow the mapping
+ restrictions imposed on kmap_local_page(). Furthermore, the code between
+ calls to kmap_atomic() and kunmap_atomic() may implicitly depend on the side
+ effects of atomic mappings, i.e. disabling page faults or preemption, or both.
+ In that case, explicit calls to pagefault_disable() or preempt_disable() or
+ both must be made in conjunction with the use of kmap_local_page().
+
+ [Legacy documentation]
+
+ This permits a very short duration mapping of a single page. Since the
+ mapping is restricted to the CPU that issued it, it performs well, but
+ the issuing task is therefore required to stay on that CPU until it has
+ finished, lest some other task displace its mappings.
kmap_atomic() may also be used by interrupt contexts, since it does not
sleep and the callers too may not sleep until after kunmap_atomic() is
@@ -115,11 +125,20 @@
It is assumed that k[un]map_atomic() won't fail.
-* kmap(). This should be used to make short duration mapping of a single
- page with no restrictions on preemption or migration. It comes with an
- overhead as mapping space is restricted and protected by a global lock
- for synchronization. When mapping is no longer needed, the address that
- the page was mapped to must be released with kunmap().
+* kmap(). This function has been deprecated; use kmap_local_page().
+
+ NOTE: Conversions to kmap_local_page() must take care to follow the mapping
+ restrictions imposed on kmap_local_page(). In particular, it is necessary to
+ make sure that the kernel virtual memory pointer is only valid in the thread
+ that obtained it.
+
+ [Legacy documentation]
+
+ This should be used to make short duration mapping of a single page with no
+ restrictions on preemption or migration. It comes with an overhead as mapping
+ space is restricted and protected by a global lock for synchronization. When
+ mapping is no longer needed, the address that the page was mapped to must be
+ released with kunmap().
Mapping changes must be propagated across all the CPUs. kmap() also
requires global TLB invalidation when the kmap's pool wraps and it might
diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst
index f2a59ed..9aa512c 100644
--- a/Documentation/mm/hmm.rst
+++ b/Documentation/mm/hmm.rst
@@ -1,5 +1,3 @@
-.. _hmm:
-
=====================================
Heterogeneous Memory Management (HMM)
=====================================
@@ -304,7 +302,7 @@
be tied to a ``struct device``.
The overall migration steps are similar to migrating NUMA pages within system
-memory (see :ref:`Page migration <page_migration>`) but the steps are split
+memory (see Documentation/mm/page_migration.rst) but the steps are split
between device driver specific code and shared common code:
1. ``mmap_read_lock()``
diff --git a/Documentation/mm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst
index f143954..d9c2b0f 100644
--- a/Documentation/mm/hugetlbfs_reserv.rst
+++ b/Documentation/mm/hugetlbfs_reserv.rst
@@ -1,5 +1,3 @@
-.. _hugetlbfs_reserve:
-
=====================
Hugetlbfs Reservation
=====================
@@ -7,10 +5,10 @@
Overview
========
-Huge pages as described at :ref:`hugetlbpage` are typically
-preallocated for application use. These huge pages are instantiated in a
-task's address space at page fault time if the VMA indicates huge pages are
-to be used. If no huge page exists at page fault time, the task is sent
+Huge pages as described at Documentation/admin-guide/mm/hugetlbpage.rst are
+typically preallocated for application use. These huge pages are instantiated
+in a task's address space at page fault time if the VMA indicates huge pages
+are to be used. If no huge page exists at page fault time, the task is sent
a SIGBUS and often dies an unhappy death. Shortly after huge page support
was added, it was determined that it would be better to detect a shortage
of huge pages at mmap() time. The idea is that if there were not enough
@@ -181,14 +179,14 @@
Reservations are consumed when huge pages associated with the reservations
are allocated and instantiated in the corresponding mapping. The allocation
-is performed within the routine alloc_huge_page()::
+is performed within the routine alloc_hugetlb_folio()::
- struct page *alloc_huge_page(struct vm_area_struct *vma,
+ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve)
-alloc_huge_page is passed a VMA pointer and a virtual address, so it can
+alloc_hugetlb_folio is passed a VMA pointer and a virtual address, so it can
consult the reservation map to determine if a reservation exists. In addition,
-alloc_huge_page takes the argument avoid_reserve which indicates reserves
+alloc_hugetlb_folio takes the argument avoid_reserve which indicates reserves
should not be used even if it appears they have been set aside for the
specified address. The avoid_reserve argument is most often used in the case
of Copy on Write and Page Migration where additional copies of an existing
@@ -208,7 +206,8 @@
exists and can be used for the allocation, the routine dequeue_huge_page_vma()
is called. This routine takes two arguments related to reservations:
-- avoid_reserve, this is the same value/argument passed to alloc_huge_page()
+- avoid_reserve, this is the same value/argument passed to
+ alloc_hugetlb_folio().
- chg, even though this argument is of type long only the values 0 or 1 are
passed to dequeue_huge_page_vma. If the value is 0, it indicates a
reservation exists (see the section "Memory Policy and Reservations" for
@@ -233,9 +232,9 @@
reservation based adjustments as above will be made: SetPagePrivate(page) and
resv_huge_pages--.
-After obtaining a new huge page, (page)->private is set to the value of
-the subpool associated with the page if it exists. This will be used for
-subpool accounting when the page is freed.
+After obtaining a new hugetlb folio, (folio)->_hugetlb_subpool is set to the
+value of the subpool associated with the page if it exists. This will be used
+for subpool accounting when the folio is freed.
The routine vma_commit_reservation() is then called to adjust the reserve
map based on the consumption of the reservation. In general, this involves
@@ -246,8 +245,8 @@
entry must be created.
It is possible that the reserve map could have been changed between the call
-to vma_needs_reservation() at the beginning of alloc_huge_page() and the
-call to vma_commit_reservation() after the page was allocated. This would
+to vma_needs_reservation() at the beginning of alloc_hugetlb_folio() and the
+call to vma_commit_reservation() after the folio was allocated. This would
be possible if hugetlb_reserve_pages was called for the same page in a shared
mapping. In such cases, the reservation count and subpool free page count
will be off by one. This rare condition can be identified by comparing the
diff --git a/Documentation/mm/hwpoison.rst b/Documentation/mm/hwpoison.rst
index b9d5253..ba48a44 100644
--- a/Documentation/mm/hwpoison.rst
+++ b/Documentation/mm/hwpoison.rst
@@ -1,5 +1,3 @@
-.. hwpoison:
-
========
hwpoison
========
diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
index 4aa12b8..5a94a92 100644
--- a/Documentation/mm/index.rst
+++ b/Documentation/mm/index.rst
@@ -1,6 +1,6 @@
-=====================================
-Linux Memory Management Documentation
-=====================================
+===============================
+Memory Management Documentation
+===============================
Memory Management Guide
=======================
diff --git a/Documentation/mm/ksm.rst b/Documentation/mm/ksm.rst
index f83cfbc..2806e3e 100644
--- a/Documentation/mm/ksm.rst
+++ b/Documentation/mm/ksm.rst
@@ -1,5 +1,3 @@
-.. _ksm:
-
=======================
Kernel Samepage Merging
=======================
@@ -8,7 +6,7 @@
added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation,
and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/
-The userspace interface of KSM is described in :ref:`Documentation/admin-guide/mm/ksm.rst <admin_guide_ksm>`
+The userspace interface of KSM is described in Documentation/admin-guide/mm/ksm.rst
Design
======
diff --git a/Documentation/mm/memory-model.rst b/Documentation/mm/memory-model.rst
index 3779e562d..5f3eafb 100644
--- a/Documentation/mm/memory-model.rst
+++ b/Documentation/mm/memory-model.rst
@@ -1,7 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _physical_memory_model:
-
=====================
Physical Memory Model
=====================
diff --git a/Documentation/mm/mmu_notifier.rst b/Documentation/mm/mmu_notifier.rst
index df5d777..c687bea 100644
--- a/Documentation/mm/mmu_notifier.rst
+++ b/Documentation/mm/mmu_notifier.rst
@@ -1,5 +1,3 @@
-.. _mmu_notifier:
-
When do you need to notify inside page table lock ?
===================================================
diff --git a/Documentation/mm/multigen_lru.rst b/Documentation/mm/multigen_lru.rst
index d7062c6..5f1f6ec 100644
--- a/Documentation/mm/multigen_lru.rst
+++ b/Documentation/mm/multigen_lru.rst
@@ -89,15 +89,15 @@
Generation numbers are truncated into ``order_base_2(MAX_NR_GENS+1)``
bits in order to fit into the gen counter in ``folio->flags``. Each
-truncated generation number is an index to ``lrugen->lists[]``. The
+truncated generation number is an index to ``lrugen->folios[]``. The
sliding window technique is used to track at least ``MIN_NR_GENS`` and
at most ``MAX_NR_GENS`` generations. The gen counter stores a value
within ``[1, MAX_NR_GENS]`` while a page is on one of
-``lrugen->lists[]``; otherwise it stores zero.
+``lrugen->folios[]``; otherwise it stores zero.
Each generation is divided into multiple tiers. A page accessed ``N``
times through file descriptors is in tier ``order_base_2(N)``. Unlike
-generations, tiers do not have dedicated ``lrugen->lists[]``. In
+generations, tiers do not have dedicated ``lrugen->folios[]``. In
contrast to moving across generations, which requires the LRU lock,
moving across tiers only involves atomic operations on
``folio->flags`` and therefore has a negligible cost. A feedback loop
@@ -127,7 +127,7 @@
Eviction
--------
The eviction consumes old generations. Given an ``lruvec``, it
-increments ``min_seq`` when ``lrugen->lists[]`` indexed by
+increments ``min_seq`` when ``lrugen->folios[]`` indexed by
``min_seq%MAX_NR_GENS`` becomes empty. To select a type and a tier to
evict from, it first compares ``min_seq[]`` to select the older type.
If both types are equally old, it selects the one whose first tier has
@@ -141,9 +141,85 @@
this end, the feedback loop uses the first tier as the baseline, for
the reason stated earlier.
+Working set protection
+----------------------
+Each generation is timestamped at birth. If ``lru_gen_min_ttl`` is
+set, an ``lruvec`` is protected from the eviction when its oldest
+generation was born within ``lru_gen_min_ttl`` milliseconds. In other
+words, it prevents the working set of ``lru_gen_min_ttl`` milliseconds
+from getting evicted. The OOM killer is triggered if this working set
+cannot be kept in memory.
+
+This time-based approach has the following advantages:
+
+1. It is easier to configure because it is agnostic to applications
+ and memory sizes.
+2. It is more reliable because it is directly wired to the OOM killer.
+
+Rmap/PT walk feedback
+---------------------
+Searching the rmap for PTEs mapping each page on an LRU list (to test
+and clear the accessed bit) can be expensive because pages from
+different VMAs (PA space) are not cache friendly to the rmap (VA
+space). For workloads mostly using mapped pages, searching the rmap
+can incur the highest CPU cost in the reclaim path.
+
+``lru_gen_look_around()`` exploits spatial locality to reduce the
+trips into the rmap. It scans the adjacent PTEs of a young PTE and
+promotes hot pages. If the scan was done cacheline efficiently, it
+adds the PMD entry pointing to the PTE table to the Bloom filter. This
+forms a feedback loop between the eviction and the aging.
+
+Bloom Filters
+-------------
+Bloom filters are a space and memory efficient data structure for set
+membership test, i.e., test if an element is not in the set or may be
+in the set.
+
+In the eviction path, specifically, in ``lru_gen_look_around()``, if a
+PMD has a sufficient number of hot pages, its address is placed in the
+filter. In the aging path, set membership means that the PTE range
+will be scanned for young pages.
+
+Note that Bloom filters are probabilistic on set membership. If a test
+is false positive, the cost is an additional scan of a range of PTEs,
+which may yield hot pages anyway. Parameters of the filter itself can
+control the false positive rate in the limit.
+
+Memcg LRU
+---------
+An memcg LRU is a per-node LRU of memcgs. It is also an LRU of LRUs,
+since each node and memcg combination has an LRU of folios (see
+``mem_cgroup_lruvec()``). Its goal is to improve the scalability of
+global reclaim, which is critical to system-wide memory overcommit in
+data centers. Note that memcg LRU only applies to global reclaim.
+
+The basic structure of an memcg LRU can be understood by an analogy to
+the active/inactive LRU (of folios):
+
+1. It has the young and the old (generations), i.e., the counterparts
+ to the active and the inactive;
+2. The increment of ``max_seq`` triggers promotion, i.e., the
+ counterpart to activation;
+3. Other events trigger similar operations, e.g., offlining an memcg
+ triggers demotion, i.e., the counterpart to deactivation.
+
+In terms of global reclaim, it has two distinct features:
+
+1. Sharding, which allows each thread to start at a random memcg (in
+ the old generation) and improves parallelism;
+2. Eventual fairness, which allows direct reclaim to bail out at will
+ and reduces latency without affecting fairness over some time.
+
+In terms of traversing memcgs during global reclaim, it improves the
+best-case complexity from O(n) to O(1) and does not affect the
+worst-case complexity O(n). Therefore, on average, it has a sublinear
+complexity.
+
Summary
-------
-The multi-gen LRU can be disassembled into the following parts:
+The multi-gen LRU (of folios) can be disassembled into the following
+parts:
* Generations
* Rmap walks
diff --git a/Documentation/mm/numa.rst b/Documentation/mm/numa.rst
index 99fdeca..0f1b568 100644
--- a/Documentation/mm/numa.rst
+++ b/Documentation/mm/numa.rst
@@ -1,5 +1,3 @@
-.. _numa:
-
Started Nov 1999 by Kanoj Sarcar <kanoj@sgi.com>
=============
@@ -64,7 +62,7 @@
the emulation of additional nodes. For NUMA emulation, linux will carve up
the existing nodes--or the system memory for non-NUMA platforms--into multiple
nodes. Each emulated node will manage a fraction of the underlying cells'
-physical memory. NUMA emluation is useful for testing NUMA kernel and
+physical memory. NUMA emulation is useful for testing NUMA kernel and
application features on non-NUMA platforms, and as a sort of memory resource
management mechanism when used together with cpusets.
[see Documentation/admin-guide/cgroup-v1/cpusets.rst]
@@ -110,7 +108,7 @@
such as taskset(1) and numactl(1), and program interfaces such as
sched_setaffinity(2). Further, one can modify the kernel's default local
allocation behavior using Linux NUMA memory policy. [see
-:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`].
+Documentation/admin-guide/mm/numa_memory_policy.rst].
System administrators can restrict the CPUs and nodes' memories that a non-
privileged user can specify in the scheduling or NUMA commands and functions
diff --git a/Documentation/mm/page_frags.rst b/Documentation/mm/page_frags.rst
index 7d6f938..a81617e 100644
--- a/Documentation/mm/page_frags.rst
+++ b/Documentation/mm/page_frags.rst
@@ -1,5 +1,3 @@
-.. _page_frags:
-
==============
Page fragments
==============
diff --git a/Documentation/mm/page_migration.rst b/Documentation/mm/page_migration.rst
index 11493ba..313dce1 100644
--- a/Documentation/mm/page_migration.rst
+++ b/Documentation/mm/page_migration.rst
@@ -1,5 +1,3 @@
-.. _page_migration:
-
==============
Page migration
==============
@@ -9,8 +7,8 @@
virtual addresses that the process sees do not change. However, the
system rearranges the physical location of those pages.
-Also see :ref:`Heterogeneous Memory Management (HMM) <hmm>`
-for migrating pages to or from device private memory.
+Also see Documentation/mm/hmm.rst for migrating pages to or from device
+private memory.
The main intent of page migration is to reduce the latency of memory accesses
by moving pages near to the processor where the process accessing that memory
diff --git a/Documentation/mm/page_owner.rst b/Documentation/mm/page_owner.rst
index 1275149..62e3f7a 100644
--- a/Documentation/mm/page_owner.rst
+++ b/Documentation/mm/page_owner.rst
@@ -1,5 +1,3 @@
-.. _page_owner:
-
==================================================
page owner: Tracking about who allocated each page
==================================================
@@ -52,7 +50,7 @@
Although it doesn't mean that they have the right owner information,
at least, we can tell whether the page is allocated or not,
more accurately. On 2GB memory x86-64 VM box, 13343 early allocated pages
-are catched and marked, although they are mostly allocated from struct
+are caught and marked, although they are mostly allocated from struct
page extension feature. Anyway, after that, no page is left in
un-tracking state.
@@ -61,7 +59,7 @@
1) Build user-space helper::
- cd tools/vm
+ cd tools/mm
make page_owner_sort
2) Enable page owner: add "page_owner=on" to boot cmdline.
@@ -178,7 +176,7 @@
at alloc_ts timestamp of the page when it was allocated
ator allocator memory allocator for pages
- For --curl option:
+ For --cull option:
KEY LONG DESCRIPTION
p pid process ID
diff --git a/Documentation/mm/page_table_check.rst b/Documentation/mm/page_table_check.rst
index 1a09472..cfd8f41 100644
--- a/Documentation/mm/page_table_check.rst
+++ b/Documentation/mm/page_table_check.rst
@@ -1,7 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _page_table_check:
-
================
Page Table Check
================
diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst
index 2ab7b8c..1bc888d 100644
--- a/Documentation/mm/physical_memory.rst
+++ b/Documentation/mm/physical_memory.rst
@@ -3,3 +3,350 @@
===============
Physical Memory
===============
+
+Linux is available for a wide range of architectures so there is a need for an
+architecture-independent abstraction to represent the physical memory. This
+chapter describes the structures used to manage physical memory in a running
+system.
+
+The first principal concept prevalent in the memory management is
+`Non-Uniform Memory Access (NUMA)
+<https://en.wikipedia.org/wiki/Non-uniform_memory_access>`_.
+With multi-core and multi-socket machines, memory may be arranged into banks
+that incur a different cost to access depending on the “distance” from the
+processor. For example, there might be a bank of memory assigned to each CPU or
+a bank of memory very suitable for DMA near peripheral devices.
+
+Each bank is called a node and the concept is represented under Linux by a
+``struct pglist_data`` even if the architecture is UMA. This structure is
+always referenced to by it's typedef ``pg_data_t``. ``A pg_data_t`` structure
+for a particular node can be referenced by ``NODE_DATA(nid)`` macro where
+``nid`` is the ID of that node.
+
+For NUMA architectures, the node structures are allocated by the architecture
+specific code early during boot. Usually, these structures are allocated
+locally on the memory bank they represent. For UMA architectures, only one
+static ``pg_data_t`` structure called ``contig_page_data`` is used. Nodes will
+be discussed further in Section :ref:`Nodes <nodes>`
+
+The entire physical address space is partitioned into one or more blocks
+called zones which represent ranges within memory. These ranges are usually
+determined by architectural constraints for accessing the physical memory.
+The memory range within a node that corresponds to a particular zone is
+described by a ``struct zone``, typedeffed to ``zone_t``. Each zone has
+one of the types described below.
+
+* ``ZONE_DMA`` and ``ZONE_DMA32`` historically represented memory suitable for
+ DMA by peripheral devices that cannot access all of the addressable
+ memory. For many years there are better more and robust interfaces to get
+ memory with DMA specific requirements (Documentation/core-api/dma-api.rst),
+ but ``ZONE_DMA`` and ``ZONE_DMA32`` still represent memory ranges that have
+ restrictions on how they can be accessed.
+ Depending on the architecture, either of these zone types or even they both
+ can be disabled at build time using ``CONFIG_ZONE_DMA`` and
+ ``CONFIG_ZONE_DMA32`` configuration options. Some 64-bit platforms may need
+ both zones as they support peripherals with different DMA addressing
+ limitations.
+
+* ``ZONE_NORMAL`` is for normal memory that can be accessed by the kernel all
+ the time. DMA operations can be performed on pages in this zone if the DMA
+ devices support transfers to all addressable memory. ``ZONE_NORMAL`` is
+ always enabled.
+
+* ``ZONE_HIGHMEM`` is the part of the physical memory that is not covered by a
+ permanent mapping in the kernel page tables. The memory in this zone is only
+ accessible to the kernel using temporary mappings. This zone is available
+ only on some 32-bit architectures and is enabled with ``CONFIG_HIGHMEM``.
+
+* ``ZONE_MOVABLE`` is for normal accessible memory, just like ``ZONE_NORMAL``.
+ The difference is that the contents of most pages in ``ZONE_MOVABLE`` is
+ movable. That means that while virtual addresses of these pages do not
+ change, their content may move between different physical pages. Often
+ ``ZONE_MOVABLE`` is populated during memory hotplug, but it may be
+ also populated on boot using one of ``kernelcore``, ``movablecore`` and
+ ``movable_node`` kernel command line parameters. See
+ Documentation/mm/page_migration.rst and
+ Documentation/admin-guide/mm/memory-hotplug.rst for additional details.
+
+* ``ZONE_DEVICE`` represents memory residing on devices such as PMEM and GPU.
+ It has different characteristics than RAM zone types and it exists to provide
+ :ref:`struct page <Pages>` and memory map services for device driver
+ identified physical address ranges. ``ZONE_DEVICE`` is enabled with
+ configuration option ``CONFIG_ZONE_DEVICE``.
+
+It is important to note that many kernel operations can only take place using
+``ZONE_NORMAL`` so it is the most performance critical zone. Zones are
+discussed further in Section :ref:`Zones <zones>`.
+
+The relation between node and zone extents is determined by the physical memory
+map reported by the firmware, architectural constraints for memory addressing
+and certain parameters in the kernel command line.
+
+For example, with 32-bit kernel on an x86 UMA machine with 2 Gbytes of RAM the
+entire memory will be on node 0 and there will be three zones: ``ZONE_DMA``,
+``ZONE_NORMAL`` and ``ZONE_HIGHMEM``::
+
+ 0 2G
+ +-------------------------------------------------------------+
+ | node 0 |
+ +-------------------------------------------------------------+
+
+ 0 16M 896M 2G
+ +----------+-----------------------+--------------------------+
+ | ZONE_DMA | ZONE_NORMAL | ZONE_HIGHMEM |
+ +----------+-----------------------+--------------------------+
+
+
+With a kernel built with ``ZONE_DMA`` disabled and ``ZONE_DMA32`` enabled and
+booted with ``movablecore=80%`` parameter on an arm64 machine with 16 Gbytes of
+RAM equally split between two nodes, there will be ``ZONE_DMA32``,
+``ZONE_NORMAL`` and ``ZONE_MOVABLE`` on node 0, and ``ZONE_NORMAL`` and
+``ZONE_MOVABLE`` on node 1::
+
+
+ 1G 9G 17G
+ +--------------------------------+ +--------------------------+
+ | node 0 | | node 1 |
+ +--------------------------------+ +--------------------------+
+
+ 1G 4G 4200M 9G 9320M 17G
+ +---------+----------+-----------+ +------------+-------------+
+ | DMA32 | NORMAL | MOVABLE | | NORMAL | MOVABLE |
+ +---------+----------+-----------+ +------------+-------------+
+
+.. _nodes:
+
+Nodes
+=====
+
+As we have mentioned, each node in memory is described by a ``pg_data_t`` which
+is a typedef for a ``struct pglist_data``. When allocating a page, by default
+Linux uses a node-local allocation policy to allocate memory from the node
+closest to the running CPU. As processes tend to run on the same CPU, it is
+likely the memory from the current node will be used. The allocation policy can
+be controlled by users as described in
+Documentation/admin-guide/mm/numa_memory_policy.rst.
+
+Most NUMA architectures maintain an array of pointers to the node
+structures. The actual structures are allocated early during boot when
+architecture specific code parses the physical memory map reported by the
+firmware. The bulk of the node initialization happens slightly later in the
+boot process by free_area_init() function, described later in Section
+:ref:`Initialization <initialization>`.
+
+
+Along with the node structures, kernel maintains an array of ``nodemask_t``
+bitmasks called ``node_states``. Each bitmask in this array represents a set of
+nodes with particular properties as defined by ``enum node_states``:
+
+``N_POSSIBLE``
+ The node could become online at some point.
+``N_ONLINE``
+ The node is online.
+``N_NORMAL_MEMORY``
+ The node has regular memory.
+``N_HIGH_MEMORY``
+ The node has regular or high memory. When ``CONFIG_HIGHMEM`` is disabled
+ aliased to ``N_NORMAL_MEMORY``.
+``N_MEMORY``
+ The node has memory(regular, high, movable)
+``N_CPU``
+ The node has one or more CPUs
+
+For each node that has a property described above, the bit corresponding to the
+node ID in the ``node_states[<property>]`` bitmask is set.
+
+For example, for node 2 with normal memory and CPUs, bit 2 will be set in ::
+
+ node_states[N_POSSIBLE]
+ node_states[N_ONLINE]
+ node_states[N_NORMAL_MEMORY]
+ node_states[N_HIGH_MEMORY]
+ node_states[N_MEMORY]
+ node_states[N_CPU]
+
+For various operations possible with nodemasks please refer to
+``include/linux/nodemask.h``.
+
+Among other things, nodemasks are used to provide macros for node traversal,
+namely ``for_each_node()`` and ``for_each_online_node()``.
+
+For instance, to call a function foo() for each online node::
+
+ for_each_online_node(nid) {
+ pg_data_t *pgdat = NODE_DATA(nid);
+
+ foo(pgdat);
+ }
+
+Node structure
+--------------
+
+The nodes structure ``struct pglist_data`` is declared in
+``include/linux/mmzone.h``. Here we briefly describe fields of this
+structure:
+
+General
+~~~~~~~
+
+``node_zones``
+ The zones for this node. Not all of the zones may be populated, but it is
+ the full list. It is referenced by this node's node_zonelists as well as
+ other node's node_zonelists.
+
+``node_zonelists``
+ The list of all zones in all nodes. This list defines the order of zones
+ that allocations are preferred from. The ``node_zonelists`` is set up by
+ ``build_zonelists()`` in ``mm/page_alloc.c`` during the initialization of
+ core memory management structures.
+
+``nr_zones``
+ Number of populated zones in this node.
+
+``node_mem_map``
+ For UMA systems that use FLATMEM memory model the 0's node
+ ``node_mem_map`` is array of struct pages representing each physical frame.
+
+``node_page_ext``
+ For UMA systems that use FLATMEM memory model the 0's node
+ ``node_page_ext`` is array of extensions of struct pages. Available only
+ in the kernels built with ``CONFIG_PAGE_EXTENSION`` enabled.
+
+``node_start_pfn``
+ The page frame number of the starting page frame in this node.
+
+``node_present_pages``
+ Total number of physical pages present in this node.
+
+``node_spanned_pages``
+ Total size of physical page range, including holes.
+
+``node_size_lock``
+ A lock that protects the fields defining the node extents. Only defined when
+ at least one of ``CONFIG_MEMORY_HOTPLUG`` or
+ ``CONFIG_DEFERRED_STRUCT_PAGE_INIT`` configuration options are enabled.
+ ``pgdat_resize_lock()`` and ``pgdat_resize_unlock()`` are provided to
+ manipulate ``node_size_lock`` without checking for ``CONFIG_MEMORY_HOTPLUG``
+ or ``CONFIG_DEFERRED_STRUCT_PAGE_INIT``.
+
+``node_id``
+ The Node ID (NID) of the node, starts at 0.
+
+``totalreserve_pages``
+ This is a per-node reserve of pages that are not available to userspace
+ allocations.
+
+``first_deferred_pfn``
+ If memory initialization on large machines is deferred then this is the first
+ PFN that needs to be initialized. Defined only when
+ ``CONFIG_DEFERRED_STRUCT_PAGE_INIT`` is enabled
+
+``deferred_split_queue``
+ Per-node queue of huge pages that their split was deferred. Defined only when ``CONFIG_TRANSPARENT_HUGEPAGE`` is enabled.
+
+``__lruvec``
+ Per-node lruvec holding LRU lists and related parameters. Used only when
+ memory cgroups are disabled. It should not be accessed directly, use
+ ``mem_cgroup_lruvec()`` to look up lruvecs instead.
+
+Reclaim control
+~~~~~~~~~~~~~~~
+
+See also Documentation/mm/page_reclaim.rst.
+
+``kswapd``
+ Per-node instance of kswapd kernel thread.
+
+``kswapd_wait``, ``pfmemalloc_wait``, ``reclaim_wait``
+ Workqueues used to synchronize memory reclaim tasks
+
+``nr_writeback_throttled``
+ Number of tasks that are throttled waiting on dirty pages to clean.
+
+``nr_reclaim_start``
+ Number of pages written while reclaim is throttled waiting for writeback.
+
+``kswapd_order``
+ Controls the order kswapd tries to reclaim
+
+``kswapd_highest_zoneidx``
+ The highest zone index to be reclaimed by kswapd
+
+``kswapd_failures``
+ Number of runs kswapd was unable to reclaim any pages
+
+``min_unmapped_pages``
+ Minimal number of unmapped file backed pages that cannot be reclaimed.
+ Determined by ``vm.min_unmapped_ratio`` sysctl. Only defined when
+ ``CONFIG_NUMA`` is enabled.
+
+``min_slab_pages``
+ Minimal number of SLAB pages that cannot be reclaimed. Determined by
+ ``vm.min_slab_ratio sysctl``. Only defined when ``CONFIG_NUMA`` is enabled
+
+``flags``
+ Flags controlling reclaim behavior.
+
+Compaction control
+~~~~~~~~~~~~~~~~~~
+
+``kcompactd_max_order``
+ Page order that kcompactd should try to achieve.
+
+``kcompactd_highest_zoneidx``
+ The highest zone index to be compacted by kcompactd.
+
+``kcompactd_wait``
+ Workqueue used to synchronize memory compaction tasks.
+
+``kcompactd``
+ Per-node instance of kcompactd kernel thread.
+
+``proactive_compact_trigger``
+ Determines if proactive compaction is enabled. Controlled by
+ ``vm.compaction_proactiveness`` sysctl.
+
+Statistics
+~~~~~~~~~~
+
+``per_cpu_nodestats``
+ Per-CPU VM statistics for the node
+
+``vm_stat``
+ VM statistics for the node.
+
+.. _zones:
+
+Zones
+=====
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
+
+.. _pages:
+
+Pages
+=====
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
+
+.. _folios:
+
+Folios
+======
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
+
+.. _initialization:
+
+Initialization
+==============
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
diff --git a/Documentation/mm/remap_file_pages.rst b/Documentation/mm/remap_file_pages.rst
index 7bef671..297091c 100644
--- a/Documentation/mm/remap_file_pages.rst
+++ b/Documentation/mm/remap_file_pages.rst
@@ -1,5 +1,3 @@
-.. _remap_file_pages:
-
==============================
remap_file_pages() system call
==============================
diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst
index 7f65221..be759715 100644
--- a/Documentation/mm/slub.rst
+++ b/Documentation/mm/slub.rst
@@ -1,5 +1,3 @@
-.. _slub:
-
==========================
Short users guide for SLUB
==========================
@@ -21,7 +19,7 @@
running the command. ``slabinfo`` can be compiled with
::
- gcc -o slabinfo tools/vm/slabinfo.c
+ gcc -o slabinfo tools/mm/slabinfo.c
Some of the modes of operation of ``slabinfo`` require that slub debugging
be enabled on the command line. F.e. no tracking information will be
diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
index c089196..50ee0df 100644
--- a/Documentation/mm/split_page_table_lock.rst
+++ b/Documentation/mm/split_page_table_lock.rst
@@ -1,5 +1,3 @@
-.. _split_page_table_lock:
-
=====================
Split page table lock
=====================
diff --git a/Documentation/mm/transhuge.rst b/Documentation/mm/transhuge.rst
index ec3dc5b..9a60705 100644
--- a/Documentation/mm/transhuge.rst
+++ b/Documentation/mm/transhuge.rst
@@ -1,5 +1,3 @@
-.. _transhuge:
-
============================
Transparent Hugepage Support
============================
@@ -112,20 +110,20 @@
Refcounting on THP is mostly consistent with refcounting on other compound
pages:
- - get_page()/put_page() and GUP operate on head page's ->_refcount.
+ - get_page()/put_page() and GUP operate on the folio->_refcount.
- ->_refcount in tail pages is always zero: get_page_unless_zero() never
succeeds on tail pages.
- - map/unmap of PMD entry for the whole compound page increment/decrement
- ->compound_mapcount, stored in the first tail page of the compound page;
- and also increment/decrement ->subpages_mapcount (also in the first tail)
- by COMPOUND_MAPPED when compound_mapcount goes from -1 to 0 or 0 to -1.
+ - map/unmap of a PMD entry for the whole THP increment/decrement
+ folio->_entire_mapcount and also increment/decrement
+ folio->_nr_pages_mapped by COMPOUND_MAPPED when _entire_mapcount
+ goes from -1 to 0 or 0 to -1.
- - map/unmap of sub-pages with PTE entry increment/decrement ->_mapcount
- on relevant sub-page of the compound page, and also increment/decrement
- ->subpages_mapcount, stored in first tail page of the compound page, when
- _mapcount goes from -1 to 0 or 0 to -1: counting sub-pages mapped by PTE.
+ - map/unmap of individual pages with PTE entry increment/decrement
+ page->_mapcount and also increment/decrement folio->_nr_pages_mapped
+ when page->_mapcount goes from -1 to 0 or 0 to -1 as this counts
+ the number of pages mapped by PTE.
split_huge_page internally has to distribute the refcounts in the head
page to the tail pages before clearing all PG_head/tail bits from the page
@@ -153,8 +151,8 @@
Note that split_huge_pmd() doesn't have any limitations on refcounting:
pmd can be split at any point and never fails.
-Partial unmap and deferred_split_huge_page()
-============================================
+Partial unmap and deferred_split_folio()
+========================================
Unmapping part of THP (with munmap() or other way) is not going to free
memory immediately. Instead, we detect that a subpage of THP is not in use
@@ -166,6 +164,6 @@
counterproductive since in many cases partial unmap happens during exit(2) if
a THP crosses a VMA boundary.
-The function deferred_split_huge_page() is used to queue a page for splitting.
+The function deferred_split_folio() is used to queue a folio for splitting.
The splitting itself will happen when we get memory pressure via shrinker
interface.
diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst
index 4a0e158..92ac5dc 100644
--- a/Documentation/mm/unevictable-lru.rst
+++ b/Documentation/mm/unevictable-lru.rst
@@ -1,5 +1,3 @@
-.. _unevictable_lru:
-
==============================
Unevictable LRU Infrastructure
==============================
@@ -12,7 +10,7 @@
This document describes the Linux memory manager's "Unevictable LRU"
infrastructure and the use of this to manage several types of "unevictable"
-pages.
+folios.
The document attempts to provide the overall rationale behind this mechanism
and the rationale for some of the design decisions that drove the
@@ -27,8 +25,8 @@
===================
The Unevictable LRU facility adds an additional LRU list to track unevictable
-pages and to hide these pages from vmscan. This mechanism is based on a patch
-by Larry Woodman of Red Hat to address several scalability problems with page
+folios and to hide these folios from vmscan. This mechanism is based on a patch
+by Larry Woodman of Red Hat to address several scalability problems with folio
reclaim in Linux. The problems have been observed at customer sites on large
memory x86_64 systems.
@@ -52,40 +50,41 @@
unevictable, either by definition or by circumstance, in the future.
-The Unevictable LRU Page List
------------------------------
+The Unevictable LRU Folio List
+------------------------------
-The Unevictable LRU page list is a lie. It was never an LRU-ordered list, but a
-companion to the LRU-ordered anonymous and file, active and inactive page lists;
-and now it is not even a page list. But following familiar convention, here in
-this document and in the source, we often imagine it as a fifth LRU page list.
+The Unevictable LRU folio list is a lie. It was never an LRU-ordered
+list, but a companion to the LRU-ordered anonymous and file, active and
+inactive folio lists; and now it is not even a folio list. But following
+familiar convention, here in this document and in the source, we often
+imagine it as a fifth LRU folio list.
The Unevictable LRU infrastructure consists of an additional, per-node, LRU list
-called the "unevictable" list and an associated page flag, PG_unevictable, to
-indicate that the page is being managed on the unevictable list.
+called the "unevictable" list and an associated folio flag, PG_unevictable, to
+indicate that the folio is being managed on the unevictable list.
The PG_unevictable flag is analogous to, and mutually exclusive with, the
-PG_active flag in that it indicates on which LRU list a page resides when
+PG_active flag in that it indicates on which LRU list a folio resides when
PG_lru is set.
-The Unevictable LRU infrastructure maintains unevictable pages as if they were
+The Unevictable LRU infrastructure maintains unevictable folios as if they were
on an additional LRU list for a few reasons:
- (1) We get to "treat unevictable pages just like we treat other pages in the
+ (1) We get to "treat unevictable folios just like we treat other folios in the
system - which means we get to use the same code to manipulate them, the
same code to isolate them (for migrate, etc.), the same code to keep track
of the statistics, etc..." [Rik van Riel]
- (2) We want to be able to migrate unevictable pages between nodes for memory
+ (2) We want to be able to migrate unevictable folios between nodes for memory
defragmentation, workload management and memory hotplug. The Linux kernel
- can only migrate pages that it can successfully isolate from the LRU
+ can only migrate folios that it can successfully isolate from the LRU
lists (or "Movable" pages: outside of consideration here). If we were to
- maintain pages elsewhere than on an LRU-like list, where they can be
- detected by isolate_lru_page(), we would prevent their migration.
+ maintain folios elsewhere than on an LRU-like list, where they can be
+ detected by folio_isolate_lru(), we would prevent their migration.
-The unevictable list does not differentiate between file-backed and anonymous,
-swap-backed pages. This differentiation is only important while the pages are,
-in fact, evictable.
+The unevictable list does not differentiate between file-backed and
+anonymous, swap-backed folios. This differentiation is only important
+while the folios are, in fact, evictable.
The unevictable list benefits from the "arrayification" of the per-node LRU
lists and statistics originally proposed and posted by Christoph Lameter.
@@ -158,7 +157,7 @@
Detecting Unevictable Pages
---------------------------
-The function page_evictable() in mm/internal.h determines whether a page is
+The function folio_evictable() in mm/internal.h determines whether a folio is
evictable or not using the query function outlined above [see section
:ref:`Marking address spaces unevictable <mark_addr_space_unevict>`]
to check the AS_UNEVICTABLE flag.
@@ -167,7 +166,7 @@
might be), the lock action (e.g. SHM_LOCK) can be lazy, and need not populate
the page tables for the region as does, for example, mlock(), nor need it make
any special effort to push any pages in the SHM_LOCK'd area to the unevictable
-list. Instead, vmscan will do this if and when it encounters the pages during
+list. Instead, vmscan will do this if and when it encounters the folios during
a reclamation scan.
On an unlock action (such as SHM_UNLOCK), the unlocker (e.g. shmctl()) must scan
@@ -176,41 +175,43 @@
the pages are also "rescued" from the unevictable list in the process of
freeing them.
-page_evictable() also checks for mlocked pages by testing an additional page
-flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is
-faulted into a VM_LOCKED VMA, or found in a VMA being VM_LOCKED.
+folio_evictable() also checks for mlocked folios by calling
+folio_test_mlocked(), which is set when a folio is faulted into a
+VM_LOCKED VMA, or found in a VMA being VM_LOCKED.
-Vmscan's Handling of Unevictable Pages
---------------------------------------
+Vmscan's Handling of Unevictable Folios
+---------------------------------------
-If unevictable pages are culled in the fault path, or moved to the unevictable
-list at mlock() or mmap() time, vmscan will not encounter the pages until they
+If unevictable folios are culled in the fault path, or moved to the unevictable
+list at mlock() or mmap() time, vmscan will not encounter the folios until they
have become evictable again (via munlock() for example) and have been "rescued"
from the unevictable list. However, there may be situations where we decide,
-for the sake of expediency, to leave an unevictable page on one of the regular
+for the sake of expediency, to leave an unevictable folio on one of the regular
active/inactive LRU lists for vmscan to deal with. vmscan checks for such
-pages in all of the shrink_{active|inactive|page}_list() functions and will
-"cull" such pages that it encounters: that is, it diverts those pages to the
+folios in all of the shrink_{active|inactive|page}_list() functions and will
+"cull" such folios that it encounters: that is, it diverts those folios to the
unevictable list for the memory cgroup and node being scanned.
-There may be situations where a page is mapped into a VM_LOCKED VMA, but the
-page is not marked as PG_mlocked. Such pages will make it all the way to
-shrink_active_list() or shrink_page_list() where they will be detected when
-vmscan walks the reverse map in folio_referenced() or try_to_unmap(). The page
-is culled to the unevictable list when it is released by the shrinker.
+There may be situations where a folio is mapped into a VM_LOCKED VMA,
+but the folio does not have the mlocked flag set. Such folios will make
+it all the way to shrink_active_list() or shrink_page_list() where they
+will be detected when vmscan walks the reverse map in folio_referenced()
+or try_to_unmap(). The folio is culled to the unevictable list when it
+is released by the shrinker.
-To "cull" an unevictable page, vmscan simply puts the page back on the LRU list
-using putback_lru_page() - the inverse operation to isolate_lru_page() - after
-dropping the page lock. Because the condition which makes the page unevictable
-may change once the page is unlocked, __pagevec_lru_add_fn() will recheck the
-unevictable state of a page before placing it on the unevictable list.
+To "cull" an unevictable folio, vmscan simply puts the folio back on
+the LRU list using folio_putback_lru() - the inverse operation to
+folio_isolate_lru() - after dropping the folio lock. Because the
+condition which makes the folio unevictable may change once the folio
+is unlocked, __pagevec_lru_add_fn() will recheck the unevictable state
+of a folio before placing it on the unevictable list.
MLOCKED Pages
=============
-The unevictable page list is also useful for mlock(), in addition to ramfs and
+The unevictable folio list is also useful for mlock(), in addition to ramfs and
SYSV SHM. Note that mlock() is only available in CONFIG_MMU=y situations; in
NOMMU situations, all mappings are effectively mlocked.
@@ -295,7 +296,7 @@
If the VMA passes some filtering as described in "Filtering Special VMAs"
below, mlock_fixup() will attempt to merge the VMA with its neighbors or split
off a subset of the VMA if the range does not cover the entire VMA. Any pages
-already present in the VMA are then marked as mlocked by mlock_page() via
+already present in the VMA are then marked as mlocked by mlock_folio() via
mlock_pte_range() via walk_page_range() via mlock_vma_pages_range().
Before returning from the system call, do_mlock() or mlockall() will call
@@ -308,22 +309,22 @@
fault path - which is also how mlock2()'s MLOCK_ONFAULT areas are handled.
For each PTE (or PMD) being faulted into a VMA, the page add rmap function
-calls mlock_vma_page(), which calls mlock_page() when the VMA is VM_LOCKED
+calls mlock_vma_folio(), which calls mlock_folio() when the VMA is VM_LOCKED
(unless it is a PTE mapping of a part of a transparent huge page). Or when
-it is a newly allocated anonymous page, lru_cache_add_inactive_or_unevictable()
-calls mlock_new_page() instead: similar to mlock_page(), but can make better
+it is a newly allocated anonymous page, folio_add_lru_vma() calls
+mlock_new_folio() instead: similar to mlock_folio(), but can make better
judgments, since this page is held exclusively and known not to be on LRU yet.
-mlock_page() sets PageMlocked immediately, then places the page on the CPU's
-mlock pagevec, to batch up the rest of the work to be done under lru_lock by
-__mlock_page(). __mlock_page() sets PageUnevictable, initializes mlock_count
+mlock_folio() sets PG_mlocked immediately, then places the page on the CPU's
+mlock folio batch, to batch up the rest of the work to be done under lru_lock by
+__mlock_folio(). __mlock_folio() sets PG_unevictable, initializes mlock_count
and moves the page to unevictable state ("the unevictable LRU", but with
-mlock_count in place of LRU threading). Or if the page was already PageLRU
-and PageUnevictable and PageMlocked, it simply increments the mlock_count.
+mlock_count in place of LRU threading). Or if the page was already PG_lru
+and PG_unevictable and PG_mlocked, it simply increments the mlock_count.
But in practice that may not work ideally: the page may not yet be on an LRU, or
it may have been temporarily isolated from LRU. In such cases the mlock_count
-field cannot be touched, but will be set to 0 later when __pagevec_lru_add_fn()
+field cannot be touched, but will be set to 0 later when __munlock_folio()
returns the page to "LRU". Races prohibit mlock_count from being set to 1 then:
rather than risk stranding a page indefinitely as unevictable, always err with
mlock_count on the low side, so that when munlocked the page will be rescued to
@@ -370,20 +371,21 @@
any "special" VMAs. So, those VMAs will be ignored for munlock.
If the VMA is VM_LOCKED, mlock_fixup() again attempts to merge or split off the
-specified range. All pages in the VMA are then munlocked by munlock_page() via
+specified range. All pages in the VMA are then munlocked by munlock_folio() via
mlock_pte_range() via walk_page_range() via mlock_vma_pages_range() - the same
function used when mlocking a VMA range, with new flags for the VMA indicating
that it is munlock() being performed.
-munlock_page() uses the mlock pagevec to batch up work to be done under
-lru_lock by __munlock_page(). __munlock_page() decrements the page's
-mlock_count, and when that reaches 0 it clears PageMlocked and clears
-PageUnevictable, moving the page from unevictable state to inactive LRU.
+munlock_folio() uses the mlock pagevec to batch up work to be done
+under lru_lock by __munlock_folio(). __munlock_folio() decrements the
+folio's mlock_count, and when that reaches 0 it clears the mlocked flag
+and clears the unevictable flag, moving the folio from unevictable state
+to the inactive LRU.
-But in practice that may not work ideally: the page may not yet have reached
+But in practice that may not work ideally: the folio may not yet have reached
"the unevictable LRU", or it may have been temporarily isolated from it. In
those cases its mlock_count field is unusable and must be assumed to be 0: so
-that the page will be rescued to an evictable LRU, then perhaps be mlocked
+that the folio will be rescued to an evictable LRU, then perhaps be mlocked
again later if vmscan finds it in a VM_LOCKED VMA.
@@ -410,7 +412,7 @@
before mlocking any pages already present, if one of those pages were migrated
before mlock_pte_range() reached it, it would get counted twice in mlock_count.
To prevent that, mlock_vma_pages_range() temporarily marks the VMA as VM_IO,
-so that mlock_vma_page() will skip it.
+so that mlock_vma_folio() will skip it.
To complete page migration, we place the old and new pages back onto the LRU
afterwards. The "unneeded" page - old page on success, new page on failure -
@@ -483,18 +485,19 @@
way, so unmapping them required no processing.
For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
-munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED
+munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
(unless it was a PTE mapping of a part of a transparent huge page).
-munlock_page() uses the mlock pagevec to batch up work to be done under
-lru_lock by __munlock_page(). __munlock_page() decrements the page's
-mlock_count, and when that reaches 0 it clears PageMlocked and clears
-PageUnevictable, moving the page from unevictable state to inactive LRU.
+munlock_folio() uses the mlock pagevec to batch up work to be done
+under lru_lock by __munlock_folio(). __munlock_folio() decrements the
+folio's mlock_count, and when that reaches 0 it clears the mlocked flag
+and clears the unevictable flag, moving the folio from unevictable state
+to the inactive LRU.
-But in practice that may not work ideally: the page may not yet have reached
+But in practice that may not work ideally: the folio may not yet have reached
"the unevictable LRU", or it may have been temporarily isolated from it. In
those cases its mlock_count field is unusable and must be assumed to be 0: so
-that the page will be rescued to an evictable LRU, then perhaps be mlocked
+that the folio will be rescued to an evictable LRU, then perhaps be mlocked
again later if vmscan finds it in a VM_LOCKED VMA.
@@ -507,7 +510,7 @@
Mlocked pages can be munlocked and deleted in this way: like with munmap(),
for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
-munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED
+munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
(unless it was a PTE mapping of a part of a transparent huge page).
However, if there is a racing munlock(), since mlock_vma_pages_range() starts
@@ -515,7 +518,7 @@
present, if one of those pages were unmapped by truncation or hole punch before
mlock_pte_range() reached it, it would not be recognized as mlocked by this VMA,
and would not be counted out of mlock_count. In this rare case, a page may
-still appear as PageMlocked after it has been fully unmapped: and it is left to
+still appear as PG_mlocked after it has been fully unmapped: and it is left to
release_pages() (or __page_cache_release()) to clear it and update statistics
before freeing (this event is counted in /proc/vmstat unevictable_pgs_cleared,
which is usually 0).
@@ -527,7 +530,7 @@
vmscan's shrink_active_list() culls any obviously unevictable pages -
i.e. !page_evictable(page) pages - diverting those to the unevictable list.
However, shrink_active_list() only sees unevictable pages that made it onto the
-active/inactive LRU lists. Note that these pages do not have PageUnevictable
+active/inactive LRU lists. Note that these pages do not have PG_unevictable
set - otherwise they would be on the unevictable list and shrink_active_list()
would never see them.
@@ -549,6 +552,6 @@
rmap's folio_referenced_one(), called via vmscan's shrink_active_list() or
shrink_page_list(), and rmap's try_to_unmap_one() called via shrink_page_list(),
-check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_page()
+check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_folio()
to correct them. Such pages are culled to the unevictable list when released
by the shrinker.
diff --git a/Documentation/mm/z3fold.rst b/Documentation/mm/z3fold.rst
index 224e3c6..25b5935 100644
--- a/Documentation/mm/z3fold.rst
+++ b/Documentation/mm/z3fold.rst
@@ -1,5 +1,3 @@
-.. _z3fold:
-
======
z3fold
======
diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst
index 6e79893..a3c26d5 100644
--- a/Documentation/mm/zsmalloc.rst
+++ b/Documentation/mm/zsmalloc.rst
@@ -1,5 +1,3 @@
-.. _zsmalloc:
-
========
zsmalloc
========
@@ -41,13 +39,12 @@
# cat /sys/kernel/debug/zsmalloc/zram0/classes
- class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage
+ class size 10% 20% 30% 40% 50% 60% 70% 80% 90% 99% 100% obj_allocated obj_used pages_used pages_per_zspage freeable
...
...
- 9 176 0 1 186 129 8 4
- 10 192 1 0 2880 2872 135 3
- 11 208 0 1 819 795 42 2
- 12 224 0 1 219 159 12 4
+ 30 512 0 12 4 1 0 1 0 0 1 0 414 3464 3346 433 1 14
+ 31 528 2 7 2 2 1 0 1 0 0 2 117 4154 3793 536 4 44
+ 32 544 6 3 4 1 2 1 0 0 0 1 260 4170 3965 556 2 26
...
...
@@ -56,10 +53,28 @@
index
size
object size zspage stores
-almost_empty
- the number of ZS_ALMOST_EMPTY zspages(see below)
-almost_full
- the number of ZS_ALMOST_FULL zspages(see below)
+10%
+ the number of zspages with usage ratio less than 10% (see below)
+20%
+ the number of zspages with usage ratio between 10% and 20%
+30%
+ the number of zspages with usage ratio between 20% and 30%
+40%
+ the number of zspages with usage ratio between 30% and 40%
+50%
+ the number of zspages with usage ratio between 40% and 50%
+60%
+ the number of zspages with usage ratio between 50% and 60%
+70%
+ the number of zspages with usage ratio between 60% and 70%
+80%
+ the number of zspages with usage ratio between 70% and 80%
+90%
+ the number of zspages with usage ratio between 80% and 90%
+99%
+ the number of zspages with usage ratio between 90% and 99%
+100%
+ the number of zspages with usage ratio 100%
obj_allocated
the number of objects allocated
obj_used
@@ -68,15 +83,183 @@
the number of pages allocated for the class
pages_per_zspage
the number of 0-order pages to make a zspage
+freeable
+ the approximate number of pages class compaction can free
-We assign a zspage to ZS_ALMOST_EMPTY fullness group when n <= N / f, where
+Each zspage maintains inuse counter which keeps track of the number of
+objects stored in the zspage. The inuse counter determines the zspage's
+"fullness group" which is calculated as the ratio of the "inuse" objects to
+the total number of objects the zspage can hold (objs_per_zspage). The
+closer the inuse counter is to objs_per_zspage, the better.
-* n = number of allocated objects
-* N = total number of objects zspage can store
-* f = fullness_threshold_frac(ie, 4 at the moment)
+Internals
+=========
-Similarly, we assign zspage to:
+zsmalloc has 255 size classes, each of which can hold a number of zspages.
+Each zspage can contain up to ZSMALLOC_CHAIN_SIZE physical (0-order) pages.
+The optimal zspage chain size for each size class is calculated during the
+creation of the zsmalloc pool (see calculate_zspage_chain_size()).
-* ZS_ALMOST_FULL when n > N / f
-* ZS_EMPTY when n == 0
-* ZS_FULL when n == N
+As an optimization, zsmalloc merges size classes that have similar
+characteristics in terms of the number of pages per zspage and the number
+of objects that each zspage can store.
+
+For instance, consider the following size classes:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+ ...
+ 94 1536 0 .... 0 0 0 0 3 0
+ 100 1632 0 .... 0 0 0 0 2 0
+ ...
+
+
+Size classes #95-99 are merged with size class #100. This means that when we
+need to store an object of size, say, 1568 bytes, we end up using size class
+#100 instead of size class #96. Size class #100 is meant for objects of size
+1632 bytes, so each object of size 1568 bytes wastes 1632-1568=64 bytes.
+
+Size class #100 consists of zspages with 2 physical pages each, which can
+hold a total of 5 objects. If we need to store 13 objects of size 1568, we
+end up allocating three zspages, or 6 physical pages.
+
+However, if we take a closer look at size class #96 (which is meant for
+objects of size 1568 bytes) and trace `calculate_zspage_chain_size()`, we
+find that the most optimal zspage configuration for this class is a chain
+of 5 physical pages:::
+
+ pages per zspage wasted bytes used%
+ 1 960 76
+ 2 352 95
+ 3 1312 89
+ 4 704 95
+ 5 96 99
+
+This means that a class #96 configuration with 5 physical pages can store 13
+objects of size 1568 in a single zspage, using a total of 5 physical pages.
+This is more efficient than the class #100 configuration, which would use 6
+physical pages to store the same number of objects.
+
+As the zspage chain size for class #96 increases, its key characteristics
+such as pages per-zspage and objects per-zspage also change. This leads to
+dewer class mergers, resulting in a more compact grouping of classes, which
+reduces memory wastage.
+
+Let's take a closer look at the bottom of `/sys/kernel/debug/zsmalloc/zramX/classes`:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ 202 3264 0 .. 0 0 0 0 4 0
+ 254 4096 0 .. 0 0 0 0 1 0
+ ...
+
+Size class #202 stores objects of size 3264 bytes and has a maximum of 4 pages
+per zspage. Any object larger than 3264 bytes is considered huge and belongs
+to size class #254, which stores each object in its own physical page (objects
+in huge classes do not share pages).
+
+Increasing the size of the chain of zspages also results in a higher watermark
+for the huge size class and fewer huge classes overall. This allows for more
+efficient storage of large objects.
+
+For zspage chain size of 8, huge class watermark becomes 3632 bytes:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ 202 3264 0 .. 0 0 0 0 4 0
+ 211 3408 0 .. 0 0 0 0 5 0
+ 217 3504 0 .. 0 0 0 0 6 0
+ 222 3584 0 .. 0 0 0 0 7 0
+ 225 3632 0 .. 0 0 0 0 8 0
+ 254 4096 0 .. 0 0 0 0 1 0
+ ...
+
+For zspage chain size of 16, huge class watermark becomes 3840 bytes:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ 202 3264 0 .. 0 0 0 0 4 0
+ 206 3328 0 .. 0 0 0 0 13 0
+ 207 3344 0 .. 0 0 0 0 9 0
+ 208 3360 0 .. 0 0 0 0 14 0
+ 211 3408 0 .. 0 0 0 0 5 0
+ 212 3424 0 .. 0 0 0 0 16 0
+ 214 3456 0 .. 0 0 0 0 11 0
+ 217 3504 0 .. 0 0 0 0 6 0
+ 219 3536 0 .. 0 0 0 0 13 0
+ 222 3584 0 .. 0 0 0 0 7 0
+ 223 3600 0 .. 0 0 0 0 15 0
+ 225 3632 0 .. 0 0 0 0 8 0
+ 228 3680 0 .. 0 0 0 0 9 0
+ 230 3712 0 .. 0 0 0 0 10 0
+ 232 3744 0 .. 0 0 0 0 11 0
+ 234 3776 0 .. 0 0 0 0 12 0
+ 235 3792 0 .. 0 0 0 0 13 0
+ 236 3808 0 .. 0 0 0 0 14 0
+ 238 3840 0 .. 0 0 0 0 15 0
+ 254 4096 0 .. 0 0 0 0 1 0
+ ...
+
+Overall the combined zspage chain size effect on zsmalloc pool configuration:::
+
+ pages per zspage number of size classes (clusters) huge size class watermark
+ 4 69 3264
+ 5 86 3408
+ 6 93 3504
+ 7 112 3584
+ 8 123 3632
+ 9 140 3680
+ 10 143 3712
+ 11 159 3744
+ 12 164 3776
+ 13 180 3792
+ 14 183 3808
+ 15 188 3840
+ 16 191 3840
+
+
+A synthetic test
+----------------
+
+zram as a build artifacts storage (Linux kernel compilation).
+
+* `CONFIG_ZSMALLOC_CHAIN_SIZE=4`
+
+ zsmalloc classes stats:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ Total 13 .. 51 413836 412973 159955 3
+
+ zram mm_stat:::
+
+ 1691783168 628083717 655175680 0 655175680 60 0 34048 34049
+
+
+* `CONFIG_ZSMALLOC_CHAIN_SIZE=8`
+
+ zsmalloc classes stats:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ Total 18 .. 87 414852 412978 156666 0
+
+ zram mm_stat:::
+
+ 1691803648 627793930 641703936 0 641703936 60 0 33591 33591
+
+Using larger zspage chains may result in using fewer physical pages, as seen
+in the example where the number of physical pages used decreased from 159955
+to 156666, at the same time maximum zsmalloc pool memory usage went down from
+655175680 to 641703936 bytes.
+
+However, this advantage may be offset by the potential for increased system
+memory pressure (as some zspages have larger chain sizes) in cases where there
+is heavy internal fragmentation and zspool compaction is unable to relocate
+objects and release zspages. In these cases, it is recommended to decrease
+the limit on the size of the zspage chains (as specified by the
+CONFIG_ZSMALLOC_CHAIN_SIZE option).
diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml
new file mode 100644
index 0000000..5c3642b
--- /dev/null
+++ b/Documentation/netlink/genetlink-c.yaml
@@ -0,0 +1,331 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://kernel.org/schemas/netlink/genetlink-c.yaml#
+$schema: https://json-schema.org/draft-07/schema
+
+# Common defines
+$defs:
+ uint:
+ type: integer
+ minimum: 0
+ len-or-define:
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_]+( - 1)?$
+ minimum: 0
+
+# Schema for specs
+title: Protocol
+description: Specification of a genetlink protocol
+type: object
+required: [ name, doc, attribute-sets, operations ]
+additionalProperties: False
+properties:
+ name:
+ description: Name of the genetlink family.
+ type: string
+ doc:
+ type: string
+ version:
+ description: Generic Netlink family version. Default is 1.
+ type: integer
+ minimum: 1
+ protocol:
+ description: Schema compatibility level. Default is "genetlink".
+ enum: [ genetlink, genetlink-c ]
+ # Start genetlink-c
+ uapi-header:
+ description: Path to the uAPI header, default is linux/${family-name}.h
+ type: string
+ c-family-name:
+ description: Name of the define for the family name.
+ type: string
+ c-version-name:
+ description: Name of the define for the verion of the family.
+ type: string
+ max-by-define:
+ description: Makes the number of attributes and commands be specified by a define, not an enum value.
+ type: boolean
+ # End genetlink-c
+
+ definitions:
+ description: List of type and constant definitions (enums, flags, defines).
+ type: array
+ items:
+ type: object
+ required: [ type, name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ header:
+ description: For C-compatible languages, header which already defines this value.
+ type: string
+ type:
+ enum: [ const, enum, flags ]
+ doc:
+ type: string
+ # For const
+ value:
+ description: For const - the value.
+ type: [ string, integer ]
+ # For enum and flags
+ value-start:
+ description: For enum or flags the literal initializer for the first value.
+ type: [ string, integer ]
+ entries:
+ description: For enum or flags array of values.
+ type: array
+ items:
+ oneOf:
+ - type: string
+ - type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ value:
+ type: integer
+ doc:
+ type: string
+ render-max:
+ description: Render the max members for this enum.
+ type: boolean
+ # Start genetlink-c
+ enum-name:
+ description: Name for enum, if empty no name will be used.
+ type: [ string, "null" ]
+ name-prefix:
+ description: For enum the prefix of the values, optional.
+ type: string
+ # End genetlink-c
+
+ attribute-sets:
+ description: Definition of attribute spaces for this family.
+ type: array
+ items:
+ description: Definition of a single attribute space.
+ type: object
+ required: [ name, attributes ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ Name used when referring to this space in other definitions, not used outside of the spec.
+ type: string
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the attributes. Default family[name]-set[name]-a-
+ type: string
+ enum-name:
+ description: Name for the enum type of the attribute.
+ type: string
+ doc:
+ description: Documentation of the space.
+ type: string
+ subset-of:
+ description: |
+ Name of another space which this is a logical part of. Sub-spaces can be used to define
+ a limited group of attributes which are used in a nest.
+ type: string
+ # Start genetlink-c
+ attr-cnt-name:
+ description: The explicit name for constant holding the count of attributes (last attr + 1).
+ type: string
+ attr-max-name:
+ description: The explicit name for last member of attribute enum.
+ type: string
+ # End genetlink-c
+ attributes:
+ description: List of attributes in the space.
+ type: array
+ items:
+ type: object
+ required: [ name, type ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ type: &attr-type
+ enum: [ unused, pad, flag, binary, u8, u16, u32, u64, s32, s64,
+ string, nest, array-nest, nest-type-value ]
+ doc:
+ description: Documentation of the attribute.
+ type: string
+ value:
+ description: Value for the enum item representing this attribute in the uAPI.
+ $ref: '#/$defs/uint'
+ type-value:
+ description: Name of the value extracted from the type of a nest-type-value attribute.
+ type: array
+ items:
+ type: string
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ multi-attr:
+ type: boolean
+ nested-attributes:
+ description: Name of the space (sub-space) used inside the attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ checks:
+ description: Kernel input validation.
+ type: object
+ additionalProperties: False
+ properties:
+ flags-mask:
+ description: Name of the flags constant on which to base mask (unsigned scalar types only).
+ type: string
+ min:
+ description: Min value for an integer attribute.
+ type: integer
+ min-len:
+ description: Min length for a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ max-len:
+ description: Max length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ sub-type: *attr-type
+
+ # Make sure name-prefix does not appear in subsets (subsets inherit naming)
+ dependencies:
+ name-prefix:
+ not:
+ required: [ subset-of ]
+ subset-of:
+ not:
+ required: [ name-prefix ]
+
+ operations:
+ description: Operations supported by the protocol.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ enum-model:
+ description: |
+ The model of assigning values to the operations.
+ "unified" is the recommended model where all message types belong
+ to a single enum.
+ "directional" has the messages sent to the kernel and from the kernel
+ enumerated separately.
+ enum: [ unified ]
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the command. The name is formed by concatenating
+ the prefix with the upper case name of the command, with dashes replaced by underscores.
+ type: string
+ enum-name:
+ description: Name for the enum type with commands.
+ type: string
+ async-prefix:
+ description: Same as name-prefix but used to render notifications and events to separate enum.
+ type: string
+ async-enum:
+ description: Name for the enum type with notifications/events.
+ type: string
+ list:
+ description: List of commands
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, doc ]
+ properties:
+ name:
+ description: Name of the operation, also defining its C enum value in uAPI.
+ type: string
+ doc:
+ description: Documentation for the command.
+ type: string
+ value:
+ description: Value for the enum in the uAPI.
+ $ref: '#/$defs/uint'
+ attribute-set:
+ description: |
+ Attribute space from which attributes directly in the requests and replies
+ to this command are defined.
+ type: string
+ flags: &cmd_flags
+ description: Command flags.
+ type: array
+ items:
+ enum: [ admin-perm ]
+ dont-validate:
+ description: Kernel attribute validation flags.
+ type: array
+ items:
+ enum: [ strict, dump ]
+ do: &subop-type
+ description: Main command handler.
+ type: object
+ additionalProperties: False
+ properties:
+ request: &subop-attr-list
+ description: Definition of the request message for a given command.
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: |
+ Names of attributes from the attribute-set (not full attribute
+ definitions, just names).
+ type: array
+ items:
+ type: string
+ reply: *subop-attr-list
+ pre:
+ description: Hook for a function to run before the main callback (pre_doit or start).
+ 