Merge tag 'docs-5.11-2' of git://git.lwn.net/linux
Pull documentation fixes from Jonathan Corbet:
"A small set of late-arriving, small documentation fixes"
* tag 'docs-5.11-2' of git://git.lwn.net/linux:
docs: admin-guide: Fix default value of max_map_count in sysctl/vm.rst
Documentation/submitting-patches: Document the SoB chain
Documentation: process: Correct numbering
docs: submitting-patches: Trivial - fix grammatical error
diff --git a/.mailmap b/.mailmap
index 1e14566..632700c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -82,7 +82,10 @@
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>
-Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
+Dmitry Baryshkov <dbaryshkov@gmail.com>
+Dmitry Baryshkov <dbaryshkov@gmail.com> <[dbaryshkov@gmail.com]>
+Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_baryshkov@mentor.com>
+Dmitry Baryshkov <dbaryshkov@gmail.com> <dmitry_eremin@mentor.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
@@ -119,6 +122,8 @@
Henrik Kretzschmar <henne@nachtwindheim.de>
Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
+Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
+Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
Jacob Shin <Jacob.Shin@amd.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
@@ -287,6 +292,7 @@
Sarangdhar Joshi <spjoshi@codeaurora.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
+Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
@@ -318,6 +324,8 @@
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
+Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Uwe Kleine-König <ukleinek@strlen.de>
Uwe Kleine-König <ukl@pengutronix.de>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
@@ -337,3 +345,4 @@
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
Yusuke Goda <goda.yusuke@renesas.com>
+Zhu Yanjun <zyjzyj2000@gmail.com> <yanjunz@nvidia.com>
diff --git a/CREDITS b/CREDITS
index 8592e45..090ed4b 100644
--- a/CREDITS
+++ b/CREDITS
@@ -98,7 +98,7 @@
E: andersen@codepoet.org
W: https://www.codepoet.org/
P: 1024D/30D39057 1BC4 2742 E885 E4DE 9301 0C82 5F9B 643E 30D3 9057
-D: Maintainer of ide-cd and Uniform CD-ROM driver,
+D: Maintainer of ide-cd and Uniform CD-ROM driver,
D: ATAPI CD-Changer support, Major 2.1.x CD-ROM update.
S: 352 North 525 East
S: Springville, Utah 84663
@@ -263,7 +263,7 @@
E: pbd@op.net
D: Driver for WaveFront soundcards (Turtle Beach Maui, Tropez, Tropez+)
D: Various bugfixes and changes to sound drivers
-S: USA
+S: USA
N: Carlos Henrique Bauer
E: chbauer@acm.org
@@ -740,6 +740,11 @@
S: Portland, Oregon
S: USA
+N: Jason Cooper
+D: ARM/Marvell SOC co-maintainer
+D: irqchip co-maintainer
+D: MVEBU PCI DRIVER co-maintainer
+
N: Robin Cornelius
E: robincornelius@users.sourceforge.net
D: Ralink rt2x00 WLAN driver
@@ -849,6 +854,12 @@
D: AX25-HOWTO, HAM-HOWTO, IPX-HOWTO, NET-2-HOWTO
D: ax25-utils maintainer.
+N: Kamil Debski
+E: kamil@wypas.org
+D: Samsung S5P 2D graphics acceleration and Multi Format Codec drivers
+D: Samsung USB2 phy drivers
+D: PWM fan driver
+
N: Helge Deller
E: deller@gmx.de
W: http://www.parisc-linux.org/
@@ -1199,7 +1210,7 @@
E: dfrasnel@alphalinux.org
W: http://www.alphalinux.org/
P: 1024/3EF87611 B9 F1 44 50 D3 E8 C2 80 DA E5 55 AA 56 7C 42 DA
-D: DEC Alpha hacker
+D: DEC Alpha hacker
D: Miscellaneous bug squisher
N: Jim Freeman
@@ -1299,7 +1310,7 @@
S: New South Wales, 2121
S: Australia
-N: Carlos E. Gorges
+N: Carlos E. Gorges
E: carlos@techlinux.com.br
D: fix smp support on cmpci driver
P: 2048G/EA3C4B19 FF31 33A6 0362 4915 B7EB E541 17D0 0379 EA3C 4B19
@@ -1340,7 +1351,7 @@
E: wgreathouse@myfavoritei.com
D: Current Belkin USB Serial Adapter F5U103 hacker
D: Kernel hacker, embedded systems
-S: 7802 Fitzwater Road
+S: 7802 Fitzwater Road
S: Brecksville, OH 44141-1334
S: USA
@@ -1381,7 +1392,7 @@
E: grant@torque.net
W: http://www.torque.net/linux-pp.html
D: original author of ppa driver for parallel port ZIP drive
-D: original architect of the parallel-port sharing scheme
+D: original architect of the parallel-port sharing scheme
D: PARIDE subsystem: drivers for parallel port IDE & ATAPI devices
S: 44 St. Joseph Street, Suite 506
S: Toronto, Ontario, M4Y 2W4
@@ -1523,7 +1534,7 @@
E: benh@kernel.crashing.org
D: Various parts of PPC/PPC64 & PowerMac
S: 312/107 Canberra Avenue
-S: Griffith, ACT 2603
+S: Griffith, ACT 2603
S: Australia
N: Andreas Herrmann
@@ -1825,7 +1836,7 @@
N: Bernhard Kaindl
E: bkaindl@netway.at
E: edv@bartelt.via.at
-D: Author of a menu based configuration tool, kmenu, which
+D: Author of a menu based configuration tool, kmenu, which
D: is the predecessor of 'make menuconfig' and 'make xconfig'.
D: digiboard driver update(modularisation work and 2.1.x upd)
S: Tallak 95
@@ -2016,7 +2027,7 @@
D: IP transparent proxy support
S: X/OS Experts in Open Systems BV
S: Kruislaan 419
-S: 1098 VA Amsterdam
+S: 1098 VA Amsterdam
S: The Netherlands
N: Goran Koruga
@@ -2088,7 +2099,7 @@
N: Andrzej M. Krzysztofowicz
E: ankry@mif.pg.gda.pl
-D: Some 8-bit XT disk driver and devfs hacking
+D: Some 8-bit XT disk driver and devfs hacking
D: Aladdin 1533/1543(C) chipset IDE
D: PIIX chipset IDE
S: ul. Matemblewska 1B/10
@@ -2463,7 +2474,7 @@
D: Logical Volume Manager
S: Bartningstr. 12
S: 64289 Darmstadt
-S: Germany
+S: Germany
N: Mark W. McClelland
E: mmcclell@bigfoot.com
@@ -2499,15 +2510,6 @@
D: RCU and variants
D: rcutorture module
-N: Mike McLagan
-E: mike.mclagan@linux.org
-W: http://www.invlogic.com/~mmclagan
-D: DLCI/FRAD drivers for Sangoma SDLAs
-S: Innovative Logic Corp
-S: Post Office Box 1068
-S: Laurel, Maryland 20732
-S: USA
-
N: Bradley McLean
E: brad@bradpc.gaylord.com
D: Device driver hacker
@@ -2547,7 +2549,7 @@
P: 1024/04B6E8F5 6C 77 33 CA CC D6 22 03 AB AB 15 A3 AE AD 39 7D
D: Kernel hacker. PostgreSQL hacker. Software watchdog daemon.
D: Maintainer of several Debian packages
-S: Th.-Heuss-Str. 61
+S: Th.-Heuss-Str. 61
S: D-41812 Erkelenz
S: Germany
@@ -2785,7 +2787,7 @@
W: http://www.i-Connect.Net/~mike/
D: Developer and maintainer of the EATA-DMA SCSI driver
D: Co-developer EATA-PIO SCSI driver
-D: /proc/scsi and assorted other snippets
+D: /proc/scsi and assorted other snippets
S: Zum Schiersteiner Grund 2
S: 55127 Mainz
S: Germany
@@ -2852,6 +2854,10 @@
N: Venkatesh Pallipadi (Venki)
D: x86/HPET
+N: Kyungmin Park
+E: kyungmin.park@samsung.com
+D: Samsung S5Pv210 and Exynos4210 mobile platforms
+
N: David Parsons
E: orc@pell.chi.il.us
D: improved memory detection code.
@@ -3019,7 +3025,7 @@
S: Chandler, Arizona 85249
S: USA
-N: Frederic Potter
+N: Frederic Potter
E: fpotter@cirpack.com
D: Some PCI kernel support
@@ -3452,21 +3458,21 @@
S: 76131 Karlsruhe
S: Germany
-N: James Simmons
+N: James Simmons
E: jsimmons@infradead.org
-E: jsimmons@users.sf.net
+E: jsimmons@users.sf.net
D: Frame buffer device maintainer
D: input layer development
D: tty/console layer
-D: various mipsel devices
-S: 115 Carmel Avenue
+D: various mipsel devices
+S: 115 Carmel Avenue
S: El Cerrito CA 94530
-S: USA
+S: USA
N: Jaspreet Singh
E: jaspreet@sangoma.com
W: www.sangoma.com
-D: WANPIPE drivers & API Support for Sangoma S508/FT1 cards
+D: WANPIPE drivers & API Support for Sangoma S508/FT1 cards
S: Sangoma Technologies Inc.,
S: 1001 Denison Street
S: Suite 101
@@ -3490,7 +3496,7 @@
E: csmall@triode.apana.org.au
E: vk2xlz@gonzo.vk2xlz.ampr.org (packet radio)
D: Gracilis PackeTwin device driver
-D: RSPF daemon
+D: RSPF daemon
S: 10 Stockalls Place
S: Minto, NSW, 2566
S: Australia
@@ -3700,7 +3706,7 @@
E: tsusheng@scf.usc.edu
D: IGMP(Internet Group Management Protocol) version 2
S: 2F 14 ALY 31 LN 166 SEC 1 SHIH-PEI RD
-S: Taipei
+S: Taipei
S: Taiwan 112
S: Republic of China
S: 24335 Delta Drive
@@ -3861,7 +3867,7 @@
D: patches for ghostscript, worked on color 'ls', etc.
S: 301 15th Street S.
S: Moorhead, Minnesota 56560
-S: USA
+S: USA
N: Jos Vos
E: jos@xos.nl
@@ -3869,7 +3875,7 @@
D: Various IP firewall updates, ipfwadm
S: X/OS Experts in Open Systems BV
S: Kruislaan 419
-S: 1098 VA Amsterdam
+S: 1098 VA Amsterdam
S: The Netherlands
N: Jeroen Vreeken
@@ -4107,7 +4113,7 @@
N: Victor Yodaiken
E: yodaiken@fsmlabs.com
D: RTLinux (RealTime Linux)
-S: POB 1822
+S: POB 1822
S: Socorro NM, 87801
S: USA
@@ -4205,7 +4211,7 @@
S: France
# Don't add your name here, unless you really _are_ after Marc
-# alphabetically. Leonard used to be very proud of being the
+# alphabetically. Leonard used to be very proud of being the
# last entry, and he'll get positively pissed if he can't even
# be second-to-last. (and this file really _is_ supposed to be
# in alphabetic order)
diff --git a/Documentation/ABI/obsolete/sysfs-class-net-batman-adv b/Documentation/ABI/obsolete/sysfs-class-net-batman-adv
deleted file mode 100644
index 5bdbc8d..0000000
--- a/Documentation/ABI/obsolete/sysfs-class-net-batman-adv
+++ /dev/null
@@ -1,32 +0,0 @@
-This ABI is deprecated and will be removed after 2021. It is
-replaced with the batadv generic netlink family.
-
-What: /sys/class/net/<iface>/batman-adv/elp_interval
-Date: Feb 2014
-Contact: Linus Lüssing <linus.luessing@web.de>
-Description:
- Defines the interval in milliseconds in which batman
- emits probing packets for neighbor sensing (ELP).
-
-What: /sys/class/net/<iface>/batman-adv/iface_status
-Date: May 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Indicates the status of <iface> as it is seen by batman.
-
-What: /sys/class/net/<iface>/batman-adv/mesh_iface
-Date: May 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- The /sys/class/net/<iface>/batman-adv/mesh_iface file
- displays the batman mesh interface this <iface>
- currently is associated with.
-
-What: /sys/class/net/<iface>/batman-adv/throughput_override
-Date: Feb 2014
-Contact: Antonio Quartulli <a@unstable.cc>
-description:
- Defines the throughput value to be used by B.A.T.M.A.N. V
- when estimating the link throughput using this interface.
- If the value is set to 0 then batman-adv will try to
- estimate the throughput by itself.
diff --git a/Documentation/ABI/obsolete/sysfs-class-net-mesh b/Documentation/ABI/obsolete/sysfs-class-net-mesh
deleted file mode 100644
index 04c1a29..0000000
--- a/Documentation/ABI/obsolete/sysfs-class-net-mesh
+++ /dev/null
@@ -1,110 +0,0 @@
-This ABI is deprecated and will be removed after 2021. It is
-replaced with the batadv generic netlink family.
-
-What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
-Date: May 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Indicates whether the batman protocol messages of the
- mesh <mesh_iface> shall be aggregated or not.
-
-What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
-Date: May 2011
-Contact: Antonio Quartulli <a@unstable.cc>
-Description:
- Indicates whether the data traffic going from a
- wireless client to another wireless client will be
- silently dropped. <vlan_subdir> is empty when referring
- to the untagged lan.
-
-What: /sys/class/net/<mesh_iface>/mesh/bonding
-Date: June 2010
-Contact: Simon Wunderlich <sw@simonwunderlich.de>
-Description:
- Indicates whether the data traffic going through the
- mesh will be sent using multiple interfaces at the
- same time (if available).
-
-What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
-Date: November 2011
-Contact: Simon Wunderlich <sw@simonwunderlich.de>
-Description:
- Indicates whether the bridge loop avoidance feature
- is enabled. This feature detects and avoids loops
- between the mesh and devices bridged with the soft
- interface <mesh_iface>.
-
-What: /sys/class/net/<mesh_iface>/mesh/fragmentation
-Date: October 2010
-Contact: Andreas Langer <an.langer@gmx.de>
-Description:
- Indicates whether the data traffic going through the
- mesh will be fragmented or silently discarded if the
- packet size exceeds the outgoing interface MTU.
-
-What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
-Date: October 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Defines the bandwidth which is propagated by this
- node if gw_mode was set to 'server'.
-
-What: /sys/class/net/<mesh_iface>/mesh/gw_mode
-Date: October 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Defines the state of the gateway features. Can be
- either 'off', 'client' or 'server'.
-
-What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
-Date: October 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Defines the selection criteria this node will use
- to choose a gateway if gw_mode was set to 'client'.
-
-What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
-Date: Oct 2010
-Contact: Linus Lüssing <linus.luessing@web.de>
-Description:
- Defines the penalty which will be applied to an
- originator message's tq-field on every hop.
-
-What: /sys/class/net/<mesh_iface>/mesh/isolation_mark
-Date: Nov 2013
-Contact: Antonio Quartulli <a@unstable.cc>
-Description:
- Defines the isolation mark (and its bitmask) which
- is used to classify clients as "isolated" by the
- Extended Isolation feature.
-
-What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
-Date: Feb 2014
-Contact: Linus Lüssing <linus.luessing@web.de>
-Description:
- Indicates whether multicast optimizations are enabled
- or disabled. If set to zero then all nodes in the
- mesh are going to use classic flooding for any
- multicast packet with no optimizations.
-
-What: /sys/class/net/<mesh_iface>/mesh/network_coding
-Date: Nov 2012
-Contact: Martin Hundeboll <martin@hundeboll.net>
-Description:
- Controls whether Network Coding (using some magic
- to send fewer wifi packets but still the same
- content) is enabled or not.
-
-What: /sys/class/net/<mesh_iface>/mesh/orig_interval
-Date: May 2010
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Defines the interval in milliseconds in which batman
- sends its protocol messages.
-
-What: /sys/class/net/<mesh_iface>/mesh/routing_algo
-Date: Dec 2011
-Contact: Marek Lindner <mareklindner@neomailbox.ch>
-Description:
- Defines the routing procotol this mesh instance
- uses to find the optimal paths through the mesh.
diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd
index b441838..55285c1 100644
--- a/Documentation/ABI/stable/sysfs-driver-dma-idxd
+++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd
@@ -77,6 +77,13 @@
Description: The operation capability bit mask specify the operation types
supported by the this device.
+What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled
+Date: Oct 27, 2020
+KernelVersion: 5.11.0
+Contact: dmaengine@vger.kernel.org
+Description: To indicate if PASID (process address space identifier) is
+ enabled or not for this device.
+
What: /sys/bus/dsa/devices/dsa<m>/state
Date: Oct 25, 2019
KernelVersion: 5.6.0
@@ -122,6 +129,13 @@
Contact: dmaengine@vger.kernel.org
Description: The last executed device administrative command's status/error.
+What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
+Date: Oct 27, 2020
+KernelVersion: 5.11.0
+Contact: dmaengine@vger.kernel.org
+Description: To indicate block on fault is allowed or not for the work queue
+ to support on demand paging.
+
What: /sys/bus/dsa/devices/wq<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
@@ -190,6 +204,13 @@
Description: The max batch size for this workqueue. Cannot exceed device
max batch size. Configurable parameter.
+What: /sys/bus/dsa/devices/wq<m>.<n>/ats_disable
+Date: Nov 13, 2020
+KernelVersion: 5.11.0
+Contact: dmaengine@vger.kernel.org
+Description: Indicate whether ATS disable is turned on for the workqueue.
+ 0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
+
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index df42bed..35289d4 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1743,6 +1743,16 @@
Raw counter device counters direction for channel Y.
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_label
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_label
+KernelVersion: 5.8
+Contact: linux-iio@vger.kernel.org
+Description:
+ Optional symbolic label to a device channel.
+ If a label is defined for this channel add that to the channel
+ specific attributes. This is useful for userspace to be able to
+ better identify an individual channel.
+
What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360
new file mode 100644
index 0000000..e5a7b1c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360
@@ -0,0 +1,78 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage0_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 USBID ADC which connected to connector ID pin.
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage1_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 VBUS ADC with lower accuracy(+-75mA)
+ higher measure range(1~22mV)
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage2_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 VBUS ADC with higher accuracy(+-30mA)
+ lower measure range(1~9.76V)
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage3_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 VSYS ADC
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage4_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 VBAT ADC
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_current5_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 IBUS ADC
+ Calculating with scale and offset returns voltage in uA
+
+What: /sys/bus/iio/devices/iio:deviceX/in_current6_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 IBAT ADC
+ Calculating with scale and offset returns voltage in uA
+
+What: /sys/bus/iio/devices/iio:deviceX/in_current7_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 CHG_VDDP ADC
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_temp8_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 IC junction temperature
+ Calculating with scale and offset returns temperature in degree
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage9_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 VREF_TS ADC
+ Calculating with scale and offset returns voltage in uV
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage10_raw
+KernelVersion: 5.8.0
+Contact: gene_chen@richtek.com
+Description:
+ Indicated MT6360 TS ADC
+ Calculating with scale and offset returns voltage in uV
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
index a10a4de..c4a4497 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
+++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
@@ -109,30 +109,6 @@
When counting down the counter start from preset value
and fire event when reach 0.
-What: /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available
-KernelVersion: 4.12
-Contact: benjamin.gaignard@st.com
-Description:
- Reading returns the list possible quadrature modes.
-
-What: /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode
-KernelVersion: 4.12
-Contact: benjamin.gaignard@st.com
-Description:
- Configure the device counter quadrature modes:
-
- channel_A:
- Encoder A input servers as the count input and B as
- the UP/DOWN direction control input.
-
- channel_B:
- Encoder B input serves as the count input and A as
- the UP/DOWN direction control input.
-
- quadrature:
- Encoder A and B inputs are mixed to get direction
- and count with a scale of 0.25.
-
What: /sys/bus/iio/devices/iio:deviceX/in_count_enable_mode_available
KernelVersion: 4.12
Contact: benjamin.gaignard@st.com
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 77ad9ec..25c9c39 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -366,3 +366,12 @@
Description: If ASPM is supported for an endpoint, these files can be
used to disable or enable the individual power management
states. Write y/1/on to enable, n/0/off to disable.
+
+What: /sys/bus/pci/devices/.../power_state
+Date: November 2020
+Contact: Linux PCI developers <linux-pci@vger.kernel.org>
+Description:
+ This file contains the current PCI power state of the device.
+ The value comes from the PCI kernel device state and can be one
+ of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold".
+ The file is read only.
diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index 0b4ab9e..a91b4b2 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -1,3 +1,31 @@
+What: /sys/bus/thunderbolt/devices/<xdomain>/rx_speed
+Date: Feb 2021
+KernelVersion: 5.11
+Contact: Isaac Hazan <isaac.hazan@intel.com>
+Description: This attribute reports the XDomain RX speed per lane.
+ All RX lanes run at the same speed.
+
+What: /sys/bus/thunderbolt/devices/<xdomain>/rx_lanes
+Date: Feb 2021
+KernelVersion: 5.11
+Contact: Isaac Hazan <isaac.hazan@intel.com>
+Description: This attribute reports the number of RX lanes the XDomain
+ is using simultaneously through its upstream port.
+
+What: /sys/bus/thunderbolt/devices/<xdomain>/tx_speed
+Date: Feb 2021
+KernelVersion: 5.11
+Contact: Isaac Hazan <isaac.hazan@intel.com>
+Description: This attribute reports the XDomain TX speed per lane.
+ All TX lanes run at the same speed.
+
+What: /sys/bus/thunderbolt/devices/<xdomain>/tx_lanes
+Date: Feb 2021
+KernelVersion: 5.11
+Contact: Isaac Hazan <isaac.hazan@intel.com>
+Description: This attribute reports number of TX lanes the XDomain
+ is using simultaneously through its upstream port.
+
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
Date: Jun 2018
KernelVersion: 4.17
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq
index b8ebff4..386bc23 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -37,20 +37,6 @@
The /sys/class/devfreq/.../target_freq shows the next governor
predicted target frequency of the corresponding devfreq object.
-What: /sys/class/devfreq/.../polling_interval
-Date: September 2011
-Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
-Description:
- The /sys/class/devfreq/.../polling_interval shows and sets
- the requested polling interval of the corresponding devfreq
- object. The values are represented in ms. If the value is
- less than 1 jiffy, it is considered to be 0, which means
- no polling. This value is meaningless if the governor is
- not polling; thus. If the governor is not using
- devfreq-provided central polling
- (/sys/class/devfreq/.../central_polling is 0), this value
- may be useless.
-
What: /sys/class/devfreq/.../trans_stat
Date: October 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
@@ -66,14 +52,6 @@
echo 0 > /sys/class/devfreq/.../trans_stat
-What: /sys/class/devfreq/.../userspace/set_freq
-Date: September 2011
-Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
-Description:
- The /sys/class/devfreq/.../userspace/set_freq shows and
- sets the requested frequency for the devfreq object if
- userspace governor is in effect.
-
What: /sys/class/devfreq/.../available_frequencies
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
@@ -110,6 +88,35 @@
The max_freq overrides min_freq because max_freq may be
used to throttle devices to avoid overheating.
+What: /sys/class/devfreq/.../polling_interval
+Date: September 2011
+Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+ The /sys/class/devfreq/.../polling_interval shows and sets
+ the requested polling interval of the corresponding devfreq
+ object. The values are represented in ms. If the value is
+ less than 1 jiffy, it is considered to be 0, which means
+ no polling. This value is meaningless if the governor is
+ not polling; thus. If the governor is not using
+ devfreq-provided central polling
+ (/sys/class/devfreq/.../central_polling is 0), this value
+ may be useless.
+
+ A list of governors that support the node:
+ - simple_ondmenad
+ - tegra_actmon
+
+What: /sys/class/devfreq/.../userspace/set_freq
+Date: September 2011
+Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+ The /sys/class/devfreq/.../userspace/set_freq shows and
+ sets the requested frequency for the devfreq object if
+ userspace governor is in effect.
+
+ A list of governors that support the node:
+ - userspace
+
What: /sys/class/devfreq/.../timer
Date: July 2020
Contact: Chanwoo Choi <cw00.choi@samsung.com>
@@ -122,3 +129,6 @@
echo deferrable > /sys/class/devfreq/.../timer
echo delayed > /sys/class/devfreq/.../timer
+
+ A list of governors that support the node:
+ - simple_ondemand
diff --git a/Documentation/ABI/testing/sysfs-class-fc_host b/Documentation/ABI/testing/sysfs-class-fc_host
new file mode 100644
index 0000000..0a696cb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fc_host
@@ -0,0 +1,23 @@
+What: /sys/class/fc_host/hostX/statistics/fpin_cn_yyy
+Date: July 2020
+Contact: Shyam Sundar <ssundar@marvell.com>
+Description:
+ These files contain the number of congestion notification
+ events recorded by the F_Port, reported using fabric
+ performance impact notification (FPIN) event.
+
+What: /sys/class/fc_host/hostX/statistics/fpin_li_yyy
+Date: July 2020
+Contact: Shyam Sundar <ssundar@marvell.com>
+Description:
+ These files contain the number of link integrity error
+ events recorded by the F_Port/Nx_Port, reported using fabric
+ performance impact notification (FPIN) event.
+
+What: /sys/class/fc_host/hostX/statistics/fpin_dn_yyy
+Date: July 2020
+Contact: Shyam Sundar <ssundar@marvell.com>
+Description:
+ These files contain the number of delivery related errors
+ recorded by the F_Port/Nx_Port, reported using fabric
+ performance impact notification (FPIN) event.
diff --git a/Documentation/ABI/testing/sysfs-class-fc_remote_ports b/Documentation/ABI/testing/sysfs-class-fc_remote_ports
new file mode 100644
index 0000000..55a9515
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fc_remote_ports
@@ -0,0 +1,23 @@
+What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_cn_yyy
+Date: July 2020
+Contact: Shyam Sundar <ssundar@marvell.com>
+Description:
+ These files contain the number of congestion notification
+ events recorded by the F_Port/Nx_Port, reported using fabric
+ performance impact notification (FPIN) event.
+
+What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_li_yyy
+Date: July 2020
+Contact: Shyam Sundar <ssundar@marvell.com>
+Description:
+ These files contain the number of link integrity error
+ events recorded by the F_Port/Nx_Port, reported using fabric
+ performance impact notification (FPIN) event.
+
+What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_dn_yyy
+Date: July 2020
+Contact: Shyam Sundar <ssundar@marvell.com>
+Description:
+ These files contain the number of delivery related errors
+ recorded by the F_Port/Nx_Port, reported using fabric
+ performance impact notification (FPIN) event.
diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
new file mode 100644
index 0000000..8ea59fe
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
@@ -0,0 +1,258 @@
+What: /sys/class/firmware-attributes/*/attributes/*/
+Date: February 2021
+KernelVersion: 5.11
+Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
+ Mario Limonciello <mario.limonciello@dell.com>,
+ Prasanth KSR <prasanth.ksr@dell.com>
+Description:
+ A sysfs interface for systems management software to enable
+ configuration capability on supported systems. This directory
+ exposes interfaces for interacting with configuration options.
+
+ Unless otherwise specified in an attribute description all attributes are optional
+ and will accept UTF-8 input.
+
+ type:
+ A file that can be read to obtain the type of attribute.
+ This attribute is mandatory.
+
+ The following are known types:
+
+ - enumeration: a set of pre-defined valid values
+ - integer: a range of numerical values
+ - string
+
+ All attribute types support the following values:
+
+ current_value:
+ A file that can be read to obtain the current
+ value of the <attr>.
+
+ This file can also be written to in order to update the value of a
+ <attr>
+
+ This attribute is mandatory.
+
+ default_value:
+ A file that can be read to obtain the default
+ value of the <attr>
+
+ display_name:
+ A file that can be read to obtain a user friendly
+ description of the at <attr>
+
+ display_name_language_code:
+ A file that can be read to obtain
+ the IETF language tag corresponding to the
+ "display_name" of the <attr>
+
+ "enumeration"-type specific properties:
+
+ possible_values:
+ A file that can be read to obtain the possible
+ values of the <attr>. Values are separated using
+ semi-colon (``;``).
+
+ "integer"-type specific properties:
+
+ min_value:
+ A file that can be read to obtain the lower
+ bound value of the <attr>
+
+ max_value:
+ A file that can be read to obtain the upper
+ bound value of the <attr>
+
+ scalar_increment:
+ A file that can be read to obtain the scalar value used for
+ increments of current_value this attribute accepts.
+
+ "string"-type specific properties:
+
+ max_length:
+ A file that can be read to obtain the maximum
+ length value of the <attr>
+
+ min_length:
+ A file that can be read to obtain the minimum
+ length value of the <attr>
+
+ Dell specific class extensions
+ ------------------------------
+
+ On Dell systems the following additional attributes are available:
+
+ dell_modifier:
+ A file that can be read to obtain attribute-level
+ dependency rule. It says an attribute X will become read-only or
+ suppressed, if/if-not attribute Y is configured.
+
+ modifier rules can be in following format::
+
+ [ReadOnlyIf:<attribute>=<value>]
+ [ReadOnlyIfNot:<attribute>=<value>]
+ [SuppressIf:<attribute>=<value>]
+ [SuppressIfNot:<attribute>=<value>]
+
+ For example::
+
+ AutoOnFri/dell_modifier has value,
+ [SuppressIfNot:AutoOn=SelectDays]
+
+ This means AutoOnFri will be suppressed in BIOS setup if AutoOn
+ attribute is not "SelectDays" and its value will not be effective
+ through sysfs until this rule is met.
+
+ Enumeration attributes also support the following:
+
+ dell_value_modifier:
+ A file that can be read to obtain value-level dependency.
+ This file is similar to dell_modifier but here, an
+ attribute's current value will be forcefully changed based
+ dependent attributes value.
+
+ dell_value_modifier rules can be in following format::
+
+ <value>[ForceIf:<attribute>=<value>]
+ <value>[ForceIfNot:<attribute>=<value>]
+
+ For example:
+
+ LegacyOrom/dell_value_modifier has value:
+ Disabled[ForceIf:SecureBoot=Enabled]
+
+ This means LegacyOrom's current value will be forced to
+ "Disabled" in BIOS setup if SecureBoot is Enabled and its
+ value will not be effective through sysfs until this rule is
+ met.
+
+What: /sys/class/firmware-attributes/*/authentication/
+Date: February 2021
+KernelVersion: 5.11
+Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
+ Mario Limonciello <mario.limonciello@dell.com>,
+ Prasanth KSR <prasanth.ksr@dell.com>
+Description:
+ Devices support various authentication mechanisms which can be exposed
+ as a separate configuration object.
+
+ For example a "BIOS Admin" password and "System" Password can be set,
+ reset or cleared using these attributes.
+
+ - An "Admin" password is used for preventing modification to the BIOS
+ settings.
+ - A "System" password is required to boot a machine.
+
+ Change in any of these two authentication methods will also generate an
+ uevent KOBJ_CHANGE.
+
+ is_enabled:
+ A file that can be read to obtain a 0/1 flag to see if
+ <attr> authentication is enabled.
+ This attribute is mandatory.
+
+ role:
+ The type of authentication used.
+ This attribute is mandatory.
+
+ Known types:
+ bios-admin:
+ Representing BIOS administrator password
+ power-on:
+ Representing a password required to use
+ the system
+
+ mechanism:
+ The means of authentication. This attribute is mandatory.
+ Only supported type currently is "password".
+
+ max_password_length:
+ A file that can be read to obtain the
+ maximum length of the Password
+
+ min_password_length:
+ A file that can be read to obtain the
+ minimum length of the Password
+
+ current_password:
+ A write only value used for privileged access such as
+ setting attributes when a system or admin password is set
+ or resetting to a new password
+
+ This attribute is mandatory when mechanism == "password".
+
+ new_password:
+ A write only value that when used in tandem with
+ current_password will reset a system or admin password.
+
+ Note, password management is session specific. If Admin password is set,
+ same password must be written into current_password file (required for
+ password-validation) and must be cleared once the session is over.
+ For example::
+
+ echo "password" > current_password
+ echo "disabled" > TouchScreen/current_value
+ echo "" > current_password
+
+ Drivers may emit a CHANGE uevent when a password is set or unset
+ userspace may check it again.
+
+ On Dell systems, if Admin password is set, then all BIOS attributes
+ require password validation.
+
+What: /sys/class/firmware-attributes/*/attributes/pending_reboot
+Date: February 2021
+KernelVersion: 5.11
+Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
+ Mario Limonciello <mario.limonciello@dell.com>,
+ Prasanth KSR <prasanth.ksr@dell.com>
+Description:
+ A read-only attribute reads 1 if a reboot is necessary to apply
+ pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is
+ generated when it changes to 1.
+
+ == =========================================
+ 0 All BIOS attributes setting are current
+ 1 A reboot is necessary to get pending BIOS
+ attribute changes applied
+ == =========================================
+
+ Note, userspace applications need to follow below steps for efficient
+ BIOS management,
+
+ 1. Check if admin password is set. If yes, follow session method for
+ password management as briefed under authentication section above.
+ 2. Before setting any attribute, check if it has any modifiers
+ or value_modifiers. If yes, incorporate them and then modify
+ attribute.
+
+ Drivers may emit a CHANGE uevent when this value changes and userspace
+ may check it again.
+
+What: /sys/class/firmware-attributes/*/attributes/reset_bios
+Date: February 2021
+KernelVersion: 5.11
+Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
+ Mario Limonciello <mario.limonciello@dell.com>,
+ Prasanth KSR <prasanth.ksr@dell.com>
+Description:
+ This attribute can be used to reset the BIOS Configuration.
+ Specifically, it tells which type of reset BIOS configuration is being
+ requested on the host.
+
+ Reading from it returns a list of supported options encoded as:
+
+ - 'builtinsafe' (Built in safe configuration profile)
+ - 'lastknowngood' (Last known good saved configuration profile)
+ - 'factory' (Default factory settings configuration profile)
+ - 'custom' (Custom saved configuration profile)
+
+ The currently selected option is printed in square brackets as
+ shown below::
+
+ # echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios
+ # cat /sys/class/firmware-attributes/*/device/attributes/reset_bios
+ # builtinsafe lastknowngood [factory] custom
+
+ Note that any changes to this attribute requires a reboot
+ for changes to take effect.
diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt b/Documentation/ABI/testing/sysfs-class-intel_pmt
new file mode 100644
index 0000000..ed4c886
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-intel_pmt
@@ -0,0 +1,119 @@
+What: /sys/class/intel_pmt/
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ The intel_pmt/ class directory contains information for
+ devices that expose hardware telemetry using Intel Platform
+ Monitoring Technology (PMT)
+
+What: /sys/class/intel_pmt/telem<x>
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ The telem<x> directory contains files describing an instance of
+ a PMT telemetry device that exposes hardware telemetry. Each
+ telem<x> directory has an associated telem file. This file
+ may be opened and mapped or read to access the telemetry space
+ of the device. The register layout of the telemetry space is
+ determined from an XML file that matches the PCI device id and
+ GUID for the device.
+
+What: /sys/class/intel_pmt/telem<x>/telem
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ (RO) The telemetry data for this telemetry device. This file
+ may be mapped or read to obtain the data.
+
+What: /sys/class/intel_pmt/telem<x>/guid
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ (RO) The GUID for this telemetry device. The GUID identifies
+ the version of the XML file for the parent device that is to
+ be used to get the register layout.
+
+What: /sys/class/intel_pmt/telem<x>/size
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ (RO) The size of telemetry region in bytes that corresponds to
+ the mapping size for the telem file.
+
+What: /sys/class/intel_pmt/telem<x>/offset
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ (RO) The offset of telemetry region in bytes that corresponds to
+ the mapping for the telem file.
+
+What: /sys/class/intel_pmt/crashlog<x>
+Date: October 2020
+KernelVersion: 5.10
+Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+ The crashlog<x> directory contains files for configuring an
+ instance of a PMT crashlog device that can perform crash data
+ recording. Each crashlog<x> device has an associated crashlog
+ file. This file can be opened and mapped or read to access the
+ resulting crashlog buffer. The register layout for the buffer
+ can be determined from an XML file of specified GUID for the
+ parent device.
+
+What: /sys/class/intel_pmt/crashlog<x>/crashlog
+Date: October 2020
+KernelVersion: 5.10
+Contact: David Box <david.e.box@linux.intel.com>
+Description:
+ (RO) The crashlog buffer for this crashlog device. This file
+ may be mapped or read to obtain the data.
+
+What: /sys/class/intel_pmt/crashlog<x>/guid
+Date: October 2020
+KernelVersion: 5.10
+Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+ (RO) The GUID for this crashlog device. The GUID identifies the
+ version of the XML file for the parent device that should be
+ used to determine the register layout.
+
+What: /sys/class/intel_pmt/crashlog<x>/size
+Date: October 2020
+KernelVersion: 5.10
+Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+ (RO) The length of the result buffer in bytes that corresponds
+ to the size for the crashlog buffer.
+
+What: /sys/class/intel_pmt/crashlog<x>/offset
+Date: October 2020
+KernelVersion: 5.10
+Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+ (RO) The offset of the buffer in bytes that corresponds
+ to the mapping for the crashlog device.
+
+What: /sys/class/intel_pmt/crashlog<x>/enable
+Date: October 2020
+KernelVersion: 5.10
+Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+ (RW) Boolean value controlling if the crashlog functionality
+ is enabled for the crashlog device.
+
+What: /sys/class/intel_pmt/crashlog<x>/trigger
+Date: October 2020
+KernelVersion: 5.10
+Contact: Alexander Duyck <alexander.h.duyck@linux.intel.com>
+Description:
+ (RW) Boolean value controlling the triggering of the crashlog
+ device node. When read it provides data on if the crashlog has
+ been triggered. When written to it can be used to either clear
+ the current trigger by writing false, or to trigger a new
+ event if the trigger is not currently set.
diff --git a/Documentation/ABI/testing/sysfs-class-rnbd-client b/Documentation/ABI/testing/sysfs-class-rnbd-client
index 00c0286..2aa05b3 100644
--- a/Documentation/ABI/testing/sysfs-class-rnbd-client
+++ b/Documentation/ABI/testing/sysfs-class-rnbd-client
@@ -66,7 +66,7 @@
The rnbd_server prepends the <device_path> received from client
with <dev_search_path> and tries to open the
<dev_search_path>/<device_path> block device. On success,
- a /dev/rnbd<N> device file, a /sys/block/rnbd_client/rnbd<N>/
+ a /dev/rnbd<N> device file, a /sys/block/rnbd<N>/
directory and an entry in /sys/class/rnbd-client/ctl/devices
will be created.
@@ -95,12 +95,12 @@
---------------------------------
After mapping, the device file can be found by:
- o The symlink /sys/class/rnbd-client/ctl/devices/<device_id>
+ o The symlink /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>
points to /sys/block/<dev-name>. The last part of the symlink destination
is the same as the device name. By extracting the last part of the
path the path to the device /dev/<dev-name> can be build.
- * /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>/dev)
+ * /dev/block/$(cat /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>/dev)
How to find the <device_id> of the device is described on the next
section.
@@ -110,7 +110,7 @@
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: For each device mapped on the client a new symbolic link is created as
- /sys/class/rnbd-client/ctl/devices/<device_id>, which points
+ /sys/class/rnbd-client/ctl/devices/<device_id>@<session_name>, which points
to the block device created by rnbd (/sys/block/rnbd<N>/).
The <device_id> of each device is created as follows:
diff --git a/Documentation/ABI/testing/sysfs-class-rnbd-server b/Documentation/ABI/testing/sysfs-class-rnbd-server
index ba60a90..6c5996c 100644
--- a/Documentation/ABI/testing/sysfs-class-rnbd-server
+++ b/Documentation/ABI/testing/sysfs-class-rnbd-server
@@ -48,3 +48,11 @@
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: Contains the device access mode: ro, rw or migration.
+
+What: /sys/class/rnbd-server/ctl/devices/<device_name>/sessions/<session-name>/force_close
+Date: Nov 2020
+KernelVersion: 5.10
+Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
+Description: Write "1" to the file to close the device on server side. Please
+ note that the client side device will not be closed, read or
+ write to the device will get -ENOTCONN.
diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec
index b7794e0..8eab41e 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -139,6 +139,49 @@
Shows if the partner supports USB Power Delivery communication:
Valid values: yes, no
+What: /sys/class/typec/<port>-partner/number_of_alternate_modes
+Date: November 2020
+Contact: Prashant Malani <pmalani@chromium.org>
+Description:
+ Shows the number of alternate modes which are advertised by the partner
+ during Power Delivery discovery. This file remains hidden until a value
+ greater than or equal to 0 is set by Type C port driver.
+
+What: /sys/class/typec/<port>-partner/type
+Date: December 2020
+Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description: USB Power Delivery Specification defines a set of product types
+ for the partner devices. This file will show the product type of
+ the partner if it is known. Dual-role capable partners will have
+ both UFP and DFP product types defined, but only one that
+ matches the current role will be active at the time. If the
+ product type of the partner is not visible to the device driver,
+ this file will not exist.
+
+ When the partner product type is detected, or changed with role
+ swap, uvevent is also raised that contains PRODUCT_TYPE=<product
+ type> (for example PRODUCT_TYPE=hub).
+
+ Valid values:
+
+ UFP / device role
+ ====================== ==========================
+ undefined -
+ hub PDUSB Hub
+ peripheral PDUSB Peripheral
+ psd Power Bank
+ ama Alternate Mode Adapter
+ ====================== ==========================
+
+ DFP / host role
+ ====================== ==========================
+ undefined -
+ hub PDUSB Hub
+ host PDUSB Host
+ power_brick Power Brick
+ amc Alternate Mode Controller
+ ====================== ==========================
+
What: /sys/class/typec/<port>-partner>/identity/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
@@ -151,31 +194,6 @@
directory exists, it will have an attribute file for every VDO
in Discover Identity command result.
-What: /sys/class/typec/<port>-partner/identity/id_header
-Date: April 2017
-Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
-Description:
- ID Header VDO part of Discover Identity command result. The
- value will show 0 until Discover Identity command result becomes
- available. The value can be polled.
-
-What: /sys/class/typec/<port>-partner/identity/cert_stat
-Date: April 2017
-Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
-Description:
- Cert Stat VDO part of Discover Identity command result. The
- value will show 0 until Discover Identity command result becomes
- available. The value can be polled.
-
-What: /sys/class/typec/<port>-partner/identity/product
-Date: April 2017
-Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
-Description:
- Product VDO part of Discover Identity command result. The value
- will show 0 until Discover Identity command result becomes
- available. The value can be polled.
-
-
USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
Note: Electronically Marked Cables will have a device also for one cable plug
@@ -187,9 +205,21 @@
What: /sys/class/typec/<port>-cable/type
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
-Description:
- Shows if the cable is active.
- Valid values: active, passive
+Description: USB Power Delivery Specification defines a set of product types
+ for the cables. This file will show the product type of the
+ cable if it is known. If the product type of the cable is not
+ visible to the device driver, this file will not exist.
+
+ When the cable product type is detected, uvevent is also raised
+ with PRODUCT_TYPE showing the product type of the cable.
+
+ Valid values:
+
+ ====================== ==========================
+ undefined -
+ active Active Cable
+ passive Passive Cable
+ ====================== ==========================
What: /sys/class/typec/<port>-cable/plug_type
Date: April 2017
@@ -202,17 +232,37 @@
- type-c
- captive
-What: /sys/class/typec/<port>-cable/identity/
+What: /sys/class/typec/<port>-<plug>/number_of_alternate_modes
+Date: November 2020
+Contact: Prashant Malani <pmalani@chromium.org>
+Description:
+ Shows the number of alternate modes which are advertised by the plug
+ associated with a particular cable during Power Delivery discovery.
+ This file remains hidden until a value greater than or equal to 0
+ is set by Type C port driver.
+
+
+USB Type-C partner/cable Power Delivery Identity objects
+
+NOTE: The following attributes will be applicable to both
+partner (e.g /sys/class/typec/port0-partner/) and
+cable (e.g /sys/class/typec/port0-cable/) devices. Consequently, the example file
+paths below are prefixed with "/sys/class/typec/<port>-{partner|cable}/" to
+reflect this.
+
+What: /sys/class/typec/<port>-{partner|cable}/identity/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This directory appears only if the port device driver is capable
of showing the result of Discover Identity USB power delivery
command. That will not always be possible even when USB power
- delivery is supported. If the directory exists, it will have an
- attribute for every VDO returned by Discover Identity command.
+ delivery is supported, for example when USB power delivery
+ communication for the port is mostly handled in firmware. If the
+ directory exists, it will have an attribute file for every VDO
+ in Discover Identity command result.
-What: /sys/class/typec/<port>-cable/identity/id_header
+What: /sys/class/typec/<port>-{partner|cable}/identity/id_header
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@@ -220,7 +270,7 @@
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
-What: /sys/class/typec/<port>-cable/identity/cert_stat
+What: /sys/class/typec/<port>-{partner|cable}/identity/cert_stat
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@@ -228,7 +278,7 @@
value will show 0 until Discover Identity command result becomes
available. The value can be polled.
-What: /sys/class/typec/<port>-cable/identity/product
+What: /sys/class/typec/<port>-{partner|cable}/identity/product
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@@ -236,6 +286,30 @@
will show 0 until Discover Identity command result becomes
available. The value can be polled.
+What: /sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo1
+Date: October 2020
+Contact: Prashant Malani <pmalani@chromium.org>
+Description:
+ 1st Product Type VDO of Discover Identity command result.
+ The value will show 0 until Discover Identity command result becomes
+ available and a valid Product Type VDO is returned.
+
+What: /sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo2
+Date: October 2020
+Contact: Prashant Malani <pmalani@chromium.org>
+Description:
+ 2nd Product Type VDO of Discover Identity command result.
+ The value will show 0 until Discover Identity command result becomes
+ available and a valid Product Type VDO is returned.
+
+What: /sys/class/typec/<port>-{partner|cable}/identity/product_type_vdo3
+Date: October 2020
+Contact: Prashant Malani <pmalani@chromium.org>
+Description:
+ 3rd Product Type VDO of Discover Identity command result.
+ The value will show 0 until Discover Identity command result becomes
+ available and a valid Product Type VDO is returned.
+
USB Type-C port alternate mode devices.
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 1a04ca8..0eee30b 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -264,7 +264,8 @@
attribute is useful for user space DVFS controllers to get better
power/performance results for platforms using acpi-cpufreq.
- This file is only present if the acpi-cpufreq driver is in use.
+ This file is only present if the acpi-cpufreq or the cppc-cpufreq
+ drivers are in use.
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm
index 6a37dc3..74642c7 100644
--- a/Documentation/ABI/testing/sysfs-driver-w1_therm
+++ b/Documentation/ABI/testing/sysfs-driver-w1_therm
@@ -14,7 +14,7 @@
w1_term device
-What: /sys/bus/w1/devices/.../eeprom
+What: /sys/bus/w1/devices/.../eeprom_cmd
Date: May 2020
Contact: Akira Shimahara <akira215corp@gmail.com>
Description:
diff --git a/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo b/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo
new file mode 100644
index 0000000..5e3f614
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo
@@ -0,0 +1,35 @@
+What: /sys/firmware/lefi/boardinfo
+Date: October 2020
+Contact: Tiezhu Yang <yangtiezhu@loongson.cn>
+Description:
+ Get mainboard and BIOS info easily on the Loongson platform,
+ this is useful to point out the current used mainboard type
+ and BIOS version when there exists problems related with
+ hardware or firmware.
+
+ The related structures are already defined in the interface
+ specification about firmware and kernel which are common
+ requirement and specific for Loongson64, so only add a new
+ boardinfo.c file in arch/mips/loongson64.
+
+ For example:
+
+ [loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo
+ Board Info
+ Manufacturer : LEMOTE
+ Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc
+ Family : LOONGSON3
+
+ BIOS Info
+ Vendor : Kunlun
+ Version : Kunlun-A1901-V4.1.3-20200414093938
+ ROM Size : 4 KB
+ Release Date : 2020-04-14
+
+ By the way, using dmidecode command can get the similar info if there
+ exists SMBIOS in firmware, but the fact is that there is no SMBIOS on
+ some machines, we can see nothing when execute dmidecode, like this:
+
+ [root@linux loongson]# dmidecode
+ # dmidecode 2.12
+ # No SMBIOS nor DMI entry point found, sorry.
diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
index 66800baa..637c668 100644
--- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
+++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
@@ -1,27 +1,159 @@
What: /sys/firmware/sgi_uv/
-Date: August 2008
-Contact: Russ Anderson <rja@sgi.com>
+Date: September 2020
+Contact: Justin Ernst <justin.ernst@hpe.com>
Description:
The /sys/firmware/sgi_uv directory contains information
- about the SGI UV platform.
+ about the UV platform.
- Under that directory are a number of files::
+ Under that directory are a number of read-only attributes::
+ archtype
+ hub_type
+ hubless
partition_id
coherence_id
+ uv_type
+
+ The archtype entry contains the UV architecture type that
+ is used to select arch-dependent addresses and features.
+ It can be set via the OEM_ID in the ACPI MADT table or by
+ UVsystab entry both passed from UV BIOS.
+
+ The hub_type entry is used to select the type of hub which is
+ similar to uv_type but encoded in a binary format. Include
+ the file uv_hub.h to get the definitions.
+
+ The hubless entry basically is present and set only if there
+ is no hub. In this case the hub_type entry is not present.
The partition_id entry contains the partition id.
- SGI UV systems can be partitioned into multiple physical
+ UV systems can be partitioned into multiple physical
machines, which each partition running a unique copy
- of the operating system. Each partition will have a unique
- partition id. To display the partition id, use the command::
-
- cat /sys/firmware/sgi_uv/partition_id
+ of the operating system. Each partition will have a unique
+ partition id.
The coherence_id entry contains the coherence id.
- A partitioned SGI UV system can have one or more coherence
- domain. The coherence id indicates which coherence domain
- this partition is in. To display the coherence id, use the
- command::
+ A partitioned UV system can have one or more coherence
+ domains. The coherence id indicates which coherence domain
+ this partition is in.
- cat /sys/firmware/sgi_uv/coherence_id
+ The uv_type entry contains the hub revision number.
+ This value can be used to identify the UV system version::
+ "0.*" = Hubless UV ('*' is subtype)
+
+ "3.0" = UV2
+ "5.0" = UV3
+ "7.0" = UV4
+ "7.1" = UV4a
+ "9.0" = UV5
+
+ The /sys/firmware/sgi_uv directory also contains two directories::
+
+ hubs/
+ pcibuses/
+
+ The hubs directory contains a number of hub objects, each representing
+ a UV Hub visible to the BIOS. Each hub object's name is appended by a
+ unique ordinal value (ex. /sys/firmware/sgi_uv/hubs/hub_5)
+
+ Each hub object directory contains a number of read-only attributes::
+
+ cnode
+ location
+ name
+ nasid
+ shared
+ this_partition
+
+ The cnode entry contains the cnode number of the corresponding hub.
+ If a cnode value is not applicable, the value returned will be -1.
+
+ The location entry contains the location string of the corresponding hub.
+ This value is used to physically identify a hub within a system.
+
+ The name entry contains the name of the corresponding hub. This name can
+ be two variants::
+
+ "UVHub x.x" = A 'node' ASIC, connecting a CPU to the interconnect
+ fabric. The 'x.x' value represents the ASIC revision.
+ (ex. 'UVHub 5.0')
+
+ "NLxRouter" = A 'router ASIC, only connecting other ASICs to
+ the interconnect fabric. The 'x' value representing
+ the fabric technology version. (ex. 'NL8Router')
+
+ The nasid entry contains the nasid number of the corresponding hub.
+ If a nasid value is not applicable, the value returned will be -1.
+
+ The shared entry contains a boolean value describing whether the
+ corresponding hub is shared between system partitions.
+
+ The this_partition entry contains a boolean value describing whether
+ the corresponding hub is local to the current partition.
+
+ Each hub object directory also contains a number of port objects,
+ each representing a fabric port on the corresponding hub.
+ A port object's name is appended by a unique ordinal value
+ (ex. /sys/firmware/sgi_uv/hubs/hub_5/port_3)
+
+ Each port object directory contains a number of read-only attributes::
+
+ conn_hub
+ conn_port
+
+ The conn_hub entry contains a value representing the unique
+ oridinal value of the hub on the other end of the fabric
+ cable plugged into the port. If the port is disconnected,
+ the value returned will be -1.
+
+ The conn_port entry contains a value representing the unique
+ oridinal value of the port on the other end of the fabric cable
+ plugged into the port. If the port is disconnected, the value
+ returned will be -1.
+
+ Ex:
+ A value of '3' is read from:
+ /sys/firmware/sgi_uv/hubs/hub_5/port_3/conn_hub
+
+ and a value of '6' is read from:
+ /sys/firmware/sgi_uv/hubs/hub_5/port_3/conn_port
+
+ representing that this port is connected to:
+ /sys/firmware/sgi_uv/hubs/hub_3/port_6
+
+ The pcibuses directory contains a number of PCI bus objects.
+ Each PCI bus object's name is appended by its PCI bus address.
+ (ex. pcibus_0003:80)
+
+ Each pcibus object has a number of possible read-only attributes::
+
+ type
+ location
+ slot
+ ppb_addr
+ iio_stack
+
+ The type entry contains a value describing the type of IO at
+ the corresponding PCI bus address. Known possible values
+ across all UV versions are::
+
+ BASE IO
+ PCIe IO
+ PCIe SLOT
+ NODE IO
+ Riser
+ PPB
+
+ The location entry contains the location string of the UV Hub
+ of the CPU physically connected to the corresponding PCI bus.
+
+ The slot entry contains the physical slot number of the
+ corresponding PCI bus. This value is used to physically locate
+ PCI cards within a system.
+
+ The ppb_addr entry contains the PCI address string of the
+ bridged PCI bus. This entry is only present when the PCI bus
+ object type is 'PPB'.
+
+ The iio_stack entry contains a value describing the IIO stack
+ number that the corresponding PCI bus object is connected to.
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 67b3ed8..3dfee94 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -370,3 +370,10 @@
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Give a way to change iostat_period time. 3secs by default.
The new iostat trace gives stats gap given the period.
+What: /sys/fs/f2fs/<disk>/max_io_bytes
+Date: December 2020
+Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
+Description: This gives a control to limit the bio size in f2fs.
+ Default is zero, which will follow underlying block layer limit,
+ whereas, if it has a certain bytes value, f2fs won't submit a
+ bio larger than that size.
diff --git a/Documentation/ABI/testing/sysfs-kernel-btf b/Documentation/ABI/testing/sysfs-kernel-btf
index 2c9744b..fe96efd 100644
--- a/Documentation/ABI/testing/sysfs-kernel-btf
+++ b/Documentation/ABI/testing/sysfs-kernel-btf
@@ -15,3 +15,11 @@
information with description of all internal kernel types. See
Documentation/bpf/btf.rst for detailed description of format
itself.
+
+What: /sys/kernel/btf/<module-name>
+Date: Nov 2020
+KernelVersion: 5.11
+Contact: bpf@vger.kernel.org
+Description:
+ Read-only binary attribute exposing kernel module's BTF type
+ information as an add-on to the kernel's BTF (/sys/kernel/btf/vmlinux).
diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups
index 017f5bc..0fedbb0 100644
--- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups
+++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups
@@ -33,3 +33,33 @@
it is now exposed as "direct-relaxable" instead of "direct".
In device assignment use case, for instance, those RMRR
are considered to be relaxable and safe.
+
+What: /sys/kernel/iommu_groups/<grp_id>/type
+Date: November 2020
+KernelVersion: v5.11
+Contact: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
+Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
+ domain in use by iommu for this group. See include/linux/iommu.h
+ for possible read values. A privileged user could request kernel to
+ change the group type by writing to this file. Valid write values:
+
+ ======== ======================================================
+ DMA All the DMA transactions from the device in this group
+ are translated by the iommu.
+ identity All the DMA transactions from the device in this group
+ are not translated by the iommu.
+ auto Change to the type the device was booted with.
+ ======== ======================================================
+
+ The default domain type of a group may be modified only when
+
+ - The group has only one device.
+ - The device in the group is not bound to any device driver.
+ So, the users must unbind the appropriate driver before
+ changing the default domain type.
+
+ Unbinding a device driver will take away the driver's control
+ over the device and if done on devices that host root file
+ system could lead to catastrophic effects (the users might
+ need to reboot the machine to get it to normal state). So, it's
+ expected that the users understand what they're doing.
diff --git a/Documentation/ABI/testing/sysfs-kernel-reboot b/Documentation/ABI/testing/sysfs-kernel-reboot
new file mode 100644
index 0000000..837330f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-reboot
@@ -0,0 +1,32 @@
+What: /sys/kernel/reboot
+Date: November 2020
+KernelVersion: 5.11
+Contact: Matteo Croce <mcroce@microsoft.com>
+Description: Interface to set the kernel reboot behavior, similarly to
+ what can be done via the reboot= cmdline option.
+ (see Documentation/admin-guide/kernel-parameters.txt)
+
+What: /sys/kernel/reboot/mode
+Date: November 2020
+KernelVersion: 5.11
+Contact: Matteo Croce <mcroce@microsoft.com>
+Description: Reboot mode. Valid values are: cold warm hard soft gpio
+
+What: /sys/kernel/reboot/type
+Date: November 2020
+KernelVersion: 5.11
+Contact: Matteo Croce <mcroce@microsoft.com>
+Description: Reboot type. Valid values are: bios acpi kbd triple efi pci
+
+What: /sys/kernel/reboot/cpu
+Date: November 2020
+KernelVersion: 5.11
+Contact: Matteo Croce <mcroce@microsoft.com>
+Description: CPU number to use to reboot.
+
+What: /sys/kernel/reboot/force
+Date: November 2020
+KernelVersion: 5.11
+Contact: Matteo Croce <mcroce@microsoft.com>
+Description: Don't wait for any other CPUs on reboot and
+ avoid anything that could hang.
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index 1ae79a1..e8c84fc 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -1929,16 +1929,46 @@
to allow the various kernel subsystems (including RCU) to respond
appropriately to a given CPU-hotplug operation. Most RCU operations may
be invoked from CPU-hotplug notifiers, including even synchronous
-grace-period operations such as ``synchronize_rcu()`` and
-``synchronize_rcu_expedited()``.
+grace-period operations such as (``synchronize_rcu()`` and
+``synchronize_rcu_expedited()``). However, these synchronous operations
+do block and therefore cannot be invoked from notifiers that execute via
+``stop_machine()``, specifically those between the ``CPUHP_AP_OFFLINE``
+and ``CPUHP_AP_ONLINE`` states.
-However, all-callback-wait operations such as ``rcu_barrier()`` are also
-not supported, due to the fact that there are phases of CPU-hotplug
-operations where the outgoing CPU's callbacks will not be invoked until
-after the CPU-hotplug operation ends, which could also result in
-deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations
-during its execution, which results in another type of deadlock when
-invoked from a CPU-hotplug notifier.
+In addition, all-callback-wait operations such as ``rcu_barrier()`` may
+not be invoked from any CPU-hotplug notifier. This restriction is due
+to the fact that there are phases of CPU-hotplug operations where the
+outgoing CPU's callbacks will not be invoked until after the CPU-hotplug
+operation ends, which could also result in deadlock. Furthermore,
+``rcu_barrier()`` blocks CPU-hotplug operations during its execution,
+which results in another type of deadlock when invoked from a CPU-hotplug
+notifier.
+
+Finally, RCU must avoid deadlocks due to interaction between hotplug,
+timers and grace period processing. It does so by maintaining its own set
+of books that duplicate the centrally maintained ``cpu_online_mask``,
+and also by reporting quiescent states explicitly when a CPU goes
+offline. This explicit reporting of quiescent states avoids any need
+for the force-quiescent-state loop (FQS) to report quiescent states for
+offline CPUs. However, as a debugging measure, the FQS loop does splat
+if offline CPUs block an RCU grace period for too long.
+
+An offline CPU's quiescent state will be reported either:
+
+1. As the CPU goes offline using RCU's hotplug notifier (``rcu_report_dead()``).
+2. When grace period initialization (``rcu_gp_init()``) detects a
+ race either with CPU offlining or with a task unblocking on a leaf
+ ``rcu_node`` structure whose CPUs are all offline.
+
+The CPU-online path (``rcu_cpu_starting()``) should never need to report
+a quiescent state for an offline CPU. However, as a debugging measure,
+it does emit a warning if a quiescent state was not already reported
+for that CPU.
+
+During the checking/modification of RCU's hotplug bookkeeping, the
+corresponding CPU's leaf node lock is held. This avoids race conditions
+between RCU's hotplug notifier hooks, the grace period initialization
+code, and the FQS loop, all of which refer to or modify this bookkeeping.
Scheduler and RCU
~~~~~~~~~~~~~~~~~
diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst
index 2efed99..bb7128e 100644
--- a/Documentation/RCU/checklist.rst
+++ b/Documentation/RCU/checklist.rst
@@ -314,6 +314,13 @@
shared between readers and updaters. Additional primitives
are provided for this case, as discussed in lockdep.txt.
+ One exception to this rule is when data is only ever added to
+ the linked data structure, and is never removed during any
+ time that readers might be accessing that structure. In such
+ cases, READ_ONCE() may be used in place of rcu_dereference()
+ and the read-side markers (rcu_read_lock() and rcu_read_unlock(),
+ for example) may be omitted.
+
10. Conversely, if you are in an RCU read-side critical section,
and you don't hold the appropriate update-side lock, you -must-
use the "_rcu()" variants of the list macros. Failing to do so
diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst
index c9667eb..f3e587a 100644
--- a/Documentation/RCU/rcu_dereference.rst
+++ b/Documentation/RCU/rcu_dereference.rst
@@ -28,6 +28,12 @@
for an example where the compiler can in fact deduce the exact
value of the pointer, and thus cause misordering.
+- In the special case where data is added but is never removed
+ while readers are accessing the structure, READ_ONCE() may be used
+ instead of rcu_dereference(). In this case, use of READ_ONCE()
+ 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.
The compiler simply knows too much about integral values to
trust it to carry dependencies through integer operations.
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index fb3ff76..1a4723f 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -497,8 +497,7 @@
In such cases, one uses call_rcu() rather than synchronize_rcu().
The call_rcu() API is as follows::
- void call_rcu(struct rcu_head * head,
- void (*func)(struct rcu_head *head));
+ void call_rcu(struct rcu_head *head, rcu_callback_t func);
This function invokes func(head) after a grace period has elapsed.
This invocation might happen from either softirq or process context,
diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst
index 9093228..700329d 100644
--- a/Documentation/admin-guide/blockdev/zram.rst
+++ b/Documentation/admin-guide/blockdev/zram.rst
@@ -266,6 +266,7 @@
No memory is allocated for such pages.
pages_compacted the number of pages freed during compaction
huge_pages the number of incompressible pages
+ huge_pages_since the number of incompressible pages since zram set up
================ =============================================================
File /sys/block/zram<id>/bd_stat
@@ -334,6 +335,11 @@
With the command, zram writeback idle pages from memory to the storage.
+If admin want to write a specific page in zram device to backing device,
+they could write a page index into the interface.
+
+ echo "page_index=1251" > /sys/block/zramX/writeback
+
If there are lots of write IO with flash device, potentially, it has
flash wearout problem so that admin needs to design write limitation
to guarantee storage health for entire product life.
diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst
index a22024f..9b90efc 100644
--- a/Documentation/admin-guide/bootconfig.rst
+++ b/Documentation/admin-guide/bootconfig.rst
@@ -137,15 +137,24 @@
==============================
Since the boot configuration file is loaded with initrd, it will be added
-to the end of the initrd (initramfs) image file with size, checksum and
-12-byte magic word as below.
+to the end of the initrd (initramfs) image file with padding, size,
+checksum and 12-byte magic word as below.
-[initrd][bootconfig][size(u32)][checksum(u32)][#BOOTCONFIG\n]
+[initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n]
+
+The size and checksum fields are unsigned 32bit little endian value.
+
+When the boot configuration is added to the initrd image, the total
+file size is aligned to 4 bytes. To fill the gap, null characters
+(``\0``) will be added. Thus the ``size`` is the length of the bootconfig
+file + padding bytes.
The Linux kernel decodes the last part of the initrd image in memory to
get the boot configuration data.
Because of this "piggyback" method, there is no need to change or
-update the boot loader and the kernel image itself.
+update the boot loader and the kernel image itself as long as the boot
+loader passes the correct initrd file size. If by any chance, the boot
+loader passes a longer size, the kernel feils to find the bootconfig data.
To do this operation, Linux kernel provides "bootconfig" command under
tools/bootconfig, which allows admin to apply or delete the config file
@@ -176,7 +185,8 @@
contain 256 key-value pairs. In most cases, the number of config items
will be under 100 entries and smaller than 8KB, so it would be enough.
If the node number exceeds 1024, parser returns an error even if the file
-size is smaller than 32KB.
+size is smaller than 32KB. (Note that this maximum size is not including
+the padding null characters.)
Anyway, since bootconfig command verifies it when appending a boot config
to initrd image, user can notice it before boot.
diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 3f7115e..45b94f7 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -133,18 +133,9 @@
8. LRU
======
- Each memcg has its own private LRU. Now, its handling is under global
- VM's control (means that it's handled under global pgdat->lru_lock).
- Almost all routines around memcg's LRU is called by global LRU's
- list management functions under pgdat->lru_lock.
-
- A special function is mem_cgroup_isolate_pages(). This scans
- memcg's private LRU and call __isolate_lru_page() to extract a page
- from LRU.
-
- (By __isolate_lru_page(), the page is removed from both of global and
- private LRU.)
-
+ Each memcg has its own vector of LRUs (inactive anon, active anon,
+ inactive file, active file, unevictable) of pages from each node,
+ each LRU handled under a single lru_lock for that memcg and node.
9. Typical Tests.
=================
@@ -219,13 +210,11 @@
This is an easy way to test page migration, too.
-9.5 mkdir/rmdir
----------------
+9.5 nested cgroups
+------------------
- When using hierarchy, mkdir/rmdir test should be done.
- Use tests like the following::
+ Use tests like the following for testing nested cgroups::
- echo 1 >/opt/cgroup/01/memory/use_hierarchy
mkdir /opt/cgroup/01/child_a
mkdir /opt/cgroup/01/child_b
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
index 12757e6..52688ae 100644
--- a/Documentation/admin-guide/cgroup-v1/memory.rst
+++ b/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -77,6 +77,8 @@
memory.soft_limit_in_bytes set/show soft limit of memory usage
memory.stat show various statistics
memory.use_hierarchy set/show hierarchical account enabled
+ This knob is deprecated and shouldn't be
+ used.
memory.force_empty trigger forced page reclaim
memory.pressure_level set memory pressure notifications
memory.swappiness set/show swappiness parameter of vmscan
@@ -285,20 +287,17 @@
2.6 Locking
-----------
- lock_page_cgroup()/unlock_page_cgroup() should not be called under
- the i_pages lock.
+Lock order is as follows:
- Other lock order is following:
+ Page lock (PG_locked bit of page->flags)
+ mm->page_table_lock or split pte_lock
+ lock_page_memcg (memcg->move_lock)
+ mapping->i_pages lock
+ lruvec->lru_lock.
- PG_locked.
- mm->page_table_lock
- pgdat->lru_lock
- lock_page_cgroup.
-
- In many cases, just lock_page_cgroup() is called.
-
- per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
- pgdat->lru_lock, it has no lock of its own.
+Per-node-per-memcgroup LRU (cgroup's private LRU) is guarded by
+lruvec->lru_lock; PG_lru bit of page->flags is cleared before
+isolating a page from its LRU under lruvec->lru_lock.
2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
-----------------------------------------------
@@ -495,16 +494,13 @@
tasks have migrated away from it. (because we charge against pages, not
against tasks.)
-We move the stats to root (if use_hierarchy==0) or parent (if
-use_hierarchy==1), and no change on the charge except uncharging
+We move the stats to parent, and no change on the charge except uncharging
from the child.
Charges recorded in swap information is not updated at removal of cgroup.
Recorded information is discarded and a cgroup which uses swap (swapcache)
will be charged as a new owner of it.
-About use_hierarchy, see Section 6.
-
5. Misc. interfaces
===================
@@ -527,8 +523,6 @@
write will still return success. In this case, it is expected that
memory.kmem.usage_in_bytes == memory.usage_in_bytes.
- About use_hierarchy, see Section 6.
-
5.2 stat file
-------------
@@ -675,32 +669,21 @@
d e
In the diagram above, with hierarchical accounting enabled, all memory
-usage of e, is accounted to its ancestors up until the root (i.e, c and root),
-that has memory.use_hierarchy enabled. If one of the ancestors goes over its
-limit, the reclaim algorithm reclaims from the tasks in the ancestor and the
-children of the ancestor.
+usage of e, is accounted to its ancestors up until the root (i.e, c and root).
+If one of the ancestors goes over its limit, the reclaim algorithm reclaims
+from the tasks in the ancestor and the children of the ancestor.
-6.1 Enabling hierarchical accounting and reclaim
-------------------------------------------------
+6.1 Hierarchical accounting and reclaim
+---------------------------------------
-A memory cgroup by default disables the hierarchy feature. Support
-can be enabled by writing 1 to memory.use_hierarchy file of the root cgroup::
+Hierarchical accounting is enabled by default. Disabling the hierarchical
+accounting is deprecated. An attempt to do it will result in a failure
+and a warning printed to dmesg.
+
+For compatibility reasons writing 1 to memory.use_hierarchy will always pass::
# echo 1 > memory.use_hierarchy
-The feature can be disabled by::
-
- # echo 0 > memory.use_hierarchy
-
-NOTE1:
- Enabling/disabling will fail if either the cgroup already has other
- cgroups created below it, or if the parent cgroup has use_hierarchy
- enabled.
-
-NOTE2:
- When panic_on_oom is set to "2", the whole system will panic in
- case of an OOM event in any cgroup.
-
7. Soft limits
==============
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 608d7c2..63521cd 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1274,6 +1274,9 @@
kernel_stack
Amount of memory allocated to kernel stacks.
+ pagetables
+ Amount of memory allocated for page tables.
+
percpu(npn)
Amount of memory used for storing per-cpu kernel
data structures.
@@ -1300,6 +1303,14 @@
Amount of memory used in anonymous mappings backed by
transparent hugepages
+ file_thp
+ Amount of cached filesystem data backed by transparent
+ hugepages
+
+ shmem_thp
+ Amount of shm, tmpfs, shared anonymous mmap()s backed by
+ transparent hugepages
+
inactive_anon, active_anon, inactive_file, active_file, unevictable
Amount of memory, swap-backed and filesystem-backed,
on the internal memory management lists used by the
diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst
index 8c50e5c..1a6b913 100644
--- a/Documentation/admin-guide/device-mapper/verity.rst
+++ b/Documentation/admin-guide/device-mapper/verity.rst
@@ -134,7 +134,12 @@
the pkcs7 signature of the roothash. The pkcs7 signature is used to validate
the root hash during the creation of the device mapper block device.
Verification of roothash depends on the config DM_VERITY_VERIFY_ROOTHASH_SIG
- being set in the kernel.
+ being set in the kernel. The signatures are checked against the builtin
+ trusted keyring by default, or the secondary trusted keyring if
+ DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING is set. The secondary
+ trusted keyring includes by default the builtin trusted keyring, and it can
+ also gain new certificates at run time if they are signed by a certificate
+ already in the secondary trusted keyring.
Theory of operation
===================
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 621d1c5..423116c 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -113,13 +113,13 @@
rtc
serial-console
svga
+ syscall-user-dispatch
sysrq
thunderbolt
ufs
unicode
vga-softcursor
video-output
- wimax/index
xfs
.. only:: subproject and html
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index e44a6c0..3861a25 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -39,6 +39,12 @@
User-space tools can get the kernel name, host name, kernel release
number, kernel version, architecture name and OS type from it.
+(uts_namespace, name)
+---------------------
+
+Offset of the name's member. Crash Utility and Makedumpfile get
+the start address of the init_uts_ns.name from this.
+
node_online_map
---------------
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 8bdbc55..c722ec1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1883,11 +1883,6 @@
Note that using this option lowers the security
provided by tboot because it makes the system
vulnerable to DMA attacks.
- nobounce [Default off]
- Disable bounce buffer for untrusted devices such as
- the Thunderbolt devices. This will treat the untrusted
- devices as the trusted ones, hence might expose security
- risks of DMA attacks.
intel_idle.max_cstate= [KNL,HW,ACPI,X86]
0 disables intel_idle and fall back on acpi_idle.
@@ -2259,6 +2254,16 @@
for all guests.
Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
+ kvm-arm.mode=
+ [KVM,ARM] Select one of KVM/arm64's modes of operation.
+
+ protected: nVHE-based mode with support for guests whose
+ state is kept private from the host.
+ Not valid if the kernel is running in EL2.
+
+ Defaults to VHE/nVHE based on hardware support and
+ the value of CONFIG_ARM64_VHE.
+
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
system registers
@@ -2858,6 +2863,8 @@
mds=off [X86]
tsx_async_abort=off [X86]
kvm.nx_huge_pages=off [X86]
+ no_entry_flush [PPC]
+ no_uaccess_flush [PPC]
Exceptions:
This does not have any effect on
@@ -2951,7 +2958,7 @@
mtdset= [ARM]
ARM/S3C2412 JIVE boot control
- See arch/arm/mach-s3c2412/mach-jive.c
+ See arch/arm/mach-s3c/mach-jive.c
mtouchusb.raw_coordinates=
[HW] Make the MicroTouch USB driver use raw coordinates
@@ -3186,6 +3193,8 @@
noefi Disable EFI runtime services support.
+ no_entry_flush [PPC] Don't flush the L1-D cache when entering the kernel.
+
noexec [IA-64]
noexec [X86]
@@ -3235,6 +3244,9 @@
nospec_store_bypass_disable
[HW] Disable all mitigations for the Speculative Store Bypass vulnerability
+ no_uaccess_flush
+ [PPC] Don't flush the L1-D cache after accessing user data.
+
noxsave [BUGS=X86] Disables x86 extended register state save
and restore using xsave. The kernel will fallback to
enabling legacy floating-point and sse state.
@@ -3368,6 +3380,8 @@
nosep [BUGS=X86-32] Disables x86 SYSENTER/SYSEXIT support.
+ nosgx [X86-64,SGX] Disables Intel SGX kernel support.
+
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC. legacy for "maxcpus=0".
@@ -5656,6 +5670,7 @@
device);
j = NO_REPORT_LUNS (don't use report luns
command, uas only);
+ k = NO_SAME (do not use WRITE_SAME, uas only)
l = NOT_LOCKABLE (don't try to lock and
unlock ejectable media, not on uas);
m = MAX_SECTORS_64 (don't transfer more
diff --git a/Documentation/admin-guide/media/rkisp1.rst b/Documentation/admin-guide/media/rkisp1.rst
index 42e37ed..2267e4f 100644
--- a/Documentation/admin-guide/media/rkisp1.rst
+++ b/Documentation/admin-guide/media/rkisp1.rst
@@ -86,7 +86,7 @@
video stream.
The buffer format is defined by struct :c:type:`rkisp1_stat_buffer`, and
userspace should set
-:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A <v4l2-meta-fmt-stat-rkisp1>` as the
+:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A <v4l2-meta-fmt-rk-isp1-stat-3a>` as the
dataformat.
.. _rkisp1_params:
@@ -100,7 +100,7 @@
The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
userspace should set
-:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-params-rkisp1>` as the
+:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-rk-isp1-params>` as the
dataformat.
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index b2acd0d..3b8a336 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -401,21 +401,6 @@
is incremented if the system tries to compact memory
but failed.
-compact_pages_moved
- is incremented each time a page is moved. If
- this value is increasing rapidly, it implies that the system
- is copying a lot of data to satisfy the huge page allocation.
- It is possible that the cost of copying exceeds any savings
- from reduced TLB misses.
-
-compact_pagemigrate_failed
- is incremented when the underlying mechanism
- for moving a page failed.
-
-compact_blocks_moved
- is incremented each time memory compaction examines
- a huge page aligned range of pages.
-
It is possible to establish how long the stalls were using the function
tracer to record how long was spent in __alloc_pages_nodemask and
using the mm_page_alloc tracepoint to identify which allocations were
diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
index 1307b52..904e4eb 100644
--- a/Documentation/admin-guide/perf-security.rst
+++ b/Documentation/admin-guide/perf-security.rst
@@ -84,11 +84,14 @@
is recommended as the preferred secure approach to resolve double access
denial logging related to usage of performance monitoring and observability.
-Unprivileged processes using perf_events system call are also subject
-for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose
-outcome determines whether monitoring is permitted. So unprivileged
-processes provided with CAP_SYS_PTRACE capability are effectively
-permitted to pass the check.
+Prior Linux v5.9 unprivileged processes using perf_events system call
+are also subject for PTRACE_MODE_READ_REALCREDS ptrace access mode check
+[7]_ , whose outcome determines whether monitoring is permitted.
+So unprivileged processes provided with CAP_SYS_PTRACE capability are
+effectively permitted to pass the check. Starting from Linux v5.9
+CAP_SYS_PTRACE capability is not required and CAP_PERFMON is enough to
+be provided for processes to make performance monitoring and observability
+operations.
Other capabilities being granted to unprivileged processes can
effectively enable capturing of additional data required for later
@@ -99,11 +102,11 @@
Privileged Perf users groups
---------------------------------
-Mechanisms of capabilities, privileged capability-dumb files [6]_ and
-file system ACLs [10]_ can be used to create dedicated groups of
-privileged Perf users who are permitted to execute performance monitoring
-and observability without scope limits. The following steps can be
-taken to create such groups of privileged Perf users.
+Mechanisms of capabilities, privileged capability-dumb files [6]_,
+file system ACLs [10]_ and sudo [15]_ utility can be used to create
+dedicated groups of privileged Perf users who are permitted to execute
+performance monitoring and observability without limits. The following
+steps can be taken to create such groups of privileged Perf users.
1. Create perf_users group of privileged Perf users, assign perf_users
group to Perf tool executable and limit access to the executable for
@@ -133,7 +136,7 @@
# getcap perf
perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep
-If the libcap installed doesn't yet support "cap_perfmon", use "38" instead,
+If the libcap [16]_ installed doesn't yet support "cap_perfmon", use "38" instead,
i.e.:
::
@@ -159,6 +162,60 @@
configured Perf tool executable that, when executes, passes perf_events
subsystem scope checks.
+In case Perf tool executable can't be assigned required capabilities (e.g.
+file system is mounted with nosuid option or extended attributes are
+not supported by the file system) then creation of the capabilities
+privileged environment, naturally shell, is possible. The shell provides
+inherent processes with CAP_PERFMON and other required capabilities so that
+performance monitoring and observability operations are available in the
+environment without limits. Access to the environment can be open via sudo
+utility for members of perf_users group only. In order to create such
+environment:
+
+1. Create shell script that uses capsh utility [16]_ to assign CAP_PERFMON
+ and other required capabilities into ambient capability set of the shell
+ process, lock the process security bits after enabling SECBIT_NO_SETUID_FIXUP,
+ SECBIT_NOROOT and SECBIT_NO_CAP_AMBIENT_RAISE bits and then change
+ the process identity to sudo caller of the script who should essentially
+ be a member of perf_users group:
+
+::
+
+ # ls -alh /usr/local/bin/perf.shell
+ -rwxr-xr-x. 1 root root 83 Oct 13 23:57 /usr/local/bin/perf.shell
+ # cat /usr/local/bin/perf.shell
+ exec /usr/sbin/capsh --iab=^cap_perfmon --secbits=239 --user=$SUDO_USER -- -l
+
+2. Extend sudo policy at /etc/sudoers file with a rule for perf_users group:
+
+::
+
+ # grep perf_users /etc/sudoers
+ %perf_users ALL=/usr/local/bin/perf.shell
+
+3. Check that members of perf_users group have access to the privileged
+ shell and have CAP_PERFMON and other required capabilities enabled
+ in permitted, effective and ambient capability sets of an inherent process:
+
+::
+
+ $ id
+ uid=1003(capsh_test) gid=1004(capsh_test) groups=1004(capsh_test),1000(perf_users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
+ $ sudo perf.shell
+ [sudo] password for capsh_test:
+ $ grep Cap /proc/self/status
+ CapInh: 0000004000000000
+ CapPrm: 0000004000000000
+ CapEff: 0000004000000000
+ CapBnd: 000000ffffffffff
+ CapAmb: 0000004000000000
+ $ capsh --decode=0000004000000000
+ 0x0000004000000000=cap_perfmon
+
+As a result, members of perf_users group have access to the privileged
+environment where they can use tools employing performance monitoring APIs
+governed by CAP_PERFMON Linux capability.
+
This specific access control management is only available to superuser
or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_
capabilities.
@@ -264,3 +321,5 @@
.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_
.. [13] `<https://sites.google.com/site/fullycapable>`_
.. [14] `<http://man7.org/linux/man-pages/man8/auditd.8.html>`_
+.. [15] `<https://man7.org/linux/man-pages/man8/sudo.8.html>`_
+.. [16] `<https://git.kernel.org/pub/scm/libs/libcap/libcap.git/>`_
diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst
index 6898aba..49d8149 100644
--- a/Documentation/admin-guide/pstore-blk.rst
+++ b/Documentation/admin-guide/pstore-blk.rst
@@ -35,7 +35,7 @@
Here is an example for module parameters::
- pstore_blk.blkdev=179:7 pstore_blk.kmsg_size=64
+ pstore_blk.blkdev=/dev/mmcblk0p7 pstore_blk.kmsg_size=64 best_effort=y
The detail of each configurations may be of interest to you.
@@ -151,10 +151,7 @@
Configurations for driver
-------------------------
-Only a block device driver cares about these configurations. A block device
-driver uses ``register_pstore_blk`` to register to pstore/blk.
-
-A non-block device driver uses ``register_pstore_device`` with
+A device driver uses ``register_pstore_device`` with
``struct pstore_device_info`` to register to pstore/blk.
.. kernel-doc:: fs/pstore/blk.c
diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt
index 3782f6a..5ff6a0f 100644
--- a/Documentation/admin-guide/spkguide.txt
+++ b/Documentation/admin-guide/spkguide.txt
@@ -344,6 +344,7 @@
spk key_8 = speakup_paste
shift spk key_m = say_first_char
ctrl spk key_semicolon = say_last_char
+spk key_r = read_all_doc
5. The Speakup Sys System
diff --git a/Documentation/admin-guide/syscall-user-dispatch.rst b/Documentation/admin-guide/syscall-user-dispatch.rst
new file mode 100644
index 0000000..a380d65
--- /dev/null
+++ b/Documentation/admin-guide/syscall-user-dispatch.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Syscall User Dispatch
+=====================
+
+Background
+----------
+
+Compatibility layers like Wine need a way to efficiently emulate system
+calls of only a part of their process - the part that has the
+incompatible code - while being able to execute native syscalls without
+a high performance penalty on the native part of the process. Seccomp
+falls short on this task, since it has limited support to efficiently
+filter syscalls based on memory regions, and it doesn't support removing
+filters. Therefore a new mechanism is necessary.
+
+Syscall User Dispatch brings the filtering of the syscall dispatcher
+address back to userspace. The application is in control of a flip
+switch, indicating the current personality of the process. A
+multiple-personality application can then flip the switch without
+invoking the kernel, when crossing the compatibility layer API
+boundaries, to enable/disable the syscall redirection and execute
+syscalls directly (disabled) or send them to be emulated in userspace
+through a SIGSYS.
+
+The goal of this design is to provide very quick compatibility layer
+boundary crosses, which is achieved by not executing a syscall to change
+personality every time the compatibility layer executes. Instead, a
+userspace memory region exposed to the kernel indicates the current
+personality, and the application simply modifies that variable to
+configure the mechanism.
+
+There is a relatively high cost associated with handling signals on most
+architectures, like x86, but at least for Wine, syscalls issued by
+native Windows code are currently not known to be a performance problem,
+since they are quite rare, at least for modern gaming applications.
+
+Since this mechanism is designed to capture syscalls issued by
+non-native applications, it must function on syscalls whose invocation
+ABI is completely unexpected to Linux. Syscall User Dispatch, therefore
+doesn't rely on any of the syscall ABI to make the filtering. It uses
+only the syscall dispatcher address and the userspace key.
+
+As the ABI of these intercepted syscalls is unknown to Linux, these
+syscalls are not instrumentable via ptrace or the syscall tracepoints.
+
+Interface
+---------
+
+A thread can setup this mechanism on supported kernels by executing the
+following prctl:
+
+ prctl(PR_SET_SYSCALL_USER_DISPATCH, <op>, <offset>, <length>, [selector])
+
+<op> is either PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF, to enable and
+disable the mechanism globally for that thread. When
+PR_SYS_DISPATCH_OFF is used, the other fields must be zero.
+
+[<offset>, <offset>+<length>) delimit a memory region interval
+from which syscalls are always executed directly, regardless of the
+userspace selector. This provides a fast path for the C library, which
+includes the most common syscall dispatchers in the native code
+applications, and also provides a way for the signal handler to return
+without triggering a nested SIGSYS on (rt\_)sigreturn. Users of this
+interface should make sure that at least the signal trampoline code is
+included in this region. In addition, for syscalls that implement the
+trampoline code on the vDSO, that trampoline is never intercepted.
+
+[selector] is a pointer to a char-sized region in the process memory
+region, that provides a quick way to enable disable syscall redirection
+thread-wide, without the need to invoke the kernel directly. selector
+can be set to PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF. Any other
+value should terminate the program with a SIGSYS.
+
+Security Notes
+--------------
+
+Syscall User Dispatch provides functionality for compatibility layers to
+quickly capture system calls issued by a non-native part of the
+application, while not impacting the Linux native regions of the
+process. It is not a mechanism for sandboxing system calls, and it
+should not be seen as a security mechanism, since it is trivial for a
+malicious application to subvert the mechanism by jumping to an allowed
+dispatcher region prior to executing the syscall, or to discover the
+address and modify the selector value. If the use case requires any
+kind of security sandboxing, Seccomp should be used instead.
+
+Any fork or exec of the existing process resets the mechanism to
+PR_SYS_DISPATCH_OFF.
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 82b5e7a..e35a3f2 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -873,12 +873,17 @@
unprivileged_userfaultfd
========================
-This flag controls whether unprivileged users can use the userfaultfd
-system calls. Set this to 1 to allow unprivileged users to use the
-userfaultfd system calls, or set this to 0 to restrict userfaultfd to only
-privileged users (with SYS_CAP_PTRACE capability).
+This flag controls the mode in which unprivileged users can use the
+userfaultfd system calls. Set this to 0 to restrict unprivileged users
+to handle page faults in user mode only. In this case, users without
+SYS_CAP_PTRACE must pass UFFD_USER_MODE_ONLY in order for userfaultfd to
+succeed. Prohibiting use of userfaultfd for handling faults from kernel
+mode may make certain vulnerabilities more difficult to exploit.
-The default value is 1.
+Set this to 1 to allow unprivileged users to use the userfaultfd system
+calls without any restrictions.
+
+The default value is 0.
user_reserve_kbytes
diff --git a/Documentation/arm/memory.rst b/Documentation/arm/memory.rst
index 0521b4c..0cb1e29 100644
--- a/Documentation/arm/memory.rst
+++ b/Documentation/arm/memory.rst
@@ -45,9 +45,14 @@
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
-ffc00000 ffefffff Fixmap mapping region. Addresses provided
+ffc80000 ffefffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
+ffc00000 ffc7ffff Guard region
+
+ff800000 ffbfffff Permanent, fixed read-only mapping of the
+ firmware provided DT blob
+
fee00000 feffffff Mapping of PCI I/O space. This is a static
mapping within the vmalloc space.
@@ -72,6 +77,11 @@
Kernel modules inserted via insmod are
placed here using dynamic mappings.
+TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use.
+ The range from MODULES_VADDR to the top
+ of the memory is shadowed here with 1 bit
+ per byte of memory.
+
00001000 TASK_SIZE-1 User space mappings
Per-thread mappings are placed here via
the mmap() system call.
diff --git a/Documentation/arm/samsung-s3c24xx/gpio.rst b/Documentation/arm/samsung-s3c24xx/gpio.rst
index f7c3d7d..f4a8c80 100644
--- a/Documentation/arm/samsung-s3c24xx/gpio.rst
+++ b/Documentation/arm/samsung-s3c24xx/gpio.rst
@@ -29,7 +29,7 @@
The following functions now either have a `s3c_` specific variant
or are merged into gpiolib. See the definitions in
- arch/arm/plat-samsung/include/plat/gpio-cfg.h:
+ 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()
@@ -86,7 +86,7 @@
Headers
-------
- See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list
+ 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>
diff --git a/Documentation/arm/samsung-s3c24xx/overview.rst b/Documentation/arm/samsung-s3c24xx/overview.rst
index e9a1dc7..14535e5 100644
--- a/Documentation/arm/samsung-s3c24xx/overview.rst
+++ b/Documentation/arm/samsung-s3c24xx/overview.rst
@@ -18,7 +18,7 @@
versions.
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
- included under the arch/arm/mach-s3c2416 directory. Note, while core
+ 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.
@@ -37,19 +37,11 @@
Layout
------
- The core support files are located in the platform code contained in
- arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx.
- This directory should be kept to items shared between the platform
- code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code.
+ 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
- Each cpu has a directory with the support files for it, and the
- machines that carry the device. For example S3C2410 is contained
- in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
-
- Register, kernel and platform data definitions are held in the
- arch/arm/mach-s3c2410 directory./include/mach
-
-arch/arm/plat-s3c24xx:
+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
@@ -134,7 +126,7 @@
should keep this in mind before altering items outside of their own
machine files.
- Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
+ 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
@@ -293,7 +285,7 @@
}
Note, since the code is marked as __init, it should not be
- exported outside arch/arm/mach-s3c2410/, or exported to
+ exported outside arch/arm/mach-s3c/, or exported to
modules via EXPORT_SYMBOL() and related functions.
diff --git a/Documentation/arm/samsung-s3c24xx/usb-host.rst b/Documentation/arm/samsung-s3c24xx/usb-host.rst
index c84268b..7aaffac 100644
--- a/Documentation/arm/samsung-s3c24xx/usb-host.rst
+++ b/Documentation/arm/samsung-s3c24xx/usb-host.rst
@@ -36,7 +36,7 @@
-------------
The driver attaches to a platform device, which will need to be
- added by the board specific support file in linux/arch/arm/mach-s3c2410,
+ 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
@@ -51,9 +51,9 @@
Platform Data
-------------
- See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
+ See include/linux/platform_data/usb-ohci-s3c2410.h for the
descriptions of the platform device data. An implementation
- can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
+ 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
diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arm/samsung/gpio.rst
index 5f7cadd..f6e27b0 100644
--- a/Documentation/arm/samsung/gpio.rst
+++ b/Documentation/arm/samsung/gpio.rst
@@ -37,5 +37,4 @@
The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
driver or machine to change gpio configuration.
-See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
-on these functions.
+See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions.
diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arm64/kasan-offsets.sh
index 2b7a021..2dc5f9e 100644
--- a/Documentation/arm64/kasan-offsets.sh
+++ b/Documentation/arm64/kasan-offsets.sh
@@ -1,12 +1,11 @@
#!/bin/sh
# Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW
-# start address at the mid-point of the kernel VA space
+# start address at the top of the linear region
print_kasan_offset () {
printf "%02d\t" $1
printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
- + (1 << ($1 - 32 - $2)) \
- (1 << (64 - 32 - $2)) ))
}
diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
index cf03b32..901cd09 100644
--- a/Documentation/arm64/memory.rst
+++ b/Documentation/arm64/memory.rst
@@ -32,17 +32,16 @@
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
- ffff800000000000 ffff9fffffffffff 32TB kasan shadow region
- ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
- ffffa00008000000 ffffa0000fffffff 128MB modules
- ffffa00010000000 fffffdffbffeffff ~93TB vmalloc
- fffffdffbfff0000 fffffdfffe5f8fff ~998MB [guard region]
- fffffdfffe5f9000 fffffdfffe9fffff 4124KB fixed mappings
- fffffdfffea00000 fffffdfffebfffff 2MB [guard region]
- fffffdfffec00000 fffffdffffbfffff 16MB PCI I/O space
- fffffdffffc00000 fffffdffffdfffff 2MB [guard region]
- fffffdffffe00000 ffffffffffdfffff 2TB vmemmap
- ffffffffffe00000 ffffffffffffffff 2MB [guard region]
+ [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
+ ffff800000000000 ffff800007ffffff 128MB bpf jit region
+ ffff800008000000 ffff80000fffffff 128MB modules
+ ffff800010000000 fffffbffefffffff 124TB vmalloc
+ fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
+ fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
+ fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
+ fffffbffff800000 fffffbffffffffff 8MB [guard region]
+ fffffc0000000000 fffffdffffffffff 2TB vmemmap
+ fffffe0000000000 ffffffffffffffff 2TB [guard region]
AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
@@ -50,19 +49,17 @@
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000fffffffffffff 4PB user
- fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map
- fff8000000000000 fffd9fffffffffff 1440TB [gap]
- fffda00000000000 ffff9fffffffffff 512TB kasan shadow region
- ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
- ffffa00008000000 ffffa0000fffffff 128MB modules
- ffffa00010000000 fffff81ffffeffff ~88TB vmalloc
- fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region]
- fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings
- fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region]
- fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O space
- fffffc1fffc00000 fffffc1fffdfffff 2MB [guard region]
- fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap
- ffffffffffe00000 ffffffffffffffff 2MB [guard region]
+ fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
+ [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
+ ffff800000000000 ffff800007ffffff 128MB bpf jit region
+ ffff800008000000 ffff80000fffffff 128MB modules
+ ffff800010000000 fffffbffefffffff 124TB vmalloc
+ fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
+ fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
+ fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
+ fffffbffff800000 fffffbffffffffff 8MB [guard region]
+ fffffc0000000000 ffffffdfffffffff ~4TB vmemmap
+ ffffffe000000000 ffffffffffffffff 128GB [guard region]
Translation table lookup with 4KB pages::
@@ -100,7 +97,7 @@
random) offset from the linear mapping. See the kern_hyp_va macro and
kvm_update_va_mask function for more details. MMIO devices such as
GICv2 gets mapped next to the HYP idmap page, as do vectors when
-ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs.
+ARM64_SPECTRE_V3A is enabled for particular CPUs.
When using KVM with the Virtualization Host Extensions, no additional
mappings are created, since the host kernel runs directly in EL2.
diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
index eab4323..19d284b 100644
--- a/Documentation/arm64/tagged-pointers.rst
+++ b/Documentation/arm64/tagged-pointers.rst
@@ -53,12 +53,25 @@
Preserving tags
---------------
-Non-zero tags are not preserved when delivering signals. This means that
-signal handlers in applications making use of tags cannot rely on the
-tag information for user virtual addresses being maintained for fields
-inside siginfo_t. One exception to this rule is for signals raised in
-response to watchpoint debug exceptions, where the tag information will
-be preserved.
+When delivering signals, non-zero tags are not preserved in
+siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in
+sigaction.sa_flags when the signal handler was installed. This means
+that signal handlers in applications making use of tags cannot rely
+on the tag information for user virtual addresses being maintained
+in these fields unless the flag was set.
+
+Due to architecture limitations, bits 63:60 of the fault address
+are not preserved in response to synchronous tag check faults
+(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
+treat the values of these bits as undefined in order to accommodate
+future architecture revisions which may preserve the bits.
+
+For signals raised in response to watchpoint debug exceptions, the
+tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
+flag setting.
+
+Non-zero tags are never preserved in sigcontext.fault_address
+regardless of the SA_EXPOSE_TAGBITS flag setting.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
diff --git a/Documentation/core-api/atomic_ops.rst b/Documentation/core-api/atomic_ops.rst
deleted file mode 100644
index 7245834..0000000
--- a/Documentation/core-api/atomic_ops.rst
+++ /dev/null
@@ -1,664 +0,0 @@
-=======================================================
-Semantics and Behavior of Atomic and Bitmask Operations
-=======================================================
-
-:Author: David S. Miller
-
-This document is intended to serve as a guide to Linux port
-maintainers on how to implement atomic counter, bitops, and spinlock
-interfaces properly.
-
-Atomic Type And Operations
-==========================
-
-The atomic_t type should be defined as a signed integer and
-the atomic_long_t type as a signed long integer. Also, they should
-be made opaque such that any kind of cast to a normal C integer type
-will fail. Something like the following should suffice::
-
- typedef struct { int counter; } atomic_t;
- typedef struct { long counter; } atomic_long_t;
-
-Historically, counter has been declared volatile. This is now discouraged.
-See :ref:`Documentation/process/volatile-considered-harmful.rst
-<volatile_considered_harmful>` for the complete rationale.
-
-local_t is very similar to atomic_t. If the counter is per CPU and only
-updated by one CPU, local_t is probably more appropriate. Please see
-:ref:`Documentation/core-api/local_ops.rst <local_ops>` for the semantics of
-local_t.
-
-The first operations to implement for atomic_t's are the initializers and
-plain writes. ::
-
- #define ATOMIC_INIT(i) { (i) }
- #define atomic_set(v, i) ((v)->counter = (i))
-
-The first macro is used in definitions, such as::
-
- static atomic_t my_counter = ATOMIC_INIT(1);
-
-The initializer is atomic in that the return values of the atomic operations
-are guaranteed to be correct reflecting the initialized value if the
-initializer is used before runtime. If the initializer is used at runtime, a
-proper implicit or explicit read memory barrier is needed before reading the
-value with atomic_read from another thread.
-
-As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
-with ``atomic_long_`` to operate on atomic_long_t.
-
-The second interface can be used at runtime, as in::
-
- struct foo { atomic_t counter; };
- ...
-
- struct foo *k;
-
- k = kmalloc(sizeof(*k), GFP_KERNEL);
- if (!k)
- return -ENOMEM;
- atomic_set(&k->counter, 0);
-
-The setting is atomic in that the return values of the atomic operations by
-all threads are guaranteed to be correct reflecting either the value that has
-been set with this operation or set with another operation. A proper implicit
-or explicit memory barrier is needed before the value set with the operation
-is guaranteed to be readable with atomic_read from another thread.
-
-Next, we have::
-
- #define atomic_read(v) ((v)->counter)
-
-which simply reads the counter value currently visible to the calling thread.
-The read is atomic in that the return value is guaranteed to be one of the
-values initialized or modified with the interface operations if a proper
-implicit or explicit memory barrier is used after possible runtime
-initialization by any other thread and the value is modified only with the
-interface operations. atomic_read does not guarantee that the runtime
-initialization by any other thread is visible yet, so the user of the
-interface must take care of that with a proper implicit or explicit memory
-barrier.
-
-.. warning::
-
- ``atomic_read()`` and ``atomic_set()`` DO NOT IMPLY BARRIERS!
-
- Some architectures may choose to use the volatile keyword, barriers, or
- inline assembly to guarantee some degree of immediacy for atomic_read()
- and atomic_set(). This is not uniformly guaranteed, and may change in
- the future, so all users of atomic_t should treat atomic_read() and
- atomic_set() as simple C statements that may be reordered or optimized
- away entirely by the compiler or processor, and explicitly invoke the
- appropriate compiler and/or memory barrier for each use case. Failure
- to do so will result in code that may suddenly break when used with
- different architectures or compiler optimizations, or even changes in
- unrelated code which changes how the compiler optimizes the section
- accessing atomic_t variables.
-
-Properly aligned pointers, longs, ints, and chars (and unsigned
-equivalents) may be atomically loaded from and stored to in the same
-sense as described for atomic_read() and atomic_set(). The READ_ONCE()
-and WRITE_ONCE() macros should be used to prevent the compiler from using
-optimizations that might otherwise optimize accesses out of existence on
-the one hand, or that might create unsolicited accesses on the other.
-
-For example consider the following code::
-
- while (a > 0)
- do_something();
-
-If the compiler can prove that do_something() does not store to the
-variable a, then the compiler is within its rights transforming this to
-the following::
-
- if (a > 0)
- for (;;)
- do_something();
-
-If you don't want the compiler to do this (and you probably don't), then
-you should use something like the following::
-
- while (READ_ONCE(a) > 0)
- do_something();
-
-Alternatively, you could place a barrier() call in the loop.
-
-For another example, consider the following code::
-
- tmp_a = a;
- do_something_with(tmp_a);
- do_something_else_with(tmp_a);
-
-If the compiler can prove that do_something_with() does not store to the
-variable a, then the compiler is within its rights to manufacture an
-additional load as follows::
-
- tmp_a = a;
- do_something_with(tmp_a);
- tmp_a = a;
- do_something_else_with(tmp_a);
-
-This could fatally confuse your code if it expected the same value
-to be passed to do_something_with() and do_something_else_with().
-
-The compiler would be likely to manufacture this additional load if
-do_something_with() was an inline function that made very heavy use
-of registers: reloading from variable a could save a flush to the
-stack and later reload. To prevent the compiler from attacking your
-code in this manner, write the following::
-
- tmp_a = READ_ONCE(a);
- do_something_with(tmp_a);
- do_something_else_with(tmp_a);
-
-For a final example, consider the following code, assuming that the
-variable a is set at boot time before the second CPU is brought online
-and never changed later, so that memory barriers are not needed::
-
- if (a)
- b = 9;
- else
- b = 42;
-
-The compiler is within its rights to manufacture an additional store
-by transforming the above code into the following::
-
- b = 42;
- if (a)
- b = 9;
-
-This could come as a fatal surprise to other code running concurrently
-that expected b to never have the value 42 if a was zero. To prevent
-the compiler from doing this, write something like::
-
- if (a)
- WRITE_ONCE(b, 9);
- else
- WRITE_ONCE(b, 42);
-
-Don't even -think- about doing this without proper use of memory barriers,
-locks, or atomic operations if variable a can change at runtime!
-
-.. warning::
-
- ``READ_ONCE()`` OR ``WRITE_ONCE()`` DO NOT IMPLY A BARRIER!
-
-Now, we move onto the atomic operation interfaces typically implemented with
-the help of assembly code. ::
-
- void atomic_add(int i, atomic_t *v);
- void atomic_sub(int i, atomic_t *v);
- void atomic_inc(atomic_t *v);
- void atomic_dec(atomic_t *v);
-
-These four routines add and subtract integral values to/from the given
-atomic_t value. The first two routines pass explicit integers by
-which to make the adjustment, whereas the latter two use an implicit
-adjustment value of "1".
-
-One very important aspect of these two routines is that they DO NOT
-require any explicit memory barriers. They need only perform the
-atomic_t counter update in an SMP safe manner.
-
-Next, we have::
-
- int atomic_inc_return(atomic_t *v);
- int atomic_dec_return(atomic_t *v);
-
-These routines add 1 and subtract 1, respectively, from the given
-atomic_t and return the new counter value after the operation is
-performed.
-
-Unlike the above routines, it is required that these primitives
-include explicit memory barriers that are performed before and after
-the operation. It must be done such that all memory operations before
-and after the atomic operation calls are strongly ordered with respect
-to the atomic operation itself.
-
-For example, it should behave as if a smp_mb() call existed both
-before and after the atomic operation.
-
-If the atomic instructions used in an implementation provide explicit
-memory barrier semantics which satisfy the above requirements, that is
-fine as well.
-
-Let's move on::
-
- int atomic_add_return(int i, atomic_t *v);
- int atomic_sub_return(int i, atomic_t *v);
-
-These behave just like atomic_{inc,dec}_return() except that an
-explicit counter adjustment is given instead of the implicit "1".
-This means that like atomic_{inc,dec}_return(), the memory barrier
-semantics are required.
-
-Next::
-
- int atomic_inc_and_test(atomic_t *v);
- int atomic_dec_and_test(atomic_t *v);
-
-These two routines increment and decrement by 1, respectively, the
-given atomic counter. They return a boolean indicating whether the
-resulting counter value was zero or not.
-
-Again, these primitives provide explicit memory barrier semantics around
-the atomic operation::
-
- int atomic_sub_and_test(int i, atomic_t *v);
-
-This is identical to atomic_dec_and_test() except that an explicit
-decrement is given instead of the implicit "1". This primitive must
-provide explicit memory barrier semantics around the operation::
-
- int atomic_add_negative(int i, atomic_t *v);
-
-The given increment is added to the given atomic counter value. A boolean
-is return which indicates whether the resulting counter value is negative.
-This primitive must provide explicit memory barrier semantics around
-the operation.
-
-Then::
-
- int atomic_xchg(atomic_t *v, int new);
-
-This performs an atomic exchange operation on the atomic variable v, setting
-the given new value. It returns the old value that the atomic variable v had
-just before the operation.
-
-atomic_xchg must provide explicit memory barriers around the operation. ::
-
- int atomic_cmpxchg(atomic_t *v, int old, int new);
-
-This performs an atomic compare exchange operation on the atomic value v,
-with the given old and new values. Like all atomic_xxx operations,
-atomic_cmpxchg will only satisfy its atomicity semantics as long as all
-other accesses of \*v are performed through atomic_xxx operations.
-
-atomic_cmpxchg must provide explicit memory barriers around the operation,
-although if the comparison fails then no memory ordering guarantees are
-required.
-
-The semantics for atomic_cmpxchg are the same as those defined for 'cas'
-below.
-
-Finally::
-
- int atomic_add_unless(atomic_t *v, int a, int u);
-
-If the atomic value v is not equal to u, this function adds a to v, and
-returns non zero. If v is equal to u then it returns zero. This is done as
-an atomic operation.
-
-atomic_add_unless must provide explicit memory barriers around the
-operation unless it fails (returns 0).
-
-atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
-
-
-If a caller requires memory barrier semantics around an atomic_t
-operation which does not return a value, a set of interfaces are
-defined which accomplish this::
-
- void smp_mb__before_atomic(void);
- void smp_mb__after_atomic(void);
-
-Preceding a non-value-returning read-modify-write atomic operation with
-smp_mb__before_atomic() and following it with smp_mb__after_atomic()
-provides the same full ordering that is provided by value-returning
-read-modify-write atomic operations.
-
-For example, smp_mb__before_atomic() can be used like so::
-
- obj->dead = 1;
- smp_mb__before_atomic();
- atomic_dec(&obj->ref_count);
-
-It makes sure that all memory operations preceding the atomic_dec()
-call are strongly ordered with respect to the atomic counter
-operation. In the above example, it guarantees that the assignment of
-"1" to obj->dead will be globally visible to other cpus before the
-atomic counter decrement.
-
-Without the explicit smp_mb__before_atomic() call, the
-implementation could legally allow the atomic counter update visible
-to other cpus before the "obj->dead = 1;" assignment.
-
-A missing memory barrier in the cases where they are required by the
-atomic_t implementation above can have disastrous results. Here is
-an example, which follows a pattern occurring frequently in the Linux
-kernel. It is the use of atomic counters to implement reference
-counting, and it works such that once the counter falls to zero it can
-be guaranteed that no other entity can be accessing the object::
-
- static void obj_list_add(struct obj *obj, struct list_head *head)
- {
- obj->active = 1;
- list_add(&obj->list, head);
- }
-
- static void obj_list_del(struct obj *obj)
- {
- list_del(&obj->list);
- obj->active = 0;
- }
-
- static void obj_destroy(struct obj *obj)
- {
- BUG_ON(obj->active);
- kfree(obj);
- }
-
- struct obj *obj_list_peek(struct list_head *head)
- {
- if (!list_empty(head)) {
- struct obj *obj;
-
- obj = list_entry(head->next, struct obj, list);
- atomic_inc(&obj->refcnt);
- return obj;
- }
- return NULL;
- }
-
- void obj_poke(void)
- {
- struct obj *obj;
-
- spin_lock(&global_list_lock);
- obj = obj_list_peek(&global_list);
- spin_unlock(&global_list_lock);
-
- if (obj) {
- obj->ops->poke(obj);
- if (atomic_dec_and_test(&obj->refcnt))
- obj_destroy(obj);
- }
- }
-
- void obj_timeout(struct obj *obj)
- {
- spin_lock(&global_list_lock);
- obj_list_del(obj);
- spin_unlock(&global_list_lock);
-
- if (atomic_dec_and_test(&obj->refcnt))
- obj_destroy(obj);
- }
-
-.. note::
-
- This is a simplification of the ARP queue management in the generic
- neighbour discover code of the networking. Olaf Kirch found a bug wrt.
- memory barriers in kfree_skb() that exposed the atomic_t memory barrier
- requirements quite clearly.
-
-Given the above scheme, it must be the case that the obj->active
-update done by the obj list deletion be visible to other processors
-before the atomic counter decrement is performed.
-
-Otherwise, the counter could fall to zero, yet obj->active would still
-be set, thus triggering the assertion in obj_destroy(). The error
-sequence looks like this::
-
- cpu 0 cpu 1
- obj_poke() obj_timeout()
- obj = obj_list_peek();
- ... gains ref to obj, refcnt=2
- obj_list_del(obj);
- obj->active = 0 ...
- ... visibility delayed ...
- atomic_dec_and_test()
- ... refcnt drops to 1 ...
- atomic_dec_and_test()
- ... refcount drops to 0 ...
- obj_destroy()
- BUG() triggers since obj->active
- still seen as one
- obj->active update visibility occurs
-
-With the memory barrier semantics required of the atomic_t operations
-which return values, the above sequence of memory visibility can never
-happen. Specifically, in the above case the atomic_dec_and_test()
-counter decrement would not become globally visible until the
-obj->active update does.
-
-As a historical note, 32-bit Sparc used to only allow usage of
-24-bits of its atomic_t type. This was because it used 8 bits
-as a spinlock for SMP safety. Sparc32 lacked a "compare and swap"
-type instruction. However, 32-bit Sparc has since been moved over
-to a "hash table of spinlocks" scheme, that allows the full 32-bit
-counter to be realized. Essentially, an array of spinlocks are
-indexed into based upon the address of the atomic_t being operated
-on, and that lock protects the atomic operation. Parisc uses the
-same scheme.
-
-Another note is that the atomic_t operations returning values are
-extremely slow on an old 386.
-
-
-Atomic Bitmask
-==============
-
-We will now cover the atomic bitmask operations. You will find that
-their SMP and memory barrier semantics are similar in shape and scope
-to the atomic_t ops above.
-
-Native atomic bit operations are defined to operate on objects aligned
-to the size of an "unsigned long" C data type, and are least of that
-size. The endianness of the bits within each "unsigned long" are the
-native endianness of the cpu. ::
-
- void set_bit(unsigned long nr, volatile unsigned long *addr);
- void clear_bit(unsigned long nr, volatile unsigned long *addr);
- void change_bit(unsigned long nr, volatile unsigned long *addr);
-
-These routines set, clear, and change, respectively, the bit number
-indicated by "nr" on the bit mask pointed to by "ADDR".
-
-They must execute atomically, yet there are no implicit memory barrier
-semantics required of these interfaces. ::
-
- int test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
- int test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
- int test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
-
-Like the above, except that these routines return a boolean which
-indicates whether the changed bit was set _BEFORE_ the atomic bit
-operation.
-
-
-.. warning::
- It is incredibly important that the value be a boolean, ie. "0" or "1".
- Do not try to be fancy and save a few instructions by declaring the
- above to return "long" and just returning something like "old_val &
- mask" because that will not work.
-
-For one thing, this return value gets truncated to int in many code
-paths using these interfaces, so on 64-bit if the bit is set in the
-upper 32-bits then testers will never see that.
-
-One great example of where this problem crops up are the thread_info
-flag operations. Routines such as test_and_set_ti_thread_flag() chop
-the return value into an int. There are other places where things
-like this occur as well.
-
-These routines, like the atomic_t counter operations returning values,
-must provide explicit memory barrier semantics around their execution.
-All memory operations before the atomic bit operation call must be
-made visible globally before the atomic bit operation is made visible.
-Likewise, the atomic bit operation must be visible globally before any
-subsequent memory operation is made visible. For example::
-
- obj->dead = 1;
- if (test_and_set_bit(0, &obj->flags))
- /* ... */;
- obj->killed = 1;
-
-The implementation of test_and_set_bit() must guarantee that
-"obj->dead = 1;" is visible to cpus before the atomic memory operation
-done by test_and_set_bit() becomes visible. Likewise, the atomic
-memory operation done by test_and_set_bit() must become visible before
-"obj->killed = 1;" is visible.
-
-Finally there is the basic operation::
-
- int test_bit(unsigned long nr, __const__ volatile unsigned long *addr);
-
-Which returns a boolean indicating if bit "nr" is set in the bitmask
-pointed to by "addr".
-
-If explicit memory barriers are required around {set,clear}_bit() (which do
-not return a value, and thus does not need to provide memory barrier
-semantics), two interfaces are provided::
-
- void smp_mb__before_atomic(void);
- void smp_mb__after_atomic(void);
-
-They are used as follows, and are akin to their atomic_t operation
-brothers::
-
- /* All memory operations before this call will
- * be globally visible before the clear_bit().
- */
- smp_mb__before_atomic();
- clear_bit( ... );
-
- /* The clear_bit() will be visible before all
- * subsequent memory operations.
- */
- smp_mb__after_atomic();
-
-There are two special bitops with lock barrier semantics (acquire/release,
-same as spinlocks). These operate in the same way as their non-_lock/unlock
-postfixed variants, except that they are to provide acquire/release semantics,
-respectively. This means they can be used for bit_spin_trylock and
-bit_spin_unlock type operations without specifying any more barriers. ::
-
- int test_and_set_bit_lock(unsigned long nr, unsigned long *addr);
- void clear_bit_unlock(unsigned long nr, unsigned long *addr);
- void __clear_bit_unlock(unsigned long nr, unsigned long *addr);
-
-The __clear_bit_unlock version is non-atomic, however it still implements
-unlock barrier semantics. This can be useful if the lock itself is protecting
-the other bits in the word.
-
-Finally, there are non-atomic versions of the bitmask operations
-provided. They are used in contexts where some other higher-level SMP
-locking scheme is being used to protect the bitmask, and thus less
-expensive non-atomic operations may be used in the implementation.
-They have names similar to the above bitmask operation interfaces,
-except that two underscores are prefixed to the interface name. ::
-
- void __set_bit(unsigned long nr, volatile unsigned long *addr);
- void __clear_bit(unsigned long nr, volatile unsigned long *addr);
- void __change_bit(unsigned long nr, volatile unsigned long *addr);
- int __test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
- int __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
- int __test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
-
-These non-atomic variants also do not require any special memory
-barrier semantics.
-
-The routines xchg() and cmpxchg() must provide the same exact
-memory-barrier semantics as the atomic and bit operations returning
-values.
-
-.. note::
-
- If someone wants to use xchg(), cmpxchg() and their variants,
- linux/atomic.h should be included rather than asm/cmpxchg.h, unless the
- code is in arch/* and can take care of itself.
-
-Spinlocks and rwlocks have memory barrier expectations as well.
-The rule to follow is simple:
-
-1) When acquiring a lock, the implementation must make it globally
- visible before any subsequent memory operation.
-
-2) When releasing a lock, the implementation must make it such that
- all previous memory operations are globally visible before the
- lock release.
-
-Which finally brings us to _atomic_dec_and_lock(). There is an
-architecture-neutral version implemented in lib/dec_and_lock.c,
-but most platforms will wish to optimize this in assembler. ::
-
- int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock);
-
-Atomically decrement the given counter, and if will drop to zero
-atomically acquire the given spinlock and perform the decrement
-of the counter to zero. If it does not drop to zero, do nothing
-with the spinlock.
-
-It is actually pretty simple to get the memory barrier correct.
-Simply satisfy the spinlock grab requirements, which is make
-sure the spinlock operation is globally visible before any
-subsequent memory operation.
-
-We can demonstrate this operation more clearly if we define
-an abstract atomic operation::
-
- long cas(long *mem, long old, long new);
-
-"cas" stands for "compare and swap". It atomically:
-
-1) Compares "old" with the value currently at "mem".
-2) If they are equal, "new" is written to "mem".
-3) Regardless, the current value at "mem" is returned.
-
-As an example usage, here is what an atomic counter update
-might look like::
-
- void example_atomic_inc(long *counter)
- {
- long old, new, ret;
-
- while (1) {
- old = *counter;
- new = old + 1;
-
- ret = cas(counter, old, new);
- if (ret == old)
- break;
- }
- }
-
-Let's use cas() in order to build a pseudo-C atomic_dec_and_lock()::
-
- int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
- {
- long old, new, ret;
- int went_to_zero;
-
- went_to_zero = 0;
- while (1) {
- old = atomic_read(atomic);
- new = old - 1;
- if (new == 0) {
- went_to_zero = 1;
- spin_lock(lock);
- }
- ret = cas(atomic, old, new);
- if (ret == old)
- break;
- if (went_to_zero) {
- spin_unlock(lock);
- went_to_zero = 0;
- }
- }
-
- return went_to_zero;
- }
-
-Now, as far as memory barriers go, as long as spin_lock()
-strictly orders all subsequent memory operations (including
-the cas()) with respect to itself, things will be fine.
-
-Said another way, _atomic_dec_and_lock() must guarantee that
-a counter dropping to zero is never made visible before the
-spinlock being acquired.
-
-.. note::
-
- Note that this also means that for the case where the counter is not
- dropping to zero, there are no memory ordering requirements.
diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst
index 096db12..a77c24c 100644
--- a/Documentation/core-api/irq/irq-domain.rst
+++ b/Documentation/core-api/irq/irq-domain.rst
@@ -147,6 +147,7 @@
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
+ irq_domain_create_legacy()
The Legacy mapping is a special case for drivers that already have a
range of irq_descs allocated for the hwirqs. It is used when the
@@ -185,6 +186,11 @@
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
+irq_domain_add_legacy() and irq_domain_create_legacy() are functionally
+equivalent, except for the first argument is different - the former
+accepts an Open Firmware specific 'struct device_node', while the latter
+accepts a more general abstraction 'struct fwnode_handle'.
+
Hierarchy IRQ domain
--------------------
diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst
index 4446a1a..5954ddf 100644
--- a/Documentation/core-api/memory-allocation.rst
+++ b/Documentation/core-api/memory-allocation.rst
@@ -147,6 +147,10 @@
ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
alignment is also guaranteed to be at least the respective size.
+Chunks allocated with kmalloc() can be resized with krealloc(). Similarly
+to kmalloc_array(): a helper for resizing arrays is provided in the form of
+krealloc_array().
+
For large allocations you can use vmalloc() and vzalloc(), or directly
request pages from the page allocator. The memory allocated by `vmalloc`
and related functions is not physically contiguous.
diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst
index 7ca8c7b..fcf605b 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -221,12 +221,12 @@
============
This file::
- tools/testing/selftests/vm/gup_benchmark.c
+ tools/testing/selftests/vm/gup_test.c
has the following new calls to exercise the new pin*() wrapper functions:
-* PIN_FAST_BENCHMARK (./gup_benchmark -a)
-* PIN_BENCHMARK (./gup_benchmark -b)
+* PIN_FAST_BENCHMARK (./gup_test -a)
+* PIN_BASIC_TEST (./gup_test -b)
You can monitor how many total dma-pinned pages have been acquired and released
since the system was booted, via two new /proc/vmstat entries: ::
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 0bd6d0e..0fc3fb1 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -4,13 +4,16 @@
Overview
--------
-KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to
-find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN
-(similar to userspace ASan) and software tag-based KASAN (similar to userspace
-HWASan).
+KernelAddressSANitizer (KASAN) is a dynamic memory safety error detector
+designed to find out-of-bound and use-after-free bugs. KASAN has three modes:
-KASAN uses compile-time instrumentation to insert validity checks before every
-memory access, and therefore requires a compiler version that supports that.
+1. generic KASAN (similar to userspace ASan),
+2. software tag-based KASAN (similar to userspace HWASan),
+3. hardware tag-based KASAN (based on hardware memory tagging).
+
+Software KASAN modes (1 and 2) use compile-time instrumentation to insert
+validity checks before every memory access, and therefore require a compiler
+version that supports that.
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
8.3.0 or later. Any supported Clang version is compatible, but detection of
@@ -18,8 +21,8 @@
Tag-based KASAN is only supported in Clang.
-Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
-riscv architectures, and tag-based KASAN is supported only for arm64.
+Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390
+and riscv architectures, and tag-based KASAN modes are supported only for arm64.
Usage
-----
@@ -28,30 +31,22 @@
CONFIG_KASAN = y
-and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and
-CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).
+and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN),
+CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN), and
+CONFIG_KASAN_HW_TAGS (to enable hardware tag-based KASAN).
-You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE.
-Outline and inline are compiler instrumentation types. The former produces
-smaller binary while the latter is 1.1 - 2 times faster.
+For software modes, you also need to choose between CONFIG_KASAN_OUTLINE and
+CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types.
+The former produces smaller binary while the latter is 1.1 - 2 times faster.
-Both KASAN modes work with both SLUB and SLAB memory allocators.
-For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
+Both software KASAN modes work with both SLUB and SLAB memory allocators,
+while the hardware tag-based KASAN currently only support SLUB.
+
+For better error reports that include stack traces, enable CONFIG_STACKTRACE.
To augment reports with last allocation and freeing stack of the physical page,
it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
-To disable instrumentation for specific files or directories, add a line
-similar to the following to the respective kernel Makefile:
-
-- For a single file (e.g. main.o)::
-
- KASAN_SANITIZE_main.o := n
-
-- For all files in one directory::
-
- KASAN_SANITIZE := n
-
Error reports
~~~~~~~~~~~~~
@@ -136,22 +131,75 @@
the accessed slab object and information about the accessed memory page.
In the last section the report shows memory state around the accessed address.
-Reading this part requires some understanding of how KASAN works.
+Internally KASAN tracks memory state separately for each memory granule, which
+is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
+memory state section of the report shows the state of one of the memory
+granules that surround the accessed address.
-The state of each 8 aligned bytes of memory is encoded in one shadow byte.
-Those 8 bytes can be accessible, partially accessible, freed or be a redzone.
-We use the following encoding for each shadow byte: 0 means that all 8 bytes
-of the corresponding memory region are accessible; number N (1 <= N <= 7) means
-that the first N bytes are accessible, and other (8 - N) bytes are not;
-any negative value indicates that the entire 8-byte word is inaccessible.
-We use different negative values to distinguish between different kinds of
-inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h).
+For generic KASAN the size of each memory granule is 8. The state of each
+granule is encoded in one shadow byte. Those 8 bytes can be accessible,
+partially accessible, freed or be a part of a redzone. KASAN uses the following
+encoding for each shadow byte: 0 means that all 8 bytes of the corresponding
+memory region are accessible; number N (1 <= N <= 7) means that the first N
+bytes are accessible, and other (8 - N) bytes are not; any negative value
+indicates that the entire 8-byte word is inaccessible. KASAN uses different
+negative values to distinguish between different kinds of inaccessible memory
+like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible.
For tag-based KASAN this last report section shows the memory tags around the
-accessed address (see Implementation details section).
+accessed address (see `Implementation details`_ section).
+
+Boot parameters
+~~~~~~~~~~~~~~~
+
+Hardware tag-based KASAN mode (see the section about different mode below) is
+intended for use in production as a security mitigation. Therefore it supports
+boot parameters that allow to disable KASAN competely or otherwise control
+particular KASAN features.
+
+The things that can be controlled are:
+
+1. Whether KASAN is enabled at all.
+2. Whether KASAN collects and saves alloc/free stacks.
+3. Whether KASAN panics on a detected bug or not.
+
+The ``kasan.mode`` boot parameter allows to choose one of three main modes:
+
+- ``kasan.mode=off`` - KASAN is disabled, no tag checks are performed
+- ``kasan.mode=prod`` - only essential production features are enabled
+- ``kasan.mode=full`` - all KASAN features are enabled
+
+The chosen mode provides default control values for the features mentioned
+above. However it's also possible to override the default values by providing:
+
+- ``kasan.stacktrace=off`` or ``=on`` - enable alloc/free stack collection
+ (default: ``on`` for ``mode=full``,
+ otherwise ``off``)
+- ``kasan.fault=report`` or ``=panic`` - only print KASAN report or also panic
+ (default: ``report``)
+
+If ``kasan.mode`` parameter is not provided, it defaults to ``full`` when
+``CONFIG_DEBUG_KERNEL`` is enabled, and to ``prod`` otherwise.
+
+For developers
+~~~~~~~~~~~~~~
+
+Software KASAN modes use compiler instrumentation to insert validity checks.
+Such instrumentation might be incompatible with some part of the kernel, and
+therefore needs to be disabled. To disable instrumentation for specific files
+or directories, add a line similar to the following to the respective kernel
+Makefile:
+
+- For a single file (e.g. main.o)::
+
+ KASAN_SANITIZE_main.o := n
+
+- For all files in one directory::
+
+ KASAN_SANITIZE := n
Implementation details
@@ -160,10 +208,10 @@
Generic KASAN
~~~~~~~~~~~~~
-From a high level, our approach to memory error detection is similar to that
-of kmemcheck: use shadow memory to record whether each byte of memory is safe
-to access, and use compile-time instrumentation to insert checks of shadow
-memory on each memory access.
+From a high level perspective, KASAN's approach to memory error detection is
+similar to that of kmemcheck: use shadow memory to record whether each byte of
+memory is safe to access, and use compile-time instrumentation to insert checks
+of shadow memory on each memory access.
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
@@ -190,23 +238,34 @@
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
-Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one
-and the second to last.
+Generic KASAN also reports the last 2 call stacks to creation of work that
+potentially has access to an object. Call stacks for the following are shown:
+call_rcu() and workqueue queuing.
+
+Generic KASAN is the only mode that delays the reuse of freed object via
+quarantine (see mm/kasan/quarantine.c for implementation).
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
-Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to
-store a pointer tag in the top byte of kernel pointers. Like generic KASAN it
-uses shadow memory to store memory tags associated with each 16-byte memory
+Software tag-based KASAN requires software memory tagging support in the form
+of HWASan-like compiler instrumentation (see HWASan documentation for details).
+
+Software tag-based KASAN is currently only implemented for arm64 architecture.
+
+Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
+to store a pointer tag in the top byte of kernel pointers. Like generic KASAN
+it uses shadow memory to store memory tags associated with each 16-byte memory
cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
-On each memory allocation tag-based KASAN generates a random tag, tags the
-allocated memory with this tag, and embeds this tag into the returned pointer.
+On each memory allocation software tag-based KASAN generates a random tag, tags
+the allocated memory with this tag, and embeds this tag into the returned
+pointer.
+
Software tag-based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that tag of the memory that
is being accessed is equal to tag of the pointer that is used to access this
-memory. In case of a tag mismatch tag-based KASAN prints a bug report.
+memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
Software tag-based KASAN also has two instrumentation modes (outline, that
emits callbacks to check memory accesses; and inline, that performs the shadow
@@ -215,9 +274,36 @@
instrumentation a brk instruction is emitted by the compiler, and a dedicated
brk handler is used to print bug reports.
-A potential expansion of this mode is a hardware tag-based mode, which would
-use hardware memory tagging support instead of compiler instrumentation and
-manual shadow memory manipulation.
+Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
+pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
+reserved to tag freed memory regions.
+
+Software tag-based KASAN currently only supports tagging of
+kmem_cache_alloc/kmalloc and page_alloc memory.
+
+Hardware tag-based KASAN
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Hardware tag-based KASAN is similar to the software mode in concept, but uses
+hardware memory tagging support instead of compiler instrumentation and
+shadow memory.
+
+Hardware tag-based KASAN is currently only implemented for arm64 architecture
+and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
+Instruction Set Architecture, and Top Byte Ignore (TBI).
+
+Special arm64 instructions are used to assign memory tags for each allocation.
+Same tags are assigned to pointers to those allocations. On every memory
+access, hardware makes sure that tag of the memory that is being accessed is
+equal to tag of the pointer that is used to access this memory. In case of a
+tag mismatch a fault is generated and a report is printed.
+
+Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
+pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
+reserved to tag freed memory regions.
+
+Hardware tag-based KASAN currently only supports tagging of
+kmem_cache_alloc/kmalloc and page_alloc memory.
What memory accesses are sanitised by KASAN?
--------------------------------------------
@@ -264,17 +350,17 @@
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mappings
use different shadow pages, mappings would have to be aligned to
-``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``.
+``KASAN_GRANULE_SIZE * PAGE_SIZE``.
-Instead, we share backing space across multiple mappings. We allocate
+Instead, KASAN shares backing space across multiple mappings. It allocates
a backing page when a mapping in vmalloc space uses a particular page
of the shadow region. This page can be shared by other vmalloc
mappings later on.
-We hook in to the vmap infrastructure to lazily clean up unused shadow
+KASAN hooks into the vmap infrastructure to lazily clean up unused shadow
memory.
-To avoid the difficulties around swapping mappings around, we expect
+To avoid the difficulties around swapping mappings around, KASAN expects
that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.
@@ -285,24 +371,31 @@
CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE
--------------------------------------------------
-``CONFIG_KASAN_KUNIT_TEST`` utilizes the KUnit Test Framework for testing.
-This means each test focuses on a small unit of functionality and
-there are a few ways these tests can be run.
+KASAN tests consist on two parts:
-Each test will print the KASAN report if an error is detected and then
-print the number of the test and the status of the test:
+1. Tests that are integrated with the KUnit Test Framework. Enabled with
+``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
+automatically in a few different ways, see the instructions below.
-pass::
+2. Tests that are currently incompatible with KUnit. Enabled with
+``CONFIG_TEST_KASAN_MODULE`` and can only be run as a module. These tests can
+only be verified manually, by loading the kernel module and inspecting the
+kernel log for KASAN reports.
+
+Each KUnit-compatible KASAN test prints a KASAN report if an error is detected.
+Then the test prints its number and status.
+
+When a test passes::
ok 28 - kmalloc_double_kzfree
-or, if kmalloc failed::
+When a test fails due to a failed ``kmalloc``::
# kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163
Expected ptr is not null, but is
not ok 4 - kmalloc_large_oob_right
-or, if a KASAN report was expected, but not found::
+When a test fails due to a missing KASAN report::
# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
Expected kasan_data->report_expected == kasan_data->report_found, but
@@ -310,46 +403,38 @@
kasan_data->report_found == 0
not ok 28 - kmalloc_double_kzfree
-All test statuses are tracked as they run and an overall status will
-be printed at the end::
+At the end the cumulative status of all KASAN tests is printed. On success::
ok 1 - kasan
-or::
+Or, if one of the tests failed::
not ok 1 - kasan
-(1) Loadable Module
-~~~~~~~~~~~~~~~~~~~~
+
+There are a few ways to run KUnit-compatible KASAN tests.
+
+1. Loadable module
+~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` enabled, ``CONFIG_KASAN_KUNIT_TEST`` can be built as
-a loadable module and run on any architecture that supports KASAN
-using something like insmod or modprobe. The module is called ``test_kasan``.
+a loadable module and run on any architecture that supports KASAN by loading
+the module with insmod or modprobe. The module is called ``test_kasan``.
-(2) Built-In
-~~~~~~~~~~~~~
+2. Built-In
+~~~~~~~~~~~
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
-on any architecture that supports KASAN. These and any other KUnit
-tests enabled will run and print the results at boot as a late-init
-call.
+on any architecure that supports KASAN. These and any other KUnit tests enabled
+will run and print the results at boot as a late-init call.
-(3) Using kunit_tool
-~~~~~~~~~~~~~~~~~~~~~
+3. Using kunit_tool
+~~~~~~~~~~~~~~~~~~~
-With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, we can also
-use kunit_tool to see the results of these along with other KUnit
-tests in a more readable way. This will not print the KASAN reports
-of tests that passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ for more up-to-date
-information on kunit_tool.
+With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it's also
+possible use ``kunit_tool`` to see the results of these and other KUnit tests
+in a more readable way. This will not print the KASAN reports of the tests that
+passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
+for more up-to-date information on ``kunit_tool``.
.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
-
-``CONFIG_TEST_KASAN_MODULE`` is a set of KASAN tests that could not be
-converted to KUnit. These tests can be run only as a module with
-``CONFIG_TEST_KASAN_MODULE`` built as a loadable module and
-``CONFIG_KASAN`` built-in. The type of error expected and the
-function being run is printed before the expression expected to give
-an error. Then the error is printed, if found, and that test
-should be interpreted to pass only if the error was the one expected
-by the test.
diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst
index 1628862..8d5029a 100644
--- a/Documentation/dev-tools/kunit/faq.rst
+++ b/Documentation/dev-tools/kunit/faq.rst
@@ -90,7 +90,7 @@
re-run kunit_tool.
5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This
may help clean up any residual config items which could be causing problems.
-6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be
+6. Finally, try running KUnit outside UML. KUnit and KUnit tests can be
built into any kernel, or can be built as a module and loaded at runtime.
Doing so should allow you to determine if UML is causing the issue you're
seeing. When tests are built-in, they will execute when the kernel boots, and
diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst
index da1d6f0..8dbcdc5 100644
--- a/Documentation/dev-tools/kunit/style.rst
+++ b/Documentation/dev-tools/kunit/style.rst
@@ -175,17 +175,17 @@
.. code-block:: none
- config FOO_KUNIT_TEST
- tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
- depends on KUNIT
- default KUNIT_ALL_TESTS
- help
- This builds unit tests for foo.
+ config FOO_KUNIT_TEST
+ tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for foo.
- For more information on KUnit and unit tests in general, please refer
- to the KUnit documentation in Documentation/dev-tools/kunit
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
- If unsure, say N
+ If unsure, say N.
Test File and Module Names
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 62142a4..d9fdc14 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -15,10 +15,10 @@
Organization of this document
=============================
-This document is organized into two main sections: Testing and Isolating
-Behavior. The first covers what unit tests are and how to use KUnit to write
-them. The second covers how to use KUnit to isolate code and make it possible
-to unit test code that was otherwise un-unit-testable.
+This document is organized into two main sections: Testing and Common Patterns.
+The first covers what unit tests are and how to use KUnit to write them. The
+second covers common testing patterns, e.g. how to isolate code and make it
+possible to unit test code that was otherwise un-unit-testable.
Testing
=======
@@ -92,7 +92,7 @@
the second parameter, in this case, is what the value is expected to be; the
last value is what the value actually is. If ``add`` passes all of these
expectations, the test case, ``add_test_basic`` will pass; if any one of these
-expectations fail, the test case will fail.
+expectations fails, the test case will fail.
It is important to understand that a test case *fails* when any expectation is
violated; however, the test will continue running, potentially trying other
@@ -202,7 +202,7 @@
kunit_test_suite(example_test_suite);
In the above example the test suite, ``example_test_suite``, would run the test
-cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``,
+cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``;
each would have ``example_test_init`` called immediately before it and would
have ``example_test_exit`` called immediately after it.
``kunit_test_suite(example_test_suite)`` registers the test suite with the
@@ -218,8 +218,11 @@
For more information on these types of things see the :doc:`api/test`.
+Common Patterns
+===============
+
Isolating Behavior
-==================
+------------------
The most important aspect of unit testing that other forms of testing do not
provide is the ability to limit the amount of code under test to a single unit.
@@ -229,11 +232,11 @@
such that the definition of that function can be changed without affecting the
rest of the code base. In the kernel this primarily comes from two constructs,
classes, structs that contain function pointers that are provided by the
-implementer, and architecture specific functions which have definitions selected
+implementer, and architecture-specific functions which have definitions selected
at compile time.
Classes
--------
+~~~~~~~
Classes are not a construct that is built into the C programming language;
however, it is an easily derived concept. Accordingly, pretty much every project
@@ -451,6 +454,74 @@
destroy_eeprom_buffer(ctx->eeprom_buffer);
}
+Testing against multiple inputs
+-------------------------------
+
+Testing just a few inputs might not be enough to have confidence that the code
+works correctly, e.g. for a hash function.
+
+In such cases, it can be helpful to have a helper macro or function, e.g. this
+fictitious example for ``sha1sum(1)``
+
+.. code-block:: c
+
+ /* Note: the cast is to satisfy overly strict type-checking. */
+ #define TEST_SHA1(in, want) \
+ sha1sum(in, out); \
+ KUNIT_EXPECT_STREQ_MSG(test, (char *)out, want, "sha1sum(%s)", in);
+
+ char out[40];
+ TEST_SHA1("hello world", "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed");
+ TEST_SHA1("hello world!", "430ce34d020724ed75a196dfc2ad67c77772d169");
+
+
+Note the use of ``KUNIT_EXPECT_STREQ_MSG`` to give more context when it fails
+and make it easier to track down. (Yes, in this example, ``want`` is likely
+going to be unique enough on its own).
+
+The ``_MSG`` variants are even more useful when the same expectation is called
+multiple times (in a loop or helper function) and thus the line number isn't
+enough to identify what failed, like below.
+
+In some cases, it can be helpful to write a *table-driven test* instead, e.g.
+
+.. code-block:: c
+
+ int i;
+ char out[40];
+
+ struct sha1_test_case {
+ const char *str;
+ const char *sha1;
+ };
+
+ struct sha1_test_case cases[] = {
+ {
+ .str = "hello world",
+ .sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
+ },
+ {
+ .str = "hello world!",
+ .sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169",
+ },
+ };
+ for (i = 0; i < ARRAY_SIZE(cases); ++i) {
+ sha1sum(cases[i].str, out);
+ KUNIT_EXPECT_STREQ_MSG(test, (char *)out, cases[i].sha1,
+ "sha1sum(%s)", cases[i].str);
+ }
+
+
+There's more boilerplate involved, but it can:
+
+* be more readable when there are multiple inputs/outputs thanks to field names,
+
+ * E.g. see ``fs/ext4/inode-test.c`` for an example of both.
+* reduce duplication if test cases can be shared across multiple tests.
+
+ * E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256``
+ field and reuse ``cases``.
+
.. _kunit-on-non-uml:
KUnit on non-UML architectures
@@ -459,7 +530,7 @@
By default KUnit uses UML as a way to provide dependencies for code under test.
Under most circumstances KUnit's usage of UML should be treated as an
implementation detail of how KUnit works under the hood. Nevertheless, there
-are instances where being able to run architecture specific code or test
+are instances where being able to run architecture-specific code or test
against real hardware is desirable. For these reasons KUnit supports running on
other architectures.
@@ -599,7 +670,7 @@
hardware state in between test cases; if this is not possible, you may only be
able to run one test case per invocation.
-.. TODO(brendanhiggins@google.com): Add an actual example of an architecture
+.. TODO(brendanhiggins@google.com): Add an actual example of an architecture-
dependent KUnit test.
KUnit debugfs representation
diff --git a/Documentation/dev-tools/ubsan.rst b/Documentation/dev-tools/ubsan.rst
index 655e6b6..1be6618 100644
--- a/Documentation/dev-tools/ubsan.rst
+++ b/Documentation/dev-tools/ubsan.rst
@@ -86,3 +86,4 @@
.. _1: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html
.. _2: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
+.. _3: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
index f504200..8f2b054 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -27,17 +27,17 @@
-name '*.example.dt.yaml' \)
quiet_cmd_yamllint = LINT $(src)
- cmd_yamllint = $(find_cmd) | \
- xargs $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint
+ cmd_yamllint = ($(find_cmd) | \
+ xargs $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint) || true
quiet_cmd_chk_bindings = CHKDT $@
- cmd_chk_bindings = $(find_cmd) | \
- xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(srctree)/$(src)
+ cmd_chk_bindings = ($(find_cmd) | \
+ xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(srctree)/$(src)) || true
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = f=$$(mktemp) ; \
$(if $(DT_MK_SCHEMA_FLAGS), \
- echo $(real-prereqs), \
+ printf '%s\n' $(real-prereqs), \
$(find_cmd)) > $$f ; \
$(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \
rm -f $$f
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
index 55deb68..b5ce5b3 100644
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
@@ -62,6 +62,20 @@
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCMI commands.
+Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
+------------------------------------------------------------
+An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
+and should be always positioned as a root regulator.
+It does not support any current operation.
+
+SCMI Regulators are grouped under a 'regulators' node which in turn is a child
+of the SCMI Voltage protocol node inside the desired SCMI instance node.
+
+This binding uses the common regulator binding[6].
+
+Required properties:
+ - reg : shall identify an existent SCMI Voltage Domain.
+
Sensor bindings for the sensors based on SCMI Message Protocol
--------------------------------------------------------------
SCMI provides an API to access the various sensors on the SoC.
@@ -105,6 +119,7 @@
[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
[4] Documentation/devicetree/bindings/sram/sram.yaml
[5] Documentation/devicetree/bindings/reset/reset.txt
+[6] Documentation/devicetree/bindings/regulator/regulator.yaml
Example:
@@ -169,6 +184,25 @@
reg = <0x16>;
#reset-cells = <1>;
};
+
+ scmi_voltage: protocol@17 {
+ reg = <0x17>;
+
+ regulators {
+ regulator_devX: regulator@0 {
+ reg = <0x0>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ regulator_devY: regulator@9 {
+ reg = <0x9>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <4200000>;
+ };
+
+ ...
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml
new file mode 100644
index 0000000..5fec063
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4908.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4908 device tree bindings
+
+description:
+ Broadcom BCM4906 / BCM4908 / BCM49408 Wi-Fi/network SoCs with Brahma CPUs.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: BCM4906 based boards
+ items:
+ - const: brcm,bcm4906
+ - const: brcm,bcm4908
+
+ - description: BCM4908 based boards
+ items:
+ - enum:
+ - asus,gt-ac5300
+ - const: brcm,bcm4908
+
+ - description: BCM49408 based boards
+ items:
+ - const: brcm,bcm49408
+ - const: brcm,bcm4908
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 6064d98..395359d 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -89,7 +89,10 @@
"fsl,imx8qm-clock"
"fsl,imx8qxp-clock"
followed by "fsl,scu-clk"
-- #clock-cells: Should be 1. Contains the Clock ID value.
+- #clock-cells: Should be either
+ 2: Contains the Resource and Clock ID value.
+ or
+ 1: Contains the Clock ID value. (DEPRECATED)
- clocks: List of clock specifiers, must contain an entry for
each required entry in clock-names
- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
@@ -208,7 +211,7 @@
clk: clk {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
- #clock-cells = <1>;
+ #clock-cells = <2>;
};
iomuxc {
@@ -263,8 +266,7 @@
...
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpuart0>;
- clocks = <&clk IMX8QXP_UART0_CLK>,
- <&clk IMX8QXP_UART0_IPG_CLK>;
- clock-names = "per", "ipg";
+ clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
+ clock-names = "ipg";
power-domains = <&pd IMX_SC_R_UART_0>;
};
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 9342894..34000f7 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -33,16 +33,57 @@
items:
- enum:
- fsl,imx25-pdk
+ - karo,imx25-tx25
- const: fsl,imx25
- - description: i.MX27 Product Development Kit
+ - description: i.MX25 Eukrea CPUIMX25 Boards
+ items:
+ - enum:
+ - eukrea,mbimxsd25-baseboard # Eukrea MBIMXSD25
+ - const: eukrea,cpuimx25
+ - const: fsl,imx25
+
+ - description: i.MX25 Eukrea MBIMXSD25 Boards
+ items:
+ - enum:
+ - eukrea,mbimxsd25-baseboard-cmo-qvga
+ - eukrea,mbimxsd25-baseboard-dvi-svga
+ - eukrea,mbimxsd25-baseboard-dvi-vga
+ - const: eukrea,mbimxsd25-baseboard
+ - const: eukrea,cpuimx25
+ - const: fsl,imx25
+
+ - description: i.MX27 based Boards
items:
- enum:
- armadeus,imx27-apf27 # APF27 SoM
- - armadeus,imx27-apf27dev # APF27 SoM on APF27Dev board
- fsl,imx27-pdk
- const: fsl,imx27
+ - description: i.MX27 APF27 SoM Board
+ items:
+ - const: armadeus,imx27-apf27dev
+ - const: armadeus,imx27-apf27
+ - const: fsl,imx27
+
+ - description: i.MX27 Eukrea CPUIMX27 SoM Board
+ items:
+ - const: eukrea,mbimxsd27-baseboard
+ - const: eukrea,cpuimx27
+ - const: fsl,imx27
+
+ - description: i.MX27 Phytec pca100 Board
+ items:
+ - const: phytec,imx27-pca100-rdk
+ - const: phytec,imx27-pca100
+ - const: fsl,imx27
+
+ - description: i.MX27 Phytec pcm970 Board
+ items:
+ - const: phytec,imx27-pcm970
+ - const: phytec,imx27-pcm038
+ - const: fsl,imx27
+
- description: i.MX28 based Boards
items:
- enum:
@@ -88,13 +129,33 @@
- kobo,aura
- const: fsl,imx50
- - description: i.MX51 Babbage Board
+ - description: i.MX51 based Boards
items:
- enum:
- - armadeus,imx51-apf51 # APF51 SoM
- - armadeus,imx51-apf51dev # APF51 SoM on APF51Dev board
+ - armadeus,imx51-apf51 # Armadeus Systems APF51 module
- fsl,imx51-babbage
- technologic,imx51-ts4800
+ - zii,imx51-scu3-esb
+ - zii,imx51-scu2-mezz
+ - zii,imx51-rdu1
+ - const: fsl,imx51
+
+ - description: i.MX51 based Armadeus Systems APF51Dev Board
+ items:
+ - const: armadeus,imx51-apf51dev
+ - const: armadeus,imx51-apf51
+ - const: fsl,imx51
+
+ - description: i.MX51 based Digi ConnectCore CC(W)-MX51 JSK Board
+ items:
+ - const: digi,connectcore-ccxmx51-jsk
+ - const: digi,connectcore-ccxmx51-som
+ - const: fsl,imx51
+
+ - description: i.MX51 based Eukrea CPUIMX51 Board
+ items:
+ - const: eukrea,mbimxsd51
+ - const: eukrea,cpuimx51
- const: fsl,imx51
- description: i.MX53 based Boards
@@ -104,36 +165,111 @@
- fsl,imx53-ard
- fsl,imx53-evk
- fsl,imx53-qsb
+ - fsl,imx53-qsrb # Freescale i.MX53 Quick Start-R Board
- fsl,imx53-smd
+ - ge,imx53-cpuvo # General Electric CS ONE
+ - inversepath,imx53-usbarmory # Inverse Path USB armory
+ - karo,tx53 # Ka-Ro electronics TX53 module
+ - kiebackpeter,imx53-ddc # K+P imx53 DDC
+ - kiebackpeter,imx53-hsc # K+P imx53 HSC
- menlo,m53menlo
+ - voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668
+ - const: fsl,imx53
+
+ - description: i.MX53 based Aries/DENX M53EVK Board
+ items:
+ - const: aries,imx53-m53evk
+ - const: denx,imx53-m53evk
+ - const: fsl,imx53
+
+ - description: i.MX53 based TQ MBa53 Board
+ items:
+ - const: tq,mba53
+ - const: tq,tqma53
- const: fsl,imx53
- description: i.MX6Q based Boards
items:
- enum:
- - armadeus,imx6q-apf6 # APF6 (Quad/Dual) SoM
- - armadeus,imx6q-apf6dev # APF6 (Quad/Dual) SoM on APF6Dev board
+ - auvidea,h100 # Auvidea H100
+ - boundary,imx6q-nitrogen6_max
+ - boundary,imx6q-nitrogen6_som2
+ - boundary,imx6q-nitrogen6x
+ - compulab,cm-fx6 # CompuLab CM-FX6
+ - dmo,imx6q-edmqmx6 # Data Modul eDM-QMX6 Board
+ - embest,imx6q-marsboard # Embest MarS Board i.MX6Dual
- emtrion,emcon-mx6 # emCON-MX6D or emCON-MX6Q SoM
- emtrion,emcon-mx6-avari # emCON-MX6D or emCON-MX6Q SoM on Avari Base
+ - engicam,imx6-icore # Engicam i.CoreM6 Starter Kit
+ - engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit
- fsl,imx6q-arm2
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
+ - karo,imx6q-tx6q # Ka-Ro electronics TX6Q Modules
+ - kiebackpeter,imx6q-tpc # K+P i.MX6 Quad TPC Board
- kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module
+ - kosagi,imx6q-novena # Kosagi Novena Dual/Quad
- logicpd,imx6q-logicpd
+ - lwn,display5 # Liebherr Display5 i.MX6 Quad Board
+ - lwn,mccmon6 # Liebherr Monitor6 i.MX6 Quad Board
+ - nutsboard,imx6q-pistachio # NutsBoard i.MX6 Quad Pistachio
+ - microsys,sbc6x # MicroSys sbc6x board
+ - poslab,imx6q-savageboard # Poslab SavageBoard Quad
- prt,prti6q # Protonic PRTI6Q board
- prt,prtwd2 # Protonic WD2 board
+ - rex,imx6q-rex-pro # Rex Pro i.MX6 Quad Board
+ - solidrun,cubox-i/q # SolidRun Cubox-i Dual/Quad
+ - solidrun,hummingboard/q
+ - solidrun,hummingboard2/q
+ - tbs,imx6q-tbs2910 # TBS2910 Matrix ARM mini PC
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
- technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi
- technologic,imx6q-ts4900
- technologic,imx6q-ts7970
- - toradex,apalis_imx6q # Apalis iMX6 Module
- - toradex,apalis_imx6q-eval # Apalis iMX6 Module on Apalis Evaluation Board
- - toradex,apalis_imx6q-ixora # Apalis iMX6 Module on Ixora
- - toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6 Module on Ixora V1.1
+ - toradex,apalis_imx6q # Apalis iMX6 Module
+ - udoo,imx6q-udoo # Udoo i.MX6 Quad Board
+ - uniwest,imx6q-evi # Uniwest Evi
- variscite,dt6customboard
+ - wand,imx6q-wandboard # Wandboard i.MX6 Quad Board
+ - zealz,imx6q-gk802 # Zealz GK802
+ - zii,imx6q-zii-rdu2 # ZII RDU2 Board
+ - const: fsl,imx6q
+
+ - description: i.MX6Q Advantech DMS-BA16 Boards
+ items:
+ - enum:
+ - advantech,imx6q-dms-ba16 # Advantech DMS-BA16
+ - ge,imx6q-b450v3 # General Electric B450v3
+ - ge,imx6q-b650v3 # General Electric B650v3
+ - ge,imx6q-b850v3 # General Electric B850v3
+ - const: advantech,imx6q-ba16
+ - const: fsl,imx6q
+
+ - description: i.MX6Q Armadeus APF6 Boards
+ items:
+ - const: armadeus,imx6q-apf6dev
+ - const: armadeus,imx6q-apf6
+ - const: fsl,imx6q
+
+ - description: i.MX6Q CompuLab Utilite Pro Board
+ items:
+ - const: compulab,utilite-pro
+ - const: compulab,cm-fx6
+ - const: fsl,imx6q
+
+ - description: i.MX6Q DFI FS700-M60-6QD Board
+ items:
+ - const: dfi,fs700-m60-6qd
+ - const: dfi,fs700e-m60
+ - const: fsl,imx6q
+
+ - description: i.MX6Q DHCOM Premium Developer Kit Board
+ items:
+ - const: dh,imx6q-dhcom-pdk2
+ - const: dh,imx6q-dhcom-som
- const: fsl,imx6q
- description: i.MX6Q Gateworks Ventana Boards
@@ -172,11 +308,32 @@
- const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
- const: fsl,imx6q
+ - description: i.MX6Q Boards with Toradex Apalis iMX6Q/D Module
+ items:
+ - enum:
+ - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board
+ - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board
+ - const: toradex,apalis_imx6q
+ - const: fsl,imx6q
+
+ - description: i.MX6Q Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1
+ items:
+ - const: toradex,apalis_imx6q-ixora-v1.1
+ - const: toradex,apalis_imx6q-ixora
+ - const: toradex,apalis_imx6q
+ - const: fsl,imx6q
+
- description: i.MX6QP based Boards
items:
- enum:
+ - boundary,imx6qp-nitrogen6_max
+ - boundary,imx6qp-nitrogen6_som2
- fsl,imx6qp-sabreauto # i.MX6 Quad Plus SABRE Automotive Board
- fsl,imx6qp-sabresd # i.MX6 Quad Plus SABRE Smart Device Board
+ - karo,imx6qp-tx6qp # Ka-Ro electronics TX6QP-8037 Module
+ - prt,prtwd3 # Protonic WD3 board
+ - wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board
+ - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board
- const: fsl,imx6qp
- description: i.MX6QP PHYTEC phyBOARD-Mira
@@ -189,32 +346,59 @@
- description: i.MX6DL based Boards
items:
- enum:
- - armadeus,imx6dl-apf6 # APF6 (Solo) SoM
- - armadeus,imx6dl-apf6dev # APF6 (Solo) SoM on APF6Dev board
+ - abb,aristainetos-imx6dl-4 # aristainetos i.MX6 Dual Lite Board 4
+ - abb,aristainetos-imx6dl-7 # aristainetos i.MX6 Dual Lite Board 7
+ - abb,aristainetos2-imx6dl-4 # aristainetos2 i.MX6 Dual Lite Board 4
+ - abb,aristainetos2-imx6dl-7 # aristainetos2 i.MX6 Dual Lite Board 7
+ - alt,alti6p # Altesco I6P Board
+ - boundary,imx6dl-nit6xlite # Boundary Devices Nitrogen6 Lite
+ - boundary,imx6dl-nitrogen6x # Boundary Devices Nitrogen6x
+ - bticino,imx6dl-mamoj # BTicino i.MX6DL Mamoj
- eckelmann,imx6dl-ci4x10
- emtrion,emcon-mx6 # emCON-MX6S or emCON-MX6DL SoM
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
+ - engicam,imx6-icore # Engicam i.CoreM6 Starter Kit
+ - engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
+ - fsl,imx6dl-sabrelite # i.MX6 DualLite SABRE Lite Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
+ - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules
- kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module
+ - poslab,imx6dl-savageboard # Poslab SavageBoard Dual
- prt,prtrvt # Protonic RVT board
- prt,prtvt7 # Protonic VT7 board
+ - rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board
+ - riot,imx6s-riotboard # RIoTboard i.MX6S
+ - solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite
+ - solidrun,hummingboard/dl
+ - solidrun,hummingboard2/dl # SolidRun HummingBoard2 Solo/DualLite
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
- technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- - toradex,colibri_imx6dl # Colibri iMX6 Module
- - toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1
- - toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3
- - toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6 Module V1.1 on Colibri Evaluation Board V3
+ - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board
+ - vdl,lanmcu # Van der Laan LANMCU board
+ - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board
- ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board
- ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board
- ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board
- ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board
- const: fsl,imx6dl
+ - description: i.MX6DL based Armadeus AFP6 Board
+ items:
+ - const: armadeus,imx6dl-apf6dev
+ - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM
+ - const: fsl,imx6dl
+
+ - description: i.MX6DL based DFI FS700-M60-6DL Board
+ items:
+ - const: dfi,fs700-m60-6dl
+ - const: dfi,fs700e-m60
+ - const: fsl,imx6dl
+
- description: i.MX6DL Gateworks Ventana Boards
items:
- enum:
@@ -250,12 +434,29 @@
- const: phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
- const: fsl,imx6dl
+ - description: i.MX6DL Toradex Colibri iMX6 Module on Colibri
+ Evaluation Board V3
+ items:
+ - const: toradex,colibri_imx6dl-eval-v3
+ - const: toradex,colibri_imx6dl # Colibri iMX6 Module
+ - const: fsl,imx6dl
+
+ - description: i.MX6DL Toradex Colibri iMX6 Module V1.1 on Colibri
+ Evaluation Board V3
+ items:
+ - const: toradex,colibri_imx6dl-v1_1-eval-v3
+ - const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1
+ - const: toradex,colibri_imx6dl-eval-v3
+ - const: toradex,colibri_imx6dl # Colibri iMX6 Module
+ - const: fsl,imx6dl
+
- description: i.MX6SL based Boards
items:
- enum:
- fsl,imx6sl-evk # i.MX6 SoloLite EVK Board
- kobo,tolino-shine2hd
- kobo,tolino-shine3
+ - revotics,imx6sl-warp # Revotics WaRP Board
- const: fsl,imx6sl
- description: i.MX6SLL based Boards
@@ -268,17 +469,23 @@
- description: i.MX6SX based Boards
items:
- enum:
+ - boundary,imx6sx-nitrogen6sx
- fsl,imx6sx-sabreauto # i.MX6 SoloX Sabre Auto Board
- fsl,imx6sx-sdb # i.MX6 SoloX SDB Board
- fsl,imx6sx-sdb-reva # i.MX6 SoloX SDB Rev-A Board
+ - samtec,imx6sx-vining-2000 # Softing VIN|ING 2000 Board
+ - udoo,neobasic # UDOO Neo Basic Board
+ - udoo,neoextended # UDOO Neo Extended
+ - udoo,neofull # UDOO Neo Full
- const: fsl,imx6sx
- description: i.MX6UL based Boards
items:
- enum:
- - armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM
- - armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board
+ - engicam,imx6ul-geam # Engicam GEAM6UL Starter Kit
+ - engicam,imx6ul-isiot # Engicam Is.IoT MX6UL eMMC/NAND Starter kit
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
+ - karo,imx6ul-tx6ul # Ka-Ro electronics TXUL-0010 Module
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- kontron,imx6ul-n6311-som # Kontron N6311 SOM
- technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf
@@ -286,6 +493,26 @@
- technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi
- const: fsl,imx6ul
+ - description: i.MX6UL Armadeus Systems OPOS6UL SoM Board
+ items:
+ - const: armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board
+ - const: armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM
+ - const: fsl,imx6ul
+
+ - description: i.MX6UL Digi International ConnectCore 6UL Boards
+ items:
+ - enum:
+ - digi,ccimx6ulsbcexpress # Digi International ConnectCore 6UL SBC Express
+ - digi,ccimx6ulsbcpro # Digi International ConnectCore 6UL SBC Pro
+ - const: digi,ccimx6ulsom
+ - const: fsl,imx6ul
+
+ - description: i.MX6UL Grinn liteBoard
+ items:
+ - const: grinn,imx6ul-liteboard
+ - const: grinn,imx6ul-litesom
+ - const: fsl,imx6ul
+
- description: i.MX6UL PHYTEC phyBOARD-Segin
items:
- enum:
@@ -317,8 +544,6 @@
- description: i.MX6ULL based Boards
items:
- enum:
- - armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
- - armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
- kontron,imx6ull-n6411-som # Kontron N6411 SOM
- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board
@@ -326,6 +551,12 @@
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board
- const: fsl,imx6ull
+ - description: i.MX6ULL Armadeus Systems OPOS6ULDev Board
+ items:
+ - const: armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
+ - const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
+ - const: fsl,imx6ull
+
- description: i.MX6ULL PHYTEC phyBOARD-Segin
items:
- enum:
@@ -351,17 +582,32 @@
- description: i.MX7S based Boards
items:
- enum:
- - toradex,colibri-imx7s # Colibri iMX7 Solo Module
- - toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board
- - toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3
- - tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM
+ - element14,imx7s-warp # Element14 Warp i.MX7 Board
+ - const: fsl,imx7s
+
+ - description: i.MX7S Boards with Toradex Colibri iMX7S Module
+ items:
+ - enum:
+ - toradex,colibri-imx7s-aster # Module on Aster Carrier Board
+ - toradex,colibri-imx7s-eval-v3 # Module on Colibri Evaluation Board V3
+ - const: toradex,colibri-imx7s
+ - const: fsl,imx7s
+
+ - description: TQ-Systems TQMa7S SoM on MBa7x board
+ items:
+ - const: tq,imx7s-mba7
+ - const: tq,imx7s-tqma7
- const: fsl,imx7s
- description: i.MX7D based Boards
items:
- enum:
+ - boundary,imx7d-nitrogen7
+ - compulab,cl-som-imx7 # CompuLab CL-SOM-iMX7
- fsl,imx7d-sdb # i.MX7 SabreSD Board
- fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board
+ - kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator
+ - kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf
- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
@@ -376,11 +622,16 @@
# Colibri Evaluation Board V3
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on
# Colibri Evaluation Board V3
- - tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
- zii,imx7d-rmu2 # ZII RMU2 Board
- zii,imx7d-rpu2 # ZII RPU2 Board
- const: fsl,imx7d
+ - description: TQ-Systems TQMa7D SoM on MBa7x board
+ items:
+ - const: tq,imx7d-mba7
+ - const: tq,imx7d-tqma7
+ - const: fsl,imx7d
+
- description:
Compulab SBC-iMX7 is a single board computer based on the
Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with
@@ -392,6 +643,22 @@
- const: compulab,cl-som-imx7
- const: fsl,imx7d
+ - description: i.MX7D Boards with Toradex Colibri i.MX7D Module
+ items:
+ - enum:
+ - toradex,colibri-imx7d-aster # Module on Aster Carrier Board
+ - toradex,colibri-imx7d-eval-v3 # Module on Colibri Evaluation Board V3
+ - const: toradex,colibri-imx7d
+ - const: fsl,imx7d
+
+ - description: i.MX7D Boards with Toradex Colibri i.MX7D eMMC Module
+ items:
+ - enum:
+ - toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board
+ - toradex,colibri-imx7d-emmc-eval-v3 # Module on Colibri Evaluation Board V3
+ - const: toradex,colibri-imx7d-emmc
+ - const: fsl,imx7d
+
- description: i.MX7ULP based Boards
items:
- enum:
@@ -405,9 +672,16 @@
- beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
- fsl,imx8mm-evk # i.MX8MM EVK Board
+ - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM
- variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module
- const: fsl,imx8mm
+ - description: Kontron BL i.MX8MM (N801X S) Board
+ items:
+ - const: kontron,imx8mm-n801x-s
+ - const: kontron,imx8mm-n801x-som
+ - const: fsl,imx8mm
+
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
@@ -491,10 +765,26 @@
- fsl,vf600
- fsl,vf610
- fsl,vf610m4
- - toradex,vf500-colibri_vf50 # Colibri VF50 Module
- - toradex,vf500-colibri_vf50-on-eval # Colibri VF50 Module on Colibri Evaluation Board
- - toradex,vf610-colibri_vf61 # Colibri VF61 Module
- - toradex,vf610-colibri_vf61-on-eval # Colibri VF61 Module on Colibri Evaluation Board
+
+ - description: Toradex Colibri VF50 Module on Colibri Evaluation Board
+ items:
+ - const: toradex,vf500-colibri_vf50-on-eval
+ - const: toradex,vf500-colibri_vf50
+ - const: fsl,vf500
+
+ - description: VF610 based Boards
+ items:
+ - enum:
+ - lwn,bk4 # Liebherr BK4 controller
+ - phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board
+ - fsl,vf610-twr # VF610 Tower Board
+ - const: fsl,vf610
+
+ - description: Toradex Colibri VF61 Module on Colibri Evaluation Board
+ items:
+ - const: toradex,vf610-colibri_vf61-on-eval
+ - const: toradex,vf610-colibri_vf61
+ - const: fsl,vf610
- description: ZII's VF610 based Boards
items:
@@ -515,6 +805,7 @@
- ebs-systart,oxalis
- fsl,ls1012a-rdb
- fsl,ls1012a-frdm
+ - fsl,ls1012a-frwy
- fsl,ls1012a-qds
- const: fsl,ls1012a
@@ -613,6 +904,15 @@
- enum:
- fsl,lx2160a-qds
- fsl,lx2160a-rdb
+ - fsl,lx2162a-qds
+ - const: fsl,lx2160a
+
+ - description: SolidRun LX2160A based Boards
+ items:
+ - enum:
+ - solidrun,clearfog-cx
+ - solidrun,honeycomb
+ - const: solidrun,lx2160a-cex7
- const: fsl,lx2160a
- description: S32V234 based Boards
diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/arm/idle-states.yaml
index ea805c1..52bce5d 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.yaml
+++ b/Documentation/devicetree/bindings/arm/idle-states.yaml
@@ -313,7 +313,7 @@
wakeup-latency-us by this duration.
idle-state-name:
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
description:
A string used as a descriptive name for the idle state.
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index f736e8c..53f0d4e 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -84,6 +84,10 @@
- enum:
- mediatek,mt8135-evbp1
- const: mediatek,mt8135
+ - items:
+ - enum:
+ - mediatek,mt8167-pumpkin
+ - const: mediatek,mt8167
- description: Google Elm (Acer Chromebook R13)
items:
- const: google,elm-rev8
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
index c3a8604..0a9889d 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
@@ -23,6 +23,7 @@
enum:
- qcom,sc7180-llcc
- qcom,sdm845-llcc
+ - qcom,sm8150-llcc
reg:
items:
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
new file mode 100644
index 0000000..599c659
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 thingy.jp.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: MStar/SigmaStar Armv7 SoC SMP control registers
+
+maintainers:
+ - Daniel Palmer <daniel@thingy.jp>
+
+description: |
+ MStar/SigmaStar's Armv7 SoCs that have more than one processor
+ have a region of registers that allow setting the boot address
+ and a magic number that allows secondary processors to leave
+ the loop they are parked in by the boot ROM.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - sstar,ssd201-smpctrl # SSD201/SSD202D
+ - const: mstar,smpctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ smpctrl@204000 {
+ compatible = "sstar,ssd201-smpctrl", "mstar,smpctrl";
+ reg = <0x204000 0x200>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
index 7c78740..61d08c4 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
@@ -20,6 +20,12 @@
- thingyjp,breadbee-crust # thingy.jp BreadBee Crust
- const: mstar,infinity
+ - description: infinity2m boards
+ items:
+ - enum:
+ - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit
+ - const: mstar,infinity2m
+
- description: infinity3 boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/picoxcell.txt b/Documentation/devicetree/bindings/arm/picoxcell.txt
deleted file mode 100644
index e75c0ef..0000000
--- a/Documentation/devicetree/bindings/arm/picoxcell.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Picochip picoXcell device tree bindings.
-========================================
-
-Required root node properties:
- - compatible:
- - "picochip,pc7302-pc3x3" : PC7302 development board with PC3X3 device.
- - "picochip,pc7302-pc3x2" : PC7302 development board with PC3X2 device.
- - "picochip,pc3x3" : picoXcell PC3X3 device based board.
- - "picochip,pc3x2" : picoXcell PC3X2 device based board.
-
-Timers required properties:
- - compatible = "picochip,pc3x2-timer"
- - interrupts : The single IRQ line for the timer.
- - clock-freq : The frequency in HZ of the timer.
- - reg : The register bank for the timer.
-
-Note: two timers are required - one for the scheduler clock and one for the
-event tick/NOHZ.
-
-VIC required properties:
- - compatible = "arm,pl192-vic".
- - interrupt-controller.
- - reg : The register bank for the device.
- - #interrupt-cells : Must be 1.
diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml
index ff94c45..fe11be6 100644
--- a/Documentation/devicetree/bindings/arm/renesas.yaml
+++ b/Documentation/devicetree/bindings/arm/renesas.yaml
@@ -245,6 +245,7 @@
- enum:
- renesas,r8a7795
- renesas,r8a7796
+ - renesas,r8a77961
- renesas,r8a77965
- description: R-Car M3-N (R8A77965)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index b621752..ef4544a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -70,6 +70,24 @@
- const: elgin,rv1108-r1
- const: rockchip,rv1108
+ - description: Engicam PX30.Core C.TOUCH 2.0
+ items:
+ - const: engicam,px30-core-ctouch2
+ - const: engicam,px30-core
+ - const: rockchip,px30
+
+ - description: Engicam PX30.Core C.TOUCH 2.0 10.1" Open Frame
+ items:
+ - const: engicam,px30-core-ctouch2-of10
+ - const: engicam,px30-core
+ - const: rockchip,px30
+
+ - description: Engicam PX30.Core EDIMM2.2 Starter Kit
+ items:
+ - const: engicam,px30-core-edimm2.2
+ - const: engicam,px30-core
+ - const: rockchip,px30
+
- description: Firefly Firefly-RK3288
items:
- enum:
@@ -381,6 +399,11 @@
- khadas,edge-v
- const: rockchip,rk3399
+ - description: Kobol Helios64
+ items:
+ - const: kobol,helios64
+ - const: rockchip,rk3399
+
- description: Mecer Xtreme Mini S6
items:
- const: mecer,xms6
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index 2725080..0796f0c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -14,6 +14,19 @@
const: '/'
compatible:
oneOf:
+ - description: S3C2416 based boards
+ items:
+ - enum:
+ - samsung,smdk2416 # Samsung SMDK2416
+ - const: samsung,s3c2416
+
+ - description: S3C6410 based boards
+ items:
+ - enum:
+ - friendlyarm,mini6410 # FriendlyARM Mini6410
+ - samsung,smdk6410 # Samsung SMDK6410
+ - const: samsung,s3c6410
+
- description: S5PV210 based boards
items:
- enum:
@@ -83,6 +96,14 @@
- const: samsung,exynos4412
- const: samsung,exynos4
+ - description: Samsung p4note family boards
+ items:
+ - enum:
+ - samsung,n8010 # Samsung GT-N8010/GT-N8013
+ - const: samsung,p4note
+ - const: samsung,exynos4412
+ - const: samsung,exynos4
+
- description: Exynos5250 based boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
index 6f1cd01..149afb5 100644
--- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
@@ -19,7 +19,12 @@
- st,stm32mp151-pwr-mcu
- st,stm32-syscfg
- st,stm32-power-config
+ - st,stm32-tamp
- const: syscon
+ - items:
+ - const: st,stm32-tamp
+ - const: syscon
+ - const: simple-mfd
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index 009b424..e7525a3 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -14,6 +14,20 @@
const: "/"
compatible:
oneOf:
+ - description: DH STM32MP1 SoM based Boards
+ items:
+ - enum:
+ - arrow,stm32mp157a-avenger96 # Avenger96
+ - dh,stm32mp153c-dhcom-drc02
+ - dh,stm32mp157c-dhcom-pdk2
+ - dh,stm32mp157c-dhcom-picoitx
+ - enum:
+ - dh,stm32mp153c-dhcom-som
+ - dh,stm32mp157a-dhcor-som
+ - dh,stm32mp157c-dhcom-som
+ - enum:
+ - st,stm32mp153
+ - st,stm32mp157
- items:
- enum:
- st,stm32f429i-disco
@@ -39,8 +53,6 @@
- const: st,stm32h743
- items:
- enum:
- - arrow,stm32mp157a-avenger96 # Avenger96
- - lxa,stm32mp157c-mc1
- shiratech,stm32mp157a-iot-box # IoT Box
- shiratech,stm32mp157a-stinger96 # Stinger96
- st,stm32mp157c-ed1
@@ -52,6 +64,13 @@
- const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
+ - description: Octavo OSD32MP15x System-in-Package based boards
+ items:
+ - enum:
+ - lxa,stm32mp157c-mc1 # Linux Automation MC-1
+ - const: oct,stm32mp15xx-osd32
+ - enum:
+ - st,stm32mp157
- description: Odyssey STM32MP1 SoM based Boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index cab8e1b..6db32fb 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -201,6 +201,19 @@
- const: dserve,dsrv9703c
- const: allwinner,sun4i-a10
+ - description: Elimo Engineering Impetus SoM
+ items:
+ - const: elimo,impetus
+ - const: sochip,s3
+ - const: allwinner,sun8i-v3
+
+ - description: Elimo Engineering Initium
+ items:
+ - const: elimo,initium
+ - const: elimo,impetus
+ - const: sochip,s3
+ - const: allwinner,sun8i-v3
+
- description: Empire Electronix D709 Tablet
items:
- const: empire-electronix,d709
@@ -251,6 +264,16 @@
- const: friendlyarm,nanopi-neo-plus2
- const: allwinner,sun50i-h5
+ - description: FriendlyARM NanoPi R1
+ items:
+ - const: friendlyarm,nanopi-r1
+ - const: allwinner,sun8i-h3
+
+ - description: FriendlyARM ZeroPi
+ items:
+ - const: friendlyarm,zeropi
+ - const: allwinner,sun8i-h3
+
- description: Gemei G9 Tablet
items:
- const: gemei,g9
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 767e863..c5fbf86 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -72,6 +72,9 @@
- const: asus,grouper
- const: nvidia,tegra30
- items:
+ - const: ouya,ouya
+ - const: nvidia,tegra30
+ - items:
- enum:
- nvidia,dalmore
- nvidia,roth
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
index ea670a5..897eedf 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
@@ -18,8 +18,30 @@
../../reset/reset.txt for details.
- reset-names: Must include the following entries:
- actmon
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+- interconnects: Should contain entries for memory clients sitting on
+ MC->EMC memory interconnect path.
+- interconnect-names: Should include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for
+ information about available memory clients, see MEMORY
+ CONTROLLER section.
+
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: bitfield indicating SoC speedo ID mask
+- opp-peak-kBps: peak bandwidth of the memory channel
Example:
+ dfs_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp@12750000 {
+ opp-hz = /bits/ 64 <12750000>;
+ opp-supported-hw = <0x000F>;
+ opp-peak-kBps = <51000>;
+ };
+ ...
+ };
+
actmon@6000c800 {
compatible = "nvidia,tegra124-actmon";
reg = <0x0 0x6000c800 0x0 0x400>;
@@ -29,4 +51,7 @@
clock-names = "actmon", "emc";
resets = <&tegra_car 119>;
reset-names = "actmon";
+ operating-points-v2 = <&dfs_opp_table>;
+ interconnects = <&mc TEGRA124_MC_MPCORER &emc>;
+ interconnect-names = "cpu";
};
diff --git a/Documentation/devicetree/bindings/arm/vt8500.yaml b/Documentation/devicetree/bindings/arm/vt8500.yaml
index 29ff399..7b762bf 100644
--- a/Documentation/devicetree/bindings/arm/vt8500.yaml
+++ b/Documentation/devicetree/bindings/arm/vt8500.yaml
@@ -21,6 +21,5 @@
- wm,wm8650
- wm,wm8750
- wm,wm8850
-
-additionalProperties: true
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml b/Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml
new file mode 100644
index 0000000..a1d55a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/modtronix,lcd2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Modtronix engineering LCD2S Character LCD Display
+
+maintainers:
+ - Lars Poeschel <poeschel@lemonage.de>
+
+description:
+ The LCD2S is a Character LCD Display manufactured by Modtronix Engineering.
+ The display supports a serial I2C and SPI interface. The driver currently
+ only supports the I2C interface.
+
+properties:
+ compatible:
+ const: modtronix,lcd2s
+
+ reg:
+ maxItems: 1
+ description:
+ I2C bus address of the display.
+
+ display-height-chars:
+ description: Height of the display, in character cells.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 4
+
+ display-width-chars:
+ description: Width of the display, in character cells.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 16
+ maximum: 20
+
+required:
+ - compatible
+ - reg
+ - display-height-chars
+ - display-width-chars
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lcd2s: auxdisplay@28 {
+ compatible = "modtronix,lcd2s";
+ reg = <0x28>;
+ display-height-chars = <4>;
+ display-width-chars = <20>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
index 0503651..863a287 100644
--- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
+++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
@@ -34,7 +34,7 @@
description:
The SRAM that needs to be claimed to access the display engine
bus.
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
ranges: true
diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml
index 0bee469..4ac78b4 100644
--- a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml
+++ b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml
@@ -46,7 +46,7 @@
const: 1
syscon:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description: Phandle to the Baikal-T1 System Controller DT node
interrupts:
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
deleted file mode 100644
index 3108d03..0000000
--- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-NVIDIA Tegra ACONNECT Bus
-
-The Tegra ACONNECT bus is an AXI switch which is used to connnect various
-components inside the Audio Processing Engine (APE). All CPU accesses to
-the APE subsystem go through the ACONNECT via an APB to AXI wrapper.
-
-Required properties:
-- compatible: Must be "nvidia,tegra210-aconnect".
-- clocks: Must contain the entries for the APE clock (TEGRA210_CLK_APE),
- and APE interface clock (TEGRA210_CLK_APB2APE).
-- clock-names: Must contain the names "ape" and "apb2ape" for the corresponding
- 'clocks' entries.
-- power-domains: Must contain a phandle that points to the audio powergate
- (namely 'aud') for Tegra210.
-- #address-cells: The number of cells used to represent physical base addresses
- in the aconnect address space. Should be 1.
-- #size-cells: The number of cells used to represent the size of an address
- range in the aconnect address space. Should be 1.
-- ranges: Mapping of the aconnect address space to the CPU address space.
-
-All devices accessed via the ACONNNECT are described by child-nodes.
-
-Example:
-
- aconnect@702c0000 {
- compatible = "nvidia,tegra210-aconnect";
- clocks = <&tegra_car TEGRA210_CLK_APE>,
- <&tegra_car TEGRA210_CLK_APB2APE>;
- clock-names = "ape", "apb2ape";
- power-domains = <&pd_audio>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x702c0000 0x0 0x702c0000 0x00040000>;
-
-
- child1 {
- ...
- };
-
- child2 {
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
new file mode 100644
index 0000000..7b1a08c
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/nvidia,tegra210-aconnect.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra ACONNECT Bus
+
+description: |
+ The Tegra ACONNECT bus is an AXI switch which is used to connnect various
+ components inside the Audio Processing Engine (APE). All CPU accesses to
+ the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All
+ devices accessed via the ACONNNECT are described by child-nodes.
+
+maintainers:
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra210-aconnect
+ - items:
+ - enum:
+ - nvidia,tegra186-aconnect
+ - nvidia,tegra194-aconnect
+ - const: nvidia,tegra210-aconnect
+
+ clocks:
+ items:
+ - description: Must contain the entry for APE clock
+ - description: Must contain the entry for APE interface clock
+
+ clock-names:
+ items:
+ - const: ape
+ - const: apb2ape
+
+ power-domains:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "@[0-9a-f]+$":
+ type: object
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include<dt-bindings/clock/tegra210-car.h>
+
+ aconnect@702c0000 {
+ compatible = "nvidia,tegra210-aconnect";
+ clocks = <&tegra_car TEGRA210_CLK_APE>,
+ <&tegra_car TEGRA210_CLK_APB2APE>;
+ clock-names = "ape", "apb2ape";
+ power-domains = <&pd_audio>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x702c0000 0x702c0000 0x00040000>;
+
+ // Child device nodes follow ...
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
new file mode 100644
index 0000000..0d06387
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.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/adi,axi-clkgen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binding for Analog Devices AXI clkgen pcore clock generator
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+ - Michael Hennerich <michael.hennerich@analog.com>
+
+description: |
+ The axi_clkgen IP core is a software programmable clock generator,
+ that can be synthesized on various FPGA platforms.
+
+ Link: https://wiki.analog.com/resources/fpga/docs/axi_clkgen
+
+properties:
+ compatible:
+ enum:
+ - adi,axi-clkgen-2.00.a
+
+ clocks:
+ description:
+ Specifies the reference clock(s) from which the output frequency is
+ derived. This must either reference one clock if only the first clock
+ input is connected or two if both clock inputs are connected.
+ minItems: 1
+ maxItems: 2
+
+ '#clock-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@ff000000 {
+ compatible = "adi,axi-clkgen-2.00.a";
+ #clock-cells = <0>;
+ reg = <0xff000000 0x1000>;
+ clocks = <&osc 1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
deleted file mode 100644
index aca94fe..0000000
--- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Binding for the axi-clkgen clock generator
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
-- #clock-cells : from common clock binding; Should always be set to 0.
-- reg : Address and length of the axi-clkgen register set.
-- clocks : Phandle and clock specifier for the parent clock(s). This must
- either reference one clock if only the first clock input is connected or two
- if both clock inputs are connected. For the later case the clock connected
- to the first input must be specified first.
-
-Optional properties:
-- clock-output-names : From common clock binding.
-
-Example:
- clock@ff000000 {
- compatible = "adi,axi-clkgen";
- #clock-cells = <0>;
- reg = <0xff000000 0x1000>;
- clocks = <&osc 1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml b/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml
new file mode 100644
index 0000000..565ca46
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/canaan,k210-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan Kendryte K210 Clock Device Tree Bindings
+
+maintainers:
+ - Damien Le Moal <damien.lemoal@wdc.com>
+
+description: |
+ Canaan Kendryte K210 SoC clocks driver bindings. The clock
+ controller node must be defined as a child node of the K210
+ system controller node.
+
+ See also:
+ - dt-bindings/clock/k210-clk.h
+
+properties:
+ compatible:
+ const: canaan,k210-clk
+
+ clocks:
+ description:
+ Phandle of the SoC 26MHz fixed-rate oscillator clock.
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#clock-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/k210-clk.h>
+ clocks {
+ in0: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+ };
+
+ /* ... */
+ sysclk: clock-controller {
+ #clock-cells = <1>;
+ compatible = "canaan,k210-clk";
+ clocks = <&in0>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/fsl,flexspi-clock.yaml b/Documentation/devicetree/bindings/clock/fsl,flexspi-clock.yaml
new file mode 100644
index 0000000..1fa390e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,flexspi-clock.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/fsl,flexspi-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale FlexSPI clock driver for Layerscape SoCs
+
+maintainers:
+ - Michael Walle <michael@walle.cc>
+
+description:
+ The Freescale Layerscape SoCs have a special FlexSPI clock which is
+ derived from the platform PLL.
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls1028a-flexspi-clk
+ - fsl,lx2160a-flexspi-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ dcfg {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ fspi_clk: clock-controller@900 {
+ compatible = "fsl,ls1028a-flexspi-clk";
+ reg = <0x900 0x4>;
+ #clock-cells = <0>;
+ clocks = <&parentclk>;
+ clock-output-names = "fspi_clk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.yaml b/Documentation/devicetree/bindings/clock/imx5-clock.yaml
index 4d9e7c7..90775c2 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.yaml
@@ -57,7 +57,7 @@
};
can@53fc8000 {
- compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
index 33f3010..940486e 100644
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -21,27 +21,58 @@
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See the full list of clock IDs from:
- include/dt-bindings/clock/imx8-clock.h
+ include/dt-bindings/clock/imx8-lpcg.h
properties:
compatible:
- enum:
- - fsl,imx8qxp-lpcg-adma
- - fsl,imx8qxp-lpcg-conn
- - fsl,imx8qxp-lpcg-dc
- - fsl,imx8qxp-lpcg-dsp
- - fsl,imx8qxp-lpcg-gpu
- - fsl,imx8qxp-lpcg-hsio
- - fsl,imx8qxp-lpcg-img
- - fsl,imx8qxp-lpcg-lsio
- - fsl,imx8qxp-lpcg-vpu
-
+ oneOf:
+ - const: fsl,imx8qxp-lpcg
+ - items:
+ - enum:
+ - fsl,imx8qm-lpcg
+ - const: fsl,imx8qxp-lpcg
+ - enum:
+ - fsl,imx8qxp-lpcg-adma
+ - fsl,imx8qxp-lpcg-conn
+ - fsl,imx8qxp-lpcg-dc
+ - fsl,imx8qxp-lpcg-dsp
+ - fsl,imx8qxp-lpcg-gpu
+ - fsl,imx8qxp-lpcg-hsio
+ - fsl,imx8qxp-lpcg-img
+ - fsl,imx8qxp-lpcg-lsio
+ - fsl,imx8qxp-lpcg-vpu
+ deprecated: true
reg:
maxItems: 1
'#clock-cells':
const: 1
+ clocks:
+ description: |
+ Input parent clocks phandle array for each clock
+ minItems: 1
+ maxItems: 8
+
+ clock-indices:
+ description: |
+ An integer array indicating the bit offset for each clock.
+ Refer to <include/dt-bindings/clock/imx8-lpcg.h> for the
+ supported LPCG clock indices.
+ minItems: 1
+ maxItems: 8
+
+ clock-output-names:
+ description: |
+ Shall be the corresponding names of the outputs.
+ NOTE this property must be specified in the same order
+ as the clock-indices property.
+ minItems: 1
+ maxItems: 8
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -51,23 +82,33 @@
examples:
- |
- #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/clock/imx8-lpcg.h>
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- clock-controller@5b200000 {
- compatible = "fsl,imx8qxp-lpcg-conn";
- reg = <0x5b200000 0xb0000>;
+ sdhc0_lpcg: clock-controller@5b200000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x5b200000 0x10000>;
#clock-cells = <1>;
+ clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>,
+ <&conn_ipg_clk>,
+ <&conn_axi_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>,
+ <IMX_LPCG_CLK_4>,
+ <IMX_LPCG_CLK_5>;
+ clock-output-names = "sdhc0_lpcg_per_clk",
+ "sdhc0_lpcg_ipg_clk",
+ "sdhc0_lpcg_ahb_clk";
+ power-domains = <&pd IMX_SC_R_SDHC_0>;
};
mmc@5b010000 {
compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
reg = <0x5b010000 0x10000>;
- clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
- <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>,
- <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>;
+ clocks = <&sdhc0_lpcg IMX_LPCG_CLK_4>,
+ <&sdhc0_lpcg IMX_LPCG_CLK_0>,
+ <&sdhc0_lpcg IMX_LPCG_CLK_5>;
clock-names = "ipg", "per", "ahb";
power-domains = <&pd IMX_SC_R_SDHC_0>;
};
diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
index 5dd7ea8..c65b945 100644
--- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
+++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
@@ -92,7 +92,7 @@
patternProperties:
"^usb-phy@[a-f0-9]+$":
- allOf: [ $ref: "../usb/ingenic,jz4770-phy.yaml#" ]
+ allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ]
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml
new file mode 100644
index 0000000..c40a74b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,aoncc-sm8250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for LPASS Always ON Clock Controller on SM8250 SoCs
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell.
+ See include/dt-bindings/clock/qcom,sm8250-lpass-aoncc.h for the full list
+ of Audio Clock controller clock IDs.
+
+properties:
+ compatible:
+ const: qcom,sm8250-lpass-aon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: Glitch Free Mux register clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8250-lpass-aoncc.h>
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ clock-controller@3800000 {
+ #clock-cells = <1>;
+ compatible = "qcom,sm8250-lpass-aon";
+ reg = <0x03380000 0x40000>;
+ clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "bus";
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml
new file mode 100644
index 0000000..915d762
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,audiocc-sm8250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock bindings for LPASS Audio Clock Controller on SM8250 SoCs
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell.
+ See include/dt-bindings/clock/qcom,sm8250-lpass-audiocc.h for the full list
+ of Audio Clock controller clock IDs.
+
+properties:
+ compatible:
+ const: qcom,sm8250-lpass-audiocc
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: Glitch Free Mux register clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8250-lpass-audiocc.h>
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ clock-controller@3300000 {
+ #clock-cells = <1>;
+ compatible = "qcom,sm8250-lpass-audiocc";
+ reg = <0x03300000 0x30000>;
+ clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "bus";
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
new file mode 100644
index 0000000..1121b39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx55.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller Binding for SDX55
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on SDX55
+
+ See also:
+ - dt-bindings/clock/qcom,gcc-sdx55.h
+
+properties:
+ compatible:
+ const: qcom,gcc-sdx55
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PLL test clock source (Optional clock)
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: sleep_clk
+ - const: core_bi_pll_test_se # Optional clock
+ minItems: 2
+ maxItems: 3
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ 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";
+ #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 a46a3a7..12c9cbc 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
@@ -19,8 +19,10 @@
enum:
- qcom,sc7180-rpmh-clk
- qcom,sdm845-rpmh-clk
+ - qcom,sdx55-rpmh-clk
- qcom,sm8150-rpmh-clk
- qcom,sm8250-rpmh-clk
+ - qcom,sm8350-rpmh-clk
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
new file mode 100644
index 0000000..f49027e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sc7180-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller Binding for SC7180
+
+maintainers:
+ - Taniya Das <tdas@codeaurora.org>
+
+description: |
+ Qualcomm camera clock control module which supports the clocks, resets and
+ power domains on SC7180.
+
+ See also:
+ - dt-bindings/clock/qcom,camcc-sc7180.h
+
+properties:
+ compatible:
+ const: qcom,sc7180-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Camera_ahb clock from GCC
+ - description: Camera XO clock from GCC
+
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: iface
+ - const: xo
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc7180.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@ad00000 {
+ compatible = "qcom,sc7180-camcc";
+ reg = <0x0ad00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_XO_CLK>;
+ clock-names = "bi_tcxo", "iface", "xo";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt
deleted file mode 100644
index da92f57..0000000
--- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-* Renesas R-Car USB 2.0 clock selector
-
-This file provides information on what the device node for the R-Car USB 2.0
-clock selector.
-
-If you connect an external clock to the USB_EXTAL pin only, you should set
-the clock rate to "usb_extal" node only.
-If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module
-is not needed because this is default setting. (Of course, you can set the
-clock rates to both "usb_extal" and "usb_xtal" nodes.
-
-Case 1: An external clock connects to R-Car SoC
- +----------+ +--- R-Car ---------------------+
- |External |---|USB_EXTAL ---> all usb channels|
- |clock | |USB_XTAL |
- +----------+ +-------------------------------+
-In this case, we need this driver with "usb_extal" clock.
-
-Case 2: An oscillator connects to R-Car SoC
- +----------+ +--- R-Car ---------------------+
- |Oscillator|---|USB_EXTAL -+-> all usb channels|
- | |---|USB_XTAL --+ |
- +----------+ +-------------------------------+
-In this case, we don't need this selector.
-
-Required properties:
-- compatible: "renesas,r8a7795-rcar-usb2-clock-sel" if the device is a part of
- an R8A7795 SoC.
- "renesas,r8a7796-rcar-usb2-clock-sel" if the device if a part of
- an R8A77960 SoC.
- "renesas,r8a77961-rcar-usb2-clock-sel" if the device if a part of
- an R8A77961 SoC.
- "renesas,rcar-gen3-usb2-clock-sel" for a generic R-Car Gen3
- compatible device.
-
- When compatible with the generic version, nodes must list the
- SoC-specific version corresponding to the platform first
- followed by the generic version.
-
-- reg: offset and length of the USB 2.0 clock selector register block.
-- clocks: A list of phandles and specifier pairs.
-- clock-names: Name of the clocks.
- - The functional clock of USB 2.0 host side must be "ehci_ohci"
- - The functional clock of HS-USB side must be "hs-usb-if"
- - The USB_EXTAL clock pin must be "usb_extal"
- - The USB_XTAL clock pin must be "usb_xtal"
-- #clock-cells: Must be 0
-- power-domains: A phandle and symbolic PM domain specifier.
- See power/renesas,rcar-sysc.yaml.
-- resets: A list of phandles and specifier pairs.
-- reset-names: Name of the resets.
- - The reset of USB 2.0 host side must be "ehci_ohci"
- - The reset of HS-USB side must be "hs-usb-if"
-
-Example (R-Car H3):
-
- usb2_clksel: clock-controller@e6590630 {
- compatible = "renesas,r8a7795-rcar-usb2-clock-sel",
- "renesas,rcar-gen3-usb2-clock-sel";
- reg = <0 0xe6590630 0 0x02>;
- clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
- <&usb_extal>, <&usb_xtal>;
- clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal";
- #clock-cells = <0>;
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
- resets = <&cpg 703>, <&cpg 704>;
- reset-names = "ehci_ohci", "hs-usb-if";
- };
diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
new file mode 100644
index 0000000..5be1229
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Renesas R-Car USB 2.0 clock selector
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+description: |
+ If you connect an external clock to the USB_EXTAL pin only, you should set
+ the clock rate to "usb_extal" node only.
+ If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module
+ is not needed because this is default setting. (Of course, you can set the
+ clock rates to both "usb_extal" and "usb_xtal" nodes.
+
+ Case 1: An external clock connects to R-Car SoC
+ +----------+ +--- R-Car ---------------------+
+ |External |---|USB_EXTAL ---> all usb channels|
+ |clock | |USB_XTAL |
+ +----------+ +-------------------------------+
+
+ In this case, we need this driver with "usb_extal" clock.
+
+ Case 2: An oscillator connects to R-Car SoC
+ +----------+ +--- R-Car ---------------------+
+ |Oscillator|---|USB_EXTAL -+-> all usb channels|
+ | |---|USB_XTAL --+ |
+ +----------+ +-------------------------------+
+ In this case, we don't need this selector.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a7795-rcar-usb2-clock-sel # R-Car H3
+ - renesas,r8a7796-rcar-usb2-clock-sel # R-Car M3-W
+ - renesas,r8a77961-rcar-usb2-clock-sel # R-Car M3-W+
+ - const: renesas,rcar-gen3-usb2-clock-sel
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: ehci_ohci
+ - const: hs-usb-if
+ - const: usb_extal
+ - const: usb_xtal
+
+ '#clock-cells':
+ const: 0
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: ehci_ohci
+ - const: hs-usb-if
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - power-domains
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
+ #include <dt-bindings/power/r8a7795-sysc.h>
+
+ usb2_clksel: clock-controller@e6590630 {
+ compatible = "renesas,r8a7795-rcar-usb2-clock-sel",
+ "renesas,rcar-gen3-usb2-clock-sel";
+ reg = <0xe6590630 0x02>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
+ <&usb_extal>, <&usb_xtal>;
+ clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal";
+ #clock-cells = <0>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 703>, <&cpg 704>;
+ reset-names = "ehci_ohci", "hs-usb-if";
+ };
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml b/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml
new file mode 100644
index 0000000..e17143c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sifive/fu740-prci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive FU740 Power Reset Clock Interrupt Controller (PRCI)
+
+maintainers:
+ - Zong Li <zong.li@sifive.com>
+ - Paul Walmsley <paul.walmsley@sifive.com>
+
+description:
+ On the FU740 family of SoCs, most system-wide clock and reset integration
+ is via the PRCI IP block.
+ The clock consumer should specify the desired clock via the clock ID
+ macros defined in include/dt-bindings/clock/sifive-fu740-prci.h.
+ These macros begin with PRCI_CLK_.
+
+ The hfclk and rtcclk nodes are required, and represent physical
+ crystals or resonators located on the PCB. These nodes should be present
+ underneath /, rather than /soc.
+
+properties:
+ compatible:
+ const: sifive,fu740-c000-prci
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: high frequency clock.
+ - description: RTL clock.
+
+ clock-names:
+ items:
+ - const: hfclk
+ - const: rtcclk
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ prci: clock-controller@10000000 {
+ compatible = "sifive,fu740-c000-prci";
+ reg = <0x10000000 0x1000>;
+ clocks = <&hfclk>, <&rtcclk>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 728f82d..4286ed7 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -37,7 +37,7 @@
description: Size of the connector, should be specified in case of
non-fullsize 'usb-a-connector' or 'usb-b-connector' compatible
connectors.
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- mini
@@ -67,7 +67,7 @@
power-role:
description: Determines the power role that the Type C connector will
support. "dual" refers to Dual Role Port (DRP).
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- source
@@ -76,7 +76,7 @@
try-power-role:
description: Preferred power role.
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- source
@@ -86,13 +86,31 @@
data-role:
description: Data role if Type C connector supports USB data. "dual" refers
Dual Role Device (DRD).
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- host
- device
- dual
+ typec-power-opmode:
+ description: Determines the power operation mode that the Type C connector
+ will support and will advertise through CC pins when it has no power
+ delivery support.
+ - "default" corresponds to default USB voltage and current defined by the
+ USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
+ 5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
+ operation respectively.
+ - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB
+ Type-C Cable and Connector specification, when Power Delivery is not
+ supported.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - default
+ - 1.5A
+ - 3.0A
+
# The following are optional properties for "usb-c-connector" with power
# delivery support.
source-pdos:
@@ -147,6 +165,25 @@
required:
- port@0
+ new-source-frs-typec-current:
+ description: Initial current capability of the new source when vSafe5V
+ is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO - Sink"
+ of "USB Power Delivery Specification Revision 3.0, Version 1.2" provides the
+ different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C Current"
+ provides a detailed description of the field. The sink PDO from current source
+ reflects the current source's(i.e. transmitter of the FRS signal) power
+ requirement during fr swap. The current sink (i.e. receiver of the FRS signal),
+ a.k.a new source, should check if it will be able to satisfy the current source's,
+ new sink's, requirement during frswap before enabling the frs signal reception.
+ This property refers to maximum current capability that the current sink can
+ satisfy. During FRS, VBUS voltage is at 5V, as the partners are in implicit
+ contract, hence, the power level is only a function of the current capability.
+ "1" refers to default USB power level as described by "Table 6-14 Fixed Supply PDO - Sink".
+ "2" refers to 1.5A@5V.
+ "3" refers to 3.0A@5V.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3]
+
required:
- compatible
@@ -173,6 +210,12 @@
type:
const: micro
+anyOf:
+ - not:
+ required:
+ - typec-power-opmode
+ - new-source-frs-typec-current
+
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
new file mode 100644
index 0000000..ee2c099
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/intel,keembay-ocs-aes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Keem Bay OCS AES Device Tree Bindings
+
+maintainers:
+ - Daniele Alessandrelli <daniele.alessandrelli@intel.com>
+
+description:
+ The Intel Keem Bay Offload and Crypto Subsystem (OCS) AES engine provides
+ hardware-accelerated AES/SM4 encryption/decryption.
+
+properties:
+ compatible:
+ const: intel,keembay-ocs-aes
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ crypto@30008000 {
+ compatible = "intel,keembay-ocs-aes";
+ reg = <0x30008000 0x1000>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk 95>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/picochip-spacc.txt b/Documentation/devicetree/bindings/crypto/picochip-spacc.txt
deleted file mode 100644
index df1151f..0000000
--- a/Documentation/devicetree/bindings/crypto/picochip-spacc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Picochip picoXcell SPAcc (Security Protocol Accelerator) bindings
-
-Picochip picoXcell devices contain crypto offload engines that may be used for
-IPSEC and femtocell layer 2 ciphering.
-
-Required properties:
- - compatible : "picochip,spacc-ipsec" for the IPSEC offload engine
- "picochip,spacc-l2" for the femtocell layer 2 ciphering engine.
- - reg : Offset and length of the register set for this device
- - interrupts : The interrupt line from the SPAcc.
- - ref-clock : The input clock that drives the SPAcc.
-
-Example SPAcc node:
-
-spacc@10000 {
- compatible = "picochip,spacc-ipsec";
- reg = <0x100000 0x10000>;
- interrupt-parent = <&vic0>;
- interrupts = <24>;
- ref-clock = <&ipsec_clk>, "ref";
-};
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index e71f752..bcaa2c0 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -51,6 +51,19 @@
- exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
+Optional properties for the interconnect functionality (QoS frequency
+constraints):
+- #interconnect-cells: should be 0.
+- interconnects: as documented in ../interconnect.txt, describes a path at the
+ higher level interconnects used by this interconnect provider.
+ If this interconnect provider is directly linked to a top level interconnect
+ provider the property contains only one phandle. The provider extends
+ the interconnect graph by linking its node to a node registered by provider
+ pointed to by first phandle in the 'interconnects' property.
+
+- samsung,data-clock-ratio: ratio of the data throughput in B/s to minimum data
+ clock frequency in Hz, default value is 8 when this property is missing.
+
Detailed correlation between sub-blocks and power line according to Exynos SoC:
- In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC
@@ -135,7 +148,7 @@
|--- PERIC (Fixed clock rate)
|--- FSYS (Fixed clock rate)
-Example1:
+Example 1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regulator.
@@ -184,7 +197,7 @@
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
-Example2 :
+Example 2:
The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
is listed below:
@@ -419,3 +432,57 @@
devfreq = <&bus_leftbus>;
status = "okay";
};
+
+Example 3:
+ An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on
+ Exynos4412 SoC with video mixer as an interconnect consumer device.
+
+ soc {
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ samsung,data-clock-ratio = <4>;
+ #interconnect-cells = <0>;
+ };
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ #interconnect-cells = <0>;
+ interconnects = <&bus_dmc>;
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_display_opp_table>;
+ #interconnect-cells = <0>;
+ interconnects = <&bus_leftbus &bus_dmc>;
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ /* ... */
+ }
+
+ bus_leftbus_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ /* ... */
+ };
+
+ bus_display_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+ /* .. */
+ };
+
+ &mixer {
+ compatible = "samsung,exynos4212-mixer";
+ interconnects = <&bus_display &bus_dmc>;
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 03a7672..7ce06f9 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -76,6 +76,12 @@
resets:
maxItems: 1
+ wifi-2.4ghz-coexistence:
+ type: boolean
+ description: >
+ Should the pixel frequencies in the WiFi frequencies range be
+ avoided?
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 0000000..9392b55
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji <xji@analogixsemi.com>
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ compatible:
+ items:
+ - const: analogix,anx7625
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: used for interrupt pin B8.
+ maxItems: 1
+
+ enable-gpios:
+ description: used for power on chip control, POWER_EN pin D2.
+ maxItems: 1
+
+ reset-gpios:
+ description: used for reset chip control, RESET_N pin B7.
+ maxItems: 1
+
+ ports:
+ type: object
+
+ properties:
+ port@0:
+ type: object
+ description:
+ Video port for MIPI DSI input.
+
+ port@1:
+ type: object
+ description:
+ Video port for panel or connector.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ encoder@58 {
+ compatible = "analogix,anx7625";
+ reg = <0x58>;
+ enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi2dp_bridge_in: port@0 {
+ reg = <0>;
+ anx7625_in: endpoint {
+ remote-endpoint = <&mipi_dsi>;
+ };
+ };
+
+ mipi2dp_bridge_out: port@1 {
+ reg = <1>;
+ anx7625_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
index 8c0e4f28..fccd635 100644
--- a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
@@ -26,11 +26,9 @@
description: GPIO connected to active low reset
dvdd12-supply:
- maxItems: 1
description: Regulator for 1.2V digital core power.
dvdd25-supply:
- maxItems: 1
description: Regulator for 2.5V digital core power.
ports:
diff --git a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
new file mode 100644
index 0000000..35c9dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/intel,keembay-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay mipi dsi controller
+
+maintainers:
+ - Anitha Chrisanthus <anitha.chrisanthus@intel.com>
+ - Edmond J Dea <edmund.j.dea@intel.com>
+
+properties:
+ compatible:
+ const: intel,keembay-dsi
+
+ reg:
+ items:
+ - description: MIPI registers range
+
+ reg-names:
+ items:
+ - const: mipi
+
+ clocks:
+ items:
+ - description: MIPI DSI clock
+ - description: MIPI DSI econfig clock
+ - description: MIPI DSI config clock
+
+ clock-names:
+ items:
+ - const: clk_mipi
+ - const: clk_mipi_ecfg
+ - const: clk_mipi_cfg
+
+ ports:
+ type: object
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+ type: object
+ description: MIPI DSI input port.
+
+ port@1:
+ type: object
+ description: DSI output port.
+
+ required:
+ - port@0
+ - port@1
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ mipi-dsi@20900000 {
+ compatible = "intel,keembay-dsi";
+ reg = <0x20900000 0x4000>;
+ reg-names = "mipi";
+ clocks = <&scmi_clk 0x86>,
+ <&scmi_clk 0x88>,
+ <&scmi_clk 0x89>;
+ clock-names = "clk_mipi", "clk_mipi_ecfg",
+ "clk_mipi_cfg";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi_in: endpoint {
+ remote-endpoint = <&disp_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi_out: endpoint {
+ remote-endpoint = <&adv7535_input>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
index efbb3d0..02cfc0a 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -35,11 +35,9 @@
maxItems: 1
ovdd-supply:
- maxItems: 1
description: I/O voltage
pwr18-supply:
- maxItems: 1
description: core voltage
interrupts:
diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
index d602083..7a1c89b 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -4,18 +4,19 @@
$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Lontium LT9611 2 Port MIPI to HDMI Bridge
+title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
maintainers:
- Vinod Koul <vkoul@kernel.org>
description: |
- The LT9611 is a bridge device which converts DSI to HDMI
+ The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
properties:
compatible:
enum:
- lontium,lt9611
+ - lontium,lt9611uxc
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index e5e3c72..66a14d6 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -79,8 +79,7 @@
The GPIO used to control the power down line of this device.
maxItems: 1
- power-supply:
- maxItems: 1
+ power-supply: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
index 7e27cfc..763c790 100644
--- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -35,11 +35,9 @@
description: GPIO connected to active low reset.
vdd12-supply:
- maxItems: 1
description: Regulator for 1.2V digital core power.
vdd33-supply:
- maxItems: 1
description: Regulator for 3.3V digital core power.
ports:
diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
index 0d1db3f..02c21b5 100644
--- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
@@ -8,6 +8,8 @@
- interrupts: describe the interrupt line used to inform the host
about hotplug events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
+ - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V)
+ - cvcc12-supply: Digital Core Supply Voltage (1.2V)
HDMI audio properties:
- #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin
@@ -54,6 +56,8 @@
compatible = "sil,sii9022";
reg = <0x39>;
reset-gpios = <&pioA 1 0>;
+ iovcc-supply = <&v3v3_hdmi>;
+ cvcc12-supply = <&v1v2_hdmi>;
#sound-dai-cells = <0>;
sil,i2s-data-lanes = < 0 1 2 >;
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index 3ddb35f..64e8a1c 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -60,7 +60,6 @@
description: GPIO controlling bridge enable
vdd-supply:
- maxItems: 1
description: Power supply for the bridge
required:
diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
index 469ac4a..3d5ce08 100644
--- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
@@ -74,7 +74,6 @@
description: Power down GPIO signal, pin name "/PDWN", active low.
vcc-supply:
- maxItems: 1
description:
Power supply for the TTL output, TTL CLOCKOUT signal, LVDS input, PLL and
digital circuitry.
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
index fd3113a..b5959cc 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
@@ -28,11 +28,9 @@
description: i2c address of the bridge, 0x0f
vdd-supply:
- maxItems: 1
description: 1.2V LVDS Power Supply
vddio-supply:
- maxItems: 1
description: 1.8V IO Power Supply
stby-gpios:
diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
index 5a99490..3c35338 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
@@ -12,7 +12,7 @@
example:
display-subsystem {
- compatible = "fsl,display-subsystem";
+ compatible = "fsl,imx-display-subsystem";
ports = <&ipu_di0>;
};
diff --git a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
new file mode 100644
index 0000000..0a697d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay display controller
+
+maintainers:
+ - Anitha Chrisanthus <anitha.chrisanthus@intel.com>
+ - Edmond J Dea <edmund.j.dea@intel.com>
+
+properties:
+ compatible:
+ const: intel,keembay-display
+
+ reg:
+ items:
+ - description: LCD registers range
+
+ reg-names:
+ items:
+ - const: lcd
+
+ clocks:
+ items:
+ - description: LCD controller clock
+ - description: pll0 clock
+
+ clock-names:
+ items:
+ - const: clk_lcd
+ - const: clk_pll0
+
+ interrupts:
+ maxItems: 1
+
+ port:
+ type: object
+ description: Display output node to DSI.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ display@20930000 {
+ compatible = "intel,keembay-display";
+ reg = <0x20930000 0x3000>;
+ reg-names = "lcd";
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk 0x83>,
+ <&scmi_clk 0x0>;
+ clock-names = "clk_lcd", "clk_pll0";
+
+ port {
+ disp_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
new file mode 100644
index 0000000..a222b52
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/intel,keembay-msscam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devicetree bindings for Intel Keem Bay MSSCAM
+
+maintainers:
+ - Anitha Chrisanthus <anitha.chrisanthus@intel.com>
+ - Edmond J Dea <edmund.j.dea@intel.com>
+
+description: |
+ MSSCAM controls local clocks in the display subsystem namely LCD clocks and
+ MIPI DSI clocks. It also configures the interconnect between LCD and
+ MIPI DSI.
+
+properties:
+ compatible:
+ items:
+ - const: intel,keembay-msscam
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ reg-io-width:
+ const: 4
+
+required:
+ - compatible
+ - reg
+ - reg-io-width
+
+additionalProperties: false
+
+examples:
+ - |
+ msscam:msscam@20910000 {
+ compatible = "intel,keembay-msscam", "syscon";
+ reg = <0x20910000 0x30>;
+ reg-io-width = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 1212207..33977e1 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -43,7 +43,7 @@
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
"mediatek,<chip>-disp-mutex" - display mutex
"mediatek,<chip>-disp-od" - overdrive
- the supported chips are mt2701, mt7623, mt2712 and mt8173.
+ the supported chips are mt2701, mt7623, mt2712, mt8167 and mt8173.
- reg: Physical base address and length of the function block register space
- interrupts: The interrupt signal from the function block (required, except for
merge and split function blocks).
@@ -59,7 +59,7 @@
"mediatek,<chip>-disp-ovl"
"mediatek,<chip>-disp-rdma"
"mediatek,<chip>-disp-wdma"
- the supported chips are mt2701 and mt8173.
+ the supported chips are mt2701, mt8167 and mt8173.
- larb: Should contain a phandle pointing to the local arbiter device as defined
in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
- iommus: Should point to the respective IOMMU block with master port as
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
deleted file mode 100644
index dc1ebd13..0000000
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Mediatek DPI Device
-===================
-
-The Mediatek DPI function block is a sink of the display subsystem and
-provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
-output bus.
-
-Required properties:
-- compatible: "mediatek,<chip>-dpi"
- the supported chips are mt2701, mt7623, mt8173 and mt8183.
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "engine", and "pll"
-- port: Output port node with endpoint definitions as described in
- Documentation/devicetree/bindings/graph.txt. This port should be connected
- to the input port of an attached HDMI or LVDS encoder chip.
-
-Optional properties:
-- pinctrl-names: Contain "default" and "sleep".
-
-Example:
-
-dpi0: dpi@1401d000 {
- compatible = "mediatek,mt8173-dpi";
- reg = <0 0x1401d000 0 0x1000>;
- interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&mmsys CLK_MM_DPI_PIXEL>,
- <&mmsys CLK_MM_DPI_ENGINE>,
- <&apmixedsys CLK_APMIXED_TVDPLL>;
- clock-names = "pixel", "engine", "pll";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&dpi_pin_func>;
- pinctrl-1 = <&dpi_pin_idle>;
-
- port {
- dpi0_out: endpoint {
- remote-endpoint = <&hdmi0_in>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
new file mode 100644
index 0000000..6cdb734
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: mediatek DPI Controller Device Tree Bindings
+
+maintainers:
+ - CK Hu <ck.hu@mediatek.com>
+ - Jitao shi <jitao.shi@mediatek.com>
+
+description: |
+ The Mediatek DPI function block is a sink of the display subsystem and
+ provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
+ output bus.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-dpi
+ - mediatek,mt7623-dpi
+ - mediatek,mt8173-dpi
+ - mediatek,mt8183-dpi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Pixel Clock
+ - description: Engine Clock
+ - description: DPI PLL
+
+ clock-names:
+ items:
+ - const: pixel
+ - const: engine
+ - const: pll
+
+ pinctrl-0: true
+ pinctrl-1: true
+
+ pinctrl-names:
+ items:
+ - const: default
+ - const: sleep
+
+ port:
+ type: object
+ description:
+ Output port node with endpoint definitions as described in
+ Documentation/devicetree/bindings/graph.txt. This port should be connected
+ to the input port of an attached HDMI or LVDS encoder chip.
+
+ properties:
+ endpoint:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ dpi0: dpi@1401d000 {
+ compatible = "mediatek,mt8173-dpi";
+ reg = <0x1401d000 0x1000>;
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&mmsys CLK_MM_DPI_PIXEL>,
+ <&mmsys CLK_MM_DPI_ENGINE>,
+ <&apmixedsys CLK_APMIXED_TVDPLL>;
+ clock-names = "pixel", "engine", "pll";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&dpi_pin_func>;
+ pinctrl-1 = <&dpi_pin_idle>;
+
+ port {
+ dpi0_out: endpoint {
+ remote-endpoint = <&hdmi0_in>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 1af0ff1..090dcb3 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -39,6 +39,10 @@
a4xx Snapdragon SoCs. See
Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
+Optional properties:
+- #cooling-cells: The value must be 2. For details, please refer
+ Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
+
Example 3xx/4xx:
/ {
@@ -61,6 +65,7 @@
power-domains = <&mmcc OXILICX_GDSC>;
operating-points-v2 = <&gpu_opp_table>;
iommus = <&gpu_iommu 0>;
+ #cooling-cells = <2>;
};
gpu_sram: ocmem@fdd00000 {
@@ -98,6 +103,8 @@
reg = <0x5000000 0x40000>, <0x509e000 0x10>;
reg-names = "kgsl_3d0_reg_memory", "cx_mem";
+ #cooling-cells = <2>;
+
/*
* Look ma, no clocks! The GPU clocks and power are
* controlled entirely by the GMU
diff --git a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
new file mode 100644
index 0000000..a108029
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/abt,y030xx067a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD panel
+
+description: |
+ The panel must obey the rules for a SPI slave device as specified in
+ spi/spi-controller.yaml
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: abt,y030xx067a
+
+ backlight: true
+ port: true
+ power-supply: true
+ reg: true
+ reset-gpios: true
+
+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 = "abt,y030xx067a";
+ 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/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
new file mode 100644
index 0000000..2f5df1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672A based DSI display Panels
+
+maintainers:
+ - Sumit Semwal <sumit.semwal@linaro.org>
+
+description: |
+ The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
+ panels.
+ Right now, support is added only for a Tianma FHD+ LCD display panel with a
+ resolution of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - tianma,fhd-video
+ - const: novatek,nt36672a
+ description: This indicates the panel manufacturer of the panel that is
+ in turn using the NT36672A panel driver. This compatible string
+ determines how the NT36672A panel driver is configured for the indicated
+ panel. The novatek,nt36672a compatible shall always be provided as a fallback.
+
+ reset-gpios:
+ description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+ description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+ description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+ description: phandle of the negative boost supply regulator
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "tianma,fhd-video", "novatek,nt36672a";
+ reg = <0>;
+ vddi0-supply = <&vreg_l14a_1p88>;
+ vddpos-supply = <&lab>;
+ vddneg-supply = <&ibb>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index c0dd9fa..72e4b6d 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -47,6 +47,12 @@
- panasonic,vvx10f004b00
# Panasonic 10" WUXGA TFT LCD panel
- panasonic,vvx10f034n00
+ # Samsung s6e3fc2x01 1080x2340 AMOLED panel
+ - samsung,s6e3fc2x01
+ # Samsung sofef00 1080x2280 AMOLED panel
+ - samsung,sofef00
+ # Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel
+ - tdo,tl070wsh30
reg:
maxItems: 1
@@ -54,6 +60,7 @@
backlight: true
enable-gpios: true
+ reset-gpios: true
port: true
power-supply: true
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index edb53ab..27fffaf 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -159,6 +159,8 @@
- innolux,g121x1-l03
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bge
+ # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
+ - innolux,n125hce-gn1
# InnoLux 15.6" WXGA TFT LCD panel
- innolux,n156bge-l21
# Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
@@ -282,6 +284,8 @@
- vxt,vl050-8048nt-c01
# Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
- winstar,wf35ltiacd
+ # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
+ - yes-optoelectronics,ytc700tlag-05-201c
backlight: true
enable-gpios: true
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index ac63ae4a..34d9933 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -20,6 +20,10 @@
- reset-names: Must include the following entries:
- host1x
+Each host1x client module having to perform DMA through the Memory Controller
+should have the interconnect endpoints set to the Memory Client and External
+Memory respectively.
+
The host1x top-level node defines a number of children, each representing one
of the following host1x client modules:
@@ -36,6 +40,12 @@
- reset-names: Must include the following entries:
- mpe
+ Optional properties:
+ - interconnects: Must contain entry for the MPE memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
- vi: video input
Required properties:
@@ -113,6 +123,12 @@
Required properties:
- remote-endpoint: phandle to vi port 'endpoint' node.
+ Optional properties:
+ - interconnects: Must contain entry for the VI memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
- epp: encoder pre-processor
Required properties:
@@ -126,6 +142,12 @@
- reset-names: Must include the following entries:
- epp
+ Optional properties:
+ - interconnects: Must contain entry for the EPP memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
- isp: image signal processor
Required properties:
@@ -139,6 +161,12 @@
- reset-names: Must include the following entries:
- isp
+ Optional properties:
+ - interconnects: Must contain entry for the ISP memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
- gr2d: 2D graphics engine
Required properties:
@@ -152,6 +180,12 @@
- reset-names: Must include the following entries:
- 2d
+ Optional properties:
+ - interconnects: Must contain entry for the GR2D memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
- gr3d: 3D graphics engine
Required properties:
@@ -170,6 +204,12 @@
- 3d
- 3d2 (Only required on SoCs with two 3D clocks)
+ Optional properties:
+ - interconnects: Must contain entry for the GR3D memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
- dc: display controller
Required properties:
@@ -197,6 +237,10 @@
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
+ - interconnects: Must contain entry for the DC memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
- hdmi: High Definition Multimedia Interface
@@ -345,6 +389,12 @@
- reset-names: Must include the following entries:
- vic
+ Optional properties:
+ - interconnects: Must contain entry for the VIC memory clients.
+ - interconnect-names: Must include name of the interconnect path for each
+ interconnect entry. Consult TRM documentation for information about
+ available memory clients, see MEMORY CONTROLLER section.
+
Example:
/ {
@@ -498,6 +548,15 @@
resets = <&tegra_car 27>;
reset-names = "dc";
+ interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
+ <&mc TEGRA20_MC_DISPLAY0B &emc>,
+ <&mc TEGRA20_MC_DISPLAY0C &emc>,
+ <&mc TEGRA20_MC_DISPLAYHC &emc>;
+ interconnect-names = "wina",
+ "winb",
+ "winc",
+ "cursor";
+
rgb {
status = "disabled";
};
@@ -513,6 +572,15 @@
resets = <&tegra_car 26>;
reset-names = "dc";
+ interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>,
+ <&mc TEGRA20_MC_DISPLAY0BB &emc>,
+ <&mc TEGRA20_MC_DISPLAY0CB &emc>,
+ <&mc TEGRA20_MC_DISPLAYHCB &emc>;
+ interconnect-names = "wina",
+ "winb",
+ "winc",
+ "cursor";
+
rgb {
status = "disabled";
};
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 4f91854..4dc3073 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -55,6 +55,14 @@
- const: vp1
- const: vp2
+ assigned-clocks:
+ minItems: 1
+ maxItems: 3
+
+ assigned-clock-parents:
+ minItems: 1
+ maxItems: 3
+
interrupts:
maxItems: 1
@@ -62,6 +70,9 @@
maxItems: 1
description: phandle to the associated power domain
+ dma-coherent:
+ type: boolean
+
ports:
type: object
description:
diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
index 173730d5..c9a947d 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
@@ -77,6 +77,14 @@
- const: vp3
- const: vp4
+ assigned-clocks:
+ minItems: 1
+ maxItems: 5
+
+ assigned-clock-parents:
+ minItems: 1
+ maxItems: 5
+
interrupts:
items:
- description: common_m DSS Master common
@@ -95,6 +103,9 @@
maxItems: 1
description: phandle to the associated power domain
+ dma-coherent:
+ type: boolean
+
ports:
type: object
description:
diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
index 7b9d468..403d579 100644
--- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
@@ -98,7 +98,6 @@
maxItems: 1
dmas:
- maxItems: 4
items:
- description: Video layer, plane 0 (RGB or luma)
- description: Video layer, plane 1 (U/V or U)
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
index 372679d..b6e1ebf 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
@@ -21,6 +21,7 @@
compatible:
oneOf:
- const: allwinner,sun50i-a64-dma
+ - const: allwinner,sun50i-a100-dma
- const: allwinner,sun50i-h6-dma
- items:
- const: allwinner,sun8i-r40-dma
@@ -56,7 +57,9 @@
if:
properties:
compatible:
- const: allwinner,sun50i-h6-dma
+ enum:
+ - allwinner,sun50i-a100-dma
+ - allwinner,sun50i-h6-dma
then:
properties:
diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
index 4dc398e..510b7f2 100644
--- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
@@ -2,7 +2,8 @@
* XDMA Controller
Required properties:
-- compatible: Should be "atmel,sama5d4-dma" or "microchip,sam9x60-dma".
+- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or
+ "microchip,sama7g5-dma".
- reg: Should contain DMA registers location and length.
- interrupts: Should contain DMA interrupt.
- #dma-cells: Must be <1>, used to represent the number of integer cells in
diff --git a/Documentation/devicetree/bindings/dma/dma-common.yaml b/Documentation/devicetree/bindings/dma/dma-common.yaml
index 307b499..ad06d36 100644
--- a/Documentation/devicetree/bindings/dma/dma-common.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-common.yaml
@@ -38,12 +38,12 @@
maxItems: 255
dma-channels:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Number of DMA channels supported by the controller.
dma-requests:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Number of DMA request signals supported by the controller.
diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml
index 4cee566..e727484 100644
--- a/Documentation/devicetree/bindings/dma/dma-router.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-router.yaml
@@ -23,7 +23,7 @@
pattern: "^dma-router(@.*)?$"
dma-masters:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
Array of phandles to the DMA controllers the router can direct
the signal to.
diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
index 00f19b3..6a20437 100644
--- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
+++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
@@ -48,7 +48,7 @@
ingenic,reserved-channels property.
ingenic,reserved-channels:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: >
Bitmask of channels to reserve for devices that need a specific
channel. These channels will only be assigned when explicitely
diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
index 2117db0..fef9c1e 100644
--- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
+++ b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
@@ -4,6 +4,7 @@
- compatible should contain:
* "mediatek,mt2712-uart-dma" for MT2712 compatible APDMA
* "mediatek,mt6577-uart-dma" for MT6577 and all of the above
+ * "mediatek,mt8516-uart-dma", "mediatek,mt6577" for MT8516 SoC
- reg: The base address of the APDMA register bank.
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt
deleted file mode 100644
index 245d306..0000000
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* NVIDIA Tegra Audio DMA (ADMA) controller
-
-The Tegra Audio DMA controller that is used for transferring data
-between system memory and the Audio Processing Engine (APE).
-
-Required properties:
-- compatible: Should contain one of the following:
- - "nvidia,tegra210-adma": for Tegra210
- - "nvidia,tegra186-adma": for Tegra186 and Tegra194
-- reg: Should contain DMA registers location and length. This should be
- a single entry that includes all of the per-channel registers in one
- contiguous bank.
-- interrupts: Should contain all of the per-channel DMA interrupts in
- ascending order with respect to the DMA channel index.
-- clocks: Must contain one entry for the ADMA module clock
- (TEGRA210_CLK_D_AUDIO).
-- clock-names: Must contain the name "d_audio" for the corresponding
- 'clocks' entry.
-- #dma-cells : Must be 1. The first cell denotes the receive/transmit
- request number and should be between 1 and the maximum number of
- requests supported. This value corresponds to the RX/TX_REQUEST_SELECT
- fields in the ADMA_CHn_CTRL register.
-
-
-Example:
-
-adma: dma@702e2000 {
- compatible = "nvidia,tegra210-adma";
- reg = <0x0 0x702e2000 0x0 0x2000>;
- interrupt-parent = <&tegra_agic>;
- interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>;
- clock-names = "d_audio";
- #dma-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
new file mode 100644
index 0000000..5c2e2f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/nvidia,tegra210-adma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Audio DMA (ADMA) controller
+
+description: |
+ The Tegra Audio DMA controller is used for transferring data
+ between system memory and the Audio Processing Engine (APE).
+
+maintainers:
+ - Jon Hunter <jonathanh@nvidia.com>
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra210-adma
+ - nvidia,tegra186-adma
+ - items:
+ - const: nvidia,tegra194-adma
+ - const: nvidia,tegra186-adma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: |
+ Should contain all of the per-channel DMA interrupts in
+ ascending order with respect to the DMA channel index.
+ minItems: 1
+ maxItems: 32
+
+ clocks:
+ description: Must contain one entry for the ADMA module clock
+ maxItems: 1
+
+ clock-names:
+ const: d_audio
+
+ "#dma-cells":
+ description: |
+ The first cell denotes the receive/transmit request number and
+ should be between 1 and the maximum number of requests supported.
+ This value corresponds to the RX/TX_REQUEST_SELECT fields in the
+ ADMA_CHn_CTRL register.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include<dt-bindings/clock/tegra210-car.h>
+
+ dma-controller@702e2000 {
+ compatible = "nvidia,tegra210-adma";
+ reg = <0x702e2000 0x2000>;
+ interrupt-parent = <&tegra_agic>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>;
+ clock-names = "d_audio";
+ #dma-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
new file mode 100644
index 0000000..f8142ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies Inc GPI DMA controller
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description: |
+ QCOM GPI DMA controller provides DMA capabilities for
+ peripheral buses such as I2C, UART, and SPI.
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdm845-gpi-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Interrupt lines for each GPI instance
+ maxItems: 13
+
+ "#dma-cells":
+ const: 3
+ description: >
+ DMA clients must use the format described in dma.txt, giving a phandle
+ to the DMA controller plus the following 3 integer cells:
+ - channel: if set to 0xffffffff, any available channel will be allocated
+ for the client. Otherwise, the exact channel specified will be used.
+ - seid: serial id of the client as defined in the SoC documentation.
+ - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h
+
+ iommus:
+ maxItems: 1
+
+ dma-channels:
+ maximum: 31
+
+ dma-channel-mask:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - iommus
+ - dma-channels
+ - dma-channel-mask
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/dma/qcom-gpi.h>
+ gpi_dma0: dma-controller@800000 {
+ compatible = "qcom,gpi-dma";
+ #dma-cells = <3>;
+ reg = <0x00800000 0x60000>;
+ iommus = <&apps_smmu 0x0016 0x0>;
+ dma-channels = <13>;
+ dma-channel-mask = <0xfa>;
+ interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 253 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
index b548e47..c07eb6f 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
@@ -73,7 +73,6 @@
maxItems: 1
clock-names:
- maxItems: 1
items:
- const: fck
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index ef1d687..6b35089 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -54,7 +54,7 @@
maximum: 16
dma-masters:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Number of DMA masters supported by the controller. In case if
not specified the driver will try to auto-detect this and
@@ -63,7 +63,7 @@
maximum: 4
chan_allocation_order:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
DMA channels allocation order specifier. Zero means ascending order
(first free allocated), while one - descending (last free allocated).
@@ -71,7 +71,7 @@
enum: [0, 1]
chan_priority:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
DMA channels priority order. Zero means ascending channels priority
so the very first channel has the highest priority. While 1 means
@@ -80,7 +80,7 @@
enum: [0, 1]
block_size:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: Maximum block size supported by the DMA controller.
enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095]
@@ -139,7 +139,7 @@
default: 256
snps,dma-protection-control:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting
indicates the following features: bit 0 - privileged mode,
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
new file mode 100644
index 0000000..b15f68c
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@ti.com>
+
+description: |
+ The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
+ mode channels of K3 UDMA-P.
+ BCDMA includes block copy channels and Split channels.
+
+ Block copy channels mainly used for memory to memory transfers, but with
+ optional triggers a block copy channel can service peripherals by accessing
+ directly to memory mapped registers or area.
+
+ Split channels can be used to service PSI-L based peripherals.
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the
+ legacy peripheral.
+
+ 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#
+
+properties:
+ compatible:
+ const: ti,am64-dmss-bcdma
+
+ "#dma-cells":
+ const: 3
+ description: |
+ cell 1: type of the BCDMA channel to be used to service the peripheral:
+ 0 - split channel
+ 1 - block copy channel using global trigger 1
+ 2 - block copy channel using global trigger 2
+ 3 - block copy channel using local trigger
+
+ cell 2: parameter for the channel:
+ if cell 1 is 0 (split channel):
+ PSI-L thread ID of the remote (to BCDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0xffff
+
+ Please refer to the device documentation for the PSI-L thread map and
+ also the PSI-L peripheral chapter for the correct thread ID.
+ if cell 1 is 1 or 2 (block copy channel using global trigger):
+ Unused, ignored
+
+ The trigger must be configured for the channel externally to BCDMA,
+ channels using global triggers should not be requested directly, but
+ via DMA event router.
+ if cell 1 is 3 (block copy channel using local trigger):
+ bchan number of the locally triggered channel
+
+ 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
+
+ ti,asel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: ASEL value for non slave channels
+
+ ti,sci-rm-range-bchan:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of BCDMA block-copy channel resource subtypes for resource
+ allocation for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-tchan:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of BCDMA split tx channel resource subtypes for resource allocation
+ for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rchan:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of BCDMA split rx channel resource subtypes for resource allocation
+ for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+required:
+ - compatible
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-bchan
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-rchan
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+ cbass_main {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ main_dmss {
+ compatible = "simple-mfd";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges;
+ ranges;
+
+ ti,sci-dev-id = <25>;
+
+ main_bcdma: dma-controller@485c0100 {
+ compatible = "ti,am64-dmss-bcdma";
+
+ reg = <0x0 0x485c0100 0x0 0x100>,
+ <0x0 0x4c000000 0x0 0x20000>,
+ <0x0 0x4a820000 0x0 0x20000>,
+ <0x0 0x4aa40000 0x0 0x20000>,
+ <0x0 0x4bc00000 0x0 0x100000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+ msi-parent = <&inta_main_dmss>;
+ #dma-cells = <3>;
+
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <26>;
+
+ ti,sci-rm-range-bchan = <0x20>; /* BLOCK_COPY_CHAN */
+ ti,sci-rm-range-rchan = <0x21>; /* SPLIT_TR_RX_CHAN */
+ ti,sci-rm-range-tchan = <0x22>; /* SPLIT_TR_TX_CHAN */
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
new file mode 100644
index 0000000..b13ab60
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@ti.com>
+
+description: |
+ The Packet DMA (PKTDMA) is intended to perform similar functions as the packet
+ mode channels of K3 UDMA-P.
+ PKTDMA only includes Split channels to service PSI-L based peripherals.
+
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the
+ legacy peripheral.
+
+ PDMAs can be configured via PKTDMA split channel's peer registers to match
+ with the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ compatible:
+ const: ti,am64-dmss-pktdma
+
+ "#dma-cells":
+ const: 2
+ description: |
+ The first cell is the PSI-L thread ID of the remote (to PKTDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0xffff
+
+ Please refer to the device documentation for the PSI-L thread map and also
+ the PSI-L peripheral chapter for the correct thread ID.
+
+ The second cell is the ASEL value for the channel
+
+ reg:
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,sci-rm-range-tchan:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of PKTDMA split tx channel resource subtypes for resource allocation
+ for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-tflow:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of PKTDMA split tx flow resource subtypes for resource allocation
+ for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rchan:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of PKTDMA split rx channel resource subtypes for resource allocation
+ for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+ ti,sci-rm-range-rflow:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Array of PKTDMA split rx flow resource subtypes for resource allocation
+ for this host
+ minItems: 1
+ # Should be enough
+ maxItems: 255
+ items:
+ maximum: 0x3f
+
+required:
+ - compatible
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-tflow
+ - ti,sci-rm-range-rchan
+ - ti,sci-rm-range-rflow
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+ cbass_main {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ main_dmss {
+ compatible = "simple-mfd";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges;
+ ranges;
+
+ ti,sci-dev-id = <25>;
+
+ main_pktdma: dma-controller@485c0000 {
+ compatible = "ti,am64-dmss-pktdma";
+
+ reg = <0x0 0x485c0000 0x0 0x100>,
+ <0x0 0x4a800000 0x0 0x20000>,
+ <0x0 0x4aa00000 0x0 0x40000>,
+ <0x0 0x4b800000 0x0 0x400000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ msi-parent = <&inta_main_dmss>;
+ #dma-cells = <2>;
+
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <30>;
+
+ ti,sci-rm-range-tchan = <0x23>, /* UNMAPPED_TX_CHAN */
+ <0x24>, /* CPSW_TX_CHAN */
+ <0x25>, /* SAUL_TX_0_CHAN */
+ <0x26>, /* SAUL_TX_1_CHAN */
+ <0x27>, /* ICSSG_0_TX_CHAN */
+ <0x28>; /* ICSSG_1_TX_CHAN */
+ ti,sci-rm-range-tflow = <0x10>, /* RING_UNMAPPED_TX_CHAN */
+ <0x11>, /* RING_CPSW_TX_CHAN */
+ <0x12>, /* RING_SAUL_TX_0_CHAN */
+ <0x13>, /* RING_SAUL_TX_1_CHAN */
+ <0x14>, /* RING_ICSSG_0_TX_CHAN */
+ <0x15>; /* RING_ICSSG_1_TX_CHAN */
+ ti,sci-rm-range-rchan = <0x29>, /* UNMAPPED_RX_CHAN */
+ <0x2b>, /* CPSW_RX_CHAN */
+ <0x2d>, /* SAUL_RX_0_CHAN */
+ <0x2f>, /* SAUL_RX_1_CHAN */
+ <0x31>, /* SAUL_RX_2_CHAN */
+ <0x33>, /* SAUL_RX_3_CHAN */
+ <0x35>, /* ICSSG_0_RX_CHAN */
+ <0x37>; /* ICSSG_1_RX_CHAN */
+ ti,sci-rm-range-rflow = <0x2a>, /* FLOW_UNMAPPED_RX_CHAN */
+ <0x2c>, /* FLOW_CPSW_RX_CHAN */
+ <0x2e>, /* FLOW_SAUL_RX_0/1_CHAN */
+ <0x32>, /* FLOW_SAUL_RX_2/3_CHAN */
+ <0x36>, /* FLOW_ICSSG_0_RX_CHAN */
+ <0x38>; /* FLOW_ICSSG_1_RX_CHAN */
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
index 6a0f3d9..8ca9e0a 100644
--- a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
+++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
@@ -1,6 +1,6 @@
-Aspeed AST2500 SoC EDAC node
+Aspeed BMC SoC EDAC node
-The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error
+The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error
correction check).
The memory controller supports SECDED (single bit error correction, double bit
@@ -11,7 +11,10 @@
Required properties:
-- compatible: should be "aspeed,ast2500-sdram-edac"
+- compatible: should be one of
+ - "aspeed,ast2400-sdram-edac"
+ - "aspeed,ast2500-sdram-edac"
+ - "aspeed,ast2600-sdram-edac"
- reg: sdram controller register set should be <0x1e6e0000 0x174>
- interrupts: should be AVIC interrupt #0
diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml
index 6edfa70..d5117c6 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
@@ -131,7 +131,7 @@
default: 1
read-only:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Disables writes to the eeprom.
@@ -141,7 +141,7 @@
Total eeprom size in bytes.
no-read-rollover:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Indicates that the multi-address eeprom does not automatically roll
over reads to the next slave address. Please consult the manual of
diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml
index 7449736..121a601 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
@@ -45,13 +45,13 @@
spi-max-frequency: true
pagesize:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072]
description:
Size of the eeprom page.
size:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Total eeprom size in bytes.
diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
deleted file mode 100644
index 624bd76..0000000
--- a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-FAIRCHILD SEMICONDUCTOR FSA9480 MICROUSB SWITCH
-
-The FSA9480 is a USB port accessory detector and switch. The FSA9480 is fully
-controlled using I2C and enables USB data, stereo and mono audio, video,
-microphone, and UART data to use a common connector port.
-
-Required properties:
- - compatible : Must be one of
- "fcs,fsa9480"
- "fcs,fsa880"
- - reg : Specifies i2c slave address. Must be 0x25.
- - interrupts : Should contain one entry specifying interrupt signal of
- interrupt parent to which interrupt pin of the chip is connected.
-
- Example:
- musb@25 {
- compatible = "fcs,fsa9480";
- reg = <0x25>;
- interrupt-parent = <&gph2>;
- interrupts = <7 0>;
- };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml
new file mode 100644
index 0000000..9875b4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/extcon-usbc-tusb320.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TUSB320 USB Type-C CC Logic controller
+
+maintainers:
+ - Michael Auchter <michael.auchter@ni.com>
+
+properties:
+ compatible:
+ const: ti,tusb320
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ tusb320@61 {
+ compatible = "ti,tusb320";
+ reg = <0x61>;
+ interrupt-parent = <&gpio>;
+ interrupts = <27 1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml b/Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml
new file mode 100644
index 0000000..ef6a246
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/fcs,fsa880.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fairchild Semiconductor FSA880, FSA9480 and compatibles
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ The FSA880 and FSA9480 are USB port accessory detectors and switches.
+ The switch is fully controlled using I2C and enables USB data, stereo
+ and mono audio, video, microphone, and UART data to use a common
+ connector port. Compatible switches exist from other manufacturers.
+
+properties:
+ compatible:
+ enum:
+ - fcs,fsa880
+ - fcs,fsa9480
+ - ti,tsu6111
+
+ reg:
+ maxItems: 1
+ description: The I2C address for an FSA880 compatible device is
+ usually 0x25.
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ usb-switch@25 {
+ compatible = "fcs,fsa880";
+ reg = <0x25>;
+ interrupt-parent = <&gpio>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
index 99ca986..e733580 100644
--- a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
@@ -1,13 +1,13 @@
-Device-tree bindings for FSI-attached POWER9 On-Chip Controller (OCC)
----------------------------------------------------------------------
+Device-tree bindings for FSI-attached POWER9/POWER10 On-Chip Controller (OCC)
+-----------------------------------------------------------------------------
-This is the binding for the P9 On-Chip Controller accessed over FSI from a
-service processor. See fsi.txt for details on bindings for FSI slave and CFAM
+This is the binding for the P9 or P10 On-Chip Controller accessed over FSI from
+a service processor. See fsi.txt for details on bindings for FSI slave and CFAM
nodes. The OCC is not an FSI slave device itself, rather it is accessed
-through the SBE fifo.
+through the SBE FIFO.
Required properties:
- - compatible = "ibm,p9-occ"
+ - compatible = "ibm,p9-occ" or "ibm,p10-occ"
Examples:
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
index 183ec23..f5ee23c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
@@ -48,6 +48,7 @@
- nxp,pcal6416
- nxp,pcal6524
- nxp,pcal9535
+ - nxp,pcal9554b
- nxp,pcal9555a
- onnn,cat9554
- onnn,pca9654
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
index 08eed23..e506f30 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
@@ -13,6 +13,7 @@
- gpio-controller : Marks the device node as a GPIO controller.
Optional properties:
+- clocks : Input clock specifier. Refer to common clock bindings.
- interrupts : Interrupt mapping for GPIO IRQ.
- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
@@ -29,6 +30,7 @@
gpio: gpio@40000000 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
+ clocks = <&clkc25>;
gpio-controller ;
interrupt-parent = <µblaze_0_intc>;
interrupts = < 6 2 >;
diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
deleted file mode 100644
index e1c49b6..0000000
--- a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Mediatek MT7621 SoC GPIO controller bindings
-
-The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
-The registers of all the banks are interwoven inside one single IO range.
-We load one GPIO controller instance per bank. Also the GPIO controller can receive
-interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU
-using GIC INT12.
-
-Required properties for the top level node:
-- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
- second cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
- Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt. Should be 2. The first cell defines the interrupt number,
- the second encodes the trigger flags encoded as described in
- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-- compatible:
- - "mediatek,mt7621-gpio" for Mediatek controllers
-- reg : Physical base address and length of the controller's registers
-- interrupt-parent : phandle of the parent interrupt controller.
-- interrupts : Interrupt specifier for the controllers interrupt.
-- interrupt-controller : Mark the device node as an interrupt controller.
-- gpio-controller : Marks the device node as a GPIO controller.
-
-Example:
- gpio@600 {
- #gpio-cells = <2>;
- #interrupt-cells = <2>;
- compatible = "mediatek,mt7621-gpio";
- gpio-controller;
- interrupt-controller;
- reg = <0x600 0x100>;
- interrupt-parent = <&gic>;
- interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml
new file mode 100644
index 0000000..5bbb2a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/mediatek,mt7621-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT7621 SoC GPIO controller
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
+ The registers of all the banks are interwoven inside one single IO range.
+ We load one GPIO controller instance per bank. Also the GPIO controller can receive
+ interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU
+ using GIC INT12.
+
+properties:
+ $nodename:
+ pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+ const: mediatek,mt7621-gpio
+
+ reg:
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+ gpio-ranges: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+ - gpio-ranges
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+
+ gpio@600 {
+ compatible = "mediatek,mt7621-gpio";
+ reg = <0x600 0x100>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 95>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
new file mode 100644
index 0000000..1f2ef40
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/mstar,msc313-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MStar/SigmaStar GPIO controller
+
+maintainers:
+ - Daniel Palmer <daniel@thingy.jp>
+
+properties:
+ $nodename:
+ pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+ const: mstar,msc313-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/msc313-gpio.h>
+
+ gpio: gpio@207800 {
+ compatible = "mstar,msc313e-gpio";
+ #gpio-cells = <2>;
+ reg = <0x207800 0x200>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 36 22>,
+ <&pinctrl 22 63 4>,
+ <&pinctrl 26 68 6>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&intc_fiq>;
+ };
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index b1844b9..1844921 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -52,6 +52,23 @@
"#cooling-cells":
const: 2
+ dynamic-power-coefficient:
+ $ref: '/schemas/types.yaml#/definitions/uint32'
+ description:
+ A u32 value that represents the running time dynamic
+ power coefficient in units of uW/MHz/V^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the GPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn = dynamic-power-coefficient * V^2 * f
+
+ where voltage is in V, frequency is in MHz.
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index e9c42b5..696c17a 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -90,6 +90,23 @@
dma-coherent: true
+ dynamic-power-coefficient:
+ $ref: '/schemas/types.yaml#/definitions/uint32'
+ description:
+ A u32 value that represents the running time dynamic
+ power coefficient in units of uW/MHz/V^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the GPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn = dynamic-power-coefficient * V^2 * f
+
+ where voltage is in V, frequency is in MHz.
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
index 662a3c8..cc6ce52 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
@@ -97,8 +97,8 @@
gpu@17000000 {
compatible = "nvidia,gv11b";
- reg = <0x17000000 0x10000000>,
- <0x18000000 0x10000000>;
+ reg = <0x17000000 0x1000000>,
+ <0x18000000 0x1000000>;
interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "stall", "nonstall";
diff --git a/Documentation/devicetree/bindings/hwmon/ad741x.txt b/Documentation/devicetree/bindings/hwmon/ad741x.txt
deleted file mode 100644
index 9102152..0000000
--- a/Documentation/devicetree/bindings/hwmon/ad741x.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* AD7416/AD7417/AD7418 Temperature Sensor Device Tree Bindings
-
-Required properties:
-- compatible: one of
- "adi,ad7416"
- "adi,ad7417"
- "adi,ad7418"
-- reg: I2C address
-
-Example:
-
-hwmon@28 {
- compatible = "adi,ad7418";
- reg = <0x28>;
-};
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml
new file mode 100644
index 0000000..ce7f8ce9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/adi,ad741x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7416/AD7417/AD7418 temperature sensors
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7416
+ - adi,ad7417
+ - adi,ad7418
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@28 {
+ compatible = "adi,ad7418";
+ reg = <0x28>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
new file mode 100644
index 0000000..223393d
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/adi,adm1275.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADM1075/ADM127x/ADM129x digital power monitors
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ The ADM1293 and ADM1294 are high accuracy integrated digital power monitors
+ that offer digital current, voltage, and power monitoring using an on-chip,
+ 12-bit analog-to-digital converter (ADC), communicated through a PMBus
+ compliant I2C interface.
+
+ Datasheets:
+ https://www.analog.com/en/products/adm1294.html
+
+properties:
+ compatible:
+ enum:
+ - adi,adm1075
+ - adi,adm1272
+ - adi,adm1275
+ - adi,adm1276
+ - adi,adm1278
+ - adi,adm1293
+ - adi,adm1294
+
+ reg:
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description:
+ Shunt resistor value in micro-Ohm.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-sensor@10 {
+ compatible = "adi,adm1272";
+ reg = <0x10>;
+ shunt-resistor-micro-ohms = <500>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
new file mode 100644
index 0000000..64a8fcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc2992.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linear Technology 2992 Power Monitor
+
+maintainers:
+ - Alexandru Tachici <alexandru.tachici@analog.com>
+
+description: |
+ Linear Technology 2992 Dual Wide Range Power Monitor
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2992.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc2992
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ avcc-supply: true
+
+patternProperties:
+ "^channel@([0-1])$":
+ type: object
+ description: |
+ Represents the two supplies to be monitored.
+
+ properties:
+ reg:
+ description: |
+ The channel number. LTC2992 can monitor two supplies.
+ items:
+ minimum: 0
+ maximum: 1
+
+ shunt-resistor-micro-ohms:
+ description:
+ The value of curent sense resistor in microohms.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ltc2992@6F {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "adi,ltc2992";
+ reg = <0x6F>;
+
+ channel@0 {
+ reg = <0x0>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
+
+ channel@1 {
+ reg = <0x1>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/adm1275.txt b/Documentation/devicetree/bindings/hwmon/adm1275.txt
deleted file mode 100644
index 1ecd03f..0000000
--- a/Documentation/devicetree/bindings/hwmon/adm1275.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-adm1275 properties
-
-Required properties:
-- compatible: Must be one of the supported compatible strings:
- - "adi,adm1075" for adm1075
- - "adi,adm1272" for adm1272
- - "adi,adm1275" for adm1275
- - "adi,adm1276" for adm1276
- - "adi,adm1278" for adm1278
- - "adi,adm1293" for adm1293
- - "adi,adm1294" for adm1294
-- reg: I2C address
-
-Optional properties:
-
-- shunt-resistor-micro-ohms
- Shunt resistor value in micro-Ohm
-
-Example:
-
-adm1272@10 {
- compatible = "adi,adm1272";
- reg = <0x10>;
- shunt-resistor-micro-ohms = <500>;
-};
diff --git a/Documentation/devicetree/bindings/hwmon/ads7828.txt b/Documentation/devicetree/bindings/hwmon/ads7828.txt
deleted file mode 100644
index fe0cc4a..0000000
--- a/Documentation/devicetree/bindings/hwmon/ads7828.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-ads7828 properties
-
-Required properties:
-- compatible: Should be one of
- ti,ads7828
- ti,ads7830
-- reg: I2C address
-
-Optional properties:
-
-- ti,differential-input
- Set to use the device in differential mode.
-- vref-supply
- The external reference on the device is set to this regulators output. If it
- does not exists the internal reference will be used and output by the ads78xx
- on the "external vref" pin.
-
- Example ADS7828 node:
-
- ads7828: ads@48 {
- comatible = "ti,ads7828";
- reg = <0x48>;
- vref-supply = <&vref>;
- ti,differential-input;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
new file mode 100644
index 0000000..446b09f
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amd,sbtsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: >
+ Sideband interface Temperature Sensor Interface (SB-TSI) compliant
+ AMD SoC temperature device
+
+maintainers:
+ - Kun Yi <kunyi@google.com>
+ - Supreeth Venkatesh <supreeth.venkatesh@amd.com>
+
+description: |
+ SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible
+ interface that reports AMD SoC's Ttcl (normalized temperature),
+ and resembles a typical 8-pin remote temperature sensor's I2C interface
+ to BMC. The emulated thermal sensor can report temperatures in increments
+ of 0.125 degrees, ranging from 0 to 255.875.
+
+properties:
+ compatible:
+ enum:
+ - amd,sbtsi
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C bus address of the device as specified in Section 6.3.1 of the
+ SoC register reference. The SB-TSI address is normally 98h for socket
+ 0 and 90h for socket 1, but it could vary based on hardware address
+ select pins.
+ \[open source SoC register reference\]
+ https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sbtsi@4c {
+ compatible = "amd,sbtsi";
+ reg = <0x4c>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/ina2xx.txt b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
deleted file mode 100644
index 02af0d9..0000000
--- a/Documentation/devicetree/bindings/hwmon/ina2xx.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-ina2xx properties
-
-Required properties:
-- compatible: Must be one of the following:
- - "ti,ina209" for ina209
- - "ti,ina219" for ina219
- - "ti,ina220" for ina220
- - "ti,ina226" for ina226
- - "ti,ina230" for ina230
- - "ti,ina231" for ina231
-- reg: I2C address
-
-Optional properties:
-
-- shunt-resistor
- Shunt resistor value in micro-Ohm
-
-Example:
-
-ina220@44 {
- compatible = "ti,ina220";
- reg = <0x44>;
- shunt-resistor = <1000>;
-};
diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
index 6f3e3c0..b79f069 100644
--- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
+++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
@@ -32,7 +32,7 @@
PVT controller has 5 VM (voltage monitor) sensors.
vm-map defines CPU core to VM instance mapping. A
value of 0xff means that VM sensor is unused.
- $ref: /schemas/types.yaml#definitions/uint8-array
+ $ref: /schemas/types.yaml#/definitions/uint8-array
maxItems: 5
clocks:
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 41b7676..4509e68 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -8,15 +8,16 @@
Optional properties:
- fan-supply : phandle to the regulator that provides power to the fan
-- interrupts : This contains a single interrupt specifier which
- describes the tachometer output of the fan as an
- interrupt source. The output signal must generate a
- defined number of interrupts per fan revolution, which
- require that it must be self resetting edge interrupts.
- See interrupt-controller/interrupts.txt for the format.
-- pulses-per-revolution : define the tachometer pulses per fan revolution as
- an integer (default is 2 interrupts per revolution).
- The value must be greater than zero.
+- interrupts : This contains an interrupt specifier for each fan
+ tachometer output connected to an interrupt source.
+ The output signal must generate a defined number of
+ interrupts per fan revolution, which require that
+ it must be self resetting edge interrupts. See
+ interrupt-controller/interrupts.txt for the format.
+- pulses-per-revolution : define the number of pulses per fan revolution for
+ each tachometer input as an integer (default is 2
+ interrupts per revolution). The value must be
+ greater than zero.
Example:
fan0: pwm-fan {
@@ -55,3 +56,12 @@
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
pulses-per-revolution = <2>;
};
+
+Example 3:
+ fan0: pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm1 0 25000 0>;
+ interrupts-extended = <&gpio1 1 IRQ_TYPE_EDGE_FALLING>,
+ <&gpio2 5 IRQ_TYPE_EDGE_FALLING>;
+ pulses-per-revolution = <2>, <1>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
index c523a1b..7d49478 100644
--- a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -29,12 +29,12 @@
const: 0x70
sensirion,blocking-io:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
If set, the driver hold the i2c bus until measurement is finished.
sensirion,low-precision:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
If set, the sensor aquire data with low precision (not recommended).
The driver aquire data with high precision by default.
diff --git a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml
new file mode 100644
index 0000000..33ee575
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/ti,ads7828.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ADS7828/ADS7830 Analog to Digital Converter (ADC)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ The ADS7828 is 12-Bit, 8-Channel Sampling Analog to Digital Converter (ADC)
+ with an I2C interface.
+
+ Datasheets:
+ https://www.ti.com/product/ADS7828
+
+properties:
+ compatible:
+ enum:
+ - ti,ads7828
+ - ti,ads7830
+
+ reg:
+ maxItems: 1
+
+ ti,differential-input:
+ description:
+ Set to use the device in differential mode.
+ type: boolean
+
+ vref-supply:
+ description:
+ The regulator to use as an external reference. If it does not exists the
+ internal reference will be used.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@48 {
+ comatible = "ti,ads7828";
+ reg = <0x48>;
+ vref-supply = <&vref>;
+ ti,differential-input;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
new file mode 100644
index 0000000..6f04433
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/ti,ina2xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments INA209 family of power/voltage monitors
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ The INA209 is a high-side current shunt and power monitor with
+ an I2C interface.
+
+ Datasheets:
+ https://www.ti.com/product/INA209
+
+properties:
+ compatible:
+ enum:
+ - ti,ina209
+ - ti,ina219
+ - ti,ina220
+ - ti,ina226
+ - ti,ina230
+ - ti,ina231
+
+ reg:
+ maxItems: 1
+
+ shunt-resistor:
+ description:
+ Shunt resistor value in micro-Ohm.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-sensor@44 {
+ compatible = "ti,ina220";
+ reg = <0x44>;
+ shunt-resistor = <1000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
index c17e5d3..8020d73 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
@@ -61,7 +61,7 @@
Array of three(TMP513) or two(TMP512) n-Factor value for each remote
temperature channel.
See datasheet Table 11 for n-Factor range list and value interpretation.
- $ref: /schemas/types.yaml#definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 3
items:
diff --git a/Documentation/devicetree/bindings/i2c/i2c-gate.txt b/Documentation/devicetree/bindings/i2c/i2c-gate.txt
deleted file mode 100644
index 1846d23..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-gate.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-An i2c gate is useful to e.g. reduce the digital noise for RF tuners connected
-to the i2c bus. Gates are similar to arbitrators in that you need to perform
-some kind of operation to access the i2c bus past the arbitrator/gate, but
-there are no competing masters to consider for gates and therefore there is
-no arbitration happening for gates.
-
-Common i2c gate properties.
-
-- i2c-gate child node
-
-Required properties for the i2c-gate child node:
-- #address-cells = <1>;
-- #size-cells = <0>;
-
-Optional properties for i2c-gate child node:
-- Child nodes conforming to i2c bus binding
-
-
-Example :
-
- /*
- An Invensense mpu9150 at address 0x68 featuring an on-chip Asahi
- Kasei ak8975 compass behind a gate.
- */
-
- mpu9150@68 {
- compatible = "invensense,mpu9150";
- reg = <0x68>;
- interrupt-parent = <&gpio1>;
- interrupts = <18 1>;
-
- i2c-gate {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ax8975@c {
- compatible = "ak,ak8975";
- reg = <0x0c>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-gate.yaml b/Documentation/devicetree/bindings/i2c/i2c-gate.yaml
new file mode 100644
index 0000000..66472f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-gate.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-gate.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common i2c gate properties
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ An i2c gate is useful to e.g. reduce the digital noise for RF tuners connected
+ to the i2c bus. Gates are similar to arbitrators in that you need to perform
+ some kind of operation to access the i2c bus past the arbitrator/gate, but
+ there are no competing masters to consider for gates and therefore there is
+ no arbitration happening for gates.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml
+
+properties:
+ $nodename:
+ const: i2c-gate
+
+additionalProperties: true
+
+examples:
+ - |
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ak8975@c {
+ compatible = "ak,ak8975";
+ reg = <0x0c>;
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
index 6b25a80..a37c945 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
@@ -5,8 +5,12 @@
"aeroflexgaisler,i2cmst"
"sifive,fu540-c000-i2c", "sifive,i2c0"
For Opencore based I2C IP block reimplemented in
- FU540-C000 SoC. Please refer to sifive-blocks-ip-versioning.txt
- for additional details.
+ FU540-C000 SoC.
+ "sifive,fu740-c000-i2c", "sifive,i2c0"
+ For Opencore based I2C IP block reimplemented in
+ FU740-C000 SoC.
+ Please refer to sifive-blocks-ip-versioning.txt for
+ additional details.
- reg : bus address start and address range size of device
- clocks : handle to the controller clock; see the note below.
Mutually exclusive with opencores,ip-clock-frequency
diff --git a/Documentation/devicetree/bindings/i2c/i2c-omap.txt b/Documentation/devicetree/bindings/i2c/i2c-omap.txt
index a44573d..a425b91 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-omap.txt
@@ -8,6 +8,7 @@
"ti,omap4-i2c" for OMAP4+ SoCs
"ti,am654-i2c", "ti,omap4-i2c" for AM654 SoCs
"ti,j721e-i2c", "ti,omap4-i2c" for J721E SoCs
+ "ti,am64-i2c", "ti,omap4-i2c" for AM64 SoCs
- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
- #address-cells = <1>;
- #size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
deleted file mode 100644
index 54c05db..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Actions Semiconductor Owl I2C controller
-
-Required properties:
-
-- compatible : Should be one of the following:
- - "actions,s700-i2c" for S700 SoC
- - "actions,s900-i2c" for S900 SoC
-- reg : Offset and length of the register set for the device.
-- #address-cells : Should be 1.
-- #size-cells : Should be 0.
-- interrupts : A single interrupt specifier.
-- clocks : Phandle of the clock feeding the I2C controller.
-
-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.
-Examples:
-
- i2c0: i2c@e0170000 {
- compatible = "actions,s900-i2c";
- reg = <0 0xe0170000 0 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clock CLK_I2C0>;
- clock-frequency = <100000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.yaml b/Documentation/devicetree/bindings/i2c/i2c-owl.yaml
new file mode 100644
index 0000000..d96908b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-owl.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-owl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl I2C Controller
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description: |
+ This I2C controller is found in the Actions Semi Owl SoCs:
+ S500, S700 and S900.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - actions,s500-i2c # Actions Semi S500 compatible SoCs
+ - actions,s700-i2c # Actions Semi S700 compatible SoCs
+ - actions,s900-i2c # Actions Semi S900 compatible SoCs
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description: Phandle of the clock feeding the I2C controller.
+ minItems: 1
+
+ clock-frequency:
+ description: |
+ Desired I2C bus clock frequency in Hz. As only Standard and Fast
+ modes are supported, possible values are 100000 and 400000.
+ enum: [100000, 400000]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/actions,s900-cmu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c@e0170000 {
+ compatible = "actions,s900-i2c";
+ reg = <0xe0170000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_I2C0>;
+ clock-frequency = <100000>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.txt b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.txt
deleted file mode 100644
index 566ea86..0000000
--- a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Device tree configuration for the Mellanox I2C SMBus on BlueField SoCs
-
-Required Properties:
-
-- compatible : should be "mellanox,i2c-mlxbf1" or "mellanox,i2c-mlxbf2".
-
-- reg : address offset and length of the device registers. The
- registers consist of the following set of resources:
- 1) Smbus block registers.
- 2) Cause master registers.
- 3) Cause slave registers.
- 4) Cause coalesce registers (if compatible isn't set
- to "mellanox,i2c-mlxbf1").
-
-- interrupts : interrupt number.
-
-Optional Properties:
-
-- clock-frequency : bus frequency used to configure timing registers;
- allowed values are 100000, 400000 and 1000000;
- those are expressed in Hz. Default is 100000.
-
-Example:
-
-i2c@2804000 {
- compatible = "mellanox,i2c-mlxbf1";
- reg = <0x02804000 0x800>,
- <0x02801200 0x020>,
- <0x02801260 0x020>;
- interrupts = <57>;
- clock-frequency = <100000>;
-};
-
-i2c@2808800 {
- compatible = "mellanox,i2c-mlxbf2";
- reg = <0x02808800 0x600>,
- <0x02808e00 0x020>,
- <0x02808e20 0x020>,
- <0x02808e40 0x010>;
- interrupts = <57>;
- clock-frequency = <400000>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml
new file mode 100644
index 0000000..d2b401d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/mellanox,i2c-mlxbf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mellanox I2C SMBus on BlueField SoCs
+
+maintainers:
+ - Khalil Blaiech <kblaiech@nvidia.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - mellanox,i2c-mlxbf1
+ - mellanox,i2c-mlxbf2
+
+ reg:
+ minItems: 3
+ maxItems: 4
+ items:
+ - description: Smbus block registers
+ - description: Cause master registers
+ - description: Cause slave registers
+ - description: Cause coalesce registers
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ enum: [ 100000, 400000, 1000000 ]
+ description:
+ bus frequency used to configure timing registers;
+ The frequency is expressed in Hz. Default is 100000.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mellanox,i2c-mlxbf1
+
+then:
+ properties:
+ reg:
+ maxItems: 3
+
+examples:
+ - |
+ i2c@2804000 {
+ compatible = "mellanox,i2c-mlxbf1";
+ reg = <0x02804000 0x800>,
+ <0x02801200 0x020>,
+ <0x02801260 0x020>;
+ interrupts = <57>;
+ clock-frequency = <100000>;
+ };
+
+ - |
+ i2c@2808800 {
+ compatible = "mellanox,i2c-mlxbf2";
+ reg = <0x02808800 0x600>,
+ <0x02808e00 0x020>,
+ <0x02808e20 0x020>,
+ <0x02808e40 0x010>;
+ interrupts = <57>;
+ clock-frequency = <400000>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
index 4f746be..c22b66b 100644
--- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
@@ -101,8 +101,6 @@
required:
- compatible
- reg
- - "#address-cells"
- - "#size-cells"
- interrupts
examples:
@@ -110,8 +108,6 @@
i2c@f0000 {
compatible = "snps,designware-i2c";
reg = <0xf0000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
interrupts = <11>;
clock-frequency = <400000>;
};
@@ -119,8 +115,6 @@
i2c@1120000 {
compatible = "snps,designware-i2c";
reg = <0x1120000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
interrupts = <12 1>;
clock-frequency = <400000>;
i2c-sda-hold-time-ns = <300>;
@@ -148,8 +142,6 @@
reg = <0x100400 0x100>, <0x198 0x8>;
pinctrl-0 = <&i2c_pins>;
pinctrl-names = "default";
- #address-cells = <1>;
- #size-cells = <0>;
interrupts = <8>;
clocks = <&ahb_clk>;
};
diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
new file mode 100644
index 0000000..07a7b10
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: MIPI I3C HCI Device Tree Bindings
+
+maintainers:
+ - Nicolas Pitre <npitre@baylibre.com>
+
+description: |
+ MIPI I3C Host Controller Interface
+
+ The MIPI I3C HCI (Host Controller Interface) specification defines
+ a common software driver interface to support compliant MIPI I3C
+ host controller hardware implementations from multiple vendors.
+
+ The hardware is self-advertising for differences in implementation
+ capabilities, including the spec version it is based on, so there
+ isn't much to describe here (yet).
+
+ For details, please see:
+ https://www.mipi.org/specifications/i3c-hci
+
+properties:
+ compatible:
+ const: mipi-i3c-hci
+ reg:
+ maxItems: 1
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ i3c@a0000000 {
+ compatible = "mipi-i3c-hci";
+ reg = <0xa0000000 0x2000>;
+ interrupts = <89>;
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt b/Documentation/devicetree/bindings/iio/accel/bma180.txt
deleted file mode 100644
index 33da4a6..0000000
--- a/Documentation/devicetree/bindings/iio/accel/bma180.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* Bosch BMA023 / BMA150/ BMA180 / BMA25x / SMB380 triaxial acceleration sensor
-
-https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA150.pdf
-http://omapworld.com/BMA180_111_1002839.pdf
-http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf
-
-Required properties:
-
- - compatible : should be one of:
- "bosch,bma023"
- "bosch,bma150"
- "bosch,bma180"
- "bosch,bma250"
- "bosch,bma254"
- "bosch,smb380"
- - reg : the I2C address of the sensor
- - vdd-supply : regulator phandle connected to the VDD pin
- - vddio-supply : regulator phandle connected to the VDDIO pin
-
-Optional properties:
-
- - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
- flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
- For the bma250 the first interrupt listed must be the one
- connected to the INT1 pin, the second (optional) interrupt
- listed must be the one connected to the INT2 pin.
-
-Example:
-
-bma180@40 {
- compatible = "bosch,bma180";
- reg = <0x40>;
- interrupt-parent = <&gpio6>;
- interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
-};
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml
new file mode 100644
index 0000000..45b3abd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/bosch,bma180.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMA023 / BMA150/ BMA180 / BMA25x / SMB380 triaxial accelerometers
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA150.pdf
+ http://omapworld.com/BMA180_111_1002839.pdf
+ http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf
+
+properties:
+ compatible:
+ enum:
+ - bosch,bma023
+ - bosch,bma150
+ - bosch,bma180
+ - bosch,bma250
+ - bosch,bma254
+ - bosch,smb380
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ vddio-supply: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+ description: |
+ Type should be either IRQ_TYPE_LEVEL_HIGH or IRQ_TYPE_EDGE_RISING.
+ For the bma250 the first interrupt listed must be the one
+ connected to the INT1 pin, the second (optional) interrupt
+ listed must be the one connected to the INT2 pin.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ accel@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml
new file mode 100644
index 0000000..6eef348
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/bosch,bma255.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMA255 and Similar Accelerometers
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ 3 axis accelerometers with varying range and I2C or SPI
+ 4-wire interface.
+
+properties:
+ compatible:
+ enum:
+ - bosch,bmc150
+ - bosch,bmi055
+ - bosch,bma255
+ - bosch,bma250e
+ - bosch,bma222
+ - bosch,bma222e
+ - bosch,bma280
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+ interrupts:
+ maxItems: 1
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
+ spi-max-frequency:
+ maximum: 10000000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ accelerometer@8 {
+ compatible = "bosch,bma222";
+ reg = <0x08>;
+ vddio-supply = <&vddio>;
+ vdd-supply = <&vdd>;
+ interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+ - |
+ # include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ accel@0 {
+ compatible = "bosch,bma222";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/accel/dmard06.txt b/Documentation/devicetree/bindings/iio/accel/dmard06.txt
deleted file mode 100644
index ce105a1..0000000
--- a/Documentation/devicetree/bindings/iio/accel/dmard06.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Device tree bindings for Domintech DMARD05, DMARD06, DMARD07 accelerometers
-
-Required properties:
- - compatible : Should be "domintech,dmard05"
- or "domintech,dmard06"
- or "domintech,dmard07"
- - reg : I2C address of the chip. Should be 0x1c
-
-Example:
- &i2c1 {
- /* ... */
-
- accelerometer@1c {
- compatible = "domintech,dmard06";
- reg = <0x1c>;
- };
-
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma8452.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma8452.yaml
new file mode 100644
index 0000000..b0dd2b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma8452.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/fsl,mma8452.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Freescale MMA8451Q, MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC or FXLS8471Q
+ triaxial accelerometer
+
+maintainers:
+ - Martin Kepplinger <martin.kepplinger@theobroma-systems.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,mma8451
+ - fsl,mma8452
+ - fsl,mma8453
+ - fsl,mma8652
+ - fsl,mma8653
+ - fsl,fxls8471
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ 2 highly configurable interrupt lines exist.
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ description: Specify which interrupt line is in use.
+ items:
+ enum:
+ - INT1
+ - INT2
+ minItems: 1
+ maxItems: 2
+
+ vdd-supply: true
+ vddio-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accel@1d {
+ compatible = "fsl,mma8453";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 0>;
+ interrupt-names = "INT2";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt
deleted file mode 100644
index ce950e1..0000000
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Kionix KXCJK-1013 Accelerometer device tree bindings
-
-Required properties:
-
-- compatible: Must be one of:
- "kionix,kxcjk1013"
- "kionix,kxcj91008"
- "kionix,kxtj21009"
- "kionix,kxtf9"
- - reg: i2c slave address
-
-Optional properties:
-
- - mount-matrix: an optional 3x3 mounting rotation matrix
-
-Example:
-
-kxtf9@f {
- compatible = "kionix,kxtf9";
- reg = <0x0F>;
- mount-matrix = "0", "1", "0",
- "1", "0", "0",
- "0", "0", "1";
-};
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
new file mode 100644
index 0000000..5667d09
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/kionix,kxcjk1013.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kionix KXCJK-1013 Accelerometer
+
+maintainers:
+ - Robert Yang <decatf@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - kionix,kxcjk1013
+ - kionix,kxcj91008
+ - kionix,kxtj21009
+ - kionix,kxtf9
+
+ reg:
+ maxItems: 1
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accel@f {
+ compatible = "kionix,kxtf9";
+ reg = <0x0F>;
+ mount-matrix = "0", "1", "0",
+ "1", "0", "0",
+ "0", "0", "1";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
deleted file mode 100644
index e132394..0000000
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Freescale MMA8451Q, MMA8452Q, MMA8453Q, MMA8652FC, MMA8653FC or FXLS8471Q
-triaxial accelerometer
-
-Required properties:
-
- - compatible: should contain one of
- * "fsl,mma8451"
- * "fsl,mma8452"
- * "fsl,mma8453"
- * "fsl,mma8652"
- * "fsl,mma8653"
- * "fsl,fxls8471"
-
- - reg: the I2C address of the chip
-
-Optional properties:
-
- - interrupts: interrupt mapping for GPIO IRQ
-
- - interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
- interrupt line in use.
-
- - vdd-supply: phandle to the regulator that provides vdd power to the accelerometer.
-
- - vddio-supply: phandle to the regulator that provides vddio power to the accelerometer.
-
-Example:
-
- mma8453fc@1d {
- compatible = "fsl,mma8453";
- reg = <0x1d>;
- interrupt-parent = <&gpio1>;
- interrupts = <5 0>;
- interrupt-names = "INT2";
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.txt b/Documentation/devicetree/bindings/iio/adc/adc.txt
deleted file mode 100644
index 5bbaa33..0000000
--- a/Documentation/devicetree/bindings/iio/adc/adc.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Common ADCs properties
-
-Optional properties for child nodes:
-- bipolar : Boolean, if set the channel is used in bipolar mode.
-- diff-channels : Differential channels muxed for this ADC. The first value
- specifies the positive input pin, the second value the negative
- input pin.
-
-Example:
- adc@0 {
- compatible = "some,adc";
- ...
- channel@0 {
- bipolar;
- diff-channels = <0 1>;
- ...
- };
-
- channel@1 {
- diff-channels = <2 3>;
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
new file mode 100644
index 0000000..912a763
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic IIO bindings for ADC channels
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description:
+ A few properties are defined in a common way ADC channels.
+
+properties:
+ $nodename:
+ pattern: "^channel(@[0-9a-f]+)?$"
+ description:
+ A channel index should match reg.
+
+ reg:
+ maxItems: 1
+
+ label:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Unique name to identify which channel this is.
+
+ bipolar:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: If provided, the channel is to be used in bipolar mode.
+
+ diff-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ minItems: 2
+ description:
+ Many ADCs have dual Muxes to allow different input pins to be routed
+ to both the positive and negative inputs of a differential ADC.
+ The first value specifies the positive input pin, the second
+ specifies the negative input pin.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
index f1c574c..fb3d0da 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
@@ -63,10 +63,10 @@
patternProperties:
"^channel@([0-9]|1[0-5])$":
+ $ref: "adc.yaml"
type: object
description: |
Represents the external channels which are connected to the ADC.
- See Documentation/devicetree/bindings/iio/adc/adc.txt.
properties:
reg:
@@ -88,15 +88,9 @@
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 3]
- diff-channels:
- description: see Documentation/devicetree/bindings/iio/adc/adc.txt
- items:
- minimum: 0
- maximum: 15
+ diff-channels: true
- bipolar:
- description: see Documentation/devicetree/bindings/iio/adc/adc.txt
- type: boolean
+ bipolar: true
adi,buffered-positive:
description: Enable buffered mode for positive input.
@@ -110,6 +104,8 @@
- reg
- diff-channels
+ additionalProperties: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
index 108d202..a3e39a4 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
@@ -45,10 +45,10 @@
patternProperties:
"^channel@[0-7]$":
+ $ref: "adc.yaml"
type: object
description: |
Represents the external channels which are connected to the ADC.
- See Documentation/devicetree/bindings/iio/adc/adc.txt.
properties:
reg:
@@ -58,13 +58,13 @@
- minimum: 0
maximum: 7
- diff-channels:
- description: see Documentation/devicetree/bindings/iio/adc/adc.txt
- maxItems: 1
+ diff-channels: true
required:
- reg
+ additionalProperties: true
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
index 8f32800..924477d 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
@@ -29,6 +29,12 @@
interrupts:
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
vref-supply:
description:
ADC reference voltage supply
@@ -62,6 +68,24 @@
- spi-cpha
- adi,sync-in-gpios
+patternProperties:
+ "^channel@([0-9]|1[0-5])$":
+ type: object
+ description: |
+ Represents the external channels which are connected to the device.
+
+ properties:
+ reg:
+ description: |
+ The channel number.
+
+ label:
+ description: |
+ Unique name to identify which channel this is.
+ required:
+ - reg
+ additionalProperties: false
+
additionalProperties: false
examples:
@@ -85,6 +109,14 @@
reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
clocks = <&ad7768_mclk>;
clock-names = "mclk";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ label = "channel_0";
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
deleted file mode 100644
index 07c59f3..0000000
--- a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* AT91 SAMA5D2 Analog to Digital Converter (ADC)
-
-Required properties:
- - compatible: Should be "atmel,sama5d2-adc" or "microchip,sam9x60-adc".
- - reg: Should contain ADC registers location and length.
- - interrupts: Should contain the IRQ line for the ADC.
- - clocks: phandle to device clock.
- - clock-names: Must be "adc_clk".
- - vref-supply: Supply used as reference for conversions.
- - vddana-supply: Supply for the adc device.
- - atmel,min-sample-rate-hz: Minimum sampling rate, it depends on SoC.
- - atmel,max-sample-rate-hz: Maximum sampling rate, it depends on SoC.
- - atmel,startup-time-ms: Startup time expressed in ms, it depends on SoC.
- - atmel,trigger-edge-type: One of possible edge types for the ADTRG hardware
- trigger pin. When the specific edge type is detected, the conversion will
- start. Possible values are rising, falling, or both.
- This property uses the IRQ edge types values: IRQ_TYPE_EDGE_RISING ,
- IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH
-
-Optional properties:
- - dmas: Phandle to dma channel for the ADC.
- - dma-names: Must be "rx" when dmas property is being used.
- See ../../dma/dma.txt for details.
- - #io-channel-cells: in case consumer drivers are attached, this must be 1.
- See <Documentation/devicetree/bindings/iio/iio-bindings.txt> for details.
-
-Properties for consumer drivers:
- - Consumer drivers can be connected to this producer device, as specified
- in <Documentation/devicetree/bindings/iio/iio-bindings.txt>
- - Channels exposed are specified in:
- <dt-bindings/iio/adc/at91-sama5d2_adc.txt>
-
-Example:
-
-adc: adc@fc030000 {
- compatible = "atmel,sama5d2-adc";
- reg = <0xfc030000 0x100>;
- interrupts = <40 IRQ_TYPE_LEVEL_HIGH 7>;
- clocks = <&adc_clk>;
- clock-names = "adc_clk";
- atmel,min-sample-rate-hz = <200000>;
- atmel,max-sample-rate-hz = <20000000>;
- atmel,startup-time-ms = <4>;
- vddana-supply = <&vdd_3v3_lp_reg>;
- vref-supply = <&vdd_3v3_lp_reg>;
- atmel,trigger-edge-type = <IRQ_TYPE_EDGE_BOTH>;
- dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(25))>;
- dma-names = "rx";
- #io-channel-cells = <1>;
-}
diff --git a/Documentation/devicetree/bindings/iio/adc/at91_adc.txt b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
deleted file mode 100644
index f65b04f..0000000
--- a/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-* AT91's Analog to Digital Converter (ADC)
-
-Required properties:
- - compatible: Should be "atmel,<chip>-adc"
- <chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5"
- - reg: Should contain ADC registers location and length
- - interrupts: Should contain the IRQ line for the ADC
- - clock-names: tuple listing input clock names.
- Required elements: "adc_clk", "adc_op_clk".
- - clocks: phandles to input clocks.
- - atmel,adc-channels-used: Bitmask of the channels muxed and enabled for this
- device
- - atmel,adc-startup-time: Startup Time of the ADC in microseconds as
- defined in the datasheet
- - atmel,adc-vref: Reference voltage in millivolts for the conversions
- - atmel,adc-res: List of resolutions in bits supported by the ADC. List size
- must be two at least.
- - atmel,adc-res-names: Contains one identifier string for each resolution
- in atmel,adc-res property. "lowres" and "highres"
- identifiers are required.
-
-Optional properties:
- - atmel,adc-use-external-triggers: Boolean to enable the external triggers
- - atmel,adc-use-res: String corresponding to an identifier from
- atmel,adc-res-names property. If not specified, the highest
- resolution will be used.
- - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
- - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
- - atmel,adc-ts-wires: Number of touchscreen wires. Should be 4 or 5. If this
- value is set, then the adc driver will enable touchscreen
- support.
- NOTE: when adc touchscreen is enabled, the adc hardware trigger will be
- disabled. Since touchscreen will occupy the trigger register.
- - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
- makes touch detection more precise.
-
-Optional trigger Nodes:
- - Required properties:
- * trigger-name: Name of the trigger exposed to the user
- * trigger-value: Value to put in the Trigger register
- to activate this trigger
- - Optional properties:
- * trigger-external: Is the trigger an external trigger?
-
-Examples:
-adc0: adc@fffb0000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "atmel,at91sam9260-adc";
- reg = <0xfffb0000 0x100>;
- interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
- clocks = <&adc_clk>, <&adc_op_clk>;
- clock-names = "adc_clk", "adc_op_clk";
- atmel,adc-channels-used = <0xff>;
- atmel,adc-startup-time = <40>;
- atmel,adc-use-external-triggers;
- atmel,adc-vref = <3300>;
- atmel,adc-res = <8 10>;
- atmel,adc-res-names = "lowres", "highres";
- atmel,adc-use-res = "lowres";
-
- trigger0 {
- trigger-name = "external-rising";
- trigger-value = <0x1>;
- trigger-external;
- };
- trigger1 {
- trigger-name = "external-falling";
- trigger-value = <0x2>;
- trigger-external;
- };
-
- trigger2 {
- trigger-name = "external-any";
- trigger-value = <0x3>;
- trigger-external;
- };
-
- trigger3 {
- trigger-name = "continuous";
- trigger-value = <0x6>;
- };
-};
diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
new file mode 100644
index 0000000..79c13b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/atmel,sama5d2-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AT91 SAMA5D2 Analog to Digital Converter (ADC)
+
+maintainers:
+ - Ludovic Desroches <ludovic.desroches@atmel.com>
+ - Eugen Hristev <eugen.hristev@microchip.com>
+
+properties:
+ compatible:
+ enum:
+ - atmel,sama5d2-adc
+ - microchip,sam9x60-adc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: adc_clk
+
+ vref-supply: true
+ vddana-supply: true
+
+ atmel,min-sample-rate-hz:
+ description: Minimum sampling rate, it depends on SoC.
+
+ atmel,max-sample-rate-hz:
+ description: Maximum sampling rate, it depends on SoC.
+
+ atmel,startup-time-ms:
+ description: Startup time expressed in ms, it depends on SoC.
+
+ atmel,trigger-edge-type:
+ $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
+ start. Should be one of IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING
+ or IRQ_TYPE_EDGE_BOTH.
+ enum: [1, 2, 3]
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+ "#io-channel-cells":
+ const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - vref-supply
+ - vddana-supply
+ - atmel,min-sample-rate-hz
+ - atmel,max-sample-rate-hz
+ - atmel,startup-time-ms
+ - atmel,trigger-edge-type
+
+examples:
+ - |
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ adc@fc030000 {
+ compatible = "atmel,sama5d2-adc";
+ reg = <0xfc030000 0x100>;
+ interrupts = <40 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <&adc_clk>;
+ clock-names = "adc_clk";
+ atmel,min-sample-rate-hz = <200000>;
+ atmel,max-sample-rate-hz = <20000000>;
+ atmel,startup-time-ms = <4>;
+ vddana-supply = <&vdd_3v3_lp_reg>;
+ vref-supply = <&vdd_3v3_lp_reg>;
+ atmel,trigger-edge-type = <IRQ_TYPE_EDGE_BOTH>;
+ dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(25))>;
+ dma-names = "rx";
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
new file mode 100644
index 0000000..e6a1f91
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/atmel,sama9260-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AT91 sama9260 and similar Analog to Digital Converter (ADC)
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91sam9260-adc
+ - atmel,at91sam9rl-adc
+ - atmel,at91sam9g45-adc
+ - atmel,at91sam9x5-adc
+ - atmel,at91sama5d3-adc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: adc_clk
+ - const: adc_op_clk
+
+ atmel,adc-channels-used:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Bitmask of the channels muxed and enabled for this device
+
+ atmel,adc-startup-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Startup Time of the ADC in microseconds as defined in the datasheet
+
+ atmel,adc-vref:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Reference voltage in millivolts for the conversions
+
+ atmel,adc-use-external-triggers:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enable the external triggers
+
+ atmel,adc-use-res:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ String corresponding to an identifier from atmel,adc-res-names property.
+ If not specified, the highest resolution will be used.
+ enum:
+ - "lowres"
+ - "highres"
+
+ atmel,adc-sleep-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enable sleep mode when no conversion
+
+ atmel,adc-sample-hold-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Sample and Hold Time in microseconds
+
+ atmel,adc-ts-wires:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Number of touchscreen wires. Must be set to enable touchscreen.
+ NOTE: when adc touchscreen is enabled, the adc hardware trigger will be
+ disabled. Since touchscreen will occupy the trigger register.
+ enum:
+ - 4
+ - 5
+
+ atmel,adc-ts-pressure-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Pressure threshold for touchscreen.
+
+ "#io-channel-cells":
+ const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - atmel,adc-channels-used
+ - atmel,adc-startup-time
+ - atmel,adc-vref
+
+examples:
+ - |
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ adc@fffb0000 {
+ compatible = "atmel,at91sam9260-adc";
+ reg = <0xfffb0000 0x100>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&adc_clk>, <&adc_op_clk>;
+ clock-names = "adc_clk", "adc_op_clk";
+ atmel,adc-channels-used = <0xff>;
+ atmel,adc-startup-time = <40>;
+ atmel,adc-use-external-triggers;
+ atmel,adc-vref = <3300>;
+ atmel,adc-use-res = "lowres";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
deleted file mode 100644
index 7a63139..0000000
--- a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-* X-Powers AXP ADC bindings
-
-Required properties:
- - compatible: should be one of:
- - "x-powers,axp209-adc",
- - "x-powers,axp221-adc",
- - "x-powers,axp813-adc",
- - #io-channel-cells: should be 1,
-
-Example:
-
-&axp22x {
- adc {
- compatible = "x-powers,axp221-adc";
- #io-channel-cells = <1>;
- };
-};
-
-ADC channels and their indexes per variant:
-
-AXP209
-------
- 0 | acin_v
- 1 | acin_i
- 2 | vbus_v
- 3 | vbus_i
- 4 | pmic_temp
- 5 | gpio0_v
- 6 | gpio1_v
- 7 | ipsout_v
- 8 | batt_v
- 9 | batt_chrg_i
-10 | batt_dischrg_i
-
-AXP22x
-------
- 0 | pmic_temp
- 1 | batt_v
- 2 | batt_chrg_i
- 3 | batt_dischrg_i
-
-AXP813
-------
- 0 | pmic_temp
- 1 | gpio0_v
- 2 | batt_v
- 3 | batt_chrg_i
- 4 | batt_dischrg_i
diff --git a/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt b/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt
deleted file mode 100644
index 7b1b1e4..0000000
--- a/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-* Broadcom's IPROC Static ADC controller
-
-Broadcom iProc ADC controller has 8 channels 10bit ADC.
-Allows user to convert analog input voltage values to digital.
-
-Required properties:
-
-- compatible: Must be "brcm,iproc-static-adc"
-
-- adc-syscon: Handler of syscon node defining physical base address of the
- controller and length of memory mapped region.
-
-- #io-channel-cells = <1>; As ADC has multiple outputs
- refer to Documentation/devicetree/bindings/iio/iio-bindings.txt for details.
-
-- io-channel-ranges:
- refer to Documentation/devicetree/bindings/iio/iio-bindings.txt for details.
-
-- clocks: Clock used for this block.
-
-- clock-names: Clock name should be given as tsc_clk.
-
-- interrupts: interrupt line number.
-
-For example:
-
- ts_adc_syscon: ts_adc_syscon@180a6000 {
- compatible = "brcm,iproc-ts-adc-syscon","syscon";
- reg = <0x180a6000 0xc30>;
- };
-
- adc: adc@180a6000 {
- compatible = "brcm,iproc-static-adc";
- adc-syscon = <&ts_adc_syscon>;
- #io-channel-cells = <1>;
- io-channel-ranges;
- clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
- clock-names = "tsc_clk";
- interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.yaml b/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.yaml
new file mode 100644
index 0000000..c562d25
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/brcm,iproc-static-adc.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/brcm,iproc-static-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom's IPROC Static ADC controller
+
+maintainers:
+ - Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
+
+description: |
+ Broadcom iProc ADC controller has 8 10bit channels
+
+properties:
+ compatible:
+ const: brcm,iproc-static-adc
+
+ adc-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ syscon node defining physical base address of the controller and length
+ of memory mapped region.
+
+ "#io-channel-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: tsc_clk
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - adc-syscon
+ - "#io-channel-cells"
+ - clocks
+ - clock-names
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm-cygnus.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ts_adc_syscon: ts_adc_syscon@180a6000 {
+ compatible = "brcm,iproc-ts-adc-syscon","syscon";
+ reg = <0x180a6000 0xc30>;
+ };
+
+ adc {
+ compatible = "brcm,iproc-static-adc";
+ adc-syscon = <&ts_adc_syscon>;
+ #io-channel-cells = <1>;
+ clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
+ clock-names = "tsc_clk";
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt b/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
deleted file mode 100644
index 27544bd..0000000
--- a/Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Bindings for ADC envelope detector using a DAC and a comparator
-
-The DAC is used to find the peak level of an alternating voltage input
-signal by a binary search using the output of a comparator wired to
-an interrupt pin. Like so:
- _
- | \
- input +------>-------|+ \
- | \
- .-------. | }---.
- | | | / |
- | dac|-->--|- / |
- | | |_/ |
- | | |
- | | |
- | irq|------<-------'
- | |
- '-------'
-
-Required properties:
-- compatible: Should be "axentia,tse850-envelope-detector"
-- io-channels: Channel node of the dac to be used for comparator input.
-- io-channel-names: Should be "dac".
-- interrupt specification for one client interrupt,
- see ../../interrupt-controller/interrupts.txt for details.
-- interrupt-names: Should be "comp".
-
-Example:
-
- &i2c {
- dpot: mcp4651-104@28 {
- compatible = "microchip,mcp4651-104";
- reg = <0x28>;
- #io-channel-cells = <1>;
- };
- };
-
- dac: dac {
- compatible = "dpot-dac";
- vref-supply = <®_3v3>;
- io-channels = <&dpot 0>;
- io-channel-names = "dpot";
- #io-channel-cells = <1>;
- };
-
- envelope-detector {
- compatible = "axentia,tse850-envelope-detector";
- io-channels = <&dac 0>;
- io-channel-names = "dac";
-
- interrupt-parent = <&gpio>;
- interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
- interrupt-names = "comp";
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml b/Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml
new file mode 100644
index 0000000..296d545
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/envelope-detector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADC envelope detector using a DAC and a comparator
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ The DAC is used to find the peak level of an alternating voltage input
+ signal by a binary search using the output of a comparator wired to
+ an interrupt pin. Like so:
+ _
+ | \
+ input +------>-------|+ \
+ | \
+ .-------. | }---.
+ | | | / |
+ | dac|-->--|- / |
+ | | |_/ |
+ | | |
+ | | |
+ | irq|------<-------'
+ | |
+ '-------'
+
+properties:
+ compatible:
+ const: axentia,tse850-envelope-detector
+
+ io-channels:
+ maxItems: 1
+ description: Channel node of the dac to be used for comparator input.
+
+ io-channel-names:
+ const: dac
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: comp
+
+required:
+ - compatible
+ - io-channels
+ - io-channel-names
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dpot: dpot@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+ };
+
+ dac: dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&gpio>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "comp";
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
index 6a991e9..2716d4e 100644
--- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
@@ -17,8 +17,7 @@
- lltc,ltc2496
vref-supply:
- description: phandle to an external regulator providing the reference voltage
- $ref: /schemas/types.yaml#/definitions/phandle
+ description: Power supply for the reference voltage
reg:
description: spi chipselect number according to the usual spi bindings
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
new file mode 100644
index 0000000..46b7747
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/maxim,max1027.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX1027 and similar ADCs
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+ - Philippe Reynes <tremyfr@yahoo.fr>
+
+description: |
+ 300ks/s SPI ADCs with temperature sensors.
+
+properties:
+ compatible:
+ enum:
+ # 10-bit 8 channels
+ - maxim,max1027
+ # 10-bit 12 channels
+ - maxim,max1029
+ # 10-bit 16 channels
+ - maxim,max1031
+ # 12-bit 8 channels
+ - maxim,max1227
+ # 12-bit 12 channels
+ - maxim,max1229
+ # 12-bit 16 channels
+ - maxim,max1231
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 10000000
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ maxadc: adc@0 {
+ compatible = "maxim,max1027";
+ reg = <0>;
+ #io-channel-cells = <1>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <15 IRQ_TYPE_EDGE_RISING>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
new file mode 100644
index 0000000..5b21a9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/mediatek,mt2701-auxadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek AUXADC - ADC on Mediatek mobile SoC (mt65xx/mt81xx/mt27xx)
+
+maintainers:
+ - Zhiyong Tao <zhiyong.tao@mediatek.com>
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description: |
+ The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
+ in some Mediatek SoCs which among other things measures the temperatures
+ in the SoC. It can be used directly with register accesses, but it is also
+ used by thermal controller which reads the temperatures from the AUXADC
+ directly via its own bus interface. See mediatek-thermal bindings
+ for the Thermal Controller which holds a phandle to the AUXADC.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-auxadc
+ - mediatek,mt2712-auxadc
+ - mediatek,mt6765-auxadc
+ - mediatek,mt7622-auxadc
+ - mediatek,mt8173-auxadc
+ - items:
+ - enum:
+ - mediatek,mt7623-auxadc
+ - const: mediatek,mt2701-auxadc
+ - items:
+ - enum:
+ - mediatek,mt8183-auxadc
+ - mediatek,mt8516-auxadc
+ - const: mediatek,mt8173-auxadc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: main
+
+ "#io-channel-cells":
+ const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#io-channel-cells"
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ adc@11001000 {
+ compatible = "mediatek,mt8183-auxadc",
+ "mediatek,mt8173-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml
new file mode 100644
index 0000000..db4e361
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6360-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT6360 and similar ADCs
+
+maintainers:
+ - Gene Chen <gene_chen@richtek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt6360-adc
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - "#io-channel-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ adc {
+ compatible = "mediatek,mt6360-adc";
+ #io-channel-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
deleted file mode 100644
index 78c06e05..0000000
--- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc (mt65xx/mt81xx/mt27xx)
-===============
-
-The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
-in some Mediatek SoCs which among other things measures the temperatures
-in the SoC. It can be used directly with register accesses, but it is also
-used by thermal controller which reads the temperatures from the AUXADC
-directly via its own bus interface. See
-Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
-for the Thermal Controller which holds a phandle to the AUXADC.
-
-Required properties:
- - compatible: Should be one of:
- - "mediatek,mt2701-auxadc": For MT2701 family of SoCs
- - "mediatek,mt2712-auxadc": For MT2712 family of SoCs
- - "mediatek,mt6765-auxadc": For MT6765 family of SoCs
- - "mediatek,mt7622-auxadc": For MT7622 family of SoCs
- - "mediatek,mt8173-auxadc": For MT8173 family of SoCs
- - "mediatek,mt8183-auxadc", "mediatek,mt8173-auxadc": For MT8183 family of SoCs
- - reg: Address range of the AUXADC unit.
- - clocks: Should contain a clock specifier for each entry in clock-names
- - clock-names: Should contain "main".
- - #io-channel-cells: Should be 1, see ../iio-bindings.txt
-
-Example:
-
-auxadc: adc@11001000 {
- compatible = "mediatek,mt2701-auxadc";
- reg = <0 0x11001000 0 0x1000>;
- clocks = <&pericfg CLK_PERI_AUXADC>;
- clock-names = "main";
- #io-channel-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
deleted file mode 100644
index 4bb9a86..0000000
--- a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-* Palmas general purpose ADC IP block devicetree bindings
-
-Channels list:
- 0 battery type
- 1 battery temp NTC (optional current source)
- 2 GP
- 3 temp (with ext. diode, optional current source)
- 4 GP
- 5 GP
- 6 VBAT_SENSE
- 7 VCC_SENSE
- 8 Backup Battery voltage
- 9 external charger (VCHG)
- 10 VBUS
- 11 DC-DC current probe (how does this work?)
- 12 internal die temp
- 13 internal die temp
- 14 USB ID pin voltage
- 15 test network
-
-Required properties:
-- compatible : Must be "ti,palmas-gpadc".
-- #io-channel-cells: Should be set to <1>.
-
-Optional sub-nodes:
-ti,channel0-current-microamp: Channel 0 current in uA.
- Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
-ti,channel3-current-microamp: Channel 3 current in uA.
- Values are rounded to derive 0uA, 10uA, 400uA, 800uA.
-ti,enable-extended-delay: Enable extended delay.
-
-Example:
-
-pmic {
- compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
- ...
- gpadc {
- compatible = "ti,palmas-gpadc";
- interrupts = <18 0
- 16 0
- 17 0>;
- #io-channel-cells = <1>;
- ti,channel0-current-microamp = <5>;
- ti,channel3-current-microamp = <10>;
- };
- };
- ...
-};
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
new file mode 100644
index 0000000..d186b713
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/qcom,pm8018-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's PM8xxx voltage XOADC
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description: |
+ The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Crystal
+ oscillator ADC) encompassing PM8018, PM8038, PM8058 and PM8921.
+
+properties:
+ compatible:
+ enum:
+ - qcom,pm8018-adc
+ - qcom,pm8038-adc
+ - qcom,pm8058-adc
+ - qcom,pm8921-adc
+
+ reg:
+ maxItems: 1
+ description:
+ ADC base address in the PMIC, typically 0x197.
+
+ xoadc-ref-supply:
+ description:
+ The reference voltage may vary with PMIC variant but is typically
+ something like 2.2 or 1.8V.
+
+ interrupts:
+ maxItems: 1
+
+ "#address-cells":
+ const: 2
+ description:
+ The first cell is the prescaler (on PM8058) or premux (on PM8921)
+ with two valid bits so legal values are 0x00, 0x01 or 0x02.
+ The second cell is the main analog mux setting (0x00..0x0f).
+ The combination of prescaler/premux and analog mux uniquely addresses
+ a hardware channel on all systems.
+
+ "#size-cells":
+ const: 0
+
+ "#io-channel-cells":
+ const: 2
+ description:
+ The cells are precaler or premux followed by the analog muxing line.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#io-channel-cells"
+ - "#address-cells"
+ - "#size-cells"
+ - adc-channel@c
+ - adc-channel@d
+ - adc-channel@f
+
+patternProperties:
+ "^(adc-channel@)[0-9a-f]$":
+ type: object
+ description: |
+ ADC channel specific configuration.
+ Note that channels c, d and f must be present for calibration.
+ These three nodes are used for absolute and ratiometric calibration
+ and only need to have these reg values: they are by hardware definition
+ 1:1 ratio converters that sample 625, 1250 and 0 milliV and create
+ an interpolation calibration for all other ADCs.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ qcom,decimation:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ This parameter is used to decrease the ADC sampling rate.
+ Quicker measurements can be made by reducing the decimation ratio.
+ Valid values are 512, 1024, 2048, 4096.
+ If the property is not found, a default value of 512 will be used.
+
+ qcom,ratiometric:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Channel calibration type. If this property is specified
+ VADC will use a special voltage references for channel
+ calibration. The available references are specified in the
+ as a u32 value setting (see below) and it is compulsory
+ to also specify this reference if ratiometric calibration
+ is selected.
+
+ If the property is not found, the channel will be
+ calibrated with the 0.625V and 1.25V reference channels, also
+ known as an absolute calibration.
+
+ The reference voltage pairs when using ratiometric calibration:
+ 0 = XO_IN/XOADC_GND
+ 1 = PMIC_IN/XOADC_GND
+ 2 = PMIC_IN/BMS_CSP
+ 3 (invalid)
+ 4 = XOADC_GND/XOADC_GND
+ 5 = XOADC_VREF/XOADC_GND
+
+ additionalProperties: false
+
+ required:
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@197 {
+ compatible = "qcom,pm8058-adc";
+ reg = <0x197>;
+ interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ #io-channel-cells = <2>;
+
+ vcoin: adc-channel@0 {
+ reg = <0x00 0x00>;
+ };
+ vbat: adc-channel@1 {
+ reg = <0x00 0x01>;
+ };
+ dcin: adc-channel@2 {
+ reg = <0x00 0x02>;
+ };
+ ichg: adc-channel@3 {
+ reg = <0x00 0x03>;
+ };
+ vph_pwr: adc-channel@4 {
+ reg = <0x00 0x04>;
+ };
+ usb_vbus: adc-channel@a {
+ reg = <0x00 0x0a>;
+ };
+ die_temp: adc-channel@b {
+ reg = <0x00 0x0b>;
+ };
+ ref_625mv: adc-channel@c {
+ reg = <0x00 0x0c>;
+ };
+ ref_1250mv: adc-channel@d {
+ reg = <0x00 0x0d>;
+ };
+ ref_325mv: adc-channel@e {
+ reg = <0x00 0x0e>;
+ };
+ ref_muxoff: adc-channel@f {
+ reg = <0x00 0x0f>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
deleted file mode 100644
index 3ae0612..0000000
--- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-Qualcomm's PM8xxx voltage XOADC
-
-The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Crystal
-oscillator ADC) encompassing PM8018, PM8038, PM8058 and PM8921.
-
-Required properties:
-
-- compatible: should be one of:
- "qcom,pm8018-adc"
- "qcom,pm8038-adc"
- "qcom,pm8058-adc"
- "qcom,pm8921-adc"
-
-- reg: should contain the ADC base address in the PMIC, typically
- 0x197.
-
-- xoadc-ref-supply: should reference a regulator that can supply
- a reference voltage on demand. The reference voltage may vary
- with PMIC variant but is typically something like 2.2 or 1.8V.
-
-The following required properties are standard for IO channels, see
-iio-bindings.txt for more details, but notice that this particular
-ADC has a special addressing scheme that require two cells for
-identifying each ADC channel:
-
-- #address-cells: should be set to <2>, the first cell is the
- prescaler (on PM8058) or premux (on PM8921) with two valid bits
- so legal values are 0x00, 0x01 or 0x02. The second cell
- is the main analog mux setting (0x00..0x0f). The combination
- of prescaler/premux and analog mux uniquely addresses a hardware
- channel on all systems.
-
-- #size-cells: should be set to <0>
-
-- #io-channel-cells: should be set to <2>, again the cells are
- precaler or premux followed by the analog muxing line.
-
-- interrupts: should refer to the parent PMIC interrupt controller
- and reference the proper ADC interrupt.
-
-Required subnodes:
-
-The ADC channels are configured as subnodes of the ADC.
-
-Since some of them are used for calibrating the ADC, these nodes are
-compulsory:
-
-adc-channel@c {
- reg = <0x00 0x0c>;
-};
-
-adc-channel@d {
- reg = <0x00 0x0d>;
-};
-
-adc-channel@f {
- reg = <0x00 0x0f>;
-};
-
-These three nodes are used for absolute and ratiometric calibration
-and only need to have these reg values: they are by hardware definition
-1:1 ratio converters that sample 625, 1250 and 0 milliV and create
-an interpolation calibration for all other ADCs.
-
-Optional subnodes: any channels other than channels [0x00 0x0c],
-[0x00 0x0d] and [0x00 0x0f] are optional.
-
-Required channel node properties:
-
-- reg: should contain the hardware channel number in the range
- 0 .. 0xff (8 bits).
-
-Optional channel node properties:
-
-- qcom,decimation:
- Value type: <u32>
- Definition: This parameter is used to decrease the ADC sampling rate.
- Quicker measurements can be made by reducing the decimation ratio.
- Valid values are 512, 1024, 2048, 4096.
- If the property is not found, a default value of 512 will be used.
-
-- qcom,ratiometric:
- Value type: <u32>
- Definition: Channel calibration type. If this property is specified
- VADC will use a special voltage references for channel
- calibration. The available references are specified in the
- as a u32 value setting (see below) and it is compulsory
- to also specify this reference if ratiometric calibration
- is selected.
-
- If the property is not found, the channel will be
- calibrated with the 0.625V and 1.25V reference channels, also
- known as an absolute calibration.
- The reference voltage pairs when using ratiometric calibration:
- 0 = XO_IN/XOADC_GND
- 1 = PMIC_IN/XOADC_GND
- 2 = PMIC_IN/BMS_CSP
- 3 (invalid)
- 4 = XOADC_GND/XOADC_GND
- 5 = XOADC_VREF/XOADC_GND
-
-Example:
-
-xoadc: xoadc@197 {
- compatible = "qcom,pm8058-adc";
- reg = <0x197>;
- interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
- #address-cells = <2>;
- #size-cells = <0>;
- #io-channel-cells = <2>;
-
- vcoin: adc-channel@0 {
- reg = <0x00 0x00>;
- };
- vbat: adc-channel@1 {
- reg = <0x00 0x01>;
- };
- dcin: adc-channel@2 {
- reg = <0x00 0x02>;
- };
- ichg: adc-channel@3 {
- reg = <0x00 0x03>;
- };
- vph_pwr: adc-channel@4 {
- reg = <0x00 0x04>;
- };
- usb_vbus: adc-channel@a {
- reg = <0x00 0x0a>;
- };
- die_temp: adc-channel@b {
- reg = <0x00 0x0b>;
- };
- ref_625mv: adc-channel@c {
- reg = <0x00 0x0c>;
- };
- ref_1250mv: adc-channel@d {
- reg = <0x00 0x0d>;
- };
- ref_325mv: adc-channel@e {
- reg = <0x00 0x0e>;
- };
- ref_muxoff: adc-channel@f {
- reg = <0x00 0x0f>;
- };
-};
-
-/* IIO client node */
-iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = <&xoadc 0x00 0x01>, /* Battery */
- <&xoadc 0x00 0x02>, /* DC in (charger) */
- <&xoadc 0x00 0x04>, /* VPH the main system voltage */
- <&xoadc 0x00 0x0b>, /* Die temperature */
- <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
- <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
- <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
-};
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
deleted file mode 100644
index 4e36d6e..0000000
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Qualcomm's SPMI PMIC current ADC
-
-QPNP PMIC current ADC (IADC) provides interface to clients to read current.
-A 16 bit ADC is used for current measurements. IADC can measure the current
-through an external resistor (channel 1) or internal (built-in) resistor
-(channel 0). When using an external resistor it is to be described by
-qcom,external-resistor-micro-ohms property.
-
-IADC node:
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Should contain "qcom,spmi-iadc".
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: IADC base address and length in the SPMI PMIC register map
-
-- interrupts:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: End of ADC conversion.
-
-- qcom,external-resistor-micro-ohms:
- Usage: optional
- Value type: <u32>
- Definition: Sense resister value in micro Ohm.
- If not defined value of 10000 micro Ohms will be used.
-
-Example:
- /* IADC node */
- pmic_iadc: iadc@3600 {
- compatible = "qcom,spmi-iadc";
- reg = <0x3600 0x100>;
- interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
- qcom,external-resistor-micro-ohms = <10000>;
- #io-channel-cells = <1>;
- };
-
- /* IIO client node */
- bat {
- io-channels = <&pmic_iadc 0>;
- io-channel-names = "iadc";
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
new file mode 100644
index 0000000..27e3108
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/qcom,spmi-iadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's SPMI PMIC current ADC
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ QPNP PMIC current ADC (IADC) provides interface to clients to read current.
+ A 16 bit ADC is used for current measurements. IADC can measure the current
+ through an external resistor (channel 1) or internal (built-in) resistor
+ (channel 0). When using an external resistor it is to be described by
+ qcom,external-resistor-micro-ohms property.
+
+properties:
+ compatible:
+ const: qcom,spmi-iadc
+
+ reg:
+ description: IADC base address and length in the SPMI PMIC register map
+ maxItems: 1
+
+ qcom,external-resistor-micro-ohms:
+ description:
+ Sensor resistor value. If not defined value of 10000 micro Ohms
+ will be used.
+
+ interrupts:
+ maxItems: 1
+ description:
+ End of conversion interrupt.
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spmi_bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic_iadc: adc@3600 {
+ compatible = "qcom,spmi-iadc";
+ reg = <0x3600 0x100>;
+ interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
+ qcom,external-resistor-micro-ohms = <10000>;
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
index 7f4f827c..95cc705b 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
@@ -48,8 +48,6 @@
description:
End of conversion interrupt.
- io-channel-ranges: true
-
required:
- compatible
- reg
@@ -249,7 +247,6 @@
#address-cells = <1>;
#size-cells = <0>;
#io-channel-cells = <1>;
- io-channel-ranges;
/* Channel node */
adc-chan@39 {
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt b/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
deleted file mode 100644
index df5b9f2..0000000
--- a/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-* Renesas R-Car GyroADC device driver
-
-The GyroADC block is a reduced SPI block with up to 8 chipselect lines,
-which supports the SPI protocol of a selected few SPI ADCs. The SPI ADCs
-are sampled by the GyroADC block in a round-robin fashion and the result
-presented in the GyroADC registers.
-
-Required properties:
-- compatible: Should be "<soc-specific>", "renesas,rcar-gyroadc".
- The <soc-specific> should be one of:
- renesas,r8a7791-gyroadc - for the GyroADC block present
- in r8a7791 SoC
- renesas,r8a7792-gyroadc - for the GyroADC with interrupt
- block present in r8a7792 SoC
-- reg: Address and length of the register set for the device
-- clocks: References to all the clocks specified in the clock-names
- property as specified in
- Documentation/devicetree/bindings/clock/clock-bindings.txt.
-- clock-names: Shall contain "fck". The "fck" is the GyroADC block clock.
-- power-domains: Must contain a reference to the PM domain, if available.
-- #address-cells: Should be <1> (setting for the subnodes) for all ADCs
- except for "fujitsu,mb88101a". Should be <0> (setting for
- only subnode) for "fujitsu,mb88101a".
-- #size-cells: Should be <0> (setting for the subnodes)
-
-Sub-nodes:
-You must define subnode(s) which select the connected ADC type and reference
-voltage for the GyroADC channels.
-
-Required properties for subnodes:
-- compatible: Should be either of:
- "fujitsu,mb88101a"
- - Fujitsu MB88101A compatible mode,
- 12bit sampling, up to 4 channels can be sampled in
- round-robin fashion. One Fujitsu chip supplies four
- GyroADC channels with data as it contains four ADCs
- on the chip and thus for 4-channel operation, single
- MB88101A is required. The Cx chipselect lines of the
- MB88101A connect directly to two CHS lines of the
- GyroADC, no demuxer is required. The data out line
- of each MB88101A connects to a shared input pin of
- the GyroADC.
- "ti,adcs7476" or "ti,adc121" or "adi,ad7476"
- - TI ADCS7476 / TI ADC121 / ADI AD7476 compatible mode,
- 15bit sampling, up to 8 channels can be sampled in
- round-robin fashion. One TI/ADI chip supplies single
- ADC channel with data, thus for 8-channel operation,
- 8 chips are required. A 3:8 chipselect demuxer is
- required to connect the nCS line of the TI/ADI chips
- to the GyroADC, while MISO line of each TI/ADI ADC
- connects to a shared input pin of the GyroADC.
- "maxim,max1162" or "maxim,max11100"
- - Maxim MAX1162 / Maxim MAX11100 compatible mode,
- 16bit sampling, up to 8 channels can be sampled in
- round-robin fashion. One Maxim chip supplies single
- ADC channel with data, thus for 8-channel operation,
- 8 chips are required. A 3:8 chipselect demuxer is
- required to connect the nCS line of the MAX chips
- to the GyroADC, while MISO line of each Maxim ADC
- connects to a shared input pin of the GyroADC.
-- reg: Should be the number of the analog input. Should be present
- for all ADCs except "fujitsu,mb88101a".
-- vref-supply: Reference to the channel reference voltage regulator.
-
-Example:
- vref_max1162: regulator-vref-max1162 {
- compatible = "regulator-fixed";
-
- regulator-name = "MAX1162 Vref";
- regulator-min-microvolt = <4096000>;
- regulator-max-microvolt = <4096000>;
- };
-
- adc@e6e54000 {
- compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
- reg = <0 0xe6e54000 0 64>;
- clocks = <&mstp9_clks R8A7791_CLK_GYROADC>;
- clock-names = "fck";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
-
- pinctrl-0 = <&adc_pins>;
- pinctrl-names = "default";
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- adc@0 {
- reg = <0>;
- compatible = "maxim,max1162";
- vref-supply = <&vref_max1162>;
- };
-
- adc@1 {
- reg = <1>;
- compatible = "maxim,max1162";
- vref-supply = <&vref_max1162>;
- };
- };
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
new file mode 100644
index 0000000..c115e2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/renesas,rcar-gyroadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car GyroADC
+
+maintainers:
+ - Marek Vasut <marek.vasut+renesas@gmail.com>
+
+description: |
+ The GyroADC block is a reduced SPI block with up to 8 chipselect lines,
+ which supports the SPI protocol of a selected few SPI ADCs. The SPI ADCs
+ are sampled by the GyroADC block in a round-robin fashion and the result
+ presented in the GyroADC registers.
+ The ADC bindings should match with that of the devices connected to a
+ full featured SPI bus.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a7791-gyroadc
+ - renesas,r8a7792-gyroadc
+ - const: renesas,rcar-gyroadc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: fck
+
+ power-domains: true
+
+ resets: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#address-cells"
+ - "#size-cells"
+
+patternProperties:
+ "@[0-7]$":
+ type: object
+ properties:
+ compatible:
+ description: |
+ fujitsu,mb88101a
+ - Fujitsu MB88101A compatible mode,
+ 12bit sampling, up to 4 channels can be sampled in round-robin
+ fashion. One Fujitsu chip supplies four GyroADC channels with
+ data as it contains four ADCs on the chip and thus for 4-channel
+ operation, single MB88101A is required. The Cx chipselect lines
+ of the MB88101A connect directly to two CHS lines of the GyroADC,
+ no demuxer is required. The data out line of each MB88101A
+ connects to a shared input pin of the GyroADC.
+ ti,adcs7476 or ti,adc121 or adi,ad7476
+ - TI ADCS7476 / TI ADC121 / ADI AD7476 compatible mode, 15bit
+ sampling, up to 8 channels can be sampled in round-robin
+ fashion. One TI/ADI chip supplies single ADC channel with data,
+ thus for 8-channel operation, 8 chips are required.
+ A 3:8 chipselect demuxer is required to connect the nCS line
+ of the TI/ADI chips to the GyroADC, while MISO line of each
+ TI/ADI ADC connects to a shared input pin of the GyroADC.
+ maxim,max1162 or maxim,max11100
+ - Maxim MAX1162 / Maxim MAX11100 compatible mode, 16bit sampling,
+ up to 8 channels can be sampled in round-robin fashion. One
+ Maxim chip supplies single ADC channel with data, thus for
+ 8-channel operation, 8 chips are required.
+ A 3:8 chipselect demuxer is required to connect the nCS line
+ of the MAX chips to the GyroADC, while MISO line of each Maxim
+ ADC connects to a shared input pin of the GyroADC.
+ enum:
+ - adi,7476
+ - fujitsu,mb88101a
+ - maxim,max1162
+ - maxim,max11100
+ - ti,adcs7476
+ - ti,adc121
+
+ reg:
+ minimum: 0
+ maximum: 7
+
+ vref-supply: true
+
+ additionalProperties: false
+
+ required:
+ - compatible
+ - reg
+ - vref-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7791-clock.h>
+ #include <dt-bindings/power/r8a7791-sysc.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ adc@e6e54000 {
+ compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
+ reg = <0 0xe6e54000 0 64>;
+ clocks = <&mstp9_clks R8A7791_CLK_GYROADC>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+
+ pinctrl-0 = <&adc_pins>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ reg = <0>;
+ compatible = "maxim,max1162";
+ vref-supply = <&vref_max1162>;
+ };
+
+ adc@1 {
+ reg = <1>;
+ compatible = "maxim,max1162";
+ vref-supply = <&vref_max1162>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
index 5ebb0ab..c65921e 100644
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
@@ -49,8 +49,6 @@
"#io-channel-cells":
const: 1
- io-channel-ranges: true
-
vdd-supply: true
samsung,syscon-phandle:
@@ -130,7 +128,6 @@
reg = <0x12d10000 0x100>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
- io-channel-ranges;
clocks = <&clock 303>;
clock-names = "adc";
@@ -156,7 +153,6 @@
reg = <0x126C0000 0x100>;
interrupts = <0 137 0>;
#io-channel-cells = <1>;
- io-channel-ranges;
clocks = <&cmu CLK_TSADC>,
<&cmu CLK_SCLK_TSADC>;
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
index d61bc01..6f2398c 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
@@ -199,8 +199,6 @@
description:
From common IIO binding. Used to pipe external sigma delta
modulator or internal ADC output to DFSDM channel.
- This is not required for "st,stm32-dfsdm-pdm" compatibility as
- PDM microphone is binded in Audio DT node.
required:
- io-channels
@@ -235,6 +233,10 @@
description: child node
properties:
+ compatible:
+ enum:
+ - st,stm32h7-dfsdm-dai
+
"#sound-dai-cells":
const: 0
@@ -244,6 +246,7 @@
modulator or internal ADC output to DFSDM channel.
required:
+ - compatible
- "#sound-dai-cells"
- io-channels
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml
new file mode 100644
index 0000000..1a113b30
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,adc084s021.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ADC084S021 ADC
+
+maintainers:
+ - Mårten Lindahl <martenli@axis.com>
+
+description: |
+ 8 bit ADC with 4 channels
+
+properties:
+ compatible:
+ const: ti,adc084s021
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+ vref-supply:
+ description: External reference, needed to establish input scaling
+
+ spi-cpol: true
+ spi-cpha: true
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+ - spi-cpol
+ - spi-cpha
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "ti,adc084s021";
+ reg = <0>;
+ vref-supply = <&adc_vref>;
+ spi-cpol;
+ spi-cpha;
+ spi-max-frequency = <16000000>;
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml
new file mode 100644
index 0000000..9f5e964
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads124s08.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' ads124s08 and ads124s06 ADC chip
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,ads124s06
+ - ti,ads124s08
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+ spi-cpha: true
+
+ reset-gpios:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "ti,ads124s08";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpha;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml
new file mode 100644
index 0000000..692dacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,palmas-gpadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Palmas general purpose ADC IP block devicetree bindings
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description: |
+ This ADC is often used to provide channels via the io-channels
+ consumer framework.
+ Channels list:
+ 0 battery type
+ 1 battery temp NTC (optional current source)
+ 2 GP
+ 3 temp (with ext. diode, optional current source)
+ 4 GP
+ 5 GP
+ 6 VBAT_SENSE
+ 7 VCC_SENSE
+ 8 Backup Battery voltage
+ 9 external charger (VCHG)
+ 10 VBUS
+ 11 DC-DC current probe (how does this work?)
+ 12 internal die temp
+ 13 internal die temp
+ 14 USB ID pin voltage
+ 15 test network
+
+properties:
+ compatible:
+ const: ti,palmas-gpadc
+
+ interrupts:
+ minItems: 1
+ maxItems: 3
+
+ "#io-channel-cells":
+ const: 1
+
+ ti,channel0-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Channel 0 current in uA.
+ enum:
+ - 0
+ - 5
+ - 15
+ - 20
+
+ ti,channel3-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Channel 3 current in uA.
+ enum:
+ - 0
+ - 10
+ - 400
+ - 800
+
+ ti,enable-extended-delay:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enable extended delay.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#io-channel-cells"
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ pmic {
+ compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+ adc {
+ compatible = "ti,palmas-gpadc";
+ interrupts = <18 0
+ 16 0
+ 17 0>;
+ #io-channel-cells = <1>;
+ ti,channel0-current-microamp = <5>;
+ ti,channel3-current-microamp = <10>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt b/Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt
deleted file mode 100644
index 4259e50..0000000
--- a/Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Texas Instruments' ADC084S021
-
-Required properties:
- - compatible : Must be "ti,adc084s021"
- - reg : SPI chip select number for the device
- - vref-supply : The regulator supply for ADC reference voltage
- - spi-cpol : Per spi-bus bindings
- - spi-cpha : Per spi-bus bindings
- - spi-max-frequency : Per spi-bus bindings
-
-Example:
-adc@0 {
- compatible = "ti,adc084s021";
- reg = <0>;
- vref-supply = <&adc_vref>;
- spi-cpol;
- spi-cpha;
- spi-max-frequency = <16000000>;
-};
diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads124s08.txt b/Documentation/devicetree/bindings/iio/adc/ti-ads124s08.txt
deleted file mode 100644
index ecf807b..0000000
--- a/Documentation/devicetree/bindings/iio/adc/ti-ads124s08.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Texas Instruments' ads124s08 and ads124s06 ADC chip
-
-Required properties:
- - compatible :
- "ti,ads124s08"
- "ti,ads124s06"
- - reg : spi chip select number for the device
-
-Recommended properties:
- - spi-max-frequency : Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
- - spi-cpha : Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
- - reset-gpios : GPIO pin used to reset the device.
-
-Example:
-adc@0 {
- compatible = "ti,ads124s08";
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpha;
- reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml
new file mode 100644
index 0000000..5ccbb1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/x-powers,axp209-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: X-Powers AXP ADC bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+
+description: |
+ ADC is frequently used as a provider to consumers of the ADC channels.
+ Device is a child of an axp209 multifunction device
+ ADC channels and their indexes per variant:
+
+ AXP209
+ ------
+ 0 | acin_v
+ 1 | acin_i
+ 2 | vbus_v
+ 3 | vbus_i
+ 4 | pmic_temp
+ 5 | gpio0_v
+ 6 | gpio1_v
+ 7 | ipsout_v
+ 8 | batt_v
+ 9 | batt_chrg_i
+ 10 | batt_dischrg_i
+
+ AXP22x
+ ------
+ 0 | pmic_temp
+ 1 | batt_v
+ 2 | batt_chrg_i
+ 3 | batt_dischrg_i
+
+ AXP813
+ ------
+ 0 | pmic_temp
+ 1 | gpio0_v
+ 2 | batt_v
+ 3 | batt_chrg_i
+ 4 | batt_dischrg_i
+
+
+properties:
+ compatible:
+ enum:
+ - x-powers,axp209-adc
+ - x-powers,axp221-adc
+ - x-powers,axp813-adc
+
+ "#io-channel-cells":
+ const: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ axp221 {
+ adc {
+ compatible = "x-powers,axp221-adc";
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
deleted file mode 100644
index 821b61b..0000000
--- a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Current Sense Amplifier
-=======================
-
-When an io-channel measures the output voltage from a current sense
-amplifier, the interesting measurement is almost always the current
-through the sense resistor, not the voltage output. This binding
-describes such a current sense circuit.
-
-Required properties:
-- compatible : "current-sense-amplifier"
-- io-channels : Channel node of a voltage io-channel.
-- sense-resistor-micro-ohms : The sense resistance in microohms.
-
-Optional properties:
-- sense-gain-mult: Amplifier gain multiplier. The default is <1>.
-- sense-gain-div: Amplifier gain divider. The default is <1>.
-
-Example:
-
-sysi {
- compatible = "current-sense-amplifier";
- io-channels = <&tiadc 0>;
-
- sense-resistor-micro-ohms = <20000>;
- sense-gain-mul = <50>;
-};
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
new file mode 100644
index 0000000..527501c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/afe/current-sense-amplifier.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Current Sense Amplifier
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ When an io-channel measures the output voltage from a current sense
+ amplifier, the interesting measurement is almost always the current
+ through the sense resistor, not the voltage output. This binding
+ describes such a current sense circuit.
+
+properties:
+ compatible:
+ const: current-sense-amplifier
+
+ io-channels:
+ maxItems: 1
+ description: |
+ Channel node of a voltage io-channel.
+
+ sense-resistor-micro-ohms:
+ description: The sense resistance.
+
+ sense-gain-mult:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Amplifier gain multiplier. The default is <1>.
+
+ sense-gain-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Amplifier gain divider. The default is <1>.
+
+required:
+ - compatible
+ - io-channels
+ - sense-resistor-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ sysi {
+ compatible = "current-sense-amplifier";
+ io-channels = <&tiadc 0>;
+
+ sense-resistor-micro-ohms = <20000>;
+ sense-gain-mult = <50>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
deleted file mode 100644
index 0f67108..0000000
--- a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Current Sense Shunt
-===================
-
-When an io-channel measures the voltage over a current sense shunt,
-the interesting measurement is almost always the current through the
-shunt, not the voltage over it. This binding describes such a current
-sense circuit.
-
-Required properties:
-- compatible : "current-sense-shunt"
-- io-channels : Channel node of a voltage io-channel.
-- shunt-resistor-micro-ohms : The shunt resistance in microohms.
-
-Example:
-The system current is measured by measuring the voltage over a
-3.3 ohms shunt resistor.
-
-sysi {
- compatible = "current-sense-shunt";
- io-channels = <&tiadc 0>;
-
- /* Divide the voltage by 3300000/1000000 (or 3.3) for the current. */
- shunt-resistor-micro-ohms = <3300000>;
-};
-
-&i2c {
- tiadc: adc@48 {
- compatible = "ti,ads1015";
- reg = <0x48>;
- #io-channel-cells = <1>;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- channel@0 { /* IN0,IN1 differential */
- reg = <0>;
- ti,gain = <1>;
- ti,datarate = <4>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml
new file mode 100644
index 0000000..90439a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/afe/current-sense-shunt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Current Sense Shunt
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ When an io-channel measures the voltage over a current sense shunt,
+ the interesting measurement is almost always the current through the
+ shunt, not the voltage over it. This binding describes such a current
+ sense circuit.
+
+properties:
+ compatible:
+ const: current-sense-shunt
+
+ io-channels:
+ maxItems: 1
+ description: |
+ Channel node of a voltage io-channel.
+
+ shunt-resistor-micro-ohms:
+ description: The shunt resistance.
+
+required:
+ - compatible
+ - io-channels
+ - shunt-resistor-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ tiadc: adc@48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ #io-channel-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 { /* IN0,IN1 differential */
+ reg = <0>;
+ ti,gain = <1>;
+ ti,datarate = <4>;
+ };
+ };
+ };
+ sysi {
+ compatible = "current-sense-shunt";
+ io-channels = <&tiadc 0>;
+
+ /* Divide the voltage by 3300000/1000000 (or 3.3) for the current. */
+ shunt-resistor-micro-ohms = <3300000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.txt b/Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
deleted file mode 100644
index b452a84..0000000
--- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Voltage divider
-===============
-
-When an io-channel measures the midpoint of a voltage divider, the
-interesting voltage is often the voltage over the full resistance
-of the divider. This binding describes the voltage divider in such
-a curcuit.
-
- Vin ----.
- |
- .-----.
- | R |
- '-----'
- |
- +---- Vout
- |
- .-----.
- | Rout|
- '-----'
- |
- GND
-
-Required properties:
-- compatible : "voltage-divider"
-- io-channels : Channel node of a voltage io-channel measuring Vout.
-- output-ohms : Resistance Rout over which the output voltage is measured.
- See full-ohms.
-- full-ohms : Resistance R + Rout for the full divider. The io-channel
- is scaled by the Rout / (R + Rout) quotient.
-
-Example:
-The system voltage is circa 12V, but divided down with a 22/222
-voltage divider (R = 200 Ohms, Rout = 22 Ohms) and fed to an ADC.
-
-sysv {
- compatible = "voltage-divider";
- io-channels = <&maxadc 1>;
-
- /* Scale the system voltage by 22/222 to fit the ADC range. */
- output-ohms = <22>;
- full-ohms = <222>; /* 200 + 22 */
-};
-
-&spi {
- maxadc: adc@0 {
- compatible = "maxim,max1027";
- reg = <0>;
- #io-channel-cells = <1>;
- interrupt-parent = <&gpio5>;
- interrupts = <15 IRQ_TYPE_EDGE_RISING>;
- spi-max-frequency = <1000000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
new file mode 100644
index 0000000..df2589f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/afe/voltage-divider.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Voltage divider
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ When an io-channel measures the midpoint of a voltage divider, the
+ interesting voltage is often the voltage over the full resistance
+ of the divider. This binding describes the voltage divider in such
+ a curcuit.
+
+ Vin ----.
+ |
+ .-----.
+ | R |
+ '-----'
+ |
+ +---- Vout
+ |
+ .-----.
+ | Rout|
+ '-----'
+ |
+ GND
+
+
+properties:
+ compatible:
+ const: voltage-divider
+
+ io-channels:
+ maxItems: 1
+ description: |
+ Channel node of a voltage io-channel.
+
+ output-ohms:
+ description:
+ Resistance Rout over which the output voltage is measured. See full-ohms.
+
+ full-ohms:
+ description:
+ Resistance R + Rout for the full divider. The io-channel is scaled by
+ the Rout / (R + Rout) quotient.
+
+required:
+ - compatible
+ - io-channels
+ - output-ohms
+ - full-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ /*
+ * The system voltage is circa 12V, but divided down with a 22/222
+ * voltage divider (R = 200 Ohms, Rout = 22 Ohms) and fed to an ADC.
+ */
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ maxadc: adc@0 {
+ compatible = "maxim,max1027";
+ reg = <0>;
+ #io-channel-cells = <1>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <15 IRQ_TYPE_EDGE_RISING>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+ sysv {
+ compatible = "voltage-divider";
+ io-channels = <&maxadc 1>;
+
+ /* Scale the system voltage by 22/222 to fit the ADC range. */
+ output-ohms = <22>;
+ full-ohms = <222>; /* 200 + 22 */
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/chemical/bme680.txt b/Documentation/devicetree/bindings/iio/chemical/bme680.txt
deleted file mode 100644
index 7f3827c..0000000
--- a/Documentation/devicetree/bindings/iio/chemical/bme680.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-Bosch Sensortec BME680 pressure/temperature/humidity/voc sensors
-
-Required properties:
-- compatible: must be "bosch,bme680"
-
-Example:
-
-bme680@76 {
- compatible = "bosch,bme680";
- reg = <0x76>;
-};
diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,sgp30.txt b/Documentation/devicetree/bindings/iio/chemical/sensirion,sgp30.txt
deleted file mode 100644
index 5844ed5..0000000
--- a/Documentation/devicetree/bindings/iio/chemical/sensirion,sgp30.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* Sensirion SGP30/SGPC3 multi-pixel Gas Sensor
-
-Required properties:
-
- - compatible: must be one of
- "sensirion,sgp30"
- "sensirion,sgpc3"
- - reg: the I2C address of the sensor
-
-Example:
-
-gas@58 {
- compatible = "sensirion,sgp30";
- reg = <0x58>;
-};
diff --git a/Documentation/devicetree/bindings/iio/dac/ad5592r.txt b/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
deleted file mode 100644
index 989f96f..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ad5592r.txt
+++ /dev/null
@@ -1,155 +0,0 @@
-Analog Devices AD5592R/AD5593R DAC/ADC device driver
-
-Required properties for the AD5592R:
- - compatible: Must be "adi,ad5592r"
- - reg: SPI chip select number for the device
- - spi-max-frequency: Max SPI frequency to use (< 30000000)
- - spi-cpol: The AD5592R requires inverse clock polarity (CPOL) mode
-
-Required properties for the AD5593R:
- - compatible: Must be "adi,ad5593r"
- - reg: I2C address of the device
-
-Required properties for all supported chips:
- - #address-cells: Should be 1.
- - #size-cells: Should be 0.
- - channel nodes:
- Each child node represents one channel and has the following
- Required properties:
- * reg: Pin on which this channel is connected to.
- * adi,mode: Mode or function of this channel.
- Macros specifying the valid values
- can be found in <dt-bindings/iio/adi,ad5592r.h>.
-
- The following values are currently supported:
- * CH_MODE_UNUSED (the pin is unused)
- * CH_MODE_ADC (the pin is ADC input)
- * CH_MODE_DAC (the pin is DAC output)
- * CH_MODE_DAC_AND_ADC (the pin is DAC output
- but can be monitored by an ADC, since
- there is no disadvantage this
- this should be considered as the
- preferred DAC mode)
- * CH_MODE_GPIO (the pin is registered
- with GPIOLIB)
- Optional properties:
- * adi,off-state: State of this channel when unused or the
- device gets removed. Macros specifying the
- valid values can be found in
- <dt-bindings/iio/adi,ad5592r.h>.
-
- * CH_OFFSTATE_PULLDOWN (the pin is pulled down)
- * CH_OFFSTATE_OUT_LOW (the pin is output low)
- * CH_OFFSTATE_OUT_HIGH (the pin is output high)
- * CH_OFFSTATE_OUT_TRISTATE (the pin is
- tristated output)
-
-
-Optional properties:
- - vref-supply: Phandle to the external reference voltage supply. This should
- only be set if there is an external reference voltage connected to the VREF
- pin. If the property is not set the internal 2.5V reference is used.
- - reset-gpios : GPIO spec for the RESET pin. If specified, it will be
- asserted during driver probe.
- - gpio-controller: Marks the device node as a GPIO controller.
- - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
- cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
-
-AD5592R Example:
-
- #include <dt-bindings/iio/adi,ad5592r.h>
-
- vref: regulator-vref {
- compatible = "regulator-fixed";
- regulator-name = "vref-ad559x";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- ad5592r@0 {
- #size-cells = <0>;
- #address-cells = <1>;
- #gpio-cells = <2>;
- compatible = "adi,ad5592r";
- reg = <0>;
-
- spi-max-frequency = <1000000>;
- spi-cpol;
-
- vref-supply = <&vref>; /* optional */
- reset-gpios = <&gpio0 86 0>; /* optional */
- gpio-controller;
-
- channel@0 {
- reg = <0>;
- adi,mode = <CH_MODE_DAC>;
- };
- channel@1 {
- reg = <1>;
- adi,mode = <CH_MODE_ADC>;
- };
- channel@2 {
- reg = <2>;
- adi,mode = <CH_MODE_DAC_AND_ADC>;
- };
- channel@3 {
- reg = <3>;
- adi,mode = <CH_MODE_DAC_AND_ADC>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@4 {
- reg = <4>;
- adi,mode = <CH_MODE_UNUSED>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@5 {
- reg = <5>;
- adi,mode = <CH_MODE_GPIO>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@6 {
- reg = <6>;
- adi,mode = <CH_MODE_GPIO>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@7 {
- reg = <7>;
- adi,mode = <CH_MODE_GPIO>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- };
-
-AD5593R Example:
-
- #include <dt-bindings/iio/adi,ad5592r.h>
-
- ad5593r@10 {
- #size-cells = <0>;
- #address-cells = <1>;
- #gpio-cells = <2>;
- compatible = "adi,ad5593r";
- reg = <0x10>;
- gpio-controller;
-
- channel@0 {
- reg = <0>;
- adi,mode = <CH_MODE_DAC>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@1 {
- reg = <1>;
- adi,mode = <CH_MODE_ADC>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@2 {
- reg = <2>;
- adi,mode = <CH_MODE_DAC_AND_ADC>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- channel@6 {
- reg = <6>;
- adi,mode = <CH_MODE_GPIO>;
- adi,off-state = <CH_OFFSTATE_PULLDOWN>;
- };
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/ad5758.txt b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
deleted file mode 100644
index 2f607f4..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ad5758.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-Analog Devices AD5758 DAC device driver
-
-Required properties for the AD5758:
- - compatible: Must be "adi,ad5758"
- - reg: SPI chip select number for the device
- - spi-max-frequency: Max SPI frequency to use (< 50000000)
- - spi-cpha: is the only mode that is supported
-
-Required properties:
-
- - adi,dc-dc-mode: Mode of operation of the dc-to-dc converter
- Dynamic Power Control (DPC)
- In this mode, the AD5758 circuitry senses the output
- voltage and dynamically regulates the supply voltage,
- VDPC+, to meet compliance requirements plus an optimized
- headroom voltage for the output buffer.
-
- Programmable Power Control (PPC)
- In this mode, the VDPC+ voltage is user-programmable to
- a fixed level that needs to accommodate the maximum output
- load required.
-
- The output of the DAC core is either converted to a
- current or voltage output at the VIOUT pin. Only one mode
- can be enabled at any one time.
-
- The following values are currently supported:
- * 1: DPC current mode
- * 2: DPC voltage mode
- * 3: PPC current mode
-
- Depending on the selected output mode (voltage or current) one of the
- two properties must
- be present:
-
- - adi,range-microvolt: Voltage output range
- The array of voltage output ranges must contain two fields:
- * <0 5000000>: 0 V to 5 V voltage range
- * <0 10000000>: 0 V to 10 V voltage range
- * <(-5000000) 5000000>: ±5 V voltage range
- * <(-10000000) 10000000>: ±10 V voltage range
- - adi,range-microamp: Current output range
- The array of current output ranges must contain two fields:
- * <0 20000>: 0 mA to 20 mA current range
- * <0 24000>: 0 mA to 24 mA current range
- * <4 24000>: 4 mA to 20 mA current range
- * <(-20000) 20000>: ±20 mA current range
- * <(-24000) 24000>: ±24 mA current range
- * <(-1000) 22000>: −1 mA to +22 mA current range
-
-Optional properties:
-
- - reset-gpios : GPIO spec for the RESET pin. If specified, it will be
- asserted during driver probe.
-
- - adi,dc-dc-ilim-microamp: The dc-to-dc converter current limit
- The following values are currently supported [uA]:
- * 150000
- * 200000
- * 250000
- * 300000
- * 350000
- * 400000
-
- - adi,slew-time-us: The time it takes for the output to reach the
- full scale [uS]
- The supported range is between 133us up to 1023984375us
-
-AD5758 Example:
-
- dac@0 {
- compatible = "adi,ad5758";
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpha;
-
- reset-gpios = <&gpio 22 0>;
-
- adi,dc-dc-mode = <2>;
- adi,range-microvolt = <0 10000000>;
- adi,dc-dc-ilim-microamp = <200000>;
- adi,slew-time-us = <125000>;
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
deleted file mode 100644
index 914610f..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ad7303.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Analog Devices AD7303 DAC device driver
-
-Required properties:
- - compatible: Must be "adi,ad7303"
- - reg: SPI chip select number for the device
- - spi-max-frequency: Max SPI frequency to use (< 30000000)
- - Vdd-supply: Phandle to the Vdd power supply
-
-Optional properties:
- - REF-supply: Phandle to the external reference voltage supply. This should
- only be set if there is an external reference voltage connected to the REF
- pin. If the property is not set Vdd/2 is used as the reference voltage.
-
-Example:
-
- ad7303@4 {
- compatible = "adi,ad7303";
- reg = <4>;
- spi-max-frequency = <10000000>;
- Vdd-supply = <&vdd_supply>;
- adi,use-external-reference;
- REF-supply = <&vref_supply>;
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5592r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5592r.yaml
new file mode 100644
index 0000000..3019488
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5592r.yaml
@@ -0,0 +1,204 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5592r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5592R/AD5593R DAC/ADC
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5592r
+ - adi,ad5593r
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 30000000
+
+ spi-cpol: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ "#io-channel-cells":
+ const: 1
+
+ vref-supply:
+ description: If not set internal 2.5V reference used.
+
+ reset-gpios:
+ maxItems: 1
+
+ gpio-controller:
+ description: Marks the device node as a GPIO controller.
+
+ "#gpio-cells":
+ const: 2
+ description:
+ The first cell is the GPIO number and the second cell specifies
+ GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,ad5592r
+ then:
+ required:
+ - spi-cpol
+ else:
+ properties:
+ spi-cpol: false
+
+additionalProperties: false
+
+patternProperties:
+ "^(channel@)[0-7]$":
+ type: object
+ description: Child node to describe a channel
+ properties:
+ reg:
+ minimum: 0
+ maximum: 7
+
+ adi,mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 8]
+ description: |
+ Mode or function of this channel.
+ Macros specifying the valid values can be found in
+ <dt-bindings/iio/adi,ad5592r.h>.
+
+ The following values are currently supported:
+ * CH_MODE_UNUSED (the pin is unused)
+ * CH_MODE_ADC (the pin is ADC input)
+ * CH_MODE_DAC (the pin is DAC output)
+ * CH_MODE_DAC_AND_ADC (the pin is DAC output but can be monitored
+ by an ADC, since there is no disadvantage this should be
+ considered as the preferred DAC mode)
+ * CH_MODE_GPIO (the pin is registered with GPIOLIB)
+
+ adi,off-state:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ description: |
+ State of this channel when unused or the device gets removed.
+ Macros specifying the valid values can be found in
+ <dt-bindings/iio/adi,ad5592r.h>.
+ * CH_OFFSTATE_PULLDOWN (the pin is pulled down)
+ * CH_OFFSTATE_OUT_LOW (the pin is output low)
+ * CH_OFFSTATE_OUT_HIGH (the pin is output high)
+ * CH_OFFSTATE_OUT_TRISTATE (the pin is tristated output)
+
+ required:
+ - reg
+ - adi,mode
+
+ additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/iio/adi,ad5592r.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ addac@0 {
+ compatible = "adi,ad5592r";
+ #size-cells = <0>;
+ #address-cells = <1>;
+ #gpio-cells = <2>;
+ reg = <0>;
+
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+
+ vref-supply = <&vref>;
+ reset-gpios = <&gpio0 86 0>;
+ gpio-controller;
+
+ channel@0 {
+ reg = <0>;
+ adi,mode = <CH_MODE_DAC>;
+ };
+ channel@1 {
+ reg = <1>;
+ adi,mode = <CH_MODE_ADC>;
+ };
+ channel@2 {
+ reg = <2>;
+ adi,mode = <CH_MODE_DAC_AND_ADC>;
+ };
+ channel@3 {
+ reg = <3>;
+ adi,mode = <CH_MODE_DAC_AND_ADC>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@4 {
+ reg = <4>;
+ adi,mode = <CH_MODE_UNUSED>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@5 {
+ reg = <5>;
+ adi,mode = <CH_MODE_GPIO>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@6 {
+ reg = <6>;
+ adi,mode = <CH_MODE_GPIO>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@7 {
+ reg = <7>;
+ adi,mode = <CH_MODE_GPIO>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ };
+ ad5593r@10 {
+ compatible = "adi,ad5593r";
+ #size-cells = <0>;
+ #address-cells = <1>;
+ #gpio-cells = <2>;
+ reg = <0x10>;
+ gpio-controller;
+
+ channel@0 {
+ reg = <0>;
+ adi,mode = <CH_MODE_DAC>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@1 {
+ reg = <1>;
+ adi,mode = <CH_MODE_ADC>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@2 {
+ reg = <2>;
+ adi,mode = <CH_MODE_DAC_AND_ADC>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ channel@6 {
+ reg = <6>;
+ adi,mode = <CH_MODE_GPIO>;
+ adi,off-state = <CH_OFFSTATE_PULLDOWN>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
new file mode 100644
index 0000000..8065228
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5686 and similar multi-channel DACs
+
+maintainers:
+ - Michael Auchter <michael.auchter@ni.com>
+
+description: |
+ Binding for Analog Devices AD5686 and similar multi-channel DACs
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5311r
+ - adi,ad5338r
+ - adi,ad5671r
+ - adi,ad5675r
+ - adi,ad5691r
+ - adi,ad5692r
+ - adi,ad5693
+ - adi,ad5693r
+ - adi,ad5694
+ - adi,ad5694r
+ - adi,ad5695r
+ - adi,ad5696
+ - adi,ad5696r
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: |
+ The regulator supply for DAC reference voltage.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ad5686: dac@0 {
+ compatible = "adi,ad5686";
+ reg = <0>;
+ vcc-supply = <&dac_vref>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
new file mode 100644
index 0000000..626ccb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5758.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5758 DAC
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+
+properties:
+ compatible:
+ const: adi,ad5758
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+ spi-cpha: true
+
+ adi,dc-dc-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3]
+ description: |
+ Mode of operation of the dc-to-dc converter
+ Dynamic Power Control (DPC)
+ In this mode, the AD5758 circuitry senses the output voltage and
+ dynamically regulates the supply voltage, VDPC+, to meet compliance
+ requirements plus an optimized headroom voltage for the output buffer.
+
+ Programmable Power Control (PPC)
+ In this mode, the VDPC+ voltage is user-programmable to a fixed level
+ that needs to accommodate the maximum output load required.
+
+ The output of the DAC core is either converted to a current or
+ voltage output at the VIOUT pin. Only one mode can be enabled at
+ any one time.
+
+ The following values are currently supported:
+ * 1: DPC current mode
+ * 2: DPC voltage mode
+ * 3: PPC current mode
+
+ Depending on the selected output mode (voltage or current) one of the
+ two properties must be present:
+
+ adi,range-microvolt:
+ $ref: /schemas/types.yaml#/definitions/int32-array
+ description: |
+ Voltage output range specified as <minimum, maximum>
+ enum:
+ - [[0, 5000000]]
+ - [[0, 10000000]]
+ - [[-5000000, 5000000]]
+ - [[-10000000, 10000000]]
+
+ adi,range-microamp:
+ $ref: /schemas/types.yaml#/definitions/int32-array
+ description: |
+ Current output range specified as <minimum, maximum>
+ enum:
+ - [[0, 20000]]
+ - [[0, 24000]]
+ - [[4, 24000]]
+ - [[-20000, 20000]]
+ - [[-24000, 24000]]
+ - [[-1000, 22000]]
+
+ reset-gpios: true
+
+ adi,dc-dc-ilim-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [150000, 200000, 250000, 300000, 350000, 400000]
+ description: |
+ The dc-to-dc converter current limit.
+
+ adi,slew-time-us:
+ description: |
+ The time it takes for the output to reach the full scale [uS]
+ minimum: 133
+ maximum: 1023984375
+
+required:
+ - compatible
+ - reg
+ - spi-cpha
+ - adi,dc-dc-mode
+
+allOf:
+ - if:
+ properties:
+ adi,dc-dc-mode:
+ contains:
+ enum: [1, 3]
+ then:
+ properties:
+ adi,range-microvolt: false
+ required:
+ - adi,range-microamp
+ else:
+ properties:
+ adi,range-microamp: false
+ required:
+ - adi,range-microvolt
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad5758";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpha;
+
+ reset-gpios = <&gpio 22 0>;
+
+ adi,dc-dc-mode = <2>;
+ adi,range-microvolt = <0 10000000>;
+ adi,dc-dc-ilim-microamp = <200000>;
+ adi,slew-time-us = <125000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad7303.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad7303.yaml
new file mode 100644
index 0000000..1f00371
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad7303.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad7303.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7303 DAC
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+properties:
+ compatible:
+ const: adi,ad7303
+
+ reg:
+ maxItems: 1
+
+ Vdd-supply:
+ description:
+ Used to calculate output channel scalling if REF-supply not specified.
+ REF-supply:
+ description:
+ If not provided, Vdd/2 is used as the reference voltage.
+
+ spi-max-frequency:
+ maximum: 30000000
+
+required:
+ - compatible
+ - reg
+ - Vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@4 {
+ compatible = "adi,ad7303";
+ reg = <4>;
+ spi-max-frequency = <10000000>;
+ Vdd-supply = <&vdd_supply>;
+ REF-supply = <&vref_supply>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt b/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
deleted file mode 100644
index fdf47a0..0000000
--- a/Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Bindings for DAC emulation using a digital potentiometer
-
-It is assumed that the dpot is used as a voltage divider between the
-current dpot wiper setting and the maximum resistance of the dpot. The
-divided voltage is provided by a vref regulator.
-
- .------.
- .-----------. | |
- | vref |--' .---.
- | regulator |--. | |
- '-----------' | | d |
- | | p |
- | | o | wiper
- | | t |<---------+
- | | |
- | '---' dac output voltage
- | |
- '------+------------+
-
-Required properties:
-- compatible: Should be "dpot-dac"
-- vref-supply: The regulator supplying the voltage divider.
-- io-channels: Channel node of the dpot to be used for the voltage division.
-- io-channel-names: Should be "dpot".
-
-Example:
-
- &i2c {
- dpot: mcp4651-503@28 {
- compatible = "microchip,mcp4651-503";
- reg = <0x28>;
- #io-channel-cells = <1>;
- };
- };
-
- dac {
- compatible = "dpot-dac";
- vref-supply = <®_3v3>;
- io-channels = <&dpot 0>;
- io-channel-names = "dpot";
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml b/Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml
new file mode 100644
index 0000000..6a7ca8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/dpot-dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DAC emulation using a digital potentiometer
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ It is assumed that the dpot is used as a voltage divider between the
+ current dpot wiper setting and the maximum resistance of the dpot. The
+ divided voltage is provided by a vref regulator.
+
+ .------.
+ .-----------. | |
+ | vref |--' .---.
+ | regulator |--. | |
+ '-----------' | | d |
+ | | p |
+ | | o | wiper
+ | | t |<---------+
+ | | |
+ | '---' dac output voltage
+ | |
+ '------+------------+
+
+properties:
+ compatible:
+ const: dpot-dac
+
+ vref-supply:
+ description: Regulator supplying the voltage divider.
+
+ io-channels:
+ maxItems: 1
+ description: |
+ Channel node of the dpot to be used for the voltage division.
+
+ io-channel-names:
+ const: dpot
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - vref-supply
+ - io-channels
+ - io-channel-names
+
+additionalProperties: false
+
+examples:
+ - |
+ dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/ds4424.txt b/Documentation/devicetree/bindings/iio/dac/ds4424.txt
deleted file mode 100644
index eaebbf8..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ds4424.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Maxim Integrated DS4422/DS4424 7-bit Sink/Source Current DAC Device Driver
-
-Datasheet publicly available at:
-https://datasheets.maximintegrated.com/en/ds/DS4422-DS4424.pdf
-
-Required properties:
- - compatible: Should be one of
- maxim,ds4422
- maxim,ds4424
- - reg: Should contain the DAC I2C address
-
-Optional properties:
- - vcc-supply: Power supply is optional. If not defined, driver will ignore it.
-
-Example:
- ds4224@10 {
- compatible = "maxim,ds4424";
- reg = <0x10>; /* When A0, A1 pins are ground */
- vcc-supply = <&vcc_3v3>;
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/fsl,vf610-dac.yaml b/Documentation/devicetree/bindings/iio/dac/fsl,vf610-dac.yaml
new file mode 100644
index 0000000..999c715
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/fsl,vf610-dac.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/fsl,vf610-dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale vf610 Digital to Analog Converter
+
+maintainers:
+ - Sanchayan Maity <maitysanchayan@gmail.com>
+
+properties:
+ compatible:
+ const: fsl,vf610-dac
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: dac
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/vf610-clock.h>
+ bus@40000000 {
+ compatible = "fsl,aips-bus", "simple-bus";
+ reg = <0x40000000 0x00070000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dac@400cc000 {
+ compatible = "fsl,vf610-dac";
+ reg = <0x400cc000 0x1000>;
+ interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "dac";
+ clocks = <&clks VF610_CLK_DAC0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/lpc1850-dac.txt b/Documentation/devicetree/bindings/iio/dac/lpc1850-dac.txt
deleted file mode 100644
index 42db783..0000000
--- a/Documentation/devicetree/bindings/iio/dac/lpc1850-dac.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-NXP LPC1850 DAC bindings
-
-Required properties:
-- compatible: Should be "nxp,lpc1850-dac"
-- reg: Offset and length of the register set for the ADC device
-- interrupts: The interrupt number for the ADC device
-- clocks: The root clock of the ADC controller
-- vref-supply: The regulator supply ADC reference voltage
-- resets: phandle to reset controller and line specifier
-
-Example:
-dac: dac@400e1000 {
- compatible = "nxp,lpc1850-dac";
- reg = <0x400e1000 0x1000>;
- interrupts = <0>;
- clocks = <&ccu1 CLK_APB3_DAC>;
- vref-supply = <®_vdda>;
- resets = <&rgu 42>;
-};
diff --git a/Documentation/devicetree/bindings/iio/dac/max5821.txt b/Documentation/devicetree/bindings/iio/dac/max5821.txt
deleted file mode 100644
index 54276ce..0000000
--- a/Documentation/devicetree/bindings/iio/dac/max5821.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Maxim max5821 DAC device driver
-
-Required properties:
- - compatible: Must be "maxim,max5821"
- - reg: Should contain the DAC I2C address
- - vref-supply: Phandle to the vref power supply
-
-Example:
-
- max5821@38 {
- compatible = "maxim,max5821";
- reg = <0x38>;
- vref-supply = <®_max5821>;
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
new file mode 100644
index 0000000..264fa7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/maxim,ds4424.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/maxim,ds4424.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated DS4422/DS4424 7-bit Sink/Source Current DAC
+
+maintainers:
+ - Ismail Kose <ihkose@gmail.com>
+
+description: |
+ Datasheet publicly available at:
+ https://datasheets.maximintegrated.com/en/ds/DS4422-DS4424.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,ds4422
+ - maxim,ds4424
+
+ reg:
+ maxItems: 1
+
+ vcc-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@10 {
+ compatible = "maxim,ds4424";
+ reg = <0x10>; /* When A0, A1 pins are ground */
+ vcc-supply = <&vcc_3v3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,max5821.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,max5821.yaml
new file mode 100644
index 0000000..c43fb5f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/maxim,max5821.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/maxim,max5821.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim max5821 dual 10-bit DAC
+
+maintainers:
+ - Philippe Reynes <tremyfr@yahoo.fr>
+
+description: |
+ Datasheet publicly available at:
+ https://datasheets.maximintegrated.com/en/ds/MAX5821.pdf
+
+properties:
+ compatible:
+ const: maxim,max5821
+
+ reg:
+ maxItems: 1
+
+ vref-supply: true
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@38 {
+ compatible = "maxim,max5821";
+ reg = <0x38>;
+ vref-supply = <®_max5821>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/mcp4725.txt b/Documentation/devicetree/bindings/iio/dac/mcp4725.txt
deleted file mode 100644
index 1bc6c09..0000000
--- a/Documentation/devicetree/bindings/iio/dac/mcp4725.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Microchip mcp4725 and mcp4726 DAC device driver
-
-Required properties:
- - compatible: Must be "microchip,mcp4725" or "microchip,mcp4726"
- - reg: Should contain the DAC I2C address
- - vdd-supply: Phandle to the Vdd power supply. This supply is used as a
- voltage reference on mcp4725. It is used as a voltage reference on
- mcp4726 if there is no vref-supply specified.
-
-Optional properties (valid only for mcp4726):
- - vref-supply: Optional phandle to the Vref power supply. Vref pin is
- used as a voltage reference when this supply is specified.
- - microchip,vref-buffered: Boolean to enable buffering of the external
- Vref pin. This boolean is not valid without the vref-supply. Quoting
- the datasheet: This is offered in cases where the reference voltage
- does not have the current capability not to drop its voltage when
- connected to the internal resistor ladder circuit.
-
-Examples:
-
- /* simple mcp4725 */
- mcp4725@60 {
- compatible = "microchip,mcp4725";
- reg = <0x60>;
- vdd-supply = <&vdac_vdd>;
- };
-
- /* mcp4726 with the buffered external reference voltage */
- mcp4726@60 {
- compatible = "microchip,mcp4726";
- reg = <0x60>;
- vdd-supply = <&vdac_vdd>;
- vref-supply = <&vdac_vref>;
- microchip,vref-buffered;
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4725.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4725.yaml
new file mode 100644
index 0000000..2719986
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4725.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4725.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip mcp4725 and mcp4726 DAC
+
+maintainers:
+ - Tomas Novotny <tomas@novotny.cz>
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp4725
+ - microchip,mcp4726
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: |
+ Provides both power and acts as the reference supply on the mcp4725.
+ For the mcp4726 it will be used as the reference voltage if vref-supply
+ is not provided.
+
+ vref-supply:
+ description:
+ Vref pin is used as a voltage reference when this supply is specified.
+
+ microchip,vref-buffered:
+ type: boolean
+ description: |
+ Enable buffering of the external Vref pin. This boolean is not valid
+ without the vref-supply. Quoting the datasheet: This is offered in
+ cases where the reference voltage does not have the current
+ capability not to drop its voltage when connected to the internal
+ resistor ladder circuit.
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: microchip,mcp4726
+ then:
+ properties:
+ vref-supply: false
+ microchip,vref-buffered: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mcp4725@60 {
+ compatible = "microchip,mcp4725";
+ reg = <0x60>;
+ vdd-supply = <&vdac_vdd>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml b/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml
new file mode 100644
index 0000000..595f481
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/nxp,lpc1850-dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1850 DAC bindings
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description:
+ Supports the DAC found on the LPC1850 SoC.
+
+properties:
+ compatible:
+ const: nxp,lpc1850-dac
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ vref-supply: true
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - vref-supply
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dac: dac@400e1000 {
+ compatible = "nxp,lpc1850-dac";
+ reg = <0x400e1000 0x1000>;
+ interrupts = <0>;
+ clocks = <&ccu1 CLK_APB3_DAC>;
+ vref-supply = <®_vdda>;
+ resets = <&rgu 42>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.txt b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.txt
deleted file mode 100644
index 03af6b9..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Texas Instruments DAC5571 Family
-
-Required properties:
- - compatible: Should contain
- "ti,dac5571"
- "ti,dac6571"
- "ti,dac7571"
