Merge tag 'objtool-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull objtool fix from Ingo Molnar:
"Fix a segfault that occurs when built with Clang"
* tag 'objtool-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Fix seg fault with Clang non-section symbols
diff --git a/.mailmap b/.mailmap
index 225546c..632700c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -122,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>
@@ -343,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 e88d1a7..090ed4b 100644
--- a/CREDITS
+++ b/CREDITS
@@ -2510,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
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/configfs-usb-gadget-ecm b/Documentation/ABI/testing/configfs-usb-gadget-ecm
index 272bc1e..732101c 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-ecm
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ecm
@@ -7,7 +7,7 @@
ifname
- network device interface name associated with
this function instance
- qmult
+ qmult
- queue length multiplier for high and
super speed
host_addr
diff --git a/Documentation/ABI/testing/procfs-attr-current b/Documentation/ABI/testing/procfs-attr-current
new file mode 100644
index 0000000..198b9fe
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-attr-current
@@ -0,0 +1,20 @@
+What: /proc/*/attr/current
+Contact: linux-security-module@vger.kernel.org,
+ selinux@vger.kernel.org,
+ apparmor@lists.ubuntu.com
+Description: The current security information used by a Linux
+ security module (LSM) that is active on the system.
+ The details of permissions required to read from
+ this interface and hence obtain the security state
+ of the task identified is LSM dependent.
+ A process cannot write to this interface unless it
+ refers to itself.
+ The other details of permissions required to write to
+ this interface and hence change the security state of
+ the task identified are LSM dependent.
+ The format of the data used by this interface is LSM
+ dependent.
+ SELinux, Smack and AppArmor provide this interface.
+Users: SELinux user-space
+ Smack user-space
+ AppArmor user-space
diff --git a/Documentation/ABI/testing/procfs-attr-exec b/Documentation/ABI/testing/procfs-attr-exec
new file mode 100644
index 0000000..3459386
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-attr-exec
@@ -0,0 +1,20 @@
+What: /proc/*/attr/exec
+Contact: linux-security-module@vger.kernel.org,
+ selinux@vger.kernel.org,
+ apparmor@lists.ubuntu.com
+Description: The security information to be used on the process
+ by a Linux security module (LSM) active on the system
+ after a subsequent exec() call.
+ The details of permissions required to read from
+ this interface and hence obtain the security state
+ of the task identified is LSM dependent.
+ A process cannot write to this interface unless it
+ refers to itself.
+ The other details of permissions required to write to
+ this interface and hence change the security state of
+ the task identified are LSM dependent.
+ The format of the data used by this interface is LSM
+ dependent.
+ SELinux and AppArmor provide this interface.
+Users: SELinux user-space
+ AppArmor user-space
diff --git a/Documentation/ABI/testing/procfs-attr-prev b/Documentation/ABI/testing/procfs-attr-prev
new file mode 100644
index 0000000..f990b35
--- /dev/null
+++ b/Documentation/ABI/testing/procfs-attr-prev
@@ -0,0 +1,19 @@
+What: /proc/*/attr/prev
+Contact: linux-security-module@vger.kernel.org,
+ selinux@vger.kernel.org,
+ apparmor@lists.ubuntu.com
+Description: The security information used on the process by
+ a Linux security module (LSM) active on the system
+ prior to the most recent exec() call.
+ The details of permissions required to read from
+ this interface is LSM dependent.
+ A process cannot write to this interface unless it
+ refers to itself.
+ The other details of permissions required to write to
+ this interface are LSM dependent.
+ The format of the data used by this interface is LSM
+ dependent.
+ SELinux and AppArmor provide this interface.
+Users: SELinux user-space
+ AppArmor user-space
+
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-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-memory b/Documentation/ABI/testing/sysfs-devices-memory
index 2da2b1f..246a45b 100644
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -19,7 +19,7 @@
identify removable sections of the memory before attempting
potentially expensive hot-remove memory operation
Users: hotplug memory remove tools
- http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
+ http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memory/memoryX/phys_device
Date: September 2008
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-ext4 b/Documentation/ABI/testing/sysfs-fs-ext4
index 99e3d92..2edd0a6 100644
--- a/Documentation/ABI/testing/sysfs-fs-ext4
+++ b/Documentation/ABI/testing/sysfs-fs-ext4
@@ -33,7 +33,7 @@
Date: March 2008
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
- Tuning parameter which controls the minimum size for
+ Tuning parameter which controls the minimum size for
requests (as a power of 2) where the buddy cache is
used
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/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module
index 353c0db5..a485434 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -25,7 +25,7 @@
However there are cases, when 80% max isochronous bandwidth is
too limiting. For example two video streams could require 110
microseconds of isochronous bandwidth per microframe to work
- together.
+ together.
Through this setting it is possible to raise the limit so that
the host controller would allow allocating more than 100
diff --git a/Documentation/ABI/testing/sysfs-platform-renesas_usb3 b/Documentation/ABI/testing/sysfs-platform-renesas_usb3
index 8af5b9c..b08379e 100644
--- a/Documentation/ABI/testing/sysfs-platform-renesas_usb3
+++ b/Documentation/ABI/testing/sysfs-platform-renesas_usb3
@@ -12,6 +12,6 @@
- "peripheral" - switching mode from host to peripheral.
Read the file, then it shows the following strings:
-
+
- "host" - The mode is host now.
- "peripheral" - The mode is peripheral now.
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/README.rst b/Documentation/admin-guide/README.rst
index 95a28f4..261b7b4 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -398,8 +398,8 @@
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
- possible will help. Please read the :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
- document for details.
+ possible will help. Please read
+ 'Documentation/admin-guide/reporting-issues.rst' for details.
- Alternatively, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
diff --git a/Documentation/admin-guide/acpi/cppc_sysfs.rst b/Documentation/admin-guide/acpi/cppc_sysfs.rst
index a4b99af..fccf221 100644
--- a/Documentation/admin-guide/acpi/cppc_sysfs.rst
+++ b/Documentation/admin-guide/acpi/cppc_sysfs.rst
@@ -8,7 +8,7 @@
====
CPPC defined in the ACPI spec describes a mechanism for the OS to manage the
-performance of a logical processor on a contigious and abstract performance
+performance of a logical processor on a contiguous and abstract performance
scale. CPPC exposes a set of registers to describe abstract performance scale,
to request performance levels and to measure per-cpu delivered performance.
@@ -45,7 +45,7 @@
* lowest_freq : CPU frequency corresponding to lowest_perf (in MHz).
* nominal_freq : CPU frequency corresponding to nominal_perf (in MHz).
The above frequencies should only be used to report processor performance in
- freqency instead of abstract scale. These values should not be used for any
+ frequency instead of abstract scale. These values should not be used for any
functional decisions.
* feedback_ctrs : Includes both Reference and delivered performance counter.
diff --git a/Documentation/admin-guide/binderfs.rst b/Documentation/admin-guide/binderfs.rst
index 8243af9..199d843 100644
--- a/Documentation/admin-guide/binderfs.rst
+++ b/Documentation/admin-guide/binderfs.rst
@@ -70,5 +70,5 @@
Binderfs binder devices can be deleted via `unlink() <unlink_>`_. This means
that the `rm() <rm_>`_ tool can be used to delete them. Note that the
``binder-control`` device cannot be deleted since this would make the binderfs
-instance unuseable. The ``binder-control`` device will be deleted when the
+instance unusable. The ``binder-control`` device will be deleted when the
binderfs instance is unmounted and all references to it have been dropped.
diff --git a/Documentation/admin-guide/blockdev/paride.rst b/Documentation/admin-guide/blockdev/paride.rst
index 87b4278..e1ce90a 100644
--- a/Documentation/admin-guide/blockdev/paride.rst
+++ b/Documentation/admin-guide/blockdev/paride.rst
@@ -220,7 +220,7 @@
Finally, you can load high-level drivers for each kind of device that
you have connected. By default, each driver will autoprobe for a single
device, but you can support up to four similar devices by giving their
-individual co-ordinates when you load the driver.
+individual coordinates when you load the driver.
For example, if you had two no-name CD-ROM drives both using the
KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc
diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst
index a6fd1f9..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.
@@ -360,7 +366,7 @@
/sys/block/zram0/writeback_limit.
$ echo 1 > /sys/block/zram0/writeback_limit_enable
-If admins want to allow further write again once the bugdet is exhausted,
+If admins want to allow further write again once the budget is exhausted,
he could do it like below::
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
diff --git a/Documentation/admin-guide/bug-bisect.rst b/Documentation/admin-guide/bug-bisect.rst
index 59567da..325c5d0 100644
--- a/Documentation/admin-guide/bug-bisect.rst
+++ b/Documentation/admin-guide/bug-bisect.rst
@@ -15,7 +15,7 @@
MAINTAINERS for who that is for the subsystem you have worked on.
Before you submit a bug report read
-:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`.
+'Documentation/admin-guide/reporting-issues.rst'.
Devices not appearing
=====================
diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst
index f7c80f4..95299b0 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -263,7 +263,7 @@
- The last developers that touched the source code (if this is done inside
a git tree). On the above example, Tejun and Bhaktipriya (in this
- specific case, none really envolved on the development of this file);
+ specific case, none really involved on the development of this file);
- The driver maintainer (Hans Verkuil);
- The subsystem maintainer (Mauro Carvalho Chehab);
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
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/cifs/introduction.rst b/Documentation/admin-guide/cifs/introduction.rst
index 0b98f67..cc2851d 100644
--- a/Documentation/admin-guide/cifs/introduction.rst
+++ b/Documentation/admin-guide/cifs/introduction.rst
@@ -9,7 +9,7 @@
PC operating systems. New and improved versions of CIFS are now
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1)
is strongly preferred over using older dialects like CIFS due to
- security reaasons. All modern dialects, including the most recent,
+ security reasons. All modern dialects, including the most recent,
SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol
is implemented and supported by all major file servers
such as all modern versions of Windows (including Windows 2016
diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst
index 7b32d50..b6d9f02 100644
--- a/Documentation/admin-guide/cifs/usage.rst
+++ b/Documentation/admin-guide/cifs/usage.rst
@@ -115,7 +115,7 @@
Allowing User Unmounts
======================
-To permit users to ummount directories that they have user mounted (see above),
+To permit users to unmount directories that they have user mounted (see above),
the utility umount.cifs may be used. It may be invoked directly, or if
umount.cifs is placed in /sbin, umount can invoke the cifs umount helper
(at least for most versions of the umount utility) for umount of cifs
@@ -197,7 +197,7 @@
not be traversed by the Samba server). This is opaque to the Linux client
application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or
later, but only for remote clients using the CIFS Unix extensions, and will
-be invisbile to Windows clients and typically will not affect local
+be invisible to Windows clients and typically will not affect local
applications running on the same server as Samba.
Use instructions
@@ -267,7 +267,7 @@
configured for Unix Extensions (and the client has not disabled
/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option
``mapposix`` can be used on CIFS (vers=1.0) to force the mapping of
-illegal Windows/NTFS/SMB characters to a remap range (this mount parm
+illegal Windows/NTFS/SMB characters to a remap range (this mount parameter
is the default for SMB3). This remap (``mapposix``) range is also
compatible with Mac (and "Services for Mac" on some older Windows).
diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst
index bc28a95..1a6753b 100644
--- a/Documentation/admin-guide/device-mapper/dm-crypt.rst
+++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst
@@ -46,7 +46,7 @@
capi:authenc(hmac(sha256),xts(aes))-random
capi:rfc7539(chacha20,poly1305)-random
- The /proc/crypto contains a list of curently loaded crypto modes.
+ The /proc/crypto contains a list of currently loaded crypto modes.
<key>
Key used for encryption. It is encoded either as a hexadecimal number
@@ -92,7 +92,7 @@
<#opt_params>
Number of optional parameters. If there are no optional parameters,
- the optional paramaters section can be skipped or #opt_params can be zero.
+ the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 3ab4f77..4e6f504 100644
--- a/Documentation/admin-guide/device-mapper/dm-integrity.rst
+++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst
@@ -117,7 +117,7 @@
commit_time:number
Commit time in milliseconds. When this time passes, the journal is
- written. The journal is also written immediatelly if the FLUSH
+ written. The journal is also written immediately if the FLUSH
request is received.
internal_hash:algorithm(:key) (the key is optional)
@@ -147,7 +147,7 @@
"salsa20" or "ctr(aes)").
The journal contains history of last writes to the block device,
- an attacker reading the journal could see the last sector nubmers
+ an attacker reading the journal could see the last sector numbers
that were written. From the sector numbers, the attacker can infer
the size of files that were written. To protect against this
situation, you can encrypt the journal.
diff --git a/Documentation/admin-guide/device-mapper/dm-raid.rst b/Documentation/admin-guide/device-mapper/dm-raid.rst
index 7ef9fe6..bb17e26 100644
--- a/Documentation/admin-guide/device-mapper/dm-raid.rst
+++ b/Documentation/admin-guide/device-mapper/dm-raid.rst
@@ -418,6 +418,6 @@
specific devices are requested via rebuild. Fix RAID leg
rebuild errors.
1.15.0 Fix size extensions not being synchronized in case of new MD bitmap
- pages allocated; also fix those not occuring after previous reductions
+ pages allocated; also fix those not occurring after previous reductions
1.15.1 Fix argument count and arguments for rebuild/write_mostly/journal_(dev|mode)
on the status line.
diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst b/Documentation/admin-guide/device-mapper/dm-zoned.rst
index e6350413..0fac051 100644
--- a/Documentation/admin-guide/device-mapper/dm-zoned.rst
+++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst
@@ -24,7 +24,7 @@
and memory usage as well as storage capacity loss). For a 10TB
host-managed disk with 256 MB zones, dm-zoned memory usage per disk
instance is at most 4.5 MB and as little as 5 zones will be used
-internally for storing metadata and performaing reclaim operations.
+internally for storing metadata and performing reclaim operations.
dm-zoned target devices are formatted and checked using the dmzadm
utility available at:
@@ -102,7 +102,7 @@
accessed blocks are invalid, the read buffer is zeroed and the read
operation terminated.
-After some time, the limited number of convnetional zones available may
+After some time, the limited number of conventional zones available may
be exhausted (all used to map chunks or buffer sequential zones) and
unaligned writes to unbuffered chunks become impossible. To avoid this
situation, a reclaim process regularly scans used conventional zones and
@@ -158,7 +158,7 @@
dmzadm --format /dev/sdxx /dev/sdyy
-Fomatted device(s) can be started with the dmzadm utility, too.:
+Formatted device(s) can be started with the dmzadm utility, too.:
Ex::
diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst
index 66f71f0..1a6b913 100644
--- a/Documentation/admin-guide/device-mapper/verity.rst
+++ b/Documentation/admin-guide/device-mapper/verity.rst
@@ -69,7 +69,7 @@
<#opt_params>
Number of optional parameters. If there are no optional parameters,
- the optional paramaters section can be skipped or #opt_params can be zero.
+ the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:
@@ -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/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst
index d3d7690..dce0184 100644
--- a/Documentation/admin-guide/device-mapper/writecache.rst
+++ b/Documentation/admin-guide/device-mapper/writecache.rst
@@ -37,10 +37,10 @@
autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
when the application writes this amount of blocks without
issuing the FLUSH request, the blocks are automatically
- commited
+ committed
autocommit_time ms (default: 1000)
autocommit time in milliseconds. The data is automatically
- commited if this time passes and no FLUSH request is
+ committed if this time passes and no FLUSH request is
received
fua (by default on)
applicable only to persistent memory - use the FUA flag
diff --git a/Documentation/admin-guide/features.rst b/Documentation/admin-guide/features.rst
new file mode 100644
index 0000000..8c16708
--- /dev/null
+++ b/Documentation/admin-guide/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features
diff --git a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
index 68d96f0..76673af 100644
--- a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
+++ b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
@@ -60,7 +60,7 @@
The victim of a malicious actor does not need to make use of TSX. Only the
attacker needs to begin a TSX transaction and raise an asynchronous abort
-which in turn potenitally leaks data stored in the buffers.
+which in turn potentially leaks data stored in the buffers.
More detailed technical information is available in the TAA specific x86
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 4e0c4ae..423116c 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -19,6 +19,7 @@
sysctl/index
abi
+ features
This section describes CPU vulnerabilities and their mitigations.
@@ -33,7 +34,8 @@
.. toctree::
:maxdepth: 1
- reporting-bugs
+ reporting-issues
+ Reporting bugs (obsolete) <reporting-bugs>
security-bugs
bug-hunting
bug-bisect
@@ -111,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.rst b/Documentation/admin-guide/kernel-parameters.rst
index 6d42169..06fb1b4 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -172,6 +172,7 @@
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
X86_UV SGI UV support is enabled.
XEN Xen support is enabled
+ XTENSA xtensa architecture is enabled.
In addition, the following text indicates that the option::
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 44fde25..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
@@ -2709,7 +2714,7 @@
option description.
memmap=nn[KMG]@ss[KMG]
- [KNL] Force usage of a specific region of memory.
+ [KNL, X86, MIPS, XTENSA] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
If @ss[KMG] is omitted, it is equivalent to mem=nn[KMG],
which limits max address to nn[KMG].
@@ -2953,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
@@ -3375,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".
@@ -5663,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/md.rst b/Documentation/admin-guide/md.rst
index cc8781b..d8fc9a5 100644
--- a/Documentation/admin-guide/md.rst
+++ b/Documentation/admin-guide/md.rst
@@ -221,7 +221,7 @@
layout
The ``layout`` for the array for the particular level. This is
- simply a number that is interpretted differently by different
+ simply a number that is interpreted differently by different
levels. It can be written while assembling an array.
array_size
diff --git a/Documentation/admin-guide/media/bttv.rst b/Documentation/admin-guide/media/bttv.rst
index 4938237..0ef1f20 100644
--- a/Documentation/admin-guide/media/bttv.rst
+++ b/Documentation/admin-guide/media/bttv.rst
@@ -77,7 +77,7 @@
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
-at :doc:`bttv-cardlist` (in case you are intrested or want to mail
+at :doc:`bttv-cardlist` (in case you are interested or want to mail
patches with updates).
diff --git a/Documentation/admin-guide/media/dvb_references.rst b/Documentation/admin-guide/media/dvb_references.rst
index 48445ac..4f0fd42 100644
--- a/Documentation/admin-guide/media/dvb_references.rst
+++ b/Documentation/admin-guide/media/dvb_references.rst
@@ -10,7 +10,7 @@
http://vger.kernel.org/vger-lists.html#linux-media for details.
There are also some other old lists hosted at:
-https://linuxtv.org/lists.php. If you're insterested on that for historic
+https://linuxtv.org/lists.php. If you're interested on that for historic
reasons, please check the archive at https://linuxtv.org/pipermail/linux-dvb/.
The media subsystem Wiki is hosted at https://linuxtv.org/wiki/.
diff --git a/Documentation/admin-guide/media/frontend-cardlist.rst b/Documentation/admin-guide/media/frontend-cardlist.rst
index 73a248c..ba5b7c6 100644
--- a/Documentation/admin-guide/media/frontend-cardlist.rst
+++ b/Documentation/admin-guide/media/frontend-cardlist.rst
@@ -68,7 +68,7 @@
cx24117 Conexant CX24117 based
cx24120 Conexant CX24120 based
cx24123 Conexant CX24123 based
-ds3000 Montage Tehnology DS3000 based
+ds3000 Montage Technology DS3000 based
mb86a16 Fujitsu MB86A16 based
mt312 Zarlink VP310/MT312/ZL10313 based
s5h1420 Samsung S5H1420 based
@@ -83,7 +83,7 @@
tda8083 Philips TDA8083 based
tda8261 Philips TDA8261 based
tda826x Philips TDA826X silicon tuner
-ts2020 Montage Tehnology TS2020 based tuners
+ts2020 Montage Technology TS2020 based tuners
tua6100 Infineon TUA6100 PLL
cx24113 Conexant CX24113/CX24128 tuner for DVB-S/DSS
itd1000 Integrant ITD1000 Zero IF tuner for DVB-S/DSS
diff --git a/Documentation/admin-guide/media/gspca-cardlist.rst b/Documentation/admin-guide/media/gspca-cardlist.rst
index adda933..e3404d1 100644
--- a/Documentation/admin-guide/media/gspca-cardlist.rst
+++ b/Documentation/admin-guide/media/gspca-cardlist.rst
@@ -305,7 +305,7 @@
pac7302 093a:2626 Labtec 2200
pac7302 093a:2627 Genius FaceCam 300
pac7302 093a:2628 Genius iLook 300
-pac7302 093a:2629 Genious iSlim 300
+pac7302 093a:2629 Genius iSlim 300
pac7302 093a:262a Webcam 300k
pac7302 093a:262c Philips SPC 230 NC
jl2005bcd 0979:0227 Various brands, 19 known cameras supported
diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst
index 07d139b..f59697c 100644
--- a/Documentation/admin-guide/media/ipu3.rst
+++ b/Documentation/admin-guide/media/ipu3.rst
@@ -86,7 +86,7 @@
Let us take the example of ov5670 sensor connected to CSI2 port 0, for a
2592x1944 image capture.
-Using the media contorller APIs, the ov5670 sensor is configured to send
+Using the media controller APIs, the ov5670 sensor is configured to send
frames in packed raw Bayer format to IPU3 CSI2 receiver.
.. code-block:: none
@@ -313,8 +313,8 @@
**Geometric Distortion Correction**
-Geometric Distortion Correction is used to performe correction of distortions
-and image filtering. It needs some extra filter and envelop padding pixels to
+Geometric Distortion Correction is used to perform correction of distortions
+and image filtering. It needs some extra filter and envelope padding pixels to
work, so the input resolution of GDC should be larger than the output
resolution.
diff --git a/Documentation/admin-guide/media/remote-controller.rst b/Documentation/admin-guide/media/remote-controller.rst
index fa05410..188944b 100644
--- a/Documentation/admin-guide/media/remote-controller.rst
+++ b/Documentation/admin-guide/media/remote-controller.rst
@@ -68,7 +68,7 @@
Xorg recognizes several IR keycodes that have its numerical value lower
than 247. With the advent of Wayland, the input driver got updated too,
-and should now accept all keycodes. Yet, you may want to just reasign
+and should now accept all keycodes. Yet, you may want to just reassign
the keycodes to something that your favorite media application likes.
This can be done by setting
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/index.rst b/Documentation/admin-guide/mm/index.rst
index cd727cf..4b14d8b 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -3,9 +3,9 @@
=================
Linux memory management subsystem is responsible, as the name implies,
-for managing the memory in the system. This includes implemnetation of
+for managing the memory in the system. This includes implementation of
virtual memory and demand paging, memory allocation both for kernel
-internal structures and user space programms, mapping of files into
+internal structures and user space programs, mapping of files into
processes address space and many other cool things.
Linux memory management is a complex system with many configurable
diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
index 86f2a3c..c2f8264 100644
--- a/Documentation/admin-guide/mm/numaperf.rst
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -74,7 +74,7 @@
/sys/devices/system/node/nodeY/access0/initiators/
These attributes apply only when accessed from nodes that have the
-are linked under the this access's inititiators.
+are linked under the this access's initiators.
The performance characteristics the kernel provides for the local initiators
are exported are as follows::
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/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
index 1dc2d5f..65eefa6 100644
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -114,7 +114,7 @@
you must provide some kind of page in your thread after reading from
the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``.
The normal behavior of the OS automatically providing a zero page on
- an annonymous mmaping is not in place.
+ an anonymous mmaping is not in place.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index f8b5841..7d7c7c8 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -106,7 +106,7 @@
certificate and a private key.
If the PEM file containing the private key is encrypted, or if the
- PKCS#11 token requries a PIN, this can be provided at build time by
+ PKCS#11 token requires a PIN, this can be provided at build time by
means of the ``KBUILD_SIGN_PIN`` variable.
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/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
index f05f56c..90926d0 100644
--- a/Documentation/admin-guide/perf/imx-ddr.rst
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -4,7 +4,7 @@
There are no performance counters inside the DRAM controller, so performance
signals are brought out to the edge of the controller where a set of 4 x 32 bit
-counters is implemented. This is controlled by the CSV modes programed in counter
+counters is implemented. This is controlled by the CSV modes programmed in counter
control register which causes a large number of PERF signals to be generated.
Selection of the value for each counter is done via the config registers. There
diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst
index 219f135..0a1fbdb 100644
--- a/Documentation/admin-guide/pm/intel-speed-select.rst
+++ b/Documentation/admin-guide/pm/intel-speed-select.rst
@@ -57,7 +57,7 @@
Summary of platform capability
------------------------------
-To check the current platform and driver capaibilities, execute::
+To check the current platform and driver capabilities, execute::
#intel-speed-select --info
@@ -658,7 +658,7 @@
Intel(R) SST-BF:
- Discover Intel(R) SST-BF and note low and high priority base frequency
-- Note the high prioity CPU list
+- Note the high priority CPU list
- Enable CLOS using core-power feature set
- Configure CLOS parameters. Use CLOS.min to set to minimum performance
- Subscribe desired CPUs to CLOS groups
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst
index 5072e70..df29b4f 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -56,7 +56,7 @@
``intel_pstate`` can operate in two different modes, active or passive. In the
active mode, it uses its own internal performance scaling governor algorithm or
-allows the hardware to do preformance scaling by itself, while in the passive
+allows the hardware to do performance scaling by itself, while in the passive
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
a certain performance scaling algorithm. Which of them will be in effect
depends on what kernel command line options are used and on the capabilities of
@@ -380,13 +380,13 @@
``no_turbo``
If set (equal to 1), the driver is not allowed to set any turbo P-states
- (see `Turbo P-states Support`_). If unset (equalt to 0, which is the
+ (see `Turbo P-states Support`_). If unset (equal to 0, which is the
default), turbo P-states can be set by the driver.
[Note that ``intel_pstate`` does not support the general ``boost``
attribute (supported by some other scaling drivers) which is replaced
by this one.]
- This attrubute does not affect the maximum supported frequency value
+ This attribute does not affect the maximum supported frequency value
supplied to the ``CPUFreq`` core and exposed via the policy interface,
but it affects the maximum possible value of per-policy P-state limits
(see `Interpretation of Policy Attributes`_ below for details).
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/ramoops.rst b/Documentation/admin-guide/ramoops.rst
index a60a962..b0a1ae7 100644
--- a/Documentation/admin-guide/ramoops.rst
+++ b/Documentation/admin-guide/ramoops.rst
@@ -22,7 +22,7 @@
* ``mem_address`` for the start
* ``mem_size`` for the size. The memory size will be rounded down to a
power of two.
- * ``mem_type`` to specifiy if the memory type (default is pgprot_writecombine).
+ * ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use
diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
index 42481ea..409fa91 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -1,5 +1,10 @@
.. _reportingbugs:
+.. note::
+
+ This document is obsolete, and will be replaced by
+ 'Documentation/admin-guide/reporting-issues.rst' in the near future.
+
Reporting bugs
++++++++++++++
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
new file mode 100644
index 0000000..07879d0
--- /dev/null
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -0,0 +1,1631 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+..
+ If you want to distribute this text under CC-BY-4.0 only, please use 'The
+ Linux kernel developers' for author attribution and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
+
+.. important::
+
+ This document is being prepared to replace
+ 'Documentation/admin-guide/reporting-bugs.rst'. The main work is done and
+ you are already free to follow its instructions when reporting issues to the
+ Linux kernel developers. But keep in mind, below text still needs a few
+ finishing touches and review. It was merged to the Linux kernel sources at
+ this stage to make this process easier and increase the text's visibility.
+
+ Any improvements for the text or other feedback is thus very much welcome.
+ Please send it to 'Thorsten Leemhuis <linux@leemhuis.info>' and 'Jonathan
+ Corbet <corbet@lwn.net>', ideally with 'Linux kernel mailing list (LKML)
+ <linux-kernel@vger.kernel.org>' and the 'Linux Kernel Documentation List
+ <linux-doc@vger.kernel.org>' in CC.
+
+ Areas in the text that still need work or discussion contain a hint like this
+ which point out the remaining issues; all of them start with the word "FIXME"
+ to make them easy to find.
+
+
+Reporting issues
+++++++++++++++++
+
+
+The short guide (aka TL;DR)
+===========================
+
+If you're facing multiple issues with the Linux kernel at once, report each
+separately to its developers. Try your best guess which kernel part might be
+causing the issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its
+developers expect to be told about issues. Note, it's rarely
+`bugzilla.kernel.org <https://bugzilla.kernel.org/>`_, as in almost all cases
+the report needs to be sent by email!
+
+Check the destination thoroughly for existing reports; also search the LKML
+archives and the web. Join existing discussion if you find matches. If you
+don't find any, install `the latest Linux mainline kernel
+<https://kernel.org/>`_. Make sure it's vanilla, thus is not patched or using
+add-on kernel modules. Also ensure the kernel is running in a healthy
+environment and is not already tainted before the issue occurs.
+
+If you can reproduce your issue with the mainline kernel, send a report to the
+destination you determined earlier. Make sure it includes all relevant
+information, which in case of a regression should mention the change that's
+causing it which can often can be found with a bisection. Also ensure the
+report reaches all people that need to know about it, for example the security
+team, the stable maintainers or the developers of the patch that causes a
+regression. Once the report is out, answer any questions that might be raised
+and help where you can. That includes keeping the ball rolling: every time a
+new rc1 mainline kernel is released, check if the issue is still happening
+there and attach a status update to your initial report.
+
+If you can not reproduce the issue with the mainline kernel, consider sticking
+with it; if you'd like to use an older version line and want to see it fixed
+there, first make sure it's still supported. Install its latest release as
+vanilla kernel. If you cannot reproduce the issue there, try to find the commit
+that fixed it in mainline or any discussion preceding it: those will often
+mention if backporting is planed or considered too complex. If backporting was
+not discussed, ask if it's in the cards. In case you don't find any commits or
+a preceding discussion, see the Linux-stable mailing list archives for existing
+reports, as it might be a regression specific to the version line. If it is,
+report it like you would report a problem in mainline (including the
+bisection).
+
+If you reached this point without a solution, ask for advice one the
+subsystem's mailing list.
+
+
+Step-by-step guide how to report issues to the kernel maintainers
+=================================================================
+
+The above TL;DR outlines roughly how to report issues to the Linux kernel
+developers. It might be all that's needed for people already familiar with
+reporting issues to Free/Libre & Open Source Software (FLOSS) projects. For
+everyone else there is this section. It is more detailed and uses a
+step-by-step approach. It still tries to be brief for readability and leaves
+out a lot of details; those are described below the step-by-step guide in a
+reference section, which explains each of the steps in more detail.
+
+Note: this section covers a few more aspects than the TL;DR and does things in
+a slightly different order. That's in your interest, to make sure you notice
+early if an issue that looks like a Linux kernel problem is actually caused by
+something else. These steps thus help to ensure the time you invest in this
+process won't feel wasted in the end:
+
+ * Stop reading this document and report the problem to your vendor instead,
+ unless you are running the latest mainline kernel already or are willing to
+ install it. This kernel must not be modified or enhanced in any way, and
+ thus be considered 'vanilla'.
+
+ * See if the issue you are dealing with qualifies as regression, security
+ issue, or a really severe problem: those are 'issues of high priority' that
+ need special handling in some steps that are about to follow.
+
+ * Check if your kernel was 'tainted' when the issue occurred, as the event
+ that made the kernel set this flag might be causing the issue you face.
+
+ * Locate the driver or kernel subsystem that seems to be causing the issue.
+ Find out how and where its developers expect reports. Note: most of the
+ time this won't be bugzilla.kernel.org, as issues typically need to be sent
+ by mail to a maintainer and a public mailing list.
+
+ * Search the archives of the bug tracker or mailing list in question
+ thoroughly for reports that might match your issue. Also check if you find
+ something with your favorite internet search engine or in the Linux Kernel
+ Mailing List (LKML) archives. If you find anything, join the discussion
+ instead of sending a new report.
+
+ * Create a fresh backup and put system repair and restore tools at hand.
+
+ * Ensure your system does not enhance its kernels by building additional
+ kernel modules on-the-fly, which solutions like DKMS might be doing locally
+ without your knowledge.
+
+ * Make sure it's not the kernel's surroundings that are causing the issue
+ you face.
+
+ * Write down coarsely how to reproduce the issue. If you deal with multiple
+ issues at once, create separate notes for each of them and make sure they
+ work independently on a freshly booted system. That's needed, as each issue
+ needs to get reported to the kernel developers separately, unless they are
+ strongly entangled.
+
+After these preparations you'll now enter the main part:
+
+ * Install the latest Linux mainline kernel: that's where all issues get
+ fixed first, because it's the version line the kernel developers mainly
+ care about. Testing and reporting with the latest Linux stable kernel can
+ be an acceptable alternative in some situations, for example during the
+ merge window; but during that period you might want to suspend your efforts
+ till its end anyway.
+
+ * Ensure the kernel you just installed does not 'taint' itself when
+ running.
+
+ * Reproduce the issue with the kernel you just installed. If it doesn't show
+ up there, head over to the instructions for issues only happening with
+ stable and longterm kernels.
+
+ * Optimize your notes: try to find and write the most straightforward way to
+ reproduce your issue. Make sure the end result has all the important
+ details, and at the same time is easy to read and understand for others
+ that hear about it for the first time. And if you learned something in this
+ process, consider searching again for existing reports about the issue.
+
+ * If the failure includes a stack dump, like an Oops does, consider decoding
+ it to find the offending line of code.
+
+ * If your problem is a regression, try to narrow down when the issue was
+ introduced as much as possible.
+
+ * Start to compile the report by writing a detailed description about the
+ issue. Always mention a few things: the latest kernel version you installed
+ for reproducing, the Linux Distribution used, and your notes on how to
+ reproduce the issue. Ideally, make the kernel's build configuration
+ (.config) and the output from ``dmesg`` available somewhere on the net and
+ link to it. Include or upload all other information that might be relevant,
+ like the output/screenshot of an Oops or the output from ``lspci``. Once
+ you wrote this main part, insert a normal length paragraph on top of it
+ outlining the issue and the impact quickly. On top of this add one sentence
+ that briefly describes the problem and gets people to read on. Now give the
+ thing a descriptive title or subject that yet again is shorter. Then you're
+ ready to send or file the report like the MAINTAINERS file told you, unless
+ you are dealing with one of those 'issues of high priority': they need
+ special care which is explained in 'Special handling for high priority
+ issues' below.
+
+ * Wait for reactions and keep the thing rolling until you can accept the
+ outcome in one way or the other. Thus react publicly and in a timely manner
+ to any inquiries. Test proposed fixes. Do proactive testing: retest with at
+ least every first release candidate (RC) of a new mainline version and
+ report your results. Send friendly reminders if things stall. And try to
+ help yourself, if you don't get any help or if it's unsatisfying.
+
+
+Reporting issues only occurring in older kernel version lines
+-------------------------------------------------------------
+
+This section is for you, if you tried the latest mainline kernel as outlined
+above, but failed to reproduce your issue there; at the same time you want to
+see the issue fixed in older version lines or a vendor kernel that's regularly
+rebased on new stable or longterm releases. If that case follow these steps:
+
+ * Prepare yourself for the possibility that going through the next few steps
+ might not get the issue solved in older releases: the fix might be too big
+ or risky to get backported there.
+
+ * Check if the kernel developers still maintain the Linux kernel version
+ line you care about: go to the front page of kernel.org and make sure it
+ mentions the latest release of the particular version line without an
+ '[EOL]' tag.
+
+ * Check the archives of the Linux stable mailing list for existing reports.
+
+ * Install the latest release from the particular version line as a vanilla
+ kernel. Ensure this kernel is not tainted and still shows the problem, as
+ the issue might have already been fixed there.
+
+ * Search the Linux kernel version control system for the change that fixed
+ the issue in mainline, as its commit message might tell you if the fix is
+ scheduled for backporting already. If you don't find anything that way,
+ search the appropriate mailing lists for posts that discuss such an issue
+ or peer-review possible fixes; then check the discussions if the fix was
+ deemed unsuitable for backporting. If backporting was not considered at
+ all, join the newest discussion, asking if it's in the cards.
+
+ * Check if you're dealing with a regression that was never present in
+ mainline by installing the first release of the version line you care
+ about. If the issue doesn't show up with it, you basically need to report
+ the issue with this version like you would report a problem with mainline
+ (see above). This ideally includes a bisection followed by a search for
+ existing reports on the net; with the help of the subject and the two
+ relevant commit-ids. If that doesn't turn up anything, write the report; CC
+ or forward the report to the stable maintainers, the stable mailing list,
+ and those who authored the change. Include the shortened commit-id if you
+ found the change that causes it.
+
+ * One of the former steps should lead to a solution. If that doesn't work
+ out, ask the maintainers for the subsystem that seems to be causing the
+ issue for advice; CC the mailing list for the particular subsystem as well
+ as the stable mailing list.
+
+
+Reference section: Reporting issues to the kernel maintainers
+=============================================================
+
+The detailed guides above outline all the major steps in brief fashion, which
+should be enough for most people. But sometimes there are situations where even
+experienced users might wonder how to actually do one of those steps. That's
+what this section is for, as it will provide a lot more details on each of the
+above steps. Consider this as reference documentation: it's possible to read it
+from top to bottom. But it's mainly meant to skim over and a place to look up
+details how to actually perform those steps.
+
+A few words of general advice before digging into the details:
+
+ * The Linux kernel developers are well aware this process is complicated and
+ demands more than other FLOSS projects. We'd love to make it simpler. But
+ that would require work in various places as well as some infrastructure,
+ which would need constant maintenance; nobody has stepped up to do that
+ work, so that's just how things are for now.
+
+ * A warranty or support contract with some vendor doesn't entitle you to
+ request fixes from developers in the upstream Linux kernel community: such
+ contracts are completely outside the scope of the Linux kernel, its
+ development community, and this document. That's why you can't demand
+ anything such a contract guarantees in this context, not even if the
+ developer handling the issue works for the vendor in question. If you want
+ to claim your rights, use the vendor's support channel instead. When doing
+ so, you might want to mention you'd like to see the issue fixed in the
+ upstream Linux kernel; motivate them by saying it's the only way to ensure
+ the fix in the end will get incorporated in all Linux distributions.
+
+ * If you never reported an issue to a FLOSS project before you should consider
+ reading `How to Report Bugs Effectively
+ <https://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_, `How To Ask
+ Questions The Smart Way
+ <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good
+ questions <https://jvns.ca/blog/good-questions/>`_.
+
+With that off the table, find below the details on how to properly report
+issues to the Linux kernel developers.
+
+
+Make sure you're using the upstream Linux kernel
+------------------------------------------------
+
+ *Stop reading this document and report the problem to your vendor instead,
+ unless you are running the latest mainline kernel already or are willing to
+ install it. This kernel must not be modified or enhanced in any way, and
+ thus be considered 'vanilla'.*
+
+Like most programmers, Linux kernel developers don't like to spend time dealing
+with reports for issues that don't even happen with the source code they
+maintain: it's just a waste everybody's time, yours included. That's why you
+later will have to test your issue with the latest 'vanilla' kernel: a kernel
+that was build using the Linux sources taken straight from `kernel.org
+<https://kernel.org/>`_ and not modified or enhanced in any way.
+
+Almost all kernels used in devices (Computers, Laptops, Smartphones, Routers,
+…) and most kernels shipped by Linux distributors are ancient from the point of
+kernel development and heavily modified. They thus do not qualify for reporting
+an issue to the Linux kernel developers: the issue you face with such a kernel
+might be fixed already or caused by the changes or additions, even if they look
+small or totally unrelated. That's why issues with such kernels need to be
+reported to the vendor that distributed it. Its developers should look into the
+report and, in case it turns out to be an upstream issue, fix it directly
+upstream or report it there. In practice that sometimes does not work out. If
+that the case, you might want to circumvent the vendor by installing the latest
+mainline kernel yourself and reporting the issue as outlined in this document;
+just make sure to use really fresh kernel (see below).
+
+
+.. note::
+
+ FIXME: Should we accept reports for issues with kernel images that are pretty
+ close to vanilla? But when are they close enough and how to put that line in
+ words? Maybe something like this?
+
+ *Note: Some Linux kernel developers accept reports from vendor kernels that
+ are known to be close to upstream. That for example is often the case for
+ the kernels that Debian GNU/Linux Sid or Fedora Rawhide ship, which are
+ normally following mainline closely and carry only a few patches. So a
+ report with one of these might be accepted by the developers that need to
+ handle it. But if they do, depends heavily on the individual developers and
+ the issue at hand. That's why installing a mainline vanilla kernel is the
+ safe bet.*
+
+ *Arch Linux, other Fedora releases, and openSUSE Tumbleweed often use quite
+ recent stable kernels that are pretty close to upstream, too. Some
+ developers accept bugs from them as well. But note that you normally should
+ avoid stable kernels for reporting issues and use a mainline kernel instead
+ (see below).*
+
+ Are there any other major Linux distributions that should be mentioned here?
+
+
+Issue of high priority?
+-----------------------
+
+ *See if the issue you are dealing with qualifies as regression, security
+ issue, or a really severe problem: those are 'issues of high priority' that
+ need special handling in some steps that are about to follow.*
+
+Linus Torvalds and the leading Linux kernel developers want to see some issues
+fixed as soon as possible, hence there are 'issues of high priority' that get
+handled slightly differently in the reporting process. Three type of cases
+qualify: regressions, security issues, and really severe problems.
+
+You deal with a 'regression' if something that worked with an older version of
+the Linux kernel does not work with a newer one or somehow works worse with it.
+It thus is a regression when a WiFi driver that did a fine job with Linux 5.7
+somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if
+an application shows erratic behavior with a newer kernel, which might happen
+due to incompatible changes in the interface between the kernel and the
+userland (like procfs and sysfs). Significantly reduced performance or
+increased power consumption also qualify as regression. But keep in mind: the
+new kernel needs to be built with a configuration that is similar to the one
+from the old kernel (see below how to achieve that). That's because the kernel
+developers sometimes can not avoid incompatibilities when implementing new
+features; but to avoid regressions such features have to be enabled explicitly
+during build time configuration.
+
+What qualifies as security issue is left to your judgment. Consider reading
+'Documentation/admin-guide/security-bugs.rst' before proceeding, as it
+provides additional details how to best handle security issues.
+
+An issue is a 'really severe problem' when something totally unacceptably bad
+happens. That's for example the case when a Linux kernel corrupts the data it's
+handling or damages hardware it's running on. You're also dealing with a severe
+issue when the kernel suddenly stops working with an error message ('kernel
+panic') or without any farewell note at all. Note: do not confuse a 'panic' (a
+fatal error where the kernel stop itself) with a 'Oops' (a recoverable error),
+as the kernel remains running after the latter.
+
+
+Check 'taint' flag
+------------------
+
+ *Check if your kernel was 'tainted' when the issue occurred, as the event
+ that made the kernel set this flag might be causing the issue you face.*
+
+The kernel marks itself with a 'taint' flag when something happens that might
+lead to follow-up errors that look totally unrelated. The issue you face might
+be such an error if your kernel is tainted. That's why it's in your interest to
+rule this out early before investing more time into this process. This is the
+only reason why this step is here, as this process later will tell you to
+install the latest mainline kernel; you will need to check the taint flag again
+then, as that's when it matters because it's the kernel the report will focus
+on.
+
+On a running system is easy to check if the kernel tainted itself: if ``cat
+/proc/sys/kernel/tainted`` returns '0' then the kernel is not tainted and
+everything is fine. Checking that file is impossible in some situations; that's
+why the kernel also mentions the taint status when it reports an internal
+problem (a 'kernel bug'), a recoverable error (a 'kernel Oops') or a
+non-recoverable error before halting operation (a 'kernel panic'). Look near
+the top of the error messages printed when one of these occurs and search for a
+line starting with 'CPU:'. It should end with 'Not tainted' if the kernel was
+not tainted when it noticed the problem; it was tainted if you see 'Tainted:'
+followed by a few spaces and some letters.
+
+If your kernel is tainted, study 'Documentation/admin-guide/tainted-kernels.rst'
+to find out why. Try to eliminate the reason. Often it's caused by one these
+three things:
+
+ 1. A recoverable error (a 'kernel Oops') occurred and the kernel tainted
+ itself, as the kernel knows it might misbehave in strange ways after that
+ point. In that case check your kernel or system log and look for a section
+ that starts with this::
+
+ Oops: 0000 [#1] SMP
+
+ That's the first Oops since boot-up, as the '#1' between the brackets shows.
+ Every Oops and any other problem that happens after that point might be a
+ follow-up problem to that first Oops, even if both look totally unrelated.
+ Rule this out by getting rid of the cause for the first Oops and reproducing
+ the issue afterwards. Sometimes simply restarting will be enough, sometimes
+ a change to the configuration followed by a reboot can eliminate the Oops.
+ But don't invest too much time into this at this point of the process, as
+ the cause for the Oops might already be fixed in the newer Linux kernel
+ version you are going to install later in this process.
+
+ 2. Your system uses a software that installs its own kernel modules, for
+ example Nvidia's proprietary graphics driver or VirtualBox. The kernel
+ taints itself when it loads such module from external sources (even if
+ they are Open Source): they sometimes cause errors in unrelated kernel
+ areas and thus might be causing the issue you face. You therefore have to
+ prevent those modules from loading when you want to report an issue to the
+ Linux kernel developers. Most of the time the easiest way to do that is:
+ temporarily uninstall such software including any modules they might have
+ installed. Afterwards reboot.
+
+ 3. The kernel also taints itself when it's loading a module that resides in
+ the staging tree of the Linux kernel source. That's a special area for
+ code (mostly drivers) that does not yet fulfill the normal Linux kernel
+ quality standards. When you report an issue with such a module it's
+ obviously okay if the kernel is tainted; just make sure the module in
+ question is the only reason for the taint. If the issue happens in an
+ unrelated area reboot and temporarily block the module from being loaded
+ by specifying ``foo.blacklist=1`` as kernel parameter (replace 'foo' with
+ the name of the module in question).
+
+
+Locate kernel area that causes the issue
+----------------------------------------
+
+ *Locate the driver or kernel subsystem that seems to be causing the issue.
+ Find out how and where its developers expect reports. Note: most of the
+ time this won't be bugzilla.kernel.org, as issues typically need to be sent
+ by mail to a maintainer and a public mailing list.*
+
+It's crucial to send your report to the right people, as the Linux kernel is a
+big project and most of its developers are only familiar with a small subset of
+it. Quite a few programmers for example only care for just one driver, for
+example one for a WiFi chip; its developer likely will only have small or no
+knowledge about the internals of remote or unrelated "subsystems", like the TCP
+stack, the PCIe/PCI subsystem, memory management or file systems.
+
+Problem is: the Linux kernel lacks a central bug tracker where you can simply
+file your issue and make it reach the developers that need to know about it.
+That's why you have to find the right place and way to report issues yourself.
+You can do that with the help of a script (see below), but it mainly targets
+kernel developers and experts. For everybody else the MAINTAINERS file is the
+better place.
+
+How to read the MAINTAINERS file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To illustrate how to use the :ref:`MAINTAINERS <maintainers>` file, lets assume
+the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that
+case it's likely an issue in the WiFi driver. Obviously it could also be some
+code it builds upon, but unless you suspect something like that stick to the
+driver. If it's really something else, the driver's developers will get the
+right people involved.
+
+Sadly, there is no way to check which code is driving a particular hardware
+component that is both universal and easy.
+
+In case of a problem with the WiFi driver you for example might want to look at
+the output of ``lspci -k``, as it lists devices on the PCI/PCIe bus and the
+kernel module driving it::
+
+ [user@something ~]$ lspci -k
+ [...]
+ 3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
+ Subsystem: Bigfoot Networks, Inc. Device 1535
+ Kernel driver in use: ath10k_pci
+ Kernel modules: ath10k_pci
+ [...]
+
+But this approach won't work if your WiFi chip is connected over USB or some
+other internal bus. In those cases you might want to check your WiFi manager or
+the output of ``ip link``. Look for the name of the problematic network
+interface, which might be something like 'wlp58s0'. This name can be used like
+this to find the module driving it::
+
+ [user@something ~]$ realpath --relative-to=/sys/module/ /sys/class/net/wlp58s0/device/driver/module
+ ath10k_pci
+
+In case tricks like these don't bring you any further, try to search the
+internet on how to narrow down the driver or subsystem in question. And if you
+are unsure which it is: just try your best guess, somebody will help you if you
+guessed poorly.
+
+Once you know the driver or subsystem, you want to search for it in the
+MAINTAINERS file. In the case of 'ath10k_pci' you won't find anything, as the
+name is too specific. Sometimes you will need to search on the net for help;
+but before doing so, try a somewhat shorted or modified name when searching the
+MAINTAINERS file, as then you might find something like this::
+
+ QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
+ Mail: A. Some Human <shuman@example.com>
+ Mailing list: ath10k@lists.infradead.org
+ Status: Supported
+ Web-page: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
+ SCM: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
+ Files: drivers/net/wireless/ath/ath10k/
+
+Note: the line description will be abbreviations, if you read the plain
+MAINTAINERS file found in the root of the Linux source tree. 'Mail:' for
+example will be 'M:', 'Mailing list:' will be 'L', and 'Status:' will be 'S:'.
+A section near the top of the file explains these and other abbreviations.
+
+First look at the line 'Status'. Ideally it should be 'Supported' or
+'Maintained'. If it states 'Obsolete' then you are using some outdated approach
+that was replaced by a newer solution you need to switch to. Sometimes the code
+only has someone who provides 'Odd Fixes' when feeling motivated. And with
+'Orphan' you are totally out of luck, as nobody takes care of the code anymore.
+That only leaves these options: arrange yourself to live with the issue, fix it
+yourself, or find a programmer somewhere willing to fix it.
+
+After checking the status, look for a line starting with 'bugs:': it will tell
+you where to find a subsystem specific bug tracker to file your issue. The
+example above does not have such a line. That is the case for most sections, as
+Linux kernel development is completely driven by mail. Very few subsystems use
+a bug tracker, and only some of those rely on bugzilla.kernel.org.
+
+
+.. note::
+
+ FIXME: The old text took a totally different approach to bugzilla.kernel.org,
+ as it mentions it as the place to file issue for people that don't known how
+ to contact the appropriate people. The new one mentions it rarely; and when
+ it does like here, it warns users that it's often the wrong place to go.
+
+ This approach was chosen as the main author of this document noticed quite a
+ few users (or even a lot?) get no reply to the bugs they file in bugzilla.
+ That's kind of expected, as quite a few (many? most?) of the maintainers
+ don't even get notified when reports for their subsystem get filed there. And
+ not getting a single reply to report is something that is just annoying for
+ users and might make them angry. Improving bugzilla.k.o would be an option,
+ but on the kernel and maintainers summit 2017 it was agreed on to first go
+ this route (sorry it took so long): it's easier to achieve and less
+ controversial, as putting additional burden on already overworked maintainers
+ is unlikely to get well received.
+
+
+In this and many other cases you thus have to look for lines starting with
+'Mail:' instead. Those mention the name and the email addresses for the
+maintainers of the particular code. Also look for a line starting with 'Mailing
+list:', which tells you the public mailing list where the code is developed.
+Your report later needs to go by mail to those addresses. Additionally, for all
+issue reports sent by email, make sure to add the Linux Kernel Mailing List
+(LKML) <linux-kernel@vger.kernel.org> to CC. Don't omit either of the mailing
+lists when sending your issue report by mail later! Maintainers are busy people
+and might leave some work for other developers on the subsystem specific list;
+and LKML is important to have one place where all issue reports can be found.
+
+
+.. note::
+
+ FIXME: Above section tells users to always CC LKML. These days it's a kind of
+ "catch-all" list anyway, which nearly nobody seems to follow closely. So it
+ seems appropriate to go "all in" and make people send their reports here,
+ too, as everything (reports, fixes, ...) then can be found in one place (at
+ least for all reports sent by mail and all subsystems that CC LKML).
+
+ Related: Should we create mailing list like 'linux-issues@vger.kernel.org'
+ and tell users above to always CC it when reporting issues? Then there would
+ be one central place reporters could search for existing reports (at least
+ for issues reported by mail) without getting regular LKML traffic mixed into
+ the results.
+
+
+Finding the maintainers with the help of a script
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For people that have the Linux sources at hand there is a second option to find
+the proper place to report: the script 'scripts/get_maintainer.pl' which tries
+to find all people to contact. It queries the MAINTAINERS file and needs to be
+called with a path to the source code in question. For drivers compiled as
+module if often can be found with a command like this::
+
+ $ modinfo ath10k_pci | grep filename | sed 's!/lib/modules/.*/kernel/!!; s!filename:!!; s!\.ko\(\|\.xz\)!!'
+ drivers/net/wireless/ath/ath10k/ath10k_pci.ko
+
+Pass parts of this to the script::
+
+ $ ./scripts/get_maintainer.pl -f drivers/net/wireless/ath/ath10k*
+ Some Human <shuman@example.com> (supporter:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
+ Another S. Human <asomehuman@example.com> (maintainer:NETWORKING DRIVERS)
+ ath10k@lists.infradead.org (open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER)
+ linux-wireless@vger.kernel.org (open list:NETWORKING DRIVERS (WIRELESS))
+ netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
+ linux-kernel@vger.kernel.org (open list)
+
+Don't sent your report to all of them. Send it to the maintainers, which the
+script calls "supporter:"; additionally CC the most specific mailing list for
+the code as well as the Linux Kernel Mailing List (LKML). In this case you thus
+would need to send the report to 'Some Human <shuman@example.com>' with
+'ath10k@lists.infradead.org' and 'linux-kernel@vger.kernel.org' in CC.
+
+Note: in case you cloned the Linux sources with git you might want to call
+``get_maintainer.pl`` a second time with ``--git``. The script then will look
+at the commit history to find which people recently worked on the code in
+question, as they might be able to help. But use these results with care, as it
+can easily send you in a wrong direction. That for example happens quickly in
+areas rarely changed (like old or unmaintained drivers): sometimes such code is
+modified during tree-wide cleanups by developers that do not care about the
+particular driver at all.
+
+
+Search for existing reports
+---------------------------
+
+ *Search the archives of the bug tracker or mailing list in question
+ thoroughly for reports that might match your issue. Also check if you find
+ something with your favorite internet search engine or in the Linux Kernel
+ Mailing List (LKML) archives. If you find anything, join the discussion
+ instead of sending a new report.*
+
+Reporting an issue that someone else already brought forward is often a waste
+of time for everyone involved, especially you as the reporter. So it's in your
+own interest to thoroughly check if somebody reported the issue already. Thus
+do not hurry with this step of the reporting process. Spending 30 to 60 minutes
+or even more time can save you and others quite a lot of time and trouble.
+
+The best place to search is the bug tracker or the mailing list where your
+report needs to be filed. You'll find quite a few of those lists on
+`lore.kernel.org <https://lore.kernel.org/>`_, but some are hosted in
+different places. That for example is the case for the ath10k WiFi driver used
+as example in the previous step. But you'll often find the archives for these
+lists easily on the net. Searching for 'archive ath10k@lists.infradead.org' for
+example will quickly lead you to the `Info page for the ath10k mailing list
+<https://lists.infradead.org/mailman/listinfo/ath10k>`_, which at the top links
+to its `list archives <https://lists.infradead.org/pipermail/ath10k/>`_.
+
+Sadly this and quite a few other lists miss a way to search the archives. In
+those cases use a regular internet search engine and add something like
+'site:lists.infradead.org/pipermail/ath10k/' to your search terms, which limits
+the results to the archives at that URL.
+
+Additionally, search the internet and the `Linux Kernel Mailing List (LKML)
+archives <https://lore.kernel.org/lkml/>`_, as maybe the real culprit might be
+in some other subsystem. Searching in `bugzilla.kernel.org
+<https://bugzilla.kernel.org/>`_ might also be a good idea, but if you find
+anything there keep in mind: most subsystems expect reports in different
+places, hence those you find there might have not even reached the people
+responsible for the subsystem in question. Nevertheless, the data there might
+provide valuable insights.
+
+If you get flooded with results consider telling your search engine to limit
+search timeframe to the past month or year. And wherever you search, make sure
+to use good search terms; vary them a few times, too. While doing so try to
+look at the issue from the perspective of someone else: that will help you to
+come up with other words to use as search terms. Also make sure not to use too
+many search terms at once. Remember to search with and without information like
+the name of the kernel driver or the name of the affected hardware component.
+But its exact brand name (say 'ASUS Red Devil Radeon RX 5700 XT Gaming OC')
+often is not much helpful, as it is too specific. Instead try search terms like
+the model line (Radeon 5700 or Radeon 5000) and the code name of the main chip
+('Navi' or 'Navi10') with and without its manufacturer ('AMD').
+
+In case you find an existing report about your issue, join the discussion, as
+you might be able to provide valuable additional information. That can be
+important even when a fix is prepared or in its final stages already, as
+developers might look for people that can provide additional information or
+test a proposed fix. Jump to the section 'Duties after the report went out' for
+details on how to get properly involved.
+
+
+Prepare for emergencies
+-----------------------
+
+ *Create a fresh backup and put system repair and restore tools at hand.*
+
+Reminder, you are dealing with computers, which sometimes do unexpected things,
+especially if you fiddle with crucial parts like the kernel of its operating
+system. That's what you are about to do in this process. Thus, make sure to
+create a fresh backup; also ensure you have all tools at hand to repair or
+reinstall the operating system as well as everything you need to restore the
+backup.
+
+
+Make sure your kernel doesn't get enhanced
+------------------------------------------
+
+ *Ensure your system does not enhance its kernels by building additional
+ kernel modules on-the-fly, which solutions like DKMS might be doing locally
+ without your knowledge.*
+
+Your kernel must be 'vanilla' when reporting an issue, but stops being pure as
+soon as it loads a kernel module not built from the sources used to compile the
+kernel image itself. That's why you need to ensure your Linux kernel stays
+vanilla by removing or disabling mechanisms like akmods and DKMS: those might
+build additional kernel modules automatically, for example when your boot into
+a newly installed Linux kernel the first time. Reboot after removing them and
+any modules they installed.
+
+Note, you might not be aware that your system is using one of these solutions:
+they often get set up silently when you install Nvidia's proprietary graphics
+driver, VirtualBox, or other software that requires a some support from a
+module not part of the Linux kernel. That why your might need to uninstall the
+packages with such software to get rid of any 3rd party kernel module.
+
+
+Ensure a healthy environment
+----------------------------
+
+ *Make sure it's not the kernel's surroundings that are causing the issue
+ you face.*
+
+Problems that look a lot like a kernel issue are sometimes caused by build or
+runtime environment. It's hard to rule out that problem completely, but you
+should minimize it:
+
+ * Use proven tools when building your kernel, as bugs in the compiler or the
+ binutils can cause the resulting kernel to misbehave.
+
+ * Ensure your computer components run within their design specifications;
+ that's especially important for the main processor, the main memory, and the
+ motherboard. Therefore, stop undervolting or overclocking when facing a
+ potential kernel issue.
+
+ * Try to make sure it's not faulty hardware that is causing your issue. Bad
+ main memory for example can result in a multitude of issues that will
+ manifest itself in problems looking like kernel issues.
+
+ * If you're dealing with a filesystem issue, you might want to check the file
+ system in question with ``fsck``, as it might be damaged in a way that leads
+ to unexpected kernel behavior.
+
+ * When dealing with a regression, make sure it's not something else that
+ changed in parallel to updating the kernel. The problem for example might be
+ caused by other software that was updated at the same time. It can also
+ happen that a hardware component coincidentally just broke when you rebooted
+ into a new kernel for the first time. Updating the systems BIOS or changing
+ something in the BIOS Setup can also lead to problems that on look a lot
+ like a kernel regression.
+
+
+Document how to reproduce issue
+-------------------------------
+
+ *Write down coarsely how to reproduce the issue. If you deal with multiple
+ issues at once, create separate notes for each of them and make sure they
+ work independently on a freshly booted system. That's needed, as each issue
+ needs to get reported to the kernel developers separately, unless they are
+ strongly entangled.*
+
+If you deal with multiple issues at once, you'll have to report each of them
+separately, as they might be handled by different developers. Describing
+various issues in one report also makes it quite difficult for others to tear
+it apart. Hence, only combine issues in one report if they are very strongly
+entangled.
+
+Additionally, during the reporting process you will have to test if the issue
+happens with other kernel versions. Therefore, it will make your work easier if
+you know exactly how to reproduce an issue quickly on a freshly booted system.
+
+Note: it's often fruitless to report issues that only happened once, as they
+might be caused by a bit flip due to cosmic radiation. That's why you should
+try to rule that out by reproducing the issue before going further. Feel free
+to ignore this advice if you are experienced enough to tell a one-time error
+due to faulty hardware apart from a kernel issue that rarely happens and thus
+is hard to reproduce.
+
+
+Install a fresh kernel for testing
+----------------------------------
+
+ *Install the latest Linux mainline kernel: that's where all issues get
+ fixed first, because it's the version line the kernel developers mainly
+ care about. Testing and reporting with the latest Linux stable kernel can
+ be an acceptable alternative in some situations, for example during the
+ merge window; but during that period you might want to suspend your efforts
+ till its end anyway.*
+
+Reporting an issue to the Linux kernel developers they fixed weeks or months
+ago is annoying for them and wasting their and your time. That's why it's in
+everybody's interest to check if the issue occurs with the latest codebase
+before reporting it.
+
+In the scope of the Linux kernel the term 'latest' means: a kernel version
+recently created from the main line of development, as this 'mainline' tree is
+where developers first apply fixes; only after that are they are allowed to get
+backported to older, still supported version lines called 'stable' and
+'longterm' kernels. That's why you should check a recent mainline kernel, even
+if you deal with an issue you only want to see fixed in an older version line.
+Another reason: some fixes are only applied to mainline or recent version
+lines, as it's too hard or risky to backport them to older versions. If that
+the case, reporting the issue again is unlikely to change anything.
+
+Longterm kernels (sometimes called "LTS kernels") are therefore unsuitable for
+testing; they simply are too distant from current development. Even the latest
+Linux 'stable' kernel is a significant bit behind and thus better avoided. At
+least most of the time, as sometimes a stable kernel can the best choice; but
+in those situations you might want to wait a few days anyway:
+
+Choosing between mainline, stable and waiting
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Head over to `kernel.org <https://kernel.org/>`_ to decide which version to
+use. Ignore the big yellow button that says 'Latest release' and look a little
+lower for a table. At its top you'll see a line starting with 'mainline', which
+most of the time will point to a pre-release with a version number like
+'5.8-rc2'. If that's the case, you'll want to use this mainline kernel for
+testing. Do not let that 'rc' scare you, these 'development kernels' are pretty
+reliable — and you made a backup, as you were instructed above, didn't you?
+
+In about two out of every nine to ten weeks, 'mainline' might point you to a
+proper release with a version number like '5.7'. If that happens, consider
+suspending the reporting process until the first pre-release of the next
+version (5.8-rc1) shows up on kernel.org. That's because the Linux development
+cycle then is in its two-week long 'merge window'. The bulk of the changes and
+all intrusive ones get merged for the next release during this time. It's a bit
+more risky to use mainline during this period. Kernel developers are also often
+quite busy then and might have no spare time to deal with issue reports. It's
+also quite possible that one of the many changes applied during the merge
+window fixes the issue you face; that's why you soon would have to retest with
+a newer kernel version anyway, as outlined below in the section 'Duties after
+the report went out'.
+
+That's why it might make sense to wait till the merge window is over. But don't
+to that if you're dealing with something that shouldn't wait. In that case
+consider obtaining the latest mainline kernel via git (see below) or use the
+latest stable version offered on kernel.org. Using that is also acceptable in
+case mainline for some reason does currently not work for you. An in general:
+using it for reproducing the issue is also better than not reporting it issue
+at all.
+
+How to obtain a fresh Linux kernel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can use pre-built or self-compiled kernel for testing; if you choose the
+latter approach, you can either obtain the source code using git or download it
+as tar archive.
+
+Using a pre-compiled kernel for testing is often the quickest, easiest, and
+safest way – especially is you are unfamiliar with the Linux kernel. But it
+needs to be a vanilla kernel, which can be hard to come buy. You are in luck if
+you are using a popular Linux distribution: for quite a few of them you'll find
+repositories on the net that contain packages with the latest mainline or
+stable kernels in vanilla fashion. It's totally okay to use these, just make
+sure from the repository's documentation they are really vanilla. And ensure
+the packages contain the latest versions as offered on kernel.org; they are
+likely unsuitable if the package is older than a week, as new mainline and
+stable kernels typically get released at least once a week. And be aware that
+you might need to get build your own kernel later anyway when it comes to
+helping test fixes, as described later in this document.
+
+Developers and experienced Linux users familiar with git are often best served
+by obtaining the latest Linux kernel sources straight from the `official
+development repository on kernel.org
+<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_.
+Those are likely a bit ahead of the latest mainline pre-release. Don't worry
+about it: they are as reliable as a proper pre-release, unless the kernel's
+development cycle is currently in the middle of a merge window. But even then
+they are quite reliable.
+
+People unfamiliar with git are often best served by downloading the sources as
+tarball from `kernel.org <https://kernel.org/>`_.
+
+How to actually build a kernel isnot described here, as many websites explain
+the necessary steps already. If you are new to it, consider following one of
+those how-to's that suggest to use ``make localmodconfig``, as that tries to
+pick up the configuration of your current kernel and then tries to adjust it
+somewhat for your system. That does not make the resulting kernel any better,
+but quicker to compile.
+
+
+Check 'taint' flag
+------------------
+
+ *Ensure the kernel you just installed does not 'taint' itself when
+ running.*
+
+As outlined above in more detail already: the kernel sets a 'taint' flag when
+something happens that can lead to follow-up errors that look totally
+unrelated. That's why you need to check if the kernel you just installed does
+not set this flag. And if it does, you in almost all the cases needs to
+eliminate the reason for it before you reporting issues that occur with it. See
+the section above for details how to do that.
+
+
+Reproduce issue with the fresh kernel
+-------------------------------------
+
+ *Reproduce the issue with the kernel you just installed. If it doesn't show
+ up there, head over to the instructions for issues only happening with
+ stable and longterm kernels.*
+
+Check if the issue occurs with the fresh Linux kernel version you just
+installed. If it was fixed there already, consider sticking with this version
+line and abandoning your plan to report the issue. But keep in mind that other
+users might still be plagued by it, as long as it's not fixed in either stable
+and longterm version from kernel.org (and thus vendor kernels derived from
+those). If you prefer to use one of those or just want to help their users,
+head over to the section "Details about reporting issues only occurring in
+older kernel version lines" below.
+
+
+Optimize description to reproduce issue
+---------------------------------------
+
+ *Optimize your notes: try to find and write the most straightforward way to
+ reproduce your issue. Make sure the end result has all the important
+ details, and at the same time is easy to read and understand for others
+ that hear about it for the first time. And if you learned something in this
+ process, consider searching again for existing reports about the issue.*
+
+An unnecessarily complex report will make it hard for others to understand your
+report. Thus try to find a reproducer that's straight forward to describe and
+thus easy to understand in written form. Include all important details, but at
+the same time try to keep it as short as possible.
+
+In this in the previous steps you likely have learned a thing or two about the
+issue you face. Use this knowledge and search again for existing reports
+instead you can join.
+
+
+Decode failure messages
+-----------------------
+
+.. note::
+
+ FIXME: The text in this section is a placeholder for now and quite similar to
+ the old text found in 'Documentation/admin-guide/reporting-bugs.rst'
+ currently. It and the document it references are known to be outdated and
+ thus need to be revisited. Thus consider this note a request for help: if you
+ are familiar with this topic, please write a few lines that would fit here.
+ Alternatively, simply outline the current situation roughly to the main
+ authors of this document (see intro), as they might be able to write
+ something then.
+
+ This section in the end should answer questions like "when is this actually
+ needed", "what .config options to ideally set earlier to make this step easy
+ or unnecessary?" (likely CONFIG_UNWINDER_ORC when it's available, otherwise
+ CONFIG_UNWINDER_FRAME_POINTER; but is there anything else needed?).
+
+..
+
+ *If the failure includes a stack dump, like an Oops does, consider decoding
+ it to find the offending line of code.*
+
+When the kernel detects an error, it will print a stack dump that allows to
+identify the exact line of code where the issue happens. But that information
+sometimes needs to get decoded to be readable, which is explained in
+admin-guide/bug-hunting.rst.
+
+
+Special care for regressions
+----------------------------
+
+ *If your problem is a regression, try to narrow down when the issue was
+ introduced as much as possible.*
+
+Linux lead developer Linus Torvalds insists that the Linux kernel never
+worsens, that's why he deems regressions as unacceptable and wants to see them
+fixed quickly. That's why changes that introduced a regression are often
+promptly reverted if the issue they cause can't get solved quickly any other
+way. Reporting a regression is thus a bit like playing a kind of trump card to
+get something quickly fixed. But for that to happen the change that's causing
+the regression needs to be known. Normally it's up to the reporter to track
+down the culprit, as maintainers often won't have the time or setup at hand to
+reproduce it themselves.
+
+To find the change there is a process called 'bisection' which the document
+'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process
+will often require you to build about ten to twenty kernel images, trying to
+reproduce the issue with each of them before building the next. Yes, that takes
+some time, but don't worry, it works a lot quicker than most people assume.
+Thanks to a 'binary search' this will lead you to the one commit in the source
+code management system that's causing the regression. Once you find it, search
+the net for the subject of the change, its commit id and the shortened commit id
+(the first 12 characters of the commit id). This will lead you to existing
+reports about it, if there are any.
+
+Note, a bisection needs a bit of know-how, which not everyone has, and quite a
+bit of effort, which not everyone is willing to invest. Nevertheless, it's
+highly recommended performing a bisection yourself. If you really can't or
+don't want to go down that route at least find out which mainline kernel
+introduced the regression. If something for example breaks when switching from
+5.5.15 to 5.8.4, then try at least all the mainline releases in that area (5.6,
+5.7 and 5.8) to check when it first showed up. Unless you're trying to find a
+regression in a stable or longterm kernel, avoid testing versions which number
+has three sections (5.6.12, 5.7.8), as that makes the outcome hard to
+interpret, which might render your testing useless. Once you found the major
+version which introduced the regression, feel free to move on in the reporting
+process. But keep in mind: it depends on the issue at hand if the developers
+will be able to help without knowing the culprit. Sometimes they might
+recognize from the report want went wrong and can fix it; other times they will
+be unable to help unless you perform a bisection.
+
+When dealing with regressions make sure the issue you face is really caused by
+the kernel and not by something else, as outlined above already.
+
+In the whole process keep in mind: an issue only qualifies as regression if the
+older and the newer kernel got built with a similar configuration. The best way
+to archive this: copy the configuration file (``.config``) from the old working
+kernel freshly to each newer kernel version you try. Afterwards run ``make
+oldnoconfig`` to adjust it for the needs of the new version without enabling
+any new feature, as those are allowed to cause regressions.
+
+
+Write and send the report
+-------------------------
+
+ *Start to compile the report by writing a detailed description about the
+ issue. Always mention a few things: the latest kernel version you installed
+ for reproducing, the Linux Distribution used, and your notes on how to
+ reproduce the issue. Ideally, make the kernel's build configuration
+ (.config) and the output from ``dmesg`` available somewhere on the net and
+ link to it. Include or upload all other information that might be relevant,
+ like the output/screenshot of an Oops or the output from ``lspci``. Once
+ you wrote this main part, insert a normal length paragraph on top of it
+ outlining the issue and the impact quickly. On top of this add one sentence
+ that briefly describes the problem and gets people to read on. Now give the
+ thing a descriptive title or subject that yet again is shorter. Then you're
+ ready to send or file the report like the MAINTAINERS file told you, unless
+ you are dealing with one of those 'issues of high priority': they need
+ special care which is explained in 'Special handling for high priority
+ issues' below.*
+
+Now that you have prepared everything it's time to write your report. How to do
+that is partly explained by the three documents linked to in the preface above.
+That's why this text will only mention a few of the essentials as well as
+things specific to the Linux kernel.
+
+There is one thing that fits both categories: the most crucial parts of your
+report are the title/subject, the first sentence, and the first paragraph.
+Developers often get quite a lot of mail. They thus often just take a few
+seconds to skim a mail before deciding to move on or look closer. Thus: the
+better the top section of your report, the higher are the chances that someone
+will look into it and help you. And that is why you should ignore them for now
+and write the detailed report first. ;-)
+
+Things each report should mention
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Describe in detail how your issue happens with the fresh vanilla kernel you
+installed. Try to include the step-by-step instructions you wrote and optimized
+earlier that outline how you and ideally others can reproduce the issue; in
+those rare cases where that's impossible try to describe what you did to
+trigger it.
+
+Also include all the relevant information others might need to understand the
+issue and its environment. What's actually needed depends a lot on the issue,
+but there are some things you should include always:
+
+ * the output from ``cat /proc/version``, which contains the Linux kernel
+ version number and the compiler it was built with.
+
+ * the Linux distribution the machine is running (``hostnamectl | grep
+ "Operating System"``)
+
+ * the architecture of the CPU and the operating system (``uname -mi``)
+
+ * if you are dealing with a regression and performed a bisection, mention the
+ subject and the commit-id of the change that is causing it.
+
+In a lot of cases it's also wise to make two more things available to those
+that read your report:
+
+ * the configuration used for building your Linux kernel (the '.config' file)
+
+ * the kernel's messages that you get from ``dmesg`` written to a file. Make
+ sure that it starts with a line like 'Linux version 5.8-1
+ (foobar@example.com) (gcc (GCC) 10.2.1, GNU ld version 2.34) #1 SMP Mon Aug
+ 3 14:54:37 UTC 2020' If it's missing, then important messages from the first
+ boot phase already got discarded. In this case instead consider using
+ ``journalctl -b 0 -k``; alternatively you can also reboot, reproduce the
+ issue and call ``dmesg`` right afterwards.
+
+These two files are big, that's why it's a bad idea to put them directly into
+your report. If you are filing the issue in a bug tracker then attach them to
+the ticket. If you report the issue by mail do not attach them, as that makes
+the mail too large; instead do one of these things:
+
+ * Upload the files somewhere public (your website, a public file paste
+ service, a ticket created just for this purpose on `bugzilla.kernel.org
+ <https://bugzilla.kernel.org/>`_, ...) and include a link to them in your
+ report. Ideally use something where the files stay available for years, as
+ they could be useful to someone many years from now; this for example can
+ happen if five or ten years from now a developer works on some code that was
+ changed just to fix your issue.
+
+ * Put the files aside and mention you will send them later in individual
+ replies to your own mail. Just remember to actually do that once the report
+ went out. ;-)
+
+Things that might be wise to provide
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Depending on the issue you might need to add more background data. Here are a
+few suggestions what often is good to provide:
+
+ * If you are dealing with a 'warning', an 'OOPS' or a 'panic' from the kernel,
+ include it. If you can't copy'n'paste it, try to capture a netconsole trace
+ or at least take a picture of the screen.
+
+ * If the issue might be related to your computer hardware, mention what kind
+ of system you use. If you for example have problems with your graphics card,
+ mention its manufacturer, the card's model, and what chip is uses. If it's a
+ laptop mention its name, but try to make sure it's meaningful. 'Dell XPS 13'
+ for example is not, because it might be the one from 2012; that one looks
+ not that different from the one sold today, but apart from that the two have
+ nothing in common. Hence, in such cases add the exact model number, which
+ for example are '9380' or '7390' for XPS 13 models introduced during 2019.
+ Names like 'Lenovo Thinkpad T590' are also somewhat ambiguous: there are
+ variants of this laptop with and without a dedicated graphics chip, so try
+ to find the exact model name or specify the main components.
+
+ * Mention the relevant software in use. If you have problems with loading
+ modules, you want to mention the versions of kmod, systemd, and udev in use.
+ If one of the DRM drivers misbehaves, you want to state the versions of
+ libdrm and Mesa; also specify your Wayland compositor or the X-Server and
+ its driver. If you have a filesystem issue, mention the version of
+ corresponding filesystem utilities (e2fsprogs, btrfs-progs, xfsprogs, ...).
+
+ * Gather additional information from the kernel that might be of interest. The
+ output from ``lspci -nn`` will for example help others to identify what
+ hardware you use. If you have a problem with hardware you even might want to
+ make the output from ``sudo lspci -vvv`` available, as that provides
+ insights how the components were configured. For some issues it might be
+ good to include the contents of files like ``/proc/cpuinfo``,
+ ``/proc/ioports``, ``/proc/iomem``, ``/proc/modules``, or
+ ``/proc/scsi/scsi``. Some subsystem also offer tools to collect relevant
+ information. One such tool is ``alsa-info.sh`` `which the audio/sound
+ subsystem developers provide <https://www.alsa-project.org/wiki/AlsaInfo>`_.
+
+Those examples should give your some ideas of what data might be wise to
+attach, but you have to think yourself what will be helpful for others to know.
+Don't worry too much about forgetting something, as developers will ask for
+additional details they need. But making everything important available from
+the start increases the chance someone will take a closer look.
+
+
+The important part: the head of your report
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that you have the detailed part of the report prepared let's get to the
+most important section: the first few sentences. Thus go to the top, add
+something like 'The detailed description:' before the part you just wrote and
+insert two newlines at the top. Now write one normal length paragraph that
+describes the issue roughly. Leave out all boring details and focus on the
+crucial parts readers need to know to understand what this is all about; if you
+think this bug affects a lot of users, mention this to get people interested.
+
+Once you did that insert two more lines at the top and write a one sentence
+summary that explains quickly what the report is about. After that you have to
+get even more abstract and write an even shorter subject/title for the report.
+
+Now that you have written this part take some time to optimize it, as it is the
+most important parts of your report: a lot of people will only read this before
+they decide if reading the rest is time well spent.
+
+Now send or file the report like the :ref:`MAINTAINERS <maintainers>` file told
+you, unless it's one of those 'issues of high priority' outlined earlier: in
+that case please read the next subsection first before sending the report on
+its way.
+
+Special handling for high priority issues
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Reports for high priority issues need special handling.
+
+**Severe bugs**: make sure the subject or ticket title as well as the first
+paragraph makes the severeness obvious.
+
+**Regressions**: If the issue is a regression add [REGRESSION] to the mail's
+subject or the title in the bug-tracker. If you did not perform a bisection
+mention at least the latest mainline version you tested that worked fine (say
+5.7) and the oldest where the issue occurs (say 5.8). If you did a successful
+bisection mention the commit id and subject of the change that causes the
+regression. Also make sure to add the author of that change to your report; if
+you need to file your bug in a bug-tracker forward the report to him in a
+private mail and mention where your filed it.
+
+**Security issues**: for these issues your will have to evaluate if a
+short-term risk to other users would arise if details were publicly disclosed.
+If that's not the case simply proceed with reporting the issue as described.
+For issues that bear such a risk you will need to adjust the reporting process
+slightly:
+
+ * If the MAINTAINERS file instructed you to report the issue by mail, do not
+ CC any public mailing lists.
+
+ * If you were supposed to file the issue in a bug tracker make sure to mark
+ the ticket as 'private' or 'security issue'. If the bug tracker does not
+ offer a way to keep reports private, forget about it and send your report as
+ a private mail to the maintainers instead.
+
+In both cases make sure to also mail your report to the addresses the
+MAINTAINERS file lists in the section 'security contact'. Ideally directly CC
+them when sending the report by mail. If you filed it in a bug tracker, forward
+the report's text to these addresses; but on top of it put a small note where
+you mention that you filed it with a link to the ticket.
+
+See 'Documentation/admin-guide/security-bugs.rst' for more information.
+
+
+Duties after the report went out
+--------------------------------
+
+ *Wait for reactions and keep the thing rolling until you can accept the
+ outcome in one way or the other. Thus react publicly and in a timely manner
+ to any inquiries. Test proposed fixes. Do proactive testing: retest with at
+ least every first release candidate (RC) of a new mainline version and
+ report your results. Send friendly reminders if things stall. And try to
+ help yourself, if you don't get any help or if it's unsatisfying.*
+
+If your report was good and you are really lucky then one of the developers
+might immediately spot what's causing the issue; they then might write a patch
+to fix it, test it, and send it straight for integration in mainline while
+tagging it for later backport to stable and longterm kernels that need it. Then
+all you need to do is reply with a 'Thank you very much' and switch to a version
+with the fix once it gets released.
+
+But this ideal scenario rarely happens. That's why the job is only starting
+once you got the report out. What you'll have to do depends on the situations,
+but often it will be the things listed below. But before digging into the
+details, here are a few important things you need to keep in mind for this part
+of the process.
+
+
+General advice for further interactions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Always reply in public**: When you filed the issue in a bug tracker, always
+reply there and do not contact any of the developers privately about it. For
+mailed reports always use the 'Reply-all' function when replying to any mails
+you receive. That includes mails with any additional data you might want to add
+to your report: go to your mail applications 'Sent' folder and use 'reply-all'
+on your mail with the report. This approach will make sure the public mailing
+list(s) and everyone else that gets involved over time stays in the loop; it
+also keeps the mail thread intact, which among others is really important for
+mailing lists to group all related mails together.
+
+There are just two situations where a comment in a bug tracker or a 'Reply-all'
+is unsuitable:
+
+ * Someone tells you to send something privately.
+
+ * You were told to send something, but noticed it contains sensitive
+ information that needs to be kept private. In that case it's okay to send it
+ in private to the developer that asked for it. But note in the ticket or a
+ mail that you did that, so everyone else knows you honored the request.
+
+**Do research before asking for clarifications or help**: In this part of the
+process someone might tell you to do something that requires a skill you might
+not have mastered yet. For example, you might be asked to use some test tools
+you never have heard of yet; or you might be asked to apply a patch to the
+Linux kernel sources to test if it helps. In some cases it will be fine sending
+a reply asking for instructions how to do that. But before going that route try
+to find the answer own your own by searching the internet; alternatively
+consider asking in other places for advice. For example ask a fried or post
+about it to a chatroom or forum you normally hang out.
+
+**Be patient**: If you are really lucky you might get a reply to your report
+within a few hours. But most of the time it will take longer, as maintainers
+are scattered around the globe and thus might be in a different time zone – one
+where they already enjoy their night away from keyboard.
+
+In general, kernel developers will take one to five business days to respond to
+reports. Sometimes it will take longer, as they might be busy with the merge
+windows, other work, visiting developer conferences, or simply enjoying a long
+summer holiday.
+
+The 'issues of high priority' (see above for an explanation) are an exception
+here: maintainers should address them as soon as possible; that's why you
+should wait a week at maximum (or just two days if it's something urgent)
+before sending a friendly reminder.
+
+Sometimes the maintainer might not be responding in a timely manner; other
+times there might be disagreements, for example if an issue qualifies as
+regression or not. In such cases raise your concerns on the mailing list and
+ask others for public or private replies how to move on. If that fails, it
+might be appropriate to get a higher authority involved. In case of a WiFi
+driver that would be the wireless maintainers; if there are no higher level
+maintainers or all else fails, it might be one of those rare situations where
+it's okay to get Linus Torvalds involved.
+
+**Proactive testing**: Every time the first pre-release (the 'rc1') of a new
+mainline kernel version gets released, go and check if the issue is fixed there
+or if anything of importance changed. Mention the outcome in the ticket or in a
+mail you sent as reply to your report (make sure it has all those in the CC
+that up to that point participated in the discussion). This will show your
+commitment and that you are willing to help. It also tells developers if the
+issue persists and makes sure they do not forget about it. A few other
+occasional retests (for example with rc3, rc5 and the final) are also a good
+idea, but only report your results if something relevant changed or if you are
+writing something anyway.
+
+With all these general things off the table let's get into the details of how
+to help to get issues resolved once they were reported.
+
+Inquires and testing request
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here are your duties in case you got replies to your report:
+
+**Check who you deal with**: Most of the time it will be the maintainer or a
+developer of the particular code area that will respond to your report. But as
+issues are normally reported in public it could be anyone that's replying —
+including people that want to help, but in the end might guide you totally off
+track with their questions or requests. That rarely happens, but it's one of
+many reasons why it's wise to quickly run an internet search to see who you're
+interacting with. By doing this you also get aware if your report was heard by
+the right people, as a reminder to the maintainer (see below) might be in order
+later if discussion fades out without leading to a satisfying solution for the
+issue.
+
+**Inquiries for data**: Often you will be asked to test something or provide
+additional details. Try to provide the requested information soon, as you have
+the attention of someone that might help and risk losing it the longer you
+wait; that outcome is even likely if you do not provide the information within
+a few business days.
+
+**Requests for testing**: When you are asked to test a diagnostic patch or a
+possible fix, try to test it in timely manner, too. But do it properly and make
+sure to not rush it: mixing things up can happen easily and can lead to a lot
+of confusion for everyone involved. A common mistake for example is thinking a
+proposed patch with a fix was applied, but in fact wasn't. Things like that
+happen even to experienced testers occasionally, but they most of the time will
+notice when the kernel with the fix behaves just as one without it.
+
+What to do when nothing of substance happens
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some reports will not get any reaction from the responsible Linux kernel
+developers; or a discussion around the issue evolved, but faded out with
+nothing of substance coming out of it.
+
+In these cases wait two (better: three) weeks before sending a friendly
+reminder: maybe the maintainer was just away from keyboard for a while when
+your report arrived or had something more important to take care of. When
+writing the reminder, kindly ask if anything else from your side is needed to
+get the ball running somehow. If the report got out by mail, do that in the
+first lines of a mail that is a reply to your initial mail (see above) which
+includes a full quote of the original report below: that's on of those few
+situations where such a 'TOFU' (Text Over, Fullquote Under) is the right
+approach, as then all the recipients will have the details at hand immediately
+in the proper order.
+
+After the reminder wait three more weeks for replies. If you still don't get a
+proper reaction, you first should reconsider your approach. Did you maybe try
+to reach out to the wrong people? Was the report maybe offensive or so
+confusing that people decided to completely stay away from it? The best way to
+rule out such factors: show the report to one or two people familiar with FLOSS
+issue reporting and ask for their opinion. Also ask them for their advice how
+to move forward. That might mean: prepare a better report and make those people
+review it before you send it out. Such an approach is totally fine; just
+mention that this is the second and improved report on the issue and include a
+link to the first report.
+
+If the report was proper you can send a second reminder; in it ask for advice
+why the report did not get any replies. A good moment for this second reminder
+mail is shortly after the first pre-release (the 'rc1') of a new Linux kernel
+version got published, as you should retest and provide a status update at that
+point anyway (see above).
+
+If the second reminder again results in no reaction within a week, try to
+contact a higher-level maintainer asking for advice: even busy maintainers by
+then should at least have sent some kind of acknowledgment.
+
+Remember to prepare yourself for a disappointment: maintainers ideally should
+react somehow to every issue report, but they are only obliged to fix those
+'issues of high priority' outlined earlier. So don't be too devastating if you
+get a reply along the lines of 'thanks for the report, I have more important
+issues to deal with currently and won't have time to look into this for the
+foreseeable future'.
+
+It's also possible that after some discussion in the bug tracker or on a list
+nothing happens anymore and reminders don't help to motivate anyone to work out
+a fix. Such situations can be devastating, but is within the cards when it
+comes to Linux kernel development. This and several other reasons for not
+getting help are explained in 'Why some issues won't get any reaction or remain
+unfixed after being reported' near the end of this document.
+
+Don't get devastated if you don't find any help or if the issue in the end does
+not get solved: the Linux kernel is FLOSS and thus you can still help yourself.
+You for example could try to find others that are affected and team up with
+them to get the issue resolved. Such a team could prepare a fresh report
+together that mentions how many you are and why this is something that in your
+option should get fixed. Maybe together you can also narrow down the root cause
+or the change that introduced a regression, which often makes developing a fix
+easier. And with a bit of luck there might be someone in the team that knows a
+bit about programming and might be able to write a fix.
+
+
+Details about reporting issues only occurring in older kernel version lines
+---------------------------------------------------------------------------
+
+This subsection provides details for steps you need to take if you could not
+reproduce your issue with a mainline kernel, but want to see it fixed in older
+version lines (aka stable and longterm kernels).
+
+Some fixes are too complex
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Prepare yourself for the possibility that going through the next few steps
+ might not get the issue solved in older releases: the fix might be too big
+ or risky to get backported there.*
+
+Even small and seemingly obvious code-changes sometimes introduce new and
+totally unexpected problems. The maintainers of the stable and longterm kernels
+are very aware of that and thus only apply changes to these kernels that are
+within rules outlined in 'Documentation/process/stable-kernel-rules.rst'.
+
+Complex or risky changes for example do not qualify and thus only get applied
+to mainline. Other fixes are easy to get backported to the newest stable and
+longterm kernels, but too risky to integrate into older ones. So be aware the
+fix you are hoping for might be one of those that won't be backported to the
+version line your care about. In that case you'll have no other choice then to
+live with the issue or switch to a newer Linux version, unless you want to
+patch the fix into your kernels yourself.
+
+Make sure the particular version line still gets support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check if the kernel developers still maintain the Linux kernel version
+ line you care about: go to the front page of kernel.org and make sure it
+ mentions the latest release of the particular version line without an
+ '[EOL]' tag.*
+
+Most kernel version lines only get supported for about three months, as
+maintaining them longer is quite a lot of work. Hence, only one per year is
+chosen and gets supported for at least two years (often six). That's why you
+need to check if the kernel developers still support the version line you care
+for.
+
+Note, if kernel.org lists two 'stable' version lines on the front page, you
+should consider switching to the newer one and forget about the older one:
+support for it is likely to be abandoned soon. Then it will get a "end-of-life"
+(EOL) stamp. Version lines that reached that point still get mentioned on the
+kernel.org front page for a week or two, but are unsuitable for testing and
+reporting.
+
+Search stable mailing list
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check the archives of the Linux stable mailing list for existing reports.*
+
+Maybe the issue you face is already known and was fixed or is about to. Hence,
+`search the archives of the Linux stable mailing list
+<https://lore.kernel.org/stable/>`_ for reports about an issue like yours. If
+you find any matches, consider joining the discussion, unless the fix is
+already finished and scheduled to get applied soon.
+
+Reproduce issue with the newest release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Install the latest release from the particular version line as a vanilla
+ kernel. Ensure this kernel is not tainted and still shows the problem, as
+ the issue might have already been fixed there.*
+
+Before investing any more time in this process you want to check if the issue
+was already fixed in the latest release of version line you're interested in.
+This kernel needs to be vanilla and shouldn't be tainted before the issue
+happens, as detailed outlined already above in the process of testing mainline.
+
+Check code history and search for existing discussions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Search the Linux kernel version control system for the change that fixed
+ the issue in mainline, as its commit message might tell you if the fix is
+ scheduled for backporting already. If you don't find anything that way,
+ search the appropriate mailing lists for posts that discuss such an issue
+ or peer-review possible fixes; then check the discussions if the fix was
+ deemed unsuitable for backporting. If backporting was not considered at
+ all, join the newest discussion, asking if it's in the cards.*
+
+In a lot of cases the issue you deal with will have happened with mainline, but
+got fixed there. The commit that fixed it would need to get backported as well
+to get the issue solved. That's why you want to search for it or any
+discussions abound it.
+
+ * First try to find the fix in the Git repository that holds the Linux kernel
+ sources. You can do this with the web interfaces `on kernel.org
+ <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_
+ or its mirror `on GitHub <https://github.com/torvalds/linux>`_; if you have
+ a local clone you alternatively can search on the command line with ``git
+ log --grep=<pattern>``.
+
+ If you find the fix, look if the commit message near the end contains a
+ 'stable tag' that looks like this:
+
+ Cc: <stable@vger.kernel.org> # 5.4+
+
+ If that's case the developer marked the fix safe for backporting to version
+ line 5.4 and later. Most of the time it's getting applied there within two
+ weeks, but sometimes it takes a bit longer.
+
+ * If the commit doesn't tell you anything or if you can't find the fix, look
+ again for discussions about the issue. Search the net with your favorite
+ internet search engine as well as the archives for the `Linux kernel
+ developers mailing list <https://lore.kernel.org/lkml/>`_. Also read the
+ section `Locate kernel area that causes the issue` above and follow the
+ instructions to find the subsystem in question: its bug tracker or mailing
+ list archive might have the answer you are looking for.
+
+ * If you see a proposed fix, search for it in the version control system as
+ outlined above, as the commit might tell you if a backport can be expected.
+
+ * Check the discussions for any indicators the fix might be too risky to get
+ backported to the version line you care about. If that's the case you have
+ to live with the issue or switch to the kernel version line where the fix
+ got applied.
+
+ * If the fix doesn't contain a stable tag and backporting was not discussed,
+ join the discussion: mention the version where you face the issue and that
+ you would like to see it fixed, if suitable.
+
+Check if it's a regression specific to stable or longterm kernels
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check if you're dealing with a regression that was never present in
+ mainline by installing the first release of the version line you care
+ about. If the issue doesn't show up with it, you basically need to report
+ the issue with this version like you would report a problem with mainline
+ (see above). This ideally includes a bisection followed by a search for
+ existing reports on the net; with the help of the subject and the two
+ relevant commit-ids. If that doesn't turn up anything, write the report; CC
+ or forward the report to the stable maintainers, the stable mailing list,
+ and those who authored the change. Include the shortened commit-id if you
+ found the change that causes it.*
+
+Sometimes you won't find anything in the previous step: the issue you face
+might have never occurred in mainline, as it is caused by some change that is
+incomplete or not correctly applied. To check this, install the first release
+from version line you care about, e.g., if you care about 5.4.x, install 5.4.
+
+If the issue doesn't show itself there, it's a regression specific to the
+particular version line. In that case you need to report it like an issue
+happening in mainline, like the last few steps in the main section in the above
+outline.
+
+One of them suggests doing a bisection, which you are strongly advised to do in
+this case. After finding the culprit, search the net for existing reports
+again: not only search for the exact subject and the commit-id (proper and
+shortened to twelve characters) of the change, but also for the commit-id
+(proper and shortened) mentioned as 'Upstream commit' in the commit message.
+
+Write the report; just keep a few specialties in mind: CC or forward the report
+to the stable maintainers, the stable mailing list, which the :ref:`MAINTAINERS
+<maintainers>` file mentions in the section "STABLE BRANCH". If you performed a
+successful bisection, CC the author of the change and include its subject and
+the shortened commit-id.
+
+Ask for advice
+~~~~~~~~~~~~~~
+
+ *One of the former steps should lead to a solution. If that doesn't work
+ out, ask the maintainers for the subsystem that seems to be causing the
+ issue for advice; CC the mailing list for the particular subsystem as well
+ as the stable mailing list.*
+
+If the previous three steps didn't get you closer to a solution there is only
+one option left: ask for advice. Do that in a mail you sent to the maintainers
+for the subsystem where the issue seems to have its roots; CC the mailing list
+for the subsystem as well as the stable mailing list the :ref:`MAINTAINERS
+<maintainers>` file mention in the section "STABLE BRANCH".
+
+
+Why some issues won't get any reaction or remain unfixed after being reported
+=============================================================================
+
+When reporting a problem to the Linux developers, be aware only 'issues of high
+priority' (regressions, security issues, severe problems) are definitely going
+to get resolved. The maintainers or if all else fails Linus Torvalds himself
+will make sure of that. They and the other kernel developers will fix a lot of
+other issues as well. But be aware that sometimes they can't or won't help; and
+sometimes there isn't even anyone to send a report to.
+
+This is best explained with kernel developers that contribute to the Linux
+kernel in their spare time. Quite a few of the drivers in the kernel were
+written by such programmers, often because they simply wanted to make their
+hardware usable on their favorite operating system.
+
+These programmers most of the time will happily fix problems other people
+report. But nobody can force them to do, as they are contributing voluntarily.
+
+Then there are situations where such developers really want to fix an issue,
+but can't: sometimes they lack hardware programming documentation to do so.
+This often happens when the publicly available docs are superficial or the
+driver was written with the help of reverse engineering.
+
+Sooner or later spare time developers will also stop caring for the driver.
+Maybe their test hardware broke, got replaced by something more fancy, or is so
+old that it's something you don't find much outside of computer museums
+anymore. Sometimes developer stops caring for their code and Linux at all, as
+something different in their life became way more important. In some cases
+nobody is willing to take over the job as maintainer – and nobody can be forced
+to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned
+drivers nevertheless remain in the kernel: they are still useful for people and
+removing would be a regression.
+
+The situation is not that different with developers that are paid for their
+work on the Linux kernel. Those contribute most changes these days. But their
+employers sooner or later also stop caring for their code or make its
+programmer focus on other things. Hardware vendors for example earn their money
+mainly by selling new hardware; quite a few of them hence are not investing
+much time and energy in maintaining a Linux kernel driver for something they
+stopped selling years ago. Enterprise Linux distributors often care for a
+longer time period, but in new versions often leave support for old and rare
+hardware aside to limit the scope. Often spare time contributors take over once
+a company orphans some code, but as mentioned above: sooner or later they will
+leave the code behind, too.
+
+Priorities are another reason why some issues are not fixed, as maintainers
+quite often are forced to set those, as time to work on Linux is limited.
+That's true for spare time or the time employers grant their developers to
+spend on maintenance work on the upstream kernel. Sometimes maintainers also
+get overwhelmed with reports, even if a driver is working nearly perfectly. To
+not get completely stuck, the programmer thus might have no other choice than
+to prioritize issue reports and reject some of them.
+
+But don't worry too much about all of this, a lot of drivers have active
+maintainers who are quite interested in fixing as many issues as possible.
+
+
+Closing words
+=============
+
+Compared with other Free/Libre & Open Source Software it's hard to report
+issues to the Linux kernel developers: the length and complexity of this
+document and the implications between the lines illustrate that. But that's how
+it is for now. The main author of this text hopes documenting the state of the
+art will lay some groundwork to improve the situation over time.
diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
index c32eb78..82e2983 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -21,7 +21,7 @@
As it is with any bug, the more information provided the easier it
will be to diagnose and fix. Please review the procedure outlined in
-:doc:`reporting-bugs` if you are unclear about what
+'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.
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/abi.rst b/Documentation/admin-guide/sysctl/abi.rst
index ac87eaf..77b1d1b 100644
--- a/Documentation/admin-guide/sysctl/abi.rst
+++ b/Documentation/admin-guide/sysctl/abi.rst
@@ -28,7 +28,7 @@
Determines whether the kernels maps a vDSO page into 32-bit processes;
can be set to 1 to enable, or 0 to disable. Defaults to enabled if
-``CONFIG_COMPAT_VDSO`` is set, disabled otherwide.
+``CONFIG_COMPAT_VDSO`` is set, disabled otherwise.
This controls the same setting as the ``vdso32`` kernel boot
parameter.
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index d4b32cc..1d56a6b 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -14,7 +14,7 @@
------------------------------------------------------------------------------
This file contains documentation for the sysctl files in
-``/proc/sys/kernel/`` and is valid for Linux kernel version 2.2.
+``/proc/sys/kernel/``.
The files in this directory can be used to tune and monitor
miscellaneous and general things in the operation of the Linux
@@ -879,7 +879,7 @@
perf_event_mlock_kb
===================
-Control size of per-cpu ring buffer not counted agains mlock limit.
+Control size of per-cpu ring buffer not counted against mlock limit.
The default value is 512 + 1 page
@@ -1095,8 +1095,8 @@
incurs a small amount of overhead in the scheduler but is
useful for debugging and performance tuning.
-sched_util_clamp_min:
-=====================
+sched_util_clamp_min
+====================
Max allowed *minimum* utilization.
@@ -1106,8 +1106,8 @@
sched_util_clamp_min, i.e., it is restricted to the range
[0:sched_util_clamp_min].
-sched_util_clamp_max:
-=====================
+sched_util_clamp_max
+====================
Max allowed *maximum* utilization.
@@ -1117,8 +1117,8 @@
sched_util_clamp_max, i.e., it is restricted to the range
[0:sched_util_clamp_max].
-sched_util_clamp_min_rt_default:
-================================
+sched_util_clamp_min_rt_default
+===============================
By default Linux is tuned for performance. Which means that RT tasks always run
at the highest frequency and most capable (highest capacity) CPU (in
@@ -1336,7 +1336,7 @@
====== ===== ==============================================================
1 `(P)` proprietary module was loaded
2 `(F)` module was force loaded
- 4 `(S)` SMP kernel oops on an officially SMP incapable processor
+ 4 `(S)` kernel running on an out of specification system
8 `(R)` module was force unloaded
16 `(M)` processor reported a Machine Check Exception (MCE)
32 `(B)` bad page referenced or some unexpected page flags
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index f455fa0..e35a3f2 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -146,7 +146,7 @@
acceptable trade for large contiguous free memory. Set to 0 to prevent
compaction from moving pages that are unevictable. Default value is 1.
On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
-to compaction, which would block the task from becomming active until the fault
+to compaction, which would block the task from becoming active until the fault
is resolved.
@@ -428,7 +428,7 @@
programs, particularly malloc debuggers, may consume lots of them,
e.g., up to one or two maps per allocation.
-The default value is 65536.
+The default value is 65530.
memory_failure_early_kill:
@@ -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/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
index f718a2e..ceeed7b 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -84,7 +84,7 @@
=== === ====== ========================================================
0 G/P 1 proprietary module was loaded
1 _/F 2 module was force loaded
- 2 _/S 4 SMP kernel oops on an officially SMP incapable processor
+ 2 _/S 4 kernel running on an out of specification system
3 _/R 8 module was force unloaded
4 _/M 16 processor reported a Machine Check Exception (MCE)
5 _/B 32 bad page referenced or some unexpected page flags
@@ -116,10 +116,23 @@
1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
modules were loaded normally.
- 2) ``S`` if the oops occurred on an SMP kernel running on hardware that
- hasn't been certified as safe to run multiprocessor.
- Currently this occurs only on various Athlons that are not
- SMP capable.
+ 2) ``S`` if the kernel is running on a processor or system that is out of
+ specification: hardware has been put into an unsupported configuration,
+ therefore proper execution cannot be guaranteed.
+ Kernel will be tainted if, for example:
+
+ - on x86: PAE is forced through forcepae on intel CPUs (such as Pentium M)
+ which do not report PAE but may have a functional implementation, an SMP
+ kernel is running on non officially capable SMP Athlon CPUs, MSRs are
+ being poked at from userspace.
+ - on arm: kernel running on certain CPUs (such as Keystone 2) without
+ having certain kernel features enabled.
+ - on arm64: there are mismatched hardware features between CPUs, the
+ bootloader has booted CPUs in different modes.
+ - certain drivers are being used on non supported architectures (such as
+ scsi/snic on something else than x86_64, scsi/ips on non
+ x86/x86_64/itanium, have broken firmware settings for the
+ irqchip/irq-gic on arm64 ...).
3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
modules were unloaded normally.
diff --git a/Documentation/arm/features.rst b/Documentation/arm/features.rst
new file mode 100644
index 0000000..7414ec0
--- /dev/null
+++ b/Documentation/arm/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features arm
diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst
index 5fc072d..a2e9e1b 100644
--- a/Documentation/arm/index.rst
+++ b/Documentation/arm/index.rst
@@ -23,6 +23,8 @@
vlocks
porting
+ features
+
SoC-specific documents
======================
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/arm/sunxi.rst b/Documentation/arm/sunxi.rst
index 0c536ae..b85d1e2 100644
--- a/Documentation/arm/sunxi.rst
+++ b/Documentation/arm/sunxi.rst
@@ -158,3 +158,13 @@
* User Manual
https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf
+
+ - Allwinner H616
+
+ * Datasheet
+
+ https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf
+
+ * User Manual
+
+ https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf
diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
index bbd9cf5..8782166 100644
--- a/Documentation/arm64/elf_hwcaps.rst
+++ b/Documentation/arm64/elf_hwcaps.rst
@@ -1,3 +1,5 @@
+.. _elf_hwcaps_index:
+
================
ARM64 ELF hwcaps
================
diff --git a/Documentation/arm64/features.rst b/Documentation/arm64/features.rst
new file mode 100644
index 0000000..dfa4cb3
--- /dev/null
+++ b/Documentation/arm64/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features arm64
diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst
index 937634c..97d65ba 100644
--- a/Documentation/arm64/index.rst
+++ b/Documentation/arm64/index.rst
@@ -24,6 +24,8 @@
tagged-address-abi
tagged-pointers
+ features
+
.. only:: subproject and html
Indices
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/perf.rst b/Documentation/arm64/perf.rst
index 9c76a97..b567f17 100644
--- a/Documentation/arm64/perf.rst
+++ b/Documentation/arm64/perf.rst
@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
+.. _perf_index:
+
=====================
Perf Event Attributes
=====================
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/conf.py b/Documentation/conf.py
index ed2b43e..6a76729 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -39,7 +39,7 @@
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include', 'sphinx.ext.autosectionlabel',
- 'kernel_abi']
+ 'kernel_abi', 'kernel_feat']
#
# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
@@ -112,6 +112,9 @@
else:
extensions.append('cdomain')
+ if major == 1 and minor < 7:
+ sys.stderr.write('WARNING: Sphinx 1.7 or greater will be required as of '
+ 'the 5.12 release\n')
# Ensure that autosectionlabel will produce unique names
autosectionlabel_prefix_document = True
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/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index 6d26c5c..160e710 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -531,7 +531,9 @@
%*pb outputs the bitmap with field width as the number of bits and %*pbl
output the bitmap as range list with field width as the number of bits.
-Passed by reference.
+The field width is passed by value, the bitmap is passed by reference.
+Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
+printing cpumask and nodemask.
Flags bitfields such as page flags, gfp_flags
---------------------------------------------
diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst
index 74c5e6a..9c454de 100644
--- a/Documentation/dev-tools/coccinelle.rst
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -224,14 +224,21 @@
rm -f err.log
export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
- make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
+ make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd
err.log will now have the profiling information, while stdout will
provide some progress information as Coccinelle moves forward with
work.
+NOTE:
+
DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
+Currently, DEBUG_FILE support is only available to check folders, and
+not single files. This is because checking a single file requires spatch
+to be called twice leading to DEBUG_FILE being set both times to the same value,
+giving rise to an error.
+
.cocciconfig support
--------------------
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 2b68add..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 architecure 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 interpretted to pass only if the error was the one expected
-by the test.
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index 8548b0b..d2c4c27e 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -243,7 +243,7 @@
currently reserved and must be zero. In the future the number of bytes
used for the subsystem or handle ids might be increased.
-When a particular userspace proccess collects coverage via a common
+When a particular userspace process collects coverage via a common
handle, kcov will collect coverage for each code section that is annotated
to use the common handle obtained as kcov_handle from the current
task_struct. However non common handles allow to collect coverage
diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/dev-tools/kgdb.rst
index 77b688e..4345624 100644
--- a/Documentation/dev-tools/kgdb.rst
+++ b/Documentation/dev-tools/kgdb.rst
@@ -63,10 +63,9 @@
It is advised, but not required, that you turn on the
``CONFIG_FRAME_POINTER`` kernel option which is called :menuselection:`Compile
the kernel with frame pointers` in the config menu. This option inserts code
-to into the compiled executable which saves the frame information in
-registers or on the stack at different points which allows a debugger
-such as gdb to more accurately construct stack back traces while
-debugging the kernel.
+into the compiled executable which saves the frame information in registers
+or on the stack at different points which allows a debugger such as gdb to
+more accurately construct stack back traces while debugging the kernel.
If the architecture that you are using supports the kernel option
``CONFIG_STRICT_KERNEL_RWX``, you should consider turning it off. This
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 9c28c51..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
=======
@@ -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.
@@ -233,7 +236,7 @@
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
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/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/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"
- "ti,dac5574"
- "ti,dac6574"
- "ti,dac7574"
- "ti,dac5573"
- "ti,dac6573"
- "ti,dac7573"
- - reg: Should contain the DAC I2C address
-
-Optional properties:
- - vref-supply: The regulator supply for DAC reference voltage
-
-Example:
-dac@0 {
- compatible = "ti,dac5571";
- reg = <0x4C>;
- vref-supply = <&vdd_supply>;
-};
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
new file mode 100644
index 0000000..7141917
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/ti,dac5571.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DAC5571 Family
+
+maintainers:
+ - Sean Nyekjaer <sean@geanix.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,dac5571
+ - ti,dac6571
+ - ti,dac7571
+ - ti,dac5574
+ - ti,dac6574
+ - ti,dac7574
+ - ti,dac5573
+ - ti,dac6573
+ - ti,dac7573
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Reference voltage must be supplied to establish the scaling of the
+ output voltage.
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@4c {
+ compatible = "ti,dac5571";
+ reg = <0x4C>;
+ vref-supply = <&vdd_supply>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7311.txt b/Documentation/devicetree/bindings/iio/dac/ti,dac7311.txt
deleted file mode 100644
index e5a507d..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac7311.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-TI DAC7311 device tree bindings
-
-Required properties:
-- compatible: must be set to:
- * "ti,dac7311"
- * "ti,dac6311"
- * "ti,dac5311"
-- reg: spi chip select number for the device
-- vref-supply: The regulator supply for ADC reference voltage
-
-Optional properties:
-- spi-max-frequency: Max SPI frequency to use
-
-Example:
-
- spi_master {
- dac@0 {
- compatible = "ti,dac7311";
- reg = <0>; /* CS0 */
- spi-max-frequency = <1000000>;
- vref-supply = <&vdd_supply>;
- };
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml
new file mode 100644
index 0000000..10be98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/ti,dac7311.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DAC5311 and similar SPI DACs
+
+maintainers:
+ - Charles-Antoine Couret <charles-antoine.couret@essensium.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,dac7311
+ - ti,dac6311
+ - ti,dac5311
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Reference voltage must be supplied to establish the scaling of the
+ output voltage.
+
+ spi-max-frequency: true
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "ti,dac7311";
+ reg = <0>; /* CS0 */
+ spi-max-frequency = <1000000>;
+ vref-supply = <&vdd_supply>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt b/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt
deleted file mode 100644
index 1db4593..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-TI DAC7512 DEVICETREE BINDINGS
-
-Required properties:
-
- - "compatible" Must be set to "ti,dac7512"
-
-Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
-apply. In particular, "reg" and "spi-max-frequency" properties must be given.
-
-
-Example:
-
- spi_master {
- dac7512: dac7512@0 {
- compatible = "ti,dac7512";
- reg = <0>; /* CS0 */
- spi-max-frequency = <1000000>;
- };
- };
-
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7512.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7512.yaml
new file mode 100644
index 0000000..4277cf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7512.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/ti,dac7512.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DAC7512 DAC
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+properties:
+ compatible:
+ const: ti,dac7512
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ description:
+ Maximum frequency is reduced for supply voltage of less than 3.6V
+ maximum: 30000000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "ti,dac7512";
+ reg = <0>; /* CS0 */
+ spi-max-frequency = <1000000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
deleted file mode 100644
index 17af395..0000000
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Texas Instruments Dual, 12-Bit Serial Input Digital-to-Analog Converter
-
-The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with guaranteed
-12-bit monotonicity performance over the industrial temperature range.
-Is is programmable through an SPI interface.
-
-The internal DACs are loaded when the LOADDACS pin is pulled down.
-
-https://www.ti.com/lit/ds/sbas106/sbas106.pdf
-
-Required Properties:
-- compatible: Should be one of:
- "ti,dac7612"
- "ti,dac7612u"
- "ti,dac7612ub"
-- reg: Definition as per Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional Properties:
-- ti,loaddacs-gpios: GPIO descriptor for the LOADDACS pin.
-- spi-*: Definition as per Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Example:
-
- dac@1 {
- compatible = "ti,dac7612";
- reg = <0x1>;
- ti,loaddacs-gpios = <&msmgpio 25 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
new file mode 100644
index 0000000..d172b14
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/ti,dac7612.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DAC7612 family of DACs
+
+description:
+ The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with
+ guaranteed 12-bit monotonicity performance over the industrial temperature
+ range. Is is programmable through an SPI interface.
+
+maintainers:
+ - Ricardo Ribalda Delgado <ricardo@ribalda.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,dac7612
+ - ti,dac7612u
+ - ti,dac7612ub
+
+ reg:
+ maxItems: 1
+
+ ti,loaddacs-gpios:
+ description:
+ DACs are loaded when the pin connected to this GPIO is pulled low.
+ maxItems: 1
+
+ spi-max-frequency: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@1 {
+ compatible = "ti,dac7612";
+ reg = <0x1>;
+ ti,loaddacs-gpios = <&msmgpio 25 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
deleted file mode 100644
index 20c6c7a..0000000
--- a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Freescale vf610 Digital to Analog Converter bindings
-
-The devicetree bindings are for the new DAC driver written for
-vf610 SoCs from Freescale.
-
-Required properties:
-- compatible: Should contain "fsl,vf610-dac"
-- reg: Offset and length of the register set for the device
-- interrupts: Should contain the interrupt for the device
-- clocks: The clock is needed by the DAC controller
-- clock-names: Must contain "dac" matching entry in the clocks property.
-
-Example:
-dac0: 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/frequency/adf4350.txt b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt
deleted file mode 100644
index f8c181d..0000000
--- a/Documentation/devicetree/bindings/iio/frequency/adf4350.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Analog Devices ADF4350/ADF4351 device driver
-
-Required properties:
- - compatible: Should be one of
- * "adi,adf4350": When using the ADF4350 device
- * "adi,adf4351": When using the ADF4351 device
- - reg: SPI chip select numbert for the device
- - spi-max-frequency: Max SPI frequency to use (< 20000000)
- - clocks: From common clock binding. Clock is phandle to clock for
- ADF435x Reference Clock (CLKIN).
-
-Optional properties:
- - gpios: GPIO Lock detect - If set with a valid phandle and GPIO number,
- pll lock state is tested upon read.
- - adi,channel-spacing: Channel spacing in Hz (influences MODULUS).
- - adi,power-up-frequency: If set in Hz the PLL tunes to
- the desired frequency on probe.
- - adi,reference-div-factor: If set the driver skips dynamic calculation
- and uses this default value instead.
- - adi,reference-doubler-enable: Enables reference doubler.
- - adi,reference-div2-enable: Enables reference divider.
- - adi,phase-detector-polarity-positive-enable: Enables positive phase
- detector polarity. Default = negative.
- - adi,lock-detect-precision-6ns-enable: Enables 6ns lock detect precision.
- Default = 10ns.
- - adi,lock-detect-function-integer-n-enable: Enables lock detect
- for integer-N mode. Default = factional-N mode.
- - adi,charge-pump-current: Charge pump current in mA.
- Default = 2500mA.
- - adi,muxout-select: On chip multiplexer output selection.
- Valid values for the multiplexer output are:
- 0: Three-State Output (default)
- 1: DVDD
- 2: DGND
- 3: R-Counter output
- 4: N-Divider output
- 5: Analog lock detect
- 6: Digital lock detect
- - adi,low-spur-mode-enable: Enables low spur mode.
- Default = Low noise mode.
- - adi,cycle-slip-reduction-enable: Enables cycle slip reduction.
- - adi,charge-cancellation-enable: Enabled charge pump
- charge cancellation for integer-N modes.
- - adi,anti-backlash-3ns-enable: Enables 3ns antibacklash pulse width
- for integer-N modes.
- - adi,band-select-clock-mode-high-enable: Enables faster band
- selection logic.
- - adi,12bit-clk-divider: Clock divider value used when
- adi,12bit-clkdiv-mode != 0
- - adi,clk-divider-mode:
- Valid values for the clkdiv mode are:
- 0: Clock divider off (default)
- 1: Fast lock enable
- 2: Phase resync enable
- - adi,aux-output-enable: Enables auxiliary RF output.
- - adi,aux-output-fundamental-enable: Selects fundamental VCO output on
- the auxiliary RF output. Default = Output of RF dividers.
- - adi,mute-till-lock-enable: Enables Mute-Till-Lock-Detect function.
- - adi,output-power: Output power selection.
- Valid values for the power mode are:
- 0: -4dBm (default)
- 1: -1dBm
- 2: +2dBm
- 3: +5dBm
- - adi,aux-output-power: Auxiliary output power selection.
- Valid values for the power mode are:
- 0: -4dBm (default)
- 1: -1dBm
- 2: +2dBm
- 3: +5dBm
-
-
-Example:
- lo_pll0_rx_adf4351: adf4351-rx-lpc@4 {
- compatible = "adi,adf4351";
- reg = <4>;
- spi-max-frequency = <10000000>;
- clocks = <&clk0_ad9523 9>;
- clock-names = "clkin";
- adi,channel-spacing = <10000>;
- adi,power-up-frequency = <2400000000>;
- adi,phase-detector-polarity-positive-enable;
- adi,charge-pump-current = <2500>;
- adi,output-power = <3>;
- adi,mute-till-lock-enable;
- };
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml
new file mode 100644
index 0000000..d7f20b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/frequency/adi,adf4350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADF4350/ADF4351 wideband synthesizer
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - adi,adf4350
+ - adi,adf4351
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 20000000
+
+ clocks:
+ maxItems: 1
+ description: Clock to provide CLKIN reference clock signal.
+
+ clock-names:
+ const: clkin
+
+ gpios:
+ maxItems: 1
+ description: Lock detect GPIO.
+
+ adi,channel-spacing:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Channel spacing in Hz (influences MODULUS).
+
+ adi,power-up-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ If set the PLL tunes to this frequency (in Hz) on driver probe.
+
+ adi,reference-div-factor:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ If set the driver skips dynamic calculation and uses this default
+ value instead.
+
+ adi,reference-doubler-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables reference doubler.
+
+ adi,reference-div2-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables reference divider.
+
+ adi,phase-detector-polarity-positive-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables positive phase detector polarity. Default negative.
+
+ adi,lock-detect-precision-6ns-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables 6ns lock detect precision. Default = 10ns.
+
+ adi,lock-detect-function-integer-n-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enables lock detect for integer-N mode. Default = factional-N mode.
+
+ adi,charge-pump-current:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Charge pump current in mA. Default = 2500mA.
+
+ adi,muxout-select:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 6
+ description: |
+ On chip multiplexer output selection.
+ Valid values for the multiplexer output are:
+ 0: Three-State Output (default)
+ 1: DVDD
+ 2: DGND
+ 3: R-Counter output
+ 4: N-Divider output
+ 5: Analog lock detect
+ 6: Digital lock detect
+
+ adi,low-spur-mode-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables low spur mode. Default = Low noise mode.
+
+ adi,cycle-slip-reduction-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables cycle slip reduction.
+
+ adi,charge-cancellation-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enabled charge pump charge cancellation for integer-N modes.
+
+ adi,anti-backlash-3ns-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enables 3ns antibacklash pulse width for integer-N modes.
+
+ adi,band-select-clock-mode-high-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables faster band selection logic.
+
+ adi,12bit-clk-divider:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Clock divider value used when adi,12bit-clkdiv-mode != 0
+
+ adi,clk-divider-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ description: |
+ Valid values for the clkdiv mode are:
+ 0: Clock divider off (default)
+ 1: Fast lock enable
+ 2: Phase resync enable
+
+ adi,aux-output-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables auxiliary RF output.
+
+ adi,aux-output-fundamental-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Selects fundamental VCO output on the auxiliary RF output.
+ Default = Output of RF dividers.
+
+ adi,mute-till-lock-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enables Mute-Till-Lock-Detect function.
+
+ adi,output-power:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ description: |
+ Output power selection.
+ Valid values for the power mode are:
+ 0: -4dBm (default)
+ 1: -1dBm
+ 2: +2dBm
+ 3: +5dBm
+
+ adi,aux-output-power:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ description: |
+ Auxiliary output power selection.
+ Valid values for the power mode are:
+ 0: -4dBm (default)
+ 1: -1dBm
+ 2: +2dBm
+ 3: +5dBm
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pll@4 {
+ compatible = "adi,adf4351";
+ reg = <4>;
+ spi-max-frequency = <10000000>;
+ clocks = <&clk0_ad9523 9>;
+ clock-names = "clkin";
+ adi,channel-spacing = <10000>;
+ adi,power-up-frequency = <2400000000>;
+ adi,phase-detector-polarity-positive-enable;
+ adi,charge-pump-current = <2500>;
+ adi,output-power = <3>;
+ adi,mute-till-lock-enable;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt b/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt
deleted file mode 100644
index bb43d1a..0000000
--- a/Documentation/devicetree/bindings/iio/gyroscope/bmg160.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Bosch BMG160 triaxial rotation sensor (gyroscope)
-
-Required properties:
-
- - compatible : should be "bosch,bmg160", "bosch,bmi055_gyro" or "bosch,bmi088_gyro"
- - reg : the I2C address of the sensor (0x69)
-
-Optional properties:
-
- - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
- flags IRQ_TYPE_EDGE_RISING
-
-Example:
-
-bmg160@69 {
- compatible = "bosch,bmg160";
- reg = <0x69>;
- interrupt-parent = <&gpio6>;
- interrupts = <18 (IRQ_TYPE_EDGE_RISING)>;
-};
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
new file mode 100644
index 0000000..0466483
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/gyroscope/bosch,bmg160.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMG160 triaxial rotation sensor (gyroscope)
+
+maintainers:
+ - H. Nikolaus Schaller <hns@goldelico.com>
+
+properties:
+ compatible:
+ enum:
+ - bosch,bmg160
+ - bosch,bmi055_gyro
+ - bosch,bmi088_gyro
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ description:
+ Should be configured with type IRQ_TYPE_EDGE_RISING.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gyroscope@69 {
+ compatible = "bosch,bmg160";
+ reg = <0x69>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <18 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt
deleted file mode 100644
index 465e104..0000000
--- a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* NXP FXAS21002C Gyroscope device tree bindings
-
-http://www.nxp.com/products/sensors/gyroscopes/3-axis-digital-gyroscope:FXAS21002C
-
-Required properties:
- - compatible : should be "nxp,fxas21002c"
- - reg : the I2C address of the sensor or SPI chip select number for the
- device.
- - vdd-supply: phandle to the regulator that provides power to the sensor.
- - vddio-supply: phandle to the regulator that provides power to the bus.
-
-Optional properties:
- - reset-gpios : gpio used to reset the device, see gpio/gpio.txt
- - interrupts : device support 2 interrupts, INT1 and INT2,
- the interrupts can be triggered on rising or falling edges.
- See interrupt-controller/interrupts.txt
- - interrupt-names: should contain "INT1" or "INT2", the gyroscope interrupt
- line in use.
- - drive-open-drain: the interrupt/data ready line will be configured
- as open drain, which is useful if several sensors share
- the same interrupt line. This is a boolean property.
- (This binding is taken from pinctrl/pinctrl-bindings.txt)
-
-Example:
-
-gyroscope@20 {
- compatible = "nxp,fxas21002c";
- reg = <0x20>;
- vdd-supply = <®_peri_3p15v>;
- vddio-supply = <®_peri_3p15v>;
-};
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
new file mode 100644
index 0000000..d97ee77
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/gyroscope/nxp,fxas21002c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP FXAS21002C Gyroscope
+
+maintainers:
+ - Rui Miguel Silva <rmfrfs@gmail.com>
+
+description: |
+ 3 axis digital gyroscope device with an I2C and SPI interface.
+ http://www.nxp.com/products/sensors/gyroscopes/3-axis-digital-gyroscope:FXAS21002C
+
+properties:
+ compatible:
+ const: nxp,fxas21002c
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the sensor
+
+ vddio-supply:
+ description: Regulator that provides power to the bus
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO connected to reset
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+ description: Either interrupt may be triggered on rising or falling edges.
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - INT1
+ - INT2
+
+ drive-open-drain:
+ type: boolean
+ description: the interrupt/data ready line will be configured as open drain,
+ which is useful if several sensors share the same interrupt
+ line.
+
+ spi-max-frequency:
+ maximum: 2000000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gyroscope@20 {
+ compatible = "nxp,fxas21002c";
+ reg = <0x20>;
+
+ vdd-supply = <®_peri_3p15v>;
+ vddio-supply = <®_peri_3p15v>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ };
+ };
+ spi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gyroscope@0 {
+ compatible = "nxp,fxas2102c";
+ reg = <0x0>;
+
+ spi-max-frequency = <2000000>;
+
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/health/afe4403.txt b/Documentation/devicetree/bindings/iio/health/afe4403.txt
deleted file mode 100644
index 8e41205..0000000
--- a/Documentation/devicetree/bindings/iio/health/afe4403.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Texas Instruments AFE4403 Heart rate and Pulse Oximeter
-
-Required properties:
- - compatible : Should be "ti,afe4403".
- - reg : SPI chip select address of device.
- - tx-supply : Regulator supply to transmitting LEDs.
- - interrupts : The interrupt line the device ADC_RDY pin is
- connected to. For details refer to,
- ../../interrupt-controller/interrupts.txt.
-
-Optional properties:
- - reset-gpios : GPIO used to reset the device.
- For details refer to, ../../gpio/gpio.txt.
-
-For other required and optional properties of SPI slave nodes
-please refer to ../../spi/spi-bus.txt.
-
-Example:
-
-&spi0 {
- heart_mon@0 {
- compatible = "ti,afe4403";
- reg = <0>;
- spi-max-frequency = <10000000>;
-
- tx-supply = <&vbat>;
-
- interrupt-parent = <&gpio1>;
- interrupts = <28 IRQ_TYPE_EDGE_RISING>;
-
- reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
- };
-};
diff --git a/Documentation/devicetree/bindings/iio/health/afe4404.txt b/Documentation/devicetree/bindings/iio/health/afe4404.txt
deleted file mode 100644
index 0b52830..0000000
--- a/Documentation/devicetree/bindings/iio/health/afe4404.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Texas Instruments AFE4404 Heart rate and Pulse Oximeter
-
-Required properties:
- - compatible : Should be "ti,afe4404".
- - reg : I2C address of the device.
- - tx-supply : Regulator supply to transmitting LEDs.
- - interrupts : The interrupt line the device ADC_RDY pin is
- connected to. For details refer to,
- ../interrupt-controller/interrupts.txt.
-
-Optional properties:
- - reset-gpios : GPIO used to reset the device.
- For details refer to, ../gpio/gpio.txt.
-
-Example:
-
-&i2c2 {
- heart_mon@58 {
- compatible = "ti,afe4404";
- reg = <0x58>;
-
- tx-supply = <&vbat>;
-
- interrupt-parent = <&gpio1>;
- interrupts = <28 IRQ_TYPE_EDGE_RISING>;
-
- reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
- };
-};
diff --git a/Documentation/devicetree/bindings/iio/health/max30100.txt b/Documentation/devicetree/bindings/iio/health/max30100.txt
deleted file mode 100644
index 0054908..0000000
--- a/Documentation/devicetree/bindings/iio/health/max30100.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Maxim MAX30100 heart rate and pulse oximeter sensor
-
-* https://datasheets.maximintegrated.com/en/ds/MAX30100.pdf
-
-Required properties:
- - compatible: must be "maxim,max30100"
- - reg: the I2C address of the sensor
- - interrupts: the sole interrupt generated by the device
-
- Refer to interrupt-controller/interrupts.txt for generic
- interrupt client node bindings.
-
-Optional properties:
- - maxim,led-current-microamp: configuration for LED current in microamperes
- while the engine is running. First indexed value is the configuration for
- the RED LED, and second value is for the IR LED.
-
- Refer to the datasheet for the allowed current values.
-
-Example:
-
-max30100@57 {
- compatible = "maxim,max30100";
- reg = <0x57>;
- maxim,led-current-microamp = <24000 50000>;
- interrupt-parent = <&gpio1>;
- interrupts = <16 2>;
-};
diff --git a/Documentation/devicetree/bindings/iio/health/max30102.txt b/Documentation/devicetree/bindings/iio/health/max30102.txt
deleted file mode 100644
index 7ef7ae4..0000000
--- a/Documentation/devicetree/bindings/iio/health/max30102.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Maxim MAX30102 heart rate and pulse oximeter sensor
-Maxim MAX30105 optical particle-sensing module
-
-* https://datasheets.maximintegrated.com/en/ds/MAX30102.pdf
-* https://datasheets.maximintegrated.com/en/ds/MAX30105.pdf
-
-Required properties:
- - compatible: must be "maxim,max30102" or "maxim,max30105"
- - reg: the I2C address of the sensor
- - interrupts: the sole interrupt generated by the device
-
- Refer to interrupt-controller/interrupts.txt for generic
- interrupt client node bindings.
-
-Optional properties:
- - maxim,red-led-current-microamp: configuration for red LED current
- - maxim,ir-led-current-microamp: configuration for IR LED current
- - maxim,green-led-current-microamp: configuration for green LED current
- (max30105 only)
-
- Note that each step is approximately 200 microamps, ranging from 0 uA to
- 50800 uA.
-
-Example:
-
-max30102@57 {
- compatible = "maxim,max30102";
- reg = <0x57>;
- maxim,red-led-current-microamp = <7000>;
- maxim,ir-led-current-microamp = <7000>;
- interrupt-parent = <&gpio1>;
- interrupts = <16 2>;
-};
diff --git a/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml b/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml
new file mode 100644
index 0000000..64b8626
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/health/maxim,max30100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX30100 heart rate and pulse oximeter sensor
+
+maintainers:
+ - Matt Ranostay <matt.ranostay@konsulko.com>
+
+properties:
+ compatible:
+ const: maxim,max30100
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: Connected to ADC_RDY pin.
+
+ maxim,led-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+ description: |
+ LED current whilst the engine is running. First indexed value is
+ the configuration for the RED LED, and second value is for the IR LED.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ heart-rate@57 {
+ compatible = "maxim,max30100";
+ reg = <0x57>;
+ maxim,led-current-microamp = <24000 50000>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 2>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
new file mode 100644
index 0000000..c13c10c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/health/maxim,max30102.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX30102 heart rate and pulse oximeter and MAX30105 particle-sensor
+
+maintainers:
+ - Matt Ranostay <matt.ranostay@konsulko.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max30102
+ - maxim,max30105
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: Connected to ADC_RDY pin.
+
+ maxim,red-led-current-microamp:
+ description: RED LED current. Each step is approximately 200 microamps.
+ minimum: 0
+ maximum: 50800
+
+ maxim,ir-led-current-microamp:
+ description: IR LED current. Each step is approximately 200 microamps.
+ minimum: 0
+ maximum: 50800
+
+ maxim,green-led-current-microamp:
+ description: Green LED current. Each step is approximately 200 microamps.
+ minimum: 0
+ maximum: 50800
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max30100
+ then:
+ properties:
+ maxim,green-led-current-microamp: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ heart-rate@57 {
+ compatible = "maxim,max30102";
+ reg = <0x57>;
+ maxim,red-led-current-microamp = <7000>;
+ maxim,ir-led-current-microamp = <7000>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 2>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml b/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
new file mode 100644
index 0000000..d861526
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/health/ti,afe4403.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AFE4403 Heart rate and Pulse Oximeter
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+properties:
+ compatible:
+ const: ti,afe4403
+
+ reg:
+ maxItems: 1
+
+ tx-supply:
+ description: Supply to transmitting LEDs.
+
+ interrupts:
+ maxItems: 1
+ description: Connected to ADC_RDY pin.
+
+ reset-gpios: true
+
+ spi-max-frequency: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ heart_mon@0 {
+ compatible = "ti,afe4403";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ tx-supply = <&vbat>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml b/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
new file mode 100644
index 0000000..3b4d6c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/health/ti,afe4404.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AFE4404 Heart rate and Pulse Oximeter
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+properties:
+ compatible:
+ const: ti,afe4403
+
+ reg:
+ maxItems: 1
+
+ tx-supply:
+ description: Supply to transmitting LEDs.
+
+ interrupts:
+ maxItems: 1
+ description: Connected to ADC_RDY pin.
+
+ reset-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ heart_mon@58 {
+ compatible = "ti,afe4404";
+ reg = <0x58>;
+ tx-supply = <&vbat>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/humidity/dht11.txt b/Documentation/devicetree/bindings/iio/humidity/dht11.txt
deleted file mode 100644
index ecc24c19..0000000
--- a/Documentation/devicetree/bindings/iio/humidity/dht11.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* DHT11 humidity/temperature sensor (and compatibles like DHT22)
-
-Required properties:
- - compatible: Should be "dht11"
- - gpios: Should specify the GPIO connected to the sensor's data
- line, see "gpios property" in
- Documentation/devicetree/bindings/gpio/gpio.txt.
-
-Example:
-
-humidity_sensor {
- compatible = "dht11";
- gpios = <&gpio0 6 0>;
-}
diff --git a/Documentation/devicetree/bindings/iio/humidity/dht11.yaml b/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
new file mode 100644
index 0000000..2247481
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/humidity/dht11.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DHT11 humidity + temperature sensor
+
+maintainers:
+ - Harald Geyer <harald@ccbib.org>
+
+description: |
+ A simple and low cost module providing a non standard single GPIO based
+ interface. It is believed the part is made by aosong but don't have
+ absolute confirmation of this, or what the aosong part number is.
+
+properties:
+ compatible:
+ const: dht11
+
+ reg:
+ maxItems: 1
+
+ gpios:
+ maxItems: 1
+ description:
+ Single, interrupt capable, GPIO used to communicate with the device.
+
+required:
+ - compatible
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ humidity_sensor {
+ compatible = "dht11";
+ gpios = <&gpio0 6 0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/humidity/hdc100x.txt b/Documentation/devicetree/bindings/iio/humidity/hdc100x.txt
deleted file mode 100644
index c52333b..0000000
--- a/Documentation/devicetree/bindings/iio/humidity/hdc100x.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* HDC100x temperature + humidity sensors
-
-Required properties:
- - compatible: Should contain one of the following:
- ti,hdc1000
- ti,hdc1008
- ti,hdc1010
- ti,hdc1050
- ti,hdc1080
- - reg: i2c address of the sensor
-
-Example:
-
-hdc100x@40 {
- compatible = "ti,hdc1000";
- reg = <0x40>;
-};
diff --git a/Documentation/devicetree/bindings/iio/humidity/hts221.txt b/Documentation/devicetree/bindings/iio/humidity/hts221.txt
deleted file mode 100644
index 84d0293..0000000
--- a/Documentation/devicetree/bindings/iio/humidity/hts221.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* HTS221 STM humidity + temperature sensor
-
-Required properties:
-- compatible: should be "st,hts221"
-- reg: i2c address of the sensor / spi cs line
-
-Optional properties:
-- drive-open-drain: the interrupt/data ready line will be configured
- as open drain, which is useful if several sensors share the same
- interrupt line. This is a boolean property.
- If the requested interrupt is configured as IRQ_TYPE_LEVEL_HIGH or
- IRQ_TYPE_EDGE_RISING a pull-down resistor is needed to drive the line
- when it is not active, whereas a pull-up one is needed when interrupt
- line is configured as IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_EDGE_FALLING.
- Refer to pinctrl/pinctrl-bindings.txt for the property description.
-- interrupts: interrupt mapping for IRQ. It should be configured with
- flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or
- IRQ_TYPE_EDGE_FALLING.
-
- Refer to interrupt-controller/interrupts.txt for generic interrupt
- client node bindings.
-
-Example:
-
-hts221@5f {
- compatible = "st,hts221";
- reg = <0x5f>;
- interrupt-parent = <&gpio0>;
- interrupts = <0 IRQ_TYPE_EDGE_RISING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/humidity/htu21.txt b/Documentation/devicetree/bindings/iio/humidity/htu21.txt
deleted file mode 100644
index 97d7963..0000000
--- a/Documentation/devicetree/bindings/iio/humidity/htu21.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-*HTU21 - Measurement-Specialties htu21 temperature & humidity sensor and humidity part of MS8607 sensor
-
-Required properties:
-
- - compatible: should be "meas,htu21" or "meas,ms8607-humidity"
- - reg: I2C address of the sensor
-
-Example:
-
-htu21@40 {
- compatible = "meas,htu21";
- reg = <0x40>;
-};
diff --git a/Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml b/Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml
new file mode 100644
index 0000000..598473d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/humidity/st,hts221.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HTS221 STM humidity + temperature sensor
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description: |
+ Humidity and temperature sensor with I2C interface and data ready
+ interrupt.
+
+properties:
+ compatible:
+ const: st,hts221
+
+ reg:
+ maxItems: 1
+
+ drive-open-drain:
+ type: boolean
+ description:
+ The interrupt/data ready line will be configured as open drain, which
+ is useful if several sensors share the same interrupt line.
+
+ vdd-supply: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hts221@5f {
+ compatible = "st,hts221";
+ reg = <0x5f>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
index 7037f82..88384b6 100644
--- a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
+++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
@@ -22,8 +22,7 @@
- ti,hdc2010
- ti,hdc2080
- vdd-supply:
- maxItems: 1
+ vdd-supply: true
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
deleted file mode 100644
index aa63cac..0000000
--- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
+++ /dev/null
@@ -1,102 +0,0 @@
-This binding is derived from clock bindings, and based on suggestions
-from Lars-Peter Clausen [1].
-
-Sources of IIO channels can be represented by any node in the device
-tree. Those nodes are designated as IIO providers. IIO consumer
-nodes use a phandle and IIO specifier pair to connect IIO provider
-outputs to IIO inputs. Similar to the gpio specifiers, an IIO
-specifier is an array of one or more cells identifying the IIO
-output on a device. The length of an IIO specifier is defined by the
-value of a #io-channel-cells property in the IIO provider node.
-
-[1] https://marc.info/?l=linux-iio&m=135902119507483&w=2
-
-==IIO providers==
-
-Required properties:
-#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
- with a single IIO output and 1 for nodes with multiple
- IIO outputs.
-
-Optional properties:
-label: A symbolic name for the device.
-
-
-Example for a simple configuration with no trigger:
-
- adc: voltage-sensor@35 {
- compatible = "maxim,max1139";
- reg = <0x35>;
- #io-channel-cells = <1>;
- label = "voltage_feedback_group1";
- };
-
-Example for a configuration with trigger:
-
- adc@35 {
- compatible = "some-vendor,some-adc";
- reg = <0x35>;
-
- adc1: iio-device@0 {
- #io-channel-cells = <1>;
- /* other properties */
- };
- adc2: iio-device@1 {
- #io-channel-cells = <1>;
- /* other properties */
- };
- };
-
-==IIO consumers==
-
-Required properties:
-io-channels: List of phandle and IIO specifier pairs, one pair
- for each IIO input to the device. Note: if the
- IIO provider specifies '0' for #io-channel-cells,
- then only the phandle portion of the pair will appear.
-
-Optional properties:
-io-channel-names:
- List of IIO input name strings sorted in the same
- order as the io-channels property. Consumers drivers
- will use io-channel-names to match IIO input names
- with IIO specifiers.
-io-channel-ranges:
- Empty property indicating that child nodes can inherit named
- IIO channels from this node. Useful for bus nodes to provide
- and IIO channel to their children.
-
-For example:
-
- device {
- io-channels = <&adc 1>, <&ref 0>;
- io-channel-names = "vcc", "vdd";
- };
-
-This represents a device with two IIO inputs, named "vcc" and "vdd".
-The vcc channel is connected to output 1 of the &adc device, and the
-vdd channel is connected to output 0 of the &ref device.
-
-==Example==
-
- adc: max1139@35 {
- compatible = "maxim,max1139";
- reg = <0x35>;
- #io-channel-cells = <1>;
- };
-
- ...
-
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
- <&adc 3>, <&adc 4>, <&adc 5>,
- <&adc 6>, <&adc 7>, <&adc 8>,
- <&adc 9>;
- };
-
- some_consumer {
- compatible = "some-consumer";
- io-channels = <&adc 10>, <&adc 11>;
- io-channel-names = "adc1", "adc2";
- };
diff --git a/Documentation/devicetree/bindings/iio/impedance-analyzer/ad5933.txt b/Documentation/devicetree/bindings/iio/impedance-analyzer/ad5933.txt
deleted file mode 100644
index 5ff3872..0000000
--- a/Documentation/devicetree/bindings/iio/impedance-analyzer/ad5933.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Analog Devices AD5933/AD5934 Impedance Converter, Network Analyzer
-
-https://www.analog.com/media/en/technical-documentation/data-sheets/AD5933.pdf
-https://www.analog.com/media/en/technical-documentation/data-sheets/AD5934.pdf
-
-Required properties:
- - compatible : should be one of
- "adi,ad5933"
- "adi,ad5934"
- - reg : the I2C address.
- - vdd-supply : The regulator supply for DVDD, AVDD1 and AVDD2 when they
- are connected together.
-
-Optional properties:
-- clocks : external clock reference.
-- clock-names : must be "mclk" if clocks is set.
-
-Example for a I2C device node:
-
- impedance-analyzer@0d {
- compatible = "adi,adxl345";
- reg = <0x0d>;
- vdd-supply = <&vdd_supply>;
- clocks = <&ref_clk>;
- clock-names = "mclk";
- };
diff --git a/Documentation/devicetree/bindings/iio/impedance-analyzer/adi,ad5933.yaml b/Documentation/devicetree/bindings/iio/impedance-analyzer/adi,ad5933.yaml
new file mode 100644
index 0000000..2ad0435
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/impedance-analyzer/adi,ad5933.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/impedance-analyzer/adi,ad5933.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5933/AD5934 Impedance Converter, Network Analyzer
+
+maintainers:
+ - Marcelo Schmitt <marcelo.schmitt1@gmail.com>
+ - Gabriel Capella <gabriel@capella.pro>
+
+description: |
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD5933.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD5934.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5933
+ - adi,ad5934
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: |
+ The regulator supply for DVDD, AVDD1 and AVDD2 when they
+ are connected together. Used to calculate voltage scaling of measurement
+ channels.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ impedance-analyzer@d {
+ compatible = "adi,ad5933";
+ reg = <0x0d>;
+ vdd-supply = <&vdd_supply>;
+ clocks = <&ref_clk>;
+ clock-names = "mclk";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt
deleted file mode 100644
index cd903a1..0000000
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-
-Analog Devices ADIS16480 and similar IMUs
-
-Required properties for the ADIS16480:
-
-- compatible: Must be one of
- * "adi,adis16375"
- * "adi,adis16480"
- * "adi,adis16485"
- * "adi,adis16488"
- * "adi,adis16490"
- * "adi,adis16495-1"
- * "adi,adis16495-2"
- * "adi,adis16495-3"
- * "adi,adis16497-1"
- * "adi,adis16497-2"
- * "adi,adis16497-3"
-- reg: SPI chip select number for the device
-- spi-max-frequency: Max SPI frequency to use
- see: Documentation/devicetree/bindings/spi/spi-bus.txt
-- spi-cpha: See Documentation/devicetree/bindings/spi/spi-bus.txt
-- spi-cpol: See Documentation/devicetree/bindings/spi/spi-bus.txt
-- interrupts: interrupt mapping for IRQ, accepted values are:
- * IRQF_TRIGGER_RISING
- * IRQF_TRIGGER_FALLING
-
-Optional properties:
-
-- interrupt-names: Data ready line selection. Valid values are:
- * DIO1
- * DIO2
- * DIO3
- * DIO4
- If this field is left empty, DIO1 is assigned as default data ready
- signal.
-- reset-gpios: must be the device tree identifier of the RESET pin. As the line
- is active low, it should be marked GPIO_ACTIVE_LOW.
-- clocks: phandle to the external clock. Should be set according to
- "clock-names".
- If this field is left empty together with the "clock-names" field, then
- the internal clock is used.
-- clock-names: The name of the external clock to be used. Valid values are:
- * sync: In sync mode, the internal clock is disabled and the frequency
- of the external clock signal establishes therate of data
- collection and processing. See Fig 14 and 15 in the datasheet.
- The clock-frequency must be:
- * 3000 to 4500 Hz for adis1649x devices.
- * 700 to 2400 Hz for adis1648x devices.
- * pps: In Pulse Per Second (PPS) Mode, the rate of data collection and
- production is equal to the product of the external clock
- frequency and the scale factor in the SYNC_SCALE register, see
- Table 154 in the datasheet.
- The clock-frequency must be:
- * 1 to 128 Hz for adis1649x devices.
- * This mode is not supported by adis1648x devices.
- If this field is left empty together with the "clocks" field, then the
- internal clock is used.
-- adi,ext-clk-pin: The DIOx line to be used as an external clock input.
- Valid values are:
- * DIO1
- * DIO2
- * DIO3
- * DIO4
- Each DIOx pin supports only one function at a time (data ready line
- selection or external clock input). When a single pin has two
- two assignments, the enable bit for the lower priority function
- automatically resets to zero (disabling the lower priority function).
- Data ready has highest priority.
- If this field is left empty, DIO2 is assigned as default external clock
- input pin.
-
-Example:
-
- imu@0 {
- compatible = "adi,adis16495-1";
- reg = <0>;
- spi-max-frequency = <3200000>;
- spi-cpol;
- spi-cpha;
- interrupts = <25 IRQF_TRIGGER_FALLING>;
- interrupt-parent = <&gpio>;
- interrupt-names = "DIO2";
- clocks = <&adis16495_sync>;
- clock-names = "sync";
- adi,ext-clk-pin = "DIO1";
- };
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml
new file mode 100644
index 0000000..5dbe24b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/adi,adis16480.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADIS16480 and similar IMUs
+
+maintainers:
+ - Alexandru Ardelean <alexandru.ardelean@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - adi,adis16375
+ - adi,adis16480
+ - adi,adis16485
+ - adi,adis16488
+ - adi,adis16490
+ - adi,adis16495-1
+ - adi,adis16495-2
+ - adi,adis16495-3
+ - adi,adis16497-1
+ - adi,adis16497-2
+ - adi,adis16497-3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+ description: |
+ Accepted interrupt types are:
+ * IRQ_TYPE_EDGE_RISING
+ * IRQ_TYPE_EDGE_FALLING
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ description:
+ Default if not supplied is DIO1.
+ items:
+ enum:
+ - DIO1
+ - DIO2
+ - DIO3
+ - DIO4
+
+ spi-max-frequency: true
+
+ spi-cpha: true
+ spi-cpol: true
+
+ reset-gpios:
+ maxItems: 1
+ description: Connected to RESET pin which is active low.
+
+ clocks:
+ maxItems: 1
+ description: If not provided, then the internal clock is used.
+
+ clock-names:
+ description: |
+ sync: In sync mode, the internal clock is disabled and the frequency
+ of the external clock signal establishes therate of data
+ collection and processing. See Fig 14 and 15 in the datasheet.
+ The clock-frequency must be:
+ * 3000 to 4500 Hz for adis1649x devices.
+ * 700 to 2400 Hz for adis1648x devices.
+ pps: In Pulse Per Second (PPS) Mode, the rate of data collection and
+ production is equal to the product of the external clock
+ frequency and the scale factor in the SYNC_SCALE register, see
+ Table 154 in the datasheet.
+ The clock-frequency must be:
+ * 1 to 128 Hz for adis1649x devices.
+ * This mode is not supported by adis1648x devices.
+ enum:
+ - sync
+ - pps
+
+ adi,ext-clk-pin:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ The DIOx line to be used as an external clock input.
+ Each DIOx pin supports only one function at a time (data ready line
+ selection or external clock input). When a single pin has two
+ two assignments, the enable bit for the lower priority function
+ automatically resets to zero (disabling the lower priority function).
+ Data ready has highest priority.
+ If not provided then DIO2 is assigned as default external clock
+ input pin.
+ enum:
+ - DIO1
+ - DIO2
+ - DIO3
+ - DIO4
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - spi-cpha
+ - spi-cpol
+ - spi-max-frequency
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@0 {
+ compatible = "adi,adis16495-1";
+ reg = <0>;
+ spi-max-frequency = <3200000>;
+ spi-cpol;
+ spi-cpha;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ interrupt-names = "DIO2";
+ clocks = <&adis16495_sync>;
+ clock-names = "sync";
+ adi,ext-clk-pin = "DIO1";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
new file mode 100644
index 0000000..d9b3213
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/st,lsm6dsx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM 6-axis (acc + gyro) IMU Mems sensors
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ Devices have both I2C and SPI interfaces.
+
+properties:
+ compatible:
+ enum:
+ - st,lsm6ds3
+ - st,lsm6ds3h
+ - st,lsm6dsl
+ - st,lsm6dsm
+ - st,ism330dlc
+ - st,lsm6dso
+ - st,asm330lhh
+ - st,lsm6dsox
+ - st,lsm6dsr
+ - st,lsm6ds3tr-c
+ - st,ism330dhcx
+ - st,lsm9ds1-imu
+ - st,lsm6ds0
+ - st,lsm6dsrx
+ - st,lsm6dst
+ - st,lsm6dsop
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+ description:
+ Supports up to 2 interrupt lines via the INT1 and INT2 pins.
+
+ spi-max-frequency: true
+
+ vdd-supply:
+ description: if defined provides VDD power to the sensor.
+
+ vddio-supply:
+ description: if defined provides VDD IO power to the sensor.
+
+ st,drdy-int-pin:
+ $ref: '/schemas/types.yaml#/definitions/uint32'
+ description: |
+ The pin on the package that will be used to signal data ready
+ enum:
+ - 1
+ - 2
+
+ st,pullups:
+ type: boolean
+ description: enable/disable internal i2c controller pullup resistors.
+
+ drive-open-drain:
+ type: boolean
+ description:
+ The interrupt/data ready line will be configured as open drain, which
+ is useful if several sensors share the same interrupt line.
+
+ wakeup-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@6b {
+ compatible = "st,lsm6dsm";
+ reg = <0x6b>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
deleted file mode 100644
index cef4bc1..0000000
--- a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-* ST_LSM6DSx driver for STM 6-axis (acc + gyro) imu Mems sensors
-
-Required properties:
-- compatible: must be one of:
- "st,lsm6ds3"
- "st,lsm6ds3h"
- "st,lsm6dsl"
- "st,lsm6dsm"
- "st,ism330dlc"
- "st,lsm6dso"
- "st,asm330lhh"
- "st,lsm6dsox"
- "st,lsm6dsr"
- "st,lsm6ds3tr-c"
- "st,ism330dhcx"
- "st,lsm9ds1-imu"
- "st,lsm6ds0"
- "st,lsm6dsrx"
-- reg: i2c address of the sensor / spi cs line
-
-Optional properties:
-- st,drdy-int-pin: the pin on the package that will be used to signal
- "data ready" (valid values: 1 or 2).
-- st,pullups : enable/disable internal i2c controller pullup resistors.
-- drive-open-drain: the interrupt/data ready line will be configured
- as open drain, which is useful if several sensors share the same
- interrupt line. This is a boolean property.
- (This binding is taken from pinctrl/pinctrl-bindings.txt)
- If the requested interrupt is configured as IRQ_TYPE_LEVEL_HIGH or
- IRQ_TYPE_EDGE_RISING a pull-down resistor is needed to drive the line
- when it is not active, whereas a pull-up one is needed when interrupt
- line is configured as IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_EDGE_FALLING.
-- interrupts: interrupt mapping for IRQ. It should be configured with
- flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or
- IRQ_TYPE_EDGE_FALLING.
-- wakeup-source: Enables wake up of host system on event.
-
- Refer to interrupt-controller/interrupts.txt for generic interrupt
- client node bindings.
-
-Example:
-
-lsm6dsm@6b {
- compatible = "st,lsm6dsm";
- reg = <0x6b>;
- interrupt-parent = <&gpio0>;
- interrupts = <0 IRQ_TYPE_EDGE_RISING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt b/Documentation/devicetree/bindings/iio/light/apds9300.txt
deleted file mode 100644
index 3aa6db3..0000000
--- a/Documentation/devicetree/bindings/iio/light/apds9300.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Avago APDS9300 ambient light sensor
-
-https://www.avagotech.com/docs/AV02-1077EN
-
-Required properties:
-
- - compatible : should be "avago,apds9300"
- - reg : the I2C address of the sensor
-
-Optional properties:
-
- - interrupts : interrupt mapping for GPIO IRQ
-
-Example:
-
-apds9300@39 {
- compatible = "avago,apds9300";
- reg = <0x39>;
- interrupt-parent = <&gpio2>;
- interrupts = <29 8>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt b/Documentation/devicetree/bindings/iio/light/apds9960.txt
deleted file mode 100644
index c53ddb8..0000000
--- a/Documentation/devicetree/bindings/iio/light/apds9960.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Avago APDS9960 gesture/RGB/ALS/proximity sensor
-
-https://www.avagotech.com/docs/AV02-4191EN
-
-Required properties:
-
- - compatible: must be "avago,apds9960"
- - reg: the I2c address of the sensor
- - interrupts : the sole interrupt generated by the device
-
- Refer to interrupt-controller/interrupts.txt for generic interrupt client
- node bindings.
-
-Example:
-
-apds9960@39 {
- compatible = "avago,apds9960";
- reg = <0x39>;
- interrupt-parent = <&gpio1>;
- interrupts = <16 1>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml b/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml
new file mode 100644
index 0000000..206af44
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/avago,apds9300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Avago APDS9300 ambient light sensor
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Datasheet at https://www.avagotech.com/docs/AV02-1077EN
+
+properties:
+ compatible:
+ const: avago,apds9300
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@39 {
+ compatible = "avago,apds9300";
+ reg = <0x39>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 8>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml b/Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml
new file mode 100644
index 0000000..f06e0fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/avago,apds9960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Avago APDS9960 gesture/RGB/ALS/proximity sensor
+
+maintainers:
+ - Matt Ranostay <matt.ranostay@konsulko.com>
+
+description: |
+ Datasheet at https://www.avagotech.com/docs/AV02-4191EN
+
+properties:
+ compatible:
+ const: avago,apds9960
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@39 {
+ compatible = "avago,apds9960";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/capella,cm3605.yaml b/Documentation/devicetree/bindings/iio/light/capella,cm3605.yaml
new file mode 100644
index 0000000..2797293
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/capella,cm3605.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/capella,cm3605.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Capella Microsystems CM3605 Ambient Light and Short Distance Proximity Sensor
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+ - Kevin Tsai <ktsai@capellamicro.com>
+
+description: |
+ The CM3605 is an entirely analog part. However, it requires quite a bit of
+ software logic to interface a host operating system.
+
+ This ALS and proximity sensor was one of the very first deployed in mobile
+ handsets, notably it is used in the very first Nexus One Android phone from
+ 2010.
+
+properties:
+ compatible:
+ const: capella,cm3605
+
+ aset-gpios:
+ maxItems: 1
+ description:
+ ASET line (drive low to activate the ALS, should be flagged
+ GPIO_ACTIVE_LOW)
+
+ interrupts:
+ maxItems: 1
+ description:
+ Connected to the POUT (proximity sensor out) line. The edge
+ detection must be set to IRQ_TYPE_EDGE_BOTH so as to detect
+ movements toward and away from the proximity sensor.
+
+ io-channels:
+ maxItems: 1
+ description:
+ ADC channel used for converting the voltage from AOUT to a digital
+ representation.
+
+ io-channel-names:
+ const: aout
+
+ vdd-supply: true
+
+ capella,aset-resistance-ohms:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [50000, 100000, 300000, 600000]
+ description: >
+ Sensitivity calibration resistance. Note that calibration curves
+ are only provided for specific allowed values. Default: 100 kOhms.
+
+required:
+ - compatible
+ - aset-gpios
+ - interrupts
+ - io-channels
+ - io-channel-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ light-sensor {
+ compatible = "capella,cm3605";
+ vdd-supply = <&foo_reg>;
+ aset-gpios = <&foo_gpio 1 GPIO_ACTIVE_LOW>;
+ capella,aset-resistance-ohms = <100000>;
+ interrupts = <1 IRQ_TYPE_EDGE_BOTH>;
+ io-channels = <&adc 0x01>;
+ io-channel-names = "aout";
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/capella,cm36651.yaml b/Documentation/devicetree/bindings/iio/light/capella,cm36651.yaml
new file mode 100644
index 0000000..446d94f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/capella,cm36651.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/capella,cm36651.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Capella CM36651 I2C Proximity and Color Light sensor
+
+maintainers:
+ - Beomho Seo <beomho.seo@samsung.com>
+
+properties:
+ compatible:
+ const: capella,cm36651
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vled-supply:
+ description: |
+ Supply for the IR_LED which is part of the cm36651 for proximity detection.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vled-supply
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@18 {
+ compatible = "capella,cm36651";
+ reg = <0x18>;
+ interrupt-parent = <&gpx0>;
+ interrupts = <2 0>;
+ vled-supply = <&ps_als_reg>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/cm3605.txt b/Documentation/devicetree/bindings/iio/light/cm3605.txt
deleted file mode 100644
index 56331a7..0000000
--- a/Documentation/devicetree/bindings/iio/light/cm3605.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Capella Microsystems CM3605
-Ambient Light and Short Distance Proximity Sensor
-
-The CM3605 is an entirely analog part which however require quite a bit of
-software logic to interface a host operating system.
-
-This ALS and proximity sensor was one of the very first deployed in mobile
-handsets, notably it is used in the very first Nexus One Android phone from
-2010.
-
-Required properties:
-- compatible: must be: "capella,cm3605"
-- aset-gpios: GPIO line controlling the ASET line (drive low
- to activate the ALS, should be flagged GPIO_ACTIVE_LOW)
-- interrupts: the IRQ line (such as a GPIO) that is connected to
- the POUT (proximity sensor out) line. The edge detection must
- be set to IRQ_TYPE_EDGE_BOTH so as to detect movements toward
- and away from the proximity sensor.
-- io-channels: the ADC channel used for converting the voltage from
- AOUT to a digital representation.
-- io-channel-names: must be "aout"
-
-Optional properties:
-- vdd-supply: regulator supplying VDD power to the component.
-- capella,aset-resistance-ohms: the sensitivity calibration resistance,
- in Ohms. Valid values are: 50000, 100000, 300000 and 600000,
- as these are the resistance values that we are supplied with
- calibration curves for. If not supplied, 100 kOhm will be assumed
- but it is strongly recommended to supply this.
-
-Example:
-
-cm3605 {
- compatible = "capella,cm3605";
- vdd-supply = <&foo_reg>;
- aset-gpios = <&foo_gpio 1 GPIO_ACTIVE_LOW>;
- capella,aset-resistance-ohms = <100000>;
- interrupts = <1 IRQ_TYPE_EDGE_BOTH>;
- io-channels = <&adc 0x01>;
- io-channel-names = "aout";
-};
diff --git a/Documentation/devicetree/bindings/iio/light/cm36651.txt b/Documentation/devicetree/bindings/iio/light/cm36651.txt
deleted file mode 100644
index c03e19d..0000000
--- a/Documentation/devicetree/bindings/iio/light/cm36651.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Capella CM36651 I2C Proximity and Color Light sensor
-
-Required properties:
-- compatible: must be "capella,cm36651"
-- reg: the I2C address of the device
-- interrupts: interrupt-specifier for the sole interrupt
- generated by the device
-- vled-supply: regulator for the IR LED. IR_LED is a part
- of the cm36651 for proximity detection.
- As covered in ../../regulator/regulator.txt
-
-Example:
-
- i2c_cm36651: i2c-gpio {
- /* ... */
-
- cm36651@18 {
- compatible = "capella,cm36651";
- reg = <0x18>;
- interrupt-parent = <&gpx0>;
- interrupts = <2 0>;
- vled-supply = <&ps_als_reg>;
- };
-
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt b/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt
deleted file mode 100644
index 9231c82..0000000
--- a/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Sharp GP2AP020A00F I2C Proximity/ALS sensor
-
-The proximity detector sensor requires power supply
-for its built-in led. It is also defined by this binding.
-
-Required properties:
-
- - compatible : should be "sharp,gp2ap020a00f"
- - reg : the I2C slave address of the light sensor
- - interrupts : interrupt specifier for the sole interrupt generated
- by the device
- - vled-supply : VLED power supply, as covered in ../regulator/regulator.txt
-
-Example:
-
-gp2ap020a00f@39 {
- compatible = "sharp,gp2ap020a00f";
- reg = <0x39>;
- interrupts = <2 0>;
- vled-supply = <...>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/max44009.txt b/Documentation/devicetree/bindings/iio/light/max44009.txt
deleted file mode 100644
index 4a98848..0000000
--- a/Documentation/devicetree/bindings/iio/light/max44009.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* MAX44009 Ambient Light Sensor
-
-Required properties:
-
-- compatible: should be "maxim,max44009"
-- reg: the I2C address of the device (default is <0x4a>)
-
-Optional properties:
-
-- interrupts: interrupt mapping for GPIO IRQ. Should be configured with
- IRQ_TYPE_EDGE_FALLING.
-
-Refer to interrupt-controller/interrupts.txt for generic interrupt client
-node bindings.
-
-Example:
-
-light-sensor@4a {
- compatible = "maxim,max44009";
- reg = <0x4a>;
-
- interrupt-parent = <&gpio1>;
- interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/maxim,max44009.yaml b/Documentation/devicetree/bindings/iio/light/maxim,max44009.yaml
new file mode 100644
index 0000000..5911bd9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/maxim,max44009.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/maxim,max44009.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX44009 Ambient Light Sensor
+
+maintainers:
+ - Robert Eshleman <bobbyeshleman@gmail.com>
+
+properties:
+ compatible:
+ const: maxim,max44009
+
+ reg:
+ maxItems: 1
+ description: Default address is 0x4a
+
+ interrupts:
+ maxItems: 1
+ description: Should be configured with type IRQ_TYPE_EDGE_FALLING
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@4a {
+ compatible = "maxim,max44009";
+ reg = <0x4a>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/opt3001.txt b/Documentation/devicetree/bindings/iio/light/opt3001.txt
deleted file mode 100644
index 9e6f299..0000000
--- a/Documentation/devicetree/bindings/iio/light/opt3001.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Texas Instruments OPT3001 Ambient Light Sensor
-
-The driver supports interrupt-driven and interrupt-less operation, depending
-on whether an interrupt property has been populated into the DT. Note that
-the optional generation of IIO events on rising/falling light threshold changes
-requires the use of interrupts. Without interrupts, only the simple reading
-of the current light value is supported through the IIO API.
-
-https://www.ti.com/product/opt3001
-
-Required properties:
- - compatible: should be "ti,opt3001"
- - reg: the I2C address of the sensor
-
-Optional properties:
- - interrupts: interrupt mapping for GPIO IRQ (configure for falling edge)
-
-Example:
-
-opt3001@44 {
- compatible = "ti,opt3001";
- reg = <0x44>;
- interrupt-parent = <&gpio1>;
- interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/renesas,isl29501.txt b/Documentation/devicetree/bindings/iio/light/renesas,isl29501.txt
deleted file mode 100644
index 4695799..0000000
--- a/Documentation/devicetree/bindings/iio/light/renesas,isl29501.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* ISL29501 Time-of-flight sensor.
-
-Required properties:
-
- - compatible : should be "renesas,isl29501"
- - reg : the I2C address of the sensor
-
-Example:
-
-isl29501@57 {
- compatible = "renesas,isl29501";
- reg = <0x57>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/sharp,gp2ap020a00f.yaml b/Documentation/devicetree/bindings/iio/light/sharp,gp2ap020a00f.yaml
new file mode 100644
index 0000000..3fabf1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/sharp,gp2ap020a00f.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/sharp,gp2ap020a00f.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sharp GP2AP020A00F I2C Proximity/ALS sensor
+
+maintainers:
+ - Kyungmin Park <kyungmin.park@samsung.com>
+
+description: |
+ The proximity detector sensor requires power supply for its built-in led.
+
+properties:
+ compatible:
+ const: sharp,gp2ap020a00f
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vled-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vled-supply
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@39 {
+ compatible = "sharp,gp2ap020a00f";
+ reg = <0x39>;
+ interrupts = <2 0>;
+ vled-supply = <&als_reg>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/st,uvis25.yaml b/Documentation/devicetree/bindings/iio/light/st,uvis25.yaml
new file mode 100644
index 0000000..c86e5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/st,uvis25.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/st,uvis25.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST UVIS25 uv sensor
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
+
+properties:
+ compatible:
+ const: st,uvis25
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uv-sensor@47 {
+ compatible = "st,uvis25";
+ reg = <0x47>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml b/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml
new file mode 100644
index 0000000..27c36ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/st,vl6180.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicro VL6180 ALS, range and proximity sensor
+
+maintainers:
+ - Manivannan Sadhasivam <manivannanece23@gmail.com>
+ - Peter Meerwald-Stadler <pmeerw@pmeerw.net>
+
+description: |
+ Proximity sensing module incorporating time of flight sensor
+ Datasheet at https://www.st.com/resource/en/datasheet/vl6180x.pdf
+
+properties:
+ compatible:
+ const: st,vl6180
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ proximity@29 {
+ compatible = "st,vl6180";
+ reg = <0x29>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml
new file mode 100644
index 0000000..441e934
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/ti,opt3001.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OPT3001 Ambient Light Sensor
+
+maintainers:
+ - Andreas Dannenberg <dannenberg@ti.com>
+
+description: |
+ The device supports interrupt-driven and interrupt-less operation, depending
+ on whether an interrupt property has been populated into the DT.
+
+properties:
+ compatible:
+ const: ti,opt3001
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: Should be configured with type IRQ_TYPE_EDGE_FALLING
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@44 {
+ compatible = "ti,opt3001";
+ reg = <0x44>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml b/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml
new file mode 100644
index 0000000..de5882c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/upisemi,us5182.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/upisemi,us5182.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UPISEMI us5182d I2C ALS and Proximity sensor
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+properties:
+ compatible:
+ const: upisemi,asd5182
+
+ reg:
+ maxItems: 1
+
+ upsemi,glass-coef:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ glass attenuation factor - compensation factor of resolution 1000
+ for material transmittance.
+ default: 1000
+
+ upisemi,dark-ths:
+ $ref: /schemas/types.yaml#/definitions/uint16-array
+ minItems: 8
+ maxItems: 8
+ description:
+ 16-bit thresholds (adc counts) corresponding to every scale.
+
+ upisemi,upper-dark-gain:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: |
+ 8-bit dark gain compensation factor(4 int and 4 fractional bits - Q4.4)
+ applied when light > threshold.
+ default: 0
+
+ upisemi,lower-dark-gain:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: |
+ 8-bit dark gain compensation factor(4 int and 4 fractional bits - Q4.4)
+ applied when light < threshold.
+ default: 0x16
+
+ upisemi,continuous:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ This chip has two power modes: one-shot (chip takes one measurement and
+ then shuts itself down) and continuous (chip takes continuous
+ measurements). The one-shot mode is more power-friendly but the
+ continuous mode may be more reliable. If this property is specified
+ the continuous mode will be used instead of the default one-shot one for
+ raw reads.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@39 {
+ compatible = "upisemi,usd5182";
+ reg = <0x39>;
+ upisemi,glass-coef = < 1000 >;
+ upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>;
+ upisemi,upper-dark-gain = /bits/ 8 <0x00>;
+ upisemi,lower-dark-gain = /bits/ 8 <0x16>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt
deleted file mode 100644
index a619799..0000000
--- a/Documentation/devicetree/bindings/iio/light/us5182d.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-* UPISEMI us5182d I2C ALS and Proximity sensor
-
-Required properties:
-- compatible: must be "upisemi,usd5182"
-- reg: the I2C address of the device
-
-Optional properties:
-- upisemi,glass-coef: glass attenuation factor - compensation factor of
- resolution 1000 for material transmittance.
-
-- upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc
- counts) corresponding to every scale.
-
-- upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4
- fractional bits - Q4.4) applied when light > threshold
-
-- upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4
- fractional bits - Q4.4) applied when light < threshold
-
-- upisemi,continuous: This chip has two power modes: one-shot (chip takes one
- measurement and then shuts itself down) and continuous (
- chip takes continuous measurements). The one-shot mode is
- more power-friendly but the continuous mode may be more
- reliable. If this property is specified the continuous
- mode will be used instead of the default one-shot one for
- raw reads.
-
-If the optional properties are not specified these factors will default to the
-values in the below example.
-The glass-coef defaults to no compensation for the covering material.
-The threshold array defaults to experimental values that work with US5182D
-sensor on evaluation board - roughly between 12-32 lux.
-There will be no dark-gain compensation by default when ALS > thresh
-(0 * dark-gain), and a 1.35 compensation factor when ALS < thresh.
-
-Example:
-
- usd5182@39 {
- compatible = "upisemi,usd5182";
- reg = <0x39>;
- upisemi,glass-coef = < 1000 >;
- upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>;
- upisemi,upper-dark-gain = /bits/ 8 <0x00>;
- upisemi,lower-dark-gain = /bits/ 8 <0x16>;
- };
diff --git a/Documentation/devicetree/bindings/iio/light/uvis25.txt b/Documentation/devicetree/bindings/iio/light/uvis25.txt
deleted file mode 100644
index 043c139..0000000
--- a/Documentation/devicetree/bindings/iio/light/uvis25.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* ST UVIS25 uv sensor
-
-Required properties:
-- compatible: should be "st,uvis25"
-- reg: i2c address of the sensor / spi cs line
-
-Optional properties:
-- interrupts: interrupt mapping for IRQ. It should be configured with
- flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or
- IRQ_TYPE_EDGE_FALLING.
-
- Refer to interrupt-controller/interrupts.txt for generic interrupt
- client node bindings.
-
-Example:
-
-uvis25@47 {
- compatible = "st,uvis25";
- reg = <0x47>;
- interrupt-parent = <&gpio0>;
- interrupts = <0 IRQ_TYPE_EDGE_RISING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/vcnl4035.txt b/Documentation/devicetree/bindings/iio/light/vcnl4035.txt
deleted file mode 100644
index c07c7f0..0000000
--- a/Documentation/devicetree/bindings/iio/light/vcnl4035.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-VISHAY VCNL4035 - Ambient Light and proximity sensor
-
-Link to datasheet: https://www.vishay.com/docs/84251/vcnl4035x01.pdf
-
-Required properties:
-
- -compatible: should be "vishay,vcnl4035"
- -reg: I2C address of the sensor, should be 0x60
- -interrupts: interrupt mapping for GPIO IRQ (level active low)
-
-Example:
-
-light-sensor@60 {
- compatible = "vishay,vcnl4035";
- reg = <0x60>;
- interrupt-parent = <&gpio4>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/iio/light/vishay,vcnl4035.yaml b/Documentation/devicetree/bindings/iio/light/vishay,vcnl4035.yaml
new file mode 100644
index 0000000..2c57ff0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/vishay,vcnl4035.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/vishay,vcnl4035.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VISHAY VCNL4035 ambient Light and proximity sensor
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Datasheet at https://www.vishay.com/docs/84251/vcnl4035x01.pdf
+
+properties:
+ compatible:
+ const: vishay,vcnl4035
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@60 {
+ compatible = "vishay,vcnl4035";
+ reg = <0x60>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/vl6180.txt b/Documentation/devicetree/bindings/iio/light/vl6180.txt
deleted file mode 100644
index fb9137d..0000000
--- a/Documentation/devicetree/bindings/iio/light/vl6180.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-STMicro VL6180 - ALS, range and proximity sensor
-
-Link to datasheet: https://www.st.com/resource/en/datasheet/vl6180x.pdf
-
-Required properties:
-
- -compatible: should be "st,vl6180"
- -reg: the I2C address of the sensor
-
-Example:
-
-vl6180@29 {
- compatible = "st,vl6180";
- reg = <0x29>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt
deleted file mode 100644
index 7f06eff..0000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8974.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* Asahi Kasei AK8974 magnetometer sensor
-
-Required properties:
-
-- compatible:
- * "asahi-kasei,ak8974"
- * "alps,hscdtd008a"
-- reg : the I2C address of the magnetometer
-
-Optional properties:
-
-- avdd-supply: regulator supply for the analog voltage
- (see regulator/regulator.txt)
-- dvdd-supply: regulator supply for the digital voltage
- (see regulator/regulator.txt)
-- interrupts: data ready (DRDY) and interrupt (INT1) lines
- from the chip, the DRDY interrupt must be placed first.
- The interrupts can be triggered on rising or falling
- edges alike.
-- mount-matrix: an optional 3x3 mounting rotation matrix
-
-Example:
-
-ak8974@f {
- compatible = "asahi-kasei,ak8974";
- reg = <0x0f>;
- avdd-supply = <&foo_reg>;
- dvdd-supply = <&bar_reg>;
- interrupts = <0 IRQ_TYPE_EDGE_RISING>,
- <1 IRQ_TYPE_EDGE_RISING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8974.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8974.yaml
new file mode 100644
index 0000000..cefb70d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8974.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/asahi-kasei,ak8974.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asahi Kasei AK8974 magnetometer sensor
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - alps,hscdtd008a
+ - asahi-kasei,ak8974
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+ description: |
+ Data ready (DRDY) and interrupt (INT1) lines from the chip. The DRDY
+ interrupt must be placed first. The interrupts can be triggered on
+ rising or falling edges.
+
+ avdd-supply: true
+
+ dvdd-supply: true
+
+ mount-matrix: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@f {
+ compatible = "asahi-kasei,ak8974";
+ reg = <0x0f>;
+ avdd-supply = <&foo_reg>;
+ dvdd-supply = <&bar_reg>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>,
+ <1 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
deleted file mode 100644
index 22912e4..0000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Bosch BMC150 magnetometer sensor
-
-http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf
-
-Required properties:
-
- - compatible : should be one of:
- "bosch,bmc150_magn"
- "bosch,bmc156_magn"
- "bosch,bmm150"
- "bosch,bmm150_magn" (DEPRECATED, use bosch,bmm150)
- - reg : the I2C address of the magnetometer
-
-Optional properties:
-
- - interrupts : interrupt mapping for GPIO IRQ
-
-Example:
-
-bmc150_magn@12 {
- compatible = "bosch,bmc150_magn";
- reg = <0x12>;
- interrupt-parent = <&gpio1>;
- interrupts = <0 1>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml b/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml
new file mode 100644
index 0000000..cdef7ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/bosch,bmc150_magn.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMC150 magnetometer sensor
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Supports a range of parts, some of which form part of a multi die
+ package that also contains other sensors. The interface is independent
+ however, so a separate driver is used to support the magnetometer part.
+ Datasheet at:
+ http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf
+
+properties:
+ compatible:
+ description:
+ Note the bmm150_magn is a deprecated compatible as this part contains only
+ a magnetometer.
+ enum:
+ - bosch,bmc150_magn
+ - bosch,bmc156_magn
+ - bosch,bmm150
+ - bosch,bmm150_magn
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@12 {
+ compatible = "bosch,bmc150_magn";
+ reg = <0x12>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <0 1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml b/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml
new file mode 100644
index 0000000..6b54d32
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/fsl,mag3110.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MAG3110 magnetometer sensor
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,mag3110
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ vddio-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3_mag3110_int>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <16 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt b/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt
deleted file mode 100644
index 8e191ee..0000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Honeywell HMC5843 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "honeywell,hmc5843"
- Other models which are supported with driver are:
- "honeywell,hmc5883"
- "honeywell,hmc5883l"
- "honeywell,hmc5983"
- - reg : the I2C address of the magnetometer - typically 0x1e
-
-Optional properties:
-
- - gpios : should be device tree identifier of the magnetometer DRDY pin
-
-Example:
-
-hmc5843@1e {
- compatible = "honeywell,hmc5843"
- reg = <0x1e>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/honeywell,hmc5843.yaml b/Documentation/devicetree/bindings/iio/magnetometer/honeywell,hmc5843.yaml
new file mode 100644
index 0000000..5e778c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/honeywell,hmc5843.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/honeywell,hmc5843.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Honeywell HMC5843 magnetometer sensor
+
+maintainers:
+ - Neil Brown <neilb@suse.de>
+
+properties:
+ compatible:
+ enum:
+ - honeywell,hmc5843
+ - honeywell,hmc5883
+ - honeywell,hmc5883l
+ - honeywell,hmc5983
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@1e {
+ compatible = "honeywell,hmc5843";
+ reg = <0x1e>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt b/Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt
deleted file mode 100644
index bdd40bc..0000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* FREESCALE MAG3110 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "fsl,mag3110"
- - reg : the I2C address of the magnetometer
-
-Optional properties:
-
- - interrupts: the sole interrupt generated by the device
-
- Refer to interrupt-controller/interrupts.txt for generic interrupt client
- node bindings.
-
- - vdd-supply: phandle to the regulator that provides power to the sensor.
- - vddio-supply: phandle to the regulator that provides power to the sensor's IO.
-
-Example:
-
-magnetometer@e {
- compatible = "fsl,mag3110";
- reg = <0x0e>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c3_mag3110_int>;
- interrupt-parent = <&gpio3>;
- interrupts = <16 IRQ_TYPE_EDGE_RISING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/mmc35240.txt b/Documentation/devicetree/bindings/iio/magnetometer/mmc35240.txt
deleted file mode 100644
index a01235c..0000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/mmc35240.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* MEMSIC MMC35240 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "memsic,mmc35240"
- - reg : the I2C address of the magnetometer
-
-Example:
-
-mmc35240@30 {
- compatible = "memsic,mmc35240";
- reg = <0x30>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
deleted file mode 100644
index 497c932..0000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* PNI RM3100 3-axis magnetometer sensor
-
-Required properties:
-
-- compatible : should be "pni,rm3100"
-- reg : the I2C address or SPI chip select number of the sensor.
-
-Optional properties:
-
-- interrupts: data ready (DRDY) from the chip.
- The interrupts can be triggered on level high.
-
-Example:
-
-rm3100: rm3100@20 {
- compatible = "pni,rm3100";
- reg = <0x20>;
- interrupt-parent = <&gpio0>;
- interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.yaml b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.yaml
new file mode 100644
index 0000000..a845cdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/pni,rm3100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PNI RM3100 3-axis magnetometer sensor
+
+maintainers:
+ - Song Qiang <songqiang1304521@gmail.com>
+
+properties:
+ compatible:
+ const: pni,rm3100
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@20 {
+ compatible = "pni,rm3100";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/ad5272.txt b/Documentation/devicetree/bindings/iio/potentiometer/ad5272.txt
deleted file mode 100644
index f9b2eef..0000000
--- a/Documentation/devicetree/bindings/iio/potentiometer/ad5272.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Analog Devices AD5272 digital potentiometer
-
-The node for this device must be a child node of a I2C controller, hence
-all mandatory properties for your controller must be specified. See directory:
-
- Documentation/devicetree/bindings/i2c
-
-for more details.
-
-Required properties:
- - compatible: Must be one of the following, depending on the model:
- adi,ad5272-020
- adi,ad5272-050
- adi,ad5272-100
- adi,ad5274-020
- adi,ad5274-100
-
-Optional properties:
- - reset-gpios: GPIO specification for the RESET input. This is an
- active low signal to the AD5272.
-
-Example:
-ad5272: potentiometer@2f {
- reg = <0x2F>;
- compatible = "adi,ad5272-020";
- reset-gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml b/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
new file mode 100644
index 0000000..1aee9f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiometer/adi,ad5272.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5272 digital potentiometer
+
+maintainers:
+ - Phil Reid <preid@electromag.com.au>
+
+description: |
+ Datasheet: https://www.analog.com/en/products/ad5272.html
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5272-020
+ - adi,ad5272-050
+ - adi,ad5272-100
+ - adi,ad5274-020
+ - adi,ad5274-100
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Active low signal to the AD5272 RESET input.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ potentiometer@2f {
+ compatible = "adi,ad5272-020";
+ reg = <0x2F>;
+ reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
deleted file mode 100644
index df77bf5..0000000
--- a/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Maxim Integrated DS1803 digital potentiometer driver
-
-The node for this driver must be a child node of a I2C controller, hence
-all mandatory properties for your controller must be specified. See directory:
-
- Documentation/devicetree/bindings/i2c
-
-for more details.
-
-Required properties:
- - compatible: Must be one of the following, depending on the
- model:
- "maxim,ds1803-010",
- "maxim,ds1803-050",
- "maxim,ds1803-100"
-
-Example:
-ds1803: ds1803@1 {
- reg = <0x28>;
- compatible = "maxim,ds1803-010";
-};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/max5481.txt b/Documentation/devicetree/bindings/iio/potentiometer/max5481.txt
deleted file mode 100644
index 6a91b10..0000000
--- a/Documentation/devicetree/bindings/iio/potentiometer/max5481.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Maxim Linear-Taper Digital Potentiometer MAX5481-MAX5484
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in
-
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-must be specified.
-
-Required properties:
- - compatible: Must be one of the following, depending on the
- model:
- "maxim,max5481"
- "maxim,max5482"
- "maxim,max5483"
- "maxim,max5484"
-
-Example:
-max548x: max548x@0 {
- compatible = "maxim,max5482";
- spi-max-frequency = <7000000>;
- reg = <0>; /* chip-select */
-};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt b/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt
deleted file mode 100644
index 4f245e8..0000000
--- a/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Microchip MCP41010/41050/41100/42010/42050/42100 Digital Potentiometer
-
-Datasheet publicly available at:
-https://ww1.microchip.com/downloads/en/devicedoc/11195c.pdf
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in
-
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-must be specified.
-
-Required properties:
- - compatible: Must be one of the following, depending on the
- model:
- "microchip,mcp41010"
- "microchip,mcp41050"
- "microchip,mcp41100"
- "microchip,mcp42010"
- "microchip,mcp42050"
- "microchip,mcp42100"
-
-Example:
-potentiometer@0 {
- compatible = "microchip,mcp41010";
- reg = <0>;
- spi-max-frequency = <500000>;
-};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/mcp4131.txt b/Documentation/devicetree/bindings/iio/potentiometer/mcp4131.txt
deleted file mode 100644
index 3ccba16..0000000
--- a/Documentation/devicetree/bindings/iio/potentiometer/mcp4131.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-* Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital Potentiometer
- driver
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in
-
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-must be specified.
-
-Required properties:
- - compatible: Must be one of the following, depending on the
- model:
- "microchip,mcp4131-502"
- "microchip,mcp4131-103"
- "microchip,mcp4131-503"
- "microchip,mcp4131-104"
- "microchip,mcp4132-502"
- "microchip,mcp4132-103"
- "microchip,mcp4132-503"
- "microchip,mcp4132-104"
- "microchip,mcp4141-502"
- "microchip,mcp4141-103"
- "microchip,mcp4141-503"
- "microchip,mcp4141-104"
- "microchip,mcp4142-502"
- "microchip,mcp4142-103"
- "microchip,mcp4142-503"
- "microchip,mcp4142-104"
- "microchip,mcp4151-502"
- "microchip,mcp4151-103"
- "microchip,mcp4151-503"
- "microchip,mcp4151-104"
- "microchip,mcp4152-502"
- "microchip,mcp4152-103"
- "microchip,mcp4152-503"
- "microchip,mcp4152-104"
- "microchip,mcp4161-502"
- "microchip,mcp4161-103"
- "microchip,mcp4161-503"
- "microchip,mcp4161-104"
- "microchip,mcp4162-502"
- "microchip,mcp4162-103"
- "microchip,mcp4162-503"
- "microchip,mcp4162-104"
- "microchip,mcp4231-502"
- "microchip,mcp4231-103"
- "microchip,mcp4231-503"
- "microchip,mcp4231-104"
- "microchip,mcp4232-502"
- "microchip,mcp4232-103"
- "microchip,mcp4232-503"
- "microchip,mcp4232-104"
- "microchip,mcp4241-502"
- "microchip,mcp4241-103"
- "microchip,mcp4241-503"
- "microchip,mcp4241-104"
- "microchip,mcp4242-502"
- "microchip,mcp4242-103"
- "microchip,mcp4242-503"
- "microchip,mcp4242-104"
- "microchip,mcp4251-502"
- "microchip,mcp4251-103"
- "microchip,mcp4251-503"
- "microchip,mcp4251-104"
- "microchip,mcp4252-502"
- "microchip,mcp4252-103"
- "microchip,mcp4252-503"
- "microchip,mcp4252-104"
- "microchip,mcp4261-502"
- "microchip,mcp4261-103"
- "microchip,mcp4261-503"
- "microchip,mcp4261-104"
- "microchip,mcp4262-502"
- "microchip,mcp4262-103"
- "microchip,mcp4262-503"
- "microchip,mcp4262-104"
-
-Example:
-mcp4131: mcp4131@0 {
- compatible = "mcp4131-502";
- reg = <0>;
- spi-max-frequency = <500000>;
-};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml
new file mode 100644
index 0000000..567697d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiometer/microchip,mcp41010.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP41010/41050/41100/42010/42050/42100 Digital Potentiometer
+
+maintainers:
+ - Chris Coffey <cmc@babblebit.net>
+
+description: |
+ Datasheet: https://ww1.microchip.com/downloads/en/devicedoc/11195c.pdf
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp41010
+ - microchip,mcp41050
+ - microchip,mcp41100
+ - microchip,mcp42010
+ - microchip,mcp42050
+ - microchip,mcp42100
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ potentiometer@0 {
+ compatible = "microchip,mcp41010";
+ reg = <0>;
+ spi-max-frequency = <500000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml
new file mode 100644
index 0000000..945a2d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiometer/microchip,mcp4131.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital Potentiometer
+
+maintainers:
+ - Slawomir Stepien <sst@poczta.fm>
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp4131-103
+ - microchip,mcp4131-104
+ - microchip,mcp4131-502
+ - microchip,mcp4131-503
+ - microchip,mcp4132-103
+ - microchip,mcp4132-104
+ - microchip,mcp4132-502
+ - microchip,mcp4132-503
+ - microchip,mcp4141-103
+ - microchip,mcp4141-104
+ - microchip,mcp4141-502
+ - microchip,mcp4141-503
+ - microchip,mcp4142-103
+ - microchip,mcp4142-104
+ - microchip,mcp4142-502
+ - microchip,mcp4142-503
+ - microchip,mcp4151-103
+ - microchip,mcp4151-104
+ - microchip,mcp4151-502
+ - microchip,mcp4151-503
+ - microchip,mcp4152-103
+ - microchip,mcp4152-104
+ - microchip,mcp4152-502
+ - microchip,mcp4152-503
+ - microchip,mcp4161-103
+ - microchip,mcp4161-104
+ - microchip,mcp4161-502
+ - microchip,mcp4161-503
+ - microchip,mcp4162-103
+ - microchip,mcp4162-104
+ - microchip,mcp4162-502
+ - microchip,mcp4162-503
+ - microchip,mcp4231-103
+ - microchip,mcp4231-104
+ - microchip,mcp4231-502
+ - microchip,mcp4231-503
+ - microchip,mcp4232-103
+ - microchip,mcp4232-104
+ - microchip,mcp4232-502
+ - microchip,mcp4232-503
+ - microchip,mcp4241-103
+ - microchip,mcp4241-104
+ - microchip,mcp4241-502
+ - microchip,mcp4241-503
+ - microchip,mcp4242-103
+ - microchip,mcp4242-104
+ - microchip,mcp4242-502
+ - microchip,mcp4242-503
+ - microchip,mcp4251-103
+ - microchip,mcp4251-104
+ - microchip,mcp4251-502
+ - microchip,mcp4251-503
+ - microchip,mcp4252-103
+ - microchip,mcp4252-104
+ - microchip,mcp4252-502
+ - microchip,mcp4252-503
+ - microchip,mcp4261-103
+ - microchip,mcp4261-104
+ - microchip,mcp4261-502
+ - microchip,mcp4261-503
+ - microchip,mcp4262-103
+ - microchip,mcp4262-104
+ - microchip,mcp4262-502
+ - microchip,mcp4262-503
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ potentiometer@0 {
+ compatible = "mcp4131-502";
+ reg = <0>;
+ spi-max-frequency = <500000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4531.yaml b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4531.yaml
new file mode 100644
index 0000000..5c4b9b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4531.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiometer/microchip,mcp4531.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip mcp4531 and similar potentiometers.
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ Family of I2C digital potentiometer
+ Datasheets at:
+ * volatile https://ww1.microchip.com/downloads/en/DeviceDoc/22096b.pdf
+ * non-volatile https://ww1.microchip.com/downloads/en/DeviceDoc/22107B.pdf
+ Part numbers as follows: mcp4ABC-XXX where
+ A = 5 (1 wiper), 6 (2 wipers)
+ B = 3 (7-bit, volatile), 4 (7-bit, non-volatile),
+ 5 (8-bit, volatile), 6 (8-bit, non-volatile),
+ C: 1 (potentiometer), 2 (rheostat)
+ XXX = 502 (5 kOhms), 103 (10 kOhms), 503 (50 kOhms), 104 (100 kOhms)
+
+properties:
+ compatible:
+ enum:
+ # Ordering reflects part number + range, so 502 < 103 etc
+ - microchip,mcp4531-502
+ - microchip,mcp4531-103
+ - microchip,mcp4531-503
+ - microchip,mcp4531-104
+ - microchip,mcp4532-502
+ - microchip,mcp4532-103
+ - microchip,mcp4532-503
+ - microchip,mcp4532-104
+ - microchip,mcp4541-502
+ - microchip,mcp4541-103
+ - microchip,mcp4541-503
+ - microchip,mcp4541-104
+ - microchip,mcp4542-502
+ - microchip,mcp4542-103
+ - microchip,mcp4542-503
+ - microchip,mcp4542-104
+ - microchip,mcp4551-502
+ - microchip,mcp4551-103
+ - microchip,mcp4551-503
+ - microchip,mcp4551-104
+ - microchip,mcp4552-502
+ - microchip,mcp4552-103
+ - microchip,mcp4552-503
+ - microchip,mcp4552-104
+ - microchip,mcp4561-502
+ - microchip,mcp4561-103
+ - microchip,mcp4561-503
+ - microchip,mcp4561-104
+ - microchip,mcp4562-502
+ - microchip,mcp4562-103
+ - microchip,mcp4562-503
+ - microchip,mcp4562-104
+ - microchip,mcp4631-502
+ - microchip,mcp4631-103
+ - microchip,mcp4631-503
+ - microchip,mcp4631-104
+ - microchip,mcp4632-502
+ - microchip,mcp4632-103
+ - microchip,mcp4632-503
+ - microchip,mcp4632-104
+ - microchip,mcp4641-502
+ - microchip,mcp4641-103
+ - microchip,mcp4641-503
+ - microchip,mcp4641-104
+ - microchip,mcp4642-502
+ - microchip,mcp4642-103
+ - microchip,mcp4642-503
+ - microchip,mcp4642-104
+ - microchip,mcp4651-502
+ - microchip,mcp4651-103
+ - microchip,mcp4651-503
+ - microchip,mcp4651-104
+ - microchip,mcp4652-502
+ - microchip,mcp4652-103
+ - microchip,mcp4652-503
+ - microchip,mcp4652-104
+ - microchip,mcp4661-502
+ - microchip,mcp4661-103
+ - microchip,mcp4661-503
+ - microchip,mcp4661-104
+ - microchip,mcp4662-502
+ - microchip,mcp4662-103
+ - microchip,mcp4662-503
+ - microchip,mcp4662-104
+
+ reg:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dpot: dpot@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt b/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt
deleted file mode 100644
index f3ab02b..0000000
--- a/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Texas Instruments LMP91000 series of potentiostats
-
-LMP91000: https://www.ti.com/lit/ds/symlink/lmp91000.pdf
-LMP91002: https://www.ti.com/lit/ds/symlink/lmp91002.pdf
-
-Required properties:
-
- - compatible: should be one of the following:
- "ti,lmp91000"
- "ti,lmp91002"
- - reg: the I2C address of the device
- - io-channels: the phandle of the iio provider
-
- - ti,external-tia-resistor: if the property ti,tia-gain-ohm is not defined this
- needs to be set to signal that an external resistor value is being used.
-
-Optional properties:
-
- - ti,tia-gain-ohm: ohm value of the internal resistor for the transimpedance
- amplifier. Must be 2750, 3500, 7000, 14000, 35000, 120000, or 350000 ohms.
-
- - ti,rload-ohm: ohm value of the internal resistor load applied to the gas
- sensor. Must be 10, 33, 50, or 100 (default) ohms.
-
-Example:
-
-lmp91000@48 {
- compatible = "ti,lmp91000";
- reg = <0x48>;
- ti,tia-gain-ohm = <7500>;
- ti,rload = <100>;
- io-channels = <&adc>;
-};
diff --git a/Documentation/devicetree/bindings/iio/potentiostat/ti,lmp91000.yaml b/Documentation/devicetree/bindings/iio/potentiostat/ti,lmp91000.yaml
new file mode 100644
index 0000000..e4b5d89
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiostat/ti,lmp91000.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiostat/ti,lmp91000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LMP91000 series of potentiostats with I2C control
+
+maintainers:
+ - Matt Ranostay <matt.ranostay@konsulko.com>
+
+description: |
+ Typically used as a signal conditioner for chemical sensors.
+ LMP91000: https://www.ti.com/lit/ds/symlink/lmp91000.pdf
+ LMP91002: https://www.ti.com/lit/ds/symlink/lmp91002.pdf
+
+properties:
+ compatible:
+ enum:
+ - ti,lmp91000
+ - ti,lmp91002
+
+ reg:
+ maxItems: 1
+
+ io-channels:
+ maxItems: 1
+
+ ti,external-tia-resistor:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If the property ti,tia-gain-ohm is not defined this needs to be set to
+ signal that an external resistor value is being used.
+
+ ti,tia-gain-ohm:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [2750, 3500, 7000, 14000, 35000, 120000, 350000]
+ description:
+ Internal resistor for the transimpedance amplifier.
+
+ ti,rload-ohm:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [10, 33, 50, 100]
+ description:
+ Internal resistor load applied to the gas sensor.
+ Default 100 Ohms.
+
+required:
+ - compatible
+ - reg
+ - io-channels
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ lmp91000@48 {
+ compatible = "ti,lmp91000";
+ reg = <0x48>;
+ ti,tia-gain-ohm = <7000>;
+ ti,rload-ohm = <100>;
+ io-channels = <&adc>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/hoperf,hp03.yaml b/Documentation/devicetree/bindings/iio/pressure/hoperf,hp03.yaml
new file mode 100644
index 0000000..69a3759
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/hoperf,hp03.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/hoperf,hp03.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HopeRF HP03 digital pressure/temperature sensors
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+description: |
+ Digital pressure and temperature sensor with an I2C interface.
+
+properties:
+ compatible:
+ const: hoperf,hp03
+
+ reg:
+ maxItems: 1
+
+ xclr-gpios:
+ description:
+ The XCLR pin is a reset of the ADC in the chip, it must be pulled
+ HI before the conversion and readout of the value from the ADC
+ registers and pulled LO afterward.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@77 {
+ compatible = "hoperf,hp03";
+ reg = <0x77>;
+ xclr-gpios = <&portc 0 0x0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/hp03.txt b/Documentation/devicetree/bindings/iio/pressure/hp03.txt
deleted file mode 100644
index 831dbee..0000000
--- a/Documentation/devicetree/bindings/iio/pressure/hp03.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-HopeRF HP03 digital pressure/temperature sensors
-
-Required properties:
-- compatible: must be "hoperf,hp03"
-- xclr-gpio: must be device tree identifier of the XCLR pin.
- The XCLR pin is a reset of the ADC in the chip,
- it must be pulled HI before the conversion and
- readout of the value from the ADC registers and
- pulled LO afterward.
-
-Example:
-
-hp03@77 {
- compatible = "hoperf,hp03";
- reg = <0x77>;
- xclr-gpio = <&portc 0 0x0>;
-};
diff --git a/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml b/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml
new file mode 100644
index 0000000..4f06707
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/meas,ms5611.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Measurement Specialities ms5611 and similar pressure sensors
+
+maintainers:
+ - Tomasz Duszynski <tduszyns@gmail.com>
+
+description: |
+ Pressure sensors from MEAS Switzerland with SPI and I2C bus interfaces.
+
+properties:
+ compatible:
+ enum:
+ - meas,ms5607
+ - meas,ms5611
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ spi-max-frequency:
+ maximum: 20000000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@77 {
+ compatible = "meas,ms5607";
+ reg = <0x77>;
+ vdd-supply = <&ldo_3v3_gnss>;
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@0 {
+ compatible = "meas,ms5611";
+ reg = <0>;
+ vdd-supply = <&ldo_3v3_gnss>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/ms5611.txt b/Documentation/devicetree/bindings/iio/pressure/ms5611.txt
deleted file mode 100644
index 17bca86..0000000
--- a/Documentation/devicetree/bindings/iio/pressure/ms5611.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-MEAS ms5611 family pressure sensors
-
-Pressure sensors from MEAS Switzerland with SPI and I2C bus interfaces.
-
-Required properties:
-- compatible: "meas,ms5611" or "meas,ms5607"
-- reg: the I2C address or SPI chip select the device will respond to
-
-Optional properties:
-- vdd-supply: an optional regulator that needs to be on to provide VDD
- power to the sensor.
-
-Example:
-
-ms5607@77 {
- compatible = "meas,ms5607";
- reg = <0x77>;
- vdd-supply = <&ldo_3v3_gnss>;
-};
diff --git a/Documentation/devicetree/bindings/iio/pressure/ms5637.txt b/Documentation/devicetree/bindings/iio/pressure/ms5637.txt
deleted file mode 100644
index 1f43ffa..0000000
--- a/Documentation/devicetree/bindings/iio/pressure/ms5637.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* MS5637 - Measurement-Specialties MS5637, MS5805, MS5837 and MS8607 pressure & temperature sensor
-
-Required properties:
-
- -compatible: should be one of the following
- meas,ms5637
- meas,ms5805
- meas,ms5837
- meas,ms8607-temppressure
- -reg: I2C address of the sensor
-
-Example:
-
-ms5637@76 {
- compatible = "meas,ms5637";
- reg = <0x76>;
-};
diff --git a/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml b/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml
new file mode 100644
index 0000000..d6103be
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/murata,zpa2326.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Murata ZPA2326 pressure sensor
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Pressure sensor from Murata with SPI and I2C bus interfaces.
+
+
+properties:
+ compatible:
+ const: murata,zpa2326
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vref-supply: true
+
+ interrupts:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 1000000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@5c {
+ compatible = "murata,zpa2326";
+ reg = <0x5c>;
+ interrupt-parent = <&gpio>;
+ interrupts = <12>;
+ vdd-supply = <&ldo_1v8_gnss>;
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@0 {
+ compatible = "murata,zpa2326";
+ reg = <0>;
+ spi-max-frequency = <500000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/zpa2326.txt b/Documentation/devicetree/bindings/iio/pressure/zpa2326.txt
deleted file mode 100644
index a36ab3e..0000000
--- a/Documentation/devicetree/bindings/iio/pressure/zpa2326.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Murata ZPA2326 pressure sensor
-
-Pressure sensor from Murata with SPI and I2C bus interfaces.
-
-Required properties:
-- compatible: "murata,zpa2326"
-- reg: the I2C address or SPI chip select the device will respond to
-
-Recommended properties for SPI bus usage:
-- spi-max-frequency: maximum SPI bus frequency as documented in
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
-- vref-supply: an optional regulator that needs to be on to provide VREF
- power to the sensor
-- vdd-supply: an optional regulator that needs to be on to provide VDD
- power to the sensor
-- interrupts: interrupt mapping for IRQ as documented in
- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
-Example:
-
-zpa2326@5c {
- compatible = "murata,zpa2326";
- reg = <0x5c>;
- interrupt-parent = <&gpio>;
- interrupts = <12>;
- vdd-supply = <&ldo_1v8_gnss>;
-};
diff --git a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
new file mode 100644
index 0000000..7fcba5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/ams,as3935.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Austrian Microsystems AS3935 Franklin lightning sensor
+
+maintainers:
+ - Matt Ranostay <matt.ranostay@konsulko.com>
+
+description:
+ This lightening distance sensor uses an I2C or SPI interface. The
+ binding currently only covers the SPI option.
+
+properties:
+ compatible:
+ const: ams,as3935
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 2000000
+
+ spi-cpha: true
+
+ interrupts:
+ maxItems: 1
+
+ ams,tuning-capacitor-pf:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Calibration tuning capacitor stepping value. This will require using
+ the calibration data from the manufacturer.
+ minimum: 0
+ maximum: 120
+
+ ams,nflwdth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Set the noise and watchdog threshold register on startup. This will
+ need to set according to the noise from the MCU board, and possibly
+ the local environment. Refer to the datasheet for the threshold settings.
+
+required:
+ - compatible
+ - reg
+ - spi-cpha
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lightning@0 {
+ compatible = "ams,as3935";
+ reg = <0>;
+ spi-max-frequency = <400000>;
+ spi-cpha;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 1>;
+ ams,tuning-capacitor-pf = <80>;
+ ams,nflwdth = <0x44>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
deleted file mode 100644
index 8491155..0000000
--- a/Documentation/devicetree/bindings/iio/proximity/as3935.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Austrian Microsystems AS3935 Franklin lightning sensor device driver
-
-Required properties:
- - compatible: must be "ams,as3935"
- - reg: SPI chip select number for the device
- - spi-max-frequency: specifies maximum SPI clock frequency
- - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
- slave node bindings.
- - interrupts : the sole interrupt generated by the device
-
- Refer to interrupt-controller/interrupts.txt for generic
- interrupt client node bindings.
-
-Optional properties:
- - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping
- value 0 - 120pF. This will require using the calibration data from
- the manufacturer.
- - ams,nflwdth: Set the noise and watchdog threshold register on
- startup. This will need to set according to the noise from the
- MCU board, and possibly the local environment. Refer to the
- datasheet for the threshold settings.
-
-Example:
-
-as3935@0 {
- compatible = "ams,as3935";
- reg = <0>;
- spi-max-frequency = <400000>;
- spi-cpha;
- interrupt-parent = <&gpio1>;
- interrupts = <16 1>;
- ams,tuning-capacitor-pf = <80>;
- ams,nflwdth = <0x44>;
-};
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
index 5739074..5de0bb2 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
@@ -40,6 +40,63 @@
"#io-channel-cells":
const: 1
+ semtech,cs0-ground:
+ description: Indicates the CS0 sensor is connected to ground.
+ type: boolean
+
+ semtech,combined-sensors:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ List of which sensors are combined and represented by CS3.
+ Possible values are -
+ 3 - CS3 (internal)
+ 0 1 - CS0 + CS1
+ 1 2 - CS1 + CS2 (default)
+ 0 1 2 3 - CS0 + CS1 + CS2 + CS3
+ items:
+ enum: [ 0, 1, 2, 3 ]
+ minItems: 1
+ maxItems: 4
+
+ semtech,resolution:
+ description:
+ Capacitance measure resolution. Refer to datasheet for more details.
+ enum:
+ - coarsest
+ - very-coarse
+ - coarse
+ - medium-coarse
+ - medium
+ - fine
+ - very-fine
+ - finest
+
+ semtech,startup-sensor:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ default: 0
+ description:
+ Sensor used for start-up proximity detection. The combined
+ sensor is represented by the value 3. This is used for initial
+ compensation.
+
+ semtech,proxraw-strength:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 2, 4, 8]
+ default: 2
+ description:
+ PROXRAW filter strength. A value of 0 represents off, and other values
+ represent 1-1/N.
+
+ semtech,avg-pos-strength:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295]
+ default: 16
+ description:
+ Average positive filter strength. A value of 0 represents off and
+ UINT_MAX (4294967295) represents infinite. Other values
+ represent 1-1/N.
+
required:
- compatible
- reg
@@ -61,5 +118,11 @@
vdd-supply = <&pp3300_a>;
svdd-supply = <&pp1800_prox>;
#io-channel-cells = <1>;
+ semtech,cs0-ground;
+ semtech,combined-sensors = <1 2 3>;
+ semtech,resolution = "fine";
+ semtech,startup-sensor = <1>;
+ semtech,proxraw-strength = <2>;
+ semtech,avg-pos-strength = <64>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9500.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9500.yaml
new file mode 100644
index 0000000..66dd015
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9500.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/semtech,sx9500.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech's SX9500 capacitive proximity button device
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+properties:
+ compatible:
+ const: semtech,sx9500
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ GPIO connected to the active low reset pin.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ proximity@28 {
+ compatible = "semtech,sx9500";
+ reg = <0x28>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml b/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
new file mode 100644
index 0000000..656460d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/st,vl53l0x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST VL53L0X ToF ranging sensor
+
+maintainers:
+ - Song Qiang <songqiang1304521@gmail.com>
+
+properties:
+ compatible:
+ const: st,vl53l0x
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ proximity@29 {
+ compatible = "st,vl53l0x";
+ reg = <0x29>;
+ interrupt-parent = <&gpio>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/sx9500.txt b/Documentation/devicetree/bindings/iio/proximity/sx9500.txt
deleted file mode 100644
index c54455d..0000000
--- a/Documentation/devicetree/bindings/iio/proximity/sx9500.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Semtech's SX9500 capacitive proximity button device driver
-
-Required properties:
- - compatible: must be "semtech,sx9500"
- - reg: i2c address where to find the device
- - interrupts : the sole interrupt generated by the device
-
- Refer to interrupt-controller/interrupts.txt for generic
- interrupt client node bindings.
-
-Optional properties:
- - reset-gpios: Reference to the GPIO connected to the device's active
- low reset pin.
-
-Example:
-
-sx9500@28 {
- compatible = "semtech,sx9500";
- reg = <0x28>;
- interrupt-parent = <&gpio2>;
- interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
- reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
deleted file mode 100644
index dfe00eb..0000000
--- a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-ST VL53L0X ToF ranging sensor
-
-Required properties:
- - compatible: must be "st,vl53l0x"
- - reg: i2c address where to find the device
-
-Optional properties:
- - interrupts: Interrupt for notifying that new measurement is ready.
- If no interrupt is specified, polling is used.
-
-Example:
-
-vl53l0x@29 {
- compatible = "st,vl53l0x";
- reg = <0x29>;
- interrupt-parent = <&gpio>;
- interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git a/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt b/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
deleted file mode 100644
index 477d41f..0000000
--- a/Documentation/devicetree/bindings/iio/resolver/ad2s90.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Analog Devices AD2S90 Resolver-to-Digital Converter
-
-https://www.analog.com/en/products/ad2s90.html
-
-Required properties:
- - compatible: should be "adi,ad2s90"
- - reg: SPI chip select number for the device
- - spi-max-frequency: set maximum clock frequency, must be 830000
- - spi-cpol and spi-cpha:
- Either SPI mode (0,0) or (1,1) must be used, so specify none or both of
- spi-cpha, spi-cpol.
-
-See for more details:
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Note about max frequency:
- Chip's max frequency, as specified in its datasheet, is 2Mhz. But a 600ns
- delay is expected between the application of a logic LO to CS and the
- application of SCLK, as also specified. And since the delay is not
- implemented in the spi code, to satisfy it, SCLK's period should be at most
- 2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which gives
- roughly 830000Hz.
-
-Example:
-resolver@0 {
- compatible = "adi,ad2s90";
- reg = <0>;
- spi-max-frequency = <830000>;
- spi-cpol;
- spi-cpha;
-};
diff --git a/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml b/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml
new file mode 100644
index 0000000..81e4bdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/resolver/adi,ad2s90.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD2S90 Resolver-to-Digital Converter
+
+maintainers:
+ - Matheus Tavares <matheus.bernardino@usp.br>
+
+description: |
+ Datasheet: https://www.analog.com/en/products/ad2s90.html
+
+properties:
+ compatible:
+ const: adi,ad2s90
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 830000
+ description: |
+ Chip's max frequency, as specified in its datasheet, is 2Mhz. But a 600ns
+ delay is expected between the application of a logic LO to CS and the
+ application of SCLK, as also specified. And since the delay is not
+ implemented in the spi code, to satisfy it, SCLK's period should be at
+ most 2 * 600ns, so the max frequency should be 1 / (2 * 6e-7), which gives
+ roughly 830000Hz.
+
+ spi-cpol: true
+
+ spi-cpha: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+dependencies:
+ spi-cpol: [ spi-cpha ]
+ spi-cpha: [ spi-cpol ]
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ resolver@0 {
+ compatible = "adi,ad2s90";
+ reg = <0>;
+ spi-max-frequency = <830000>;
+ spi-cpol;
+ spi-cpha;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml b/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml
new file mode 100644
index 0000000..a88b3b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/samsung,sensorhub-rinato.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Sensorhub driver
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Sensorhub is a MCU which manages several sensors and also plays the role
+ of a virtual sensor device.
+
+properties:
+ compatible:
+ enum:
+ - samsung,sensorhub-rinato
+ - samsung,sensorhub-thermostat
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ap-mcu-gpios:
+ maxItems: 1
+ description:
+ Application Processor to sensorhub line - used during communication
+
+ mcu-ap-gpios:
+ maxItems: 1
+ description:
+ Sensorhub to Application Processor - used during communication
+
+ mcu-reset-gpios:
+ maxItems: 1
+ description:
+ Reset the sensorhub.
+
+ spi-max-frequency: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ap-mcu-gpios
+ - mcu-ap-gpios
+ - mcu-reset-gpios
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensorhub@0 {
+ compatible = "samsung,sensorhub-rinato";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ interrupt-parent = <&gpx0>;
+ interrupts = <2 0>;
+ ap-mcu-gpios = <&gpx0 0 0>;
+ mcu-ap-gpios = <&gpx0 4 0>;
+ mcu-reset-gpios = <&gpx0 5 0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/sensorhub.txt b/Documentation/devicetree/bindings/iio/sensorhub.txt
deleted file mode 100644
index b6ac045..0000000
--- a/Documentation/devicetree/bindings/iio/sensorhub.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Samsung Sensorhub driver
-
-Sensorhub is a MCU which manages several sensors and also plays the role
-of a virtual sensor device.
-
-Required properties:
-- compatible: "samsung,sensorhub-rinato" or "samsung,sensorhub-thermostat"
-- spi-max-frequency: max SPI clock frequency
-- interrupts: communication interrupt
-- ap-mcu-gpios: [out] ap to sensorhub line - used during communication
-- mcu-ap-gpios: [in] sensorhub to ap - used during communication
-- mcu-reset-gpios: [out] sensorhub reset
-
-Example:
-
- shub_spi: shub {
- compatible = "samsung,sensorhub-rinato";
- spi-max-frequency = <5000000>;
- interrupt-parent = <&gpx0>;
- interrupts = <2 0>;
- ap-mcu-gpios = <&gpx0 0 0>;
- mcu-ap-gpios = <&gpx0 4 0>;
- mcu-reset-gpios = <&gpx0 5 0>;
- };
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
new file mode 100644
index 0000000..db291a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/st,st-sensors.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics MEMS sensors
+
+description: |
+ Note that whilst this covers many STMicro MEMs sensors, some more complex
+ IMUs need their own bindings.
+ The STMicroelectronics sensor devices are pretty straight-forward I2C or
+ SPI devices, all sharing the same device tree descriptions no matter what
+ type of sensor it is.
+
+maintainers:
+ - Denis Ciocca <denis.ciocca@st.com>
+
+properties:
+ compatible:
+ description: |
+ Some values are deprecated.
+ st,lis3lv02d (deprecated, use st,lis3lv02dl-accel)
+ st,lis302dl-spi (deprecated, use st,lis3lv02dl-accel)
+ enum:
+ # Accelerometers
+ - st,lis3lv02d
+ - st,lis302dl-spi
+ - st,lis3lv02dl-accel
+ - st,lsm303dlh-accel
+ - st,lsm303dlhc-accel
+ - st,lis3dh-accel
+ - st,lsm330d-accel
+ - st,lsm330dl-accel
+ - st,lsm330dlc-accel
+ - st,lis331dl-accel
+ - st,lis331dlh-accel
+ - st,lsm303dl-accel
+ - st,lsm303dlm-accel
+ - st,lsm330-accel
+ - st,lsm303agr-accel
+ - st,lis2dh12-accel
+ - st,h3lis331dl-accel
+ - st,lng2dm-accel
+ - st,lis3l02dq
+ - st,lis2dw12
+ - st,lis3dhh
+ - st,lis3de
+ - st,lis2de12
+ - st,lis2hh12
+ # Gyroscopes
+ - st,l3g4200d-gyro
+ - st,lsm330d-gyro
+ - st,lsm330dl-gyro
+ - st,lsm330dlc-gyro
+ - st,l3gd20-gyro
+ - st,l3gd20h-gyro
+ - st,l3g4is-gyro
+ - st,lsm330-gyro
+ - st,lsm9ds0-gyro
+ # Magnetometers
+ - st,lsm303agr-magn
+ - st,lsm303dlh-magn
+ - st,lsm303dlhc-magn
+ - st,lsm303dlm-magn
+ - st,lis3mdl-magn
+ - st,lis2mdl
+ - st,lsm9ds1-magn
+ # Pressure sensors
+ - st,lps001wp-press
+ - st,lps25h-press
+ - st,lps331ap-press
+ - st,lps22hb-press
+ - st,lps33hw
+ - st,lps35hw
+ - st,lps22hh
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+ st,drdy-int-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Some sensors have multiple possible pins via which they can provide
+ a data ready interrupt. This selects which one.
+ enum:
+ - 1
+ - 2
+
+ drive-open-drain:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ The interrupt/data ready line will be configured as open drain, which
+ is useful if several sensors share the same interrupt line.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ accelerometer@1d {
+ compatible = "st,lis3lv02dl-accel";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <18 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&lis3lv02dl_nhk_mode>;
+ pinctrl-names = "default";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt
deleted file mode 100644
index 3213599..0000000
--- a/Documentation/devicetree/bindings/iio/st-sensors.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-STMicroelectronics MEMS sensors
-
-The STMicroelectronics sensor devices are pretty straight-forward I2C or
-SPI devices, all sharing the same device tree descriptions no matter what
-type of sensor it is.
-
-Required properties:
-- compatible: see the list of valid compatible strings below
-- reg: the I2C or SPI address the device will respond to
-
-Optional properties:
-- vdd-supply: an optional regulator that needs to be on to provide VDD
- power to the sensor.
-- vddio-supply: an optional regulator that needs to be on to provide the
- VDD IO power to the sensor.
-- st,drdy-int-pin: the pin on the package that will be used to signal
- "data ready" (valid values: 1 or 2). This property is not configurable
- on all sensors.
-- drive-open-drain: the interrupt/data ready line will be configured
- as open drain, which is useful if several sensors share the same
- interrupt line. (This binding is taken from pinctrl/pinctrl-bindings.txt)
- This is a boolean property.
-
-Sensors may also have applicable pin control settings, those use the
-standard bindings from pinctrl/pinctrl-bindings.txt.
-
-Valid compatible strings:
-
-Accelerometers:
-- st,lis3lv02d (deprecated, use st,lis3lv02dl-accel)
-- st,lis302dl-spi (deprecated, use st,lis3lv02dl-accel)
-- st,lis3lv02dl-accel
-- st,lsm303dlh-accel
-- st,lsm303dlhc-accel
-- st,lis3dh-accel
-- st,lsm330d-accel
-- st,lsm330dl-accel
-- st,lsm330dlc-accel
-- st,lis331dl-accel
-- st,lis331dlh-accel
-- st,lsm303dl-accel
-- st,lsm303dlm-accel
-- st,lsm330-accel
-- st,lsm303agr-accel
-- st,lis2dh12-accel
-- st,h3lis331dl-accel
-- st,lng2dm-accel
-- st,lis3l02dq
-- st,lis2dw12
-- st,lis3dhh
-- st,lis3de
-- st,lis2de12
-- st,lis2hh12
-
-Gyroscopes:
-- st,l3g4200d-gyro
-- st,lsm330d-gyro
-- st,lsm330dl-gyro
-- st,lsm330dlc-gyro
-- st,l3gd20-gyro
-- st,l3gd20h-gyro
-- st,l3g4is-gyro
-- st,lsm330-gyro
-- st,lsm9ds0-gyro
-
-Magnetometers:
-- st,lsm303agr-magn
-- st,lsm303dlh-magn
-- st,lsm303dlhc-magn
-- st,lsm303dlm-magn
-- st,lis3mdl-magn
-- st,lis2mdl
-- st,lsm9ds1-magn
-
-Pressure sensors:
-- st,lps001wp-press
-- st,lps25h-press
-- st,lps331ap-press
-- st,lps22hb-press
-- st,lps33hw
-- st,lps35hw
-- st,lps22hh
diff --git a/Documentation/devicetree/bindings/iio/temperature/max31856.txt b/Documentation/devicetree/bindings/iio/temperature/max31856.txt
deleted file mode 100644
index 06ab43b..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/max31856.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Maxim MAX31856 thermocouple support
-
-https://datasheets.maximintegrated.com/en/ds/MAX31856.pdf
-
-Optional property:
- - thermocouple-type: Type of thermocouple (THERMOCOUPLE_TYPE_K if
- omitted). Supported types are B, E, J, K, N, R, S, T.
-
-Required properties:
- - compatible: must be "maxim,max31856"
- - reg: SPI chip select number for the device
- - spi-max-frequency: As per datasheet max. supported freq is 5000000
- - spi-cpha: must be defined for max31856 to enable SPI mode 1
-
- Refer to spi/spi-bus.txt for generic SPI slave bindings.
-
- Example:
- temp-sensor@0 {
- compatible = "maxim,max31856";
- reg = <0>;
- spi-max-frequency = <5000000>;
- spi-cpha;
- thermocouple-type = <THERMOCOUPLE_TYPE_K>;
- };
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml
new file mode 100644
index 0000000..9969bac
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/maxim,max31855k.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX31855 and similar thermocouples
+
+maintainers:
+ - Matt Ranostay <matt.ranostay@konsulko.com>
+
+description: |
+ https://datasheets.maximintegrated.com/en/ds/MAX6675.pdf
+ https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf
+
+properties:
+ compatible:
+ description:
+ The generic maxim,max31855 compatible is deprecated in favour of
+ the thermocouple type specific variants.
+ enum:
+ - maxim,max6675
+ - maxim,max31855
+ - maxim,max31855k
+ - maxim,max31855j
+ - maxim,max31855n
+ - maxim,max31855s
+ - maxim,max31855t
+ - maxim,max31855e
+ - maxim,max31855r
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+ spi-cpha: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max6675
+ then:
+ required:
+ - spi-cpha
+ else:
+ properties:
+ spi-cpha: false
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temp-sensor@0 {
+ compatible = "maxim,max31855k";
+ reg = <0>;
+ spi-max-frequency = <4300000>;
+ };
+ temp-sensor@1 {
+ compatible = "maxim,max6675";
+ reg = <1>;
+ spi-max-frequency = <4300000>;
+ spi-cpha;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml
new file mode 100644
index 0000000..873b347
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/maxim,max31856.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX31856 thermocouple support
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ https://datasheets.maximintegrated.com/en/ds/MAX31856.pdf
+
+properties:
+ compatible:
+ const: maxim,max31856
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency: true
+ spi-cpha: true
+
+ thermocouple-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Type of thermocouple (THERMOCOUPLE_TYPE_K if omitted).
+ Use defines in dt-bindings/iio/temperature/thermocouple.h.
+ Supported types are B, E, J, K, N, R, S, T.
+
+required:
+ - compatible
+ - reg
+ - spi-cpha
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/iio/temperature/thermocouple.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temp-sensor@0 {
+ compatible = "maxim,max31856";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-cpha;
+ thermocouple-type = <THERMOCOUPLE_TYPE_K>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt b/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt
deleted file mode 100644
index bb85cd0..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/maxim_thermocouple.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Maxim thermocouple support
-
-* https://datasheets.maximintegrated.com/en/ds/MAX6675.pdf
-* https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf
-
-Required properties:
-
- - compatible: must be "maxim,max6675" or one of the following:
- "maxim,max31855k", "maxim,max31855j", "maxim,max31855n",
- "maxim,max31855s", "maxim,max31855t", "maxim,max31855e",
- "maxim,max31855r"; the generic "max,max31855" is deprecated.
- - reg: SPI chip select number for the device
- - spi-max-frequency: must be 4300000
- - spi-cpha: must be defined for max6675 to enable SPI mode 1
-
- Refer to spi/spi-bus.txt for generic SPI slave bindings.
-
-Example:
-
- max31855@0 {
- compatible = "maxim,max31855k";
- reg = <0>;
- spi-max-frequency = <4300000>;
- };
diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
new file mode 100644
index 0000000..d6965a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90614.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Melexis MLX90614 contactless IR temperature sensor
+
+maintainers:
+ - Peter Meerwald <pmeerw@pmeerw.net>
+ - Crt Mori <cmo@melexis.com>
+
+description: |
+ http://melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/MLX90614-615.aspx
+
+properties:
+ compatible:
+ const: melexis,mlx90614
+
+ reg:
+ maxItems: 1
+
+ wakeup-gpios:
+ description:
+ GPIO connected to the SDA line to hold low in order to wake up the
+ device. In normal operation, the GPIO is set as input and will
+ not interfere in I2C communication. There is no need for a GPIO
+ driving the SCL line. If no GPIO is given, power management is disabled.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temp-sensor@5a {
+ compatible = "melexis,mlx90614";
+ reg = <0x5a>;
+ wakeup-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml
new file mode 100644
index 0000000..b547ddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90632.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Melexis MLX90632 contactless Infra Red temperature sensor
+
+maintainers:
+ - Crt Mori <cmo@melexis.com>
+
+description: |
+ https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+ There are various applications for the Infra Red contactless temperature
+ sensor and MLX90632 is most suitable for consumer applications where
+ measured object temperature is in range between -20 to 200 degrees
+ Celsius with relative error of measurement below 1 degree Celsius in
+ object temperature range for industrial applications. Since it can
+ operate and measure ambient temperature in range of -20 to 85 degrees
+ Celsius it is suitable also for outdoor use.
+
+ Be aware that electronics surrounding the sensor can increase ambient
+ temperature. MLX90632 can be calibrated to reduce the housing effect via
+ already existing EEPROM parameters.
+
+ Since measured object emissivity effects Infra Red energy emitted,
+ emissivity should be set before requesting the object temperature.
+
+properties:
+ compatible:
+ const: melexis,mlx90632
+
+ reg:
+ maxItems: 1
+ description: Default is 0x3a, but can be reprogrammed.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temp-sensor@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90614.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90614.txt
deleted file mode 100644
index 9be57b03..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/mlx90614.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Melexis MLX90614 contactless IR temperature sensor
-
-http://melexis.com/Infrared-Thermometer-Sensors/Infrared-Thermometer-Sensors/MLX90614-615.aspx
-
-Required properties:
-
- - compatible: should be "melexis,mlx90614"
- - reg: the I2C address of the sensor
-
-Optional properties:
-
- - wakeup-gpios: device tree identifier of the GPIO connected to the SDA line
- to hold low in order to wake up the device. In normal operation, the
- GPIO is set as input and will not interfere in I2C communication. There
- is no need for a GPIO driving the SCL line. If no GPIO is given, power
- management is disabled.
-
-Example:
-
-mlx90614@5a {
- compatible = "melexis,mlx90614";
- reg = <0x5a>;
- wakeup-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
deleted file mode 100644
index 0b05812..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Melexis MLX90632 contactless Infra Red temperature sensor
-
-Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
-
-There are various applications for the Infra Red contactless temperature sensor
-and MLX90632 is most suitable for consumer applications where measured object
-temperature is in range between -20 to 200 degrees Celsius with relative error
-of measurement below 1 degree Celsius in object temperature range for
-industrial applications. Since it can operate and measure ambient temperature
-in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
-
-Be aware that electronics surrounding the sensor can increase ambient
-temperature. MLX90632 can be calibrated to reduce the housing effect via
-already existing EEPROM parameters.
-
-Since measured object emissivity effects Infra Red energy emitted, emissivity
-should be set before requesting the object temperature.
-
-Required properties:
- - compatible: should be "melexis,mlx90632"
- - reg: the I2C address of the sensor (default 0x3a)
-
-Example:
-
-mlx90632@3a {
- compatible = "melexis,mlx90632";
- reg = <0x3a>;
-};
diff --git a/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt b/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt
deleted file mode 100644
index 8f339cab..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/temperature-bindings.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-If the temperature sensor device can be configured to use some specific
-thermocouple type, you can use the defined types provided in the file
-"include/dt-bindings/iio/temperature/thermocouple.h".
-
-Property:
-thermocouple-type: A single cell representing the type of the thermocouple
- used by the device.
diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp007.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp007.yaml
new file mode 100644
index 0000000..3c2b718
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp007.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/ti,tmp007.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IR thermopile sensor with integrated math engine
+
+maintainers:
+ - Manivannan Sadhasivam <manivannanece23@gmail.com>
+
+description: |
+ http://www.ti.com/lit/ds/symlink/tmp007.pdf
+
+properties:
+ compatible:
+ const: ti,tmp007
+
+ reg:
+ description: |
+ The I2C address of the sensor (changeable via ADR pins)
+ ------------------------------
+ |ADR1 | ADR0 | Device Address|
+ ------------------------------
+ 0 0 0x40
+ 0 1 0x41
+ 0 SDA 0x42
+ 0 SCL 0x43
+ 1 0 0x44
+ 1 1 0x45
+ 1 SDA 0x46
+ 1 SCL 0x47
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temp-sensor@40 {
+ compatible = "ti,tmp007";
+ reg = <0x40>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <5 0x08>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/temperature/tmp007.txt b/Documentation/devicetree/bindings/iio/temperature/tmp007.txt
deleted file mode 100644
index da0af23..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/tmp007.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* TI TMP007 - IR thermopile sensor with integrated math engine
-
-Link to datasheet: http://www.ti.com/lit/ds/symlink/tmp007.pdf
-
-Required properties:
-
- - compatible: should be "ti,tmp007"
- - reg: the I2C address of the sensor (changeable via ADR pins)
- ------------------------------
- |ADR1 | ADR0 | Device Address|
- ------------------------------
- 0 0 0x40
- 0 1 0x41
- 0 SDA 0x42
- 0 SCL 0x43
- 1 0 0x44
- 1 1 0x45
- 1 SDA 0x46
- 1 SCL 0x47
-
-Optional properties:
-
- - interrupts: interrupt mapping for GPIO IRQ (level active low)
-
-Example:
-
-tmp007@40 {
- compatible = "ti,tmp007";
- reg = <0x40>;
- interrupt-parent = <&gpio0>;
- interrupts = <5 0x08>;
-};
-
diff --git a/Documentation/devicetree/bindings/iio/temperature/tsys01.txt b/Documentation/devicetree/bindings/iio/temperature/tsys01.txt
deleted file mode 100644
index 0d5cc55..0000000
--- a/Documentation/devicetree/bindings/iio/temperature/tsys01.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* TSYS01 - Measurement Specialties temperature sensor
-
-Required properties:
-
- - compatible: should be "meas,tsys01"
- - reg: I2C address of the sensor (changeable via CSB pin)
-
- ------------------------
- | CSB | Device Address |
- ------------------------
- 1 0x76
- 0 0x77
-
-Example:
-
-tsys01@76 {
- compatible = "meas,tsys01";
- reg = <0x76>;
-};
diff --git a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
new file mode 100644
index 0000000..b4ad829
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ariel-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dell Wyse 3020 a.k.a. "Ariel" Power Button
+
+maintainers:
+ - Lubomir Rintel <lkundrak@v3.sk>
+
+description: |
+ The ENE Embedded Controller on the Ariel board has an interface to the
+ SPI bus that is capable of sending keyboard and mouse data. A single
+ power button is attached to it. This binding describes this
+ configuration.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: dell,wyse-ariel-ec-input
+ - const: ene,kb3930-input
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-button@0 {
+ compatible = "dell,wyse-ariel-ec-input", "ene,kb3930-input";
+ reg = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <60 IRQ_TYPE_EDGE_RISING>;
+ spi-max-frequency = <33000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
deleted file mode 100644
index c889194..0000000
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Atmel maXTouch touchscreen/touchpad
-
-Required properties:
-- compatible:
- atmel,maxtouch
-
- The following compatibles have been used in various products but are
- deprecated:
- atmel,qt602240_ts
- atmel,atmel_mxt_ts
- atmel,atmel_mxt_tp
- atmel,mXT224
-
-- reg: The I2C address of the device
-
-- interrupts: The sink for the touchpad's IRQ output
- See ../interrupt-controller/interrupts.txt
-
-Optional properties for main touchpad device:
-
-- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
- on GPIO bit changes. An array of up to 8 entries can be provided
- indicating the Linux keycode mapped to each bit of the status byte,
- starting at the LSB. Linux keycodes are defined in
- <dt-bindings/input/input.h>.
-
- Note: the numbering of the GPIOs and the bit they start at varies between
- maXTouch devices. You must either refer to the documentation, or
- experiment to determine which bit corresponds to which input. Use
- KEY_RESERVED for unused padding values.
-
-- reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
-
-Example:
-
- touch@4b {
- compatible = "atmel,maxtouch";
- reg = <0x4b>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
new file mode 100644
index 0000000..8c6418f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/atmel,maxtouch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel maXTouch touchscreen/touchpad
+
+maintainers:
+ - Nick Dyer <nick@shmanahar.org>
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description: |
+ Atmel maXTouch touchscreen or touchpads such as the mXT244
+ and similar devices.
+
+properties:
+ compatible:
+ const: atmel,maxtouch
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdda-supply:
+ description:
+ Optional regulator for the AVDD analog voltage.
+
+ vdd-supply:
+ description:
+ Optional regulator for the VDD digital voltage.
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ Optional GPIO specifier for the touchscreen's reset pin
+ (active low). The line must be flagged with
+ GPIO_ACTIVE_LOW.
+
+ linux,gpio-keymap:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ When enabled, the SPT_GPIOPWN_T19 object sends messages
+ on GPIO bit changes. An array of up to 8 entries can be provided
+ indicating the Linux keycode mapped to each bit of the status byte,
+ starting at the LSB. Linux keycodes are defined in
+ <dt-bindings/input/input.h>.
+
+ Note: the numbering of the GPIOs and the bit they start at varies
+ between maXTouch devices. You must either refer to the documentation,
+ or experiment to determine which bit corresponds to which input. Use
+ KEY_RESERVED for unused padding values.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+ vdda-supply = <&ab8500_ldo_aux2_reg>;
+ vdd-supply = <&ab8500_ldo_aux5_reg>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
deleted file mode 100644
index 921172f..0000000
--- a/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Samsung tm2-touchkey
-
-Required properties:
-- compatible:
- * "cypress,tm2-touchkey" - for the touchkey found on the tm2 board
- * "cypress,midas-touchkey" - for the touchkey found on midas boards
- * "cypress,aries-touchkey" - for the touchkey found on aries boards
- * "coreriver,tc360-touchkey" - for the Coreriver TouchCore 360 touchkey
-- reg: I2C address of the chip.
-- interrupts: interrupt to which the chip is connected (see interrupt
- binding[0]).
-- vcc-supply : internal regulator output. 1.8V
-- vdd-supply : power supply for IC 3.3V
-
-Optional properties:
-- linux,keycodes: array of keycodes (max 4), default KEY_PHONE and KEY_BACK
-
-[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
-Example:
- &i2c0 {
- /* ... */
-
- touchkey@20 {
- compatible = "cypress,tm2-touchkey";
- reg = <0x20>;
- interrupt-parent = <&gpa3>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
- vcc-supply=<&ldo32_reg>;
- vdd-supply=<&ldo33_reg>;
- linux,keycodes = <KEY_PHONE KEY_BACK>;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.yaml b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.yaml
new file mode 100644
index 0000000..52dca8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cypress,tm2-touchkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung TM2 touch key controller
+
+maintainers:
+ - Stephan Gerhold <stephan@gerhold.net>
+
+description: |
+ Touch key controllers similar to the TM2 can be found in a wide range of
+ Samsung devices. They are implemented using many different MCUs, but use
+ a similar I2C protocol.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cypress,tm2-touchkey
+ - cypress,midas-touchkey
+ - cypress,aries-touchkey
+ - coreriver,tc360-touchkey
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Optional regulator for LED voltage, 3.3V.
+
+ vcc-supply:
+ description: Optional regulator for MCU, 1.8V-3.3V (depending on MCU).
+
+ vddio-supply:
+ description: |
+ Optional regulator that provides digital I/O voltage,
+ e.g. for pulling up the interrupt line or the I2C pins.
+
+ linux,keycodes:
+ minItems: 1
+ maxItems: 4
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchkey@20 {
+ compatible = "cypress,tm2-touchkey";
+ reg = <0x20>;
+ interrupt-parent = <&gpa3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ vcc-supply = <&ldo32_reg>;
+ vdd-supply = <&ldo33_reg>;
+ linux,keycodes = <KEY_MENU KEY_BACK>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt b/Documentation/devicetree/bindings/input/dlg,da7280.txt
new file mode 100644
index 0000000..96ee5d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da7280.txt
@@ -0,0 +1,108 @@
+Dialog Semiconductor DA7280 Haptics bindings
+
+Required properties:
+- compatible: Should be "dlg,da7280".
+- reg: Specifies the I2C slave address.
+
+- interrupt-parent : Specifies the phandle of the interrupt controller to
+ which the IRQs from DA7280 are delivered to.
+
+- dlg,actuator-type: Set Actuator type. it should be one of:
+ "LRA" - Linear Resonance Actuator type.
+ "ERM-bar" - Bar type Eccentric Rotating Mass.
+ "ERM-coin" - Coin type Eccentric Rotating Mass.
+
+- dlg,const-op-mode: Haptic operation mode for FF_CONSTANT.
+ Possible values:
+ 1 - Direct register override(DRO) mode triggered by i2c(default),
+ 2 - PWM data source mode controlled by PWM duty,
+- dlg,periodic-op-mode: Haptic operation mode for FF_PERIODIC.
+ Possible values:
+ 1 - Register triggered waveform memory(RTWM) mode, the pattern
+ assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP,
+ 2 - Edge triggered waveform memory(ETWM) mode, external GPI(N)
+ control are required to enable/disable and it needs to keep
+ device enabled by sending magnitude (X > 0),
+ the pattern is assigned to the GPI(N)_SEQUENCE_ID below.
+ The default value is 1 for both of the operation modes.
+ For more details, please see the datasheet.
+
+- dlg,nom-microvolt: Nominal actuator voltage rating.
+ Valid values: 0 - 6000000.
+- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating.
+ Valid values: 0 - 6000000.
+- dlg,imax-microamp: Actuator max current rating.
+ Valid values: 0 - 252000.
+ Default: 130000.
+- dlg,impd-micro-ohms: the impedance of the actuator in micro ohms.
+ Valid values: 0 - 1500000000.
+
+Optional properties:
+- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
+ PWM properties should be named "pwms". And number of cell is different
+ for each pwm device.
+ (See Documentation/devicetree/bindings/pwm/pwm.txt
+ for further information relating to pwm properties)
+
+- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip)
+ to play back when RTWM-MODE is enabled.
+ Valid range: 0 - 15.
+- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence
+ pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated.
+ Valid range: 0 - 15.
+- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play
+ when gpi0 is triggered, 'N' must be 0 - 2.
+ Valid range: 0 - 15.
+- dlg,gpiN-mode: the pattern mode which can select either
+ "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2.
+- dlg,gpiN-polarity: gpiN polarity which can be chosen among
+ "Rising-edge", "Falling-edge" and "Both-edge",
+ 'N' must be 0 - 2
+ Haptic will work by this edge option in case of ETWM mode.
+
+- dlg,resonant-freq-hz: use in case of LRA.
+ the frequency range: 50 - 300.
+ Default: 205.
+
+- dlg,bemf-sens-enable: Enable for internal loop computations.
+- dlg,freq-track-enable: Enable for resonant frequency tracking.
+- dlg,acc-enable: Enable for active acceleration.
+- dlg,rapid-stop-enable: Enable for rapid stop.
+- dlg,amp-pid-enable: Enable for the amplitude PID.
+- dlg,mem-array: Customized waveform memory(patterns) data downloaded to
+ the device during initialization. This is an array of 100 values(u8).
+
+For further information, see device datasheet.
+
+======
+
+Example:
+
+ haptics: da7280-haptics@4a {
+ compatible = "dlg,da7280";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ dlg,actuator-type = "LRA";
+ dlg,dlg,const-op-mode = <1>;
+ dlg,dlg,periodic-op-mode = <1>;
+ dlg,nom-microvolt = <2000000>;
+ dlg,abs-max-microvolt = <2000000>;
+ dlg,imax-microamp = <170000>;
+ dlg,resonant-freq-hz = <180>;
+ dlg,impd-micro-ohms = <10500000>;
+ dlg,freq-track-enable;
+ dlg,rapid-stop-enable;
+ dlg,mem-array = <
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ >;
+ };
diff --git a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml
index 378a85c..878464f 100644
--- a/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml
+++ b/Documentation/devicetree/bindings/input/fsl,mpr121-touchkey.yaml
@@ -31,8 +31,7 @@
interrupts:
maxItems: 1
- vdd-supply:
- maxItems: 1
+ vdd-supply: true
linux,keycodes:
minItems: 1
diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml
index 6966ab0..060a309 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys.yaml
+++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml
@@ -34,13 +34,13 @@
linux,code:
description: Key / Axis code to emit.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
linux,input-type:
description:
Specify event type this button/key generates. If not specified defaults to
<1> == EV_KEY.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 1
@@ -56,12 +56,12 @@
linux,input-value = <0xffffffff>; /* -1 */
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
debounce-interval:
description:
Debouncing interval time in milliseconds. If not specified defaults to 5.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 5
@@ -79,7 +79,7 @@
EV_ACT_ANY - both asserted and deasserted
EV_ACT_ASSERTED - asserted
EV_ACT_DEASSERTED - deasserted
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
linux,can-disable:
@@ -118,7 +118,7 @@
poll-interval:
description:
Poll interval time in milliseconds
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
required:
- poll-interval
diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
deleted file mode 100644
index f2ec0d4..0000000
--- a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Spreadtrum SC27xx PMIC Vibrator
-
-Required properties:
-- compatible: should be "sprd,sc2731-vibrator".
-- reg: address of vibrator control register.
-
-Example :
-
- sc2731_pmic: pmic@0 {
- compatible = "sprd,sc2731";
- reg = <0>;
- spi-max-frequency = <26000000>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- vibrator@eb4 {
- compatible = "sprd,sc2731-vibrator";
- reg = <0xeb4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml
new file mode 100644
index 0000000..5d67fc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2020 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/sprd,sc27xx-vibrator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC27xx PMIC Vibrator Device Tree Bindings
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - sprd,sc2721-vibrator
+ - sprd,sc2730-vibrator
+ - sprd,sc2731-vibrator
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0 0>;
+ spi-max-frequency = <26000000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vibrator@eb4 {
+ compatible = "sprd,sc2731-vibrator";
+ reg = <0xeb4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
index 4ce1094..bfc3a8b 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -55,8 +55,7 @@
wakeup-source: true
- vcc-supply:
- maxItems: 1
+ vcc-supply: true
gain:
description: Allows setting the sensitivity in the range from 0 to 31.
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
index 94c4fc6..5eef5e7 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
@@ -1,7 +1,7 @@
* Elan eKTF2127 I2C touchscreen controller
Required properties:
- - compatible : "elan,ektf2127"
+ - compatible : "elan,ektf2127" or "elan,ektf2132"
- reg : I2C slave address of the chip (0x40)
- interrupts : interrupt specification for the ektf2127 interrupt
- power-gpios : GPIO specification for the pin connected to the
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
index 0688996..ba282f4 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
@@ -35,7 +35,6 @@
- arm,gic-400
- arm,pl390
- arm,tc11mp-gic
- - nvidia,tegra210-agic
- qcom,msm-8660-qgic
- qcom,msm-qgic2
@@ -53,6 +52,14 @@
- const: brcm,brahma-b15-gic
- const: arm,cortex-a15-gic
+ - oneOf:
+ - const: nvidia,tegra210-agic
+ - items:
+ - enum:
+ - nvidia,tegra186-agic
+ - nvidia,tegra194-agic
+ - const: nvidia,tegra210-agic
+
interrupt-controller: true
"#address-cells":
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
index f0ad780..4d47df1 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
@@ -1,6 +1,7 @@
* Freescale Layerscape external IRQs
-Some Layerscape SOCs (LS1021A, LS1043A, LS1046A) support inverting
+Some Layerscape SOCs (LS1021A, LS1043A, LS1046A
+LS1088A, LS208xA, LX216xA) support inverting
the polarity of certain external interrupt lines.
The device node must be a child of the node representing the
@@ -8,12 +9,15 @@
Required properties:
- compatible: should be "fsl,<soc-name>-extirq", e.g. "fsl,ls1021a-extirq".
+ "fsl,ls1043a-extirq": for LS1043A, LS1046A.
+ "fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA.
- #interrupt-cells: Must be 2. The first element is the index of the
external interrupt line. The second element is the trigger type.
- #address-cells: Must be 0.
- interrupt-controller: Identifies the node as an interrupt controller
- reg: Specifies the Interrupt Polarity Control Register (INTPCR) in
- the SCFG.
+ the SCFG or the External Interrupt Control Register (IRQCR) in
+ the ISC.
- interrupt-map: Specifies the mapping from external interrupts to GIC
interrupts.
- interrupt-map-mask: Must be <0xffffffff 0>.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
deleted file mode 100644
index f5baecc..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsemi Ocelot SoC ICPU Interrupt Controller
-
-Required properties:
-
-- compatible : should be "mscc,ocelot-icpu-intr"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
- intc: interrupt-controller@70000070 {
- compatible = "mscc,ocelot-icpu-intr";
- reg = <0x70000070 0x70>;
- #interrupt-cells = <1>;
- interrupt-controller;
- interrupt-parent = <&cpuintc>;
- interrupts = <2>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
new file mode 100644
index 0000000..27b798b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Microsemi Ocelot SoC ICPU Interrupt Controller
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+ the Microsemi Ocelot interrupt controller that is part of the
+ ICPU. It is connected directly to the MIPS core interrupt
+ controller.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mscc,jaguar2-icpu-intr
+ - mscc,luton-icpu-intr
+ - mscc,ocelot-icpu-intr
+ - mscc,serval-icpu-intr
+
+
+ '#interrupt-cells':
+ const: 1
+
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - '#address-cells'
+ - interrupt-controller
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ intc: interrupt-controller@70000070 {
+ compatible = "mscc,ocelot-icpu-intr";
+ reg = <0x70000070 0x70>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ interrupt-controller;
+ interrupt-parent = <&cpuintc>;
+ interrupts = <2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
index 039e08a..91bb3c2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml
@@ -42,7 +42,7 @@
Specifies the list of CPU interrupt vectors to which the GIC may not
route interrupts. This property is ignored if the CPU is started in EIC
mode.
- $ref: /schemas/types.yaml#definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 6
uniqueItems: true
@@ -56,7 +56,7 @@
It accepts two values: the 1st is the starting interrupt and the 2nd is
the size of the reserved range. If not specified, the driver will
allocate the last (2 * number of VPEs in the system).
- $ref: /schemas/types.yaml#definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
items:
- minimum: 0
maximum: 254
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
index 1c4c009..c2ce215 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
@@ -80,7 +80,7 @@
mapping is provided.
ti,irqs-reserved:
- $ref: /schemas/types.yaml#definitions/uint8
+ $ref: /schemas/types.yaml#/definitions/uint8
description: |
Bitmask of host interrupts between 0 and 7 (corresponding to PRUSS INTC
output interrupts 2 through 9) that are not connected to the Arm interrupt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
index b5af120..3d89668 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
@@ -76,7 +76,7 @@
"limit" specifies the limit for translation
ti,unmapped-event-sources:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
Array of phandles to DMA controllers where the unmapped events originate.
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 503160a..3b63f2a 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -28,8 +28,6 @@
- enum:
- qcom,msm8996-smmu-v2
- qcom,msm8998-smmu-v2
- - qcom,sc7180-smmu-v2
- - qcom,sdm845-smmu-v2
- const: qcom,smmu-v2
- description: Qcom SoCs implementing "arm,mmu-500"
@@ -40,6 +38,13 @@
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- const: arm,mmu-500
+ - description: Qcom Adreno GPUs implementing "arm,smmu-v2"
+ items:
+ - enum:
+ - qcom,sc7180-smmu-v2
+ - qcom,sdm845-smmu-v2
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-v2
- description: Marvell SoCs implementing "arm,mmu-500"
items:
- const: marvell,ap806-smmu-500
diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml b/Documentation/devicetree/bindings/leds/backlight/common.yaml
index bc817f7..702ba35 100644
--- a/Documentation/devicetree/bindings/leds/backlight/common.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml
@@ -22,7 +22,7 @@
The default brightness that should be applied to the LED by the operating
system on start-up. The brightness should not exceed the brightness the
LED can provide.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
max-brightness:
description:
@@ -31,6 +31,6 @@
on the brightness apart from what the driver says, as it could happen
that a LED can be made so bright that it gets damaged or causes damage
due to restrictions in a specific system, such as mounting conditions.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index f1211e7..b1f3637 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -27,21 +27,21 @@
List of device current outputs the LED is connected to. The outputs are
identified by the numbers that must be defined in the LED device binding
documentation.
- $ref: /schemas/types.yaml#definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
function:
description:
LED function. Use one of the LED_FUNCTION_* prefixed definitions
from the header include/dt-bindings/leds/common.h. If there is no
matching LED_FUNCTION available, add a new one.
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
color:
description:
Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from
the header include/dt-bindings/leds/common.h. If there is no matching
LED_COLOR_ID available, add a new one.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 9
@@ -49,7 +49,7 @@
description:
Integer to be used when more than one instance of the same function is
needed, differing only with an ordinal number.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
label:
description:
@@ -66,7 +66,7 @@
produced where the LED momentarily turns off (or on). The "keep" setting
will keep the LED at whatever its current state is, without producing a
glitch.
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- on
- off
@@ -77,7 +77,7 @@
description:
This parameter, if present, is a string defining the trigger assigned to
the LED.
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
enum:
# LED will act as a back-light, controlled by the framebuffer system
@@ -109,7 +109,7 @@
brightness and duration (in ms). The exact format is
described in:
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
- $ref: /schemas/types.yaml#definitions/uint32-matrix
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
minItems: 2
maxItems: 2
@@ -143,7 +143,7 @@
the device tree and be referenced by a phandle and a set of phandle
arguments. A length of arguments should be specified by the
#trigger-source-cells property in the source node.
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
# Required properties for flash LED child nodes:
flash-max-microamp:
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
index 58e9747..f552cd1 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
@@ -35,7 +35,7 @@
description: I2C slave address
clock-mode:
- $ref: /schemas/types.yaml#definitions/uint8
+ $ref: /schemas/types.yaml#/definitions/uint8
description: |
Input clock mode
enum:
@@ -49,7 +49,7 @@
GPIO attached to the chip's enable pin
pwr-sel:
- $ref: /schemas/types.yaml#definitions/uint8
+ $ref: /schemas/types.yaml#/definitions/uint8
description: |
LP8501 specific property. Power selection for output channels.
enum:
@@ -70,14 +70,14 @@
$ref: common.yaml#
properties:
led-cur:
- $ref: /schemas/types.yaml#definitions/uint8
+ $ref: /schemas/types.yaml#/definitions/uint8
description: |
Current setting at each LED channel (mA x10, 0 if LED is not connected)
minimum: 0
maximum: 255
max-cur:
- $ref: /schemas/types.yaml#definitions/uint8
+ $ref: /schemas/types.yaml#/definitions/uint8
description: Maximun current at each LED channel.
reg:
@@ -97,7 +97,7 @@
- 8 # LED output D9
chan-name:
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
description: name of channel
required:
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt
deleted file mode 100644
index 6c6583c..0000000
--- a/Documentation/devicetree/bindings/leds/leds-pwm.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-LED connected to PWM
-
-Required properties:
-- compatible : should be "pwm-leds".
-
-Each LED is represented as a sub-node of the pwm-leds device. Each
-node's name represents the name of the corresponding LED.
-
-LED sub-node properties:
-- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
- specify the period time to be used: <&phandle id period_ns>;
-- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM device
- For the pwms and pwm-names property please refer to:
- Documentation/devicetree/bindings/pwm/pwm.txt
-- max-brightness : Maximum brightness possible for the LED
-- active-low : (optional) For PWMs where the LED is wired to supply
- rather than ground.
-- label : (optional)
- see Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger : (optional)
- see Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
-twl_pwm: pwm {
- /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
- compatible = "ti,twl6030-pwm";
- #pwm-cells = <2>;
-};
-
-twl_pwmled: pwmled {
- /* provides one PWM (id 0 for Charing indicator LED) */
- compatible = "ti,twl6030-pwmled";
- #pwm-cells = <2>;
-};
-
-pwmleds {
- compatible = "pwm-leds";
- kpad {
- label = "omap4::keypad";
- pwms = <&twl_pwm 0 7812500>;
- max-brightness = <127>;
- };
-
- charging {
- label = "omap4:green:chrg";
- pwms = <&twl_pwmled 0 7812500>;
- max-brightness = <255>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
new file mode 100644
index 0000000..fe4d5fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LEDs connected to PWM
+
+maintainers:
+ - Pavel Machek <pavel@ucw.cz>
+
+description:
+ Each LED is represented as a sub-node of the pwm-leds device. Each
+ node's name represents the name of the corresponding LED.
+
+properties:
+ compatible:
+ const: pwm-leds
+
+patternProperties:
+ "^led(-[0-9a-f]+)?$":
+ type: object
+
+ $ref: common.yaml#
+
+ properties:
+ pwms:
+ maxItems: 1
+
+ pwm-names: true
+
+ max-brightness:
+ description:
+ Maximum brightness possible for the LED
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ active-low:
+ description:
+ For PWMs where the LED is wired to supply rather than ground.
+ type: boolean
+
+ required:
+ - pwms
+ - max-brightness
+
+additionalProperties: false
+
+examples:
+ - |
+
+ #include <dt-bindings/leds/common.h>
+
+ led-controller {
+ compatible = "pwm-leds";
+
+ led-1 {
+ label = "omap4::keypad";
+ pwms = <&twl_pwm 0 7812500>;
+ max-brightness = <127>;
+ };
+
+ led-2 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_CHARGING;
+ pwms = <&twl_pwmled 0 7812500>;
+ max-brightness = <255>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
index d43791a..d07eb00 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
@@ -61,7 +61,6 @@
- description: low-priority non-secure
- description: high-priority non-secure
- description: Secure
- maxItems: 3
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
new file mode 100644
index 0000000..6608545
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
@@ -0,0 +1,209 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm,mhuv2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM MHUv2 Mailbox Controller
+
+maintainers:
+ - Tushar Khandelwal <tushar.khandelwal@arm.com>
+ - Viresh Kumar <viresh.kumar@linaro.org>
+
+description: |
+ The Arm Message Handling Unit (MHU) Version 2 is a mailbox controller that has
+ between 1 and 124 channel windows (each 32-bit wide) to provide unidirectional
+ communication with remote processor(s), where the number of channel windows
+ are implementation dependent.
+
+ Given the unidirectional nature of the controller, an MHUv2 mailbox may only
+ be written to or read from. If a pair of MHU controllers is implemented
+ between two processing elements to provide bidirectional communication, these
+ must be specified as two separate mailboxes.
+
+ If the interrupts property is present in device tree node, then its treated as
+ a "receiver" mailbox, otherwise a "sender".
+
+ An MHU controller must be specified along with the supported transport
+ protocols. The transport protocols determine the method of data transmission
+ as well as the number of provided mailbox channels.
+
+ Following are the possible transport protocols.
+
+ - Data-transfer: Each transfer is made of one or more words, using one or more
+ channel windows.
+
+ - Doorbell: Each transfer is made up of single bit flag, using any one of the
+ bits in a channel window. A channel window can support up to 32 doorbells
+ and the entire window shall be used in doorbell protocol. Optionally, data
+ may be transmitted through a shared memory region, wherein the MHU is used
+ strictly as an interrupt generation mechanism but that is out of the scope
+ of these bindings.
+
+# We need a select here so we don't match all nodes with 'arm,primecell'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - arm,mhuv2-tx
+ - arm,mhuv2-rx
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - description: Sender mode
+ items:
+ - const: arm,mhuv2-tx
+ - const: arm,primecell
+
+ - description: Receiver-mode
+ items:
+ - const: arm,mhuv2-rx
+ - const: arm,primecell
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: |
+ The MHUv2 controller always implements an interrupt in the "receiver"
+ mode, while the interrupt in the "sender" mode was not available in the
+ version MHUv2.0, but the later versions do have it.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ arm,mhuv2-protocols:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ The MHUv2 controller may contain up to 124 channel windows (each 32-bit
+ wide). The hardware and the DT bindings allows any combination of those to
+ be used for various transport protocols.
+
+ This property allows a platform to describe how these channel windows are
+ used in various transport protocols. The entries in this property shall be
+ present as an array of tuples, where each tuple describes details about
+ one of the transport protocol being implemented over some channel
+ window(s).
+
+ The first field of a tuple signifies the transfer protocol, 0 is reserved
+ for doorbell protocol, and 1 is reserved for data-transfer protocol.
+ Using any other value in the first field of a tuple makes it invalid.
+
+ The second field of a tuple signifies the number of channel windows where
+ the protocol would be used and should be set to a non zero value. For
+ doorbell protocol this field signifies the number of 32-bit channel
+ windows that implement the doorbell protocol. For data-transfer protocol,
+ this field signifies the number of 32-bit channel windows that implement
+ the data-transfer protocol.
+
+ The total number of channel windows specified here shouldn't be more than
+ the ones implemented by the platform, though one can specify lesser number
+ of windows here than what the platform implements.
+
+ mhu: mailbox@2b1f0000 {
+ ...
+
+ arm,mhuv2-protocols = <0 2>, <1 1>, <1 5>, <1 7>;
+ }
+
+ The above example defines the protocols of an ARM MHUv2 mailbox
+ controller, where a total of 15 channel windows are used. The first two
+ windows are used in doorbell protocol (64 doorbells), followed by 1, 5 and
+ 7 windows (separately) used in data-transfer protocol.
+
+ minItems: 1
+ maxItems: 124
+ items:
+ items:
+ - enum: [ 0, 1 ]
+ - minimum: 0
+ maximum: 124
+
+
+ '#mbox-cells':
+ description: |
+ It is always set to 2. The first argument in the consumers 'mboxes'
+ property represents the channel window group, which may be used in
+ doorbell, or data-transfer protocol, and the second argument (only
+ relevant in doorbell protocol, should be 0 otherwise) represents the
+ doorbell number within the 32 bit wide channel window.
+
+ From the example given above for arm,mhuv2-protocols, here is how a client
+ node can reference them.
+
+ mboxes = <&mhu 0 5>; // Channel Window Group 0, doorbell 5.
+ mboxes = <&mhu 1 7>; // Channel Window Group 1, doorbell 7.
+ mboxes = <&mhu 2 0>; // Channel Window Group 2, data transfer protocol with 1 window.
+ mboxes = <&mhu 3 0>; // Channel Window Group 3, data transfer protocol with 5 windows.
+ mboxes = <&mhu 4 0>; // Channel Window Group 4, data transfer protocol with 7 windows.
+
+ const: 2
+
+if:
+ # Interrupt is compulsory for receiver
+ properties:
+ compatible:
+ contains:
+ const: arm,mhuv2-rx
+then:
+ required:
+ - interrupts
+
+required:
+ - compatible
+ - reg
+ - '#mbox-cells'
+ - arm,mhuv2-protocols
+
+additionalProperties: false
+
+examples:
+ # Multiple transport protocols implemented by the mailbox controllers
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mhu_tx: mailbox@2b1f0000 {
+ #mbox-cells = <2>;
+ compatible = "arm,mhuv2-tx", "arm,primecell";
+ reg = <0 0x2b1f0000 0 0x1000>;
+ clocks = <&clock 0>;
+ clock-names = "apb_pclk";
+ interrupts = <0 45 4>;
+ arm,mhuv2-protocols = <1 5>, <1 2>, <1 5>, <1 7>, <0 2>;
+ };
+
+ mhu_rx: mailbox@2b1f1000 {
+ #mbox-cells = <2>;
+ compatible = "arm,mhuv2-rx", "arm,primecell";
+ reg = <0 0x2b1f1000 0 0x1000>;
+ clocks = <&clock 0>;
+ clock-names = "apb_pclk";
+ interrupts = <0 46 4>;
+ arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>;
+ };
+
+ mhu_client: scb@2e000000 {
+ compatible = "fujitsu,mb86s70-scb-1.0";
+ reg = <0 0x2e000000 0 0x4000>;
+
+ mboxes =
+ //data-transfer protocol with 5 windows, mhu-tx
+ <&mhu_tx 2 0>,
+ //data-transfer protocol with 7 windows, mhu-tx
+ <&mhu_tx 3 0>,
+ //doorbell protocol channel 4, doorbell 27, mhu-tx
+ <&mhu_tx 4 27>,
+ //data-transfer protocol with 1 window, mhu-rx
+ <&mhu_rx 0 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
index 4cc1a67..2f7058f 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
@@ -18,6 +18,8 @@
- allwinner,sun7i-a20-video-engine
- allwinner,sun8i-a33-video-engine
- allwinner,sun8i-h3-video-engine
+ - allwinner,sun8i-v3s-video-engine
+ - allwinner,sun8i-r40-video-engine
- allwinner,sun50i-a64-video-engine
- allwinner,sun50i-h5-video-engine
- allwinner,sun50i-h6-video-engine
diff --git a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
new file mode 100644
index 0000000..bee93bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic GE2D Acceleration Unit
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,axg-ge2d
+
+ interrupts:
+ minItems: 1
+
+ reg:
+ minItems: 1
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ ge2d: ge2d@ff940000 {
+ compatible = "amlogic,axg-ge2d";
+ reg = <0xff940000 0x10000>;
+ interrupts = <150>;
+ clocks = <&clk_ge2d>;
+ resets = <&reset_ge2d>;
+ };
diff --git a/Documentation/devicetree/bindings/media/coda.txt b/Documentation/devicetree/bindings/media/coda.txt
deleted file mode 100644
index 90eb74c..0000000
--- a/Documentation/devicetree/bindings/media/coda.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Chips&Media Coda multi-standard codec IP
-========================================
-
-Coda codec IPs are present in i.MX SoCs in various versions,
-called VPU (Video Processing Unit).
-
-Required properties:
-- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
- (a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
- (b) "fsl,imx51-vpu" for CodaHx4 present in i.MX51
- (c) "fsl,imx53-vpu" for CODA7541 present in i.MX53
- (d) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
-- reg: should be register base and length as documented in the
- SoC reference manual
-- interrupts : Should contain the VPU interrupt. For CODA960,
- a second interrupt is needed for the MJPEG unit.
-- clocks : Should contain the ahb and per clocks, in the order
- determined by the clock-names property.
-- clock-names : Should be "ahb", "per"
-- iram : phandle pointing to the SRAM device node
-
-Example:
-
-vpu: vpu@63ff4000 {
- compatible = "fsl,imx53-vpu";
- reg = <0x63ff4000 0x1000>;
- interrupts = <9>;
- clocks = <&clks 63>, <&clks 63>;
- clock-names = "ahb", "per";
- iram = <&ocram>;
-};
diff --git a/Documentation/devicetree/bindings/media/coda.yaml b/Documentation/devicetree/bindings/media/coda.yaml
new file mode 100644
index 0000000..36781ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/coda.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/coda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Chips&Media Coda multi-standard codec IP
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+description: |-
+ Coda codec IPs are present in i.MX SoCs in various versions,
+ called VPU (Video Processing Unit).
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,imx27-vpu
+ - const: cnm,codadx6
+ - items:
+ - const: fsl,imx51-vpu
+ - const: cnm,codahx4
+ - items:
+ - const: fsl,imx53-vpu
+ - const: cnm,coda7541
+ - items:
+ - enum:
+ - fsl,imx6dl-vpu
+ - fsl,imx6q-vpu
+ - const: cnm,coda960
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PER clock
+ - description: AHB interface clock
+
+ clock-names:
+ items:
+ - const: per
+ - const: ahb
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: BIT processor interrupt
+ - description: JPEG unit interrupt
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: bit
+ - const: jpeg
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ iram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle pointing to the SRAM device node
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: cnm,coda960
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+
+ interrupt-names:
+ minItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ power-domains: false
+
+examples:
+ - |
+ vpu: video-codec@63ff4000 {
+ compatible = "fsl,imx53-vpu", "cnm,coda7541";
+ reg = <0x63ff4000 0x1000>;
+ interrupts = <9>;
+ clocks = <&clks 63>, <&clks 63>;
+ clock-names = "per", "ahb";
+ iram = <&ocram>;
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
deleted file mode 100644
index b3e688b..0000000
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-* Analog Devices ADV7604/11/12 video decoder with HDMI receiver
-
-The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated
-HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog
-input, and the ADV7611 has one HDMI input and no analog input. The 7612 is
-similar to the 7611 but has 2 HDMI inputs.
-
-These device tree bindings support the ADV7611/12 only at the moment.
-
-Required Properties:
-
- - compatible: Must contain one of the following
- - "adi,adv7611" for the ADV7611
- - "adi,adv7612" for the ADV7612
-
- - reg: I2C slave addresses
- The ADV76xx has up to thirteen 256-byte maps that can be accessed via the
- main I2C ports. Each map has it own I2C address and acts as a standard
- slave device on the I2C bus. The main address is mandatory, others are
- optional and revert to defaults if not specified.
-
- - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
- detection pins, one per HDMI input. The active flag indicates the GPIO
- level that enables hot-plug detection.
-
-The device node must contain one 'port' child node per device input and output
-port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
-are numbered as follows.
-
- Port ADV7611 ADV7612
-------------------------------------------------------------
- HDMI 0 0, 1
- Digital output 1 2
-
-The digital output port node must contain at least one endpoint.
-
-Optional Properties:
-
- - reset-gpios: Reference to the GPIO connected to the device's reset pin.
- - default-input: Select which input is selected after reset.
- - reg-names : Names of maps with programmable addresses.
- It can contain any map needing a non-default address.
- Possible maps names are :
- "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
- "rep", "edid", "hdmi", "test", "cp", "vdp"
-
-Optional Endpoint Properties:
-
- The following three properties are defined in video-interfaces.txt and are
- valid for source endpoints only.
-
- - hsync-active: Horizontal synchronization polarity. Defaults to active low.
- - vsync-active: Vertical synchronization polarity. Defaults to active low.
- - pclk-sample: Pixel clock polarity. Defaults to output on the falling edge.
-
- If none of hsync-active, vsync-active and pclk-sample is specified the
- endpoint will use embedded BT.656 synchronization.
-
-Example:
-
- hdmi_receiver@4c {
- compatible = "adi,adv7611";
- /*
- * The edid page will be accessible @ 0x66 on the I2C bus. All
- * other maps will retain their default addresses.
- */
- reg = <0x4c>, <0x66>;
- reg-names = "main", "edid";
-
- reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
- hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- default-input = <0>;
-
- port@0 {
- reg = <0>;
- };
- port@1 {
- reg = <1>;
- hdmi_in: endpoint {
- remote-endpoint = <&ccdc_in>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
new file mode 100644
index 0000000..407badd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/adv7604.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7604/11/12 video decoder with HDMI receiver
+
+maintainers:
+ - Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+description:
+ The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated
+ HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog
+ input, and the ADV7611 has one HDMI input and no analog input. The 7612 is
+ similar to the 7611 but has 2 HDMI inputs.
+
+ These device tree bindings support the ADV7611/12 only at the moment.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - adi,adv7611
+ - adi,adv7612
+
+ reg:
+ minItems: 1
+ maxItems: 13
+
+ reg-names:
+ minItems: 1
+ maxItems: 13
+ items:
+ - const: main
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ hpd-gpios:
+ minItems: 1
+ description:
+ References to the GPIOs that control the HDMI hot-plug detection pins,
+ one per HDMI input. The active flag indicates the GPIO level that
+ enables hot-plug detection.
+
+ default-input:
+ maxItems: 1
+ description:
+ Select which input is selected after reset.
+
+ ports:
+ type: object
+ description:
+ A node containing input and output port nodes with endpoint definitions
+ as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7611
+ then:
+ properties:
+ ports:
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+ port@0:
+ type: object
+ description: Input port
+ port@1:
+ type: object
+ description: Output port
+
+ required:
+ - port@1
+
+ additionalProperties: false
+
+ required:
+ - ports
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7612
+ then:
+ properties:
+ ports:
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+ port@2:
+ type: object
+ description: Output port
+
+ patternProperties:
+ "^port@[0-1]$":
+ type: object
+ description: Input port
+
+ required:
+ - port@2
+
+ additionalProperties: false
+
+ required:
+ - ports
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_receiver@4c {
+ compatible = "adi,adv7611";
+ /*
+ * The edid page will be accessible @ 0x66 on the I2C bus. All
+ * other maps will retain their default addresses.
+ */
+ reg = <0x4c>, <0x66>;
+ reg-names = "main", "edid";
+
+ reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
+ hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
+ default-input = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_in: endpoint {
+ remote-endpoint = <&ccdc_in>;
+ };
+ };
+ };
+
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
deleted file mode 100644
index bd896e9..0000000
--- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Aptina MT9V111 CMOS sensor
-----------------------------
-
-The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
-based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
-
-The sensor has an active pixel array of 640x480 pixels and can output a number
-of image resolution and formats controllable through a simple two-wires
-interface.
-
-Required properties:
---------------------
-
-- compatible: shall be "aptina,mt9v111".
-- clocks: reference to the system clock input provider.
-
-Optional properties:
---------------------
-
-- enable-gpios: output enable signal, pin name "OE#". Active low.
-- standby-gpios: low power state control signal, pin name "STANDBY".
- Active high.
-- reset-gpios: chip reset signal, pin name "RESET#". Active low.
-
-The device node must contain one 'port' child node with one 'endpoint' child
-sub-node for its digital output video port, in accordance with the video
-interface bindings defined in:
-Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
---------
-
- &i2c1 {
- camera@48 {
- compatible = "aptina,mt9v111";
- reg = <0x48>;
-
- clocks = <&camera_clk>;
-
- port {
- mt9v111_out: endpoint {
- remote-endpoint = <&ceu_in>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
new file mode 100644
index 0000000..ff9546e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/aptina,mt9v111.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aptina MT9V111 CMOS sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo@jmondi.org>
+
+description: |
+ The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+ based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+ The sensor has an active pixel array of 640x480 pixels and can output a number
+ of image resolutions and formats controllable through a simple two-wires
+ interface.
+
+properties:
+ compatible:
+ const: aptina,mt9v111
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ enable-gpios:
+ description: Enable signal, pin name "OE#". Active low.
+ maxItems: 1
+
+ standby-gpios:
+ description: |
+ Low power state control signal, pin name "STANDBY". Active high.
+ maxItems: 1
+
+ reset-gpios:
+ description: Chip reset signal, pin name "RESET#". Active low.
+ maxItems: 1
+
+ port:
+ type: object
+ description: |
+ Output video port. See ../video-interfaces.txt.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+ clocks = <&camera_clk>;
+
+ port {
+ mt9v111_out: endpoint {
+ remote-endpoint = <&ceu_in>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 9ea8270..68ee8c7 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -40,7 +40,6 @@
poc-supply:
description: Regulator providing Power over Coax to the cameras
- maxItems: 1
enable-gpios:
description: GPIO connected to the \#PWDN pin with inverted polarity
diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
new file mode 100644
index 0000000..bb35283
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2014--2020 Intel Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/mipi-ccs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI CCS, SMIA++ and SMIA compliant camera sensors
+
+maintainers:
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+description:
+
+ CCS (Camera Command Set) is a raw Bayer camera sensor standard defined by the
+ MIPI Alliance; see
+ <URL:https://www.mipi.org/specifications/camera-command-set>.
+
+ SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
+ defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension of
+ that.
+
+ More detailed documentation can be found in
+ Documentation/devicetree/bindings/media/video-interfaces.txt .
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: mipi-ccs-1.1
+ - const: mipi-ccs
+ - items:
+ - const: mipi-ccs-1.0
+ - const: mipi-ccs
+ - const: nokia,smia
+
+ reg:
+ maxItems: 1
+
+ vana-supply:
+ description: Analogue voltage supply (VANA), sensor dependent.
+
+ vcore-supply:
+ description: Core voltage supply (VCore), sensor dependent.
+
+ vio-supply:
+ description: I/O voltage supply (VIO), sensor dependent.
+
+ clocks:
+ description: External clock to the sensor.
+ maxItems: 1
+
+ clock-frequency:
+ description: Frequency of the external clock to the sensor in Hz.
+
+ reset-gpios:
+ description: Reset GPIO. Also commonly called XSHUTDOWN in hardware
+ documentation.
+ maxItems: 1
+
+ flash-leds:
+ description: Flash LED phandles. See ../video-interfaces.txt for details.
+
+ lens-focus:
+ description: Lens focus controller phandles. See ../video-interfaces.txt
+ for details.
+
+ rotation:
+ description: Rotation of the sensor. See ../video-interfaces.txt for
+ details.
+ enum: [ 0, 180 ]
+
+ port:
+ type: object
+ properties:
+ endpoint:
+ type: object
+ properties:
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ description: List of allowed data link frequencies.
+ data-lanes:
+ minItems: 1
+ maxItems: 8
+ bus-type:
+ description: The type of the data bus.
+ oneOf:
+ - const: 1 # CSI-2 C-PHY
+ - const: 3 # CCP2
+ - const: 4 # CSI-2 D-PHY
+
+ required:
+ - link-frequencies
+ - data-lanes
+ - bus-type
+
+required:
+ - compatible
+ - reg
+ - clock-frequency
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-frequency = <400000>;
+
+ camera-sensor@10 {
+ compatible = "mipi-ccs-1.0", "mipi-ccs";
+ reg = <0x10>;
+ reset-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
+ vana-supply = <&vaux3>;
+ clocks = <&omap3_isp 0>;
+ clock-frequency = <9600000>;
+ port {
+ ccs_ep: endpoint {
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2a_ep>;
+ link-frequencies = /bits/ 64 <199200000 210000000
+ 499200000>;
+ bus-type = <4>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
deleted file mode 100644
index 10ece81..0000000
--- a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-SMIA/SMIA++ sensor
-
-SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
-defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension
-of that. These definitions are valid for both types of sensors.
-
-More detailed documentation can be found in
-Documentation/devicetree/bindings/media/video-interfaces.txt .
-
-The device node should contain a "port" node which may contain one or more
-endpoint nodes, in accordance with video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt .
-
-Mandatory properties
---------------------
-
-- compatible: "nokia,smia"
-- reg: I2C address (0x10, or an alternative address)
-- vana-supply: Analogue voltage supply (VANA), typically 2,8 volts (sensor
- dependent).
-- clocks: External clock to the sensor
-- clock-frequency: Frequency of the external clock to the sensor
-- link-frequencies: List of allowed data link frequencies. An array of
- 64-bit elements.
-
-
-Optional properties
--------------------
-
-- reset-gpios: XSHUTDOWN GPIO
-- flash-leds: See ../video-interfaces.txt
-- lens-focus: See ../video-interfaces.txt
-- rotation: Integer property; valid values are 0 (sensor mounted upright)
- and 180 (sensor mounted upside down). See
- ../video-interfaces.txt .
-
-
-Endpoint node mandatory properties
-----------------------------------
-
-- data-lanes: <1..n>
-
-
-Example
--------
-
-&i2c2 {
- clock-frequency = <400000>;
-
- camera-sensor@10 {
- compatible = "nokia,smia";
- reg = <0x10>;
- reset-gpios = <&gpio3 20 0>;
- vana-supply = <&vaux3>;
- clocks = <&omap3_isp 0>;
- clock-frequency = <9600000>;
- nokia,nvm-size = <512>; /* 8 * 64 */
- link-frequencies = /bits/ 64 <199200000 210000000 499200000>;
- port {
- smiapp_ep: endpoint {
- data-lanes = <1 2>;
- remote-endpoint = <&csi2a_ep>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2680.txt b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
deleted file mode 100644
index 11e925e..0000000
--- a/Documentation/devicetree/bindings/media/i2c/ov2680.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Omnivision OV2680 MIPI CSI-2 sensor
-
-Required Properties:
-- compatible: should be "ovti,ov2680".
-- clocks: reference to the xvclk input clock.
-- clock-names: should be "xvclk".
-- DOVDD-supply: Digital I/O voltage supply.
-- DVDD-supply: Digital core voltage supply.
-- AVDD-supply: Analog voltage supply.
-
-Optional Properties:
-- reset-gpios: reference to the GPIO connected to the powerdown/reset pin,
- if any. This is an active low signal to the OV2680.
-
-The device node must contain one 'port' child node for its digital output
-video port, and this port must have a single endpoint in accordance with
- the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Endpoint node required properties for CSI-2 connection are:
-- remote-endpoint: a phandle to the bus receiver's endpoint node.
-- clock-lanes: should be set to <0> (clock lane on hardware lane 0).
-- data-lanes: should be set to <1> (one CSI-2 lane supported).
-
-Example:
-
-&i2c2 {
- ov2680: camera-sensor@36 {
- compatible = "ovti,ov2680";
- reg = <0x36>;
- clocks = <&osc>;
- clock-names = "xvclk";
- reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
- DOVDD-supply = <&sw2_reg>;
- DVDD-supply = <&sw2_reg>;
- AVDD-supply = <®_peri_3p15v>;
-
- port {
- ov2680_to_mipi: endpoint {
- remote-endpoint = <&mipi_from_sensor>;
- clock-lanes = <0>;
- data-lanes = <1>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/ov772x.txt b/Documentation/devicetree/bindings/media/i2c/ov772x.txt
deleted file mode 100644
index 0b3ede5..0000000
--- a/Documentation/devicetree/bindings/media/i2c/ov772x.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-* Omnivision OV7720/OV7725 CMOS sensor
-
-The Omnivision OV7720/OV7725 sensor supports multiple resolutions output,
-such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also can
-support the YUV422, RGB565/555/444, GRB422 or raw RGB output formats.
-
-Required Properties:
-- compatible: shall be one of
- "ovti,ov7720"
- "ovti,ov7725"
-- clocks: reference to the xclk input clock.
-
-Optional Properties:
-- reset-gpios: reference to the GPIO connected to the RSTB pin which is
- active low, if any.
-- powerdown-gpios: reference to the GPIO connected to the PWDN pin which is
- active high, if any.
-
-The device node shall contain one 'port' child node with one child 'endpoint'
-subnode for its digital output video port, in accordance with the video
-interface bindings defined in Documentation/devicetree/bindings/media/
-video-interfaces.txt.
-
-Example:
-
-&i2c0 {
- ov772x: camera@21 {
- compatible = "ovti,ov7725";
- reg = <0x21>;
- reset-gpios = <&axi_gpio_0 0 GPIO_ACTIVE_LOW>;
- powerdown-gpios = <&axi_gpio_0 1 GPIO_ACTIVE_LOW>;
- clocks = <&xclk>;
-
- port {
- ov772x_0: endpoint {
- remote-endpoint = <&vcap1_in0>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
new file mode 100644
index 0000000..1c3879e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
+
+maintainers:
+ - Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+description: |-
+ The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
+ image sensor, which is the latest production derived from Omnivision's CMOS
+ image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
+ @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
+ sensor output is available via CSI-2 serial data output.
+
+properties:
+ compatible:
+ const: ovti,ov02a10
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description:
+ External clock for the sensor.
+ items:
+ - const: eclk
+
+ clock-frequency:
+ description:
+ Frequency of the eclk clock in Hz.
+
+ dovdd-supply:
+ description:
+ Definition of the regulator used as Digital I/O voltage supply.
+
+ avdd-supply:
+ description:
+ Definition of the regulator used as Analog voltage supply.
+
+ dvdd-supply:
+ description:
+ Definition of the regulator used as Digital core voltage supply.
+
+ powerdown-gpios:
+ description:
+ Must be the device tree identifier of the GPIO connected to the
+ PD_PAD pin. This pin is used to place the OV02A10 into standby mode
+ or shutdown mode. As the line needs to be high for the powerdown mode
+ to be active, it should be marked GPIO_ACTIVE_HIGH.
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Must be the device tree identifier of the GPIO connected to the
+ RST_PD pin. If specified, it will be asserted during driver probe.
+ As the line needs to be low for the reset to be active, it should be
+ marked GPIO_ACTIVE_LOW.
+ maxItems: 1
+
+ rotation:
+ description:
+ Definition of the sensor's placement.
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ - 0 # Sensor Mounted Upright
+ - 180 # Sensor Mounted Upside Down
+ default: 0
+
+ # See ../video-interfaces.txt for details
+ port:
+ type: object
+ additionalProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ link-frequencies: true
+ ovti,mipi-clock-voltage:
+ allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ description:
+ Definition of MIPI clock voltage unit. This entry corresponds to
+ the link speed defined by the 'link-frequencies' property.
+ If present, the value shall be in the range of 0-4.
+ default: 4
+ remote-endpoint: true
+
+ required:
+ - link-frequencies
+ - remote-endpoint
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-frequency
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - powerdown-gpios
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov02a10: camera-sensor@3d {
+ compatible = "ovti,ov02a10";
+ reg = <0x3d>;
+
+ powerdown-gpios = <&pio 107 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
+
+ clocks = <&ov02a10_clk>;
+ clock-names = "eclk";
+ clock-frequency = <24000000>;
+
+ rotation = <180>;
+
+ dovdd-supply = <&ov02a10_dovdd>;
+ avdd-supply = <&ov02a10_avdd>;
+ dvdd-supply = <&ov02a10_dvdd>;
+
+ port {
+ wcam_out: endpoint {
+ link-frequencies = /bits/ 64 <390000000>;
+ ovti,mipi-clock-voltage = <3>;
+ remote-endpoint = <&mipi_in_wcam>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
new file mode 100644
index 0000000..43bf749
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov2680.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV2680 CMOS Sensor
+
+maintainers:
+ - Rui Miguel Silva <rmfrfs@gmail.com>
+
+description: |-
+ The OV2680 color sensor is a low voltage, high performance 1/5 inch UXGA (2
+ megapixel) CMOS image sensor that provides a single-chip UXGA (1600 x 1200)
+ camera. It provides full-frame, sub-sampled, or windowed 10-bit images in
+ various formats via the control of the Serial Camera Control Bus (SCCB)
+ interface. The OV2680 has an image array capable of operating at up to 30
+ frames per second (fps) in UXGA resolution.
+
+properties:
+ compatible:
+ const: ovti,ov2680
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xvclk
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+ This corresponds to the hardware pin XSHUTDOWN which is physically
+ active low.
+ maxItems: 1
+
+ dovdd-supply:
+ description:
+ Definition of the regulator used as interface power supply.
+
+ avdd-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+ dvdd-supply:
+ description:
+ Definition of the regulator used as digital power supply.
+
+ port:
+ type: object
+ description:
+ A node containing an output port node with an endpoint definition
+ as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov2680: camera-sensor@36 {
+ compatible = "ovti,ov2680";
+ reg = <0x36>;
+ clocks = <&osc>;
+ clock-names = "xvclk";
+ reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
+
+ dovdd-supply = <&sw2_reg>;
+ dvdd-supply = <&sw2_reg>;
+ avdd-supply = <®_peri_3p15v>;
+
+ port {
+ ov2680_to_mipi: endpoint {
+ remote-endpoint = <&mipi_from_sensor>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
new file mode 100644
index 0000000..6866c2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov772x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV7720/OV7725 CMOS sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo@jmondi.org>
+
+description: |
+ The Omnivision OV7720/OV7725 sensor supports multiple resolutions output,
+ such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also can
+ support the YUV422, RGB565/555/444, GRB422 or raw RGB output formats.
+
+properties:
+ compatible:
+ enum:
+ - ovti,ov7720
+ - ovti,ov7725
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ reset-gpios:
+ description: |
+ Reference to the GPIO connected to the RSTB pin which is active low.
+ maxItems: 1
+
+ powerdown-gpios:
+ description: |
+ Reference to the GPIO connected to the PWDN pin which is active high.
+ maxItems: 1
+
+ port:
+ type: object
+ description: |
+ Video output port. See ../video-interfaces.txt.
+
+ properties:
+ endpoint:
+ type: object
+
+ properties:
+ bus-type:
+ enum: [5, 6]
+
+ bus-width:
+ enum: [8, 10]
+ default: 10
+
+ data-shift:
+ enum: [0, 2]
+ default: 0
+
+ hsync-active:
+ enum: [0, 1]
+ default: 1
+
+ vsync-active:
+ enum: [0, 1]
+ default: 1
+
+ pclk-sample:
+ enum: [0, 1]
+ default: 1
+
+ allOf:
+ - if:
+ properties:
+ bus-type:
+ const: 6
+ then:
+ properties:
+ hsync-active: false
+ vsync-active: false
+
+ - if:
+ properties:
+ bus-width:
+ const: 10
+ then:
+ properties:
+ data-shift:
+ const: 0
+
+ required:
+ - bus-type
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ov772x: camera@21 {
+ compatible = "ovti,ov7725";
+ reg = <0x21>;
+ reset-gpios = <&axi_gpio_0 0 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&axi_gpio_0 1 GPIO_ACTIVE_LOW>;
+ clocks = <&xclk>;
+
+ port {
+ ov772x_0: endpoint {
+ bus-type = <5>;
+ vsync-active = <0>;
+ hsync-active = <0>;
+ pclk-sample = <0>;
+ bus-width = <8>;
+ data-shift = <0>;
+ remote-endpoint = <&vcap1_in0>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt b/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
deleted file mode 100644
index f11f28a..0000000
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
-
-The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
-an active array size of 4224H x 3200V. It is programmable through an I2C
-interface.
-Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
-throughput of 1.2Gbps/lane.
-
-
-Required Properties:
-- compatible: Shall be "sony,imx214".
-- reg: I2C bus address of the device. Depending on how the sensor is wired,
- it shall be <0x10> or <0x1a>;
-- enable-gpios: GPIO descriptor for the enable pin.
-- vdddo-supply: Chip digital IO regulator (1.8V).
-- vdda-supply: Chip analog regulator (2.7V).
-- vddd-supply: Chip digital core regulator (1.12V).
-- clocks: Reference to the xclk clock.
-- clock-frequency: Frequency of the xclk clock.
-
-Optional Properties:
-- flash-leds: See ../video-interfaces.txt
-- lens-focus: See ../video-interfaces.txt
-
-The imx214 device node shall contain one 'port' child node with
-an 'endpoint' subnode. For further reading on port node refer to
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Required Properties on endpoint:
-- data-lanes: check ../video-interfaces.txt
-- link-frequencies: check ../video-interfaces.txt
-- remote-endpoint: check ../video-interfaces.txt
-
-Example:
-
- camera-sensor@1a {
- compatible = "sony,imx214";
- reg = <0x1a>;
- vdddo-supply = <&pm8994_lvs1>;
- vddd-supply = <&camera_vddd_1v12>;
- vdda-supply = <&pm8994_l17>;
- lens-focus = <&ad5820>;
- enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
- clocks = <&mmcc CAMSS_MCLK0_CLK>;
- clock-frequency = <24000000>;
- port {
- imx214_ep: endpoint {
- data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <480000000>;
- remote-endpoint = <&csiphy0_ep>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
new file mode 100644
index 0000000..eb12526
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx214.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony 1/3.06-Inch 13.13MP CMOS Digital Image Sensor
+
+maintainers:
+ - Ricardo Ribalda <ribalda@kernel.org>
+
+description: |
+ The Sony IMX214 is a 1/3.06-inch CMOS active pixel digital image sensor with
+ an active array size of 4224H x 3200V. It is programmable through an I2C
+ interface. Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a
+ maximum throughput of 1.2Gbps/lane.
+
+properties:
+ compatible:
+ const: sony,imx214
+
+ reg:
+ enum:
+ - 0x10
+ - 0x1a
+
+ clocks:
+ description: Reference to the xclk clock.
+ maxItems: 1
+
+ clock-frequency:
+ description: Frequency of the xclk clock in Hz.
+
+ enable-gpios:
+ description: GPIO descriptor for the enable pin.
+ maxItems: 1
+
+ vdddo-supply:
+ description: Chip digital IO regulator (1.8V).
+
+ vdda-supply:
+ description: Chip analog regulator (2.7V).
+
+ vddd-supply:
+ description: Chip digital core regulator (1.12V).
+
+ flash-leds:
+ description: See ../video-interfaces.txt
+
+ lens-focus:
+ description: See ../video-interfaces.txt
+
+ port:
+ type: object
+ description: |
+ Video output port. See ../video-interfaces.txt.
+
+ properties:
+ endpoint:
+ type: object
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: See ../video-interfaces.txt
+ anyOf:
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ description: See ../video-interfaces.txt
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-frequency
+ - enable-gpios
+ - vdddo-supply
+ - vdda-supply
+ - vddd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera-sensor@1a {
+ compatible = "sony,imx214";
+ reg = <0x1a>;
+ vdddo-supply = <&pm8994_lvs1>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdda-supply = <&pm8994_l17>;
+ lens-focus = <&ad5820>;
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+ clocks = <&camera_clk>;
+ clock-frequency = <24000000>;
+
+ port {
+ imx214_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <480000000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
index f697e1a..a66acb2 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
@@ -33,15 +33,12 @@
vana-supply:
description: Sensor 2.8 V analog supply.
- maxItems: 1
vdig-supply:
description: Sensor 1.8 V digital core supply.
- maxItems: 1
vddl-supply:
description: Sensor digital IO 1.2 V supply.
- maxItems: 1
port:
type: object
diff --git a/Documentation/devicetree/bindings/media/imx7-csi.txt b/Documentation/devicetree/bindings/media/imx7-csi.txt
deleted file mode 100644
index d80ceef..0000000
--- a/Documentation/devicetree/bindings/media/imx7-csi.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Freescale i.MX7 CMOS Sensor Interface
-=====================================
-
-csi node
---------
-
-This is device node for the CMOS Sensor Interface (CSI) which enables the chip
-to connect directly to external CMOS image sensors.
-
-Required properties:
-
-- compatible : "fsl,imx7-csi" or "fsl,imx6ul-csi";
-- reg : base address and length of the register set for the device;
-- interrupts : should contain CSI interrupt;
-- clocks : list of clock specifiers, see
- Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
-- clock-names : must contain "mclk";
-
-The device node shall contain one 'port' child node with one child 'endpoint'
-node, according to the bindings defined in:
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-In the following example a remote endpoint is a video multiplexer.
-
-example:
-
- csi: csi@30710000 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- compatible = "fsl,imx7-csi";
- reg = <0x30710000 0x10000>;
- interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CSI_MCLK_ROOT_CLK>;
- clock-names = "mclk";
-
- port {
- csi_from_csi_mux: endpoint {
- remote-endpoint = <&csi_mux_to_csi>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt b/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
deleted file mode 100644
index 71fd74e..0000000
--- a/Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Freescale i.MX7 Mipi CSI2
-=========================
-
-mipi_csi2 node
---------------
-
-This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
-compatible with previous version of Samsung D-phy.
-
-Required properties:
-
-- compatible : "fsl,imx7-mipi-csi2";
-- reg : base address and length of the register set for the device;
-- interrupts : should contain MIPI CSIS interrupt;
-- clocks : list of clock specifiers, see
- Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
-- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
- entries in the clock property;
-- power-domains : a phandle to the power domain, see
- Documentation/devicetree/bindings/power/power_domain.txt for details.
-- reset-names : should include following entry "mrst";
-- resets : a list of phandle, should contain reset entry of
- reset-names;
-- phy-supply : from the generic phy bindings, a phandle to a regulator that
- provides power to MIPI CSIS core;
-
-Optional properties:
-
-- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
- value when this property is not specified is 166 MHz;
-- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
-
-The device node should contain two 'port' child nodes with one child 'endpoint'
-node, according to the bindings defined in:
- Documentation/devicetree/bindings/ media/video-interfaces.txt.
- The following are properties specific to those nodes.
-
-port node
----------
-
-- reg : (required) can take the values 0 or 1, where 0 shall be
- related to the sink port and port 1 shall be the source
- one;
-
-endpoint node
--------------
-
-- data-lanes : (required) an array specifying active physical MIPI-CSI2
- data input lanes and their mapping to logical lanes; this
- shall only be applied to port 0 (sink port), the array's
- content is unused only its length is meaningful,
- in this case the maximum length supported is 2;
-
-example:
-
- mipi_csi: mipi-csi@30750000 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- compatible = "fsl,imx7-mipi-csi2";
- reg = <0x30750000 0x10000>;
- interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_IPG_ROOT_CLK>,
- <&clks IMX7D_MIPI_CSI_ROOT_CLK>,
- <&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
- clock-names = "pclk", "wrap", "phy";
- clock-frequency = <166000000>;
- power-domains = <&pgc_mipi_phy>;
- phy-supply = <®_1p0d>;
- resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
- reset-names = "mrst";
- fsl,csis-hs-settle = <3>;
-
- port@0 {
- reg = <0>;
-
- mipi_from_sensor: endpoint {
- remote-endpoint = <&ov2680_to_mipi>;
- data-lanes = <1>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- mipi_vc0_to_csi_mux: endpoint {
- remote-endpoint = <&csi_mux_from_mipi_vc0>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
new file mode 100644
index 0000000..4e81a47
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX7 CMOS Sensor Interface
+
+maintainers:
+ - Rui Miguel Silva <rmfrfs@gmail.com>
+
+description: |
+ This is device node for the CMOS Sensor Interface (CSI) which enables the
+ chip to connect directly to external CMOS image sensors.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx7-csi
+ - fsl,imx6ul-csi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
+ port:
+ type: object
+ description:
+ A node containing input port nodes with endpoint definitions as documented
+ in Documentation/devicetree/bindings/media/video-interfaces.txt
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx7d-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ csi: csi@30710000 {
+ compatible = "fsl,imx7-csi";
+ reg = <0x30710000 0x10000>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_CSI_MCLK_ROOT_CLK>;
+ clock-names = "mclk";
+
+ port {
+ csi_from_csi_mux: endpoint {
+ remote-endpoint = <&csi_mux_to_csi>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
new file mode 100644
index 0000000..0668332
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX7 Mipi CSI2
+
+maintainers:
+ - Rui Miguel Silva <rmfrfs@gmail.com>
+
+description: |
+ This is the device node for the MIPI CSI-2 receiver core in i.MX7 soc. It is
+ compatible with previous version of samsung d-phy.
+
+properties:
+ compatible:
+ const: fsl,imx7-mipi-csi2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: wrap
+ - const: phy
+
+ power-domains:
+ maxItems: 1
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: mrst
+
+ clock-frequency:
+ description:
+ The IP main (system bus) clock frequency in Hertz
+ default: 166000000
+
+ fsl,csis-hs-settle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Differential receiver (HS-RX) settle time
+
+ ports:
+ type: object
+ description:
+ A node containing input and output port nodes with endpoint definitions
+ as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+ type: object
+ description:
+ Input port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ reg:
+ const: 0
+
+ endpoint:
+ type: object
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: See ../video-interfaces.txt
+ oneOf:
+ - items:
+ - const: 1
+ - items:
+ - const: 1
+ - const: 2
+
+ remote-endpoint: true
+
+ required:
+ - data-lanes
+ - remote-endpoint
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ port@1:
+ type: object
+ description:
+ Output port node
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - phy-supply
+ - resets
+ - reset-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx7d-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/reset/imx7-reset.h>
+
+ mipi_csi: mipi-csi@30750000 {
+ compatible = "fsl,imx7-mipi-csi2";
+ reg = <0x30750000 0x10000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&clks IMX7D_IPG_ROOT_CLK>,
+ <&clks IMX7D_MIPI_CSI_ROOT_CLK>,
+ <&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
+ clock-names = "pclk", "wrap", "phy";
+ clock-frequency = <166000000>;
+
+ power-domains = <&pgc_mipi_phy>;
+ phy-supply = <®_1p0d>;
+ resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
+ reset-names = "mrst";
+ fsl,csis-hs-settle = <3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_from_sensor: endpoint {
+ remote-endpoint = <&ov2680_to_mipi>;
+ data-lanes = <1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_vc0_to_csi_mux: endpoint {
+ remote-endpoint = <&csi_mux_from_mipi_vc0>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt b/Documentation/devicetree/bindings/media/qcom,camss.txt
index 09eb6ed..4982346 100644
--- a/Documentation/devicetree/bindings/media/qcom,camss.txt
+++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
@@ -8,6 +8,7 @@
Definition: Should contain one of:
- "qcom,msm8916-camss"
- "qcom,msm8996-camss"
+ - "qcom,sdm660-camss"
- reg:
Usage: required
Value type: <prop-encoded-array>
@@ -64,30 +65,36 @@
Value type: <stringlist>
Definition: Should contain the following entries:
- "top_ahb"
+ - "throttle_axi" (660 only)
- "ispif_ahb"
- "csiphy0_timer"
- "csiphy1_timer"
- "csiphy2_timer" (8996 only)
+ - "csiphy_ahb2crif" (660 only)
- "csi0_ahb"
- "csi0"
- "csi0_phy"
- "csi0_pix"
- "csi0_rdi"
+ - "cphy_csid0" (660 only)
- "csi1_ahb"
- "csi1"
- "csi1_phy"
- "csi1_pix"
- "csi1_rdi"
+ - "cphy_csid1" (660 only)
- "csi2_ahb" (8996 only)
- "csi2" (8996 only)
- "csi2_phy" (8996 only)
- "csi2_pix" (8996 only)
- "csi2_rdi" (8996 only)
+ - "cphy_csid2" (660 only)
- "csi3_ahb" (8996 only)
- "csi3" (8996 only)
- "csi3_phy" (8996 only)
- "csi3_pix" (8996 only)
- "csi3_rdi" (8996 only)
+ - "cphy_csid3" (660 only)
- "ahb"
- "vfe0"
- "csi_vfe0"
diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml
index 8ad2cba..946441b 100644
--- a/Documentation/devicetree/bindings/media/rc.yaml
+++ b/Documentation/devicetree/bindings/media/rc.yaml
@@ -83,6 +83,7 @@
- rc-it913x-v2
- rc-kaiomy
- rc-khadas
+ - rc-khamsin
- rc-kworld-315u
- rc-kworld-pc150u
- rc-kworld-plus-tv-analog
@@ -102,6 +103,7 @@
- rc-npgtech
- rc-odroid
- rc-pctv-sedna
+ - rc-pine64
- rc-pinnacle-color
- rc-pinnacle-grey
- rc-pinnacle-pctv-hd
diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
new file mode 100644
index 0000000..2004c05
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
@@ -0,0 +1,215 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip-isp1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC Image Signal Processing unit v1
+
+maintainers:
+ - Helen Koike <helen.koike@collabora.com>
+
+description: |
+ Rockchip ISP1 is the Camera interface for the Rockchip series of SoCs
+ which contains image processing, scaling, and compression functions.
+
+properties:
+ compatible:
+ const: rockchip,rk3399-cif-isp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ items:
+ # isp0 and isp1
+ - description: ISP clock
+ - description: ISP AXI clock
+ - description: ISP AHB clock
+ # only for isp1
+ - description: ISP Pixel clock
+
+ clock-names:
+ minItems: 3
+ items:
+ # isp0 and isp1
+ - const: isp
+ - const: aclk
+ - const: hclk
+ # only for isp1
+ - const: pclk_isp
+
+ iommus:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+ description: phandle for the PHY port
+
+ phy-names:
+ const: dphy
+
+ power-domains:
+ maxItems: 1
+
+ # See ./video-interfaces.txt for details
+ ports:
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ port@0:
+ type: object
+ description: connection point for sensors at MIPI-DPHY RX0
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ reg:
+ const: 0
+
+ patternProperties:
+ endpoint:
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ remote-endpoint: true
+
+ required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - iommus
+ - phys
+ - phy-names
+ - power-domains
+ - ports
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3399-cif-isp
+then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 4
+ clock-names:
+ minItems: 3
+ maxItems: 4
+
+additionalProperties: false
+
+examples:
+ - |
+
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/rk3399-power.h>
+
+ parent0: parent {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp0: isp0@ff910000 {
+ compatible = "rockchip,rk3399-cif-isp";
+ reg = <0x0 0xff910000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru SCLK_ISP0>,
+ <&cru ACLK_ISP0_WRAPPER>,
+ <&cru HCLK_ISP0_WRAPPER>;
+ clock-names = "isp", "aclk", "hclk";
+ iommus = <&isp0_mmu>;
+ phys = <&dphy>;
+ phy-names = "dphy";
+ power-domains = <&power RK3399_PD_ISP0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_in_wcam: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&wcam_out>;
+ data-lanes = <1 2>;
+ };
+
+ mipi_in_ucam: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&ucam_out>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
+
+ i2c7: i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wcam: camera@36 {
+ compatible = "ovti,ov5695";
+ reg = <0x36>;
+
+ port {
+ wcam_out: endpoint {
+ remote-endpoint = <&mipi_in_wcam>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+
+ ucam: camera@3c {
+ compatible = "ovti,ov2685";
+ reg = <0x3c>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 3fe778c..c18574b 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -44,6 +44,43 @@
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
+ properties:
+ endpoint:
+ type: object
+
+ properties:
+ bus-type:
+ enum: [5, 6]
+ default: 5
+
+ bus-width:
+ enum: [8, 10, 12, 14]
+ default: 8
+
+ remote-endpoint: true
+
+ allOf:
+ - if:
+ properties:
+ bus-type:
+ const: 6
+
+ then:
+ properties:
+ hsync-active: false
+ vsync-active: false
+ bus-width:
+ enum: [8]
+
+ required:
+ - remote-endpoint
+ - bus-type
+ - pclk-sample
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
required:
- compatible
- reg
@@ -75,6 +112,7 @@
port {
dcmi_0: endpoint {
remote-endpoint = <&ov5640_0>;
+ bus-type = <5>;
bus-width = <8>;
hsync-active = <0>;
vsync-active = <0>;
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
deleted file mode 100644
index dbafffe..0000000
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-SMI (Smart Multimedia Interface) Common
-
-The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
-
-Mediatek SMI have two generations of HW architecture, here is the list
-which generation the SoCs use:
-generation 1: mt2701 and mt7623.
-generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183.
-
-There's slight differences between the two SMI, for generation 2, the
-register which control the iommu port is at each larb's register base. But
-for generation 1, the register is at smi ao base(smi always on register
-base). Besides that, the smi async clock should be prepared and enabled for
-SMI generation 1 to transform the smi clock into emi clock domain, but that is
-not needed for SMI generation 2.
-
-Required properties:
-- compatible : must be one of :
- "mediatek,mt2701-smi-common"
- "mediatek,mt2712-smi-common"
- "mediatek,mt6779-smi-common"
- "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
- "mediatek,mt8167-smi-common"
- "mediatek,mt8173-smi-common"
- "mediatek,mt8183-smi-common"
-- reg : the register and size of the SMI block.
-- power-domains : a phandle to the power domain of this local arbiter.
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
- for generation 2 smi HW as follows:
- - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
- the register.
- - "smi" : It's the clock for transfer data and command.
- They may be the same if both source clocks are the same.
- - "async" : asynchronous clock, it help transform the smi clock into the emi
- clock domain, this clock is only needed by generation 1 smi HW.
- and these 2 option clocks for generation 2 smi HW:
- - "gals0": the path0 clock of GALS(Global Async Local Sync).
- - "gals1": the path1 clock of GALS(Global Async Local Sync).
- Here is the list which has this GALS: mt6779 and mt8183.
-
-Example:
- smi_common: smi@14022000 {
- compatible = "mediatek,mt8173-smi-common";
- reg = <0 0x14022000 0 0x1000>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- clocks = <&mmsys CLK_MM_SMI_COMMON>,
- <&mmsys CLK_MM_SMI_COMMON>;
- clock-names = "apb", "smi";
- };
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
new file mode 100644
index 0000000..a08a323
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMI (Smart Multimedia Interface) Common
+
+maintainers:
+ - Yong Wu <yong.wu@mediatek.com>
+
+description: |
+ The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
+
+ MediaTek SMI have two generations of HW architecture, here is the list
+ which generation the SoCs use:
+ generation 1: mt2701 and mt7623.
+ generation 2: mt2712, mt6779, mt8167, mt8173, mt8183 and mt8192.
+
+ There's slight differences between the two SMI, for generation 2, the
+ register which control the iommu port is at each larb's register base. But
+ for generation 1, the register is at smi ao base(smi always on register
+ base). Besides that, the smi async clock should be prepared and enabled for
+ SMI generation 1 to transform the smi clock into emi clock domain, but that is
+ not needed for SMI generation 2.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-smi-common
+ - mediatek,mt2712-smi-common
+ - mediatek,mt6779-smi-common
+ - mediatek,mt8167-smi-common
+ - mediatek,mt8173-smi-common
+ - mediatek,mt8183-smi-common
+ - mediatek,mt8192-smi-common
+
+ - description: for mt7623
+ items:
+ - const: mediatek,mt7623-smi-common
+ - const: mediatek,mt2701-smi-common
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ description: |
+ apb and smi are mandatory. the async is only for generation 1 smi HW.
+ gals(global async local sync) also is optional, see below.
+ minItems: 2
+ maxItems: 4
+ items:
+ - description: apb is Advanced Peripheral Bus clock, It's the clock for
+ setting the register.
+ - description: smi is the clock for transfer data and command.
+ - description: async is asynchronous clock, it help transform the smi
+ clock into the emi clock domain.
+ - description: gals0 is the path0 clock of gals.
+ - description: gals1 is the path1 clock of gals.
+
+ clock-names:
+ minItems: 2
+ maxItems: 4
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - clocks
+ - clock-names
+
+allOf:
+ - if: # only for gen1 HW
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt2701-smi-common
+ then:
+ properties:
+ clock:
+ items:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: apb
+ - const: smi
+ - const: async
+
+ - if: # for gen2 HW that have gals
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt6779-smi-common
+ - mediatek,mt8183-smi-common
+ - mediatek,mt8192-smi-common
+
+ then:
+ properties:
+ clock:
+ items:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: apb
+ - const: smi
+ - const: gals0
+ - const: gals1
+
+ else: # for gen2 HW that don't have gals
+ properties:
+ clock:
+ items:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: apb
+ - const: smi
+
+additionalProperties: false
+
+examples:
+ - |+
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/power/mt8173-power.h>
+
+ smi_common: smi@14022000 {
+ compatible = "mediatek,mt8173-smi-common";
+ reg = <0x14022000 0x1000>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ clocks = <&mmsys CLK_MM_SMI_COMMON>,
+ <&mmsys CLK_MM_SMI_COMMON>;
+ clock-names = "apb", "smi";
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
deleted file mode 100644
index 0c5de12..0000000
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-SMI (Smart Multimedia Interface) Local Arbiter
-
-The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
-
-Required properties:
-- compatible : must be one of :
- "mediatek,mt2701-smi-larb"
- "mediatek,mt2712-smi-larb"
- "mediatek,mt6779-smi-larb"
- "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb"
- "mediatek,mt8167-smi-larb"
- "mediatek,mt8173-smi-larb"
- "mediatek,mt8183-smi-larb"
-- reg : the register and size of this local arbiter.
-- mediatek,smi : a phandle to the smi_common node.
-- power-domains : a phandle to the power domain of this local arbiter.
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names: must contain 2 entries, as follows:
- - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
- the register.
- - "smi" : It's the clock for transfer data and command.
- and this optional clock name:
- - "gals": the clock for GALS(Global Async Local Sync).
- Here is the list which has this GALS: mt8183.
-
-Required property for mt2701, mt2712, mt6779, mt7623 and mt8167:
-- mediatek,larb-id :the hardware id of this larb.
-
-Example:
- larb1: larb@16010000 {
- compatible = "mediatek,mt8173-smi-larb";
- reg = <0 0x16010000 0 0x1000>;
- mediatek,smi = <&smi_common>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
- clocks = <&vdecsys CLK_VDEC_CKEN>,
- <&vdecsys CLK_VDEC_LARB_CKEN>;
- clock-names = "apb", "smi";
- };
-
-Example for mt2701:
- larb0: larb@14010000 {
- compatible = "mediatek,mt2701-smi-larb";
- reg = <0 0x14010000 0 0x1000>;
- mediatek,smi = <&smi_common>;
- mediatek,larb-id = <0>;
- clocks = <&mmsys CLK_MM_SMI_LARB0>,
- <&mmsys CLK_MM_SMI_LARB0>;
- clock-names = "apb", "smi";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
- };
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
new file mode 100644
index 0000000..7ed7839
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-larb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMI (Smart Multimedia Interface) Local Arbiter
+
+maintainers:
+ - Yong Wu <yong.wu@mediatek.com>
+
+description: |
+ The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-smi-larb
+ - mediatek,mt2712-smi-larb
+ - mediatek,mt6779-smi-larb
+ - mediatek,mt8167-smi-larb
+ - mediatek,mt8173-smi-larb
+ - mediatek,mt8183-smi-larb
+ - mediatek,mt8192-smi-larb
+
+ - description: for mt7623
+ items:
+ - const: mediatek,mt7623-smi-larb
+ - const: mediatek,mt2701-smi-larb
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: |
+ apb and smi are mandatory. gals(global async local sync) is optional.
+ minItems: 2
+ maxItems: 3
+ items:
+ - description: apb is Advanced Peripheral Bus clock, It's the clock for
+ setting the register.
+ - description: smi is the clock for transfer data and command.
+ - description: the clock for gals.
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ power-domains:
+ maxItems: 1
+
+ mediatek,smi:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: a phandle to the smi_common node.
+
+ mediatek,larb-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: the hardware id of this larb. It's only required when this
+ hardward id is not consecutive from its M4U point of view.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+allOf:
+ - if: # HW has gals
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-smi-larb
+
+ then:
+ properties:
+ clock:
+ items:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: apb
+ - const: smi
+ - const: gals
+
+ else:
+ properties:
+ clock:
+ items:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: apb
+ - const: smi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt2701-smi-larb
+ - mediatek,mt2712-smi-larb
+ - mediatek,mt6779-smi-larb
+ - mediatek,mt8167-smi-larb
+ - mediatek,mt8192-smi-larb
+
+ then:
+ required:
+ - mediatek,larb-id
+
+additionalProperties: false
+
+examples:
+ - |+
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/power/mt8173-power.h>
+
+ larb1: larb@16010000 {
+ compatible = "mediatek,mt8173-smi-larb";
+ reg = <0x16010000 0x1000>;
+ mediatek,smi = <&smi_common>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+ clocks = <&vdecsys CLK_VDEC_CKEN>,
+ <&vdecsys CLK_VDEC_LARB_CKEN>;
+ clock-names = "apb", "smi";
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
index 278549f..09bde65 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
@@ -29,11 +29,23 @@
items:
- const: emc
+ "#interconnect-cells":
+ const: 0
+
nvidia,memory-controller:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle of the memory controller node
+ core-supply:
+ description:
+ Phandle of voltage regulator of the SoC "core" power domain.
+
+ operating-points-v2:
+ description:
+ Should contain freqs and voltages and opp-supported-hw property, which
+ is a bitfield indicating SoC speedo ID mask.
+
patternProperties:
"^emc-timings-[0-9]+$":
type: object
@@ -327,6 +339,8 @@
- clocks
- clock-names
- nvidia,memory-controller
+ - "#interconnect-cells"
+ - operating-points-v2
additionalProperties: false
@@ -345,6 +359,7 @@
#iommu-cells = <1>;
#reset-cells = <1>;
+ #interconnect-cells = <1>;
};
external-memory-controller@7001b000 {
@@ -354,6 +369,10 @@
clock-names = "emc";
nvidia,memory-controller = <&mc>;
+ operating-points-v2 = <&dvfs_opp_table>;
+ core-supply = <&vdd_core>;
+
+ #interconnect-cells = <0>;
emc-timings-0 {
nvidia,ram-code = <3>;
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
index 84d0339..7b18b4d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
@@ -40,6 +40,9 @@
"#iommu-cells":
const: 1
+ "#interconnect-cells":
+ const: 1
+
patternProperties:
"^emc-timings-[0-9]+$":
type: object
@@ -104,6 +107,7 @@
- clock-names
- "#reset-cells"
- "#iommu-cells"
+ - "#interconnect-cells"
additionalProperties: false
@@ -119,6 +123,7 @@
#iommu-cells = <1>;
#reset-cells = <1>;
+ #interconnect-cells = <1>;
emc-timings-3 {
nvidia,ram-code = <3>;
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index add95367..cc443fc 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -12,18 +12,44 @@
irrespective of ram-code configuration.
- interrupts : Should contain EMC General interrupt.
- clocks : Should contain EMC clock.
+- nvidia,memory-controller : Phandle of the Memory Controller node.
+- #interconnect-cells : Should be 0.
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: One bitfield indicating SoC process ID mask
+
+ A bitwise AND is performed against this value and if any bit
+ matches, the OPP gets enabled.
+
+Optional properties:
+- core-supply: Phandle of voltage regulator of the SoC "core" power domain.
Child device nodes describe the memory settings for different configurations and clock rates.
Example:
+ opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp@36000000 {
+ opp-microvolt = <950000 950000 1300000>;
+ opp-hz = /bits/ 64 <36000000>;
+ };
+ ...
+ };
+
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
+ #interconnect-cells = <0>;
compatible = "nvidia,tegra20-emc";
- reg = <0x7000f4000 0x200>;
+ reg = <0x7000f400 0x400>;
interrupts = <0 78 0x04>;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
+ nvidia,memory-controller = <&mc>;
+ core-supply = <&core_vdd_reg>;
+ operating-points-v2 = <&opp_table>;
}
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
index e553282..739b7c6 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
@@ -16,6 +16,8 @@
IOMMU specifier needed to encode an address. GART supports only a single
address space that is shared by all devices, therefore no additional
information needed for the address encoding.
+- #interconnect-cells : Should be 1. This cell represents memory client.
+ The assignments may be found in header file <dt-bindings/memory/tegra20-mc.h>.
Example:
mc: memory-controller@7000f000 {
@@ -27,6 +29,7 @@
interrupts = <GIC_SPI 77 0x04>;
#reset-cells = <1>;
#iommu-cells = <0>;
+ #interconnect-cells = <1>;
};
video-codec@6001a000 {
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
index 112bae2..0a2e2c0d0 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
@@ -31,11 +31,23 @@
interrupts:
maxItems: 1
+ "#interconnect-cells":
+ const: 0
+
nvidia,memory-controller:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle of the Memory Controller node.
+ core-supply:
+ description:
+ Phandle of voltage regulator of the SoC "core" power domain.
+
+ operating-points-v2:
+ description:
+ Should contain freqs and voltages and opp-supported-hw property, which
+ is a bitfield indicating SoC speedo ID mask.
+
patternProperties:
"^emc-timings-[0-9]+$":
type: object
@@ -214,6 +226,8 @@
- interrupts
- clocks
- nvidia,memory-controller
+ - "#interconnect-cells"
+ - operating-points-v2
additionalProperties: false
@@ -226,6 +240,10 @@
clocks = <&tegra_car 57>;
nvidia,memory-controller = <&mc>;
+ operating-points-v2 = <&dvfs_opp_table>;
+ core-supply = <&vdd_core>;
+
+ #interconnect-cells = <0>;
emc-timings-1 {
nvidia,ram-code = <1>;
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
index 84fd57b..5436e6d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
@@ -57,6 +57,9 @@
"#iommu-cells":
const: 1
+ "#interconnect-cells":
+ const: 1
+
patternProperties:
"^emc-timings-[0-9]+$":
type: object
@@ -120,6 +123,7 @@
- clock-names
- "#reset-cells"
- "#iommu-cells"
+ - "#interconnect-cells"
additionalProperties: false
@@ -135,6 +139,7 @@
#iommu-cells = <1>;
#reset-cells = <1>;
+ #interconnect-cells = <1>;
emc-timings-1 {
nvidia,ram-code = <1>;
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
index a92acf1..d0a38ba 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
@@ -46,6 +46,7 @@
- compatible: One of:
"aspeed,ast2400-lpc", "simple-mfd"
"aspeed,ast2500-lpc", "simple-mfd"
+ "aspeed,ast2600-lpc", "simple-mfd"
- reg: contains the physical address and length values of the Aspeed
LPC memory region.
@@ -64,6 +65,7 @@
- compatible: One of:
"aspeed,ast2400-lpc-bmc"
"aspeed,ast2500-lpc-bmc"
+ "aspeed,ast2600-lpc-bmc"
- reg: contains the physical address and length values of the
H8S/2168-compatible LPC controller memory region
@@ -74,6 +76,7 @@
- compatible: One of:
"aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
"aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
+ "aspeed,ast2600-lpc-host", "simple-mfd", "syscon"
- reg: contains the address and length values of the host-related
register space for the Aspeed LPC controller
@@ -128,6 +131,7 @@
- compatible: One of:
"aspeed,ast2400-lpc-ctrl";
"aspeed,ast2500-lpc-ctrl";
+ "aspeed,ast2600-lpc-ctrl";
- reg: contains offset/length values of the host interface controller
memory regions
@@ -168,6 +172,7 @@
- compatible: One of:
"aspeed,ast2400-lhc";
"aspeed,ast2500-lhc";
+ "aspeed,ast2600-lhc";
- reg: contains offset/length values of the LHC memory regions. In the
AST2400 and AST2500 there are two regions.
@@ -187,7 +192,8 @@
Required properties:
- - compatible: "aspeed,ast2500-lpc-reset" or
+ - compatible: "aspeed,ast2600-lpc-reset" or
+ "aspeed,ast2500-lpc-reset"
"aspeed,ast2400-lpc-reset"
- reg: offset and length of the IP in the LHC memory region
- #reset-controller indicates the number of reset cells expected
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
index 4d92c0b..857ee33 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
@@ -20,3 +20,29 @@
#clock-cells = <1>;
#reset-cells = <1>;
};
+
+Silicon ID
+-----------------
+
+Families have unique hardware silicon identifiers within the SoC.
+
+Required properties:
+
+ - compatible: "aspeed,silicon-id" or:
+ "aspeed,ast2400-silicon-id" or
+ "aspeed,ast2500-silicon-id" or
+ "aspeed,ast2600-silicon-id"
+
+ - reg: offset and length of the silicon id information
+ optionally, a second offset and length describes the unique chip id
+
+ The reg should be the unique silicon id register, and
+ not backwards compatible one in eg. the 2600.
+
+Example:
+
+
+silicon-id@7c {
+ compatible = "aspeed,ast2500-silicon-id", "aspeed,silicon-id";
+ reg = <0x7c 0x4 0x150 0x8>;
+};
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
index 65018a0..3bfdd33 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
@@ -32,9 +32,15 @@
clocks:
maxItems: 1
+ clock-names:
+ const: osc
+
"#clock-cells":
const: 0
+ clock-output-names:
+ const: pmic_clk
+
# The BD718x7 supports two different HW states as reset target states. States
# are called as SNVS and READY. At READY state all the PMIC power outputs go
# down and OTP is reload. At the SNVS state all other logic and external
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
index f212fc6..0f16c88 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
@@ -131,7 +131,7 @@
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
- timers2: timers@40000000 {
+ timers2: timer@40000000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "st,stm32-timers";
@@ -149,9 +149,9 @@
#pwm-cells = <3>;
st,breakinput = <0 1 5>;
};
- timer@0 {
+ timer@1 {
compatible = "st,stm32-timer-trigger";
- reg = <0>;
+ reg = <1>;
};
counter {
compatible = "st,stm32-timer-counter";
diff --git a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml
index 888ab4b..19e9afb 100644
--- a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml
@@ -26,8 +26,7 @@
drive-open-drain: true
- vdd-supply:
- maxItems: 1
+ vdd-supply: true
pinctrl:
type: object
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 8f4764a..f14ae6d 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -44,6 +44,10 @@
- hisilicon,peri-subctrl
- microchip,sparx5-cpu-syscon
- mstar,msc313-pmsleep
+ - rockchip,px30-qos
+ - rockchip,rk3066-qos
+ - rockchip,rk3288-qos
+ - rockchip,rk3399-qos
- samsung,exynos3-sysreg
- samsung,exynos4-sysreg
- samsung,exynos5-sysreg
diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
index bc817e9..cc916ea 100644
--- a/Documentation/devicetree/bindings/mips/mscc.txt
+++ b/Documentation/devicetree/bindings/mips/mscc.txt
@@ -4,7 +4,7 @@
properties:
Required properties:
-- compatible: "mscc,ocelot"
+- compatible: "mscc,ocelot", "mscc,luton", "mscc,serval" or "mscc,jr2"
* Other peripherals:
diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt
deleted file mode 100644
index 1442ba5..0000000
--- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-DPAA2 console support
-
-Required properties:
-
- - compatible
- Value type: <string>
- Definition: Must be "fsl,dpaa2-console".
- - reg
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the region where the MCFBA
- (MC firmware base address) register can be found.
diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
new file mode 100644
index 0000000..271a3ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/fsl,dpaa2-console.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DPAA2 console support
+
+maintainers:
+ - Laurentiu Tudor <laurentiu.tudor@nxp.com>
+
+properties:
+ compatible:
+ const: "fsl,dpaa2-console"
+
+ reg:
+ description: A standard property. Specifies the region where the MCFBA
+ (MC firmware base address) register can be found.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
index 0753289..37a5fe7 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
@@ -147,7 +147,7 @@
xlnx,mio-bank:
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 2]
+ enum: [0, 1, 2]
default: 0
description:
The MIO bank number in which the command and data lines are configured.
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index e71d13c..802c9df 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -39,6 +39,7 @@
- fsl,imx8mn-usdhc
- fsl,imx8mp-usdhc
- fsl,imx8mq-usdhc
+ - fsl,imx8qm-usdhc
- fsl,imx8qxp-usdhc
- const: fsl,imx7d-usdhc
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
deleted file mode 100644
index 26a8f32..0000000
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-* MTK MMC controller
-
-The MTK MSDC can act as a MMC controller
-to support MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the msdc driver.
-
-Required properties:
-- compatible: value should be either of the following.
- "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
- "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
- "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183
- "mediatek,mt8516-mmc": for mmc host ip compatible with mt8516
- "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779
- "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
- "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
- "mediatek,mt7622-mmc": for MT7622 SoC
- "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
- "mediatek,mt7620-mmc", for MT7621 SoC (and others)
-
-- reg: physical base address of the controller and length
-- interrupts: Should contain MSDC interrupt number
-- clocks: Should contain phandle for the clock feeding the MMC controller
-- clock-names: Should contain the following:
- "source" - source clock (required)
- "hclk" - HCLK which used for host (required)
- "source_cg" - independent source clock gate (required for MT2712)
- "bus_clk" - bus clock used for internal register access (required for MT2712 MSDC0/3)
-- pinctrl-names: should be "default", "state_uhs"
-- pinctrl-0: should contain default/high speed pin ctrl
-- pinctrl-1: should contain uhs mode pin ctrl
-- vmmc-supply: power to the Core
-- vqmmc-supply: power to the IO
-
-Optional properties:
-- assigned-clocks: PLL of the source clock
-- assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
-- hs400-ds-delay: HS400 DS delay setting
-- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
- This field has total 32 stages.
- The value is an integer from 0 to 31.
-- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
- This field has total 32 stages.
- The value is an integer from 0 to 31.
-- mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample selection
- If present,HS400 command responses are sampled on rising edges.
- If not present,HS400 command responses are sampled on falling edges.
-- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct latch-ck to avoid data crc
- error caused by stop clock(fifo full)
- Valid range = [0:0x7]. if not present, default value is 0.
- applied to compatible "mediatek,mt2701-mmc".
-- resets: Phandle and reset specifier pair to softreset line of MSDC IP.
-- reset-names: Should be "hrst".
-
-Examples:
-mmc0: mmc@11230000 {
- compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
- reg = <0 0x11230000 0 0x108>;
- interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_LOW>;
- vmmc-supply = <&mt6397_vemc_3v3_reg>;
- vqmmc-supply = <&mt6397_vio18_reg>;
- clocks = <&pericfg CLK_PERI_MSDC30_0>,
- <&topckgen CLK_TOP_MSDC50_0_H_SEL>;
- clock-names = "source", "hclk";
- pinctrl-names = "default", "state_uhs";
- pinctrl-0 = <&mmc0_pins_default>;
- pinctrl-1 = <&mmc0_pins_uhs>;
- assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
- assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
- hs400-ds-delay = <0x14015>;
- mediatek,hs200-cmd-int-delay = <26>;
- mediatek,hs400-cmd-int-delay = <14>;
- mediatek,hs400-cmd-resp-sel-rising;
-};
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
new file mode 100644
index 0000000..01630b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mtk-sd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTK MSDC Storage Host Controller Binding
+
+maintainers:
+ - Chaotian Jing <chaotian.jing@mediatek.com>
+ - Wenbin Mei <wenbin.mei@mediatek.com>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-mmc
+ - mediatek,mt2712-mmc
+ - mediatek,mt6779-mmc
+ - mediatek,mt7620-mmc
+ - mediatek,mt7622-mmc
+ - mediatek,mt8135-mmc
+ - mediatek,mt8173-mmc
+ - mediatek,mt8183-mmc
+ - mediatek,mt8516-mmc
+ - items:
+ - const: mediatek,mt7623-mmc
+ - const: mediatek,mt2701-mmc
+ - items:
+ - const: mediatek,mt8192-mmc
+ - const: mediatek,mt8183-mmc
+
+ clocks:
+ description:
+ Should contain phandle for the clock feeding the MMC controller.
+ minItems: 2
+ maxItems: 8
+ items:
+ - description: source clock (required).
+ - description: HCLK which used for host (required).
+ - description: independent source clock gate (required for MT2712).
+ - description: bus clock used for internal register access (required for MT2712 MSDC0/3).
+ - description: msdc subsys clock gate (required for MT8192).
+ - description: peripheral bus clock gate (required for MT8192).
+ - description: AXI bus clock gate (required for MT8192).
+ - description: AHB bus clock gate (required for MT8192).
+
+ clock-names:
+ minItems: 2
+ maxItems: 8
+ items:
+ - const: source
+ - const: hclk
+ - const: source_cg
+ - const: bus_clk
+ - const: sys_cg
+ - const: pclk_cg
+ - const: axi_cg
+ - const: ahb_cg
+
+ pinctrl-names:
+ items:
+ - const: default
+ - const: state_uhs
+
+ pinctrl-0:
+ description:
+ should contain default/high speed pin ctrl.
+ maxItems: 1
+
+ pinctrl-1:
+ description:
+ should contain uhs mode pin ctrl.
+ maxItems: 1
+
+ assigned-clocks:
+ description:
+ PLL of the source clock.
+ maxItems: 1
+
+ assigned-clock-parents:
+ description:
+ parent of source clock, used for HS400 mode to get 400Mhz source clock.
+ maxItems: 1
+
+ hs400-ds-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ HS400 DS delay setting.
+ minimum: 0
+ maximum: 0xffffffff
+
+ mediatek,hs200-cmd-int-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ HS200 command internal delay setting.
+ This field has total 32 stages.
+ The value is an integer from 0 to 31.
+ minimum: 0
+ maximum: 31
+
+ mediatek,hs400-cmd-int-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ HS400 command internal delay setting.
+ This field has total 32 stages.
+ The value is an integer from 0 to 31.
+ minimum: 0
+ maximum: 31
+
+ mediatek,hs400-cmd-resp-sel-rising:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ HS400 command response sample selection.
+ If present, HS400 command responses are sampled on rising edges.
+ If not present, HS400 command responses are sampled on falling edges.
+
+ mediatek,latch-ck:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Some SoCs do not support enhance_rx, need set correct latch-ck to avoid
+ data crc error caused by stop clock(fifo full) Valid range = [0:0x7].
+ if not present, default value is 0.
+ applied to compatible "mediatek,mt2701-mmc".
+ minimum: 0
+ maximum: 7
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: hrst
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - vmmc-supply
+ - vqmmc-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt8173-clk.h>
+ mmc0: mmc@11230000 {
+ compatible = "mediatek,mt8173-mmc";
+ reg = <0x11230000 0x1000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_LOW>;
+ vmmc-supply = <&mt6397_vemc_3v3_reg>;
+ vqmmc-supply = <&mt6397_vio18_reg>;
+ clocks = <&pericfg CLK_PERI_MSDC30_0>,
+ <&topckgen CLK_TOP_MSDC50_0_H_SEL>;
+ clock-names = "source", "hclk";
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&mmc0_pins_default>;
+ pinctrl-1 = <&mmc0_pins_uhs>;
+ assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
+ hs400-ds-delay = <0x14015>;
+ mediatek,hs200-cmd-int-delay = <26>;
+ mediatek,hs400-cmd-int-delay = <14>;
+ mediatek,hs400-cmd-resp-sel-rising;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
index b6ab527..b0d81ebe 100644
--- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
@@ -17,7 +17,9 @@
oneOf:
- const: actions,owl-mmc
- items:
- - const: actions,s700-mmc
+ - enum:
+ - actions,s500-mmc
+ - actions,s700-mmc
- const: actions,owl-mmc
reg:
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
index 28ff8c5..9d764e6 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
@@ -9,9 +9,6 @@
maintainers:
- Han Xu <han.xu@nxp.com>
-allOf:
- - $ref: "nand-controller.yaml"
-
description: |
The GPMI nand controller provides an interface to control the NAND
flash chips. The device tree may optionally contain sub-nodes
@@ -58,22 +55,10 @@
clocks:
minItems: 1
maxItems: 5
- items:
- - description: SoC gpmi io clock
- - description: SoC gpmi apb clock
- - description: SoC gpmi bch clock
- - description: SoC gpmi bch apb clock
- - description: SoC per1 bch clock
clock-names:
minItems: 1
maxItems: 5
- items:
- - const: gpmi_io
- - const: gpmi_apb
- - const: gpmi_bch
- - const: gpmi_bch_apb
- - const: per1_bch
fsl,use-minimum-ecc:
type: boolean
@@ -107,6 +92,67 @@
unevaluatedProperties: false
+allOf:
+ - $ref: "nand-controller.yaml"
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx23-gpmi-nand
+ - fsl,imx28-gpmi-nand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: SoC gpmi io clock
+ clock-names:
+ items:
+ - const: gpmi_io
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6q-gpmi-nand
+ - fsl,imx6sx-gpmi-nand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: SoC gpmi io clock
+ - description: SoC gpmi apb clock
+ - description: SoC gpmi bch clock
+ - description: SoC gpmi bch apb clock
+ - description: SoC per1 bch clock
+ clock-names:
+ items:
+ - const: gpmi_io
+ - const: gpmi_apb
+ - const: gpmi_bch
+ - const: gpmi_bch_apb
+ - const: per1_bch
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx7d-gpmi-nand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: SoC gpmi io clock
+ - description: SoC gpmi bch apb clock
+ clock-names:
+ minItems: 2
+ maxItems: 2
+ items:
+ - const: gpmi_io
+ - const: gpmi_bch_apb
+
examples:
- |
nand-controller@8000c000 {
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index 0000000..30e0c66
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+ - $ref: "nand-controller.yaml"
+
+maintainers:
+ - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
+
+properties:
+ compatible:
+ const: intel,lgm-nand
+
+ reg:
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: ebunand
+ - const: hsnand
+ - const: nand_cs0
+ - const: nand_cs1
+ - const: addr_sel0
+ - const: addr_sel1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^nand@[a-f0-9]+$":
+ type: object
+ properties:
+ reg:
+ minimum: 0
+ maximum: 7
+
+ nand-ecc-mode: true
+
+ nand-ecc-algo:
+ const: hw
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - dmas
+ - dma-names
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ nand-controller@e0f00000 {
+ compatible = "intel,lgm-nand";
+ reg = <0xe0f00000 0x100>,
+ <0xe1000000 0x300>,
+ <0xe1400000 0x8000>,
+ <0xe1c00000 0x1000>,
+ <0x17400000 0x4>,
+ <0x17c00000 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+ "addr_sel0", "addr_sel1";
+ clocks = <&cgu0 125>;
+ dmas = <&dma0 8>, <&dma0 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index b29050f..d0e422f 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -46,15 +46,6 @@
description:
Contains the native Ready/Busy IDs.
- nand-ecc-mode:
- description:
- Desired ECC engine, either hardware (most of the time
- embedded in the NAND controller) or software correction
- (Linux will handle the calculations). soft_bch is deprecated
- and should be replaced by soft and nand-ecc-algo.
- $ref: /schemas/types.yaml#/definitions/string
- enum: [none, soft, hw, hw_syndrome, hw_oob_first, on-die]
-
nand-ecc-engine:
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
@@ -171,7 +162,7 @@
nand@0 {
reg = <0>;
- nand-ecc-mode = "soft";
+ nand-use-soft-ecc-engine;
nand-ecc-algo = "bch";
/* controller specific properties */
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
index 4a39698..ead90e8 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -24,137 +24,10 @@
Available bindings are listed in the "partitions" subdirectory.
-Fixed Partitions
-================
-
-Partitions can be represented by sub-nodes of a flash device. This can be used
-on platforms which have strong conventions about which portions of a flash are
-used for what purposes, but which don't use an on-flash partition table such
-as RedBoot.
-
-The partition table should be a subnode of the flash node and should be named
-'partitions'. This node should have the following property:
-- compatible : (required) must be "fixed-partitions"
-Partitions are then defined in subnodes of the partitions node.
+Deprecated: partitions defined in flash node
+============================================
For backwards compatibility partitions as direct subnodes of the flash device are
supported. This use is discouraged.
NOTE: also for backwards compatibility, direct subnodes that have a compatible
string are not considered partitions, as they may be used for other bindings.
-
-#address-cells & #size-cells must both be present in the partitions subnode of the
-flash device. There are two valid values for both:
-<1>: for partitions that require a single 32-bit cell to represent their
- size/address (aka the value is below 4 GiB)
-<2>: for partitions that require two 32-bit cells to represent their
- size/address (aka the value is 4 GiB or greater).
-
-Required properties:
-- reg : The partition's offset and size within the flash
-
-Optional properties:
-- label : The label / name for this partition. If omitted, the label is taken
- from the node name (excluding the unit address).
-- read-only : This parameter, if present, is a hint to Linux that this
- partition should only be mounted read-only. This is usually used for flash
- partitions containing early-boot firmware images or data which should not be
- clobbered.
-- lock : Do not unlock the partition at initialization time (not supported on
- all devices)
-- slc-mode: This parameter, if present, allows one to emulate SLC mode on a
- partition attached to an MLC NAND thus making this partition immune to
- paired-pages corruptions
-
-Examples:
-
-
-flash@0 {
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "u-boot";
- reg = <0x0000000 0x100000>;
- read-only;
- };
-
- uimage@100000 {
- reg = <0x0100000 0x200000>;
- };
- };
-};
-
-flash@1 {
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <2>;
-
- /* a 4 GiB partition */
- partition@0 {
- label = "filesystem";
- reg = <0x00000000 0x1 0x00000000>;
- };
- };
-};
-
-flash@2 {
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <2>;
- #size-cells = <2>;
-
- /* an 8 GiB partition */
- partition@0 {
- label = "filesystem #1";
- reg = <0x0 0x00000000 0x2 0x00000000>;
- };
-
- /* a 4 GiB partition */
- partition@200000000 {
- label = "filesystem #2";
- reg = <0x2 0x00000000 0x1 0x00000000>;
- };
- };
-};
-
-flash@3 {
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "bootloader";
- reg = <0x000000 0x100000>;
- read-only;
- };
-
- firmware@100000 {
- label = "firmware";
- reg = <0x100000 0xe00000>;
- compatible = "brcm,trx";
- };
-
- calibration@f00000 {
- label = "calibration";
- reg = <0xf00000 0x100000>;
- compatible = "fixed-partitions";
- ranges = <0 0xf00000 0x100000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "wifi0";
- reg = <0x000000 0x080000>;
- };
-
- partition@80000 {
- label = "wifi1";
- reg = <0x080000 0x080000>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml
new file mode 100644
index 0000000..6d4a345
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/fixed-partitions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fixed partitions
+
+description: |
+ This binding can be used on platforms which have strong conventions about
+ which portions of a flash are used for what purposes, but which don't use an
+ on-flash partition table such as RedBoot.
+
+ The partition table should be a node named "partitions". Partitions are then
+ defined as subnodes.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ const: fixed-partitions
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+patternProperties:
+ "@[0-9a-f]+$":
+ description: node describing a single flash partition
+ type: object
+
+ properties:
+ reg:
+ description: partition's offset and size within the flash
+ maxItems: 1
+
+ label:
+ description: The label / name for this partition. If omitted, the label
+ is taken from the node name (excluding the unit address).
+
+ read-only:
+ description: This parameter, if present, is a hint that this partition
+ should only be mounted read-only. This is usually used for flash
+ partitions containing early-boot firmware images or data which should
+ not be clobbered.
+ type: boolean
+
+ lock:
+ description: Do not unlock the partition at initialization time (not
+ supported on all devices)
+ type: boolean
+
+ slc-mode:
+ description: This parameter, if present, allows one to emulate SLC mode
+ on a partition attached to an MLC NAND thus making this partition
+ immune to paired-pages corruptions
+ type: boolean
+
+ required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: true
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0000000 0x100000>;
+ read-only;
+ };
+
+ uimage@100000 {
+ reg = <0x0100000 0x200000>;
+ };
+ };
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <2>;
+
+ /* a 4 GiB partition */
+ partition@0 {
+ label = "filesystem";
+ reg = <0x00000000 0x1 0x00000000>;
+ };
+ };
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ /* an 8 GiB partition */
+ partition@0 {
+ label = "filesystem #1";
+ reg = <0x0 0x00000000 0x2 0x00000000>;
+ };
+
+ /* a 4 GiB partition */
+ partition@200000000 {
+ label = "filesystem #2";
+ reg = <0x2 0x00000000 0x1 0x00000000>;
+ };
+ };
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0x000000 0x100000>;
+ read-only;
+ };
+
+ firmware@100000 {
+ compatible = "brcm,trx";
+ label = "firmware";
+ reg = <0x100000 0xe00000>;
+ };
+
+ calibration@f00000 {
+ compatible = "fixed-partitions";
+ label = "calibration";
+ reg = <0xf00000 0x100000>;
+ ranges = <0 0xf00000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "wifi0";
+ reg = <0x000000 0x080000>;
+ };
+
+ partition@80000 {
+ label = "wifi1";
+ reg = <0x080000 0x080000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
index 5c2fba4..5647913 100644
--- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -6,8 +6,12 @@
SoC and it uses ADM DMA
* "qcom,ipq4019-nand" - for QPIC NAND controller v1.4.0 being used in
IPQ4019 SoC and it uses BAM DMA
+ * "qcom,ipq6018-nand" - for QPIC NAND controller v1.5.0 being used in
+ IPQ6018 SoC and it uses BAM DMA
* "qcom,ipq8074-nand" - for QPIC NAND controller v1.5.0 being used in
IPQ8074 SoC and it uses BAM DMA
+ * "qcom,sdx55-nand" - for QPIC NAND controller v2.0.0 being used in
+ SDX55 SoC and it uses BAM DMA
- reg: MMIO address range
- clocks: must contain core clock and always on clock
diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
new file mode 100644
index 0000000..0922536
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/rockchip,nand-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoCs NAND FLASH Controller (NFC)
+
+allOf:
+ - $ref: "nand-controller.yaml#"
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ oneOf:
+ - const: rockchip,px30-nfc
+ - const: rockchip,rk2928-nfc
+ - const: rockchip,rv1108-nfc
+ - items:
+ - const: rockchip,rk3036-nfc
+ - const: rockchip,rk2928-nfc
+ - items:
+ - const: rockchip,rk3308-nfc
+ - const: rockchip,rv1108-nfc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Bus Clock
+ - description: Module Clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: ahb
+ - const: nfc
+
+ assigned-clocks:
+ maxItems: 1
+
+ assigned-clock-rates:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+patternProperties:
+ "^nand@[0-7]$":
+ type: object
+ properties:
+ reg:
+ minimum: 0
+ maximum: 7
+
+ nand-ecc-mode:
+ const: hw
+
+ nand-ecc-step-size:
+ const: 1024
+
+ nand-ecc-strength:
+ enum: [16, 24, 40, 60, 70]
+ description: |
+ The ECC configurations that can be supported are as follows.
+ NFC v600 ECC 16, 24, 40, 60
+ RK2928, RK3066, RK3188
+
+ NFC v622 ECC 16, 24, 40, 60
+ RK3036, RK3128
+
+ NFC v800 ECC 16
+ RK3308, RV1108
+
+ NFC v900 ECC 16, 40, 60, 70
+ RK3326, PX30
+
+ nand-bus-width:
+ const: 8
+
+ rockchip,boot-blks:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ default: 16
+ description:
+ The NFC driver need this information to select ECC
+ algorithms supported by the boot ROM.
+ Only used in combination with 'nand-is-boot-medium'.
+
+ rockchip,boot-ecc-strength:
+ enum: [16, 24, 40, 60, 70]
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ If specified it indicates that a different BCH/ECC setting is
+ supported by the boot ROM.
+ NFC v600 ECC 16, 24
+ RK2928, RK3066, RK3188
+
+ NFC v622 ECC 16, 24, 40, 60
+ RK3036, RK3128
+
+ NFC v800 ECC 16
+ RK3308, RV1108
+
+ NFC v900 ECC 16, 70
+ RK3326, PX30
+
+ Only used in combination with 'nand-is-boot-medium'.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3308-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ nfc: nand-controller@ff4b0000 {
+ compatible = "rockchip,rk3308-nfc",
+ "rockchip,rv1108-nfc";
+ reg = <0xff4b0000 0x4000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru HCLK_NANDC>, <&cru SCLK_NANDC>;
+ clock-names = "ahb", "nfc";
+ assigned-clocks = <&clks SCLK_NANDC>;
+ assigned-clock-rates = <150000000>;
+
+ pinctrl-0 = <&flash_ale &flash_bus8 &flash_cle &flash_csn0
+ &flash_rdn &flash_rdy &flash_wrn>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "rk-nand";
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-step-size = <1024>;
+ nand-ecc-strength = <16>;
+ nand-is-boot-medium;
+ rockchip,boot-blks = <8>;
+ rockchip,boot-ecc-strength = <16>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index c7c9ad4..7f2578d 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -38,7 +38,7 @@
const: stmmaceth
syscon:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the device containing the EMAC or GMAC clock
register
@@ -114,7 +114,7 @@
then:
properties:
allwinner,leds-active-low:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
EPHY LEDs are active low.
@@ -126,7 +126,7 @@
const: allwinner,sun8i-h3-mdio-mux
mdio-parent-bus:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to EMAC MDIO.
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
index 6b057b1..1f133f4 100644
--- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -60,7 +60,7 @@
- const: timing-adjustment
amlogic,tx-delay-ns:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
The internal RGMII TX clock delay (provided by this driver) in
nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
index 13875ea..0d2df30 100644
--- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
+++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
@@ -57,6 +57,7 @@
- const: per
clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
The oscillator frequency driving the flexcan device, filled in by the
boot loader. This property should only be used the used operating system
@@ -99,7 +100,7 @@
by default.
0: clock source 0 (oscillator clock)
1: clock source 1 (peripheral clock)
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint8
default: 1
minimum: 0
maximum: 1
@@ -124,7 +125,7 @@
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
clock-frequency = <200000000>;
- fsl,clk-source = <0>;
+ fsl,clk-source = /bits/ 8 <0>;
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
deleted file mode 100644
index f1487a7..0000000
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ /dev/null
@@ -1,149 +0,0 @@
-Broadcom BCM53xx Ethernet switches
-==================================
-
-Required properties:
-
-- compatible: For external switch chips, compatible string must be exactly one
- of: "brcm,bcm5325"
- "brcm,bcm53115"
- "brcm,bcm53125"
- "brcm,bcm53128"
- "brcm,bcm5365"
- "brcm,bcm5395"
- "brcm,bcm5389"
- "brcm,bcm5397"
- "brcm,bcm5398"
-
- For the BCM11360 SoC, must be:
- "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab" string
-
- For the BCM5310x SoCs with an integrated switch, must be one of:
- "brcm,bcm53010-srab"
- "brcm,bcm53011-srab"
- "brcm,bcm53012-srab"
- "brcm,bcm53018-srab"
- "brcm,bcm53019-srab" and the mandatory "brcm,bcm5301x-srab" string
-
- For the BCM5831X/BCM1140x SoCs with an integrated switch, must be one of:
- "brcm,bcm11404-srab"
- "brcm,bcm11407-srab"
- "brcm,bcm11409-srab"
- "brcm,bcm58310-srab"
- "brcm,bcm58311-srab"
- "brcm,bcm58313-srab" and the mandatory "brcm,omega-srab" string
-
- For the BCM585xx/586XX/88312 SoCs with an integrated switch, must be one of:
- "brcm,bcm58522-srab"
- "brcm,bcm58523-srab"
- "brcm,bcm58525-srab"
- "brcm,bcm58622-srab"
- "brcm,bcm58623-srab"
- "brcm,bcm58625-srab"
- "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
-
- For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
- "brcm,bcm3384-switch"
- "brcm,bcm6328-switch"
- "brcm,bcm6368-switch" and the mandatory "brcm,bcm63xx-switch"
-
-Required properties for BCM585xx/586xx/88312 SoCs:
-
- - reg: a total of 3 register base addresses, the first one must be the
- Switch Register Access block base, the second is the port 5/4 mux
- configuration register and the third one is the SGMII configuration
- and status register base address.
-
- - interrupts: a total of 13 interrupts must be specified, in the following
- order: port 0-5, 7-8 link status change, then the integrated PHY interrupt,
- then the timestamping interrupt and the sleep timer interrupts for ports
- 5,7,8.
-
-Optional properties for BCM585xx/586xx/88312 SoCs:
-
- - reg-names: a total of 3 names matching the 3 base register address, must
- be in the following order:
- "srab"
- "mux_config"
- "sgmii_config"
-
- - interrupt-names: a total of 13 names matching the 13 interrupts specified
- must be in the following order:
- "link_state_p0"
- "link_state_p1"
- "link_state_p2"
- "link_state_p3"
- "link_state_p4"
- "link_state_p5"
- "link_state_p7"
- "link_state_p8"
- "phy"
- "ts"
- "imp_sleep_timer_p5"
- "imp_sleep_timer_p7"
- "imp_sleep_timer_p8"
-
-See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
-required and optional properties.
-
-Examples:
-
-Ethernet switch connected via MDIO to the host, CPU port wired to eth0:
-
- eth0: ethernet@10001000 {
- compatible = "brcm,unimac";
- reg = <0x10001000 0x1000>;
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- mdio0: mdio@10000000 {
- compatible = "brcm,unimac-mdio";
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch0: ethernet-switch@1e {
- compatible = "brcm,bcm53125";
- reg = <30>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port0@0 {
- reg = <0>;
- label = "lan1";
- };
-
- port1@1 {
- reg = <1>;
- label = "lan2";
- };
-
- port5@5 {
- reg = <5>;
- label = "cable-modem";
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- phy-mode = "rgmii-txid";
- };
-
- port8@8 {
- reg = <8>;
- label = "cpu";
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- phy-mode = "rgmii-txid";
- ethernet = <ð0>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
new file mode 100644
index 0000000..c3c9388
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
@@ -0,0 +1,249 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/brcm,b53.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM53xx Ethernet switches
+
+allOf:
+ - $ref: dsa.yaml#
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+description:
+ Broadcom BCM53xx Ethernet switches
+
+properties:
+ compatible:
+ oneOf:
+ - const: brcm,bcm5325
+ - const: brcm,bcm53115
+ - const: brcm,bcm53125
+ - const: brcm,bcm53128
+ - const: brcm,bcm5365
+ - const: brcm,bcm5395
+ - const: brcm,bcm5389
+ - const: brcm,bcm5397
+ - const: brcm,bcm5398
+ - items:
+ - const: brcm,bcm11360-srab
+ - const: brcm,cygnus-srab
+ - items:
+ - enum:
+ - brcm,bcm53010-srab
+ - brcm,bcm53011-srab
+ - brcm,bcm53012-srab
+ - brcm,bcm53018-srab
+ - brcm,bcm53019-srab
+ - const: brcm,bcm5301x-srab
+ - items:
+ - enum:
+ - brcm,bcm11404-srab
+ - brcm,bcm11407-srab
+ - brcm,bcm11409-srab
+ - brcm,bcm58310-srab
+ - brcm,bcm58311-srab
+ - brcm,bcm58313-srab
+ - const: brcm,omega-srab
+ - items:
+ - enum:
+ - brcm,bcm58522-srab
+ - brcm,bcm58523-srab
+ - brcm,bcm58525-srab
+ - brcm,bcm58622-srab
+ - brcm,bcm58623-srab
+ - brcm,bcm58625-srab
+ - brcm,bcm88312-srab
+ - const: brcm,nsp-srab
+ - items:
+ - enum:
+ - brcm,bcm3384-switch
+ - brcm,bcm6328-switch
+ - brcm,bcm6368-switch
+ - const: brcm,bcm63xx-switch
+
+required:
+ - compatible
+ - reg
+
+# BCM585xx/586xx/88312 SoCs
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm58522-srab
+ - brcm,bcm58523-srab
+ - brcm,bcm58525-srab
+ - brcm,bcm58622-srab
+ - brcm,bcm58623-srab
+ - brcm,bcm58625-srab
+ - brcm,bcm88312-srab
+then:
+ properties:
+ reg:
+ minItems: 3
+ maxItems: 3
+ reg-names:
+ items:
+ - const: srab
+ - const: mux_config
+ - const: sgmii_config
+ interrupts:
+ minItems: 13
+ maxItems: 13
+ interrupt-names:
+ items:
+ - const: link_state_p0
+ - const: link_state_p1
+ - const: link_state_p2
+ - const: link_state_p3
+ - const: link_state_p4
+ - const: link_state_p5
+ - const: link_state_p7
+ - const: link_state_p8
+ - const: phy
+ - const: ts
+ - const: imp_sleep_timer_p5
+ - const: imp_sleep_timer_p7
+ - const: imp_sleep_timer_p8
+ required:
+ - interrupts
+else:
+ properties:
+ reg:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@1e {
+ compatible = "brcm,bcm53125";
+ reg = <30>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cable-modem";
+ phy-mode = "rgmii-txid";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+ label = "cpu";
+ phy-mode = "rgmii-txid";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ axi {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ switch@36000 {
+ compatible = "brcm,bcm58623-srab", "brcm,nsp-srab";
+ reg = <0x36000 0x1000>,
+ <0x3f308 0x8>,
+ <0x3f410 0xc>;
+ reg-names = "srab", "mux_config", "sgmii_config";
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "link_state_p0",
+ "link_state_p1",
+ "link_state_p2",
+ "link_state_p3",
+ "link_state_p4",
+ "link_state_p5",
+ "link_state_p7",
+ "link_state_p8",
+ "phy",
+ "ts",
+ "imp_sleep_timer_p5",
+ "imp_sleep_timer_p7",
+ "imp_sleep_timer_p8";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ label = "port0";
+ reg = <0>;
+ };
+
+ port@1 {
+ label = "port1";
+ reg = <1>;
+ };
+
+ port@2 {
+ label = "port2";
+ reg = <2>;
+ };
+
+ port@3 {
+ label = "port3";
+ reg = <3>;
+ };
+
+ port@4 {
+ label = "port4";
+ reg = <4>;
+ };
+
+ port@8 {
+ ethernet = <&amac2>;
+ label = "cpu";
+ reg = <8>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
index a765ceb..8a3494d 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
@@ -20,7 +20,7 @@
properties:
$nodename:
- pattern: "^switch(@.*)?$"
+ pattern: "^(ethernet-)?switch(@.*)?$"
dsa,member:
minItems: 2
@@ -54,7 +54,7 @@
description:
Describes the label associated with this port, which will become
the netdev name
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
link:
description:
@@ -62,13 +62,13 @@
port is used as the outgoing port towards the phandle ports. The
full routing information must be given, not just the one hop
routes to neighbouring switches
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
ethernet:
description:
Should be a phandle to a valid Ethernet device node. This host
device is what the switch port is connected to
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
phy-handle: true
@@ -78,6 +78,10 @@
mac-address: true
+ sfp: true
+
+ managed: true
+
required:
- reg
diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
new file mode 100644
index 0000000..5592f58
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/hirschmann,hellcreek.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hirschmann Hellcreek TSN Switch Device Tree Bindings
+
+allOf:
+ - $ref: dsa.yaml#
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Vivien Didelot <vivien.didelot@gmail.com>
+ - Kurt Kanzenbach <kurt@linutronix.de>
+
+description:
+ The Hellcreek TSN Switch IP is a 802.1Q Ethernet compliant switch. It supports
+ the Precision Time Protocol, Hardware Timestamping as well the Time Aware
+ Shaper.
+
+properties:
+ compatible:
+ items:
+ - const: hirschmann,hellcreek-de1soc-r1
+
+ reg:
+ description:
+ The physical base address and size of TSN and PTP memory base
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: tsn
+ - const: ptp
+
+ leds:
+ type: object
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^led@[01]$":
+ type: object
+ description: Hellcreek leds
+ $ref: ../../leds/common.yaml#
+
+ properties:
+ reg:
+ items:
+ - enum: [0, 1]
+ description: Led number
+
+ label: true
+
+ default-state: true
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ethernet-ports
+ - leds
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ switch0: switch@ff240000 {
+ compatible = "hirschmann,hellcreek-de1soc-r1";
+ reg = <0xff240000 0x1000>,
+ <0xff250000 0x1000>;
+ reg-names = "tsn", "ptp";
+ dsa,member = <0 0>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan0";
+ phy-handle = <&phy1>;
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan1";
+ phy-handle = <&phy2>;
+ };
+ };
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ label = "sync_good";
+ default-state = "on";
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "is_gm";
+ default-state = "off";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt
deleted file mode 100644
index 95e91e8..0000000
--- a/Documentation/devicetree/bindings/net/dsa/ksz.txt
+++ /dev/null
@@ -1,125 +0,0 @@
-Microchip KSZ Series Ethernet switches
-==================================
-
-Required properties:
-
-- compatible: For external switch chips, compatible string must be exactly one
- of the following:
- - "microchip,ksz8765"
- - "microchip,ksz8794"
- - "microchip,ksz8795"
- - "microchip,ksz9477"
- - "microchip,ksz9897"
- - "microchip,ksz9896"
- - "microchip,ksz9567"
- - "microchip,ksz8565"
- - "microchip,ksz9893"
- - "microchip,ksz9563"
- - "microchip,ksz8563"
-
-Optional properties:
-
-- reset-gpios : Should be a gpio specifier for a reset line
-- microchip,synclko-125 : Set if the output SYNCLKO frequency should be set to
- 125MHz instead of 25MHz.
-
-See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
-required and optional properties.
-
-Examples:
-
-Ethernet switch connected via SPI to the host, CPU port wired to eth0:
-
- eth0: ethernet@10001000 {
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- spi1: spi@f8008000 {
- pinctrl-0 = <&pinctrl_spi_ksz>;
- cs-gpios = <&pioC 25 0>;
- id = <1>;
-
- ksz9477: ksz9477@0 {
- compatible = "microchip,ksz9477";
- reg = <0>;
-
- spi-max-frequency = <44000000>;
- spi-cpha;
- spi-cpol;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- label = "lan1";
- };
- port@1 {
- reg = <1>;
- label = "lan2";
- };
- port@2 {
- reg = <2>;
- label = "lan3";
- };
- port@3 {
- reg = <3>;
- label = "lan4";
- };
- port@4 {
- reg = <4>;
- label = "lan5";
- };
- port@5 {
- reg = <5>;
- label = "cpu";
- ethernet = <ð0>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
- };
- };
- ksz8565: ksz8565@0 {
- compatible = "microchip,ksz8565";
- reg = <0>;
-
- spi-max-frequency = <44000000>;
- spi-cpha;
- spi-cpol;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- label = "lan1";
- };
- port@1 {
- reg = <1>;
- label = "lan2";
- };
- port@2 {
- reg = <2>;
- label = "lan3";
- };
- port@3 {
- reg = <3>;
- label = "lan4";
- };
- port@6 {
- reg = <6>;
- label = "cpu";
- ethernet = <ð0>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
new file mode 100644
index 0000000..9f7d131
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/microchip,ksz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip KSZ Series Ethernet switches
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+ - Woojung Huh <Woojung.Huh@microchip.com>
+
+allOf:
+ - $ref: dsa.yaml#
+
+properties:
+ # See Documentation/devicetree/bindings/net/dsa/dsa.yaml for a list of additional
+ # required and optional properties.
+ compatible:
+ enum:
+ - microchip,ksz8765
+ - microchip,ksz8794
+ - microchip,ksz8795
+ - microchip,ksz9477
+ - microchip,ksz9897
+ - microchip,ksz9896
+ - microchip,ksz9567
+ - microchip,ksz8565
+ - microchip,ksz9893
+ - microchip,ksz9563
+ - microchip,ksz8563
+
+ reset-gpios:
+ description:
+ Should be a gpio specifier for a reset line.
+ maxItems: 1
+
+ microchip,synclko-125:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Set if the output SYNCLKO frequency should be set to 125MHz instead of 25MHz.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ // Ethernet switch connected via SPI to the host, CPU port wired to eth0:
+ eth0 {
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ spi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-0 = <&pinctrl_spi_ksz>;
+ cs-gpios = <&pioC 25 0>;
+ id = <1>;
+
+ ksz9477: switch@0 {
+ compatible = "microchip,ksz9477";
+ reg = <0>;
+ reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+
+ spi-max-frequency = <44000000>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ port@4 {
+ reg = <4>;
+ label = "lan5";
+ };
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
+ ksz8565: switch@1 {
+ compatible = "microchip,ksz8565";
+ reg = <1>;
+
+ spi-max-frequency = <44000000>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index fdf7098..0965f65 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -16,7 +16,7 @@
local-mac-address:
description:
Specifies the MAC address that was assigned to the network device.
- $ref: /schemas/types.yaml#definitions/uint8-array
+ $ref: /schemas/types.yaml#/definitions/uint8-array
items:
- minItems: 6
maxItems: 6
@@ -27,20 +27,20 @@
program; should be used in cases where the MAC address assigned
to the device by the boot program is different from the
local-mac-address property.
- $ref: /schemas/types.yaml#definitions/uint8-array
+ $ref: /schemas/types.yaml#/definitions/uint8-array
items:
- minItems: 6
maxItems: 6
max-frame-size:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Maximum transfer unit (IEEE defined MTU), rather than the
maximum frame size (there\'s contradiction in the Devicetree
Specification).
max-speed:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Specifies maximum speed in Mbit/s supported by the device.
@@ -95,12 +95,13 @@
# 10GBASE-KR, XFI, SFI
- 10gbase-kr
- usxgmii
+ - 10gbase-r
phy-mode:
$ref: "#/properties/phy-connection-type"
phy-handle:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Specifies a reference to a node representing a PHY device.
@@ -113,7 +114,7 @@
deprecated: true
rx-fifo-depth:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
The size of the controller\'s receive fifo in bytes. This is used
for components that can have configurable receive fifo sizes,
@@ -128,12 +129,12 @@
If this property is present then the MAC applies the RX delay.
sfp:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Specifies a reference to a node representing a SFP cage.
tx-fifo-depth:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
The size of the controller\'s transmit fifo in bytes. This
is used for components that can have configurable fifo sizes.
@@ -149,7 +150,7 @@
description:
Specifies the PHY management type. If auto is set and fixed-link
is not specified, it uses MDIO for management.
- $ref: /schemas/types.yaml#definitions/string
+ $ref: /schemas/types.yaml#/definitions/string
default: auto
enum:
- auto
@@ -197,17 +198,17 @@
speed:
description:
Link speed.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [10, 100, 1000]
full-duplex:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Indicates that full-duplex is used. When absent, half
duplex is assumed.
asym-pause:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Indicates that asym_pause should be enabled.
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 6dd72fa..2766fe4 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -78,57 +78,57 @@
Maximum PHY supported speed in Mbits / seconds.
broken-turn-around:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
If set, indicates the PHY device does not correctly release
the turn around line low at end of the control phase of the
MDIO transaction.
enet-phy-lane-swap:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
If set, indicates the PHY will swap the TX/RX lanes to
compensate for the board being designed with the lanes
swapped.
eee-broken-100tx:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
eee-broken-1000t:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
eee-broken-10gt:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
eee-broken-1000kx:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
eee-broken-10gkx4:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
eee-broken-10gkr:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
phy-is-integrated:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
If set, indicates that the PHY is integrated into the same
physical package as the Ethernet MAC. If needed, muxers
@@ -158,7 +158,7 @@
this property is missing the delay will be skipped.
sfp:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Specifies a reference to a node representing a SFP cage.
diff --git a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
new file mode 100644
index 0000000..7f620a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,qoriq-mc-dpmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DPAA2 MAC bindings
+
+maintainers:
+ - Ioana Ciornei <ioana.ciornei@nxp.com>
+
+description:
+ This binding represents the DPAA2 MAC objects found on the fsl-mc bus and
+ located under the 'dpmacs' node for the fsl-mc bus DTS node.
+
+allOf:
+ - $ref: "ethernet-controller.yaml#"
+
+properties:
+ compatible:
+ const: fsl,qoriq-mc-dpmac
+
+ reg:
+ maxItems: 1
+ description: The DPMAC number
+
+ phy-handle: true
+
+ phy-connection-type: true
+
+ phy-mode: true
+
+ pcs-handle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A reference to a node representing a PCS PHY device found on
+ the internal MDIO bus.
+
+ managed: true
+
+required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ dpmacs {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@4 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0x4>;
+ phy-handle = <&mdio1_phy6>;
+ phy-connection-type = "qsgmii";
+ managed = "in-band-status";
+ pcs-handle = <&pcs3_1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt b/Documentation/devicetree/bindings/net/ftgmac100.txt
index f878c11..2923402 100644
--- a/Documentation/devicetree/bindings/net/ftgmac100.txt
+++ b/Documentation/devicetree/bindings/net/ftgmac100.txt
@@ -15,6 +15,7 @@
- interrupts: Should contain ethernet controller interrupt
Optional properties:
+- phy-handle: See ethernet.txt file in the same directory.
- phy-mode: See ethernet.txt file in the same directory. If the property is
absent, "rgmii" is assumed. Supported values are "rgmii*" and "rmii" for
aspeed parts. Other (unknown) parts will accept any value.
@@ -32,6 +33,9 @@
- "MACCLK": The MAC IP clock
- "RCLK": Clock gate for the RMII RCLK
+Optional subnodes:
+- mdio: See mdio.txt file in the same directory.
+
Example:
mac0: ethernet@1e660000 {
@@ -40,3 +44,24 @@
interrupts = <2>;
use-ncsi;
};
+
+Example with phy-handle:
+
+ mac1: ethernet@1e680000 {
+ compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
+ reg = <0x1e680000 0x180>;
+ interrupts = <2>;
+
+ phy-handle = <&phy>;
+ phy-mode = "rgmii";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 0b61a90..a4d547e 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -7,8 +7,6 @@
Use "cdns,sam9x60-macb" for Microchip sam9x60 SoC.
Use "cdns,np4-macb" for NP4 SoC devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
- Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
- the Cadence GEM, or the generic form: "cdns,gem".
Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 SoCs.
Use "atmel,sama5d3-macb" for the 10/100Mbit IP available on Atmel sama5d3 SoCs.
Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs.
@@ -16,6 +14,8 @@
Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC.
Use "sifive,fu540-c000-gem" for SiFive FU540-C000 SoC.
+ Use "microchip,sama7g5-emac" for Microchip SAMA7G5 ethernet interface.
+ Use "microchip,sama7g5-gem" for Microchip SAMA7G5 gigabit ethernet interface.
Or the generic form: "cdns,emac".
- reg: Address and length of the register set for the device
For "sifive,fu540-c000-gem", second range is required to specify the
diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml
index e811e0f..08e15fb 100644
--- a/Documentation/devicetree/bindings/net/mdio.yaml
+++ b/Documentation/devicetree/bindings/net/mdio.yaml
@@ -70,7 +70,7 @@
The ID number for the device.
broken-turn-around:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
If set, indicates the MDIO device does not correctly release
the turn around line low at end of the control phase of the
diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
index 0bbd598..e6a5ff2 100644
--- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
@@ -42,7 +42,7 @@
- const: trans
mediatek,pericfg:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the device containing the PERICFG register range. This is used
to control the MII mode.
diff --git a/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt b/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt
index 9e4dc51..285a37c2 100644
--- a/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt
+++ b/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt
@@ -6,11 +6,11 @@
- reg: address on the bus
- interrupts: GPIO interrupt to which the chip is connected
- enable-gpios: Output GPIO pin used for enabling/disabling the chip
-- firmware-gpios: Output GPIO pin used to enter firmware download mode
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
+- firmware-gpios: Output GPIO pin used to enter firmware download mode
Example (for ARM-based BeagleBone with NPC100 NFC controller on I2C2):
diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
index cb0b8a5..477066e 100644
--- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
@@ -12,7 +12,9 @@
properties:
compatible:
- const: samsung,s3fwrn5-i2c
+ enum:
+ - samsung,s3fwrn5-i2c
+ - samsung,s3fwrn82
en-gpios:
maxItems: 1
@@ -47,10 +49,19 @@
required:
- compatible
- en-gpios
- - interrupts
- - reg
- wake-gpios
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,s3fwrn5-i2c
+ then:
+ required:
+ - interrupts
+ - reg
+
examples:
- |
#include <dt-bindings/gpio/gpio.h>
@@ -65,9 +76,23 @@
reg = <0x27>;
interrupt-parent = <&gpa1>;
- interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
en-gpios = <&gpf1 4 GPIO_ACTIVE_HIGH>;
wake-gpios = <&gpj0 2 GPIO_ACTIVE_HIGH>;
};
};
+ # UART example on Raspberry Pi
+ - |
+ uart0 {
+ status = "okay";
+
+ nfc {
+ compatible = "samsung,s3fwrn82";
+
+ en-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
+
+ status = "okay";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index 4d8464b..8a2d126 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -114,14 +114,13 @@
validating firwmare used by the GSI.
modem-remoteproc:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
This defines the phandle to the remoteproc node representing
the modem subsystem. This is requied so the IPA driver can
receive and act on notifications of modem up/down events.
memory-region:
- $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
description:
If present, a phandle for a reserved memory area that holds
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 11a6fdb..b2f6083 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -126,7 +126,7 @@
in a different mode than the PHY in order to function.
snps,axi-config:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
AXI BUS Mode parameters. Phandle to a node that can contain the
following properties
@@ -141,7 +141,7 @@
* snps,rb, rebuild INCRx Burst
snps,mtl-rx-config:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Multiple RX Queues parameters. Phandle to a node that can
contain the following properties
@@ -164,7 +164,7 @@
* snps,priority, RX queue priority (Range 0x0 to 0xF)
snps,mtl-tx-config:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Multiple TX Queues parameters. Phandle to a node that can
contain the following properties
@@ -198,7 +198,7 @@
snps,reset-active-low:
deprecated: true
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Indicates that the PHY Reset is active low
@@ -208,55 +208,55 @@
Triplet of delays. The 1st cell is reset pre-delay in micro
seconds. The 2nd cell is reset pulse in micro seconds. The 3rd
cell is reset post-delay in micro seconds.
- $ref: /schemas/types.yaml#definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 3
maxItems: 3
snps,aal:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Use Address-Aligned Beats
snps,fixed-burst:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Program the DMA to use the fixed burst mode
snps,mixed-burst:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Program the DMA to use the mixed burst mode
snps,force_thresh_dma_mode:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Force DMA to use the threshold mode for both tx and rx
snps,force_sf_dma_mode:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Force DMA to use the Store and Forward mode for both tx and
rx. This flag is ignored if force_thresh_dma_mode is set.
snps,en-tx-lpi-clockgating:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Enable gating of the MAC TX clock during TX low-power mode
snps,multicast-filter-bins:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Number of multicast filter hash bins supported by this device
instance
snps,perfect-filter-entries:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Number of perfect filter entries supported by this device
instance
snps,ps-speed:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Port selection speed that can be passed to the core when PCS
is supported. For example, this is used in case of SGMII and
@@ -307,25 +307,25 @@
snps,pbl:
description:
Programmable Burst Length (tx and rx)
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4, 8]
snps,txpbl:
description:
Tx Programmable Burst Length. If set, DMA tx will use this
value rather than snps,pbl.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4, 8]
snps,rxpbl:
description:
Rx Programmable Burst Length. If set, DMA rx will use this
value rather than snps,pbl.
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4, 8]
snps,no-pbl-x8:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
rev < 3.50, don\'t multiply the values by 4.
@@ -351,7 +351,7 @@
then:
properties:
snps,tso:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Enables the TSO feature otherwise it will be managed by
MAC HW capability register.
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
index cbacc04..8a03a24 100644
--- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
+++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
@@ -64,7 +64,7 @@
- const: ether # for others
socionext,syscon-phy-mode:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
A phandle to syscon with one argument that configures phy mode.
The argument is the ID of MAC instance.
diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
index dadeb8f..07a00f5 100644
--- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
+++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
@@ -70,7 +70,7 @@
pinctrl-names: true
syscon:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the system control device node which provides access to
efuse IO range with MAC addresses
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
index 4050a36..047d757 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -47,31 +47,31 @@
takes precedence.
tx-fifo-depth:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Transmitt FIFO depth see dt-bindings/net/ti-dp83867.h for values
rx-fifo-depth:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Receive FIFO depth see dt-bindings/net/ti-dp83867.h for values
ti,clk-output-sel:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h
for applicable values. The CLK_OUT pin can also be disabled by this
property. When omitted, the PHY's default will be left as is.
ti,rx-internal-delay:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h
for applicable values. Required only if interface type is
PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID.
ti,tx-internal-delay:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h
for applicable values. Required only if interface type is
@@ -101,7 +101,7 @@
ti,fifo-depth:
deprecated: true
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable
values.
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
index c3235f0..70a1209 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -44,22 +44,22 @@
to a maximum value (70 ohms).
tx-fifo-depth:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Transmitt FIFO depth see dt-bindings/net/ti-dp83869.h for values
rx-fifo-depth:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Receive FIFO depth see dt-bindings/net/ti-dp83869.h for values
ti,clk-output-sel:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Muxing option for CLK_OUT pin see dt-bindings/net/ti-dp83869.h for values.
ti,op-mode:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Operational mode for the PHY. If this is not set then the operational
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index 227270c..c47b58f 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -119,12 +119,12 @@
description: label associated with this port
ti,mac-only:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Specifies the port works in mac-only mode.
ti,syscon-efuse:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
Phandle to the system control device node which provides access
to efuse IO range with MAC addresses
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
index 4b365c9..85c2f69 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
@@ -136,7 +136,7 @@
- const: tcl2host-status-ring
qcom,rproc:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
DT entry of q6v5-wcss remoteproc driver.
Phandle to a node that can contain the following properties
@@ -144,6 +144,12 @@
* reg
* reg-names
+ qcom,ath11k-calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ string to uniquely identify variant of the calibration data in the
+ board-2.bin for designs with colliding bus and device specific ids
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
index 0668c45..ef93c3b 100644
--- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
+++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
@@ -7,6 +7,7 @@
"mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
"mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
"mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
+ "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516
- reg: Should contain registers location and length
= Data cells =
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 1a18b6b..992777c 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -14,7 +14,18 @@
properties:
compatible:
- const: qcom,qfprom
+ items:
+ - enum:
+ - qcom,apq8064-qfprom
+ - qcom,apq8084-qfprom
+ - qcom,msm8974-qfprom
+ - qcom,msm8916-qfprom
+ - qcom,msm8996-qfprom
+ - qcom,msm8998-qfprom
+ - qcom,qcs404-qfprom
+ - qcom,sc7180-qfprom
+ - qcom,sdm845-qfprom
+ - const: qcom,qfprom
reg:
# If the QFPROM is read-only OS image then only the corrected region
@@ -60,7 +71,7 @@
#size-cells = <2>;
efuse@784000 {
- compatible = "qcom,qfprom";
+ compatible = "qcom,sc7180-qfprom", "qcom,qfprom";
reg = <0 0x00784000 0 0x8ff>,
<0 0x00780000 0 0x7a0>,
<0 0x00782000 0 0x100>,
@@ -85,7 +96,7 @@
#size-cells = <2>;
efuse@784000 {
- compatible = "qcom,qfprom";
+ compatible = "qcom,sdm845-qfprom", "qcom,qfprom";
reg = <0 0x00784000 0 0x8ff>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 9847dfe..08b3da4 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -65,7 +65,9 @@
- OPP nodes: One or more OPP nodes describing voltage-current-frequency
combinations. Their name isn't significant but their phandle can be used to
- reference an OPP.
+ reference an OPP. These are mandatory except for the case where the OPP table
+ is present only to indicate dependency between devices using the opp-shared
+ property.
Optional properties:
- opp-shared: Indicates that device nodes using this OPP Table Node's phandle
@@ -568,3 +570,53 @@
};
};
};
+
+Example 7: Single cluster Quad-core ARM cortex A53, OPP points from firmware,
+distinct clock controls but two sets of clock/voltage/current lines.
+
+/ {
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x100>;
+ next-level-cache = <&A53_L2>;
+ clocks = <&dvfs_controller 0>;
+ operating-points-v2 = <&cpu_opp0_table>;
+ };
+ cpu@1 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x101>;
+ next-level-cache = <&A53_L2>;
+ clocks = <&dvfs_controller 1>;
+ operating-points-v2 = <&cpu_opp0_table>;
+ };
+ cpu@2 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x102>;
+ next-level-cache = <&A53_L2>;
+ clocks = <&dvfs_controller 2>;
+ operating-points-v2 = <&cpu_opp1_table>;
+ };
+ cpu@3 {
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x103>;
+ next-level-cache = <&A53_L2>;
+ clocks = <&dvfs_controller 3>;
+ operating-points-v2 = <&cpu_opp1_table>;
+ };
+
+ };
+
+ cpu_opp0_table: opp0_table {
+ compatible = "operating-points-v2";
+ opp-shared;
+ };
+
+ cpu_opp1_table: opp1_table {
+ compatible = "operating-points-v2";
+ opp-shared;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
index 60b8baf..21e8a88 100644
--- a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
@@ -20,7 +20,4 @@
maximum: 32
default: 32
-required:
- - cdns,max-outbound-regions
-
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 02bc81b..3b55310 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -13,6 +13,7 @@
- "qcom,pcie-ipq8074" for ipq8074
- "qcom,pcie-qcs404" for qcs404
- "qcom,pcie-sdm845" for sdm845
+ - "qcom,pcie-sm8250" for sm8250
- reg:
Usage: required
@@ -27,6 +28,7 @@
- "dbi" DesignWare PCIe registers
- "elbi" External local bus interface registers
- "config" PCIe configuration space
+ - "atu" ATU address space (optional)
- device_type:
Usage: required
@@ -131,7 +133,7 @@
- "slave_bus" AXI Slave clock
-clock-names:
- Usage: required for sdm845
+ Usage: required for sdm845 and sm8250
Value type: <stringlist>
Definition: Should contain the following entries
- "aux" Auxiliary clock
@@ -206,7 +208,7 @@
- "ahb" AHB reset
- reset-names:
- Usage: required for sdm845
+ Usage: required for sdm845 and sm8250
Value type: <stringlist>
Definition: Should contain the following entries
- "pci" PCIe core reset
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
index 84eeb7f..295840c 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
@@ -32,6 +32,10 @@
- const: memory2
- const: memory3
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
power-domains:
maxItems: 1
@@ -53,6 +57,7 @@
- compatible
- reg
- reg-names
+ - interrupts
- resets
- power-domains
- clocks
@@ -64,6 +69,7 @@
examples:
- |
#include <dt-bindings/clock/r8a774c0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a774c0-sysc.h>
pcie0_ep: pcie-ep@fe000000 {
@@ -75,6 +81,9 @@
<0x30000000 0x8000000>,
<0x38000000 0x8000000>;
reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
resets = <&cpg 319>;
power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>;
clocks = <&cpg CPG_MOD 319>;
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
new file mode 100644
index 0000000..4a2bcc0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rcar-pci-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car PCIe Host
+
+maintainers:
+ - Marek Vasut <marek.vasut+renesas@gmail.com>
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+allOf:
+ - $ref: pci-bus.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,pcie-r8a7742 # RZ/G1H
+ - renesas,pcie-r8a7743 # RZ/G1M
+ - renesas,pcie-r8a7744 # RZ/G1N
+ - renesas,pcie-r8a7790 # R-Car H2
+ - renesas,pcie-r8a7791 # R-Car M2-W
+ - renesas,pcie-r8a7793 # R-Car M2-N
+ - const: renesas,pcie-rcar-gen2 # R-Car Gen2 and RZ/G1
+ - items:
+ - enum:
+ - renesas,pcie-r8a774a1 # RZ/G2M
+ - renesas,pcie-r8a774b1 # RZ/G2N
+ - renesas,pcie-r8a774c0 # RZ/G2E
+ - renesas,pcie-r8a774e1 # RZ/G2H
+ - renesas,pcie-r8a7795 # R-Car H3
+ - renesas,pcie-r8a7796 # R-Car M3-W
+ - renesas,pcie-r8a77961 # R-Car M3-W+
+ - renesas,pcie-r8a77965 # R-Car M3-N
+ - renesas,pcie-r8a77980 # R-Car V3H
+ - renesas,pcie-r8a77990 # R-Car E3
+ - const: renesas,pcie-rcar-gen3 # R-Car Gen3 and RZ/G2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: pcie
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7791-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a7791-sysc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie: pcie@fe000000 {
+ compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2";
+ reg = <0 0xfe000000 0 0x80000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000>,
+ <0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000>,
+ <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>,
+ <0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+ dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>,
+ <0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 319>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
deleted file mode 100644
index 14d307d..0000000
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-* Renesas R-Car PCIe interface
-
-Required properties:
-compatible: "renesas,pcie-r8a7742" for the R8A7742 SoC;
- "renesas,pcie-r8a7743" for the R8A7743 SoC;
- "renesas,pcie-r8a7744" for the R8A7744 SoC;
- "renesas,pcie-r8a774a1" for the R8A774A1 SoC;
- "renesas,pcie-r8a774b1" for the R8A774B1 SoC;
- "renesas,pcie-r8a774c0" for the R8A774C0 SoC;
- "renesas,pcie-r8a7779" for the R8A7779 SoC;
- "renesas,pcie-r8a7790" for the R8A7790 SoC;
- "renesas,pcie-r8a7791" for the R8A7791 SoC;
- "renesas,pcie-r8a7793" for the R8A7793 SoC;
- "renesas,pcie-r8a7795" for the R8A7795 SoC;
- "renesas,pcie-r8a7796" for the R8A77960 SoC;
- "renesas,pcie-r8a77961" for the R8A77961 SoC;
- "renesas,pcie-r8a77980" for the R8A77980 SoC;
- "renesas,pcie-r8a77990" for the R8A77990 SoC;
- "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or
- RZ/G1 compatible device.
- "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 or
- RZ/G2 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: base address and length of the PCIe controller registers.
-- #address-cells: set to <3>
-- #size-cells: set to <2>
-- bus-range: PCI bus numbers covered
-- device_type: set to "pci"
-- ranges: ranges for the PCI memory and I/O regions.
-- dma-ranges: ranges for the inbound memory regions.
-- interrupts: two interrupt sources for MSI interrupts, followed by interrupt
- source for hardware related interrupts (e.g. link speed change).
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map: standard PCI properties
- to define the mapping of the PCIe interface to interrupt numbers.
-- clocks: from common clock binding: clock specifiers for the PCIe controller
- and PCIe bus clocks.
-- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
-
-Optional properties:
-- phys: from common PHY binding: PHY phandle and specifier (only make sense
- for R-Car gen3 SoCs where the PCIe PHYs have their own register blocks).
-- phy-names: from common PHY binding: should be "pcie".
-
-Example:
-
-SoC-specific DT Entry:
-
- pcie: pcie@fe000000 {
- compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2";
- reg = <0 0xfe000000 0 0x80000>;
- #address-cells = <3>;
- #size-cells = <2>;
- bus-range = <0x00 0xff>;
- device_type = "pci";
- ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
- 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
- 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
- 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
- dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000
- 0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
- interrupts = <0 116 4>, <0 117 4>, <0 118 4>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 116 4>;
- clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
- clock-names = "pcie", "pcie_bus";
- };
diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
new file mode 100644
index 0000000..1810bf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/samsung,exynos-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series PCIe Host Controller Device Tree Bindings
+
+maintainers:
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+ - Jaehoon Chung <jh80.chung@samsung.com>
+
+description: |+
+ Exynos5433 SoC PCIe host controller is based on the Synopsys DesignWare
+ PCIe IP and thus inherits all the common properties defined in
+ designware-pcie.txt.
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+ compatible:
+ const: samsung,exynos5433-pcie
+
+ reg:
+ items:
+ - description: Data Bus Interface (DBI) registers.
+ - description: External Local Bus interface (ELBI) registers.
+ - description: PCIe configuration space region.
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: elbi
+ - const: config
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PCIe bridge clock
+ - description: PCIe bus clock
+
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+
+ phys:
+ maxItems: 1
+
+ vdd10-supply:
+ description:
+ Phandle to a regulator that provides 1.0V power to the PCIe block.
+
+ vdd18-supply:
+ description:
+ Phandle to a regulator that provides 1.8V power to the PCIe block.
+
+ num-lanes:
+ const: 1
+
+ num-viewport:
+ const: 3
+
+required:
+ - reg
+ - reg-names
+ - interrupts
+ - "#address-cells"
+ - "#size-cells"
+ - "#interrupt-cells"
+ - interrupt-map
+ - interrupt-map-mask
+ - ranges
+ - bus-range
+ - device_type
+ - num-lanes
+ - num-viewport
+ - clocks
+ - clock-names
+ - phys
+ - vdd10-supply
+ - vdd18-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/exynos5433.h>
+
+ pcie: pcie@15700000 {
+ compatible = "samsung,exynos5433-pcie";
+ reg = <0x15700000 0x1000>, <0x156b0000 0x1000>, <0x0c000000 0x1000>;
+ reg-names = "dbi", "elbi", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu_fsys CLK_PCIE>, <&cmu_fsys CLK_PCLK_PCIE_PHY>;
+ clock-names = "pcie", "pcie_bus";
+ phys = <&pcie_phy>;
+ pinctrl-0 = <&pcie_bus &pcie_wlanen>;
+ pinctrl-names = "default";
+ num-lanes = <1>;
+ num-viewport = <3>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x81000000 0 0 0x0c001000 0 0x00010000>,
+ <0x82000000 0 0x0c011000 0x0c011000 0 0x03feefff>;
+ vdd10-supply = <&ldo6_reg>;
+ vdd18-supply = <&ldo7_reg>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
deleted file mode 100644
index 651d957..0000000
--- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* Samsung Exynos 5440 PCIe interface
-
-This PCIe host controller is based on the Synopsys DesignWare PCIe IP
-and thus inherits all the common properties defined in designware-pcie.txt.
-
-Required properties:
-- compatible: "samsung,exynos5440-pcie"
-- reg: base addresses and lengths of the PCIe controller,
-- reg-names : First name should be set to "elbi".
- And use the "config" instead of getting the configuration address space
- from "ranges".
- NOTE: When using the "config" property, reg-names must be set.
-- interrupts: A list of interrupt outputs for level interrupt,
- pulse interrupt, special interrupt.
-- phys: From PHY binding. Phandle for the generic PHY.
- Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt
-
-For other common properties, refer to
- Documentation/devicetree/bindings/pci/designware-pcie.txt
-
-Example:
-
-SoC-specific DT Entry (with using PHY framework):
-
- pcie_phy0: pcie-phy@270000 {
- ...
- reg = <0x270000 0x1000>, <0x271000 0x40>;
- reg-names = "phy", "block";
- ...
- };
-
- pcie@290000 {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x290000 0x1000>, <0x40000000 0x1000>;
- reg-names = "elbi", "config";
- clocks = <&clock 28>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- phys = <&pcie_phy0>;
- ranges = <0x81000000 0 0 0x60001000 0 0x00010000
- 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
- num-lanes = <4>;
- };
-
-Board-specific DT Entry:
-
- pcie@290000 {
- reset-gpio = <&pin_ctrl 5 0>;
- };
-
- pcie@2a0000 {
- reset-gpio = <&pin_ctrl 22 0>;
- };
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
index 3ae3e1a..d06f0c4 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
@@ -15,8 +15,14 @@
properties:
compatible:
- enum:
- - ti,j721e-pcie-ep
+ oneOf:
+ - description: PCIe EP controller in J7200
+ items:
+ - const: ti,j7200-pcie-ep
+ - const: ti,j721e-pcie-ep
+ - description: PCIe EP controller in J721E
+ items:
+ - const: ti,j721e-pcie-ep
reg:
maxItems: 4
@@ -29,9 +35,12 @@
- const: mem
ti,syscon-pcie-ctrl:
- description: Phandle to the SYSCON entry required for configuring PCIe mode
- and link speed.
- $ref: /schemas/types.yaml#/definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to the SYSCON entry
+ - description: pcie_ctrl register offset within SYSCON
+ description: Specifier for configuring PCIe mode and link speed.
power-domains:
maxItems: 1
@@ -57,7 +66,6 @@
- power-domains
- clocks
- clock-names
- - cdns,max-outbound-regions
- dma-coherent
- max-functions
- phys
@@ -80,13 +88,12 @@
<0x00 0x0d000000 0x00 0x00800000>,
<0x00 0x10000000 0x00 0x08000000>;
reg-names = "intd_cfg", "user_cfg", "reg", "mem";
- ti,syscon-pcie-ctrl = <&pcie0_ctrl>;
+ ti,syscon-pcie-ctrl = <&pcie0_ctrl 0x4070>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
clocks = <&k3_clks 239 1>;
clock-names = "fck";
- cdns,max-outbound-regions = <16>;
max-functions = /bits/ 8 <6>;
dma-coherent;
phys = <&serdes0_pcie_link>;
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
index ee7a8ea..0880a61 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
@@ -15,8 +15,14 @@
properties:
compatible:
- enum:
- - ti,j721e-pcie-host
+ oneOf:
+ - description: PCIe controller in J7200
+ items:
+ - const: ti,j7200-pcie-host
+ - const: ti,j721e-pcie-host
+ - description: PCIe controller in J721E
+ items:
+ - const: ti,j721e-pcie-host
reg:
maxItems: 4
@@ -29,9 +35,12 @@
- const: cfg
ti,syscon-pcie-ctrl:
- description: Phandle to the SYSCON entry required for configuring PCIe mode
- and link speed.
- $ref: /schemas/types.yaml#/definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to the SYSCON entry
+ - description: pcie_ctrl register offset within SYSCON
+ description: Specifier for configuring PCIe mode and link speed.
power-domains:
maxItems: 1
@@ -48,7 +57,11 @@
const: 0x104c
device-id:
- const: 0xb00d
+ oneOf:
+ - items:
+ - const: 0xb00d
+ - items:
+ - const: 0xb00f
msi-map: true
@@ -90,7 +103,7 @@
<0x00 0x0d000000 0x00 0x00800000>,
<0x00 0x10000000 0x00 0x00001000>;
reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
- ti,syscon-pcie-ctrl = <&pcie0_ctrl>;
+ ti,syscon-pcie-ctrl = <&pcie0_ctrl 0x4070>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
index 5aad9f4..80a9238 100644
--- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
+++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
@@ -15,6 +15,9 @@
- enum:
- fsl,imx8-ddr-pmu
- fsl,imx8m-ddr-pmu
+ - fsl,imx8mq-ddr-pmu
+ - fsl,imx8mm-ddr-pmu
+ - fsl,imx8mn-ddr-pmu
- fsl,imx8mp-ddr-pmu
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml
new file mode 100644
index 0000000..be485f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/amlogic,axg-mipi-dphy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic AXG MIPI D-PHY
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,axg-mipi-dphy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pclk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 0
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: analog
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@ff640000 {
+ compatible = "amlogic,axg-mipi-dphy";
+ reg = <0xff640000 0x100>;
+ clocks = <&clk_mipi_dsi_phy>;
+ clock-names = "pclk";
+ resets = <&reset_phy>;
+ reset-names = "phy";
+ phys = <&mipi_pcie_analog_dphy>;
+ phy-names = "analog";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
index 18c1ec5..4d01f31 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
@@ -9,27 +9,32 @@
maintainers:
- Remi Pommarel <repk@triplefau.lt>
+description: |+
+ The Everything-Else Power Domains node should be the child of a syscon
+ node with the required property:
+
+ - compatible: Should be the following:
+ "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"
+
+ Refer to the the bindings described in
+ Documentation/devicetree/bindings/mfd/syscon.yaml
+
properties:
compatible:
const: amlogic,axg-mipi-pcie-analog-phy
- reg:
- maxItems: 1
-
"#phy-cells":
- const: 1
+ const: 0
required:
- compatible
- - reg
- "#phy-cells"
additionalProperties: false
examples:
- |
- mpphy: phy@0 {
+ mpphy: phy {
compatible = "amlogic,axg-mipi-pcie-analog-phy";
- reg = <0x0 0xc>;
- #phy-cells = <1>;
+ #phy-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
new file mode 100644
index 0000000..58c3ef8
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/brcm,sata-phy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Broadcom SATA3 PHY
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ $nodename:
+ pattern: "^sata[-|_]phy(@.*)?$"
+
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - brcm,bcm7216-sata-phy
+ - brcm,bcm7425-sata-phy
+ - brcm,bcm7445-sata-phy
+ - brcm,bcm63138-sata-phy
+ - const: brcm,phy-sata3
+ - items:
+ - const: brcm,iproc-nsp-sata-phy
+ - items:
+ - const: brcm,iproc-ns2-sata-phy
+ - items:
+ - const: brcm,iproc-sr-sata-phy
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ - const: phy
+ - const: phy-ctrl
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^sata-phy@[0-9]+$":
+ type: object
+ description: |
+ Each port's PHY should be represented as a sub-node.
+
+ properties:
+ reg:
+ description: The SATA PHY port number
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ "brcm,enable-ssc":
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Use spread spectrum clocking (SSC) on this port
+ This property is not applicable for "brcm,iproc-ns2-sata-phy",
+ "brcm,iproc-nsp-sata-phy" and "brcm,iproc-sr-sata-phy".
+
+ "brcm,rxaeq-mode":
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ String that indicates the desired RX equalizer mode.
+ enum:
+ - off
+ - auto
+ - manual
+
+ "brcm,rxaeq-value":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ When 'brcm,rxaeq-mode' is set to "manual", provides the RX
+ equalizer value that should be used.
+ minimum: 0
+ maximum: 63
+
+ "brcm,tx-amplitude-millivolt":
+ description: |
+ Transmit amplitude voltage in millivolt.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [400, 500, 600, 800]
+
+ required:
+ - reg
+ - "#phy-cells"
+
+ additionalProperties: false
+
+if:
+ properties:
+ compatible:
+ items:
+ const: brcm,iproc-ns2-sata-phy
+then:
+ properties:
+ reg:
+ maxItems: 2
+ reg-names:
+ items:
+ - const: "phy"
+ - const: "phy-ctrl"
+else:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
+ items:
+ - const: "phy"
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ sata_phy@f0458100 {
+ compatible = "brcm,bcm7445-sata-phy", "brcm,phy-sata3";
+ reg = <0xf0458100 0x1e00>;
+ reg-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ sata-phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
deleted file mode 100644
index c03ad21..0000000
--- a/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* Broadcom SATA3 PHY
-
-Required properties:
-- compatible: should be one or more of
- "brcm,bcm7216-sata-phy"
- "brcm,bcm7425-sata-phy"
- "brcm,bcm7445-sata-phy"
- "brcm,iproc-ns2-sata-phy"
- "brcm,iproc-nsp-sata-phy"
- "brcm,phy-sata3"
- "brcm,iproc-sr-sata-phy"
- "brcm,bcm63138-sata-phy"
-- address-cells: should be 1
-- size-cells: should be 0
-- reg: register ranges for the PHY PCB interface
-- reg-names: should be "phy" and "phy-ctrl"
- The "phy-ctrl" registers are only required for
- "brcm,iproc-ns2-sata-phy" and "brcm,iproc-sr-sata-phy".
-
-Sub-nodes:
- Each port's PHY should be represented as a sub-node.
-
-Sub-nodes required properties:
-- reg: the PHY number
-- phy-cells: generic PHY binding; must be 0
-
-Sub-nodes optional properties:
-- brcm,enable-ssc: use spread spectrum clocking (SSC) on this port
- This property is not applicable for "brcm,iproc-ns2-sata-phy",
- "brcm,iproc-nsp-sata-phy" and "brcm,iproc-sr-sata-phy".
-
-- brcm,rxaeq-mode: string that indicates the desired RX equalizer
- mode, possible values are:
- "off" (equivalent to not specifying the property)
- "auto"
- "manual" (brcm,rxaeq-value is used in that case)
-
-- brcm,rxaeq-value: when 'rxaeq-mode' is set to "manual", provides the RX
- equalizer value that should be used. Allowed range is 0..63.
-
-Example
- sata-phy@f0458100 {
- compatible = "brcm,bcm7445-sata-phy", "brcm,phy-sata3";
- reg = <0xf0458100 0x1e00>, <0xf045804c 0x10>;
- reg-names = "phy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- sata-phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- };
-
- sata-phy@1 {
- reg = <1>;
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
new file mode 100644
index 0000000..0fd93d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ingenic,phy-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ingenic SoCs USB PHY devicetree bindings
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+ - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+
+properties:
+ $nodename:
+ pattern: '^usb-phy@.*'
+
+ compatible:
+ enum:
+ - ingenic,jz4770-phy
+ - ingenic,jz4775-phy
+ - ingenic,jz4780-phy
+ - ingenic,x1000-phy
+ - ingenic,x1830-phy
+ - ingenic,x2000-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ vcc-supply:
+ description: VCC power supply
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vcc-supply
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/jz4770-cgu.h>
+ otg_phy: usb-phy@3c {
+ compatible = "ingenic,jz4770-phy";
+ reg = <0x3c 0x10>;
+
+ vcc-supply = <&vcc>;
+ clocks = <&cgu JZ4770_CLK_OTG_PHY>;
+
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml b/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
new file mode 100644
index 0000000..a217bb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,phy-keembay-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Keem Bay USB PHY bindings
+
+maintainers:
+ - Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
+
+properties:
+ compatible:
+ const: intel,keembay-usb-phy
+
+ reg:
+ items:
+ - description: USB APB CPR (clock, power, reset) register
+ - description: USB APB slave register
+
+ reg-names:
+ items:
+ - const: cpr-apb-base
+ - const: slv-apb-base
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@20400000 {
+ compatible = "intel,keembay-usb-phy";
+ reg = <0x20400000 0x1c>,
+ <0x20480000 0xd0>;
+ reg-names = "cpr-apb-base", "slv-apb-base";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
index 00609ac..ff255aa 100644
--- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-or-later
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
# Copyright 2019 Lubomir Rintel <lkundrak@v3.sk>
%YAML 1.2
---
@@ -18,27 +18,20 @@
maxItems: 1
description: base address of the device
- reset-gpios:
- maxItems: 1
- description: GPIO connected to reset
-
"#phy-cells":
const: 0
required:
- compatible
- reg
- - reset-gpios
- "#phy-cells"
additionalProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
hsic-phy@f0001800 {
compatible = "marvell,mmp3-hsic-phy";
reg = <0xf0001800 0x40>;
- reset-gpios = <&gpio 63 GPIO_ACTIVE_HIGH>;
#phy-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
new file mode 100644
index 0000000..0ccaded
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/mediatek,mt7621-pci-phy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Mediatek Mt7621 PCIe PHY Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mt7621-pci-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 1
+ description: selects if the phy is dual-ported
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie0_phy: pcie-phy@1e149000 {
+ compatible = "mediatek,mt7621-pci-phy";
+ reg = <0x1e149000 0x0700>;
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.txt b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.txt
deleted file mode 100644
index 03f5939..0000000
--- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Cadence Sierra PHY
------------------------
-
-Required properties:
-- compatible: Must be "cdns,sierra-phy-t0" for Sierra in Cadence platform
- Must be "ti,sierra-phy-t0" for Sierra in TI's J721E SoC.
-- resets: Must contain an entry for each in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include "sierra_reset" and "sierra_apb".
- "sierra_reset" must control the reset line to the PHY.
- "sierra_apb" must control the reset line to the APB PHY
- interface ("sierra_apb" is optional).
-- reg: register range for the PHY.
-- #address-cells: Must be 1
-- #size-cells: Must be 0
-
-Optional properties:
-- clocks: Must contain an entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must contain "cmn_refclk_dig_div" and
- "cmn_refclk1_dig_div" for configuring the frequency of
- the clock to the lanes. "phy_clk" is deprecated.
-- cdns,autoconf: A boolean property whose presence indicates that the
- PHY registers will be configured by hardware. If not
- present, all sub-node optional properties must be
- provided.
-
-Sub-nodes:
- Each group of PHY lanes with a single master lane should be represented as
- a sub-node. Note that the actual configuration of each lane is determined by
- hardware strapping, and must match the configuration specified here.
-
-Sub-node required properties:
-- #phy-cells: Generic PHY binding; must be 0.
-- reg: The master lane number. This is the lowest numbered lane
- in the lane group.
-- resets: Must contain one entry which controls the reset line for the
- master lane of the sub-node.
- See ../reset/reset.txt for details.
-
-Sub-node optional properties:
-- cdns,num-lanes: Number of lanes in this group. From 1 to 4. The
- group is made up of consecutive lanes.
-- cdns,phy-type: Can be PHY_TYPE_PCIE or PHY_TYPE_USB3, depending on
- configuration of lanes.
-
-Example:
- pcie_phy4: pcie-phy@fd240000 {
- compatible = "cdns,sierra-phy-t0";
- reg = <0x0 0xfd240000 0x0 0x40000>;
- resets = <&phyrst 0>, <&phyrst 1>;
- reset-names = "sierra_reset", "sierra_apb";
- clocks = <&phyclock>;
- clock-names = "phy_clk";
- #address-cells = <1>;
- #size-cells = <0>;
- pcie0_phy0: pcie-phy@0 {
- reg = <0>;
- resets = <&phyrst 2>;
- cdns,num-lanes = <2>;
- #phy-cells = <0>;
- cdns,phy-type = <PHY_TYPE_PCIE>;
- };
- pcie0_phy1: pcie-phy@2 {
- reg = <2>;
- resets = <&phyrst 4>;
- cdns,num-lanes = <1>;
- #phy-cells = <0>;
- cdns,phy-type = <PHY_TYPE_PCIE>;
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
new file mode 100644
index 0000000..d210843
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/phy-cadence-sierra.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Cadence Sierra PHY binding
+
+description:
+ This binding describes the Cadence Sierra PHY. Sierra PHY supports multilink
+ multiprotocol combinations including protocols such as PCIe, USB etc.
+
+maintainers:
+ - Swapnil Jakhade <sjakhade@cadence.com>
+ - Yuti Amonkar <yamonkar@cadence.com>
+
+properties:
+ compatible:
+ enum:
+ - cdns,sierra-phy-t0
+ - ti,sierra-phy-t0
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ resets:
+ minItems: 1
+ maxItems: 2
+ items:
+ - description: Sierra PHY reset.
+ - description: Sierra APB reset. This is optional.
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ - const: sierra_reset
+ - const: sierra_apb
+
+ reg:
+ maxItems: 1
+ description:
+ Offset of the Sierra PHY configuration registers.
+
+ reg-names:
+ const: serdes
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: cmn_refclk_dig_div
+ - const: cmn_refclk1_dig_div
+
+ cdns,autoconf:
+ type: boolean
+ description:
+ A boolean property whose presence indicates that the PHY registers will be
+ configured by hardware. If not present, all sub-node optional properties
+ must be provided.
+
+patternProperties:
+ '^phy@[0-9a-f]$':
+ type: object
+ description:
+ Each group of PHY lanes with a single master lane should be represented as
+ a sub-node. Note that the actual configuration of each lane is determined
+ by hardware strapping, and must match the configuration specified here.
+ properties:
+ reg:
+ description:
+ The master lane number. This is the lowest numbered lane in the lane group.
+ minimum: 0
+ maximum: 15
+
+ resets:
+ minItems: 1
+ maxItems: 4
+ description:
+ Contains list of resets, one per lane, to get all the link lanes out of reset.
+
+ "#phy-cells":
+ const: 0
+
+ cdns,phy-type:
+ description:
+ Specifies the type of PHY for which the group of PHY lanes is used.
+ Refer include/dt-bindings/phy/phy.h. Constants from the header should be used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [2, 4]
+
+ cdns,num-lanes:
+ description:
+ Number of lanes in this group. The group is made up of consecutive lanes.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 16
+
+ required:
+ - reg
+ - resets
+ - "#phy-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/phy/phy.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ sierra-phy@fd240000 {
+ compatible = "cdns,sierra-phy-t0";
+ reg = <0x0 0xfd240000 0x0 0x40000>;
+ resets = <&phyrst 0>, <&phyrst 1>;
+ reset-names = "sierra_reset", "sierra_apb";
+ clocks = <&cmn_refclk_dig_div>, <&cmn_refclk1_dig_div>;
+ clock-names = "cmn_refclk_dig_div", "cmn_refclk1_dig_div";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pcie0_phy0: phy@0 {
+ reg = <0>;
+ resets = <&phyrst 2>;
+ cdns,num-lanes = <2>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_PCIE>;
+ };
+ pcie0_phy1: phy@2 {
+ reg = <2>;
+ resets = <&phyrst 4>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_PCIE>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt
deleted file mode 100644
index 725ae71..0000000
--- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-STMicroelectronics STM32 USB HS PHY controller
-
-The STM32 USBPHYC block contains a dual port High Speed UTMI+ PHY and a UTMI
-switch. It controls PHY configuration and status, and the UTMI+ switch that
-selects either OTG or HOST controller for the second PHY port. It also sets
-PLL configuration.
-
-USBPHYC
- |_ PLL
- |
- |_ PHY port#1 _________________ HOST controller
- | _ |
- | / 1|________________|
- |_ PHY port#2 ----| |________________
- | \_0| |
- |_ UTMI switch_______| OTG controller
-
-
-Phy provider node
-=================
-
-Required properties:
-- compatible: must be "st,stm32mp1-usbphyc"
-- reg: address and length of the usb phy control register set
-- clocks: phandle + clock specifier for the PLL phy clock
-- #address-cells: number of address cells for phys sub-nodes, must be <1>
-- #size-cells: number of size cells for phys sub-nodes, must be <0>
-
-Optional properties:
-- assigned-clocks: phandle + clock specifier for the PLL phy clock
-- assigned-clock-parents: the PLL phy clock parent
-- resets: phandle + reset specifier
-
-Required nodes: one sub-node per port the controller provides.
-
-Phy sub-nodes
-==============
-
-Required properties:
-- reg: phy port index
-- phy-supply: phandle to the regulator providing 3V3 power to the PHY,
- see phy-bindings.txt in the same directory.
-- vdda1v1-supply: phandle to the regulator providing 1V1 power to the PHY
-- vdda1v8-supply: phandle to the regulator providing 1V8 power to the PHY
-- #phy-cells: see phy-bindings.txt in the same directory, must be <0> for PHY
- port#1 and must be <1> for PHY port#2, to select USB controller
-
-
-Example:
- usbphyc: usb-phy@5a006000 {
- compatible = "st,stm32mp1-usbphyc";
- reg = <0x5a006000 0x1000>;
- clocks = <&rcc_clk USBPHY_K>;
- resets = <&rcc_rst USBPHY_R>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbphyc_port0: usb-phy@0 {
- reg = <0>;
- phy-supply = <&vdd_usb>;
- vdda1v1-supply = <®11>;
- vdda1v8-supply = <®18>
- #phy-cells = <0>;
- };
-
- usbphyc_port1: usb-phy@1 {
- reg = <1>;
- phy-supply = <&vdd_usb>;
- vdda1v1-supply = <®11>;
- vdda1v8-supply = <®18>
- #phy-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
new file mode 100644
index 0000000..0ba6197
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/phy-stm32-usbphyc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 USB HS PHY controller binding
+
+description:
+
+ The STM32 USBPHYC block contains a dual port High Speed UTMI+ PHY and a UTMI
+ switch. It controls PHY configuration and status, and the UTMI+ switch that
+ selects either OTG or HOST controller for the second PHY port. It also sets
+ PLL configuration.
+
+ USBPHYC
+ |_ PLL
+ |
+ |_ PHY port#1 _________________ HOST controller
+ | __ |
+ | / 1|________________|
+ |_ PHY port#2 ----| |________________
+ | \_0| |
+ |_ UTMI switch_______| OTG controller
+
+maintainers:
+ - Amelie Delaunay <amelie.delaunay@st.com>
+
+properties:
+ compatible:
+ const: st,stm32mp1-usbphyc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+#Required child nodes:
+
+patternProperties:
+ "^usb-phy@[0|1]$":
+ type: object
+ description:
+ Each port the controller provides must be represented as a sub-node.
+
+ properties:
+ reg:
+ description: phy port index.
+ maxItems: 1
+
+ phy-supply:
+ description: regulator providing 3V3 power supply to the PHY.
+
+ vdda1v1-supply:
+ description: regulator providing 1V1 power supply to the PLL block
+
+ vdda1v8-supply:
+ description: regulator providing 1V8 power supply to the PLL block
+
+ "#phy-cells":
+ enum: [ 0x0, 0x1 ]
+
+ allOf:
+ - if:
+ properties:
+ reg:
+ const: 0
+ then:
+ properties:
+ "#phy-cells":
+ const: 0
+ else:
+ properties:
+ "#phy-cells":
+ const: 1
+ description:
+ The value is used to select UTMI switch output.
+ 0 for OTG controller and 1 for Host controller.
+
+ required:
+ - reg
+ - phy-supply
+ - vdda1v1-supply
+ - vdda1v8-supply
+ - "#phy-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#address-cells"
+ - "#size-cells"
+ - usb-phy@0
+ - usb-phy@1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+ #include <dt-bindings/reset/stm32mp1-resets.h>
+ usbphyc: usbphyc@5a006000 {
+ compatible = "st,stm32mp1-usbphyc";
+ reg = <0x5a006000 0x1000>;
+ clocks = <&rcc USBPHY_K>;
+ resets = <&rcc USBPHY_R>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbphyc_port0: usb-phy@0 {
+ reg = <0>;
+ phy-supply = <&vdd_usb>;
+ vdda1v1-supply = <®11>;
+ vdda1v8-supply = <®18>;
+ #phy-cells = <0>;
+ };
+
+ usbphyc_port1: usb-phy@1 {
+ reg = <1>;
+ phy-supply = <&vdd_usb>;
+ vdda1v1-supply = <®11>;
+ vdda1v8-supply = <®18>;
+ #phy-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
index 185cdea..ec05db3 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
@@ -31,6 +31,9 @@
- qcom,sdm845-qmp-usb3-uni-phy
- qcom,sm8150-qmp-ufs-phy
- qcom,sm8250-qmp-ufs-phy
+ - qcom,sm8250-qmp-gen3x1-pcie-phy
+ - qcom,sm8250-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-modem-pcie-phy
reg:
items:
@@ -259,6 +262,9 @@
enum:
- qcom,sdm845-qhp-pcie-phy
- qcom,sdm845-qmp-pcie-phy
+ - qcom,sm8250-qmp-gen3x1-pcie-phy
+ - qcom,sm8250-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-modem-pcie-phy
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
index e728786..00aa2d3 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
@@ -16,6 +16,11 @@
- drive-impedance-ohm: Specifies the drive impedance in Ohm.
Possible values are 33, 40, 50, 66 and 100.
If not set, the default value of 50 will be applied.
+ - enable-strobe-pulldown: Enable internal pull-down for the strobe line.
+ If not set, pull-down is not used.
+ - output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
+ If not set, the register defaults to 0x4.
+ Maximum value 0xf.
Example:
diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
new file mode 100644
index 0000000..ac0af40
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/samsung,exynos-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series PCIe PHY Device Tree Bindings
+
+maintainers:
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+ - Jaehoon Chung <jh80.chung@samsung.com>
+
+properties:
+ "#phy-cells":
+ const: 0
+
+ compatible:
+ const: samsung,exynos5433-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ samsung,pmu-syscon:
+ $ref: '/schemas/types.yaml#/definitions/phandle'
+ description: phandle for PMU system controller interface, used to
+ control PMU registers bits for PCIe PHY
+
+ samsung,fsys-sysreg:
+ $ref: '/schemas/types.yaml#/definitions/phandle'
+ description: phandle for FSYS sysreg interface, used to control
+ sysreg registers bits for PCIe PHY
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - samsung,pmu-syscon
+ - samsung,fsys-sysreg
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie_phy: pcie-phy@15680000 {
+ compatible = "samsung,exynos5433-pcie-phy";
+ reg = <0x15680000 0x1000>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ samsung,fsys-sysreg = <&syscon_fsys>;
+ #phy-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 7510830..8f51aee 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -47,6 +47,7 @@
- "samsung,exynos4210-usb2-phy"
- "samsung,exynos4x12-usb2-phy"
- "samsung,exynos5250-usb2-phy"
+ - "samsung,exynos5420-usb2-phy"
- "samsung,s5pv210-usb2-phy"
- reg : a list of registers used by phy driver
- first and obligatory is the location of phy modules registers
diff --git a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
index 83d5d0a..cbbf5e8 100644
--- a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
@@ -44,13 +44,13 @@
- const: refclk
syscon-phy-power:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
phandle/offset pair. Phandle to the system control module and
register offset to power on/off the PHY.
ctrl-module:
- $ref: /schemas/types.yaml#definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
(deprecated) phandle of the control module used by PHY driver
to power on the PHY. Use syscon-phy-power instead.
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
new file mode 100644
index 0000000..df0c83c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/microchip,sparx5-sgpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microsemi/Microchip Serial GPIO controller
+
+maintainers:
+ - Lars Povlsen <lars.povlsen@microchip.com>
+
+description: |
+ By using a serial interface, the SIO controller significantly extend
+ the number of available GPIOs with a minimum number of additional
+ pins on the device. The primary purpose of the SIO controllers is to
+ connect control signals from SFP modules and to act as an LED
+ controller.
+
+properties:
+ $nodename:
+ pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - microchip,sparx5-sgpio
+ - mscc,ocelot-sgpio
+ - mscc,luton-sgpio
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ microchip,sgpio-port-ranges:
+ description: This is a sequence of tuples, defining intervals of
+ enabled ports in the serial input stream. The enabled ports must
+ match the hardware configuration in order for signals to be
+ properly written/read to/from the controller holding
+ registers. Being tuples, then number of arguments must be
+ even. The tuples mast be ordered (low, high) and are
+ inclusive.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "low" indicates start bit number of range
+ minimum: 0
+ maximum: 31
+ - description: |
+ "high" indicates end bit number of range
+ minimum: 0
+ maximum: 31
+ minItems: 1
+ maxItems: 32
+
+ bus-frequency:
+ description: The sgpio controller frequency (Hz). This dictates
+ the serial bitstream speed, which again affects the latency in
+ getting control signals back and forth between external shift
+ registers. The speed must be no larger than half the system
+ clock, and larger than zero.
+ default: 12500000
+
+patternProperties:
+ "^gpio@[0-1]$":
+ type: object
+ properties:
+ compatible:
+ const: microchip,sparx5-sgpio-bank
+
+ reg:
+ description: |
+ The GPIO bank number. "0" is designates the input pin bank,
+ "1" the output bank.
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description: |
+ Specifies the pin (port and bit) and flags. Note that the
+ SGIO pin is defined by *2* numbers, a port number between 0
+ and 31, and a bit index, 0 to 3. The maximum bit number is
+ controlled indirectly by the "ngpios" property: (ngpios/32).
+ const: 3
+
+ interrupts:
+ description: Specifies the sgpio IRQ (in parent controller)
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description:
+ Specifies the pin (port and bit) and flags, as defined in
+ defined in include/dt-bindings/interrupt-controller/irq.h
+ const: 3
+
+ ngpios:
+ description: The numbers of GPIO's exposed. This must be a
+ multiple of 32.
+ minimum: 32
+ maximum: 128
+
+ required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - ngpios
+
+ additionalProperties: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - microchip,sgpio-port-ranges
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ sgpio2: gpio@1101059c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "microchip,sparx5-sgpio";
+ clocks = <&sys_clk>;
+ pinctrl-0 = <&sgpio2_pins>;
+ pinctrl-names = "default";
+ reg = <0x1101059c 0x100>;
+ microchip,sgpio-port-ranges = <0 0>, <16 18>, <28 31>;
+ bus-frequency = <25000000>;
+ sgpio_in2: gpio@0 {
+ reg = <0>;
+ compatible = "microchip,sparx5-sgpio-bank";
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <96>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+ sgpio_out2: gpio@1 {
+ compatible = "microchip,sparx5-sgpio-bank";
+ reg = <1>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ ngpios = <96>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
index 0091244..db99bd9 100644
--- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
@@ -3,7 +3,8 @@
Required properties:
- compatible : Should be "mscc,ocelot-pinctrl",
- "mscc,jaguar2-pinctrl" or "microchip,sparx5-pinctrl"
+ "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl",
+ "mscc,luton-pinctrl" or "mscc,serval-pinctrl"
- reg : Address and length of the register set for the device
- gpio-controller : Indicates this device is a GPIO controller
- #gpio-cells : Must be 2.
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt
index 8763f44..90d38f7 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt
@@ -99,7 +99,7 @@
nvidia,schmitt = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
- nvidia,io-high-voltage = <TEGRA_PIN_ENABLE>;
+ nvidia,io-hv = <TEGRA_PIN_ENABLE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
};
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml
new file mode 100644
index 0000000..e47ebf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS)
+ Low Power Island (LPI) TLMM block
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ LPASS LPI IP on most Qualcomm SoCs
+
+properties:
+ compatible:
+ const: qcom,sm8250-lpass-lpi-pinctrl
+
+ reg:
+ minItems: 2
+ maxItems: 2
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9])$"
+ minItems: 1
+ maxItems: 14
+
+ function:
+ enum: [ gpio, swr_tx_clk, qua_mi2s_sclk, swr_tx_data, qua_mi2s_ws,
+ qua_mi2s_data, swr_rx_clk, swr_rx_data, dmic1_clk, i2s1_clk,
+ dmic1_data, i2s1_ws, dmic2_clk, dmic2_data, i2s1_data,
+ i2s2_clk, wsa_swr_clk, i2s2_ws, wsa_swr_data, dmic3_clk,
+ dmic3_data, i2s2_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ slew-rate:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ 0: No adjustments
+ 1: Higher Slew rate (faster edges)
+ 2: Lower Slew rate (slower edges)
+ 3: Reserved (No adjustments)
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ lpi_tlmm: pinctrl@33c0000 {
+ compatible = "qcom,sm8250-lpass-lpi-pinctrl";
+ reg = <0x33c0000 0x20000>,
+ <0x3550000 0x10000>;
+ clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 14>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
new file mode 100644
index 0000000..abe9f4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8953-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. MSM8953 TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ MSM8953 platform.
+
+properties:
+ compatible:
+ const: qcom,msm8953-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Specifies the TLMM summary IRQ
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description:
+ Specifies the PIN numbers and Flags, as defined in defined in
+ include/dt-bindings/interrupt-controller/irq.h
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
+ sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0,
+ qdsd_data1, qdsd_data2, qdsd_data3 ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ accel_int, adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1,
+ atest_char, atest_char0, atest_char1, atest_char2, atest_char3,
+ atest_gpsadc_dtest0_native, atest_gpsadc_dtest1_native, atest_tsens,
+ atest_wlan0, atest_wlan1, bimc_dte0, bimc_dte1, blsp1_spi,
+ blsp3_spi, blsp6_spi, blsp7_spi, blsp_i2c1, blsp_i2c2, blsp_i2c3,
+ blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_spi1,
+ blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7,
+ blsp_spi8, blsp_uart2, blsp_uart4, blsp_uart5, blsp_uart6, cam0_ldo,
+ cam1_ldo, cam1_rst, cam1_standby, cam2_rst, cam2_standby, cam3_rst,
+ cam3_standby, cam_irq, cam_mclk, cap_int, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cdc_pdm0, codec_int1, codec_int2, codec_reset, cri_trng, cri_trng0,
+ cri_trng1, dac_calib0, dac_calib1, dac_calib10, dac_calib11,
+ dac_calib12, dac_calib13, dac_calib14, dac_calib15, dac_calib16,
+ dac_calib17, dac_calib18, dac_calib19, dac_calib2, dac_calib20,
+ dac_calib21, dac_calib22, dac_calib23, dac_calib24, dac_calib25,
+ dac_calib3, dac_calib4, dac_calib5, dac_calib6, dac_calib7,
+ dac_calib8, dac_calib9, dbg_out, ddr_bist, dmic0_clk, dmic0_data,
+ ebi_cdc, ebi_ch0, ext_lpass, flash_strobe, fp_int, gcc_gp1_clk_a,
+ gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a,
+ gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gpio, gsm0_tx, gsm1_tx,
+ gyro_int, hall_int, hdmi_int, key_focus, key_home, key_snapshot,
+ key_volp, ldo_en, ldo_update, lpass_slimbus, lpass_slimbus0,
+ lpass_slimbus1, m_voc, mag_int, mdp_vsync, mipi_dsi0, modem_tsync,
+ mss_lte, nav_pps, nav_pps_in_a, nav_pps_in_b, nav_tsync,
+ nfc_disable, nfc_dwl, nfc_irq, ois_sync, pa_indicator, pbs0, pbs1,
+ pbs2, pressure_int, pri_mi2s, pri_mi2s_mclk_a, pri_mi2s_mclk_b,
+ pri_mi2s_ws, prng_rosc, pwr_crypto_enabled_a, pwr_crypto_enabled_b,
+ pwr_down, pwr_modem_enabled_a, pwr_modem_enabled_b,
+ pwr_nav_enabled_a, pwr_nav_enabled_b, qdss_cti_trig_in_a0,
+ qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
+ qdss_cti_trig_out_a0, qdss_cti_trig_out_a1, qdss_cti_trig_out_b0,
+ qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_traceclk_b,
+ qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a,
+ qdss_tracedata_b, sd_write, sdcard_det, sec_mi2s, sec_mi2s_mclk_a,
+ sec_mi2s_mclk_b, smb_int, ss_switch, ssbi_wtr1, ts_resout,
+ ts_sample, ts_xvdd, tsens_max, uim1_clk, uim1_data, uim1_present,
+ uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset,
+ uim_batt, us_emitter, us_euro, wcss_bt, wcss_fm, wcss_wlan,
+ wcss_wlan0, wcss_wlan1, wcss_wlan2, wsa_en, wsa_io, wsa_irq ]
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,msm8953-pinctrl";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 142>;
+
+ serial_default: serial-pins {
+ pins = "gpio4", "gpio5";
+ function = "blsp_uart2";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
index c3d1914..7648ab0 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
@@ -29,6 +29,7 @@
"qcom,pm8150b-gpio"
"qcom,pm6150-gpio"
"qcom,pm6150l-gpio"
+ "qcom,pmx55-gpio"
And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
if the device is on an spmi bus or an ssbi bus respectively
@@ -110,6 +111,8 @@
gpio1-gpio12 for pm8150l (hole on gpio7)
gpio1-gpio10 for pm6150
gpio1-gpio12 for pm6150l
+ gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10
+ and gpio11)
- function:
Usage: required
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml
new file mode 100644
index 0000000..7d6a2ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sc7280-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SC7280 TLMM block
+
+maintainers:
+ - Rajendra Nayak <rnayak@codeaurora.org>
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ SC7280 platform.
+
+properties:
+ compatible:
+ const: qcom,sc7280-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Specifies the TLMM summary IRQ
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description:
+ Specifies the PIN numbers and Flags, as defined in defined in
+ include/dt-bindings/interrupt-controller/irq.h
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ wakeup-parent:
+ maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-4])$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
+ sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_char0, atest_char1, atest_char2,
+ atest_char3, atest_usb0, atest_usb00, atest_usb01,
+ atest_usb02, atest_usb03, atest_usb1, atest_usb10,
+ atest_usb11, atest_usb12, atest_usb13, audio_ref,
+ cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1,
+ cci_timer2, cci_timer3, cci_timer4, cmu_rng0, cmu_rng1,
+ cmu_rng2, cmu_rng3, coex_uart1, cri_trng, cri_trng0,
+ cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, dp_hot,
+ dp_lcd, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
+ gpio, host2wlan_sol, ibi_i3c, jitter_bist, lpass_slimbus,
+ mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3,
+ mdp_vsync4, mdp_vsync5, mi2s0_data0, mi2s0_data1, mi2s0_sck,
+ mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws,
+ mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, mss_grfc0,
+ mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12, mss_grfc2,
+ mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6, mss_grfc7,
+ mss_grfc8, mss_grfc9, nav_gpio0, nav_gpio1, nav_gpio2,
+ pa_indicator, pcie0_clkreqn, pcie1_clkreqn, phase_flag,
+ pll_bist, pll_bypassnl, pll_clk, pll_reset, pri_mi2s, prng_rosc,
+ qdss, qdss_cti, qlink0_enable, qlink0_request, qlink0_wmss,
+ qlink1_enable, qlink1_request, qlink1_wmss, qspi_clk, qspi_cs,
+ qspi_data, qup00, qup01, qup02, qup03, qup04, qup05, qup06, qup07,
+ qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17,
+ sdc40, sdc41, sdc42, sdc43, sdc4_clk, sdc4_cmd, sd_write,
+ sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tsense_pwm1,
+ tsense_pwm2, uim0_clk, uim0_data, uim0_present, uim0_reset,
+ uim1_clk, uim1_data, uim1_present, uim1_reset, usb2phy_ac,
+ usb_phy, vfr_0, vfr_1, vsense_trigger ]
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f000000 {
+ compatible = "qcom,sc7280-pinctrl";
+ reg = <0xf000000 0x1000000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 175>;
+ wakeup-parent = <&pdc>;
+
+ qup_uart5_default: qup-uart5-pins {
+ pins = "gpio46", "gpio47";
+ function = "qup13";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
new file mode 100644
index 0000000..112dd59
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdx55-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SDX55 TLMM block
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description: |
+ This binding describes the Top Level Mode Multiplexer block found in the
+ SDX55 platform.
+
+properties:
+ compatible:
+ const: qcom,sdx55-pinctrl
+
+ reg:
+ description: Specifies the base address and size of the TLMM register space
+ maxItems: 1
+
+ interrupts:
+ description: Specifies the TLMM summary IRQ
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description: Specifies the PIN numbers and Flags, as defined in
+ include/dt-bindings/interrupt-controller/irq.h
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: "/schemas/pinctrl/pincfg-node.yaml"
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins. Functions are only valid for gpio pins.
+ enum: [ adsp_ext, atest, audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1,
+ blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_spi1, blsp_spi2,
+ blsp_spi3, blsp_spi4, blsp_uart1, blsp_uart2, blsp_uart3,
+ blsp_uart4, char_exec, coex_uart, coex_uart2, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
+ ebi0_wrcdc, ebi2_a, ebi2_lcd, emac_gcc0, emac_gcc1,
+ emac_pps0, emac_pps1, ext_dbg, gcc_gp1, gcc_gp2, gcc_gp3,
+ gcc_plltest, gpio, i2s_mclk, jitter_bist, ldo_en, ldo_update,
+ mgpi_clk, m_voc, native_char, native_char0, native_char1,
+ native_char2, native_char3, native_tsens, native_tsense,
+ nav_gpio, pa_indicator, pcie_clkreq, pci_e, pll_bist, pll_ref,
+ pll_test, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio,
+ qdss_gpio0, qdss_gpio1, qdss_gpio2, qdss_gpio3, qdss_gpio4,
+ qdss_gpio5, qdss_gpio6, qdss_gpio7, qdss_gpio8, qdss_gpio9,
+ qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13,
+ qdss_gpio14, qdss_gpio15, qdss_stm0, qdss_stm1, qdss_stm2,
+ qdss_stm3, qdss_stm4, qdss_stm5, qdss_stm6, qdss_stm7,
+ qdss_stm8, qdss_stm9, qdss_stm10, qdss_stm11, qdss_stm12,
+ qdss_stm13, qdss_stm14, qdss_stm15, qdss_stm16, qdss_stm17,
+ qdss_stm18, qdss_stm19, qdss_stm20, qdss_stm21, qdss_stm22,
+ qdss_stm23, qdss_stm24, qdss_stm25, qdss_stm26, qdss_stm27,
+ qdss_stm28, qdss_stm29, qdss_stm30, qdss_stm31, qlink0_en,
+ qlink0_req, qlink0_wmss, qlink1_en, qlink1_req, qlink1_wmss,
+ spmi_coex, sec_mi2s, spmi_vgi, tgu_ch0, uim1_clk, uim1_data,
+ uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present,
+ uim2_reset, usb2phy_ac, vsense_trigger ]
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1f00000 {
+ compatible = "qcom,sdx55-pinctrl";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 108>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+
+ serial-pins {
+ pins = "gpio8", "gpio9";
+ function = "blsp_uart3";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml
new file mode 100644
index 0000000..7dea3e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/ralink,rt2880-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink rt2880 pinmux controller
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description:
+ The rt2880 pinmux can only set the muxing of pin groups. muxing indiviual pins
+ is not supported. There is no pinconf support.
+
+properties:
+ compatible:
+ enum:
+ - ralink,rt2880-pinmux
+
+ pinctrl-0:
+ description:
+ A phandle to the node containing the subnodes containing default
+ configurations. This is for pinctrl hogs.
+
+ pinctrl-names:
+ description:
+ A pinctrl state named "default" can be defined.
+ const: default
+
+required:
+ - compatible
+
+patternProperties:
+ '[a-z0-9_-]+':
+ if:
+ type: object
+ description: node for pinctrl.
+ $ref: "pinmux-node.yaml"
+ then:
+ properties:
+ groups:
+ description: Name of the pin group to use for the functions.
+ enum: [i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, mdio,
+ pcie, sdhci]
+ function:
+ description: The mux function to select
+ enum: [gpio, i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2,
+ mdio, nand1, nand2, sdhci]
+
+additionalProperties: false
+
+examples:
+ # Pinmux controller node
+ - |
+ pinctrl {
+ compatible = "ralink,rt2880-pinmux";
+ pinctrl-names = "default";
+ pinctrl-0 = <&state_default>;
+
+ state_default: pinctrl0 {
+ };
+
+ i2c_pins: i2c0 {
+ i2c0 {
+ groups = "i2c";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
new file mode 100644
index 0000000..d14cb9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -0,0 +1,293 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/mediatek,power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Power Domains Controller
+
+maintainers:
+ - Weiyi Lu <weiyi.lu@mediatek.com>
+ - Matthias Brugger <mbrugger@suse.com>
+
+description: |
+ Mediatek processors include support for multiple power domains which can be
+ powered up/down by software based on different application scenes to save power.
+
+ IP cores belonging to a power domain should contain a 'power-domains'
+ property that is a phandle for SCPSYS node representing the domain.
+
+properties:
+ $nodename:
+ const: power-controller
+
+ compatible:
+ enum:
+ - mediatek,mt8173-power-controller
+ - mediatek,mt8183-power-controller
+ - mediatek,mt8192-power-controller
+
+ '#power-domain-cells':
+ const: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^power-domain@[0-9a-f]+$":
+ type: object
+ description: |
+ Represents the power domains within the power controller node as documented
+ in Documentation/devicetree/bindings/power/power-domain.yaml.
+
+ properties:
+
+ '#power-domain-cells':
+ description:
+ Must be 0 for nodes representing a single PM domain and 1 for nodes
+ providing multiple PM domains.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ description: |
+ Power domain index. Valid values are defined in:
+ "include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain.
+ "include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain.
+ "include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain.
+ maxItems: 1
+
+ clocks:
+ description: |
+ A number of phandles to clocks that need to be enabled during domain
+ power-up sequencing.
+
+ clock-names:
+ description: |
+ List of names of clocks, in order to match the power-up sequencing
+ for each power domain we need to group the clocks by name. BASIC
+ clocks need to be enabled before enabling the corresponding power
+ domain, and should not have a '-' in their name (i.e mm, mfg, venc).
+ SUSBYS clocks need to be enabled before releasing the bus protection,
+ and should contain a '-' in their name (i.e mm-0, isp-0, cam-0).
+
+ In order to follow properly the power-up sequencing, the clocks must
+ be specified by order, adding first the BASIC clocks followed by the
+ SUSBSYS clocks.
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the INFRACFG register range.
+
+ mediatek,smi:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the SMI register range.
+
+ patternProperties:
+ "^power-domain@[0-9a-f]+$":
+ type: object
+ description: |
+ Represents a power domain child within a power domain parent node.
+
+ properties:
+
+ '#power-domain-cells':
+ description:
+ Must be 0 for nodes representing a single PM domain and 1 for nodes
+ providing multiple PM domains.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: |
+ A number of phandles to clocks that need to be enabled during domain
+ power-up sequencing.
+
+ clock-names:
+ description: |
+ List of names of clocks, in order to match the power-up sequencing
+ for each power domain we need to group the clocks by name. BASIC
+ clocks need to be enabled before enabling the corresponding power
+ domain, and should not have a '-' in their name (i.e mm, mfg, venc).
+ SUSBYS clocks need to be enabled before releasing the bus protection,
+ and should contain a '-' in their name (i.e mm-0, isp-0, cam-0).
+
+ In order to follow properly the power-up sequencing, the clocks must
+ be specified by order, adding first the BASIC clocks followed by the
+ SUSBSYS clocks.
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the INFRACFG register range.
+
+ mediatek,smi:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the SMI register range.
+
+ patternProperties:
+ "^power-domain@[0-9a-f]+$":
+ type: object
+ description: |
+ Represents a power domain child within a power domain parent node.
+
+ properties:
+
+ '#power-domain-cells':
+ description:
+ Must be 0 for nodes representing a single PM domain and 1 for nodes
+ providing multiple PM domains.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: |
+ A number of phandles to clocks that need to be enabled during domain
+ power-up sequencing.
+
+ clock-names:
+ description: |
+ List of names of clocks, in order to match the power-up sequencing
+ for each power domain we need to group the clocks by name. BASIC
+ clocks need to be enabled before enabling the corresponding power
+ domain, and should not have a '-' in their name (i.e mm, mfg, venc).
+ SUSBYS clocks need to be enabled before releasing the bus protection,
+ and should contain a '-' in their name (i.e mm-0, isp-0, cam-0).
+
+ In order to follow properly the power-up sequencing, the clocks must
+ be specified by order, adding first the BASIC clocks followed by the
+ SUSBSYS clocks.
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the INFRACFG register range.
+
+ mediatek,smi:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the SMI register range.
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/power/mt8173-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ scpsys: syscon@10006000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0 0x10006000 0 0x1000>;
+
+ spm: power-controller {
+ compatible = "mediatek,mt8173-power-controller";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #power-domain-cells = <1>;
+
+ /* power domains of the SoC */
+ power-domain@MT8173_POWER_DOMAIN_VDEC {
+ reg = <MT8173_POWER_DOMAIN_VDEC>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>;
+ clock-names = "mm";
+ #power-domain-cells = <0>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_VENC {
+ reg = <MT8173_POWER_DOMAIN_VENC>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>,
+ <&topckgen CLK_TOP_VENC_SEL>;
+ clock-names = "mm", "venc";
+ #power-domain-cells = <0>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_ISP {
+ reg = <MT8173_POWER_DOMAIN_ISP>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>;
+ clock-names = "mm";
+ #power-domain-cells = <0>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_MM {
+ reg = <MT8173_POWER_DOMAIN_MM>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>;
+ clock-names = "mm";
+ #power-domain-cells = <0>;
+ mediatek,infracfg = <&infracfg>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_VENC_LT {
+ reg = <MT8173_POWER_DOMAIN_VENC_LT>;
+ clocks = <&topckgen CLK_TOP_MM_SEL>,
+ <&topckgen CLK_TOP_VENC_LT_SEL>;
+ clock-names = "mm", "venclt";
+ #power-domain-cells = <0>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_AUDIO {
+ reg = <MT8173_POWER_DOMAIN_AUDIO>;
+ #power-domain-cells = <0>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_USB {
+ reg = <MT8173_POWER_DOMAIN_USB>;
+ #power-domain-cells = <0>;
+ };
+ power-domain@MT8173_POWER_DOMAIN_MFG_ASYNC {
+ reg = <MT8173_POWER_DOMAIN_MFG_ASYNC>;
+ clocks = <&clk26m>;
+ clock-names = "mfg";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #power-domain-cells = <1>;
+
+ power-domain@MT8173_POWER_DOMAIN_MFG_2D {
+ reg = <MT8173_POWER_DOMAIN_MFG_2D>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #power-domain-cells = <1>;
+
+ power-domain@MT8173_POWER_DOMAIN_MFG {
+ reg = <MT8173_POWER_DOMAIN_MFG>;
+ #power-domain-cells = <0>;
+ mediatek,infracfg = <&infracfg>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 8058955..6482512 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -16,12 +16,16 @@
properties:
compatible:
enum:
+ - qcom,msm8916-rpmpd
+ - qcom,msm8939-rpmpd
- qcom,msm8976-rpmpd
- qcom,msm8996-rpmpd
- qcom,msm8998-rpmpd
- qcom,qcs404-rpmpd
+ - qcom,sdm660-rpmpd
- qcom,sc7180-rpmhpd
- qcom,sdm845-rpmhpd
+ - qcom,sdx55-rpmhpd
- qcom,sm8150-rpmhpd
- qcom,sm8250-rpmhpd
diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 4d530d8..c5de7b5 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -7,7 +7,9 @@
microchip Sparx5 armv8 SoC's.
Required Properties:
- - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
+
+ - compatible: "mscc,ocelot-chip-reset", "mscc,luton-chip-reset",
+ "mscc,jaguar2-chip-reset" or "microchip,sparx5-chip-reset"
Example:
reset@1070008 {
diff --git a/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml
new file mode 100644
index 0000000..03bd1fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/regulator-poweroff.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Force-disable power regulator to turn the power off.
+
+maintainers:
+ - Michael Klein <michael@fossekall.de>
+
+description: |
+ When the power-off handler is called, a power regulator is disabled by
+ calling regulator_force_disable(). If the power is still on and the
+ CPU still running after a 3000ms delay, a warning is emitted.
+
+properties:
+ compatible:
+ const: "regulator-poweroff"
+
+ cpu-supply:
+ description:
+ regulator to disable on power-down
+
+required:
+ - compatible
+ - cpu-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ regulator-poweroff {
+ compatible = "regulator-poweroff";
+ cpu-supply = <®_vcc1v2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
index ee92e6a..5fcdf58 100644
--- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
+++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
@@ -27,7 +27,7 @@
of this binary blob is kept secret by CellWise. The only way to obtain
it is to mail two batteries to a test facility of CellWise and receive
back a test report with the binary blob.
- $ref: /schemas/types.yaml#definitions/uint8-array
+ $ref: /schemas/types.yaml#/definitions/uint8-array
minItems: 64
maxItems: 64
diff --git a/Documentation/devicetree/bindings/powerpc/sleep.yaml b/Documentation/devicetree/bindings/powerpc/sleep.yaml
index 6494c7d..1b0936a 100644
--- a/Documentation/devicetree/bindings/powerpc/sleep.yaml
+++ b/Documentation/devicetree/bindings/powerpc/sleep.yaml
@@ -42,6 +42,6 @@
properties:
sleep:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
deleted file mode 100644
index 985fcc6..0000000
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Atmel TCB PWM controller
-
-Required properties:
-- compatible: should be "atmel,tcb-pwm"
-- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of
- the cells format. The only third cell flag supported by this binding is
- PWM_POLARITY_INVERTED.
-- tc-block: The Timer Counter block to use as a PWM chip.
-
-Example:
-
-pwm {
- compatible = "atmel,tcb-pwm";
- #pwm-cells = <3>;
- tc-block = <1>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml
new file mode 100644
index 0000000..ff6880a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Intel Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/intel,keembay-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Keem Bay PWM Device Tree Bindings
+
+maintainers:
+ - Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ enum:
+ - intel,keembay-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#pwm-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #define KEEM_BAY_A53_GPIO
+
+ pwm@203200a0 {
+ compatible = "intel,keembay-pwm";
+ reg = <0x203200a0 0xe8>;
+ clocks = <&scmi_clk KEEM_BAY_A53_GPIO>;
+ #pwm-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
new file mode 100644
index 0000000..11a6065
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LGM SoC PWM fan controller
+
+maintainers:
+ - Rahul Tanwar <rtanwar@maxlinear.com>
+
+properties:
+ compatible:
+ const: intel,lgm-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm: pwm@e0d00000 {
+ compatible = "intel,lgm-pwm";
+ reg = <0xe0d00000 0x30>;
+ #pwm-cells = <2>;
+ clocks = <&cgu0 126>;
+ resets = <&rcu0 0x30 21>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 29adff5..25ed214 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -7,6 +7,7 @@
- "mediatek,mt7623-pwm": found on mt7623 SoC.
- "mediatek,mt7628-pwm": found on mt7628 SoC.
- "mediatek,mt7629-pwm": found on mt7629 SoC.
+ - "mediatek,mt8183-pwm": found on mt8183 SoC.
- "mediatek,mt8516-pwm": found on mt8516 SoC.
- reg: physical base address and length of the controller's registers.
- #pwm-cells: must be 2. See pwm.yaml in this directory for a description of
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
index 0521957..902b271 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
@@ -4,6 +4,7 @@
- compatible: should be "mediatek,<name>-disp-pwm":
- "mediatek,mt2701-disp-pwm": found on mt2701 SoC.
- "mediatek,mt6595-disp-pwm": found on mt6595 SoC.
+ - "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm": found on mt8167 SoC.
- "mediatek,mt8173-disp-pwm": found on mt8173 SoC.
- reg: physical base address and length of the controller's registers.
- #pwm-cells: must be 2. See pwm.yaml in this directory for a description of
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
index e7b3abe..0a66338 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
@@ -59,7 +59,6 @@
description: u32 value representing regulator enable bit offset.
vin-supply:
- $ref: '/schemas/types.yaml#/definitions/phandle'
description: input supply phandle.
required:
diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
new file mode 100644
index 0000000..6f2164f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
@@ -0,0 +1,189 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/dlg,da9121.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA9121 voltage regulator
+
+maintainers:
+ - Adam Ward <Adam.Ward.opensource@diasemi.com>
+
+description: |
+ Dialog Semiconductor DA9121 Single-channel 10A double-phase buck converter
+ Dialog Semiconductor DA9122 Double-channel 5A single-phase buck converter
+ Dialog Semiconductor DA9220 Double-channel 3A single-phase buck converter
+ Dialog Semiconductor DA9217 Single-channel 6A double-phase buck converter
+ Dialog Semiconductor DA9130 Single-channel 10A double-phase buck converter
+ Dialog Semiconductor DA9131 Double-channel 5A single-phase buck converter
+ Dialog Semiconductor DA9132 Double-channel 3A single-phase buck converter
+
+ Current limits
+
+ This is PER PHASE, and the current limit setting in the devices reflect
+ that with a maximum 10A limit. Allowing for transients at/near double
+ the rated current, this translates across the device range to per
+ channel figures as so...
+
+ | DA9121 DA9122 DA9220 DA9217 DA9140
+ | /DA9130 /DA9131 /DA9132
+ -----------------------------------------------------------------------------
+ Output current / channel | 10000000 5000000 3000000 6000000 40000000
+ Output current / phase | 5000000 5000000 3000000 3000000 9500000
+ -----------------------------------------------------------------------------
+ Min regulator-min-microvolt| 300000 300000 300000 300000 500000
+ Max regulator-max-microvolt| 1900000 1900000 1900000 1900000 1000000
+ Device hardware default | 1000000 1000000 1000000 1000000 1000000
+ -----------------------------------------------------------------------------
+ Min regulator-min-microamp | 7000000 3500000 3500000 7000000 26000000
+ Max regulator-max-microamp | 20000000 10000000 6000000 12000000 78000000
+ Device hardware default | 15000000 7500000 5500000 11000000 58000000
+
+properties:
+ $nodename:
+ pattern: "pmic@[0-9a-f]{1,2}"
+ compatible:
+ enum:
+ - dlg,da9121
+ - dlg,da9122
+ - dlg,da9220
+ - dlg,da9217
+ - dlg,da9130
+ - dlg,da9131
+ - dlg,da9132
+ - dlg,da9140
+
+ reg:
+ maxItems: 1
+ description: Specifies the I2C slave address.
+
+ interrupts:
+ maxItems: 1
+ description: IRQ line information.
+
+ dlg,irq-polling-delay-passive-ms:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ minimum: 1000
+ maximum: 10000
+ description: |
+ Specify the polling period, measured in milliseconds, between interrupt status
+ update checks. Range 1000-10000 ms.
+
+ regulators:
+ type: object
+ $ref: regulator.yaml#
+ description: |
+ This node defines the settings for the BUCK. The content of the
+ sub-node is defined by the standard binding for regulators; see regulator.yaml.
+ The DA9121 regulator is bound using their names listed below
+ buck1 - BUCK1
+ buck2 - BUCK2 //DA9122, DA9220, DA9131, DA9132 only
+
+ patternProperties:
+ "^buck([1-2])$":
+ type: object
+ $ref: regulator.yaml#
+
+ properties:
+ regulator-mode:
+ maxItems: 1
+ description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
+
+ regulator-initial-mode:
+ maxItems: 1
+ description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
+
+ enable-gpios:
+ maxItems: 1
+ description: Specify a valid GPIO for platform control of the regulator
+
+ dlg,ripple-cancel:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ description: |
+ Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
+ Only present on multi-channel devices (DA9122, DA9220, DA9131, DA9132)
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/dlg,da9121-regulator.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@68 {
+ compatible = "dlg,da9121";
+ reg = <0x68>;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ dlg,irq-polling-delay-passive-ms = <2000>;
+
+ regulators {
+ DA9121_BUCK1: buck1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-min-microamp = <7000000>;
+ regulator-max-microamp = <20000000>;
+ regulator-boot-on;
+ regulator-initial-mode = <DA9121_BUCK_MODE_AUTO>;
+ enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/dlg,da9121-regulator.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@68 {
+ compatible = "dlg,da9122";
+ reg = <0x68>;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ dlg,irq-polling-delay-passive-ms = <2000>;
+
+ regulators {
+ DA9122_BUCK1: buck1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-min-microamp = <3500000>;
+ regulator-max-microamp = <10000000>;
+ regulator-boot-on;
+ regulator-initial-mode = <DA9121_BUCK_MODE_AUTO>;
+ enable-gpios = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ dlg,ripple-cancel = <DA9121_BUCK_RIPPLE_CANCEL_NONE>;
+ };
+ DA9122_BUCK2: buck2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-min-microamp = <3500000>;
+ regulator-max-microamp = <10000000>;
+ regulator-boot-on;
+ regulator-initial-mode = <DA9121_BUCK_MODE_AUTO>;
+ enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
+ dlg,ripple-cancel = <DA9121_BUCK_RIPPLE_CANCEL_NONE>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
index 92211f2..d3d0dc1 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
@@ -26,12 +26,22 @@
const: regulator-fixed-clock
required:
- clocks
+else:
+ if:
+ properties:
+ compatible:
+ contains:
+ const: regulator-fixed-domain
+ required:
+ - power-domains
+ - required-opps
properties:
compatible:
enum:
- regulator-fixed
- regulator-fixed-clock
+ - regulator-fixed-domain
regulator-name: true
@@ -46,6 +56,20 @@
is mandatory if compatible is chosen to regulator-fixed-clock.
maxItems: 1
+ power-domains:
+ description:
+ Power domain to use for enable control. This binding is only
+ available if the compatible is chosen to regulator-fixed-domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ Performance state to use for enable control. This binding is only
+ available if the compatible is chosen to regulator-fixed-domain. The
+ power-domain binding is mandatory if compatible is chosen to
+ regulator-fixed-domain.
+ maxItems: 1
+
startup-delay-us:
description: startup time in microseconds
$ref: /schemas/types.yaml#/definitions/uint32
@@ -89,4 +113,27 @@
gpio-open-drain;
vin-supply = <&parent_reg>;
};
+ reg_1v8_clk: regulator-1v8-clk {
+ compatible = "regulator-fixed-clock";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ clocks = <&clock1>;
+ startup-delay-us = <70000>;
+ enable-active-high;
+ regulator-boot-on;
+ vin-supply = <&parent_reg>;
+ };
+ reg_1v8_domain: regulator-1v8-domain {
+ compatible = "regulator-fixed-domain";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ power-domains = <&domain1>;
+ required-opps = <&domain1_state1>;
+ startup-delay-us = <70000>;
+ enable-active-high;
+ regulator-boot-on;
+ vin-supply = <&parent_reg>;
+ };
...
diff --git a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
index b8f843f..d86584e 100644
--- a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
@@ -10,7 +10,7 @@
name. The content of each sub-node is defined by the
standard binding for regulators; see regulator.txt.
-Regualtors of MCP16502 PMIC:
+Regulators of MCP16502 PMIC:
1) VDD_IO - Buck (1.2 - 3.7 V)
2) VDD_DDR - Buck (0.6 - 1.85 V)
3) VDD_CORE - Buck (0.6 - 1.85 V)
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
new file mode 100644
index 0000000..a6c259c
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
@@ -0,0 +1,211 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/nxp,pf8x00-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PF8100/PF8121A/PF8200 PMIC regulators
+
+maintainers:
+ - Jagan Teki <jagan@amarulasolutions.com>
+ - Troy Kisky <troy.kisky@boundarydevices.com>
+
+description: |
+ PF8100/PF8121A/PF8200 is a PMIC designed for highperformance consumer
+ applications. It features seven high efficiency buck converters, four
+ linear and one vsnvs regulators. It has built-in one time programmable
+ fuse bank for device configurations.
+
+properties:
+ compatible:
+ enum:
+ - nxp,pf8x00
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: |
+ list of regulators provided by this controller
+
+ patternProperties:
+ "^ldo[1-4]$":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ Properties for single LDO regulator.
+
+ properties:
+ regulator-name:
+ pattern: "^ldo[1-4]$"
+ description:
+ should be "ldo1", ..., "ldo4"
+
+ unevaluatedProperties: false
+
+ "^buck[1-7]$":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ Properties for single BUCK regulator.
+
+ properties:
+ regulator-name:
+ pattern: "^buck[1-7]$"
+ description:
+ should be "buck1", ..., "buck7"
+
+ nxp,ilim-ma:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ minimum: 2100
+ maximum: 4500
+ description:
+ BUCK regulators current limit in mA.
+
+ Listed current limits in mA are,
+ 2100 (default)
+ 2600
+ 3000
+ 4500
+
+ nxp,phase-shift:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ minimum: 45
+ maximum: 0
+ description:
+ BUCK regulators phase shift control in degrees.
+
+ Listed phase shift control values in degrees are,
+ 45
+ 90
+ 135
+ 180
+ 225
+ 270
+ 315
+ 0 (default)
+
+ unevaluatedProperties: false
+
+ "^vsnvs$":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ Properties for single VSNVS regulator.
+
+ properties:
+ regulator-name:
+ pattern: "^vsnvs$"
+ description:
+ should be "vsnvs"
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "nxp,pf8x00";
+ reg = <0x08>;
+
+ regulators {
+ reg_ldo1: ldo1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <1500000>;
+ };
+
+ reg_ldo2: ldo2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <1500000>;
+ };
+
+ reg_ldo3: ldo3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <1500000>;
+ };
+
+ reg_ldo4: ldo4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <1500000>;
+ };
+
+ reg_buck1: buck1 {
+ nxp,ilim-ma = <4500>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <400000>;
+ };
+
+ reg_buck2: buck2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <400000>;
+ };
+
+ reg_buck3: buck3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <400000>;
+ };
+
+ reg_buck4: buck4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <400000>;
+ };
+
+ reg_buck5: buck5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <400000>;
+ };
+
+ reg_buck6: buck6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <400000>;
+ };
+
+ reg_buck7: buck7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reg_vsnvs: vsnvs {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <1800000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
index 97c3e0b..b8f0b78 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -26,10 +26,13 @@
PM8009: smps1 - smps2, ldo1 - ldo7
PM8150: smps1 - smps10, ldo1 - ldo18
PM8150L: smps1 - smps8, ldo1 - ldo11, bob, flash, rgb
+ PM8350: smps1 - smps12, ldo1 - ldo10,
+ PM8350C: smps1 - smps10, ldo1 - ldo13, bob
PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
PMI8998: bob
PM6150: smps1 - smps5, ldo1 - ldo19
PM6150L: smps1 - smps8, ldo1 - ldo11, bob
+ PMX55: smps1 - smps7, ldo1 - ldo16
========================
First Level Nodes - PMIC
@@ -43,10 +46,13 @@
"qcom,pm8009-rpmh-regulators"
"qcom,pm8150-rpmh-regulators"
"qcom,pm8150l-rpmh-regulators"
+ "qcom,pm8350-rpmh-regulators"
+ "qcom,pm8350c-rpmh-regulators"
"qcom,pm8998-rpmh-regulators"
"qcom,pmi8998-rpmh-regulators"
"qcom,pm6150-rpmh-regulators"
"qcom,pm6150l-rpmh-regulators"
+ "qcom,pmx55-rpmh-regulators"
- qcom,pmic-id
Usage: required
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
index f5e3119..1941b36 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
@@ -105,6 +105,54 @@
PMIC hardware state machine.
type: boolean
+ # Setups where regulator (especially the buck8) output voltage is scaled
+ # by adding external connection where some other regulator output is
+ # connected to feedback-pin (over suitable resistors) is getting popular
+ # amongst users of BD71837. (This allows for example scaling down the
+ # buck8 voltages to suit lover GPU voltages for projects where buck8 is
+ # (ab)used to supply power for GPU.
+ #
+ # So we allow describing this external connection from DT and scale the
+ # voltages accordingly. This is what the connection should look like:
+ #
+ # |---------------|
+ # | buck 8 |-------+----->Vout
+ # | | |
+ # |---------------| |
+ # | |
+ # | |
+ # +-------+--R2----+
+ # |
+ # R1
+ # |
+ # V FB-pull-up
+ #
+ # Here the buck output is sifted according to formula:
+ #
+ # Vout_o = Vo - (Vpu - Vo)*R2/R1
+ # Linear_step = step_orig*(R1+R2)/R1
+ #
+ # where:
+ # Vout_o is adjusted voltage output at vsel reg value 0
+ # Vo is original voltage output at vsel reg value 0
+ # Vpu is the pull-up voltage V FB-pull-up in the picture
+ # R1 and R2 are resistor values.
+
+ rohm,fb-pull-up-microvolt:
+ description:
+ Feedback-pin has pull-up connection to adjust voltage range. This is
+ the used pull-up voltage before R1.
+
+ rohm,feedback-pull-up-r1-ohms:
+ description:
+ Feedback-pin has pull-up connection to adjust voltage range. This is
+ the used R1 resistor.
+
+ rohm,feedback-pull-up-r2-ohms:
+ description:
+ Feedback-pin has pull-up connection to adjust voltage range. This is
+ the used R2 resistor.
+
required:
- regulator-name
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
index eeac32c..a1b8063 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
@@ -99,6 +99,55 @@
Enable/Disable control of this regulator must be left to the
PMIC hardware state machine.
type: boolean
+
+ # Setups where regulator (especially the buck8) output voltage is scaled
+ # by adding external connection where some other regulator output is
+ # connected to feedback-pin (over suitable resistors) is getting popular
+ # amongst users of BD71837. (This allows for example scaling down the
+ # buck8 voltages to suit lover GPU voltages for projects where buck8 is
+ # (ab)used to supply power for GPU.
+ #
+ # So we allow describing this external connection from DT and scale the
+ # voltages accordingly. This is what the connection should look like:
+ #
+ # |---------------|
+ # | buck 8 |-------+----->Vout
+ # | | |
+ # |---------------| |
+ # | |
+ # | |
+ # +-------+--R2----+
+ # |
+ # R1
+ # |
+ # V FB-pull-up
+ #
+ # Here the buck output is sifted according to formula:
+ #
+ # Vout_o = Vo - (Vpu - Vo)*R2/R1
+ # Linear_step = step_orig*(R1+R2)/R1
+ #
+ # where:
+ # Vout_o is adjusted voltage output at vsel reg value 0
+ # Vo is original voltage output at vsel reg value 0
+ # Vpu is the pull-up voltage V FB-pull-up in the picture
+ # R1 and R2 are resistor values.
+
+ rohm,fb-pull-up-microvolt:
+ description:
+ Feedback-pin has pull-up connection to adjust voltage range. This is
+ the used pull-up voltage before R1.
+
+ rohm,feedback-pull-up-r1-ohms:
+ description:
+ Feedback-pin has pull-up connection to adjust voltage range. This is
+ the used R1 resistor.
+
+ rohm,feedback-pull-up-r2-ohms:
+ description:
+ Feedback-pin has pull-up connection to adjust voltage range. This is
+ the used R2 resistor.
+
required:
- regulator-name
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index 1f9a62e..7ccd553 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -113,8 +113,8 @@
For the compatible strings below the following supplies are required:
"qcom,q6v5-pil"
"qcom,msm8916-mss-pil",
-- cx-supply:
-- mx-supply:
+- cx-supply: (deprecated, use power domain instead)
+- mx-supply: (deprecated, use power domain instead)
- pll-supply:
Usage: required
Value type: <phandle>
@@ -123,9 +123,9 @@
For the compatible string below the following supplies are required:
"qcom,msm8974-mss-pil"
-- cx-supply:
+- cx-supply: (deprecated, use power domain instead)
- mss-supply:
-- mx-supply:
+- mx-supply: (deprecated, use power domain instead)
- pll-supply:
Usage: required
Value type: <phandle>
@@ -149,11 +149,11 @@
Usage: required
Value type: <stringlist>
Definition: The power-domains needed depend on the compatible string:
- qcom,q6v5-pil:
qcom,ipq8074-wcss-pil:
+ no power-domain names required
+ qcom,q6v5-pil:
qcom,msm8916-mss-pil:
qcom,msm8974-mss-pil:
- no power-domain names required
qcom,msm8996-mss-pil:
qcom,msm8998-mss-pil:
must be "cx", "mx"
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
index d420f84..cc0b7fc 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
@@ -34,14 +34,25 @@
Definition: should be "wdog", "fatal", optionally followed by "ready",
"handover", "stop-ack"
-- vddmx-supply:
-- vddcx-supply:
+- vddmx-supply: (deprecated for qcom,pronto-v1/2-pil)
+- vddcx-supply: (deprecated for qcom,pronto-v1/2-pil)
- vddpx-supply:
Usage: required
Value type: <phandle>
Definition: reference to the regulators to be held on behalf of the
booting of the WCNSS core
+- power-domains:
+ Usage: required (for qcom,pronto-v1/2-pil)
+ Value type: <phandle>
+ Definition: reference to the power domains to be held on behalf of the
+ booting of the WCNSS core
+
+- power-domain-names:
+ Usage: required (for qcom,pronto-v1/2-pil)
+ Value type: <stringlist>
+ Definition: must be "cx", "mx"
+
- qcom,smem-states:
Usage: optional
Value type: <prop-encoded-array>
@@ -111,8 +122,9 @@
<&wcnss_smp2p_slave 3 0>;
interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
- vddmx-supply = <&pm8841_s1>;
- vddcx-supply = <&pm8841_s2>;
+ power-domains = <&rpmpd MSM8974_VDDCX>, <&rpmpd MSM8974_VDDMX>;
+ power-domain-names = "cx", "mx";
+
vddpx-supply = <&pm8941_s3>;
qcom,smem-states = <&wcnss_smp2p_out 0>;
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
index 4ffa252..a1171df 100644
--- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
@@ -38,9 +38,6 @@
st,syscfg-tz:
description:
Reference to the system configuration which holds the RCC trust zone mode
- - Phandle of syscon block.
- - The offset of the RCC trust zone mode register.
- - The field mask of the RCC trust zone mode.
$ref: "/schemas/types.yaml#/definitions/phandle-array"
maxItems: 1
@@ -91,9 +88,19 @@
$ref: "/schemas/types.yaml#/definitions/phandle-array"
description: |
Reference to the system configuration which holds the remote
- 1st cell: phandle to syscon block
- 2nd cell: register offset containing the deep sleep setting
- 3rd cell: register bitmask for the deep sleep bit
+ maxItems: 1
+
+ st,syscfg-m4-state:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ description: |
+ Reference to the tamp register which exposes the Cortex-M4 state.
+ maxItems: 1
+
+ st,syscfg-rsc-tbl:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ description: |
+ Reference to the tamp register which references the Cortex-M4
+ resource table address.
maxItems: 1
st,auto-boot:
@@ -122,6 +129,8 @@
resets = <&rcc MCU_R>;
st,syscfg-holdboot = <&rcc 0x10C 0x1>;
st,syscfg-tz = <&rcc 0x000 0x1>;
+ st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
+ st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
};
...
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
index 4069f0f5..d905d61 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
@@ -32,6 +32,7 @@
enum:
- ti,am654-r5fss
- ti,j721e-r5fss
+ - ti,j7200-r5fss
power-domains:
description: |
@@ -95,6 +96,7 @@
enum:
- ti,am654-r5f
- ti,j721e-r5f
+ - ti,j7200-r5f
reg:
items:
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
new file mode 100644
index 0000000..63071ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
@@ -0,0 +1,214 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,pru-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Programmable Realtime Unit (PRU) cores
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+
+description: |
+ Each Programmable Real-Time Unit and Industrial Communication Subsystem
+ (PRU-ICSS or PRUSS) has two 32-bit load/store RISC CPU cores called
+ Programmable Real-Time Units (PRUs), each represented by a node. Each PRU
+ core has a dedicated Instruction RAM, Control and Debug register sets, and
+ use the Data RAMs present within the PRU-ICSS for code execution.
+
+ The K3 SoCs containing ICSSG v1.0 (eg: AM65x SR1.0) also have two Auxiliary
+ PRU cores called RTUs with slightly different IP integration. The K3 SoCs
+ containing the revised ICSSG v1.1 (eg: J721E, AM65x SR2.0) have an extra two
+ auxiliary Transmit PRU cores called Tx_PRUs that augment the PRUs. Each RTU
+ or Tx_PRU core can also be used independently like a PRU, or alongside a
+ corresponding PRU core to provide/implement auxiliary functionality/support.
+
+ Each PRU, RTU or Tx_PRU core node should be defined as a child node of the
+ corresponding PRU-ICSS node. Each node can optionally be rendered inactive by
+ using the standard DT string property, "status".
+
+ Please see the overall PRU-ICSS bindings document for additional details
+ including a complete example,
+ Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
+
+properties:
+ compatible:
+ enum:
+ - ti,am3356-pru # for AM335x SoC family (AM3356+ SoCs only)
+ - ti,am4376-pru # for AM437x SoC family (AM4376+ SoCs only)
+ - ti,am5728-pru # for AM57xx SoC family
+ - ti,k2g-pru # for 66AK2G SoC family
+ - ti,am654-pru # for PRUs in K3 AM65x SoC family
+ - ti,am654-rtu # for RTUs in K3 AM65x SoC family
+ - ti,am654-tx-pru # for Tx_PRUs in K3 AM65x SR2.0 SoCs
+ - ti,j721e-pru # for PRUs in K3 J721E SoC family
+ - ti,j721e-rtu # for RTUs in K3 J721E SoC family
+ - ti,j721e-tx-pru # for Tx_PRUs in K3 J721E SoC family
+
+ reg:
+ items:
+ - description: Address and Size of the PRU Instruction RAM
+ - description: Address and Size of the PRU CTRL sub-module registers
+ - description: Address and Size of the PRU Debug sub-module registers
+
+ reg-names:
+ items:
+ - const: iram
+ - const: control
+ - const: debug
+
+ firmware-name:
+ description: |
+ Should contain the name of the default firmware image
+ file located on the firmware search path.
+
+if:
+ properties:
+ compatible:
+ enum:
+ - ti,am654-rtu
+ - ti,j721e-rtu
+then:
+ properties:
+ $nodename:
+ pattern: "^rtu@[0-9a-f]+$"
+else:
+ if:
+ properties:
+ compatible:
+ enum:
+ - ti,am654-tx-pru
+ - ti,j721e-tx-pru
+ then:
+ properties:
+ $nodename:
+ pattern: "^txpru@[0-9a-f]+"
+ else:
+ properties:
+ $nodename:
+ pattern: "^pru@[0-9a-f]+$"
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - firmware-name
+
+additionalProperties: false
+
+examples:
+ - |
+ /* AM33xx PRU-ICSS */
+ pruss_tm: target-module@300000 { /* 0x4a300000, ap 9 04.0 */
+ compatible = "ti,sysc-pruss", "ti,sysc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x300000 0x80000>;
+
+ pruss: pruss@0 {
+ compatible = "ti,am3356-pruss";
+ reg = <0x0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pruss_mem: memories@0 {
+ reg = <0x0 0x2000>,
+ <0x2000 0x2000>,
+ <0x10000 0x3000>;
+ reg-names = "dram0", "dram1", "shrdram2";
+ };
+
+ pru0: pru@34000 {
+ compatible = "ti,am3356-pru";
+ reg = <0x34000 0x2000>,
+ <0x22000 0x400>,
+ <0x22400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am335x-pru0-fw";
+ };
+
+ pru1: pru@38000 {
+ compatible = "ti,am3356-pru";
+ reg = <0x38000 0x2000>,
+ <0x24000 0x400>,
+ <0x24400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am335x-pru1-fw";
+ };
+ };
+ };
+
+ - |
+ /* AM65x SR2.0 ICSSG */
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ icssg0: icssg@b000000 {
+ compatible = "ti,am654-icssg";
+ reg = <0xb000000 0x80000>;
+ power-domains = <&k3_pds 62 TI_SCI_PD_EXCLUSIVE>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xb000000 0x80000>;
+
+ icssg0_mem: memories@0 {
+ reg = <0x0 0x2000>,
+ <0x2000 0x2000>,
+ <0x10000 0x10000>;
+ reg-names = "dram0", "dram1", "shrdram2";
+ };
+
+ pru0_0: pru@34000 {
+ compatible = "ti,am654-pru";
+ reg = <0x34000 0x4000>,
+ <0x22000 0x100>,
+ <0x22400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-pru0_0-fw";
+ };
+
+ rtu0_0: rtu@4000 {
+ compatible = "ti,am654-rtu";
+ reg = <0x4000 0x2000>,
+ <0x23000 0x100>,
+ <0x23400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-rtu0_0-fw";
+ };
+
+ tx_pru0_0: txpru@a000 {
+ compatible = "ti,am654-tx-pru";
+ reg = <0xa000 0x1800>,
+ <0x25000 0x100>,
+ <0x25400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-txpru0_0-fw";
+ };
+
+ pru0_1: pru@38000 {
+ compatible = "ti,am654-pru";
+ reg = <0x38000 0x4000>,
+ <0x24000 0x100>,
+ <0x24400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-pru0_1-fw";
+ };
+
+ rtu0_1: rtu@6000 {
+ compatible = "ti,am654-rtu";
+ reg = <0x6000 0x2000>,
+ <0x23800 0x100>,
+ <0x23c00 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-rtu0_1-fw";
+ };
+
+ tx_pru0_1: txpru@c000 {
+ compatible = "ti,am654-tx-pru";
+ reg = <0xc000 0x1800>,
+ <0x25800 0x100>,
+ <0x25c00 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-txpru0_1-fw";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml
new file mode 100644
index 0000000..560cf65
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/brcm,bcm6345-reset.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: BCM6345 reset controller
+
+description: This document describes the BCM6345 reset controller.
+
+maintainers:
+ - Álvaro Fernández Rojas <noltari@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,bcm6345-reset
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ reset-controller@10000010 {
+ compatible = "brcm,bcm6345-reset";
+ reg = <0x10000010 0x4>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
index f94f911..0c241d4 100644
--- a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
+++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
@@ -23,7 +23,7 @@
#reset-cells = <1>;
};
- dw_rst_2: reset-controller@1000 {i
+ dw_rst_2: reset-controller@1000 {
compatible = "snps,dw-low-reset";
reg = <0x1000 0x8>;
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
index 8acd2de..d30dc04 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
@@ -63,6 +63,11 @@
description:
Enables wake up of host system on alarm.
+ reset-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The RTC is able to reset the machine.
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index c1d4c19..f54cae9 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -126,7 +126,7 @@
maxItems: 1
current-speed:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: The current active speed of the UART.
reg-offset:
@@ -154,7 +154,7 @@
Set to indicate that the port does not implement loopback test mode.
fifo-size:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: The fifo size of the UART.
auto-flow-control:
@@ -165,7 +165,7 @@
property.
tx-threshold:
- $ref: /schemas/types.yaml#definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Specify the TX FIFO low water indication for parts with programmable
TX FIFO thresholds.
diff --git a/Documentation/devicetree/bindings/serial/litex,liteuart.yaml b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
new file mode 100644
index 0000000..c4f1f48
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LiteUART serial controller
+
+maintainers:
+ - Karol Gugala <kgugala@antmicro.com>
+ - Mateusz Holenko <mholenko@antmicro.com>
+
+description: |
+ LiteUART serial controller is a part of the LiteX FPGA SoC builder. It supports
+ multiple CPU architectures, currently including e.g. OpenRISC and RISC-V.
+
+properties:
+ compatible:
+ const: litex,liteuart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ uart0: serial@e0001800 {
+ compatible = "litex,liteuart";
+ reg = <0xe0001800 0x100>;
+ interrupts = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index dcba86b..c2db8ca 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller
Required properties:
+- compatible : should be "ti,am64-uart", "ti,am654-uart" for AM64 controllers
- compatible : should be "ti,j721e-uart", "ti,am654-uart" for J721E controllers
- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index eda3d2c..6721589 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -60,6 +60,7 @@
- renesas,scif-r8a77980 # R-Car V3H
- renesas,scif-r8a77990 # R-Car E3
- renesas,scif-r8a77995 # R-Car D3
+ - renesas,scif-r8a779a0 # R-Car V3U
- const: renesas,rcar-gen3-scif # R-Car Gen3 and RZ/G2
- const: renesas,scif # generic SCIF compatible UART
diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
index 92283f6..3ac5c7f 100644
--- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
@@ -17,7 +17,9 @@
properties:
compatible:
items:
- - const: sifive,fu540-c000-uart
+ - enum:
+ - sifive,fu540-c000-uart
+ - sifive,fu740-c000-uart
- const: sifive,uart0
description:
diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
new file mode 100644
index 0000000..c8b57c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright 2020 Antmicro <www.antmicro.com>
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: LiteX SoC Controller driver
+
+description: |
+ This is the SoC Controller driver for the LiteX SoC Builder.
+ Its purpose is to verify LiteX CSR (Control&Status Register) access
+ operations and provide functions for other drivers to read/write CSRs
+ and to check if those accessors are ready to be used.
+
+maintainers:
+ - Karol Gugala <kgugala@antmicro.com>
+ - Mateusz Holenko <mholenko@antmicro.com>
+
+properties:
+ compatible:
+ const: litex,soc-controller
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc_ctrl0: soc-controller@f0000000 {
+ compatible = "litex,soc-controller";
+ reg = <0xf0000000 0xc>;
+ status = "okay";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
new file mode 100644
index 0000000..31e4d3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: MediaTek Device Access Permission Control driver
+
+description: |
+ MediaTek bus fabric provides TrustZone security support and data
+ protection to prevent slaves from being accessed by unexpected masters.
+ The security violation is logged and sent to the processor for further
+ analysis and countermeasures.
+
+maintainers:
+ - Neal Liu <neal.liu@mediatek.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6779-devapc
+
+ reg:
+ description: The base address of devapc register bank
+ maxItems: 1
+
+ interrupts:
+ description: A single interrupt specifier
+ maxItems: 1
+
+ clocks:
+ description: Contains module clock source and clock names
+ maxItems: 1
+
+ clock-names:
+ description: Names of the clocks list in clocks property
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt6779-clk.h>
+
+ devapc: devapc@10207000 {
+ compatible = "mediatek,mt6779-devapc";
+ reg = <0x10207000 0x1000>;
+ interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg_ao CLK_INFRA_DEVICE_APC>;
+ clock-names = "devapc-infra-clock";
+ };
diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
index 55fffae..597d67f 100644
--- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
+++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
@@ -59,6 +59,7 @@
items:
- enum:
- atmel,tcb-timer
+ - atmel,tcb-pwm
- microchip,tcb-capture
reg:
description:
@@ -68,10 +69,35 @@
minItems: 1
maxItems: 3
+ required:
+ - compatible
+ - reg
+
+ "^pwm@[0-2]$":
+ description: The timer block channels that are used as PWMs.
+ $ref: ../../pwm/pwm.yaml#
+ type: object
+ properties:
+ compatible:
+ const: atmel,tcb-pwm
+ reg:
+ description:
+ TCB channel to use for this PWM.
+ enum: [ 0, 1, 2 ]
+
+ "#pwm-cells":
+ description:
+ The only third cell flag supported by this binding is
+ PWM_POLARITY_INVERTED.
+ const: 3
required:
- compatible
- reg
+ - "#pwm-cells"
+
+ additionalProperties: false
+
allOf:
- if:
@@ -158,7 +184,13 @@
compatible = "atmel,tcb-timer";
reg = <1>;
};
- };
+
+ pwm@2 {
+ compatible = "atmel,tcb-pwm";
+ reg = <2>;
+ #pwm-cells = <3>;
+ };
+ };
/* TCB0 Capture with QDEC: */
timer@f800c000 {
compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
index c3c595e2..ddea3d4 100644
--- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
@@ -55,7 +55,7 @@
description: TI-SCI RM subtype for GP ring range
ti,sci:
- $ref: /schemas/types.yaml#definitions/phandle-array
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description: phandle on TI-SCI compatible System controller node
ti,sci-dev-id:
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu-settings.yaml b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu-settings.yaml
new file mode 100644
index 0000000..cb245f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu-settings.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/xilinx/xlnx,vcu-settings.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx VCU Settings
+
+maintainers:
+ - Michael Tretter <kernel@pengutronix.de>
+
+description: |
+ The Xilinx VCU Settings provides information about the configuration of the
+ video codec unit.
+
+properties:
+ compatible:
+ items:
+ - const: xlnx,vcu-settings
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ fpga {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ xlnx_vcu: vcu@a0041000 {
+ compatible = "xlnx,vcu-settings", "syscon";
+ reg = <0x0 0xa0041000 0x0 0x1000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
index 6786d67..2417b13 100644
--- a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
+++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
@@ -12,10 +12,7 @@
- compatible: shall be one of:
"xlnx,vcu"
"xlnx,vcu-logicoreip-1.0"
-- reg, reg-names: There are two sets of registers need to provide.
- 1. vcu slcr
- 2. Logicore
- reg-names should contain name for the each register sequence.
+- reg : The base offset and size of the VCU_PL_SLCR register space.
- clocks: phandle for aclk and pll_ref clocksource
- clock-names: The identification string, "aclk", is always required for
the axi clock. "pll_ref" is required for pll.
@@ -23,9 +20,7 @@
xlnx_vcu: vcu@a0040000 {
compatible = "xlnx,vcu-logicoreip-1.0";
- reg = <0x0 0xa0040000 0x0 0x1000>,
- <0x0 0xa0041000 0x0 0x1000>;
- reg-names = "vcu_slcr", "logicore";
+ reg = <0x0 0xa0040000 0x0 0x1000>;
clocks = <&si570_1>, <&clkc 71>;
clock-names = "pll_ref", "aclk";
};
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
new file mode 100644
index 0000000..7014493
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau1372.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+
+title: Analog Devices ADAU1372 CODEC
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.om>
+
+description: |
+ Analog Devices ADAU1372 four inputs and two outputs codec.
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,adau1372
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: "mclk"
+
+ powerdown-gpios:
+ description: GPIO used for hardware power-down.
+ maxItems: 1
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@3c {
+ compatible = "adi,adau1372";
+ reg = <0x3c>;
+ #sound-dai-cells = <0>;
+ clock-names = "mclk";
+ clocks = <&adau1372z_xtal>;
+ };
+ };
+
+ adau1372z_xtal: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.txt b/Documentation/devicetree/bindings/sound/adi,adau1977.txt
deleted file mode 100644
index 37f8aad..0000000
--- a/Documentation/devicetree/bindings/sound/adi,adau1977.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Analog Devices ADAU1977/ADAU1978/ADAU1979
-
-Datasheets:
-https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf
-https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf
-https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf
-
-This driver supports both the I2C and SPI bus.
-
-Required properties:
- - compatible: Should contain one of the following:
- "adi,adau1977"
- "adi,adau1978"
- "adi,adau1979"
-
- - AVDD-supply: analog power supply for the device, please consult
- Documentation/devicetree/bindings/regulator/regulator.txt
-
-Optional properties:
- - reset-gpios: the reset pin for the chip, for more details consult
- Documentation/devicetree/bindings/gpio/gpio.txt
-
- - DVDD-supply: supply voltage for the digital core, please consult
- Documentation/devicetree/bindings/regulator/regulator.txt
-
-- adi,micbias: configures the voltage setting for the MICBIAS pin.
- Select 0/1/2/3/4/5/6/7/8 to specify MICBIAS voltage
- 5V/5.5V/6V/6.5V/7V/7.5V/8V/8.5V/9V
- If not specified the default value will be "7" meaning 8.5 Volts.
- This property is only valid for the ADAU1977
-
-For required properties on SPI, please consult
-Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Required properties on I2C:
-
- - reg: The i2c address. Value depends on the state of ADDR0
- and ADDR1, as wired in hardware.
-
-Examples:
-
- adau1977_spi: adau1977@0 {
- compatible = "adi,adau1977";
- spi-max-frequency = <600000>;
-
- AVDD-supply = <®ulator>;
- DVDD-supply = <®ulator_digital>;
-
- adi,micbias = <3>;
- reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
- };
-
- adau1977_i2c: adau1977@11 {
- compatible = "adi,adau1977";
- reg = <0x11>;
-
- AVDD-supply = <®ulator>;
- DVDD-supply = <®ulator_digital>;
-
- reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.yaml b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
new file mode 100644
index 0000000..b80454a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau1977.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADAU1977/ADAU1978/ADAU1979 Quad ADC with Diagnostics
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+ - Bogdan Togorean <bogdan.togorean@analog.com>
+
+description: |
+ Analog Devices ADAU1977 and similar quad ADC with Diagnostics
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,adau1977
+ - adi,adau1978
+ - adi,adau1979
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+ AVDD-supply:
+ description: Analog power support for the device.
+
+ DVDD-supply:
+ description: Supply voltage for digital core.
+
+ adi,micbias:
+ description: |
+ Configures the voltage setting for the MICBIAS pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6, 7, 8]
+ default: 7
+
+required:
+ - reg
+ - compatible
+ - AVDD-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adau1977_spi: adau1977@0 {
+ compatible = "adi,adau1977";
+ reg = <0>;
+ spi-max-frequency = <600000>;
+
+ AVDD-supply = <®ulator>;
+ DVDD-supply = <®ulator_digital>;
+
+ reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+
+ adi,micbias = <3>;
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adau1977_i2c: adau1977@11 {
+ compatible = "adi,adau1977";
+ reg = <0x11>;
+
+ AVDD-supply = <®ulator>;
+ DVDD-supply = <®ulator_digital>;
+
+ reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
index be390ac..dd47fef 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
@@ -57,7 +57,7 @@
A list of the connections between audio components. Each entry
is a pair of strings, the first being the connection's sink, the
second being the connection's source.
- $ref: /schemas/types.yaml#definitions/non-unique-string-array
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
minItems: 2
maxItems: 18
items:
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
index 112ae00..a16e37b 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
@@ -24,6 +24,7 @@
- items:
- const: allwinner,sun50i-a64-i2s
- const: allwinner,sun8i-h3-i2s
+ - const: allwinner,sun50i-h6-i2s
reg:
maxItems: 1
@@ -59,6 +60,7 @@
- allwinner,sun8i-a83t-i2s
- allwinner,sun8i-h3-i2s
- allwinner,sun50i-a64-codec-i2s
+ - allwinner,sun50i-h6-i2s
then:
required:
@@ -68,7 +70,9 @@
properties:
compatible:
contains:
- const: allwinner,sun8i-a83t-i2s
+ enum:
+ - allwinner,sun8i-a83t-i2s
+ - allwinner,sun8i-h3-i2s
then:
properties:
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.txt b/Documentation/devicetree/bindings/sound/audio-graph-card.txt
deleted file mode 100644
index d5f6919..0000000
--- a/Documentation/devicetree/bindings/sound/audio-graph-card.txt
+++ /dev/null
@@ -1,337 +0,0 @@
-Audio Graph Card:
-
-Audio Graph Card specifies audio DAI connections of SoC <-> codec.
-It is based on common bindings for device graphs.
-see ${LINUX}/Documentation/devicetree/bindings/graph.txt
-
-Basically, Audio Graph Card property is same as Simple Card.
-see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.yaml
-
-Below are same as Simple-Card.
-
-- label
-- widgets
-- routing
-- dai-format
-- frame-master
-- bitclock-master
-- bitclock-inversion
-- frame-inversion
-- mclk-fs
-- hp-det-gpio
-- mic-det-gpio
-- dai-tdm-slot-num
-- dai-tdm-slot-width
-- clocks / system-clock-frequency
-
-Required properties:
-
-- compatible : "audio-graph-card";
-- dais : list of CPU DAI port{s}
-
-Optional properties:
-- pa-gpios: GPIO used to control external amplifier.
-
------------------------
-Example: Single DAI case
------------------------
-
- sound_card {
- compatible = "audio-graph-card";
-
- dais = <&cpu_port>;
- };
-
- dai-controller {
- ...
- cpu_port: port {
- cpu_endpoint: endpoint {
- remote-endpoint = <&codec_endpoint>;
-
- dai-format = "left_j";
- ...
- };
- };
- };
-
- audio-codec {
- ...
- port {
- codec_endpoint: endpoint {
- remote-endpoint = <&cpu_endpoint>;
- };
- };
- };
-
------------------------
-Example: Multi DAI case
------------------------
-
- sound-card {
- compatible = "audio-graph-card";
-
- label = "sound-card";
-
- dais = <&cpu_port0
- &cpu_port1
- &cpu_port2>;
- };
-
- audio-codec@0 {
- ...
- port {
- codec0_endpoint: endpoint {
- remote-endpoint = <&cpu_endpoint0>;
- };
- };
- };
-
- audio-codec@1 {
- ...
- port {
- codec1_endpoint: endpoint {
- remote-endpoint = <&cpu_endpoint1>;
- };
- };
- };
-
- audio-codec@2 {
- ...
- port {
- codec2_endpoint: endpoint {
- remote-endpoint = <&cpu_endpoint2>;
- };
- };
- };
-
- dai-controller {
- ...
- ports {
- cpu_port0: port@0 {
- cpu_endpoint0: endpoint {
- remote-endpoint = <&codec0_endpoint>;
-
- dai-format = "left_j";
- ...
- };
- };
- cpu_port1: port@1 {
- cpu_endpoint1: endpoint {
- remote-endpoint = <&codec1_endpoint>;
-
- dai-format = "i2s";
- ...
- };
- };
- cpu_port2: port@2 {
- cpu_endpoint2: endpoint {
- remote-endpoint = <&codec2_endpoint>;
-
- dai-format = "i2s";
- ...
- };
- };
- };
- };
-
-
------------------------
-Example: Sampling Rate Conversion
------------------------
-
- sound_card {
- compatible = "audio-graph-card";
-
- label = "sound-card";
- prefix = "codec";
- routing = "codec Playback", "DAI0 Playback",
- "DAI0 Capture", "codec Capture";
- convert-rate = <48000>;
-
- dais = <&cpu_port>;
- };
-
- audio-codec {
- ...
- port {
- codec_endpoint: endpoint {
- remote-endpoint = <&cpu_endpoint>;
- };
- };
- };
-
- dai-controller {
- ...
- cpu_port: port {
- cpu_endpoint: endpoint {
- remote-endpoint = <&codec_endpoint>;
-
- dai-format = "left_j";
- ...
- };
- };
- };
-
------------------------
-Example: 2 CPU 1 Codec (Mixing)
------------------------
-
- sound_card {
- compatible = "audio-graph-card";
-
- label = "sound-card";
- routing = "codec Playback", "DAI0 Playback",
- "codec Playback", "DAI1 Playback",
- "DAI0 Capture", "codec Capture";
-
- dais = <&cpu_port>;
- };
-
- audio-codec {
- ...
-
- audio-graph-card,prefix = "codec";
- audio-graph-card,convert-rate = <48000>;
- port {
- reg = <0>;
- codec_endpoint0: endpoint@0 {
- remote-endpoint = <&cpu_endpoint0>;
- };
- codec_endpoint1: endpoint@1 {
- remote-endpoint = <&cpu_endpoint1>;
- };
- };
- };
-
- dai-controller {
- ...
- cpu_port: port {
- cpu_endpoint0: endpoint@0 {
- remote-endpoint = <&codec_endpoint0>;
-
- dai-format = "left_j";
- ...
- };
- cpu_endpoint1: endpoint@1 {
- remote-endpoint = <&codec_endpoint1>;
-
- dai-format = "left_j";
- ...
- };
- };
- };
-
------------------------
-Example: Multi DAI with DPCM
------------------------
-
- CPU0 ------ ak4613
- CPU1 ------ HDMI
- CPU2 ------ PCM3168A-p /* DPCM 1ch/2ch */
- CPU3 --/ /* DPCM 3ch/4ch */
- CPU4 --/ /* DPCM 5ch/6ch */
- CPU5 --/ /* DPCM 7ch/8ch */
- CPU6 ------ PCM3168A-c
-
- sound_card: sound {
- compatible = "audio-graph-card";
-
- label = "sound-card";
-
- routing = "pcm3168a Playback", "DAI2 Playback",
- "pcm3168a Playback", "DAI3 Playback",
- "pcm3168a Playback", "DAI4 Playback",
- "pcm3168a Playback", "DAI5 Playback";
-
- dais = <&snd_port0 /* ak4613 */
- &snd_port1 /* HDMI0 */
- &snd_port2 /* pcm3168a playback */
- &snd_port3 /* pcm3168a capture */
- >;
- };
-
- ak4613: codec@10 {
- ...
- port {
- ak4613_endpoint: endpoint {
- remote-endpoint = <&rsnd_endpoint0>;
- };
- };
- };
-
- pcm3168a: audio-codec@44 {
- ...
- audio-graph-card,prefix = "pcm3168a";
- audio-graph-card,convert-channels = <8>; /* TDM Split */
- ports {
- port@0 {
- reg = <0>;
- pcm3168a_endpoint_p1: endpoint@1 {
- remote-endpoint = <&rsnd_endpoint2>;
- ...
- };
- pcm3168a_endpoint_p2: endpoint@2 {
- remote-endpoint = <&rsnd_endpoint3>;
- ...
- };
- pcm3168a_endpoint_p3: endpoint@3 {
- remote-endpoint = <&rsnd_endpoint4>;
- ...
- };
- pcm3168a_endpoint_p4: endpoint@4 {
- remote-endpoint = <&rsnd_endpoint5>;
- ...
- };
- };
- port@1 {
- reg = <1>;
- pcm3168a_endpoint_c: endpoint {
- remote-endpoint = <&rsnd_endpoint6>;
- ...
- };
- };
- };
- };
-
- &sound {
- ports {
- snd_port0: port@0 {
- rsnd_endpoint0: endpoint {
- remote-endpoint = <&ak4613_endpoint>;
- ...
- };
- };
- snd_port1: port@1 {
- rsnd_endpoint1: endpoint {
- remote-endpoint = <&dw_hdmi0_snd_in>;
- ...
- };
- };
- snd_port2: port@2 {
- #address-cells = <1>;
- #size-cells = <0>;
- rsnd_endpoint2: endpoint@2 {
- remote-endpoint = <&pcm3168a_endpoint_p1>;
- ...
- };
- rsnd_endpoint3: endpoint@3 {
- remote-endpoint = <&pcm3168a_endpoint_p2>;
- ...
- };
- rsnd_endpoint4: endpoint@4 {
- remote-endpoint = <&pcm3168a_endpoint_p3>;
- ...
- };
- rsnd_endpoint5: endpoint@5 {
- remote-endpoint = <&pcm3168a_endpoint_p4>;
- ...
- };
- };
- snd_port3: port@6 {
- rsnd_endpoint6: endpoint {
- remote-endpoint = <&pcm3168a_endpoint_c>;
- ...
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card.yaml
new file mode 100644
index 0000000..109e55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/audio-graph-card.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/audio-graph-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio Graph Card Device Tree Bindings
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+allOf:
+ - $ref: /schemas/sound/audio-graph.yaml#
+
+properties:
+ compatible:
+ enum:
+ - audio-graph-card
+ - audio-graph-scu-card
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "audio-graph-card";
+
+ dais = <&cpu_port_a>;
+ };
+
+ cpu {
+ /*
+ * dai-controller own settings
+ */
+
+ port {
+ cpu_endpoint: endpoint {
+ remote-endpoint = <&codec_endpoint>;
+ dai-format = "left_j";
+ };
+ };
+ };
+
+ codec {
+ /*
+ * codec own settings
+ */
+
+ port {
+ codec_endpoint: endpoint {
+ remote-endpoint = <&cpu_endpoint>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
new file mode 100644
index 0000000..2005014
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/audio-graph-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio Graph Card 'port' Node Bindings
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+select: false
+
+properties:
+ port:
+ description: single OF-Graph subnode
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+ prefix:
+ description: "device name prefix"
+ $ref: /schemas/types.yaml#/definitions/string
+ convert-rate:
+ description: CPU to Codec rate convert.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ convert-channels:
+ description: CPU to Codec rate channels.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ type: object
+ properties:
+ remote-endpoint:
+ maxItems: 1
+ mclk-fs:
+ description: |
+ Multiplication factor between stream rate and codec mclk.
+ When defined, mclk-fs property defined in dai-link sub nodes are
+ ignored.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ frame-inversion:
+ description: dai-link uses frame clock inversion
+ $ref: /schemas/types.yaml#/definitions/flag
+ bitclock-inversion:
+ description: dai-link uses bit clock inversion
+ $ref: /schemas/types.yaml#/definitions/flag
+ frame-master:
+ description: Indicates dai-link frame master.
+ $ref: /schemas/types.yaml#/definitions/phandle
+ bitclock-master:
+ description: Indicates dai-link bit clock master
+ $ref: /schemas/types.yaml#/definitions/phandle
+ dai-format:
+ description: audio format.
+ items:
+ enum:
+ - i2s
+ - right_j
+ - left_j
+ - dsp_a
+ - dsp_b
+ - ac97
+ - pdm
+ - msb
+ - lsb
+ convert-rate:
+ description: CPU to Codec rate convert.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ convert-channels:
+ description: CPU to Codec rate channels.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - remote-endpoint
+
+ ports:
+ description: multi OF-Graph subnode
+ type: object
+ patternProperties:
+ "^port(@[0-9a-f]+)?":
+ $ref: "#/properties/port"
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
new file mode 100644
index 0000000..4b46794
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/audio-graph.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio Graph Device Tree Bindings
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+properties:
+ dais:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ label:
+ maxItems: 1
+ prefix:
+ description: "device name prefix"
+ $ref: /schemas/types.yaml#/definitions/string
+ routing:
+ description: |
+ A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's source.
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ widgets:
+ description: User specified audio sound widgets.
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ convert-rate:
+ description: CPU to Codec rate convert.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ convert-channels:
+ description: CPU to Codec rate channels.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ pa-gpios:
+ maxItems: 1
+ hp-det-gpio:
+ maxItems: 1
+ mic-det-gpio:
+ maxItems: 1
+
+required:
+ - dais
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml b/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml
new file mode 100644
index 0000000..aa4be71
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,aud2htx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Audio Subsystem to HDMI RTX Subsystem Controller
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8mp-aud2htx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral clock
+
+ clock-names:
+ items:
+ - const: bus
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for TX
+
+ dma-names:
+ items:
+ - const: tx
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx8mp-clock.h>
+
+ aud2htx: aud2htx@30cb0000 {
+ compatible = "fsl,imx8mp-aud2htx";
+ reg = <0x30cb0000 0x10000>;
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUD2HTX_IPG>;
+ clock-names = "bus";
+ dmas = <&sdma2 26 2 0>;
+ dma-names = "tx";
+ power-domains = <&audiomix_pd>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
index 2ac671f..50449b6 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
@@ -20,6 +20,7 @@
- fsl,imx35-spdif
- fsl,vf610-spdif
- fsl,imx6sx-spdif
+ - fsl,imx8qm-spdif
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
new file mode 100644
index 0000000..223b8ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,xcvr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Audio Transceiver (XCVR) Controller
+
+maintainers:
+ - Viorel Suman <viorel.suman@nxp.com>
+
+description: |
+ NXP XCVR (Audio Transceiver) is a on-chip functional module
+ that allows CPU to receive and transmit digital audio via
+ HDMI2.1 eARC, HDMI1.4 ARC and SPDIF.
+
+properties:
+ $nodename:
+ pattern: "^xcvr@.*"
+
+ compatible:
+ enum:
+ - fsl,imx8mp-xcvr
+
+ reg:
+ items:
+ - description: 20K RAM for code and data
+ - description: registers space
+ - description: RX FIFO address
+ - description: TX FIFO address
+
+ reg-names:
+ items:
+ - const: ram
+ - const: regs
+ - const: rxfifo
+ - const: txfifo
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: PHY clock
+ - description: SPBA clock
+ - description: PLL clock
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: phy
+ - const: spba
+ - const: pll_ipg
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for RX
+ - description: DMA controller phandle and request line for TX
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/reset/imx8mp-reset.h>
+
+ xcvr: xcvr@30cc0000 {
+ compatible = "fsl,imx8mp-xcvr";
+ reg = <0x30cc0000 0x800>,
+ <0x30cc0800 0x400>,
+ <0x30cc0c00 0x080>,
+ <0x30cc0e00 0x080>;
+ reg-names = "ram", "regs", "rxfifo", "txfifo";
+ interrupts = <0x0 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>,
+ <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>,
+ <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>,
+ <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;
+ clock-names = "ipg", "phy", "spba", "pll_ipg";
+ dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>;
+ dma-names = "rx", "tx";
+ resets = <&audiomix_reset 0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index f339be6..90d9e9d 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -40,6 +40,8 @@
"fsl,imx-audio-tlv320aic32x4"
+ "fsl,imx-audio-si476x"
+
Required properties:
- compatible : Contains one of entries in the compatible list.
diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
new file mode 100644
index 0000000..5095b78
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/google,sc7180-trogdor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google SC7180-Trogdor ASoC sound card driver
+
+maintainers:
+ - Rohit kumar <rohitkr@codeaurora.org>
+ - Cheng-Yi Chiang <cychiang@chromium.org>
+
+description:
+ This binding describes the SC7180 sound card which uses LPASS for audio.
+
+properties:
+ compatible:
+ enum:
+ - google,sc7180-trogdor
+ - google,sc7180-coachz
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ dmic-gpios:
+ maxItems: 1
+ description: GPIO for switching between DMICs
+
+patternProperties:
+ "^dai-link(@[0-9])?$":
+ description:
+ Each subnode represents a dai link. Subnodes of each dai links would be
+ cpu/codec dais.
+
+ type: object
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name.
+ $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
+
+ reg:
+ description: dai link address.
+
+ cpu:
+ description: Holds subnode which indicates cpu dai.
+ type: object
+ properties:
+ sound-dai: true
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ properties:
+ sound-dai: true
+
+ required:
+ - link-name
+ - cpu
+ - codec
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - model
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+
+ - |
+ sound {
+ compatible = "google,sc7180-trogdor";
+ model = "sc7180-rt5682-max98357a-2mic";
+
+ audio-routing =
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dmic-gpios = <&tlmm 86 0>;
+
+ dai-link@0 {
+ link-name = "MultiMedia0";
+ reg = <0>;
+ cpu {
+ sound-dai = <&lpass_cpu 0>;
+ };
+
+ codec {
+ sound-dai = <&alc5682 0>;
+ };
+ };
+
+ dai-link@1 {
+ link-name = "MultiMedia1";
+ reg = <1>;
+ cpu {
+ sound-dai = <&lpass_cpu 1>;
+ };
+
+ codec {
+ sound-dai = <&max98357a>;
+ };
+ };
+
+ dai-link@2 {
+ link-name = "MultiMedia2";
+ reg = <2>;
+ cpu {
+ sound-dai = <&lpass_hdmi 0>;
+ };
+
+ codec {
+ sound-dai = <&msm_dp>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml b/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml
new file mode 100644
index 0000000..d5474f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/imx-audio-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX audio complex with HDMI
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx-audio-hdmi
+ - fsl,imx-audio-sii902x
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ audio-cpu:
+ description: The phandle of an CPU DAI controller
+
+ hdmi-out:
+ description: |
+ This is a boolean property. If present, the transmitting function
+ of HDMI will be enabled, indicating there's a physical HDMI out
+ connector or jack on the board or it's connecting to some other IP
+ block, such as an HDMI encoder or display-controller.
+
+ hdmi-in:
+ description: |
+ This is a boolean property. If present, the receiving function of
+ HDMI will be enabled, indicating there is a physical HDMI in
+ connector/jack on the board.
+
+required:
+ - compatible
+ - model
+ - audio-cpu
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-hdmi {
+ compatible = "fsl,imx-audio-hdmi";
+ model = "audio-hdmi";
+ audio-cpu = <&aud2htx>;
+ hdmi-out;
+ };
diff --git a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
index 6d20a24..234f64a 100644
--- a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
+++ b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
@@ -9,6 +9,9 @@
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
+allOf:
+ - $ref: audio-graph-port.yaml#
+
properties:
$nodename:
pattern: "^audio-controller(@.*)?$"
@@ -58,29 +61,9 @@
type: object
properties:
- remote-endpoint: true
-
- frame-master:
- type: boolean
- description: SoC generates the frame clock
-
- bitclock-master:
- type: boolean
- description: SoC generates the bit clock
-
dai-format:
- $ref: /schemas/types.yaml#/definitions/string
- description: The digital audio format
const: i2s
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
- additionalProperties: false
-
required:
- "#sound-dai-cells"
- compatible
@@ -112,8 +95,6 @@
port {
endpoint {
remote-endpoint = <&rt5631_0>;
- frame-master;
- bitclock-master;
dai-format = "i2s";
};
};
diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
new file mode 100644
index 0000000..bf8c8ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mt8192-mt6359-rt1015-rt5682.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8192 with MT6359, RT1015 and RT5682 ASoC sound card driver
+
+maintainers:
+ - Jiaxin Yu <jiaxin.yu@mediatek.com>
+ - Shane Chien <shane.chien@mediatek.com>
+
+description:
+ This binding describes the MT8192 sound card.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8192_mt6359_rt1015_rt5682
+ - mediatek,mt8192_mt6359_rt1015p_rt5682
+
+ mediatek,platform:
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+ description: The phandle of MT8192 ASoC platform.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - mediatek,platform
+
+examples:
+ - |
+
+ sound: mt8192-sound {
+ compatible = "mediatek,mt8192_mt6359_rt1015_rt5682";
+ mediatek,platform = <&afe>;
+ pinctrl-names = "aud_clk_mosi_off",
+ "aud_clk_mosi_on";
+ pinctrl-0 = <&aud_clk_mosi_off>;
+ pinctrl-1 = <&aud_clk_mosi_on>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/nau8315.txt b/Documentation/devicetree/bindings/sound/nau8315.txt
new file mode 100644
index 0000000..6eaec46
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nau8315.txt
@@ -0,0 +1,18 @@
+Nuvoton NAU8315 Mono Class-D Amplifier
+
+Required properties:
+- compatible : "nuvoton,nau8315"
+
+Optional properties:
+- enable-gpios : GPIO specifier for the chip's device enable input(EN) pin.
+ If this option is not specified then driver does not manage
+ the pin state (e.g. chip is always on).
+
+Example:
+
+#include <dt-bindings/gpio/gpio.h>
+
+nau8315 {
+ compatible = "nuvoton,nau8315";
+ enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
deleted file mode 100644
index 21cd310..0000000
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-NVIDIA Tegra30 HDA controller
-
-Required properties:
-- compatible : For Tegra30, must contain "nvidia,tegra30-hda". Otherwise,
- must contain '"nvidia,<chip>-hda", "nvidia,tegra30-hda"', where <chip> is
- tegra114, tegra124, or tegra132.
-- reg : Should contain the HDA registers location and length.
-- interrupts : The interrupt from the HDA controller.
-- clocks : Must contain an entry for each required entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries: hda, hda2hdmi, hda2codec_2x
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries: hda, hda2hdmi, hda2codec_2x
-
-Optional properties:
-- nvidia,model : The user-visible name of this sound complex. Since the property
- is optional, legacy boards can use default name provided in hda driver.
-
-Example:
-
-hda@70030000 {
- compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda";
- reg = <0x0 0x70030000 0x0 0x10000>;
- interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA124_CLK_HDA>,
- <&tegra_car TEGRA124_CLK_HDA2HDMI>,
- <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>;
- clock-names = "hda", "hda2hdmi", "hda2codec_2x";
- resets = <&tegra_car 125>, /* hda */
- <&tegra_car 128>, /* hda2hdmi */
- <&tegra_car 111>; /* hda2codec_2x */
- reset-names = "hda", "hda2hdmi", "hda2codec_2x";
- nvidia,model = "jetson-tk1-hda";
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
new file mode 100644
index 0000000..b55775e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra30-hda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra HDA controller
+
+description: |
+ The High Definition Audio (HDA) block provides a serial interface to
+ audio codec. It supports multiple input and output streams.
+
+maintainers:
+ - Thierry Reding <treding@nvidia.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ $nodename:
+ pattern: "^hda@[0-9a-f]*$"
+
+ compatible:
+ oneOf:
+ - const: nvidia,tegra30-hda
+ - items:
+ - enum:
+ - nvidia,tegra194-hda
+ - nvidia,tegra186-hda
+ - nvidia,tegra210-hda
+ - nvidia,tegra124-hda
+ - const: nvidia,tegra30-hda
+ - items:
+ - const: nvidia,tegra132-hda
+ - const: nvidia,tegra124-hda
+ - const: nvidia,tegra30-hda
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: The interrupt from the HDA controller
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: hda
+ - const: hda2hdmi
+ - const: hda2codec_2x
+
+ resets:
+ maxItems: 3
+
+ reset-names:
+ items:
+ - const: hda
+ - const: hda2hdmi
+ - const: hda2codec_2x
+
+ power-domains:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: dma-mem
+ - const: write
+
+ iommus:
+ maxItems: 1
+
+ nvidia,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ The user-visible name of this sound complex. If this property is
+ not specified then boards can use default name provided in hda driver.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include<dt-bindings/clock/tegra124-car-common.h>
+ #include<dt-bindings/interrupt-controller/arm-gic.h>
+
+ hda@70030000 {
+ compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda";
+ reg = <0x70030000 0x10000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_HDA>,
+ <&tegra_car TEGRA124_CLK_HDA2HDMI>,
+ <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>;
+ clock-names = "hda", "hda2hdmi", "hda2codec_2x";
+ resets = <&tegra_car 125>, /* hda */
+ <&tegra_car 128>, /* hda2hdmi */
+ <&tegra_car 111>; /* hda2codec_2x */
+ reset-names = "hda", "hda2hdmi", "hda2codec_2x";
+ nvidia,model = "jetson-tk1-hda";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
new file mode 100644
index 0000000..679b49c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,lpass-va-macro.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LPASS(Low Power Audio Subsystem) VA Macro audio codec DT bindings
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+properties:
+ compatible:
+ const: qcom,sm8250-lpass-va-macro
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 1
+
+ '#clock-cells':
+ const: 0
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: mclk
+ - const: core
+ - const: dcodec
+
+ clock-output-names:
+ items:
+ - const: fsgen
+
+ qcom,dmic-sample-rate:
+ description: dmic sample rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ vdd-micb-supply:
+ description: phandle to voltage regulator of MIC Bias
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ codec@3370000 {
+ compatible = "qcom,sm8250-lpass-va-macro";
+ reg = <0x3370000 0x1000>;
+ #sound-dai-cells = <1>;
+ #clock-cells = <0>;
+ clocks = <&aoncc 0>,
+ <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "mclk", "core", "dcodec";
+ clock-output-names = "fsgen";
+ qcom,dmic-sample-rate = <600000>;
+ vdd-micb-supply = <&vreg_s4a_1p8>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml
new file mode 100644
index 0000000..435b019
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,lpass-wsa-macro.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LPASS(Low Power Audio Subsystem) VA Macro audio codec DT bindings
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+properties:
+ compatible:
+ const: qcom,sm8250-lpass-wsa-macro
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 1
+
+ '#clock-cells':
+ const: 0
+
+ clocks:
+ maxItems: 5
+
+ clock-names:
+ items:
+ - const: mclk
+ - const: npl
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+ clock-output-names:
+ items:
+ - const: mclk
+
+ qcom,dmic-sample-rate:
+ description: dmic sample rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ vdd-micb-supply:
+ description: phandle to voltage regulator of MIC Bias
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ codec@3240000 {
+ compatible = "qcom,sm8250-lpass-wsa-macro";
+ reg = <0x3240000 0x1000>;
+ #sound-dai-cells = <1>;
+ #clock-cells = <0>;
+ clocks = <&audiocc 1>,
+ <&audiocc 0>,
+ <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&vamacro>;
+ clock-names = "mclk", "npl", "macro", "dcodec", "fsgen";
+ clock-output-names = "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
new file mode 100644
index 0000000..72ad9ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,sm8250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies Inc. SM8250 ASoC sound card driver
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ This bindings describes SC8250 SoC based sound cards
+ which uses LPASS internal codec for audio.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,sm8250-sndcard
+ - const: qcom,qrb5165-rb5-sndcard
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source. Valid names could be power supplies,
+ MicBias of codec and the jacks on the board.
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User visible long sound card name
+
+patternProperties:
+ ".*-dai-link$":
+ description:
+ Each subnode represents a dai link. Subnodes of each dai links would be
+ cpu/codec dais.
+
+ type: object
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name.
+ $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
+
+ cpu:
+ description: Holds subnode which indicates cpu dai.
+ type: object
+ properties:
+ sound-dai: true
+
+ platform:
+ description: Holds subnode which indicates platform dai.
+ type: object
+ properties:
+ sound-dai: true
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ properties:
+ sound-dai: true
+
+ required:
+ - link-name
+ - cpu
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - model
+
+additionalProperties: false
+
+examples:
+
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ #include <dt-bindings/sound/qcom,q6asm.h>
+ sound {
+ compatible = "qcom,qrb5165-rb5-sndcard";
+ model = "Qualcomm-qrb5165-RB5-WSA8815-Speakers-DMIC0";
+ audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
+ "SpkrRight IN", "WSA_SPK2 OUT",
+ "VA DMIC0", "vdd-micb",
+ "VA DMIC1", "vdd-micb",
+ "MM_DL1", "MultiMedia1 Playback",
+ "MM_DL2", "MultiMedia2 Playback",
+ "MultiMedia3 Capture", "MM_UL3";
+
+ mm1-dai-link {
+ link-name = "MultiMedia0";
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ mm2-dai-link {
+ link-name = "MultiMedia2";
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA2>;
+ };
+ };
+
+ mm3-dai-link {
+ link-name = "MultiMedia3";
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA3>;
+ };
+ };
+
+ hdmi-dai-link {
+ link-name = "HDMI Playback";
+ cpu {
+ sound-dai = <&q6afedai TERTIARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+
+ codec {
+ sound-dai = <<9611_codec 0>;
+ };
+ };
+
+ wsa-dai-link {
+ link-name = "WSA Playback";
+ cpu {
+ sound-dai = <&q6afedai WSA_CODEC_DMA_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+
+ codec {
+ sound-dai = <&left_spkr>, <&right_spkr>, <&swr0 0>, <&wsamacro>;
+ };
+ };
+
+ va-dai-link {
+ link-name = "VA Capture";
+ cpu {
+ sound-dai = <&q6afedai VA_CODEC_DMA_TX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+
+ codec {
+ sound-dai = <&vamacro 0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index b39743d..b731f16 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -253,523 +253,3 @@
Driver can automatically switches TDM <-> stereo mode in this case.
see "Example: simple sound card for TDM"
-
-=============================================
-Required properties:
-=============================================
-
-- compatible : "renesas,rcar_sound-<soctype>", fallbacks
- "renesas,rcar_sound-gen1" if generation1, and
- "renesas,rcar_sound-gen2" if generation2 (or RZ/G1)
- "renesas,rcar_sound-gen3" if generation3 (or RZ/G2)
- Examples with soctypes are:
- - "renesas,rcar_sound-r8a7742" (RZ/G1H)
- - "renesas,rcar_sound-r8a7743" (RZ/G1M)
- - "renesas,rcar_sound-r8a7744" (RZ/G1N)
- - "renesas,rcar_sound-r8a7745" (RZ/G1E)
- - "renesas,rcar_sound-r8a77470" (RZ/G1C)
- - "renesas,rcar_sound-r8a774a1" (RZ/G2M)
- - "renesas,rcar_sound-r8a774b1" (RZ/G2N)
- - "renesas,rcar_sound-r8a774c0" (RZ/G2E)
- - "renesas,rcar_sound-r8a774e1" (RZ/G2H)
- - "renesas,rcar_sound-r8a7778" (R-Car M1A)
- - "renesas,rcar_sound-r8a7779" (R-Car H1)
- - "renesas,rcar_sound-r8a7790" (R-Car H2)
- - "renesas,rcar_sound-r8a7791" (R-Car M2-W)
- - "renesas,rcar_sound-r8a7793" (R-Car M2-N)
- - "renesas,rcar_sound-r8a7794" (R-Car E2)
- - "renesas,rcar_sound-r8a7795" (R-Car H3)
- - "renesas,rcar_sound-r8a7796" (R-Car M3-W)
- - "renesas,rcar_sound-r8a77965" (R-Car M3-N)
- - "renesas,rcar_sound-r8a77990" (R-Car E3)
- - "renesas,rcar_sound-r8a77995" (R-Car D3)
-- reg : Should contain the register physical address.
- required register is
- SRU/ADG/SSI if generation1
- SRU/ADG/SSIU/SSI/AUDIO-DMAC-periperi if generation2/generation3
- Select extended AUDIO-DMAC-periperi address if SoC has it,
- otherwise select normal AUDIO-DMAC-periperi address.
-- reg-names : Should contain the register names.
- scu/adg/ssi if generation1
- scu/adg/ssiu/ssi/audmapp if generation2/generation3
-- rcar_sound,ssi : Should contain SSI feature.
- The number of SSI subnode should be same as HW.
- see below for detail.
-- rcar_sound,ssiu : Should contain SSIU feature.
- The number of SSIU subnode should be same as HW.
- see below for detail.
-- rcar_sound,src : Should contain SRC feature.
- The number of SRC subnode should be same as HW.
- see below for detail.
-- rcar_sound,ctu : Should contain CTU feature.
- The number of CTU subnode should be same as HW.
- see below for detail.
-- rcar_sound,mix : Should contain MIX feature.
- The number of MIX subnode should be same as HW.
- see below for detail.
-- rcar_sound,dvc : Should contain DVC feature.
- The number of DVC subnode should be same as HW.
- see below for detail.
-- rcar_sound,dai : DAI contents.
- The number of DAI subnode should be same as HW.
- see below for detail.
-- #sound-dai-cells : it must be 0 if your system is using single DAI
- it must be 1 if your system is using multi DAI
-- clocks : References to SSI/SRC/MIX/CTU/DVC/AUDIO_CLK clocks.
-- clock-names : List of necessary clock names.
- "ssi-all", "ssi.X", "src.X", "mix.X", "ctu.X",
- "dvc.X", "clk_a", "clk_b", "clk_c", "clk_i"
-
-Optional properties:
-- #clock-cells : it must be 0 if your system has audio_clkout
- it must be 1 if your system has audio_clkout0/1/2/3
-- clock-frequency : for all audio_clkout0/1/2/3
-- clkout-lr-asynchronous : boolean property. it indicates that audio_clkoutn
- is asynchronizes with lr-clock.
-- resets : References to SSI resets.
-- reset-names : List of valid reset names.
- "ssi-all", "ssi.X"
-
-SSI subnode properties:
-- interrupts : Should contain SSI interrupt for PIO transfer
-- shared-pin : if shared clock pin
-- pio-transfer : use PIO transfer mode
-- no-busif : BUSIF is not ussed when [mem -> SSI] via DMA case
-- dma : Should contain Audio DMAC entry
-- dma-names : SSI case "rx" (=playback), "tx" (=capture)
- Deprecated: see SSIU subnode properties
- SSIU case "rxu" (=playback), "txu" (=capture)
-
-SSIU subnode properties:
-- dma : Should contain Audio DMAC entry
-- dma-names : "rx" (=playback), "tx" (=capture)
-
-SRC subnode properties:
-- dma : Should contain Audio DMAC entry
-- dma-names : "rx" (=playback), "tx" (=capture)
-
-DVC subnode properties:
-- dma : Should contain Audio DMAC entry
-- dma-names : "tx" (=playback/capture)
-
-DAI subnode properties:
-- playback : list of playback modules
-- capture : list of capture modules
-
-
-=============================================
-Example:
-=============================================
-
-rcar_sound: sound@ec500000 {
- #sound-dai-cells = <1>;
- compatible = "renesas,rcar_sound-r8a7791", "renesas,rcar_sound-gen2";
- reg = <0 0xec500000 0 0x1000>, /* SCU */
- <0 0xec5a0000 0 0x100>, /* ADG */
- <0 0xec540000 0 0x1000>, /* SSIU */
- <0 0xec541000 0 0x1280>, /* SSI */
- <0 0xec740000 0 0x200>; /* Audio DMAC peri peri*/
- reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
-
- clocks = <&mstp10_clks R8A7790_CLK_SSI_ALL>,
- <&mstp10_clks R8A7790_CLK_SSI9>, <&mstp10_clks R8A7790_CLK_SSI8>,
- <&mstp10_clks R8A7790_CLK_SSI7>, <&mstp10_clks R8A7790_CLK_SSI6>,
- <&mstp10_clks R8A7790_CLK_SSI5>, <&mstp10_clks R8A7790_CLK_SSI4>,
- <&mstp10_clks R8A7790_CLK_SSI3>, <&mstp10_clks R8A7790_CLK_SSI2>,
- <&mstp10_clks R8A7790_CLK_SSI1>, <&mstp10_clks R8A7790_CLK_SSI0>,
- <&mstp10_clks R8A7790_CLK_SCU_SRC9>, <&mstp10_clks R8A7790_CLK_SCU_SRC8>,
- <&mstp10_clks R8A7790_CLK_SCU_SRC7>, <&mstp10_clks R8A7790_CLK_SCU_SRC6>,
- <&mstp10_clks R8A7790_CLK_SCU_SRC5>, <&mstp10_clks R8A7790_CLK_SCU_SRC4>,
- <&mstp10_clks R8A7790_CLK_SCU_SRC3>, <&mstp10_clks R8A7790_CLK_SCU_SRC2>,
- <&mstp10_clks R8A7790_CLK_SCU_SRC1>, <&mstp10_clks R8A7790_CLK_SCU_SRC0>,
- <&mstp10_clks R8A7790_CLK_SCU_DVC0>, <&mstp10_clks R8A7790_CLK_SCU_DVC1>,
- <&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>, <&m2_clk>;
- clock-names = "ssi-all",
- "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
- "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
- "src.9", "src.8", "src.7", "src.6", "src.5",
- "src.4", "src.3", "src.2", "src.1", "src.0",
- "dvc.0", "dvc.1",
- "clk_a", "clk_b", "clk_c", "clk_i";
-
- rcar_sound,dvc {
- dvc0: dvc-0 {
- dmas = <&audma0 0xbc>;
- dma-names = "tx";
- };
- dvc1: dvc-1 {
- dmas = <&audma0 0xbe>;
- dma-names = "tx";
- };
- };
-
- rcar_sound,mix {
- mix0: mix-0 { };
- mix1: mix-1 { };
- };
-
- rcar_sound,ctu {
- ctu00: ctu-0 { };
- ctu01: ctu-1 { };
- ctu02: ctu-2 { };
- ctu03: ctu-3 { };
- ctu10: ctu-4 { };
- ctu11: ctu-5 { };
- ctu12: ctu-6 { };
- ctu13: ctu-7 { };
- };
-
- rcar_sound,src {
- src0: src-0 {
- interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x85>, <&audma1 0x9a>;
- dma-names = "rx", "tx";
- };
- src1: src-1 {
- interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x87>, <&audma1 0x9c>;
- dma-names = "rx", "tx";
- };
- src2: src-2 {
- interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x89>, <&audma1 0x9e>;
- dma-names = "rx", "tx";
- };
- src3: src-3 {
- interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x8b>, <&audma1 0xa0>;
- dma-names = "rx", "tx";
- };
- src4: src-4 {
- interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x8d>, <&audma1 0xb0>;
- dma-names = "rx", "tx";
- };
- src5: src-5 {
- interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x8f>, <&audma1 0xb2>;
- dma-names = "rx", "tx";
- };
- src6: src-6 {
- interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x91>, <&audma1 0xb4>;
- dma-names = "rx", "tx";
- };
- src7: src-7 {
- interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x93>, <&audma1 0xb6>;
- dma-names = "rx", "tx";
- };
- src8: src-8 {
- interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x95>, <&audma1 0xb8>;
- dma-names = "rx", "tx";
- };
- src9: src-9 {
- interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x97>, <&audma1 0xba>;
- dma-names = "rx", "tx";
- };
- };
-
- rcar_sound,ssiu {
- ssiu00: ssiu-0 {
- dmas = <&audma0 0x15>, <&audma1 0x16>;
- dma-names = "rx", "tx";
- };
- ssiu01: ssiu-1 {
- dmas = <&audma0 0x35>, <&audma1 0x36>;
- dma-names = "rx", "tx";
- };
-
- ...
-
- ssiu95: ssiu-49 {
- dmas = <&audma0 0xA5>, <&audma1 0xA6>;
- dma-names = "rx", "tx";
- };
- ssiu96: ssiu-50 {
- dmas = <&audma0 0xA7>, <&audma1 0xA8>;
- dma-names = "rx", "tx";
- };
- ssiu97: ssiu-51 {
- dmas = <&audma0 0xA9>, <&audma1 0xAA>;
- dma-names = "rx", "tx";
- };
- };
-
- rcar_sound,ssi {
- ssi0: ssi-0 {
- interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x01>, <&audma1 0x02>;
- dma-names = "rx", "tx";
- };
- ssi1: ssi-1 {
- interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x03>, <&audma1 0x04>;
- dma-names = "rx", "tx";
- };
-
- ...
-
- ssi8: ssi-8 {
- interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x11>, <&audma1 0x12>;
- dma-names = "rx", "tx";
- };
- ssi9: ssi-9 {
- interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&audma0 0x13>, <&audma1 0x14>;
- dma-names = "rx", "tx";
- };
- };
-
- rcar_sound,dai {
- dai0 {
- playback = <&ssi5 &src5>;
- capture = <&ssi6>;
- };
- dai1 {
- playback = <&ssi3>;
- };
- dai2 {
- capture = <&ssi4>;
- };
- dai3 {
- playback = <&ssi7>;
- };
- dai4 {
- capture = <&ssi8>;
- };
- };
-};
-
-=============================================
-Example: simple sound card
-=============================================
-
- rsnd_ak4643: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "left_j";
- simple-audio-card,bitclock-master = <&sndcodec>;
- simple-audio-card,frame-master = <&sndcodec>;
-
- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
-
- sndcodec: simple-audio-card,codec {
- sound-dai = <&ak4643>;
- clocks = <&audio_clock>;
- };
- };
-
-&rcar_sound {
- pinctrl-0 = <&sound_pins &sound_clk_pins>;
- pinctrl-names = "default";
-
- /* Single DAI */
- #sound-dai-cells = <0>;
-
-
- rcar_sound,dai {
- dai0 {
- playback = <&ssi0 &src2 &dvc0>;
- capture = <&ssi1 &src3 &dvc1>;
- };
- };
-};
-
-&ssi1 {
- shared-pin;
-};
-
-=============================================
-Example: simple sound card for Asynchronous mode
-=============================================
-
-sound {
- compatible = "simple-scu-audio-card";
- ...
- /*
- * SRC Asynchronous mode setting
- * Playback:
- * All input data will be converted to 48kHz
- * Capture:
- * Inputed 48kHz data will be converted to
- * system specified Hz
- */
- simple-audio-card,convert-rate = <48000>;
- ...
- simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
- simple-audio-card,codec {
- ...
- };
-};
-
-=============================================
-Example: simple sound card for channel convert
-=============================================
-
-sound {
- compatible = "simple-scu-audio-card";
- ...
- /*
- * CTU setting
- * All input data will be converted to 2ch
- * as output data
- */
- simple-audio-card,convert-channels = <2>;
- ...
- simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- };
- simple-audio-card,codec {
- ...
- };
-};
-
-=============================================
-Example: simple sound card for MIXer
-=============================================
-
-sound {
- compatible = "simple-scu-audio-card";
- ...
- simple-audio-card,cpu@0 {
- sound-dai = <&rcar_sound 0>;
- };
- simple-audio-card,cpu@1 {
- sound-dai = <&rcar_sound 1>;
- };
- simple-audio-card,codec {
- ...
- };
-};
-
-&rcar_sound {
- ...
- rcar_sound,dai {
- dai0 {
- playback = <&src1 &ctu02 &mix0 &dvc0 &ssi0>;
- };
- dai1 {
- playback = <&src2 &ctu03 &mix0 &dvc0 &ssi0>;
- };
- };
-};
-
-=============================================
-Example: simple sound card for TDM
-=============================================
-
-rsnd_tdm: sound {
- compatible = "simple-audio-card";
-
- simple-audio-card,format = "left_j";
- simple-audio-card,bitclock-master = <&sndcodec>;
- simple-audio-card,frame-master = <&sndcodec>;
-
- sndcpu: simple-audio-card,cpu {
- sound-dai = <&rcar_sound>;
- dai-tdm-slot-num = <6>;
- };
-
- sndcodec: simple-audio-card,codec {
- sound-dai = <&xxx>;
- };
-};
-
-=============================================
-Example: simple sound card for TDM Split
-=============================================
-
-sound_card: sound {
- compatible = "audio-graph-scu-card";
- prefix = "xxxx";
- routing = "xxxx Playback", "DAI0 Playback",
- "xxxx Playback", "DAI1 Playback",
- "xxxx Playback", "DAI2 Playback",
- "xxxx Playback", "DAI3 Playback";
- convert-channels = <8>; /* TDM Split */
-
- dais = <&rsnd_port0 /* playback ch1/ch2 */
- &rsnd_port1 /* playback ch3/ch4 */
- &rsnd_port2 /* playback ch5/ch6 */
- &rsnd_port3 /* playback ch7/ch8 */
- >;
-};
-
-audio-codec {
- ...
- port {
- codec_0: endpoint@1 {
- remote-endpoint = <&rsnd_ep0>;
- };
- codec_1: endpoint@2 {
- remote-endpoint = <&rsnd_ep1>;
- };
- codec_2: endpoint@3 {
- remote-endpoint = <&rsnd_ep2>;
- };
- codec_3: endpoint@4 {
- remote-endpoint = <&rsnd_ep3>;
- };
- };
-};
-
-&rcar_sound {
- ...
- ports {
- rsnd_port0: port@0 {
- rsnd_ep0: endpoint {
- remote-endpoint = <&codec_0>;
- ...
- playback = <&ssiu30 &ssi3>;
- };
- };
- rsnd_port1: port@1 {
- rsnd_ep1: endpoint {
- remote-endpoint = <&codec_1>;
- ...
- playback = <&ssiu31 &ssi3>;
- };
- };
- rsnd_port2: port@2 {
- rsnd_ep2: endpoint {
- remote-endpoint = <&codec_2>;
- ...
- playback = <&ssiu32 &ssi3>;
- };
- };
- rsnd_port3: port@3 {
- rsnd_ep3: endpoint {
- remote-endpoint = <&codec_3>;
- ...
- playback = <&ssiu33 &ssi3>;
- };
- };
- };
-};
-
-=============================================
-Example: simple sound card for Multi channel
-=============================================
-
-&rcar_sound {
- pinctrl-0 = <&sound_pins &sound_clk_pins>;
- pinctrl-names = "default";
-
- /* Single DAI */
- #sound-dai-cells = <0>;
-
-
- rcar_sound,dai {
- dai0 {
- playback = <&ssi0 &ssi1 &ssi2 &src0 &dvc0>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
new file mode 100644
index 0000000..0fd37aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
@@ -0,0 +1,447 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/renesas,rsnd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Sound Driver Device Tree Bindings
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+properties:
+
+ compatible:
+ oneOf:
+ # for Gen1 SoC
+ - items:
+ - enum:
+ - renesas,rcar_sound-r8a7778 # R-Car M1A
+ - renesas,rcar_sound-r8a7779 # R-Car H1
+ - enum:
+ - renesas,rcar_sound-gen1
+ # for Gen2 SoC
+ - items:
+ - enum:
+ - renesas,rcar_sound-r8a7742 # RZ/G1H
+ - renesas,rcar_sound-r8a7743 # RZ/G1M
+ - renesas,rcar_sound-r8a7744 # RZ/G1N
+ - renesas,rcar_sound-r8a7745 # RZ/G1E
+ - renesas,rcar_sound-r8a77470 # RZ/G1C
+ - renesas,rcar_sound-r8a7790 # R-Car H2
+ - renesas,rcar_sound-r8a7791 # R-Car M2-W
+ - renesas,rcar_sound-r8a7793 # R-Car M2-N
+ - renesas,rcar_sound-r8a7794 # R-Car E2
+ - enum:
+ - renesas,rcar_sound-gen2
+ # for Gen3 SoC
+ - items:
+ - enum:
+ - renesas,rcar_sound-r8a774a1 # RZ/G2M
+ - renesas,rcar_sound-r8a774b1 # RZ/G2N
+ - renesas,rcar_sound-r8a774c0 # RZ/G2E
+ - renesas,rcar_sound-r8a774e1 # RZ/G2H
+ - renesas,rcar_sound-r8a7795 # R-Car H3
+ - renesas,rcar_sound-r8a7796 # R-Car M3-W
+ - renesas,rcar_sound-r8a77961 # R-Car M3-W+
+ - renesas,rcar_sound-r8a77965 # R-Car M3-N
+ - renesas,rcar_sound-r8a77990 # R-Car E3
+ - renesas,rcar_sound-r8a77995 # R-Car D3
+ - enum:
+ - renesas,rcar_sound-gen3
+ # for Generic
+ - items:
+ - enum:
+ - renesas,rcar_sound-gen1
+ - renesas,rcar_sound-gen2
+ - renesas,rcar_sound-gen3
+
+ reg:
+ minItems: 1
+ maxItems: 5
+
+ reg-names:
+ minItems: 1
+ maxItems: 5
+
+ "#sound-dai-cells":
+ description: |
+ it must be 0 if your system is using single DAI
+ it must be 1 if your system is using multi DAIs
+ enum: [0, 1]
+
+ "#clock-cells":
+ description: |
+ it must be 0 if your system has audio_clkout
+ it must be 1 if your system has audio_clkout0/1/2/3
+ enum: [0, 1]
+
+ clock-frequency:
+ description: for audio_clkout0/1/2/3
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ clkout-lr-asynchronous:
+ description: audio_clkoutn is asynchronizes with lr-clock.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ power-domains: true
+
+ resets:
+ maxItems: 11
+
+ reset-names:
+ maxItems: 11
+
+ clocks:
+ description: References to SSI/SRC/MIX/CTU/DVC/AUDIO_CLK clocks.
+ minItems: 1
+ maxItems: 31
+
+ clock-names:
+ description: List of necessary clock names.
+ minItems: 1
+ maxItems: 31
+ items:
+ oneOf:
+ - const: ssi-all
+ - pattern: '^ssi\.[0-9]$'
+ - pattern: '^src\.[0-9]$'
+ - pattern: '^mix\.[0-1]$'
+ - pattern: '^ctu\.[0-1]$'
+ - pattern: '^dvc\.[0-1]$'
+ - pattern: '^clk_(a|b|c|i)$'
+
+ port: true
+
+# use patternProperties to avoid naming "xxx,yyy" issue
+patternProperties:
+ "^rcar_sound,dvc$":
+ description: DVC subnode.
+ type: object
+ patternProperties:
+ "^dvc-[0-1]$":
+ type: object
+ properties:
+ dmas:
+ maxItems: 1
+ dma-names:
+ const: "tx"
+ required:
+ - dmas
+ - dma-names
+ additionalProperties: false
+
+ "^rcar_sound,mix$":
+ description: MIX subnode.
+ type: object
+ patternProperties:
+ "^mix-[0-1]$":
+ type: object
+ # no properties
+ additionalProperties: false
+
+ "^rcar_sound,ctu$":
+ description: CTU subnode.
+ type: object
+ patternProperties:
+ "^ctu-[0-7]$":
+ type: object
+ # no properties
+ additionalProperties: false
+
+ "^rcar_sound,src$":
+ description: SRC subnode.
+ type: object
+ patternProperties:
+ "^src-[0-9]$":
+ type: object
+ properties:
+ interrupts:
+ maxItems: 1
+ dmas:
+ maxItems: 2
+ dma-names:
+ allOf:
+ - items:
+ enum:
+ - tx
+ - rx
+ required:
+ - interrupts
+ - dmas
+ - dma-names
+ additionalProperties: false
+
+ "^rcar_sound,ssiu$":
+ description: SSIU subnode.
+ type: object
+ patternProperties:
+ "^ssiu-[0-9]+$":
+ type: object
+ properties:
+ dmas:
+ maxItems: 2
+ dma-names:
+ allOf:
+ - items:
+ enum:
+ - tx
+ - rx
+ required:
+ - dmas
+ - dma-names
+ additionalProperties: false
+
+ "^rcar_sound,ssi$":
+ description: SSI subnode.
+ type: object
+ patternProperties:
+ "^ssi-[0-9]$":
+ type: object
+ properties:
+ interrupts:
+ maxItems: 1
+ dmas:
+ minItems: 2
+ maxItems: 4
+ dma-names:
+ allOf:
+ - items:
+ enum:
+ - tx
+ - rx
+ - txu # if no ssiu node
+ - rxu # if no ssiu node
+
+ shared-pin:
+ description: shared clock pin
+ $ref: /schemas/types.yaml#/definitions/flag
+ pio-transfer:
+ description: PIO transfer mode
+ $ref: /schemas/types.yaml#/definitions/flag
+ no-busif:
+ description: BUSIF is not used when [mem -> SSI] via DMA case
+ $ref: /schemas/types.yaml#/definitions/flag
+ required:
+ - interrupts
+ - dmas
+ - dma-names
+ additionalProperties: false
+
+ # For DAI base
+ "^rcar_sound,dai$":
+ description: DAI subnode.
+ type: object
+ patternProperties:
+ "^dai([0-9]+)?$":
+ type: object
+ properties:
+ playback:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ capture:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ anyOf:
+ - required:
+ - playback
+ - required:
+ - capture
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - "#sound-dai-cells"
+
+allOf:
+ - $ref: audio-graph.yaml#
+ - $ref: audio-graph-port.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rcar_sound-gen1
+ then:
+ properties:
+ reg:
+ maxItems: 3
+ reg-names:
+ maxItems: 3
+ items:
+ enum:
+ - scu
+ - ssi
+ - adg
+ else:
+ properties:
+ reg:
+ maxItems: 5
+ reg-names:
+ maxItems: 5
+ items:
+ enum:
+ - scu
+ - adg
+ - ssiu
+ - ssi
+ - audmapp
+
+additionalProperties: false
+
+examples:
+ - |
+ rcar_sound: sound@ec500000 {
+ #sound-dai-cells = <1>;
+ compatible = "renesas,rcar_sound-r8a7790", "renesas,rcar_sound-gen2";
+ reg = <0xec500000 0x1000>, /* SCU */
+ <0xec5a0000 0x100>, /* ADG */
+ <0xec540000 0x1000>, /* SSIU */
+ <0xec541000 0x1280>, /* SSI */
+ <0xec740000 0x200>; /* Audio DMAC peri peri*/
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+ clocks = <&mstp10_clks 1005>, /* SSI-ALL */
+ <&mstp10_clks 1006>, <&mstp10_clks 1007>, /* SSI9, SSI8 */
+ <&mstp10_clks 1008>, <&mstp10_clks 1009>, /* SSI7, SSI6 */
+ <&mstp10_clks 1010>, <&mstp10_clks 1011>, /* SSI5, SSI4 */
+ <&mstp10_clks 1012>, <&mstp10_clks 1013>, /* SSI3, SSI2 */
+ <&mstp10_clks 1014>, <&mstp10_clks 1015>, /* SSI1, SSI0 */
+ <&mstp10_clks 1022>, <&mstp10_clks 1023>, /* SRC9, SRC8 */
+ <&mstp10_clks 1024>, <&mstp10_clks 1025>, /* SRC7, SRC6 */
+ <&mstp10_clks 1026>, <&mstp10_clks 1027>, /* SRC5, SRC4 */
+ <&mstp10_clks 1028>, <&mstp10_clks 1029>, /* SRC3, SRC2 */
+ <&mstp10_clks 1030>, <&mstp10_clks 1031>, /* SRC1, SRC0 */
+ <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* MIX1, MIX0 */
+ <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* CTU1, CTU0 */
+ <&mstp10_clks 1019>, <&mstp10_clks 1018>, /* DVC0, DVC1 */
+ <&audio_clk_a>, <&audio_clk_b>, /* CLKA, CLKB */
+ <&audio_clk_c>, <&audio_clk_i>; /* CLKC, CLKI */
+
+ clock-names = "ssi-all",
+ "ssi.9", "ssi.8",
+ "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4",
+ "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0",
+ "src.9", "src.8",
+ "src.7", "src.6",
+ "src.5", "src.4",
+ "src.3", "src.2",
+ "src.1", "src.0",
+ "mix.1", "mix.0",
+ "ctu.1", "ctu.0",
+ "dvc.0", "dvc.1",
+ "clk_a", "clk_b",
+ "clk_c", "clk_i";
+
+ rcar_sound,dvc {
+ dvc0: dvc-0 {
+ dmas = <&audma0 0xbc>;
+ dma-names = "tx";
+ };
+ dvc1: dvc-1 {
+ dmas = <&audma0 0xbe>;
+ dma-names = "tx";
+ };
+ };
+
+ rcar_sound,mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
+ rcar_sound,ctu {
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
+ };
+
+ rcar_sound,src {
+ src0: src-0 {
+ status = "disabled";
+ };
+ src1: src-1 {
+ interrupts = <0 353 0>;
+ dmas = <&audma0 0x87>, <&audma1 0x9c>;
+ dma-names = "rx", "tx";
+ };
+ /* skip after src-2 */
+ };
+
+ rcar_sound,ssiu {
+ ssiu00: ssiu-0 {
+ dmas = <&audma0 0x15>, <&audma1 0x16>;
+ dma-names = "rx", "tx";
+ };
+ ssiu01: ssiu-1 {
+ dmas = <&audma0 0x35>, <&audma1 0x36>;
+ dma-names = "rx", "tx";
+ };
+ /* skip after ssiu-2 */
+ };
+
+ rcar_sound,ssi {
+ ssi0: ssi-0 {
+ interrupts = <0 370 1>;
+ dmas = <&audma0 0x01>, <&audma1 0x02>;
+ dma-names = "rx", "tx";
+ };
+ ssi1: ssi-1 {
+ interrupts = <0 371 1>;
+ dmas = <&audma0 0x03>, <&audma1 0x04>;
+ dma-names = "rx", "tx";
+ };
+ /* skip other ssi-2 */
+ };
+
+ /* DAI base */
+ rcar_sound,dai {
+ dai0 {
+ playback = <&ssi5 &src5>;
+ capture = <&ssi6>;
+ };
+ dai1 {
+ playback = <&ssi3>;
+ };
+ dai2 {
+ capture = <&ssi4>;
+ };
+ dai3 {
+ playback = <&ssi7>;
+ };
+ dai4 {
+ capture = <&ssi8>;
+ };
+ };
+
+ /* assume audio-graph */
+ port {
+ rsnd_endpoint: endpoint {
+ remote-endpoint = <&codec_endpoint>;
+
+ dai-format = "left_j";
+ bitclock-master = <&rsnd_endpoint0>;
+ frame-master = <&rsnd_endpoint0>;
+
+ playback = <&ssi0 &src0 &dvc0>;
+ capture = <&ssi1 &src1 &dvc1>;
+ };
+ };
+ };
+
+
+ /* assume audio-graph */
+ codec {
+ port {
+ codec_endpoint: endpoint {
+ remote-endpoint = <&rsnd_endpoint>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/rt5682.txt b/Documentation/devicetree/bindings/sound/rt5682.txt
index 707fa98..9c5fadb 100644
--- a/Documentation/devicetree/bindings/sound/rt5682.txt
+++ b/Documentation/devicetree/bindings/sound/rt5682.txt
@@ -44,6 +44,8 @@
- realtek,dmic-delay-ms : Set the delay time (ms) for the requirement of
the particular DMIC.
+- realtek,dmic-clk-driving-high : Set the high drving of the DMIC clock out.
+
Pins on the device (for linking into audio routes) for RT5682:
* DMIC L1
diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
new file mode 100644
index 0000000..5986d1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/simple-audio-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple Audio Multiplexer
+
+maintainers:
+ - Alexandre Belloni <aleandre.belloni@bootlin.com>
+
+description: |
+ Simple audio multiplexers are driven using gpios, allowing to select which of
+ their input line is connected to the output line.
+
+properties:
+ compatible:
+ const: simple-audio-mux
+
+ mux-gpios:
+ description: |
+ GPIOs used to select the input line.
+
+ sound-name-prefix:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Used as prefix for sink/source names of the component. Must be a
+ unique string among multiple instances of the same component.
+
+required:
+ - compatible
+ - mux-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ mux {
+ compatible = "simple-audio-mux";
+ mux-gpios = <&gpio 3 0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml
index 35e6690..45fd9fd 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
@@ -13,13 +13,11 @@
frame-master:
description: Indicates dai-link frame master.
- $ref: /schemas/types.yaml#/definitions/phandle-array
- maxItems: 1
+ $ref: /schemas/types.yaml#/definitions/phandle
bitclock-master:
description: Indicates dai-link bit clock master
- $ref: /schemas/types.yaml#/definitions/phandle-array
- maxItems: 1
+ $ref: /schemas/types.yaml#/definitions/phandle
frame-inversion:
description: dai-link uses frame clock inversion
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt b/Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt
deleted file mode 100644
index 864f5b0..0000000
--- a/Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-STMicroelectronics Audio Digital Filter Sigma Delta modulators(DFSDM)
-
-The DFSDM allows PDM microphones capture through SPI interface. The Audio
-interface is seems as a sub block of the DFSDM device.
-For details on DFSDM bindings refer to ../iio/adc/st,stm32-dfsdm-adc.txt
-
-Required properties:
- - compatible: "st,stm32h7-dfsdm-dai".
-
- - #sound-dai-cells : Must be equal to 0
-
- - io-channels : phandle to iio dfsdm instance node.
-
-Example of a sound card using audio DFSDM node.
-
- sound_card {
- compatible = "audio-graph-card";
-
- dais = <&cpu_port>;
- };
-
- dfsdm: dfsdm@40017000 {
- compatible = "st,stm32h7-dfsdm";
- reg = <0x40017000 0x400>;
- clocks = <&rcc DFSDM1_CK>;
- clock-names = "dfsdm";
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- dfsdm_adc0: filter@0 {
- compatible = "st,stm32-dfsdm-dmic";
- reg = <0>;
- interrupts = <110>;
- dmas = <&dmamux1 101 0x400 0x00>;
- dma-names = "rx";
- st,adc-channels = <1>;
- st,adc-channel-names = "dmic0";
- st,adc-channel-types = "SPI_R";
- st,adc-channel-clk-src = "CLKOUT";
- st,filter-order = <5>;
-
- dfsdm_dai0: dfsdm-dai {
- compatible = "st,stm32h7-dfsdm-dai";
- #sound-dai-cells = <0>;
- io-channels = <&dfsdm_adc0 0>;
- cpu_port: port {
- dfsdm_endpoint: endpoint {
- remote-endpoint = <&dmic0_endpoint>;
- };
- };
- };
- };
-
- dmic0: dmic@0 {
- compatible = "dmic-codec";
- #sound-dai-cells = <0>;
- port {
- dmic0_endpoint: endpoint {
- remote-endpoint = <&dfsdm_endpoint>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
deleted file mode 100644
index c42b91e..0000000
--- a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-STMicroelectronics STM32 Serial Audio Interface (SAI).
-
-The SAI interface (Serial Audio Interface) offers a wide set of audio protocols
-as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97.
-The SAI contains two independent audio sub-blocks. Each sub-block has
-its own clock generator and I/O lines controller.
-
-Required properties:
- - compatible: Should be "st,stm32f4-sai" or "st,stm32h7-sai"
- - reg: Base address and size of SAI common register set.
- - clocks: Must contain phandle and clock specifier pairs for each entry
- in clock-names.
- - clock-names: Must contain "pclk" "x8k" and "x11k"
- "pclk": Clock which feeds the peripheral bus interface.
- Mandatory for "st,stm32h7-sai" compatible.
- Not used for "st,stm32f4-sai" compatible.
- "x8k": SAI parent clock for sampling rates multiple of 8kHz.
- "x11k": SAI parent clock for sampling rates multiple of 11.025kHz.
- - interrupts: cpu DAI interrupt line shared by SAI sub-blocks
-
-Optional properties:
- - resets: Reference to a reset controller asserting the SAI
-
-SAI subnodes:
-Two subnodes corresponding to SAI sub-block instances A et B can be defined.
-Subnode can be omitted for unsused sub-block.
-
-SAI subnodes required properties:
- - compatible: Should be "st,stm32-sai-sub-a" or "st,stm32-sai-sub-b"
- for SAI sub-block A or B respectively.
- - reg: Base address and size of SAI sub-block register set.
- - clocks: Must contain one phandle and clock specifier pair
- for sai_ck which feeds the internal clock generator.
- If the SAI shares a master clock, with another SAI set as MCLK
- clock provider, SAI provider phandle must be specified here.
- - clock-names: Must contain "sai_ck".
- Must also contain "MCLK", if SAI shares a master clock,
- with a SAI set as MCLK clock provider.
- - dmas: see Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
- - dma-names: identifier string for each DMA request line
- "tx": if sai sub-block is configured as playback DAI
- "rx": if sai sub-block is configured as capture DAI
- - pinctrl-names: should contain only value "default"
- - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
-
-SAI subnodes Optional properties:
- - st,sync: specify synchronization mode.
- By default SAI sub-block is in asynchronous mode.
- This property sets SAI sub-block as slave of another SAI sub-block.
- Must contain the phandle and index of the sai sub-block providing
- the synchronization.
- - st,iec60958: support S/PDIF IEC6958 protocol for playback
- IEC60958 protocol is not available for capture.
- By default, custom protocol is assumed, meaning that protocol is
- configured according to protocol defined in related DAI link node,
- such as i2s, left justified, right justified, dsp and pdm protocols.
- Note: ac97 protocol is not supported by SAI driver
- - #clock-cells: should be 0. This property must be present if the SAI device
- is a master clock provider, according to clocks bindings, described in
- Documentation/devicetree/bindings/clock/clock-bindings.txt.
-
-The device node should contain one 'port' child node with one child 'endpoint'
-node, according to the bindings defined in Documentation/devicetree/bindings/
-graph.txt.
-
-Example:
-sound_card {
- compatible = "audio-graph-card";
- dais = <&sai1b_port>;
-};
-
-sai1: sai1@40015800 {
- compatible = "st,stm32h7-sai";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x40015800 0x400>;
- reg = <0x40015800 0x4>;
- clocks = <&rcc SAI1_CK>, <&rcc PLL1_Q>, <&rcc PLL2_P>;
- clock-names = "pclk", "x8k", "x11k";
- interrupts = <87>;
-
- sai1a: audio-controller@40015804 {
- compatible = "st,stm32-sai-sub-a";
- reg = <0x4 0x1C>;
- clocks = <&rcc SAI1_CK>;
- clock-names = "sai_ck";
- dmas = <&dmamux1 1 87 0x400 0x0>;
- dma-names = "tx";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sai1a>;
-
- sai1b_port: port {
- cpu_endpoint: endpoint {
- remote-endpoint = <&codec_endpoint>;
- format = "i2s";
- };
- };
- };
-};
-
-audio-codec {
- codec_port: port {
- codec_endpoint: endpoint {
- remote-endpoint = <&cpu_endpoint>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
new file mode 100644
index 0000000..f2443b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
@@ -0,0 +1,200 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/st,stm32-sai.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 Serial Audio Interface (SAI)
+
+maintainers:
+ - Olivier Moysan <olivier.moysan@st.com>
+
+description:
+ The SAI interface (Serial Audio Interface) offers a wide set of audio
+ protocols as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97.
+ The SAI contains two independent audio sub-blocks. Each sub-block has
+ its own clock generator and I/O lines controller.
+
+properties:
+ compatible:
+ enum:
+ - st,stm32f4-sai
+ - st,stm32h7-sai
+
+ reg:
+ items:
+ - description: Base address and size of SAI common register set.
+ - description: Base address and size of SAI identification register set.
+ minItems: 1
+ maxItems: 2
+
+ ranges:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ maxItems: 3
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+ - clocks
+ - clock-names
+
+patternProperties:
+ "^audio-controller@[0-9a-f]+$":
+ type: object
+ description:
+ Two subnodes corresponding to SAI sub-block instances A et B
+ can be defined. Subnode can be omitted for unsused sub-block.
+
+ properties:
+ compatible:
+ description: Compatible for SAI sub-block A or B.
+ pattern: "st,stm32-sai-sub-[ab]"
+
+ "#sound-dai-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: sai_ck clock feeding the internal clock generator.
+ - description: MCLK clock from a SAI set as master clock provider.
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: sai_ck
+ - const: MCLK
+ minItems: 1
+ maxItems: 2
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ description: |
+ rx: SAI sub-block is configured as a capture DAI.
+ tx: SAI sub-block is configured as a playback DAI.
+ enum: [ rx, tx ]
+
+ st,sync:
+ description:
+ Configure the SAI sub-block as slave of another SAI sub-block.
+ By default SAI sub-block is in asynchronous mode.
+ Must contain the phandle and index of the SAI sub-block providing
+ the synchronization.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle-array
+ - maxItems: 1
+
+ st,iec60958:
+ description:
+ If set, support S/PDIF IEC6958 protocol for playback.
+ IEC60958 protocol is not available for capture.
+ By default, custom protocol is assumed, meaning that protocol is
+ configured according to protocol defined in related DAI link node,
+ such as i2s, left justified, right justified, dsp and pdm protocols.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/flag
+
+ "#clock-cells":
+ description: Configure the SAI device as master clock provider.
+ const: 0
+
+ required:
+ - compatible
+ - "#sound-dai-cells"
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32f4-sai
+
+ - then:
+ properties:
+ clocks:
+ items:
+ - description: x8k, SAI parent clock for sampling rates multiple of 8kHz.
+ - description: x11k, SAI parent clock for sampling rates multiple of 11.025kHz.
+
+ clock-names:
+ items:
+ - const: x8k
+ - const: x11k
+
+ - else:
+ properties:
+ clocks:
+ items:
+ - description: pclk feeds the peripheral bus interface.
+ - description: x8k, SAI parent clock for sampling rates multiple of 8kHz.
+ - description: x11k, SAI parent clock for sampling rates multiple of 11.025kHz.
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: x8k
+ - const: x11k
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+ #include <dt-bindings/reset/stm32mp1-resets.h>
+ sai2: sai@4400b000 {
+ compatible = "st,stm32h7-sai";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x4400b000 0x400>;
+ reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>;
+ clocks = <&rcc SAI2>, <&rcc PLL3_Q>, <&rcc PLL3_R>;
+ clock-names = "pclk", "x8k", "x11k";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&sai2a_pins_a>, <&sai2b_pins_b>;
+ pinctrl-1 = <&sai2a_sleep_pins_a>, <&sai2b_sleep_pins_b>;
+ status = "okay";
+
+ sai2a: audio-controller@4400b004 {
+ #sound-dai-cells = <0>;
+ compatible = "st,stm32-sai-sub-a";
+ reg = <0x4 0x1c>;
+ dmas = <&dmamux1 89 0x400 0x01>;
+ dma-names = "tx";
+ clocks = <&rcc SAI2_K>;
+ clock-names = "sai_ck";
+ status = "okay";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
index 99ed9b4..4825157 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -65,6 +65,8 @@
const: baikal,bt1-ssi
- description: Baikal-T1 System Boot SPI Controller
const: baikal,bt1-sys-ssi
+ - description: Canaan Kendryte K210 SoS SPI Controller
+ const: canaan,k210-spi
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml
index 1b56d5e..5f50581 100644
--- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -42,6 +42,33 @@
cs2 : &gpio1 1 0
cs3 : &gpio1 2 0
+ The second flag of a gpio descriptor can be GPIO_ACTIVE_HIGH (0)
+ or GPIO_ACTIVE_LOW(1). Legacy device trees often use 0.
+
+ There is a special rule set for combining the second flag of an
+ cs-gpio with the optional spi-cs-high flag for SPI slaves.
+
+ Each table entry defines how the CS pin is to be physically
+ driven (not considering potential gpio inversions by pinmux):
+
+ device node | cs-gpio | CS pin state active | Note
+ ================+===============+=====================+=====
+ spi-cs-high | - | H |
+ - | - | L |
+ spi-cs-high | ACTIVE_HIGH | H |
+ - | ACTIVE_HIGH | L | 1
+ spi-cs-high | ACTIVE_LOW | H | 2
+ - | ACTIVE_LOW | L |
+
+ Notes:
+ 1) Should print a warning about polarity inversion.
+ Here it would be wise to avoid and define the gpio as
+ ACTIVE_LOW.
+ 2) Should print a warning about polarity inversion
+ because ACTIVE_LOW is overridden by spi-cs-high.
+ Should be generally avoided and be replaced by
+ spi-cs-high + ACTIVE_HIGH.
+
num-cs:
$ref: /schemas/types.yaml#/definitions/uint32
description:
diff --git a/Documentation/devicetree/bindings/spi/spi-sifive.yaml b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
index 56dcf1d..6e7e394 100644
--- a/Documentation/devicetree/bindings/spi/spi-sifive.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
@@ -17,15 +17,17 @@
properties:
compatible:
items:
- - const: sifive,fu540-c000-spi
+ - enum:
+ - sifive,fu540-c000-spi
+ - sifive,fu740-c000-spi
- const: sifive,spi0
description:
Should be "sifive,<chip>-spi" and "sifive,spi<version>".
Supported compatible strings are -
- "sifive,fu540-c000-spi" for the SiFive SPI v0 as integrated
- onto the SiFive FU540 chip, and "sifive,spi0" for the SiFive
- SPI v0 IP block with no chip integration tweaks.
+ "sifive,fu540-c000-spi" and "sifive,fu740-c000-spi" for the SiFive SPI v0
+ as integrated onto the SiFive FU540 and FU740 chip resp, and "sifive,spi0"
+ for the SiFive SPI v0 IP block with no chip integration tweaks.
Please refer to sifive-blocks-ip-versioning.txt for details
SPI RTL that corresponds to the IP block version numbers can be found here -
diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst
index 0aab2b3..68129ff 100644
--- a/Documentation/devicetree/bindings/submitting-patches.rst
+++ b/Documentation/devicetree/bindings/submitting-patches.rst
@@ -25,7 +25,8 @@
make dt_binding_check
- See ../writing-schema.rst for more details about schema and tools setup.
+ See Documentation/devicetree/writing-schema.rst for more details about
+ schema and tools setup.
3) DT binding files should be dual licensed. The preferred license tag is
(GPL-2.0-only OR BSD-2-Clause).
diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
index 1e249c4..5c7e7bd 100644
--- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
@@ -14,18 +14,19 @@
- "mediatek,mt2712-thermal" : For MT2712 family of SoCs
- "mediatek,mt7622-thermal" : For MT7622 SoC
- "mediatek,mt8183-thermal" : For MT8183 family of SoCs
+ - "mediatek,mt8516-thermal", "mediatek,mt2701-thermal : For MT8516 family of SoCs
- reg: Address range of the thermal controller
- interrupts: IRQ for the thermal controller
- clocks, clock-names: Clocks needed for the thermal controller. required
clocks are:
"therm": Main clock needed for register access
"auxadc": The AUXADC clock
-- resets: Reference to the reset controller controlling the thermal controller.
- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
- #thermal-sensor-cells : Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description.
Optional properties:
+- resets: Reference to the reset controller controlling the thermal controller.
- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
unspecified default values shall be used.
- nvmem-cell-names: Should be "calibration-data"
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
index f386f2a..b33a76e 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
@@ -26,13 +26,16 @@
- renesas,r8a77961-thermal # R-Car M3-W+
- renesas,r8a77965-thermal # R-Car M3-N
- renesas,r8a77980-thermal # R-Car V3H
+ - renesas,r8a779a0-thermal # R-Car V3U
+
reg:
minItems: 2
- maxItems: 3
+ maxItems: 4
items:
- description: TSC1 registers
- description: TSC2 registers
- description: TSC3 registers
+ - description: TSC4 registers
interrupts:
items:
@@ -55,12 +58,22 @@
required:
- compatible
- reg
- - interrupts
- clocks
- power-domains
- resets
- "#thermal-sensor-cells"
+if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r8a779a0-thermal
+then:
+ required:
+ - interrupts
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
index 7e9557a..927de79 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
@@ -62,25 +62,35 @@
"#thermal-sensor-cells":
const: 0
-if:
- properties:
- compatible:
- contains:
- enum:
- - renesas,thermal-r8a73a4 # R-Mobile APE6
- - renesas,thermal-r8a7779 # R-Car H1
-then:
- required:
- - compatible
- - reg
-else:
- required:
- - compatible
- - reg
- - interrupts
- - clocks
- - power-domains
- - resets
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,thermal-r8a73a4 # R-Mobile APE6
+ - renesas,thermal-r8a7779 # R-Car H1
+ then:
+ required:
+ - resets
+ - '#thermal-sensor-cells'
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: renesas,thermal-r8a7779 # R-Car H1
+ then:
+ required:
+ - interrupts
+ - clocks
+ - power-domains
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
deleted file mode 100644
index 29159f4..0000000
--- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Renesas R-Mobile/R-Car Timer Unit (TMU)
-
-The TMU is a 32-bit timer/counter with configurable clock inputs and
-programmable compare match.
-
-Channels share hardware resources but their counter and compare match value
-are independent. The TMU hardware supports up to three channels.
-
-Required Properties:
-
- - compatible: must contain one or more of the following:
- - "renesas,tmu-r8a7740" for the r8a7740 TMU
- - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
- - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
- - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
- - "renesas,tmu-r8a7778" for the r8a7778 TMU
- - "renesas,tmu-r8a7779" for the r8a7779 TMU
- - "renesas,tmu-r8a77970" for the r8a77970 TMU
- - "renesas,tmu-r8a77980" for the r8a77980 TMU
- - "renesas,tmu" for any TMU.
- This is a fallback for the above renesas,tmu-* entries
-
- - reg: base address and length of the registers block for the timer module.
-
- - interrupts: interrupt-specifier for the timer, one per channel.
-
- - clocks: a list of phandle + clock-specifier pairs, one for each entry
- in clock-names.
- - clock-names: must contain "fck" for the functional clock.
-
-Optional Properties:
-
- - #renesas,channels: number of channels implemented by the timer, must be 2
- or 3 (if not specified the value defaults to 3).
-
-
-Example: R8A7779 (R-Car H1) TMU0 node
-
- tmu0: timer@ffd80000 {
- compatible = "renesas,tmu-r8a7779", "renesas,tmu";
- reg = <0xffd80000 0x30>;
- interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
- <0 33 IRQ_TYPE_LEVEL_HIGH>,
- <0 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
- clock-names = "fck";
-
- #renesas,channels = <3>;
- };
diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
new file mode 100644
index 0000000..c541887
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/renesas,tmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Mobile/R-Car Timer Unit (TMU)
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+ - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+description:
+ The TMU is a 32-bit timer/counter with configurable clock inputs and
+ programmable compare match.
+
+ Channels share hardware resources but their counter and compare match value
+ are independent. The TMU hardware supports up to three channels.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,tmu-r8a7740 # R-Mobile A1
+ - renesas,tmu-r8a774a1 # RZ/G2M
+ - renesas,tmu-r8a774b1 # RZ/G2N
+ - renesas,tmu-r8a774c0 # RZ/G2E
+ - renesas,tmu-r8a774e1 # RZ/G2H
+ - renesas,tmu-r8a7778 # R-Car M1A
+ - renesas,tmu-r8a7779 # R-Car H1
+ - renesas,tmu-r8a77970 # R-Car V3M
+ - renesas,tmu-r8a77980 # R-Car V3H
+ - const: renesas,tmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 2
+ maxItems: 3
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: fck
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#renesas,channels':
+ description:
+ Number of channels implemented by the timer.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 2, 3 ]
+ default: 3
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,tmu-r8a7740
+ - renesas,tmu-r8a7778
+ - renesas,tmu-r8a7779
+then:
+ required:
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7779-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a7779-sysc.h>
+ tmu0: timer@ffd80000 {
+ compatible = "renesas,tmu-r8a7779", "renesas,tmu";
+ reg = <0xffd80000 0x30>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7779_PD_ALWAYS_ON>;
+ #renesas,channels = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
index 2fc6173..d65faf2 100644
--- a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
@@ -38,13 +38,6 @@
clock-frequency: true
- clock-freq:
- $ref: "/schemas/types.yaml#/definitions/uint32"
- description: |
- Has the same meaning as the 'clock-frequency' property - timer clock
- frequency in HZ, but is defined only for the backwards compatibility
- with the picoxcell platform.
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index ab623ba..bdc2dc3 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -30,6 +30,12 @@
- ad,ad7414
# ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
- ad,adm9240
+ # Analog Devices ADP5585 Keypad Decoder and I/O Expansion
+ - adi,adp5585
+ # Analog Devices ADP5585 Keypad Decoder and I/O Expansion with support for Row5
+ - adi,adp5585-02
+ # Analog Devices ADP5589 Keypad Decoder and I/O Expansion
+ - adi,adp5589
# +/-1C TDM Extended Temp Range I.C
- adi,adt7461
# +/-1C TDM Extended Temp Range I.C
@@ -44,6 +50,8 @@
- atmel,atsha204a
# i2c h/w elliptic curve crypto module
- atmel,atecc508a
+ # Bosch Sensortec pressure, temperature, humididty and VOC sensor
+ - bosch,bme680
# CM32181: Ambient Light Sensor
- capella,cm32181
# CM3232: Ambient Light Sensor
@@ -60,6 +68,8 @@
- dallas,ds4510
# Digital Thermometer and Thermostat
- dallas,ds75
+ # 1/4 Brick DC/DC Regulated Power Module
+ - delta,q54sj108a2
# Devantech SRF02 ultrasonic ranger in I2C mode
- devantech,srf02
# Devantech SRF08 ultrasonic ranger
@@ -70,6 +80,12 @@
- dlg,da9053
# DA9063: system PMIC for quad-core application processors
- dlg,da9063
+ # DMARD05: 3-axis I2C Accelerometer
+ - domintech,dmard05
+ # DMARD06: 3-axis I2C Accelerometer
+ - domintech,dmard06
+ # DMARD05: 3-axis I2C Accelerometer
+ - domintech,dmard07
# DMARD09: 3-axis Accelerometer
- domintech,dmard09
# DMARD10: 3-axis Accelerometer
@@ -108,20 +124,22 @@
- isil,isl68137
# 5 Bit Programmable, Pulse-Width Modulator
- maxim,ds1050
- # 10-bit 8 channels 300ks/s SPI ADC with temperature sensor
- - maxim,max1027
- # 10-bit 12 channels 300ks/s SPI ADC with temperature sensor
- - maxim,max1029
- # 10-bit 16 channels 300ks/s SPI ADC with temperature sensor
- - maxim,max1031
- # 12-bit 8 channels 300ks/s SPI ADC with temperature sensor
- - maxim,max1227
- # 12-bit 12 channels 300ks/s SPI ADC with temperature sensor
- - maxim,max1229
- # 12-bit 16 channels 300ks/s SPI ADC with temperature sensor
- - maxim,max1231
+ # 10 kOhm digital potentiometer with I2C interface
+ - maxim,ds1803-010
+ # 50 kOhm digital potentiometer with I2C interface
+ - maxim,ds1803-050
+ # 100 kOhm digital potentiometer with I2C interface
+ - maxim,ds1803-100
# Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
- maxim,max1237
+ # 10-bit 10 kOhm linear programable voltage divider
+ - maxim,max5481
+ # 10-bit 50 kOhm linear programable voltage divider
+ - maxim,max5482
+ # 10-bit 10 kOhm linear programable variable resistor
+ - maxim,max5483
+ # 10-bit 50 kOhm linear programable variable resistor
+ - maxim,max5484
# PECI-to-I2C translator for PECI-to-SMBus/I2C protocol conversion
- maxim,max6621
# 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
@@ -130,8 +148,24 @@
- maxim,max31730
# mCube 3-axis 8-bit digital accelerometer
- mcube,mc3230
+ # MEMSIC magnetometer
+ - memsic,mmc35240
# MEMSIC 2-axis 8-bit digital accelerometer
- memsic,mxc6225
+ # Measurement Specialities I2C temperature and humidity sensor
+ - meas,htu21
+ # Measurement Specialities I2C pressure and temperature sensor
+ - meas,ms5637
+ # Measurement Specialities I2C pressure and temperature sensor
+ - meas,ms5805
+ # Measurement Specialities I2C pressure and temperature sensor
+ - meas,ms5837
+ # Measurement Specialities temp and humidity part of ms8607 device
+ - meas,ms8607-humidity
+ # Measurement Specialities temp and pressure part of ms8607 device
+ - meas,ms8607-temppressure
+ # Measurement Specialties temperature sensor
+ - meas,tsys01
# Microchip differential I2C ADC, 1 Channel, 18 bit
- microchip,mcp3421
# Microchip differential I2C ADC, 2 Channel, 18 bit
@@ -172,134 +206,6 @@
- microchip,mcp4019-503
# Microchip 7-bit Single I2C Digital POT (100k)
- microchip,mcp4019-104
- # Microchip 7-bit Single I2C Digital Potentiometer (5k)
- - microchip,mcp4531-502
- # Microchip 7-bit Single I2C Digital Potentiometer (10k)
- - microchip,mcp4531-103
- # Microchip 7-bit Single I2C Digital Potentiometer (50k)
- - microchip,mcp4531-503
- # Microchip 7-bit Single I2C Digital Potentiometer (100k)
- - microchip,mcp4531-104
- # Microchip 7-bit Single I2C Digital Potentiometer (5k)
- - microchip,mcp4532-502
- # Microchip 7-bit Single I2C Digital Potentiometer (10k)
- - microchip,mcp4532-103
- # Microchip 7-bit Single I2C Digital Potentiometer (50k)
- - microchip,mcp4532-503
- # Microchip 7-bit Single I2C Digital Potentiometer (100k)
- - microchip,mcp4532-104
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4541-502
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4541-103
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4541-503
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4541-104
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4542-502
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4542-103
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4542-503
- # Microchip 7-bit Single I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4542-104
- # Microchip 8-bit Single I2C Digital Potentiometer (5k)
- - microchip,mcp4551-502
- # Microchip 8-bit Single I2C Digital Potentiometer (10k)
- - microchip,mcp4551-103
- # Microchip 8-bit Single I2C Digital Potentiometer (50k)
- - microchip,mcp4551-503
- # Microchip 8-bit Single I2C Digital Potentiometer (100k)
- - microchip,mcp4551-104
- # Microchip 8-bit Single I2C Digital Potentiometer (5k)
- - microchip,mcp4552-502
- # Microchip 8-bit Single I2C Digital Potentiometer (10k)
- - microchip,mcp4552-103
- # Microchip 8-bit Single I2C Digital Potentiometer (50k)
- - microchip,mcp4552-503
- # Microchip 8-bit Single I2C Digital Potentiometer (100k)
- - microchip,mcp4552-104
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4561-502
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4561-103
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4561-503
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4561-104
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4562-502
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4562-103
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4562-503
- # Microchip 8-bit Single I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4562-104
- # Microchip 7-bit Dual I2C Digital Potentiometer (5k)
- - microchip,mcp4631-502
- # Microchip 7-bit Dual I2C Digital Potentiometer (10k)
- - microchip,mcp4631-103
- # Microchip 7-bit Dual I2C Digital Potentiometer (50k)
- - microchip,mcp4631-503
- # Microchip 7-bit Dual I2C Digital Potentiometer (100k)
- - microchip,mcp4631-104
- # Microchip 7-bit Dual I2C Digital Potentiometer (5k)
- - microchip,mcp4632-502
- # Microchip 7-bit Dual I2C Digital Potentiometer (10k)
- - microchip,mcp4632-103
- # Microchip 7-bit Dual I2C Digital Potentiometer (50k)
- - microchip,mcp4632-503
- # Microchip 7-bit Dual I2C Digital Potentiometer (100k)
- - microchip,mcp4632-104
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4641-502
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4641-103
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4641-503
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4641-104
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4642-502
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4642-103
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4642-503
- # Microchip 7-bit Dual I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4642-104
- # Microchip 8-bit Dual I2C Digital Potentiometer (5k)
- - microchip,mcp4651-502
- # Microchip 8-bit Dual I2C Digital Potentiometer (10k)
- - microchip,mcp4651-103
- # Microchip 8-bit Dual I2C Digital Potentiometer (50k)
- - microchip,mcp4651-503
- # Microchip 8-bit Dual I2C Digital Potentiometer (100k)
- - microchip,mcp4651-104
- # Microchip 8-bit Dual I2C Digital Potentiometer (5k)
- - microchip,mcp4652-502
- # Microchip 8-bit Dual I2C Digital Potentiometer (10k)
- - microchip,mcp4652-103
- # Microchip 8-bit Dual I2C Digital Potentiometer (50k)
- - microchip,mcp4652-503
- # Microchip 8-bit Dual I2C Digital Potentiometer (100k)
- - microchip,mcp4652-104
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4661-502
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4661-103
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4661-503
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4661-104
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (5k)
- - microchip,mcp4662-502
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (10k)
- - microchip,mcp4662-103
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (50k)
- - microchip,mcp4662-503
- # Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (100k)
- - microchip,mcp4662-104
# PWM Fan Speed Controller With Fan Fault Detection
- microchip,tc654
# PWM Fan Speed Controller With Fan Fault Detection
@@ -336,8 +242,14 @@
- plx,pex8648
# Pulsedlight LIDAR range-finding sensor
- pulsedlight,lidar-lite-v2
+ # Renesas ISL29501 time-of-flight sensor
+ - renesas,isl29501
# S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
- samsung,24ad0xd1
+ # Sensirion low power multi-pixel gas sensor with I2C interface
+ - sensirion,sgpc3
+ # Sensirion multi-pixel gas sensor with I2C interface
+ - sensirion,sgp30
# SGX Sensortech VZ89X Sensors
- sgx,vz89x
# Relative Humidity and Temperature Sensors
@@ -350,12 +262,18 @@
- st,24c256
# Ambient Light Sensor with SMBUS/Two Wire Serial Interface
- taos,tsl2550
- # 8-Channels, 12-bit ADC
- - ti,ads7828
- # 8-Channels, 8-bit ADC
- - ti,ads7830
# Temperature Monitoring and Fan Control
- ti,amc6821
+ # Temperature and humidity sensor with i2c interface
+ - ti,hdc1000
+ # Temperature and humidity sensor with i2c interface
+ - ti,hdc1008
+ # Temperature and humidity sensor with i2c interface
+ - ti,hdc1010
+ # Temperature and humidity sensor with i2c interface
+ - ti,hdc1050
+ # Temperature and humidity sensor with i2c interface
+ - ti,hdc1080
# Temperature sensor with 2-wire interface
- ti,lm73
# Temperature sensor with integrated fan control
diff --git a/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
new file mode 100644
index 0000000..ffa148b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/brcm,usb-pinmap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom USB pin map Controller Device Tree Bindings
+
+maintainers:
+ - Al Cooper <alcooperx@gmail.com>
+
+properties:
+ compatible:
+ items:
+ - const: brcm,usb-pinmap
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: Interrupt for signals mirrored to out-gpios.
+
+ in-gpios:
+ description: Array of one or two GPIO pins used for input signals.
+
+ brcm,in-functions:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: Array of input signal names, one per gpio in in-gpios.
+
+ brcm,in-masks:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Array of enable and mask pairs, one per gpio in-gpios.
+
+ out-gpios:
+ description: Array of one GPIO pin used for output signals.
+
+ brcm,out-functions:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: Array of output signal names, one per gpio in out-gpios.
+
+ brcm,out-masks:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Array of enable, value, changed and clear masks, one
+ per gpio in out-gpios.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+dependencies:
+ in-gpios: [ interrupts ]
+
+examples:
+ - |
+ usb_pinmap: usb-pinmap@22000d0 {
+ compatible = "brcm,usb-pinmap";
+ reg = <0x22000d0 0x4>;
+ in-gpios = <&gpio 18 0>, <&gpio 19 0>;
+ brcm,in-functions = "VBUS", "PWRFLT";
+ brcm,in-masks = <0x8000 0x40000 0x10000 0x80000>;
+ out-gpios = <&gpio 20 0>;
+ brcm,out-functions = "PWRON";
+ brcm,out-masks = <0x20000 0x800000 0x400000 0x200000>;
+ interrupts = <0x0 0xb2 0x4>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
index d6af279..a407e11 100644
--- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
+++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
@@ -26,16 +26,21 @@
- const: dev
interrupts:
+ minItems: 3
items:
- description: OTG/DRD controller interrupt
- description: XHCI host controller interrupt
- description: Device controller interrupt
+ - description: interrupt used to wake up core, e.g when usbcmd.rs is
+ cleared by xhci core, this interrupt is optional
interrupt-names:
+ minItems: 3
items:
- const: host
- const: peripheral
- const: otg
+ - const: wakeup
dr_mode:
enum: [host, otg, peripheral]
diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
deleted file mode 100644
index 2d61166..0000000
--- a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/usb/ingenic,jz4770-phy.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Ingenic SoCs USB PHY devicetree bindings
-
-maintainers:
- - Paul Cercueil <paul@crapouillou.net>
- - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
-
-properties:
- $nodename:
- pattern: '^usb-phy@.*'
-
- compatible:
- enum:
- - ingenic,jz4770-phy
- - ingenic,jz4780-phy
- - ingenic,x1000-phy
- - ingenic,x1830-phy
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- vcc-supply:
- description: VCC power supply
-
- '#phy-cells':
- const: 0
-
-required:
- - compatible
- - reg
- - clocks
- - vcc-supply
- - '#phy-cells'
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/jz4770-cgu.h>
- otg_phy: usb-phy@3c {
- compatible = "ingenic,jz4770-phy";
- reg = <0x3c 0x10>;
-
- vcc-supply = <&vcc>;
- clocks = <&cgu JZ4770_CLK_OTG_PHY>;
-
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
new file mode 100644
index 0000000..93a19ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/maxim,max33359.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Maxim TCPCI Type-C PD controller DT bindings
+
+maintainers:
+ - Badhri Jagan Sridharan <badhri@google.com>
+
+description: Maxim TCPCI Type-C PD controller
+
+properties:
+ compatible:
+ enum:
+ - maxim,max33359
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ connector:
+ type: object
+ $ref: ../connector/usb-connector.yaml#
+ description:
+ Properties for usb c connector.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - connector
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/usb/pd.h>
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ maxtcpc@25 {
+ compatible = "maxim,max33359";
+ reg = <0x25>;
+ interrupt-parent = <&gpa8>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ self-powered;
+ op-sink-microwatt = <2600000>;
+ new-source-frs-typec-current = <FRS_5V_1P5A>;
+ source-pdos = <PDO_FIXED(5000, 900,
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_DATA_SWAP |
+ PDO_FIXED_DUAL_ROLE)>;
+ sink-pdos = <PDO_FIXED(5000, 3000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_DATA_SWAP |
+ PDO_FIXED_DUAL_ROLE)
+ PDO_FIXED(9000, 2000, 0)>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
index 0f078bd..2260325 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
@@ -51,7 +51,6 @@
maxItems: 1
phy-names:
- maxItems: 1
items:
- const: usb
diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
index 737c1f4..54c361d 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
@@ -74,11 +74,8 @@
phys:
maxItems: 1
- items:
- - description: phandle + phy specifier pair.
phy-names:
- maxItems: 1
items:
- const: usb
diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml
new file mode 100644
index 0000000..9a51efa
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/st,stusb160x.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: STMicroelectronics STUSB160x Type-C controller bindings
+
+maintainers:
+ - Amelie Delaunay <amelie.delaunay@st.com>
+
+properties:
+ compatible:
+ enum:
+ - st,stusb1600
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: main power supply (4.1V-22V)
+
+ vsys-supply:
+ description: low power supply (3.0V-5.5V)
+
+ vconn-supply:
+ description: power supply (2.7V-5.5V) used to supply VConn on CC pin in
+ source or dual power role
+
+ connector:
+ type: object
+
+ allOf:
+ - $ref: ../connector/usb-connector.yaml
+
+ properties:
+ compatible:
+ const: usb-c-connector
+
+ power-role: true
+
+ typec-power-opmode: true
+
+ required:
+ - compatible
+
+required:
+ - compatible
+ - reg
+ - connector
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec: stusb1600@28 {
+ compatible = "st,stusb1600";
+ reg = <0x28>;
+ vdd-supply = <&vbus_drd>;
+ vsys-supply = <&vdd_usb>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpioi>;
+
+ typec_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ data-role = "dual";
+ typec-power-opmode = "default";
+
+ port {
+ typec_con_ep: endpoint {
+ remote-endpoint = <&usbotg_hs_ep>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 2735be1..041ae90 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -16,7 +16,7 @@
patternProperties:
# Prefixes which are not vendors, but followed the pattern
# DO NOT ADD NEW PROPERTIES TO THIS LIST
- "^(at25|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio|gpmc|hdmi|i2c-gpio),.*": true
+ "^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*": true
"^(keypad|m25p|max8952|max8997|max8998|mpmc),.*": true
"^(pinctrl-single|#pinctrl-single|PowerPC),.*": true
"^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*": true
@@ -25,10 +25,14 @@
# Keep list in alphabetical order.
"^70mai,.*":
description: 70mai Co., Ltd.
+ "^abb,.*":
+ description: ABB
"^abilis,.*":
description: Abilis Systems
"^abracon,.*":
description: Abracon Corporation
+ "^abt,.*":
+ description: ShenZhen Asia Better Technology Ltd.
"^acer,.*":
description: Acer Inc.
"^acme,.*":
@@ -65,6 +69,8 @@
description: AlphaScale Integrated Circuits Systems, Inc.
"^alps,.*":
description: Alps Electric Co., Ltd.
+ "^alt,.*":
+ description: Altus-Escon-Company BV
"^altr,.*":
description: Altera Corp.
"^amarula,.*":
@@ -79,6 +85,8 @@
description: Shenzhen Amediatech Technology Co., Ltd
"^amlogic,.*":
description: Amlogic, Inc.
+ "^ampere,.*":
+ description: Ampere Computing LLC
"^ampire,.*":
description: Ampire Co., Ltd.
"^ams,.*":
@@ -179,6 +187,8 @@
description: CALAO Systems SAS
"^calxeda,.*":
description: Calxeda
+ "^canaan,.*":
+ description: Canaan, Inc.
"^caninos,.*":
description: Caninos Loucos Program
"^capella,.*":
@@ -315,10 +325,14 @@
description: Einfochips
"^elan,.*":
description: Elan Microelectronic Corp.
+ "^element14,.*":
+ description: Element14 (A Premier Farnell Company)
"^elgin,.*":
description: Elgin S/A.
"^elida,.*":
description: Shenzhen Elida Technology Co., Ltd.
+ "^elimo,.*":
+ description: Elimo Engineering Ltd.
"^embest,.*":
description: Shenzhen Embest Technology Co., Ltd.
"^emlid,.*":
@@ -377,6 +391,8 @@
description: Shenzhen Feixin Photoelectic Co., Ltd
"^feiyang,.*":
description: Shenzhen Fly Young Technology Co.,LTD.
+ "^fii,.*":
+ description: Foxconn Industrial Internet
"^firefly,.*":
description: Firefly
"^focaltech,.*":
@@ -441,6 +457,8 @@
description: HiDeep Inc.
"^himax,.*":
description: Himax Technologies, Inc.
+ "^hirschmann,.*":
+ description: Hirschmann Automation and Control GmbH
"^hisilicon,.*":
description: Hisilicon Limited.
"^hit,.*":
@@ -451,6 +469,8 @@
description: Holt Integrated Circuits, Inc.
"^honeywell,.*":
description: Honeywell
+ "^honestar,.*":
+ description: Honestar Technologies Co., Ltd.
"^hoperun,.*":
description: Jiangsu HopeRun Software Co., Ltd.
"^hp,.*":
@@ -553,6 +573,8 @@
description: Kionix, Inc.
"^kobo,.*":
description: Rakuten Kobo Inc.
+ "^kobol,.*":
+ description: Kobol Innovations Pte. Ltd.
"^koe,.*":
description: Kaohsiung Opto-Electronics Inc.
"^kontron,.*":
@@ -601,6 +623,8 @@
description: Linux-specific binding
"^linx,.*":
description: Linx Technologies
+ "^litex,.*":
+ description: LiteX SoC builder
"^lltc,.*":
description: Linear Technology Corporation
"^logicpd,.*":
@@ -655,6 +679,8 @@
description: MEMSIC Inc.
"^menlo,.*":
description: Menlo Systems GmbH
+ "^mentor,.*":
+ description: Mentor Graphics
"^meraki,.*":
description: Cisco Meraki, LLC
"^merrii,.*":
@@ -669,6 +695,8 @@
description: Micron Technology Inc.
"^microsoft,.*":
description: Microsoft Corporation
+ "^microsys,.*":
+ description: MicroSys Electronics GmbH
"^mikroe,.*":
description: MikroElektronika d.o.o.
"^mikrotik,.*":
@@ -681,6 +709,8 @@
description: MiraMEMS Sensing Technology Co., Ltd.
"^mitsubishi,.*":
description: Mitsubishi Electric Corporation
+ "^modtronix,.*":
+ description: Modtronix Engineering
"^mosaixtech,.*":
description: Mosaix Technologies, Inc.
"^motorola,.*":
@@ -760,6 +790,8 @@
description: NXP Semiconductors
"^oceanic,.*":
description: Oceanic Systems (UK) Ltd.
+ "^oct,.*":
+ description: Octavo Systems LLC
"^okaya,.*":
description: Okaya Electric America, Inc.
"^oki,.*":
@@ -792,6 +824,8 @@
description: Ortus Technology Co., Ltd.
"^osddisplays,.*":
description: OSD Displays
+ "^ouya,.*":
+ description: Ouya Inc.
"^overkiz,.*":
description: Overkiz SAS
"^ovti,.*":
@@ -894,6 +928,8 @@
description: iMX6 Rex Project
"^rervision,.*":
description: Shenzhen Rervision Technology Co., Ltd.
+ "^revotics,.*":
+ description: Revolution Robotics, Inc. (Revotics)
"^richtek,.*":
description: Richtek Technology Corporation
"^ricoh,.*":
@@ -1053,6 +1089,8 @@
description: Trusted Computing Group
"^tcl,.*":
description: Toby Churchill Ltd.
+ "^tdo,.*":
+ description: Shangai Top Display Optoelectronics Co., Ltd
"^technexion,.*":
description: TechNexion
"^technologic,.*":
@@ -1097,7 +1135,7 @@
"^tpo,.*":
description: TPO
"^tq,.*":
- description: TQ Systems GmbH
+ description: TQ-Systems GmbH
"^tronfy,.*":
description: Tronfy
"^tronsmart,.*":
@@ -1140,12 +1178,16 @@
description: Vamrs Ltd.
"^variscite,.*":
description: Variscite Ltd.
+ "^vdl,.*":
+ description: Van der Laan b.v.
"^via,.*":
description: VIA Technologies, Inc.
"^videostrong,.*":
description: Videostrong Technology Co., Ltd.
"^virtio,.*":
description: Virtual I/O Device Specification, developed by the OASIS consortium
+ "^virtual,.*":
+ description: Used for virtual device without specific vendor.
"^vishay,.*":
description: Vishay Intertechnology, Inc
"^vitesse,.*":
@@ -1210,6 +1252,8 @@
description: Shenzhen Xunlong Software CO.,Limited
"^xylon,.*":
description: Xylon
+ "^yes-optoelectronics,.*":
+ description: Yes Optoelectronics Co.,Ltd.
"^ylm,.*":
description: Shenzhen Yangliming Electronic Technology Co., Ltd.
"^yna,.*":
diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
index e8f2263..5ac607d 100644
--- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
@@ -22,6 +22,9 @@
- const: allwinner,sun50i-a64-wdt
- const: allwinner,sun6i-a31-wdt
- items:
+ - const: allwinner,sun50i-a100-wdt
+ - const: allwinner,sun6i-a31-wdt
+ - items:
- const: allwinner,sun50i-h6-wdt
- const: allwinner,sun6i-a31-wdt
- items:
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
index 991b4e3..fb76955 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
@@ -18,10 +18,26 @@
- const: fsl,imx21-wdt
- items:
- enum:
+ - fsl,imx25-wdt
+ - fsl,imx27-wdt
+ - fsl,imx31-wdt
+ - fsl,imx35-wdt
+ - fsl,imx50-wdt
+ - fsl,imx51-wdt
+ - fsl,imx53-wdt
+ - fsl,imx6q-wdt
+ - fsl,imx6sl-wdt
+ - fsl,imx6sll-wdt
+ - fsl,imx6sx-wdt
+ - fsl,imx6ul-wdt
+ - fsl,imx7d-wdt
- fsl,imx8mm-wdt
- fsl,imx8mn-wdt
- fsl,imx8mp-wdt
- fsl,imx8mq-wdt
+ - fsl,ls1012a-wdt
+ - fsl,ls1043a-wdt
+ - fsl,vf610-wdt
- const: fsl,imx21-wdt
reg:
diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index d9fc7bb..f7ee922 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -14,7 +14,15 @@
properties:
compatible:
- const: snps,dw-wdt
+ oneOf:
+ - const: snps,dw-wdt
+ - items:
+ - enum:
+ - rockchip,rk3066-wdt
+ - rockchip,rk3188-wdt
+ - rockchip,rk3288-wdt
+ - rockchip,rk3368-wdt
+ - const: snps,dw-wdt
reg:
maxItems: 1
diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst
index 52a87ab..79aaa55 100644
--- a/Documentation/doc-guide/kernel-doc.rst
+++ b/Documentation/doc-guide/kernel-doc.rst
@@ -247,12 +247,12 @@
struct {
int memb1;
int memb2;
- }
+ };
struct {
void *memb3;
int memb4;
- }
- }
+ };
+ };
union {
struct {
int memb1;
diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst
index 896478b..2fb2ff2 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -375,7 +375,7 @@
SVG image example
-The kernel figure (and image) directive support **DOT** formated files, see
+The kernel figure (and image) directive support **DOT** formatted files, see
* DOT: http://graphviz.org/pdf/dotguide.pdf
* Graphviz: http://www.graphviz.org/content/dot-language
diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst
new file mode 100644
index 0000000..2312506
--- /dev/null
+++ b/Documentation/driver-api/auxiliary_bus.rst
@@ -0,0 +1,234 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+Auxiliary Bus
+=============
+
+In some subsystems, the functionality of the core device (PCI/ACPI/other) is
+too complex for a single device to be managed by a monolithic driver
+(e.g. Sound Open Firmware), multiple devices might implement a common
+intersection of functionality (e.g. NICs + RDMA), or a driver may want to
+export an interface for another subsystem to drive (e.g. SIOV Physical Function
+export Virtual Function management). A split of the functinoality into child-
+devices representing sub-domains of functionality makes it possible to
+compartmentalize, layer, and distribute domain-specific concerns via a Linux
+device-driver model.
+
+An example for this kind of requirement is the audio subsystem where a single
+IP is handling multiple entities such as HDMI, Soundwire, local devices such as
+mics/speakers etc. The split for the core's functionality can be arbitrary or
+be defined by the DSP firmware topology and include hooks for test/debug. This
+allows for the audio core device to be minimal and focused on hardware-specific
+control and communication.
+
+Each auxiliary_device represents a part of its parent functionality. The
+generic behavior can be extended and specialized as needed by encapsulating an
+auxiliary_device within other domain-specific structures and the use of .ops
+callbacks. Devices on the auxiliary bus do not share any structures and the use
+of a communication channel with the parent is domain-specific.
+
+Note that ops are intended as a way to augment instance behavior within a class
+of auxiliary devices, it is not the mechanism for exporting common
+infrastructure from the parent. Consider EXPORT_SYMBOL_NS() to convey
+infrastructure from the parent module to the auxiliary module(s).
+
+
+When Should the Auxiliary Bus Be Used
+=====================================
+
+The auxiliary bus is to be used when a driver and one or more kernel modules,
+who share a common header file with the driver, need a mechanism to connect and
+provide access to a shared object allocated by the auxiliary_device's
+registering driver. The registering driver for the auxiliary_device(s) and the
+kernel module(s) registering auxiliary_drivers can be from the same subsystem,
+or from multiple subsystems.
+
+The emphasis here is on a common generic interface that keeps subsystem
+customization out of the bus infrastructure.
+
+One example is a PCI network device that is RDMA-capable and exports a child
+device to be driven by an auxiliary_driver in the RDMA subsystem. The PCI
+driver allocates and registers an auxiliary_device for each physical
+function on the NIC. The RDMA driver registers an auxiliary_driver that claims
+each of these auxiliary_devices. This conveys data/ops published by the parent
+PCI device/driver to the RDMA auxiliary_driver.
+
+Another use case is for the PCI device to be split out into multiple sub
+functions. For each sub function an auxiliary_device is created. A PCI sub
+function driver binds to such devices that creates its own one or more class
+devices. A PCI sub function auxiliary device is likely to be contained in a
+struct with additional attributes such as user defined sub function number and
+optional attributes such as resources and a link to the parent device. These
+attributes could be used by systemd/udev; and hence should be initialized
+before a driver binds to an auxiliary_device.
+
+A key requirement for utilizing the auxiliary bus is that there is no
+dependency on a physical bus, device, register accesses or regmap support.
+These individual devices split from the core cannot live on the platform bus as
+they are not physical devices that are controlled by DT/ACPI. The same
+argument applies for not using MFD in this scenario as MFD relies on individual
+function devices being physical devices.
+
+Auxiliary Device
+================
+
+An auxiliary_device represents a part of its parent device's functionality. It
+is given a name that, combined with the registering drivers KBUILD_MODNAME,
+creates a match_name that is used for driver binding, and an id that combined
+with the match_name provide a unique name to register with the bus subsystem.
+
+Registering an auxiliary_device is a two-step process. First call
+auxiliary_device_init(), which checks several aspects of the auxiliary_device
+struct and performs a device_initialize(). After this step completes, any
+error state must have a call to auxiliary_device_uninit() in its resolution path.
+The second step in registering an auxiliary_device is to perform a call to
+auxiliary_device_add(), which sets the name of the device and add the device to
+the bus.
+
+Unregistering an auxiliary_device is also a two-step process to mirror the
+register process. First call auxiliary_device_delete(), then call
+auxiliary_device_uninit().
+
+.. code-block:: c
+
+ struct auxiliary_device {
+ struct device dev;
+ const char *name;
+ u32 id;
+ };
+
+If two auxiliary_devices both with a match_name "mod.foo" are registered onto
+the bus, they must have unique id values (e.g. "x" and "y") so that the
+registered devices names are "mod.foo.x" and "mod.foo.y". If match_name + id
+are not unique, then the device_add fails and generates an error message.
+
+The auxiliary_device.dev.type.release or auxiliary_device.dev.release must be
+populated with a non-NULL pointer to successfully register the auxiliary_device.
+
+The auxiliary_device.dev.parent must also be populated.
+
+Auxiliary Device Memory Model and Lifespan
+------------------------------------------
+
+The registering driver is the entity that allocates memory for the
+auxiliary_device and register it on the auxiliary bus. It is important to note
+that, as opposed to the platform bus, the registering driver is wholly
+responsible for the management for the memory used for the driver object.
+
+A parent object, defined in the shared header file, contains the
+auxiliary_device. It also contains a pointer to the shared object(s), which
+also is defined in the shared header. Both the parent object and the shared
+object(s) are allocated by the registering driver. This layout allows the
+auxiliary_driver's registering module to perform a container_of() call to go
+from the pointer to the auxiliary_device, that is passed during the call to the
+auxiliary_driver's probe function, up to the parent object, and then have
+access to the shared object(s).
+
+The memory for the auxiliary_device is freed only in its release() callback
+flow as defined by its registering driver.
+
+The memory for the shared object(s) must have a lifespan equal to, or greater
+than, the lifespan of the memory for the auxiliary_device. The auxiliary_driver
+should only consider that this shared object is valid as long as the
+auxiliary_device is still registered on the auxiliary bus. It is up to the
+registering driver to manage (e.g. free or keep available) the memory for the
+shared object beyond the life of the auxiliary_device.
+
+The registering driver must unregister all auxiliary devices before its own
+driver.remove() is completed.
+
+Auxiliary Drivers
+=================
+
+Auxiliary drivers follow the standard driver model convention, where
+discovery/enumeration is handled by the core, and drivers
+provide probe() and remove() methods. They support power management
+and shutdown notifications using the standard conventions.
+
+.. code-block:: c
+
+ struct auxiliary_driver {
+ int (*probe)(struct auxiliary_device *,
+ const struct auxiliary_device_id *id);
+ void (*remove)(struct auxiliary_device *);
+ void (*shutdown)(struct auxiliary_device *);
+ int (*suspend)(struct auxiliary_device *, pm_message_t);
+ int (*resume)(struct auxiliary_device *);
+ struct device_driver driver;
+ const struct auxiliary_device_id *id_table;
+ };
+
+Auxiliary drivers register themselves with the bus by calling
+auxiliary_driver_register(). The id_table contains the match_names of auxiliary
+devices that a driver can bind with.
+
+Example Usage
+=============
+
+Auxiliary devices are created and registered by a subsystem-level core device
+that needs to break up its functionality into smaller fragments. One way to
+extend the scope of an auxiliary_device is to encapsulate it within a domain-
+pecific structure defined by the parent device. This structure contains the
+auxiliary_device and any associated shared data/callbacks needed to establish
+the connection with the parent.
+
+An example is:
+
+.. code-block:: c
+
+ struct foo {
+ struct auxiliary_device auxdev;
+ void (*connect)(struct auxiliary_device *auxdev);
+ void (*disconnect)(struct auxiliary_device *auxdev);
+ void *data;
+ };
+
+The parent device then registers the auxiliary_device by calling
+auxiliary_device_init(), and then auxiliary_device_add(), with the pointer to
+the auxdev member of the above structure. The parent provides a name for the
+auxiliary_device that, combined with the parent's KBUILD_MODNAME, creates a
+match_name that is be used for matching and binding with a driver.
+
+Whenever an auxiliary_driver is registered, based on the match_name, the
+auxiliary_driver's probe() is invoked for the matching devices. The
+auxiliary_driver can also be encapsulated inside custom drivers that make the
+core device's functionality extensible by adding additional domain-specific ops
+as follows:
+
+.. code-block:: c
+
+ struct my_ops {
+ void (*send)(struct auxiliary_device *auxdev);
+ void (*receive)(struct auxiliary_device *auxdev);
+ };
+
+
+ struct my_driver {
+ struct auxiliary_driver auxiliary_drv;
+ const struct my_ops ops;
+ };
+
+An example of this type of usage is:
+
+.. code-block:: c
+
+ const struct auxiliary_device_id my_auxiliary_id_table[] = {
+ { .name = "foo_mod.foo_dev" },
+ { },
+ };
+
+ const struct my_ops my_custom_ops = {
+ .send = my_tx,
+ .receive = my_rx,
+ };
+
+ const struct my_driver my_drv = {
+ .auxiliary_drv = {
+ .name = "myauxiliarydrv",
+ .id_table = my_auxiliary_id_table,
+ .probe = my_probe,
+ .remove = my_remove,
+ .shutdown = my_shutdown,
+ },
+ .ops = my_custom_ops,
+ };
diff --git a/Documentation/driver-api/connector.rst b/Documentation/driver-api/connector.rst
index 23d06819..631b84a 100644
--- a/Documentation/driver-api/connector.rst
+++ b/Documentation/driver-api/connector.rst
@@ -25,7 +25,7 @@
netlink based networking for inter-process communication in a significantly
easier way::
- int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *));
+ int cn_add_callback(const struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *));
void cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask);
void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask);
diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 4144b66..a2133d6 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -115,6 +115,15 @@
.. kernel-doc:: include/linux/dma-buf.h
:internal:
+Buffer Mapping Helpers
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+ :doc: overview
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+ :internal:
+
Reservation Objects
-------------------
@@ -181,7 +190,7 @@
Indefinite DMA Fences
~~~~~~~~~~~~~~~~~~~~~
-At various times &dma_fence with an indefinite time until dma_fence_wait()
+At various times struct dma_fence with an indefinite time until dma_fence_wait()
finishes have been proposed. Examples include:
* Future fences, used in HWC1 to signal when a buffer isn't used by the display
diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
index 09a3f66..bfd057b 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -120,7 +120,9 @@
.. code-block:: c
- nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len);
+ struct device *dma_dev = dmaengine_get_dma_device(chan);
+
+ nr_sg = dma_map_sg(dma_dev, sgl, sg_len);
if (nr_sg == 0)
/* error */
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index bb67657..cd8b6e6 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -411,6 +411,12 @@
devm_reset_control_get()
devm_reset_controller_register()
+RTC
+ devm_rtc_device_register()
+ devm_rtc_allocate_device()
+ devm_rtc_register_device()
+ devm_rtc_nvmem_register()
+
SERDEV
devm_serdev_device_open()
diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
index 423492d..173e4c7 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -440,18 +440,20 @@
Interacting With the Legacy GPIO Subsystem
==========================================
-Many kernel subsystems still handle GPIOs using the legacy integer-based
-interface. Although it is strongly encouraged to upgrade them to the safer
-descriptor-based API, the following two functions allow you to convert a GPIO
-descriptor into the GPIO integer namespace and vice-versa::
+Many kernel subsystems and drivers still handle GPIOs using the legacy
+integer-based interface. It is strongly recommended to update these to the new
+gpiod interface. For cases where both interfaces need to be used, the following
+two functions allow to convert a GPIO descriptor into the GPIO integer namespace
+and vice-versa::
int desc_to_gpio(const struct gpio_desc *desc)
struct gpio_desc *gpio_to_desc(unsigned gpio)
-The GPIO number returned by desc_to_gpio() can be safely used as long as the
-GPIO descriptor has not been freed. All the same, a GPIO number passed to
-gpio_to_desc() must have been properly acquired, and usage of the returned GPIO
-descriptor is only possible after the GPIO number has been released.
+The GPIO number returned by desc_to_gpio() can safely be used as a parameter of
+the gpio\_*() functions for as long as the GPIO descriptor `desc` is not freed.
+All the same, a GPIO number passed to gpio_to_desc() must first be properly
+acquired using e.g. gpio_request_one(), and the returned GPIO descriptor is only
+considered valid until that GPIO number is released using gpio_free().
Freeing a GPIO obtained by one API with the other API is forbidden and an
unchecked error.
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index 072a745..0fb57e2 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -416,7 +416,8 @@
struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip.
If you do this, the additional irq_chip will be set up by gpiolib at the
same time as setting up the rest of the GPIO functionality. The following
-is a typical example of a cascaded interrupt handler using gpio_irq_chip:
+is a typical example of a chained cascaded interrupt handler using
+the gpio_irq_chip:
.. code-block:: c
@@ -452,7 +453,46 @@
return devm_gpiochip_add_data(dev, &g->gc, g);
-The helper support using hierarchical interrupt controllers as well.
+The helper supports using threaded interrupts as well. Then you just request
+the interrupt separately and go with it:
+
+.. code-block:: c
+
+ /* Typical state container with dynamic irqchip */
+ struct my_gpio {
+ struct gpio_chip gc;
+ struct irq_chip irq;
+ };
+
+ int irq; /* from platform etc */
+ struct my_gpio *g;
+ struct gpio_irq_chip *girq;
+
+ /* Set up the irqchip dynamically */
+ g->irq.name = "my_gpio_irq";
+ g->irq.irq_ack = my_gpio_ack_irq;
+ g->irq.irq_mask = my_gpio_mask_irq;
+ g->irq.irq_unmask = my_gpio_unmask_irq;
+ g->irq.irq_set_type = my_gpio_set_irq_type;
+
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
+ if (ret < 0)
+ return ret;
+
+ /* Get a pointer to the gpio_irq_chip */
+ girq = &g->gc.irq;
+ girq->chip = &g->irq;
+ /* This will let us handle the parent IRQ in the driver */
+ girq->parent_handler = NULL;
+ girq->num_parents = 0;
+ girq->parents = NULL;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_bad_irq;
+
+ return devm_gpiochip_add_data(dev, &g->gc, g);
+
+The helper supports using hierarchical interrupt controllers as well.
In this case the typical set-up will look like this:
.. code-block:: c
@@ -493,32 +533,13 @@
As always it is good to look at examples in the kernel tree for advice
on how to find the required pieces.
-The old way of adding irqchips to gpiochips after registration is also still
-available but we try to move away from this:
-
-- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a
- gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ
- callbacks, so the callbacks need to embed the gpio_chip in its state
- container and obtain a pointer to the container using container_of().
- (See Documentation/driver-api/driver-model/design-patterns.rst)
-
-- gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip,
- as discussed above regarding different types of cascaded irqchips. The
- cascaded irq has to be handled by a threaded interrupt handler.
- Apart from that it works exactly like the chained irqchip.
-
-- gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a
- gpio_chip from a parent IRQ. As the parent IRQ has usually been
- explicitly requested by the driver, this does very little more than
- mark all the child IRQs as having the other IRQ as parent.
-
If there is a need to exclude certain GPIO lines from the IRQ domain handled by
these helpers, we can set .irq.need_valid_mask of the gpiochip before
devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
-from this mask. The mask must be filled in before gpiochip_irqchip_add() or
-gpiochip_irqchip_add_nested() is called.
+from this mask. The mask can be filled in the init_valid_mask() callback
+that is part of the struct gpio_irq_chip.
To use the helpers please keep the following in mind:
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index f357f3e..2456d0a 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -29,6 +29,7 @@
infiniband
frame-buffer
regulator
+ reset
iio/index
input
usb/index
@@ -72,6 +73,7 @@
thermal/index
fpga/index
acpi/index
+ auxiliary_bus
backlight/lp855x-driver.rst
connector
console
diff --git a/Documentation/driver-api/input.rst b/Documentation/driver-api/input.rst
index d05bf58..4bbb26a 100644
--- a/Documentation/driver-api/input.rst
+++ b/Documentation/driver-api/input.rst
@@ -25,15 +25,6 @@
.. kernel-doc:: drivers/input/input-mt.c
:export:
-Polled input devices
---------------------
-
-.. kernel-doc:: include/linux/input-polldev.h
- :internal:
-
-.. kernel-doc:: drivers/input/input-polldev.c
- :export:
-
Matrix keyboards/keypads
------------------------
diff --git a/Documentation/driver-api/io-mapping.rst b/Documentation/driver-api/io-mapping.rst
index a966239..a0cfb15 100644
--- a/Documentation/driver-api/io-mapping.rst
+++ b/Documentation/driver-api/io-mapping.rst
@@ -20,78 +20,72 @@
mappable, while 'size' indicates how large a mapping region to
enable. Both are in bytes.
-This _wc variant provides a mapping which may only be used
-with the io_mapping_map_atomic_wc or io_mapping_map_wc.
+This _wc variant provides a mapping which may only be used with
+io_mapping_map_atomic_wc(), io_mapping_map_local_wc() or
+io_mapping_map_wc().
-With this mapping object, individual pages can be mapped either atomically
-or not, depending on the necessary scheduling environment. Of course, atomic
-maps are more efficient::
+With this mapping object, individual pages can be mapped either temporarily
+or long term, depending on the requirements. Of course, temporary maps are
+more efficient. They come in two flavours::
+
+ void *io_mapping_map_local_wc(struct io_mapping *mapping,
+ unsigned long offset)
void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
unsigned long offset)
-'offset' is the offset within the defined mapping region.
-Accessing addresses beyond the region specified in the
-creation function yields undefined results. Using an offset
-which is not page aligned yields an undefined result. The
-return value points to a single page in CPU address space.
+'offset' is the offset within the defined mapping region. Accessing
+addresses beyond the region specified in the creation function yields
+undefined results. Using an offset which is not page aligned yields an
+undefined result. The return value points to a single page in CPU address
+space.
-This _wc variant returns a write-combining map to the
-page and may only be used with mappings created by
-io_mapping_create_wc
+This _wc variant returns a write-combining map to the page and may only be
+used with mappings created by io_mapping_create_wc()
-Note that the task may not sleep while holding this page
-mapped.
+Temporary mappings are only valid in the context of the caller. The mapping
+is not guaranteed to be globaly visible.
-::
+io_mapping_map_local_wc() has a side effect on X86 32bit as it disables
+migration to make the mapping code work. No caller can rely on this side
+effect.
+io_mapping_map_atomic_wc() has the side effect of disabling preemption and
+pagefaults. Don't use in new code. Use io_mapping_map_local_wc() instead.
+
+Nested mappings need to be undone in reverse order because the mapping
+code uses a stack for keeping track of them::
+
+ addr1 = io_mapping_map_local_wc(map1, offset1);
+ addr2 = io_mapping_map_local_wc(map2, offset2);
+ ...
+ io_mapping_unmap_local(addr2);
+ io_mapping_unmap_local(addr1);
+
+The mappings are released with::
+
+ void io_mapping_unmap_local(void *vaddr)
void io_mapping_unmap_atomic(void *vaddr)
-'vaddr' must be the value returned by the last
-io_mapping_map_atomic_wc call. This unmaps the specified
-page and allows the task to sleep once again.
+'vaddr' must be the value returned by the last io_mapping_map_local_wc() or
+io_mapping_map_atomic_wc() call. This unmaps the specified mapping and
+undoes the side effects of the mapping functions.
-If you need to sleep while holding the lock, you can use the non-atomic
-variant, although they may be significantly slower.
-
-::
+If you need to sleep while holding a mapping, you can use the regular
+variant, although this may be significantly slower::
void *io_mapping_map_wc(struct io_mapping *mapping,
unsigned long offset)
-This works like io_mapping_map_atomic_wc except it allows
-the task to sleep while holding the page mapped.
+This works like io_mapping_map_atomic/local_wc() except it has no side
+effects and the pointer is globaly visible.
-
-::
+The mappings are released with::
void io_mapping_unmap(void *vaddr)
-This works like io_mapping_unmap_atomic, except it is used
-for pages mapped with io_mapping_map_wc.
+Use for pages mapped with io_mapping_map_wc().
At driver close time, the io_mapping object must be freed::
void io_mapping_free(struct io_mapping *mapping)
-
-Current Implementation
-======================
-
-The initial implementation of these functions uses existing mapping
-mechanisms and so provides only an abstraction layer and no new
-functionality.
-
-On 64-bit processors, io_mapping_create_wc calls ioremap_wc for the whole
-range, creating a permanent kernel-visible mapping to the resource. The
-map_atomic and map functions add the requested offset to the base of the
-virtual address returned by ioremap_wc.
-
-On 32-bit processors with HIGHMEM defined, io_mapping_map_atomic_wc uses
-kmap_atomic_pfn to map the specified page in an atomic fashion;
-kmap_atomic_pfn isn't really supposed to be used with device pages, but it
-provides an efficient mapping for this usage.
-
-On 32-bit processors without HIGHMEM defined, io_mapping_map_atomic_wc and
-io_mapping_map_wc both use ioremap_wc, a terribly inefficient function which
-performs an IPI to inform all processors about the new mapping. This results
-in a significant performance penalty.
diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst
index 4d1ae12..ffb0cad 100644
--- a/Documentation/driver-api/media/camera-sensor.rst
+++ b/Documentation/driver-api/media/camera-sensor.rst
@@ -132,3 +132,16 @@
The function returns a non-zero value if it succeeded getting the power count or
runtime PM was disabled, in either of which cases the driver may proceed to
access the device.
+
+Controls
+--------
+
+For camera sensors that are connected to a bus where transmitter and receiver
+require common configuration set by drivers, such as CSI-2 or parallel (BT.601
+or BT.656) bus, the ``V4L2_CID_LINK_FREQ`` control is mandatory on transmitter
+drivers. Receiver drivers can use the ``V4L2_CID_LINK_FREQ`` to query the
+frequency used on the bus.
+
+The transmitter drivers should also implement ``V4L2_CID_PIXEL_RATE`` control in
+order to tell the maximum pixel rate to the receiver. This is required on raw
+camera sensors.
diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst
index bc42982..a26dc87 100644
--- a/Documentation/driver-api/media/cec-core.rst
+++ b/Documentation/driver-api/media/cec-core.rst
@@ -143,7 +143,7 @@
int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
If enabled, then the adapter should be put in a mode to also monitor messages
-that not for us. Not all hardware supports this and this function is only
+that are not for us. Not all hardware supports this and this function is only
called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional
(some hardware may always be in 'monitor all' mode).
@@ -335,7 +335,7 @@
$ cat einj.txt >error-inj
The first callback is called when this file is read and it should show the
-the current error injection state::
+current error injection state::
int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf);
diff --git a/Documentation/driver-api/media/csi2.rst b/Documentation/driver-api/media/csi2.rst
index e1b8380..e3bbc6b 100644
--- a/Documentation/driver-api/media/csi2.rst
+++ b/Documentation/driver-api/media/csi2.rst
@@ -28,10 +28,9 @@
CSI-2 transmitter.
The V4L2_CID_LINK_FREQ control is used to tell the receiver driver the
-frequency (and not the symbol rate) of the link. The
-V4L2_CID_PIXEL_RATE is may be used by the receiver to obtain the pixel
-rate the transmitter uses. The
-:c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an
+frequency (and not the symbol rate) of the link. The V4L2_CID_PIXEL_RATE
+control may be used by the receiver to obtain the pixel rate the transmitter
+uses. The :c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an
ability to start and stop the stream.
The value of the V4L2_CID_PIXEL_RATE is calculated as follows::
diff --git a/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc b/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
new file mode 100644
index 0000000..f2042ac
--- /dev/null
+++ b/Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
@@ -0,0 +1,1041 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
+# Copyright (C) 2019--2020 Intel Corporation
+
+# register rflags
+# - f field LSB MSB rflags
+# - e enum value # after a field
+# - e enum value [LSB MSB]
+# - b bool bit
+# - l arg name min max elsize [discontig...]
+#
+# rflags
+# 8, 16, 32 register bits (default is 8)
+# v1.1 defined in version 1.1
+# f formula
+# float_ireal iReal or IEEE 754; 32 bits
+# ireal unsigned iReal
+
+# general status registers
+module_model_id 0x0000 16
+module_revision_number_major 0x0002 8
+frame_count 0x0005 8
+pixel_order 0x0006 8
+- e GRBG 0
+- e RGGB 1
+- e BGGR 2
+- e GBRG 3
+MIPI_CCS_version 0x0007 8
+- e v1_0 0x10
+- e v1_1 0x11
+- f major 4 7
+- f minor 0 3
+data_pedestal 0x0008 16
+module_manufacturer_id 0x000e 16
+module_revision_number_minor 0x0010 8
+module_date_year 0x0012 8
+module_date_month 0x0013 8
+module_date_day 0x0014 8
+module_date_phase 0x0015 8
+- f 0 2
+- e ts 0
+- e es 1
+- e cs 2
+- e mp 3
+sensor_model_id 0x0016 16
+sensor_revision_number 0x0018 8
+sensor_firmware_version 0x001a 8
+serial_number 0x001c 32
+sensor_manufacturer_id 0x0020 16
+sensor_revision_number_16 0x0022 16
+
+# frame format description registers
+frame_format_model_type 0x0040 8
+- e 2-byte 1
+- e 4-byte 2
+frame_format_model_subtype 0x0041 8
+- f rows 0 3
+- f columns 4 7
+frame_format_descriptor(n) 0x0042 16 f
+- l n 0 14 2
+- f pixels 0 11
+- f pcode 12 15
+- e embedded 1
+- e dummy_pixel 2
+- e black_pixel 3
+- e dark_pixel 4
+- e visible_pixel 5
+- e manuf_specific_0 8
+- e manuf_specific_1 9
+- e manuf_specific_2 10
+- e manuf_specific_3 11
+- e manuf_specific_4 12
+- e manuf_specific_5 13
+- e manuf_specific_6 14
+frame_format_descriptor_4(n) 0x0060 32 f
+- l n 0 7 4
+- f pixels 0 15
+- f pcode 28 31
+- e embedded 1
+- e dummy_pixel 2
+- e black_pixel 3
+- e dark_pixel 4
+- e visible_pixel 5
+- e manuf_specific_0 8
+- e manuf_specific_1 9
+- e manuf_specific_2 10
+- e manuf_specific_3 11
+- e manuf_specific_4 12
+- e manuf_specific_5 13
+- e manuf_specific_6 14
+
+# analog gain description registers
+analog_gain_capability 0x0080 16
+- e global 0
+- e alternate_global 2
+analog_gain_code_min 0x0084 16
+analog_gain_code_max 0x0086 16
+analog_gain_code_step 0x0088 16
+analog_gain_type 0x008a 16
+analog_gain_m0 0x008c 16
+analog_gain_c0 0x008e 16
+analog_gain_m1 0x0090 16
+analog_gain_c1 0x0092 16
+analog_linear_gain_min 0x0094 16 v1.1
+analog_linear_gain_max 0x0096 16 v1.1
+analog_linear_gain_step_size 0x0098 16 v1.1
+analog_exponential_gain_min 0x009a 16 v1.1
+analog_exponential_gain_max 0x009c 16 v1.1
+analog_exponential_gain_step_size 0x009e 16 v1.1
+
+# data format description registers
+data_format_model_type 0x00c0 8
+- e normal 1
+- e extended 2
+data_format_model_subtype 0x00c1 8
+- f rows 0 3
+- f columns 4 7
+data_format_descriptor(n) 0x00c2 16 f
+- l n 0 15 2
+- f compressed 0 7
+- f uncompressed 8 15
+
+# general set-up registers
+mode_select 0x0100 8
+- e software_standby 0
+- e streaming 1
+image_orientation 0x0101 8
+- b horizontal_mirror 0
+- b vertical_flip 1
+software_reset 0x0103 8
+- e off 0
+- e on 1
+grouped_parameter_hold 0x0104 8
+mask_corrupted_frames 0x0105 8
+- e allow 0
+- e mask 1
+fast_standby_ctrl 0x0106 8
+- e complete_frames 0
+- e frame_truncation 1
+CCI_address_ctrl 0x0107 8
+2nd_CCI_if_ctrl 0x0108 8
+- b enable 0
+- b ack 1
+2nd_CCI_address_ctrl 0x0109 8
+CSI_channel_identifier 0x0110 8
+CSI_signaling_mode 0x0111 8
+- e csi_2_dphy 2
+- e csi_2_cphy 3
+CSI_data_format 0x0112 16
+CSI_lane_mode 0x0114 8
+DPCM_Frame_DT 0x011d 8
+Bottom_embedded_data_DT 0x011e 8
+Bottom_embedded_data_VC 0x011f 8
+
+gain_mode 0x0120 8
+- e global 0
+- e alternate 1
+ADC_bit_depth 0x0121 8
+emb_data_ctrl 0x0122 v1.1
+- b raw8_packing_for_raw16 0
+- b raw10_packing_for_raw20 1
+- b raw12_packing_for_raw24 2
+
+GPIO_TRIG_mode 0x0130 8
+extclk_frequency_mhz 0x0136 16 ireal
+temp_sensor_ctrl 0x0138 8
+- b enable 0
+temp_sensor_mode 0x0139 8
+temp_sensor_output 0x013a 8
+
+# integration time registers
+fine_integration_time 0x0200 16
+coarse_integration_time 0x0202 16
+
+# analog gain registers
+analog_gain_code_global 0x0204 16
+analog_linear_gain_global 0x0206 16 v1.1
+analog_exponential_gain_global 0x0208 16 v1.1
+
+# digital gain registers
+digital_gain_global 0x020e 16
+
+# hdr control registers
+Short_analog_gain_global 0x0216 16
+Short_digital_gain_global 0x0218 16
+
+HDR_mode 0x0220 8
+- b enabled 0
+- b separate_analog_gain 1
+- b upscaling 2
+- b reset_sync 3
+- b timing_mode 4
+- b exposure_ctrl_direct 5
+- b separate_digital_gain 6
+HDR_resolution_reduction 0x0221 8
+- f row 0 3
+- f column 4 7
+Exposure_ratio 0x0222 8
+HDR_internal_bit_depth 0x0223 8
+Direct_short_integration_time 0x0224 16
+Short_analog_linear_gain_global 0x0226 16 v1.1
+Short_analog_exponential_gain_global 0x0228 16 v1.1
+
+# clock set-up registers
+vt_pix_clk_div 0x0300 16
+vt_sys_clk_div 0x0302 16
+pre_pll_clk_div 0x0304 16
+#vt_pre_pll_clk_div 0x0304 16
+pll_multiplier 0x0306 16
+#vt_pll_multiplier 0x0306 16
+op_pix_clk_div 0x0308 16
+op_sys_clk_div 0x030a 16
+op_pre_pll_clk_div 0x030c 16
+op_pll_multiplier 0x031e 16
+pll_mode 0x0310 8
+- f 0 0
+- e single 0
+- e dual 1
+op_pix_clk_div_rev 0x0312 16 v1.1
+op_sys_clk_div_rev 0x0314 16 v1.1
+
+# frame timing registers
+frame_length_lines 0x0340 16
+line_length_pck 0x0342 16
+
+# image size registers
+x_addr_start 0x0344 16
+y_addr_start 0x0346 16
+x_addr_end 0x0348 16
+y_addr_end 0x034a 16
+x_output_size 0x034c 16
+y_output_size 0x034e 16
+
+# timing mode registers
+Frame_length_ctrl 0x0350 8
+- b automatic 0
+Timing_mode_ctrl 0x0352 8
+- b manual_readout 0
+- b delayed_exposure 1
+Start_readout_rs 0x0353 8
+- b manual_readout_start 0
+Frame_margin 0x0354 16
+
+# sub-sampling registers
+x_even_inc 0x0380 16
+x_odd_inc 0x0382 16
+y_even_inc 0x0384 16
+y_odd_inc 0x0386 16
+
+# monochrome readout registers
+monochrome_en 0x0390 v1.1
+- e enabled 0
+
+# image scaling registers
+Scaling_mode 0x0400 16
+- e no_scaling 0
+- e horizontal 1
+scale_m 0x0404 16
+scale_n 0x0406 16
+digital_crop_x_offset 0x0408 16
+digital_crop_y_offset 0x040a 16
+digital_crop_image_width 0x040c 16
+digital_crop_image_height 0x040e 16
+
+# image compression registers
+compression_mode 0x0500 16
+- e none 0
+- e dpcm_pcm_simple 1
+
+# test pattern registers
+test_pattern_mode 0x0600 16
+- e none 0
+- e solid_color 1
+- e color_bars 2
+- e fade_to_grey 3
+- e pn9 4
+- e color_tile 5
+test_data_red 0x0602 16
+test_data_greenR 0x0604 16
+test_data_blue 0x0606 16
+test_data_greenB 0x0608 16
+value_step_size_smooth 0x060a 8
+value_step_size_quantised 0x060b 8
+
+# phy configuration registers
+tclk_post 0x0800 8
+ths_prepare 0x0801 8
+ths_zero_min 0x0802 8
+ths_trail 0x0803 8
+tclk_trail_min 0x0804 8
+tclk_prepare 0x0805 8
+tclk_zero 0x0806 8
+tlpx 0x0807 8
+phy_ctrl 0x0808 8
+- e auto 0
+- e UI 1
+- e manual 2
+tclk_post_ex 0x080a 16
+ths_prepare_ex 0x080c 16
+ths_zero_min_ex 0x080e 16
+ths_trail_ex 0x0810 16
+tclk_trail_min_ex 0x0812 16
+tclk_prepare_ex 0x0814 16
+tclk_zero_ex 0x0816 16
+tlpx_ex 0x0818 16
+
+# link rate register
+requested_link_rate 0x0820 32 u16.16
+
+# equalization control registers
+DPHY_equalization_mode 0x0824 8 v1.1
+- b eq2 0
+PHY_equalization_ctrl 0x0825 8 v1.1
+- b enable 0
+
+# d-phy preamble control registers
+DPHY_preamble_ctrl 0x0826 8 v1.1
+- b enable 0
+DPHY_preamble_length 0x0826 8 v1.1
+
+# d-phy spread spectrum control registers
+PHY_SSC_ctrl 0x0828 8 v1.1
+- b enable 0
+
+# manual lp control register
+manual_LP_ctrl 0x0829 8 v1.1
+- b enable 0
+
+# additional phy configuration registers
+twakeup 0x082a v1.1
+tinit 0x082b v1.1
+ths_exit 0x082c v1.1
+ths_exit_ex 0x082e 16 v1.1
+
+# phy calibration configuration registers
+PHY_periodic_calibration_ctrl 0x0830 8
+- b frame_blanking 0
+PHY_periodic_calibration_interval 0x0831 8
+PHY_init_calibration_ctrl 0x0832 8
+- b stream_start 0
+DPHY_calibration_mode 0x0833 8 v1.1
+- b also_alternate 0
+CPHY_calibration_mode 0x0834 8 v1.1
+- e format_1 0
+- e format_2 1
+- e format_3 2
+t3_calpreamble_length 0x0835 8 v1.1
+t3_calpreamble_length_per 0x0836 8 v1.1
+t3_calaltseq_length 0x0837 8 v1.1
+t3_calaltseq_length_per 0x0838 8 v1.1
+FM2_init_seed 0x083a 16 v1.1
+t3_caludefseq_length 0x083c 16 v1.1
+t3_caludefseq_length_per 0x083e 16 v1.1
+
+# c-phy manual control registers
+TGR_Preamble_Length 0x0841 8
+- b preamable_prog_seq 7
+- f begin_preamble_length 0 5
+TGR_Post_Length 0x0842 8
+- f post_length 0 4
+TGR_Preamble_Prog_Sequence(n2) 0x0843
+- l n2 0 6 1
+- f symbol_n_1 3 5
+- f symbol_n 0 2
+t3_prepare 0x084e 16
+t3_lpx 0x0850 16
+
+# alps control register
+ALPS_ctrl 0x085a 8
+- b lvlp_dphy 0
+- b lvlp_cphy 1
+- b alp_cphy 2
+
+# lrte control registers
+TX_REG_CSI_EPD_EN_SSP_cphy 0x0860 16
+TX_REG_CSI_EPD_OP_SLP_cphy 0x0862 16
+TX_REG_CSI_EPD_EN_SSP_dphy 0x0864 16
+TX_REG_CSI_EPD_OP_SLP_dphy 0x0866 16
+TX_REG_CSI_EPD_MISC_OPTION_cphy 0x0868 v1.1
+TX_REG_CSI_EPD_MISC_OPTION_dphy 0x0869 v1.1
+
+# scrambling control registers
+Scrambling_ctrl 0x0870
+- b enabled 0
+- f 2 3
+- e 1_seed_cphy 0
+- e 4_seed_cphy 3
+lane_seed_value(seed, lane) 0x0872 16
+- l seed 0 3 0x10
+- l lane 0 7 0x2
+
+# usl control registers
+TX_USL_REV_ENTRY 0x08c0 16 v1.1
+TX_USL_REV_Clock_Counter 0x08c2 16 v1.1
+TX_USL_REV_LP_Counter 0x08c4 16 v1.1
+TX_USL_REV_Frame_Counter 0x08c6 16 v1.1
+TX_USL_REV_Chronological_Timer 0x08c8 16 v1.1
+TX_USL_FWD_ENTRY 0x08ca 16 v1.1
+TX_USL_GPIO 0x08cc 16 v1.1
+TX_USL_Operation 0x08ce 16 v1.1
+- b reset 0
+TX_USL_ALP_ctrl 0x08d0 16 v1.1
+- b clock_pause 0
+TX_USL_APP_BTA_ACK_TIMEOUT 0x08d2 16 v1.1
+TX_USL_SNS_BTA_ACK_TIMEOUT 0x08d2 16 v1.1
+USL_Clock_Mode_d_ctrl 0x08d2 v1.1
+- b cont_clock_standby 0
+- b cont_clock_vblank 1
+- b cont_clock_hblank 2
+
+# binning configuration registers
+binning_mode 0x0900 8
+binning_type 0x0901 8
+binning_weighting 0x0902 8
+
+# data transfer interface registers
+data_transfer_if_1_ctrl 0x0a00 8
+- b enable 0
+- b write 1
+- b clear_error 2
+data_transfer_if_1_status 0x0a01 8
+- b read_if_ready 0
+- b write_if_ready 1
+- b data_corrupted 2
+- b improper_if_usage 3
+data_transfer_if_1_page_select 0x0a02 8
+data_transfer_if_1_data(p) 0x0a04 8 f
+- l p 0 63 1
+
+# image processing and sensor correction configuration registers
+shading_correction_en 0x0b00 8
+- b enable 0
+luminance_correction_level 0x0b01 8
+green_imbalance_filter_en 0x0b02 8
+- b enable 0
+mapped_defect_correct_en 0x0b05 8
+- b enable 0
+single_defect_correct_en 0x0b06 8
+- b enable 0
+dynamic_couplet_correct_en 0x0b08 8
+- b enable 0
+combined_defect_correct_en 0x0b0a 8
+- b enable 0
+module_specific_correction_en 0x0b0c 8
+- b enable 0
+dynamic_triplet_defect_correct_en 0x0b13 8
+- b enable 0
+NF_ctrl 0x0b15 8
+- b luma 0
+- b chroma 1
+- b combined 2
+
+# optical black pixel readout registers
+OB_readout_control 0x0b30 8
+- b enable 0
+- b interleaving 1
+OB_virtual_channel 0x0b31 8
+OB_DT 0x0b32 8
+OB_data_format 0x0b33 8
+
+# color temperature feedback registers
+color_temperature 0x0b8c 16
+absolute_gain_greenr 0x0b8e 16
+absolute_gain_red 0x0b90 16
+absolute_gain_blue 0x0b92 16
+absolute_gain_greenb 0x0b94 16
+
+# cfa conversion registers
+CFA_conversion_ctrl 0x0ba0 v1.1
+- b bayer_conversion_enable 0
+
+# flash strobe and sa strobe control registers
+flash_strobe_adjustment 0x0c12 8
+flash_strobe_start_point 0x0c14 16
+tflash_strobe_delay_rs_ctrl 0x0c16 16
+tflash_strobe_width_high_rs_ctrl 0x0c18 16
+flash_mode_rs 0x0c1a 8
+- b continuous 0
+- b truncate 1
+- b async 3
+flash_trigger_rs 0x0c1b 8
+flash_status 0x0c1c 8
+- b retimed 0
+sa_strobe_mode 0x0c1d 8
+- b continuous 0
+- b truncate 1
+- b async 3
+- b adjust_edge 4
+sa_strobe_start_point 0x0c1e 16
+tsa_strobe_delay_ctrl 0x0c20 16
+tsa_strobe_width_ctrl 0x0c22 16
+sa_strobe_trigger 0x0c24 8
+sa_strobe_status 0x0c25 8
+- b retimed 0
+tSA_strobe_re_delay_ctrl 0x0c30 16
+tSA_strobe_fe_delay_ctrl 0x0c32 16
+
+# pdaf control registers
+PDAF_ctrl 0x0d00 16
+- b enable 0
+- b processed 1
+- b interleaved 2
+- b visible_pdaf_correction 3
+PDAF_VC 0x0d02 8
+PDAF_DT 0x0d03 8
+pd_x_addr_start 0x0d04 16
+pd_y_addr_start 0x0d06 16
+pd_x_addr_end 0x0d08 16
+pd_y_addr_end 0x0d0a 16
+
+# bracketing interface configuration registers
+bracketing_LUT_ctrl 0x0e00 8
+bracketing_LUT_mode 0x0e01 8
+- b continue_streaming 0
+- b loop_mode 1
+bracketing_LUT_entry_ctrl 0x0e02 8
+bracketing_LUT_frame(n) 0x0e10 v1.1 f
+- l n 0 0xef 1
+
+# integration time and gain parameter limit registers
+integration_time_capability 0x1000 16
+- b fine 0
+coarse_integration_time_min 0x1004 16
+coarse_integration_time_max_margin 0x1006 16
+fine_integration_time_min 0x1008 16
+fine_integration_time_max_margin 0x100a 16
+
+# digital gain parameter limit registers
+digital_gain_capability 0x1081
+- e none 0
+- e global 2
+digital_gain_min 0x1084 16
+digital_gain_max 0x1086 16
+digital_gain_step_size 0x1088 16
+
+# data pedestal capability registers
+Pedestal_capability 0x10e0 8 v1.1
+
+# adc capability registers
+ADC_capability 0x10f0 8
+- b bit_depth_ctrl 0
+ADC_bit_depth_capability 0x10f4 32 v1.1
+
+# video timing parameter limit registers
+min_ext_clk_freq_mhz 0x1100 32 float_ireal
+max_ext_clk_freq_mhz 0x1104 32 float_ireal
+min_pre_pll_clk_div 0x1108 16
+# min_vt_pre_pll_clk_div 0x1108 16
+max_pre_pll_clk_div 0x110a 16
+# max_vt_pre_pll_clk_div 0x110a 16
+min_pll_ip_clk_freq_mhz 0x110c 32 float_ireal
+# min_vt_pll_ip_clk_freq_mhz 0x110c 32 float_ireal
+max_pll_ip_clk_freq_mhz 0x1110 32 float_ireal
+# max_vt_pll_ip_clk_freq_mhz 0x1110 32 float_ireal
+min_pll_multiplier 0x1114 16
+# min_vt_pll_multiplier 0x1114 16
+max_pll_multiplier 0x1116 16
+# max_vt_pll_multiplier 0x1116 16
+min_pll_op_clk_freq_mhz 0x1118 32 float_ireal
+max_pll_op_clk_freq_mhz 0x111c 32 float_ireal
+
+# video timing set-up capability registers
+min_vt_sys_clk_div 0x1120 16
+max_vt_sys_clk_div 0x1122 16
+min_vt_sys_clk_freq_mhz 0x1124 32 float_ireal
+max_vt_sys_clk_freq_mhz 0x1128 32 float_ireal
+min_vt_pix_clk_freq_mhz 0x112c 32 float_ireal
+max_vt_pix_clk_freq_mhz 0x1130 32 float_ireal
+min_vt_pix_clk_div 0x1134 16
+max_vt_pix_clk_div 0x1136 16
+clock_calculation 0x1138
+- b lane_speed 0
+- b link_decoupled 1
+- b dual_pll_op_sys_ddr 2
+- b dual_pll_op_pix_ddr 3
+num_of_vt_lanes 0x1139
+num_of_op_lanes 0x113a
+op_bits_per_lane 0x113b 8 v1.1
+
+# frame timing parameter limits
+min_frame_length_lines 0x1140 16
+max_frame_length_lines 0x1142 16
+min_line_length_pck 0x1144 16
+max_line_length_pck 0x1146 16
+min_line_blanking_pck 0x1148 16
+min_frame_blanking_lines 0x114a 16
+min_line_length_pck_step_size 0x114c
+timing_mode_capability 0x114d
+- b auto_frame_length 0
+- b rolling_shutter_manual_readout 2
+- b delayed_exposure_start 3
+- b manual_exposure_embedded_data 4
+frame_margin_max_value 0x114e 16
+frame_margin_min_value 0x1150
+gain_delay_type 0x1151
+- e fixed 0
+- e variable 1
+
+# output clock set-up capability registers
+min_op_sys_clk_div 0x1160 16
+max_op_sys_clk_div 0x1162 16
+min_op_sys_clk_freq_mhz 0x1164 32 float_ireal
+max_op_sys_clk_freq_mhz 0x1168 32 float_ireal
+min_op_pix_clk_div 0x116c 16
+max_op_pix_clk_div 0x116e 16
+min_op_pix_clk_freq_mhz 0x1170 32 float_ireal
+max_op_pix_clk_freq_mhz 0x1174 32 float_ireal
+
+# image size parameter limit registers
+x_addr_min 0x1180 16
+y_addr_min 0x1182 16
+x_addr_max 0x1184 16
+y_addr_max 0x1186 16
+min_x_output_size 0x1188 16
+min_y_output_size 0x118a 16
+max_x_output_size 0x118c 16
+max_y_output_size 0x118e 16
+
+x_addr_start_div_constant 0x1190 v1.1
+y_addr_start_div_constant 0x1191 v1.1
+x_addr_end_div_constant 0x1192 v1.1
+y_addr_end_div_constant 0x1193 v1.1
+x_size_div 0x1194 v1.1
+y_size_div 0x1195 v1.1
+x_output_div 0x1196 v1.1
+y_output_div 0x1197 v1.1
+non_flexible_resolution_support 0x1198 v1.1
+- b new_pix_addr 0
+- b new_output_res 1
+- b output_crop_no_pad 2
+- b output_size_lane_dep 3
+
+min_op_pre_pll_clk_div 0x11a0 16
+max_op_pre_pll_clk_div 0x11a2 16
+min_op_pll_ip_clk_freq_mhz 0x11a4 32 float_ireal
+max_op_pll_ip_clk_freq_mhz 0x11a8 32 float_ireal
+min_op_pll_multiplier 0x11ac 16
+max_op_pll_multiplier 0x11ae 16
+min_op_pll_op_clk_freq_mhz 0x11b0 32 float_ireal
+max_op_pll_op_clk_freq_mhz 0x11b4 32 float_ireal
+clock_tree_pll_capability 0x11b8 8
+- b dual_pll 0
+- b single_pll 1
+- b ext_divider 2
+- b flexible_op_pix_clk_div 3
+clock_capa_type_capability 0x11b9 v1.1
+- b ireal 0
+
+# sub-sampling parameters limit registers
+min_even_inc 0x11c0 16
+min_odd_inc 0x11c2 16
+max_even_inc 0x11c4 16
+max_odd_inc 0x11c6 16
+aux_subsamp_capability 0x11c8 v1.1
+- b factor_power_of_2 1
+aux_subsamp_mono_capability 0x11c9 v1.1
+- b factor_power_of_2 1
+monochrome_capability 0x11ca v1.1
+- e inc_odd 0
+- e inc_even 1
+pixel_readout_capability 0x11cb v1.1
+- e bayer 0
+- e monochrome 1
+- e bayer_and_mono 2
+min_even_inc_mono 0x11cc 16 v1.1
+max_even_inc_mono 0x11ce 16 v1.1
+min_odd_inc_mono 0x11d0 16 v1.1
+max_odd_inc_mono 0x11d2 16 v1.1
+min_even_inc_bc2 0x11d4 16 v1.1
+max_even_inc_bc2 0x11d6 16 v1.1
+min_odd_inc_bc2 0x11d8 16 v1.1
+max_odd_inc_bc2 0x11da 16 v1.1
+min_even_inc_mono_bc2 0x11dc 16 v1.1
+max_even_inc_mono_bc2 0x11de 16 v1.1
+min_odd_inc_mono_bc2 0x11f0 16 v1.1
+max_odd_inc_mono_bc2 0x11f2 16 v1.1
+
+# image scaling limit parameters
+scaling_capability 0x1200 16
+- e none 0
+- e horizontal 1
+- e reserved 2
+scaler_m_min 0x1204 16
+scaler_m_max 0x1206 16
+scaler_n_min 0x1208 16
+scaler_n_max 0x120a 16
+digital_crop_capability 0x120e
+- e none 0
+- e input_crop 1
+
+# hdr limit registers
+hdr_capability_1 0x1210
+- b 2x2_binning 0
+- b combined_analog_gain 1
+- b separate_analog_gain 2
+- b upscaling 3
+- b reset_sync 4
+- b direct_short_exp_timing 5
+- b direct_short_exp_synthesis 6
+min_hdr_bit_depth 0x1211
+hdr_resolution_sub_types 0x1212
+hdr_resolution_sub_type(n) 0x1213
+- l n 0 1 1
+- f row 0 3
+- f column 4 7
+hdr_capability_2 0x121b
+- b combined_digital_gain 0
+- b separate_digital_gain 1
+- b timing_mode 3
+- b synthesis_mode 4
+max_hdr_bit_depth 0x121c
+
+# usl capability register
+usl_support_capability 0x1230 v1.1
+- b clock_tree 0
+- b rev_clock_tree 1
+- b rev_clock_calc 2
+usl_clock_mode_d_capability 0x1231 v1.1
+- b cont_clock_standby 0
+- b cont_clock_vblank 1
+- b cont_clock_hblank 2
+- b noncont_clock_standby 3
+- b noncont_clock_vblank 4
+- b noncont_clock_hblank 5
+min_op_sys_clk_div_rev 0x1234 v1.1
+max_op_sys_clk_div_rev 0x1236 v1.1
+min_op_pix_clk_div_rev 0x1238 v1.1
+max_op_pix_clk_div_rev 0x123a v1.1
+min_op_sys_clk_freq_rev_mhz 0x123c 32 v1.1 float_ireal
+max_op_sys_clk_freq_rev_mhz 0x1240 32 v1.1 float_ireal
+min_op_pix_clk_freq_rev_mhz 0x1244 32 v1.1 float_ireal
+max_op_pix_clk_freq_rev_mhz 0x1248 32 v1.1 float_ireal
+max_bitrate_rev_d_mode_mbps 0x124c 32 v1.1 ireal
+max_symrate_rev_c_mode_msps 0x1250 32 v1.1 ireal
+
+# image compression capability registers
+compression_capability 0x1300
+- b dpcm_pcm_simple 0
+
+# test mode capability registers
+test_mode_capability 0x1310 16
+- b solid_color 0
+- b color_bars 1
+- b fade_to_grey 2
+- b pn9 3
+- b color_tile 5
+pn9_data_format1 0x1312
+pn9_data_format2 0x1313
+pn9_data_format3 0x1314
+pn9_data_format4 0x1315
+pn9_misc_capability 0x1316
+- f num_pixels 0 2
+- b compression 3
+test_pattern_capability 0x1317 v1.1
+- b no_repeat 1
+pattern_size_div_m1 0x1318 v1.1
+
+# fifo capability registers
+fifo_support_capability 0x1502
+- e none 0
+- e derating 1
+- e derating_overrating 2
+
+# csi-2 capability registers
+phy_ctrl_capability 0x1600
+- b auto_phy_ctl 0
+- b ui_phy_ctl 1
+- b dphy_time_ui_reg_1_ctl 2
+- b dphy_time_ui_reg_2_ctl 3
+- b dphy_time_ctl 4
+- b dphy_ext_time_ui_reg_1_ctl 5
+- b dphy_ext_time_ui_reg_2_ctl 6
+- b dphy_ext_time_ctl 7
+csi_dphy_lane_mode_capability 0x1601
+- b 1_lane 0
+- b 2_lane 1
+- b 3_lane 2
+- b 4_lane 3
+- b 5_lane 4
+- b 6_lane 5
+- b 7_lane 6
+- b 8_lane 7
+csi_signaling_mode_capability 0x1602
+- b csi_dphy 2
+- b csi_cphy 3
+fast_standby_capability 0x1603
+- e no_frame_truncation 0
+- e frame_truncation 1
+csi_address_control_capability 0x1604
+- b cci_addr_change 0
+- b 2nd_cci_addr 1
+- b sw_changeable_2nd_cci_addr 2
+data_type_capability 0x1605
+- b dpcm_programmable 0
+- b bottom_embedded_dt_programmable 1
+- b bottom_embedded_vc_programmable 2
+- b ext_vc_range 3
+csi_cphy_lane_mode_capability 0x1606
+- b 1_lane 0
+- b 2_lane 1
+- b 3_lane 2
+- b 4_lane 3
+- b 5_lane 4
+- b 6_lane 5
+- b 7_lane 6
+- b 8_lane 7
+emb_data_capability 0x1607 v1.1
+- b two_bytes_per_raw16 0
+- b two_bytes_per_raw20 1
+- b two_bytes_per_raw24 2
+- b no_one_byte_per_raw16 3
+- b no_one_byte_per_raw20 4
+- b no_one_byte_per_raw24 5
+max_per_lane_bitrate_lane_d_mode_mbps(n) 0x1608 32 ireal
+- l n 0 7 4 4,0x32
+temp_sensor_capability 0x1618
+- b supported 0
+- b CCS_format 1
+- b reset_0x80 2
+max_per_lane_bitrate_lane_c_mode_mbps(n) 0x161a 32 ireal
+- l n 0 7 4 4,0x30
+dphy_equalization_capability 0x162b
+- b equalization_ctrl 0
+- b eq1 1
+- b eq2 2
+cphy_equalization_capability 0x162c
+- b equalization_ctrl 0
+dphy_preamble_capability 0x162d
+- b preamble_seq_ctrl 0
+dphy_ssc_capability 0x162e
+- b supported 0
+cphy_calibration_capability 0x162f
+- b manual 0
+- b manual_streaming 1
+- b format_1_ctrl 2
+- b format_2_ctrl 3
+- b format_3_ctrl 4
+dphy_calibration_capability 0x1630
+- b manual 0
+- b manual_streaming 1
+- b alternate_seq 2
+phy_ctrl_capability_2 0x1631
+- b tgr_length 0
+- b tgr_preamble_prog_seq 1
+- b extra_cphy_manual_timing 2
+- b clock_based_manual_cdphy 3
+- b clock_based_manual_dphy 4
+- b clock_based_manual_cphy 5
+- b manual_lp_dphy 6
+- b manual_lp_cphy 7
+lrte_cphy_capability 0x1632
+- b pdq_short 0
+- b spacer_short 1
+- b pdq_long 2
+- b spacer_long 3
+- b spacer_no_pdq 4
+lrte_dphy_capability 0x1633
+- b pdq_short_opt1 0
+- b spacer_short_opt1 1
+- b pdq_long_opt1 2
+- b spacer_long_opt1 3
+- b spacer_short_opt2 4
+- b spacer_long_opt2 5
+- b spacer_no_pdq_opt1 6
+- b spacer_variable_opt2 7
+alps_capability_dphy 0x1634
+- e lvlp_not_supported 0 0x3
+- e lvlp_supported 1 0x3
+- e controllable_lvlp 2 0x3
+alps_capability_cphy 0x1635
+- e lvlp_not_supported 0 0x3
+- e lvlp_supported 1 0x3
+- e controllable_lvlp 2 0x3
+- e alp_not_supported 0xc 0xc
+- e alp_supported 0xd 0xc
+- e controllable_alp 0xe 0xc
+scrambling_capability 0x1636
+- b scrambling_supported 0
+- f max_seeds_per_lane_c 1 2
+- e 1 0
+- e 4 3
+- f num_seed_regs 3 5
+- e 0 0
+- e 1 1
+- e 4 4
+- b num_seed_per_lane 6
+dphy_manual_constant 0x1637
+cphy_manual_constant 0x1638
+CSI2_interface_capability_misc 0x1639 v1.1
+- b eotp_short_pkt_opt2 0
+PHY_ctrl_capability_3 0x165c v1.1
+- b dphy_timing_not_multiple 0
+- b dphy_min_timing_value_1 1
+- b twakeup_supported 2
+- b tinit_supported 3
+- b ths_exit_supported 4
+- b cphy_timing_not_multiple 5
+- b cphy_min_timing_value_1 6
+dphy_sf 0x165d v1.1
+cphy_sf 0x165e v1.1
+- f twakeup 0 3
+- f tinit 4 7
+dphy_limits_1 0x165f v1.1
+- f ths_prepare 0 3
+- f ths_zero 4 7
+dphy_limits_2 0x1660 v1.1
+- f ths_trail 0 3
+- f tclk_trail_min 4 7
+dphy_limits_3 0x1661 v1.1
+- f tclk_prepare 0 3
+- f tclk_zero 4 7
+dphy_limits_4 0x1662 v1.1
+- f tclk_post 0 3
+- f tlpx 4 7
+dphy_limits_5 0x1663 v1.1
+- f ths_exit 0 3
+- f twakeup 4 7
+dphy_limits_6 0x1664 v1.1
+- f tinit 0 3
+cphy_limits_1 0x1665 v1.1
+- f t3_prepare_max 0 3
+- f t3_lpx_max 4 7
+cphy_limits_2 0x1666 v1.1
+- f ths_exit_max 0 3
+- f twakeup_max 4 7
+cphy_limits_3 0x1667 v1.1
+- f tinit_max 0 3
+
+# binning capability registers
+min_frame_length_lines_bin 0x1700 16
+max_frame_length_lines_bin 0x1702 16
+min_line_length_pck_bin 0x1704 16
+max_line_length_pck_bin 0x1706 16
+min_line_blanking_pck_bin 0x1708 16
+fine_integration_time_min_bin 0x170a 16
+fine_integration_time_max_margin_bin 0x170c 16
+binning_capability 0x1710
+- e unsupported 0
+- e binning_then_subsampling 1
+- e subsampling_then_binning 2
+binning_weighting_capability 0x1711
+- b averaged 0
+- b summed 1
+- b bayer_corrected 2
+- b module_specific_weight 3
+binning_sub_types 0x1712
+binning_sub_type(n) 0x1713
+- l n 0 63 1
+- f row 0 3
+- f column 4 7
+binning_weighting_mono_capability 0x1771 v1.1
+- b averaged 0
+- b summed 1
+- b bayer_corrected 2
+- b module_specific_weight 3
+binning_sub_types_mono 0x1772 v1.1
+binning_sub_type_mono(n) 0x1773 v1.1 f
+- l n 0 63 1
+
+# data transfer interface capability registers
+data_transfer_if_capability 0x1800
+- b supported 0
+- b polling 2
+
+# sensor correction capability registers
+shading_correction_capability 0x1900
+- b color_shading 0
+- b luminance_correction 1
+green_imbalance_capability 0x1901
+- b supported 0
+module_specific_correction_capability 0x1903
+defect_correction_capability 0x1904 16
+- b mapped_defect 0
+- b dynamic_couplet 2
+- b dynamic_single 5
+- b combined_dynamic 8
+defect_correction_capability_2 0x1906 16
+- b dynamic_triplet 3
+nf_capability 0x1908
+- b luma 0
+- b chroma 1
+- b combined 2
+
+# optical black readout capability registers
+ob_readout_capability 0x1980
+- b controllable_readout 0
+- b visible_pixel_readout 1
+- b different_vc_readout 2
+- b different_dt_readout 3
+- b prog_data_format 4
+
+# color feedback capability registers
+color_feedback_capability 0x1987
+- b kelvin 0
+- b awb_gain 1
+
+# cfa pattern capability registers
+CFA_pattern_capability 0x1990 v1.1
+- e bayer 0
+- e monochrome 1
+- e 4x4_quad_bayer 2
+- e vendor_specific 3
+CFA_pattern_conversion_capability 0x1991 v1.1
+- b bayer 0
+
+# timer capability registers
+flash_mode_capability 0x1a02
+- b single_strobe 0
+sa_strobe_mode_capability 0x1a03
+- b fixed_width 0
+- b edge_ctrl 1
+
+# soft reset capability registers
+reset_max_delay 0x1a10 v1.1
+reset_min_time 0x1a11 v1.1
+
+# pdaf capability registers
+pdaf_capability_1 0x1b80
+- b supported 0
+- b processed_bottom_embedded 1
+- b processed_interleaved 2
+- b raw_bottom_embedded 3
+- b raw_interleaved 4
+- b visible_pdaf_correction 5
+- b vc_interleaving 6
+- b dt_interleaving 7
+pdaf_capability_2 0x1b81
+- b ROI 0
+- b after_digital_crop 1
+- b ctrl_retimed 2
+
+# bracketing interface capability registers
+bracketing_lut_capability_1 0x1c00
+- b coarse_integration 0
+- b global_analog_gain 1
+- b flash 4
+- b global_digital_gain 5
+- b alternate_global_analog_gain 6
+bracketing_lut_capability_2 0x1c01
+- b single_bracketing_mode 0
+- b looped_bracketing_mode 1
+bracketing_lut_size 0x1c02
diff --git a/Documentation/driver-api/media/drivers/ccs/ccs.rst b/Documentation/driver-api/media/drivers/ccs/ccs.rst
new file mode 100644
index 0000000..f49e971
--- /dev/null
+++ b/Documentation/driver-api/media/drivers/ccs/ccs.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
+
+.. include:: <isonum.txt>
+
+MIPI CCS camera sensor driver
+=============================
+
+The MIPI CCS camera sensor driver is a generic driver for `MIPI CCS
+<https://www.mipi.org/specifications/camera-command-set>`_ compliant
+camera sensors. It exposes three sub-devices representing the pixel array,
+the binner and the scaler.
+
+As the capabilities of individual devices vary, the driver exposes
+interfaces based on the capabilities that exist in hardware.
+
+Pixel Array sub-device
+----------------------
+
+The pixel array sub-device represents the camera sensor's pixel matrix, as well
+as analogue crop functionality present in many compliant devices. The analogue
+crop is configured using the ``V4L2_SEL_TGT_CROP`` on the source pad (0) of the
+entity. The size of the pixel matrix can be obtained by getting the
+``V4L2_SEL_TGT_NATIVE_SIZE`` target.
+
+Binner
+------
+
+The binner sub-device represents the binning functionality on the sensor. For
+that purpose, selection target ``V4L2_SEL_TGT_COMPOSE`` is supported on the
+sink pad (0).
+
+Additionally, if a device has no scaler or digital crop functionality, the
+source pad (1) expses another digital crop selection rectangle that can only
+crop at the end of the lines and frames.
+
+Scaler
+------
+
+The scaler sub-device represents the digital crop and scaling functionality of
+the sensor. The V4L2 selection target ``V4L2_SEL_TGT_CROP`` is used to
+configure the digital crop on the sink pad (0) when digital crop is supported.
+Scaling is configured using selection target ``V4L2_SEL_TGT_COMPOSE`` on the
+sink pad (0) as well.
+
+Additionally, if the scaler sub-device exists, its source pad (1) exposes
+another digital crop selection rectangle that can only crop at the end of the
+lines and frames.
+
+Digital and analogue crop
+-------------------------
+
+Digital crop functionality is referred to as cropping that effectively works by
+dropping some data on the floor. Analogue crop, on the other hand, means that
+the cropped information is never retrieved. In case of camera sensors, the
+analogue data is never read from the pixel matrix that are outside the
+configured selection rectangle that designates crop. The difference has an
+effect in device timing and likely also in power consumption.
+
+Register definition generator
+-----------------------------
+
+The ccs-regs.asc file contains MIPI CCS register definitions that are used
+to produce C source code files for definitions that can be better used by
+programs written in C language. As there are many dependencies between the
+produced files, please do not modify them manually as it's error-prone and
+in vain, but instead change the script producing them.
+
+Usage
+~~~~~
+
+Conventionally the script is called this way to update the CCS driver
+definitions:
+
+.. code-block:: none
+
+ $ Documentation/driver-api/media/drivers/ccs/mk-ccs-regs -k \
+ -e drivers/media/i2c/ccs/ccs-regs.h \
+ -L drivers/media/i2c/ccs/ccs-limits.h \
+ -l drivers/media/i2c/ccs/ccs-limits.c \
+ -c Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
+
+**Copyright** |copy| 2020 Intel Corporation
diff --git a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs
new file mode 100755
index 0000000..6668dea
--- /dev/null
+++ b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs
@@ -0,0 +1,433 @@
+#!/usr/bin/perl -w
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
+# Copyright (C) 2019--2020 Intel Corporation
+
+use Getopt::Long qw(:config no_ignore_case);
+use File::Basename;
+
+my $ccsregs = "ccs-regs.asc";
+my $header;
+my $regarray;
+my $limitc;
+my $limith;
+my $kernel;
+my $help;
+
+GetOptions("ccsregs|c=s" => \$ccsregs,
+ "header|e=s" => \$header,
+ "regarray|r=s" => \$regarray,
+ "limitc|l=s" => \$limitc,
+ "limith|L=s" => \$limith,
+ "kernel|k" => \$kernel,
+ "help|h" => \$help) or die "can't parse options";
+
+$help = 1 if ! defined $header || ! defined $limitc || ! defined $limith;
+
+if (defined $help) {
+ print <<EOH
+$0 - Create CCS register definitions for C
+
+usage: $0 -c ccs-regs.asc -e header -r regarray -l limit-c -L limit-header [-k]
+
+ -c ccs register file
+ -e header file name
+ -r register description array file name
+ -l limit and capability array file name
+ -L limit and capability header file name
+ -k generate files for kernel space consumption
+EOH
+ ;
+ exit 0;
+}
+
+my $lh_hdr = ! defined $kernel
+ ? '#include "ccs-os.h"' . "\n"
+ : "#include <linux/bits.h>\n#include <linux/types.h>\n";
+my $uint32_t = ! defined $kernel ? 'uint32_t' : 'u32';
+my $uint16_t = ! defined $kernel ? 'uint16_t' : 'u16';
+
+open(my $R, "< $ccsregs") or die "can't open $ccsregs";
+
+open(my $H, "> $header") or die "can't open $header";
+my $A;
+if (defined $regarray) {
+ open($A, "> $regarray") or die "can't open $regarray";
+}
+open(my $LC, "> $limitc") or die "can't open $limitc";
+open(my $LH, "> $limith") or die "can't open $limith";
+
+my %this;
+
+sub is_limit_reg($) {
+ my $addr = hex $_[0];
+
+ return 0 if $addr < 0x40; # weed out status registers
+ return 0 if $addr >= 0x100 && $addr < 0xfff; # weed out configuration registers
+
+ return 1;
+}
+
+my $uc_header = basename uc $header;
+$uc_header =~ s/[^A-Z0-9]/_/g;
+
+my $copyright = "/* Copyright (C) 2019--2020 Intel Corporation */\n";
+my $license = "SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause";
+
+for my $fh ($A, $LC) {
+ print $fh "// $license\n$copyright\n" if defined $fh;
+}
+
+for my $fh ($H, $LH) {
+ print $fh "/* $license */\n$copyright\n";
+}
+
+sub bit_def($) {
+ my $bit = shift @_;
+
+ return "BIT($bit)" if defined $kernel;
+ return "(1U << $bit)" if $bit =~ /^[a-zA-Z0-9_]+$/;
+ return "(1U << ($bit))";
+}
+
+print $H <<EOF
+#ifndef __${uc_header}__
+#define __${uc_header}__
+
+EOF
+ ;
+
+print $H "#include <linux/bits.h>\n\n" if defined $kernel;
+
+print $H <<EOF
+#define CCS_FL_BASE 16
+EOF
+ ;
+
+print $H "#define CCS_FL_16BIT " . bit_def("CCS_FL_BASE") . "\n";
+print $H "#define CCS_FL_32BIT " . bit_def("CCS_FL_BASE + 1") . "\n";
+print $H "#define CCS_FL_FLOAT_IREAL " . bit_def("CCS_FL_BASE + 2") . "\n";
+print $H "#define CCS_FL_IREAL " . bit_def("CCS_FL_BASE + 3") . "\n";
+
+print $H <<EOF
+#define CCS_R_ADDR(r) ((r) & 0xffff)
+
+EOF
+ ;
+
+print $A <<EOF
+#include <stdint.h>
+#include <stdio.h>
+#include "ccs-extra.h"
+#include "ccs-regs.h"
+
+EOF
+ if defined $A;
+
+my $uc_limith = basename uc $limith;
+$uc_limith =~ s/[^A-Z0-9]/_/g;
+
+print $LH <<EOF
+#ifndef __${uc_limith}__
+#define __${uc_limith}__
+
+$lh_hdr
+struct ccs_limit {
+ $uint32_t reg;
+ $uint16_t size;
+ $uint16_t flags;
+ const char *name;
+};
+
+EOF
+ ;
+print $LH "#define CCS_L_FL_SAME_REG " . bit_def(0) . "\n\n";
+
+print $LH <<EOF
+extern const struct ccs_limit ccs_limits[];
+
+EOF
+ ;
+
+print $LC <<EOF
+#include "ccs-limits.h"
+#include "ccs-regs.h"
+
+const struct ccs_limit ccs_limits[] = {
+EOF
+ ;
+
+my $limitcount = 0;
+my $argdescs;
+my $reglist = "const struct ccs_reg_desc ccs_reg_desc[] = {\n";
+
+sub name_split($$) {
+ my ($name, $addr) = @_;
+ my $args;
+
+ $name =~ /([^\(]+?)(\(.*)/;
+ ($name, $args) = ($1, $2);
+ $args = [split /,\s*/, $args];
+ foreach my $t (@$args) {
+ $t =~ s/[\(\)]//g;
+ $t =~ s/\//\\\//g;
+ }
+
+ return ($name, $addr, $args);
+}
+
+sub tabconv($) {
+ $_ = shift;
+
+ my @l = split "\n", $_;
+
+ map {
+ s/ {8,8}/\t/g;
+ s/\t\K +//;
+ } @l;
+
+ return (join "\n", @l) . "\n";
+}
+
+sub elem_size(@) {
+ my @flags = @_;
+
+ return 2 if grep /^16$/, @flags;
+ return 4 if grep /^32$/, @flags;
+ return 1;
+}
+
+sub arr_size($) {
+ my $this = $_[0];
+ my $size = $this->{elsize};
+ my $h = $this->{argparams};
+
+ foreach my $arg (@{$this->{args}}) {
+ my $apref = $h->{$arg};
+
+ $size *= $apref->{max} - $apref->{min} + 1;
+ }
+
+ return $size;
+}
+
+sub print_args($$$) {
+ my ($this, $postfix, $is_same_reg) = @_;
+ my ($args, $argparams, $name) =
+ ($this->{args}, $this->{argparams}, $this->{name});
+ my $varname = "ccs_reg_arg_" . (lc $name) . $postfix;
+ my @mins;
+ my @sorted_args = @{$this->{sorted_args}};
+ my $lim_arg;
+ my $size = arr_size($this);
+
+ $argdescs .= "static const struct ccs_reg_arg " . $varname . "[] = {\n";
+
+ foreach my $sorted_arg (@sorted_args) {
+ push @mins, $argparams->{$sorted_arg}->{min};
+ }
+
+ foreach my $sorted_arg (@sorted_args) {
+ my $h = $argparams->{$sorted_arg};
+
+ $argdescs .= "\t{ \"$sorted_arg\", $h->{min}, $h->{max}, $h->{elsize} },\n";
+
+ $lim_arg .= defined $lim_arg ? ", $h->{min}" : "$h->{min}";
+ }
+
+ $argdescs .= "};\n\n";
+
+ $reglist .= "\t{ CCS_R_" . (uc $name) . "(" . (join ",", (@mins)) .
+ "), $size, sizeof($varname) / sizeof(*$varname)," .
+ " \"" . (lc $name) . "\", $varname },\n";
+
+ print $LC tabconv sprintf "\t{ CCS_R_" . (uc $name) . "($lim_arg), " .
+ $size . ", " . ($is_same_reg ? "CCS_L_FL_SAME_REG" : "0") .
+ ", \"$name" . (defined $this->{discontig} ? " $lim_arg" : "") . "\" },\n"
+ if is_limit_reg $this->{base_addr};
+}
+
+my $hdr_data;
+
+while (<$R>) {
+ chop;
+ s/^\s*//;
+ next if /^[#;]/ || /^$/;
+ if (s/^-\s*//) {
+ if (s/^b\s*//) {
+ my ($bit, $addr) = split /\t+/;
+ $bit = uc $bit;
+ $hdr_data .= sprintf "#define %-62s %s", "CCS_" . (uc ${this{name}}) ."_$bit", bit_def($addr) . "\n";
+ } elsif (s/^f\s*//) {
+ s/[,\.-]/_/g;
+ my @a = split /\s+/;
+ my ($msb, $lsb, $this_field) = reverse @a;
+ @a = ( { "name" => "SHIFT", "addr" => $lsb, "fmt" => "%uU", },
+ { "name" => "MASK", "addr" => (1 << ($msb + 1)) - 1 - ((1 << $lsb) - 1), "fmt" => "0x%" . join(".", ($this{"elsize"} >> 2) x 2) . "x" } );
+ $this{"field"} = $this_field;
+ foreach my $ar (@a) {
+ #print $ar->{fmt}."\n";
+ $hdr_data .= sprintf "#define %-62s " . $ar->{"fmt"} . "\n", "CCS_" . (uc $this{"name"}) . (defined $this_field ? "_" . uc $this_field : "") . "_" . $ar->{"name"}, $ar->{"addr"} . "\n";
+ }
+ } elsif (s/^e\s*//) {
+ s/[,\.-]/_/g;
+ my ($enum, $addr) = split /\s+/;
+ $enum = uc $enum;
+ $hdr_data .= sprintf "#define %-62s %s", "CCS_" . (uc ${this{name}}) . (defined $this{"field"} ? "_" . uc $this{"field"} : "") ."_$enum", $addr . ($addr =~ /0x/i ? "" : "U") . "\n";
+ } elsif (s/^l\s*//) {
+ my ($arg, $min, $max, $elsize, @discontig) = split /\s+/;
+ my $size;
+
+ foreach my $num ($min, $max) {
+ $num = hex $num if $num =~ /0x/i;
+ }
+
+ $hdr_data .= sprintf "#define %-62s %s", "CCS_LIM_" . (uc ${this{name}} . "_MIN_$arg"), $min . ($min =~ /0x/i ? "" : "U") . "\n";
+ $hdr_data .= sprintf "#define %-62s %s", "CCS_LIM_" . (uc ${this{name}} . "_MAX_$arg"), $max . ($max =~ /0x/i ? "" : "U") . "\n";
+
+ my $h = $this{argparams};
+
+ $h->{$arg} = { "min" => $min,
+ "max" => $max,
+ "elsize" => $elsize =~ /^0x/ ? hex $elsize : $elsize,
+ "discontig" => \@discontig };
+
+ $this{discontig} = $arg if @discontig;
+
+ next if $#{$this{args}} + 1 != scalar keys %{$this{argparams}};
+
+ my $reg_formula = "($this{addr}";
+ my $lim_formula;
+
+ foreach my $arg (@{$this{args}}) {
+ my $d = $h->{$arg}->{discontig};
+ my $times = $h->{$arg}->{elsize} != 1 ?
+ " * " . $h->{$arg}->{elsize} : "";
+
+ if (@$d) {
+ my ($lim, $offset) = split /,/, $d->[0];
+
+ $reg_formula .= " + (($arg) < $lim ? ($arg)$times : $offset + (($arg) - $lim)$times)";
+ } else {
+ $reg_formula .= " + ($arg)$times";
+ }
+
+ $lim_formula .= (defined $lim_formula ? " + " : "") . "($arg)$times";
+ }
+
+ $reg_formula .= ")\n";
+ $lim_formula =~ s/^\(([a-z0-9]+)\)$/$1/i;
+
+ print $H tabconv sprintf("#define %-62s %s", "CCS_R_" . (uc $this{name}) .
+ $this{arglist}, $reg_formula);
+
+ print $H tabconv $hdr_data;
+ undef $hdr_data;
+
+ # Sort arguments in descending order by size
+ @{$this{sorted_args}} = sort {
+ $h->{$a}->{elsize} <= $h->{$b}->{elsize}
+ } @{$this{args}};
+
+ if (defined $this{discontig}) {
+ my $da = $this{argparams}->{$this{discontig}};
+ my ($first_discontig) = split /,/, $da->{discontig}->[0];
+ my $max = $da->{max};
+
+ $da->{max} = $first_discontig - 1;
+ print_args(\%this, "", 0);
+
+ $da->{min} = $da->{max} + 1;
+ $da->{max} = $max;
+ print_args(\%this, $first_discontig, 1);
+ } else {
+ print_args(\%this, "", 0);
+ }
+
+ next unless is_limit_reg $this{base_addr};
+
+ print $LH tabconv sprintf "#define %-63s%s\n",
+ "CCS_L_" . (uc $this{name}) . "_OFFSET(" .
+ (join ", ", @{$this{args}}) . ")", "($lim_formula)";
+ }
+
+ if (! @{$this{args}}) {
+ print $H tabconv($hdr_data);
+ undef $hdr_data;
+ }
+
+ next;
+ }
+
+ my ($name, $addr, @flags) = split /\t+/, $_;
+ my $args = [];
+
+ my $sp;
+
+ ($name, $addr, $args) = name_split($name, $addr) if /\(.*\)/;
+
+ $name =~ s/[,\.-]/_/g;
+
+ my $flagstring = "";
+ my $size = elem_size(@flags);
+ $flagstring .= "| CCS_FL_16BIT " if $size eq "2";
+ $flagstring .= "| CCS_FL_32BIT " if $size eq "4";
+ $flagstring .= "| CCS_FL_FLOAT_IREAL " if grep /^float_ireal$/, @flags;
+ $flagstring .= "| CCS_FL_IREAL " if grep /^ireal$/, @flags;
+ $flagstring =~ s/^\| //;
+ $flagstring =~ s/ $//;
+ $flagstring = "($flagstring)" if $flagstring =~ /\|/;
+ my $base_addr = $addr;
+ $addr = "($addr | $flagstring)" if $flagstring ne "";
+
+ my $arglist = @$args ? "(" . (join ", ", @$args) . ")" : "";
+ $hdr_data .= sprintf "#define %-62s %s\n", "CCS_R_" . (uc $name), $addr
+ if !@$args;
+
+ $name =~ s/\(.*//;
+
+ %this = ( name => $name,
+ addr => $addr,
+ base_addr => $base_addr,
+ argparams => {},
+ args => $args,
+ arglist => $arglist,
+ elsize => $size,
+ );
+
+ if (!@$args) {
+ $reglist .= "\t{ CCS_R_" . (uc $name) . ", 1, 0, \"" . (lc $name) . "\", NULL },\n";
+ print $H tabconv $hdr_data;
+ undef $hdr_data;
+
+ print $LC tabconv sprintf "\t{ CCS_R_" . (uc $name) . ", " .
+ $this{elsize} . ", 0, \"$name\" },\n"
+ if is_limit_reg $this{base_addr};
+ }
+
+ print $LH tabconv sprintf "#define %-63s%s\n",
+ "CCS_L_" . (uc $this{name}), $limitcount++
+ if is_limit_reg $this{base_addr};
+}
+
+if (defined $A) {
+ print $A $argdescs, $reglist;
+
+ print $A "\t{ 0 }\n";
+
+ print $A "};\n";
+}
+
+print $H "\n#endif /* __${uc_header}__ */\n";
+
+print $LH tabconv sprintf "#define %-63s%s\n", "CCS_L_LAST", $limitcount;
+
+print $LH "\n#endif /* __${uc_limith}__ */\n";
+
+print $LC "\t{ 0 } /* Guardian */\n";
+print $LC "};\n";
+
+close($R);
+close($H);
+close($A) if defined $A;
+close($LC);
+close($LH);
diff --git a/Documentation/driver-api/media/drivers/index.rst b/Documentation/driver-api/media/drivers/index.rst
index eb70117..426cda6 100644
--- a/Documentation/driver-api/media/drivers/index.rst
+++ b/Documentation/driver-api/media/drivers/index.rst
@@ -26,6 +26,7 @@
tuners
vimc-devel
zoran
+ ccs/ccs
Digital TV drivers
diff --git a/Documentation/driver-api/media/dtv-frontend.rst b/Documentation/driver-api/media/dtv-frontend.rst
index 91f77fe..ea43cdb 100644
--- a/Documentation/driver-api/media/dtv-frontend.rst
+++ b/Documentation/driver-api/media/dtv-frontend.rst
@@ -244,7 +244,7 @@
Having it available after inner FEC is more common.
Bit counts post-FEC (:ref:`DTV-STAT-POST-ERROR-BIT-COUNT` and :ref:`DTV-STAT-POST-TOTAL-BIT-COUNT`)
- - Those counters measure the number of bits and bit errors errors after
+ - Those counters measure the number of bits and bit errors after
the forward error correction (FEC) on the inner coding block
(after Viterbi, LDPC or other inner code).
@@ -253,7 +253,7 @@
see :c:type:`fe_status`).
Bit counts pre-FEC (:ref:`DTV-STAT-PRE-ERROR-BIT-COUNT` and :ref:`DTV-STAT-PRE-TOTAL-BIT-COUNT`)
- - Those counters measure the number of bits and bit errors errors before
+ - Those counters measure the number of bits and bit errors before
the forward error correction (FEC) on the inner coding block
(before Viterbi, LDPC or other inner code).
@@ -263,7 +263,7 @@
after ``FE_HAS_VITERBI``, see :c:type:`fe_status`).
Block counts (:ref:`DTV-STAT-ERROR-BLOCK-COUNT` and :ref:`DTV-STAT-TOTAL-BLOCK-COUNT`)
- - Those counters measure the number of blocks and block errors errors after
+ - Those counters measure the number of blocks and block errors after
the forward error correction (FEC) on the inner coding block
(before Viterbi, LDPC or other inner code).
diff --git a/Documentation/driver-api/media/v4l2-controls.rst b/Documentation/driver-api/media/v4l2-controls.rst
index 77f42ea..b2e9180 100644
--- a/Documentation/driver-api/media/v4l2-controls.rst
+++ b/Documentation/driver-api/media/v4l2-controls.rst
@@ -335,7 +335,7 @@
union v4l2_ctrl_ptr p_new;
union v4l2_ctrl_ptr p_cur;
-If the control has a simple s32 type type, then:
+If the control has a simple s32 type, then:
.. code-block:: c
@@ -349,7 +349,7 @@
themselves. The p_char pointers point to character buffers of length
ctrl->maximum + 1, and are always 0-terminated.
-Unless the control is marked volatile the p_cur field points to the the
+Unless the control is marked volatile the p_cur field points to the
current cached control value. When you create a new control this value is made
identical to the default value. After calling v4l2_ctrl_handler_setup() this
value is passed to the hardware. It is generally a good idea to call this
diff --git a/Documentation/driver-api/media/v4l2-dev.rst b/Documentation/driver-api/media/v4l2-dev.rst
index 666330a..99e3b5f 100644
--- a/Documentation/driver-api/media/v4l2-dev.rst
+++ b/Documentation/driver-api/media/v4l2-dev.rst
@@ -212,7 +212,7 @@
========================== ==================== ==============================
The last argument gives you a certain amount of control over the device
-device node number used (i.e. the X in ``videoX``). Normally you will pass -1
+node number used (i.e. the X in ``videoX``). Normally you will pass -1
to let the v4l2 framework pick the first free number. But sometimes users
want to select a specific node number. It is common that drivers allow
the user to select a specific device node number through a driver module
diff --git a/Documentation/driver-api/mtd/intel-spi.rst b/Documentation/driver-api/mtd/intel-spi.rst
index 0e6d9cd..0465f68 100644
--- a/Documentation/driver-api/mtd/intel-spi.rst
+++ b/Documentation/driver-api/mtd/intel-spi.rst
@@ -52,7 +52,7 @@
16384+0 records out
8388608 bytes (8.4 MB) copied, 10.0269 s, 837 kB/s
- 6) Verify the backup:
+ 6) Verify the backup::
# sha1sum /dev/mtd0ro bios.bak
fdbb011920572ca6c991377c4b418a0502668b73 /dev/mtd0ro
@@ -66,7 +66,7 @@
# flash_erase /dev/mtd0 0 0
Erasing 4 Kibyte @ 7ff000 -- 100 % complete
- 8) Once completed without errors you can write the new BIOS image:
+ 8) Once completed without errors you can write the new BIOS image::
# dd if=MNW2MAX1.X64.0092.R01.1605221712.bin of=/dev/mtd0
diff --git a/Documentation/driver-api/mtd/nand_ecc.rst b/Documentation/driver-api/mtd/nand_ecc.rst
index e8d3c53..74347c1 100644
--- a/Documentation/driver-api/mtd/nand_ecc.rst
+++ b/Documentation/driver-api/mtd/nand_ecc.rst
@@ -5,7 +5,7 @@
Introduction
============
-Having looked at the linux mtd/nand driver and more specific at nand_ecc.c
+Having looked at the linux mtd/nand Hamming software ECC engine driver
I felt there was room for optimisation. I bashed the code for a few hours
performing tricks like table lookup removing superfluous code etc.
After that the speed was increased by 35-40%.
diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
index 1f04376..4a3adca 100644
--- a/Documentation/driver-api/mtd/spi-nor.rst
+++ b/Documentation/driver-api/mtd/spi-nor.rst
@@ -34,7 +34,8 @@
------------------------
SPI NOR chip
- After this framework, the layer is like:
+After this framework, the layer is like::
+
MTD
------------------------
SPI NOR framework
@@ -45,7 +46,8 @@
------------------------
SPI NOR chip
- With the SPI NOR controller driver (Freescale QuadSPI), it looks like:
+With the SPI NOR controller driver (Freescale QuadSPI), it looks like::
+
MTD
------------------------
SPI NOR framework
diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst
index 0bf8d6e..ce77e02 100644
--- a/Documentation/driver-api/mtdnand.rst
+++ b/Documentation/driver-api/mtdnand.rst
@@ -972,9 +972,6 @@
.. kernel-doc:: drivers/mtd/nand/raw/nand_base.c
:export:
-.. kernel-doc:: drivers/mtd/nand/raw/nand_ecc.c
- :export:
-
Internal Functions Provided
===========================
diff --git a/Documentation/driver-api/reset.rst b/Documentation/driver-api/reset.rst
new file mode 100644
index 0000000..84e03d7
--- /dev/null
+++ b/Documentation/driver-api/reset.rst
@@ -0,0 +1,221 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+====================
+Reset controller API
+====================
+
+Introduction
+============
+
+Reset controllers are central units that control the reset signals to multiple
+peripherals.
+The reset controller API is split into two parts:
+the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
+<#reset-consumer-api>`__), which allows peripheral drivers to request control
+over their reset input signals, and the `reset controller driver interface
+<#reset-controller-driver-interface>`__ (`API reference
+<#reset-controller-driver-api>`__), which is used by drivers for reset
+controller devices to register their reset controls to provide them to the
+consumers.
+
+While some reset controller hardware units also implement system restart
+functionality, restart handlers are out of scope for the reset controller API.
+
+Glossary
+--------
+
+The reset controller API uses these terms with a specific meaning:
+
+Reset line
+
+ Physical reset line carrying a reset signal from a reset controller
+ hardware unit to a peripheral module.
+
+Reset control
+
+ Control method that determines the state of one or multiple reset lines.
+ Most commonly this is a single bit in reset controller register space that
+ either allows direct control over the physical state of the reset line, or
+ is self-clearing and can be used to trigger a predetermined pulse on the
+ reset line.
+ In more complicated reset controls, a single trigger action can launch a
+ carefully timed sequence of pulses on multiple reset lines.
+
+Reset controller
+
+ A hardware module that provides a number of reset controls to control a
+ number of reset lines.
+
+Reset consumer
+
+ Peripheral module or external IC that is put into reset by the signal on a
+ reset line.
+
+Consumer driver interface
+=========================
+
+This interface provides an API that is similar to the kernel clock framework.
+Consumer drivers use get and put operations to acquire and release reset
+controls.
+Functions are provided to assert and deassert the controlled reset lines,
+trigger reset pulses, or to query reset line status.
+
+When requesting reset controls, consumers can use symbolic names for their
+reset inputs, which are mapped to an actual reset control on an existing reset
+controller device by the core.
+
+A stub version of this API is provided when the reset controller framework is
+not in use in order to minimize the need to use ifdefs.
+
+Shared and exclusive resets
+---------------------------
+
+The reset controller API provides either reference counted deassertion and
+assertion or direct, exclusive control.
+The distinction between shared and exclusive reset controls is made at the time
+the reset control is requested, either via devm_reset_control_get_shared() or
+via devm_reset_control_get_exclusive().
+This choice determines the behavior of the API calls made with the reset
+control.
+
+Shared resets behave similarly to clocks in the kernel clock framework.
+They provide reference counted deassertion, where only the first deassert,
+which increments the deassertion reference count to one, and the last assert
+which decrements the deassertion reference count back to zero, have a physical
+effect on the reset line.
+
+Exclusive resets on the other hand guarantee direct control.
+That is, an assert causes the reset line to be asserted immediately, and a
+deassert causes the reset line to be deasserted immediately.
+
+Assertion and deassertion
+-------------------------
+
+Consumer drivers use the reset_control_assert() and reset_control_deassert()
+functions to assert and deassert reset lines.
+For shared reset controls, calls to the two functions must be balanced.
+
+Note that since multiple consumers may be using a shared reset control, there
+is no guarantee that calling reset_control_assert() on a shared reset control
+will actually cause the reset line to be asserted.
+Consumer drivers using shared reset controls should assume that the reset line
+may be kept deasserted at all times.
+The API only guarantees that the reset line can not be asserted as long as any
+consumer has requested it to be deasserted.
+
+Triggering
+----------
+
+Consumer drivers use reset_control_reset() to trigger a reset pulse on a
+self-deasserting reset control.
+In general, these resets can not be shared between multiple consumers, since
+requesting a pulse from any consumer driver will reset all connected
+peripherals.
+
+The reset controller API allows requesting self-deasserting reset controls as
+shared, but for those only the first trigger request causes an actual pulse to
+be issued on the reset line.
+All further calls to this function have no effect until all consumers have
+called reset_control_rearm().
+For shared reset controls, calls to the two functions must be balanced.
+This allows devices that only require an initial reset at any point before the
+driver is probed or resumed to share a pulsed reset line.
+
+Querying
+--------
+
+Only some reset controllers support querying the current status of a reset
+line, via reset_control_status().
+If supported, this function returns a positive non-zero value if the given
+reset line is asserted.
+The reset_control_status() function does not accept a
+`reset control array <#reset-control-arrays>`__ handle as its input parameter.
+
+Optional resets
+---------------
+
+Often peripherals require a reset line on some platforms but not on others.
+For this, reset controls can be requested as optional using
+devm_reset_control_get_optional_exclusive() or
+devm_reset_control_get_optional_shared().
+These functions return a NULL pointer instead of an error when the requested
+reset control is not specified in the device tree.
+Passing a NULL pointer to the reset_control functions causes them to return
+quietly without an error.
+
+Reset control arrays
+--------------------
+
+Some drivers need to assert a bunch of reset lines in no particular order.
+devm_reset_control_array_get() returns an opaque reset control handle that can
+be used to assert, deassert, or trigger all specified reset controls at once.
+The reset control API does not guarantee the order in which the individual
+controls therein are handled.
+
+Reset controller driver interface
+=================================
+
+Drivers for reset controller modules provide the functionality necessary to
+assert or deassert reset signals, to trigger a reset pulse on a reset line, or
+to query its current state.
+All functions are optional.
+
+Initialization
+--------------
+
+Drivers fill a struct :c:type:`reset_controller_dev` and register it with
+reset_controller_register() in their probe function.
+The actual functionality is implemented in callback functions via a struct
+:c:type:`reset_control_ops`.
+
+API reference
+=============
+
+The reset controller API is documented here in two parts:
+the `reset consumer API <#reset-consumer-api>`__ and the `reset controller
+driver API <#reset-controller-driver-api>`__.
+
+Reset consumer API
+------------------
+
+Reset consumers can control a reset line using an opaque reset control handle,
+which can be obtained from devm_reset_control_get_exclusive() or
+devm_reset_control_get_shared().
+Given the reset control, consumers can call reset_control_assert() and
+reset_control_deassert(), trigger a reset pulse using reset_control_reset(), or
+query the reset line status using reset_control_status().
+
+.. kernel-doc:: include/linux/reset.h
+ :internal:
+
+.. kernel-doc:: drivers/reset/core.c
+ :functions: reset_control_reset
+ reset_control_assert
+ reset_control_deassert
+ reset_control_status
+ reset_control_acquire
+ reset_control_release
+ reset_control_rearm
+ reset_control_put
+ of_reset_control_get_count
+ of_reset_control_array_get
+ devm_reset_control_array_get
+ reset_control_get_count
+
+Reset controller driver API
+---------------------------
+
+Reset controller drivers are supposed to implement the necessary functions in
+a static constant structure :c:type:`reset_control_ops`, allocate and fill out
+a struct :c:type:`reset_controller_dev`, and register it using
+devm_reset_controller_register().
+
+.. kernel-doc:: include/linux/reset-controller.h
+ :internal:
+
+.. kernel-doc:: drivers/reset/core.c
+ :functions: of_reset_simple_xlate
+ reset_controller_register
+ reset_controller_unregister
+ devm_reset_controller_register
+ reset_controller_add_lookup
diff --git a/Documentation/driver-api/thermal/power_allocator.rst b/Documentation/driver-api/thermal/power_allocator.rst
index 67b6a32..aa5f665 100644
--- a/Documentation/driver-api/thermal/power_allocator.rst
+++ b/Documentation/driver-api/thermal/power_allocator.rst
@@ -71,7 +71,9 @@
simply an estimate, and may be tuned to affect the aggressiveness of
the thermal ramp. For reference, the sustainable power of a 4" phone
is typically 2000mW, while on a 10" tablet is around 4500mW (may vary
-depending on screen size).
+depending on screen size). It is possible to have the power value
+expressed in an abstract scale. The sustained power should be aligned
+to the scale used by the related cooling devices.
If you are using device tree, do add it as a property of the
thermal-zone. For example::
@@ -269,3 +271,11 @@
governor, step-wise will also misbehave if you call its throttle()
faster than the normal thermal framework tick (due to interrupts for
example) as it will overreact.
+
+Energy Model requirements
+=========================
+
+Another important thing is the consistent scale of the power values
+provided by the cooling devices. All of the cooling devices in a single
+thermal zone should have power values reported either in milli-Watts
+or scaled to the same 'abstract scale'.
diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst
index b40b1f8..e7520cb 100644
--- a/Documentation/driver-api/thermal/sysfs-api.rst
+++ b/Documentation/driver-api/thermal/sysfs-api.rst
@@ -654,8 +654,7 @@
The amount of time spent by the cooling device in various cooling
states. The output will have "<state> <time>" pair in each line, which
will mean this cooling device spent <time> msec of time at <state>.
- Output will have one line for each of the supported states. usertime
- units here is 10mS (similar to other time exported in /proc).
+ Output will have one line for each of the supported states.
RO, Required
diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt
index c3fe9b2..b2288dc 100644
--- a/Documentation/features/debug/KASAN/arch-support.txt
+++ b/Documentation/features/debug/KASAN/arch-support.txt
@@ -8,7 +8,7 @@
-----------------------
| alpha: | TODO |
| arc: | TODO |
- | arm: | TODO |
+ | arm: | ok |
| arm64: | ok |
| c6x: | TODO |
| csky: | TODO |
diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh
index 1ec47c3..e73aa35 100755
--- a/Documentation/features/list-arch.sh
+++ b/Documentation/features/list-arch.sh
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Small script that visualizes the kernel feature support status
# of an architecture.
@@ -7,18 +8,4 @@
ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
-cd $(dirname $0)
-echo "#"
-echo "# Kernel feature support matrix of the '$ARCH' architecture:"
-echo "#"
-
-for F in */*/arch-support.txt; do
- SUBSYS=$(echo $F | cut -d/ -f1)
- N=$(grep -h "^# Feature name:" $F | cut -c25-)
- C=$(grep -h "^# Kconfig:" $F | cut -c25-)
- D=$(grep -h "^# description:" $F | cut -c25-)
- S=$(grep -hv "^#" $F | grep -w $ARCH | cut -d\| -f3)
-
- printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
-done
-
+$(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH
diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
index 5c6bcfc..4dd5e55 100644
--- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | ok |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |
diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
index b55e420..b16d4f7 100644
--- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | ok |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |
diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
index c688aba..eb3d740 100644
--- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt
+++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
@@ -11,7 +11,7 @@
| arm: | ok |
| arm64: | ok |
| c6x: | TODO |
- | csky: | TODO |
+ | csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
| ia64: | TODO |
@@ -25,7 +25,7 @@
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
- | sh: | TODO |
+ | sh: | ok |
| sparc: | TODO |
| um: | ok |
| x86: | ok |
diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt
index 8287b6a..6863a3f 100644
--- a/Documentation/features/time/clockevents/arch-support.txt
+++ b/Documentation/features/time/clockevents/arch-support.txt
@@ -1,6 +1,6 @@
#
# Feature name: clockevents
-# Kconfig: GENERIC_CLOCKEVENTS
+# Kconfig: !LEGACY_TIMER_TICK
# description: arch support generic clock events
#
-----------------------
@@ -8,20 +8,20 @@
-----------------------
| alpha: | ok |
| arc: | ok |
- | arm: | ok |
+ | arm: | TODO |
| arm64: | ok |
| c6x: | ok |
| csky: | ok |
| h8300: | ok |
| hexagon: | ok |
| ia64: | TODO |
- | m68k: | ok |
+ | m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
| nds32: | ok |
| nios2: | ok |
| openrisc: | ok |
- | parisc: | ok |
+ | parisc: | TODO |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt
index 266c81e..52aea27 100644
--- a/Documentation/features/time/context-tracking/arch-support.txt
+++ b/Documentation/features/time/context-tracking/arch-support.txt
@@ -11,7 +11,7 @@
| arm: | ok |
| arm64: | ok |
| c6x: | TODO |
- | csky: | TODO |
+ | csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
| ia64: | TODO |
diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt
index d9082b9..6fc03de 100644
--- a/Documentation/features/time/irq-time-acct/arch-support.txt
+++ b/Documentation/features/time/irq-time-acct/arch-support.txt
@@ -23,7 +23,7 @@
| openrisc: | TODO |
| parisc: | .. |
| powerpc: | ok |
- | riscv: | TODO |
+ | riscv: | ok |
| s390: | .. |
| sh: | TODO |
| sparc: | .. |
diff --git a/Documentation/features/time/modern-timekeeping/arch-support.txt b/Documentation/features/time/modern-timekeeping/arch-support.txt
deleted file mode 100644
index a84c3b9..0000000
--- a/Documentation/features/time/modern-timekeeping/arch-support.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# Feature name: modern-timekeeping
-# Kconfig: !ARCH_USES_GETTIMEOFFSET
-# description: arch does not use arch_gettimeoffset() anymore
-#
- -----------------------
- | arch |status|
- -----------------------
- | alpha: | ok |
- | arc: | ok |
- | arm: | TODO |
- | arm64: | ok |
- | c6x: | ok |
- | csky: | ok |
- | h8300: | ok |
- | hexagon: | ok |
- | ia64: | ok |
- | m68k: | ok |
- | microblaze: | ok |
- | mips: | ok |
- | nds32: | ok |
- | nios2: | ok |
- | openrisc: | ok |
- | parisc: | ok |
- | powerpc: | ok |
- | riscv: | ok |
- | s390: | ok |
- | sh: | ok |
- | sparc: | ok |
- | um: | ok |
- | x86: | ok |
- | xtensa: | ok |
- -----------------------
diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt
index 56b372d..e51f3af 100644
--- a/Documentation/features/time/virt-cpuacct/arch-support.txt
+++ b/Documentation/features/time/virt-cpuacct/arch-support.txt
@@ -11,7 +11,7 @@
| arm: | ok |
| arm64: | ok |
| c6x: | TODO |
- | csky: | TODO |
+ | csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
| ia64: | ok |
diff --git a/Documentation/filesystems/ext2.rst b/Documentation/filesystems/ext2.rst
index d83dbbb..c2fce22 100644
--- a/Documentation/filesystems/ext2.rst
+++ b/Documentation/filesystems/ext2.rst
@@ -1,6 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
+==============================
The Second Extended Filesystem
==============================
diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst
index 849d5b1..cdbfec4 100644
--- a/Documentation/filesystems/ext4/journal.rst
+++ b/Documentation/filesystems/ext4/journal.rst
@@ -681,3 +681,53 @@
- Stores the TID of the commit, CRC of the fast commit of which this tag
represents the end of
+Fast Commit Replay Idempotence
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Fast commits tags are idempotent in nature provided the recovery code follows
+certain rules. The guiding principle that the commit path follows while
+committing is that it stores the result of a particular operation instead of
+storing the procedure.
+
+Let's consider this rename operation: 'mv /a /b'. Let's assume dirent '/a'
+was associated with inode 10. During fast commit, instead of storing this
+operation as a procedure "rename a to b", we store the resulting file system
+state as a "series" of outcomes:
+
+- Link dirent b to inode 10
+- Unlink dirent a
+- Inode 10 with valid refcount
+
+Now when recovery code runs, it needs "enforce" this state on the file
+system. This is what guarantees idempotence of fast commit replay.
+
+Let's take an example of a procedure that is not idempotent and see how fast
+commits make it idempotent. Consider following sequence of operations:
+
+1) rm A
+2) mv B A
+3) read A
+
+If we store this sequence of operations as is then the replay is not idempotent.
+Let's say while in replay, we crash after (2). During the second replay,
+file A (which was actually created as a result of "mv B A" operation) would get
+deleted. Thus, file named A would be absent when we try to read A. So, this
+sequence of operations is not idempotent. However, as mentioned above, instead
+of storing the procedure fast commits store the outcome of each procedure. Thus
+the fast commit log for above procedure would be as follows:
+
+(Let's assume dirent A was linked to inode 10 and dirent B was linked to
+inode 11 before the replay)
+
+1) Unlink A
+2) Link A to inode 11
+3) Unlink B
+4) Inode 11
+
+If we crash after (3) we will have file A linked to inode 11. During the second
+replay, we will remove file A (inode 11). But we will create it back and make
+it point to inode 11. We won't find B, so we'll just skip that step. At this
+point, the refcount for inode 11 is not reliable, but that gets fixed by the
+replay of last inode 11 tag. Thus, by converting a non-idempotent procedure
+into a series of idempotent outcomes, fast commits ensured idempotence during
+the replay.
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index b8ee761..dae15c9 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -260,6 +260,14 @@
For other files, we can still enable compression via ioctl.
Note that, there is one reserved special extension '*', it
can be set to enable compression for all files.
+compress_chksum Support verifying chksum of raw data in compressed cluster.
+compress_mode=%s Control file compression mode. This supports "fs" and "user"
+ modes. In "fs" mode (default), f2fs does automatic compression
+ on the compression enabled files. In "user" mode, f2fs disables
+ the automaic compression and gives the user discretion of
+ choosing the target file and the timing. The user can do manual
+ compression/decompression on the compression enabled files using
+ ioctls.
inlinecrypt When possible, encrypt/decrypt the contents of encrypted
files using the blk-crypto framework rather than
filesystem-layer encryption. This allows the use of
@@ -810,6 +818,34 @@
| data length | data chksum | reserved | compressed data |
+-------------+-------------+----------+----------------------------+
+Compression mode
+--------------------------
+
+f2fs supports "fs" and "user" compression modes with "compression_mode" mount option.
+With this option, f2fs provides a choice to select the way how to compress the
+compression enabled files (refer to "Compression implementation" section for how to
+enable compression on a regular inode).
+
+1) compress_mode=fs
+This is the default option. f2fs does automatic compression in the writeback of the
+compression enabled files.
+
+2) compress_mode=user
+This disables the automaic compression and gives the user discretion of choosing the
+target file and the timing. The user can do manual compression/decompression on the
+compression enabled files using F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE
+ioctls like the below.
+
+To decompress a file,
+
+fd = open(filename, O_WRONLY, 0);
+ret = ioctl(fd, F2FS_IOC_DECOMPRESS_FILE);
+
+To compress a file,
+
+fd = open(filename, O_WRONLY, 0);
+ret = ioctl(fd, F2FS_IOC_COMPRESS_FILE);
+
NVMe Zoned Namespace devices
----------------------------
diff --git a/Documentation/filesystems/files.rst b/Documentation/filesystems/files.rst
index cbf8e57..bcf8445 100644
--- a/Documentation/filesystems/files.rst
+++ b/Documentation/filesystems/files.rst
@@ -62,7 +62,7 @@
be held.
4. To look up the file structure given an fd, a reader
- must use either fcheck() or fcheck_files() APIs. These
+ must use either lookup_fd_rcu() or files_lookup_fd_rcu() APIs. These
take care of barrier requirements due to lock-free lookup.
An example::
@@ -70,7 +70,7 @@
struct file *file;
rcu_read_lock();
- file = fcheck(fd);
+ file = lookup_fd_rcu(fd);
if (file) {
...
}
@@ -84,7 +84,7 @@
on ->f_count::
rcu_read_lock();
- file = fcheck_files(files, fd);
+ file = files_lookup_fd_rcu(files, fd);
if (file) {
if (atomic_long_inc_not_zero(&file->f_count))
*fput_needed = 1;
@@ -104,7 +104,7 @@
lock-free, they must be installed using rcu_assign_pointer()
API. If they are looked up lock-free, rcu_dereference()
must be used. However it is advisable to use files_fdtable()
- and fcheck()/fcheck_files() which take care of these issues.
+ and lookup_fd_rcu()/files_lookup_fd_rcu() which take care of these issues.
7. While updating, the fdtable pointer must be looked up while
holding files->file_lock. If ->file_lock is dropped, then
diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index 895e971..e0204a2 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -27,9 +27,9 @@
corrupted data, including mmap reads, will fail.
Userspace can use another ioctl to retrieve the root hash (actually
-the "file measurement", which is a hash that includes the root hash)
-that fs-verity is enforcing for the file. This ioctl executes in
-constant time, regardless of the file size.
+the "fs-verity file digest", which is a hash that includes the Merkle
+tree root hash) that fs-verity is enforcing for the file. This ioctl
+executes in constant time, regardless of the file size.
fs-verity is essentially a way to hash a file in constant time,
subject to the caveat that reads which would violate the hash will
@@ -177,9 +177,10 @@
FS_IOC_MEASURE_VERITY
---------------------
-The FS_IOC_MEASURE_VERITY ioctl retrieves the measurement of a verity
-file. The file measurement is a digest that cryptographically
-identifies the file contents that are being enforced on reads.
+The FS_IOC_MEASURE_VERITY ioctl retrieves the digest of a verity file.
+The fs-verity file digest is a cryptographic digest that identifies
+the file contents that are being enforced on reads; it is computed via
+a Merkle tree and is different from a traditional full-file digest.
This ioctl takes in a pointer to a variable-length structure::
@@ -197,7 +198,7 @@
follows:
- ``digest_algorithm`` will be the hash algorithm used for the file
- measurement. It will match ``fsverity_enable_arg::hash_algorithm``.
+ digest. It will match ``fsverity_enable_arg::hash_algorithm``.
- ``digest_size`` will be the size of the digest in bytes, e.g. 32
for SHA-256. (This can be redundant with ``digest_algorithm``.)
- ``digest`` will be the actual bytes of the digest.
@@ -257,25 +258,24 @@
with EIO (for read()) or SIGBUS (for mmap() reads).
- If the sysctl "fs.verity.require_signatures" is set to 1 and the
- file's verity measurement is not signed by a key in the fs-verity
- keyring, then opening the file will fail. See `Built-in signature
- verification`_.
+ file is not signed by a key in the fs-verity keyring, then opening
+ the file will fail. See `Built-in signature verification`_.
Direct access to the Merkle tree is not supported. Therefore, if a
verity file is copied, or is backed up and restored, then it will lose
its "verity"-ness. fs-verity is primarily meant for files like
executables that are managed by a package manager.
-File measurement computation
-============================
+File digest computation
+=======================
This section describes how fs-verity hashes the file contents using a
-Merkle tree to produce the "file measurement" which cryptographically
-identifies the file contents. This algorithm is the same for all
-filesystems that support fs-verity.
+Merkle tree to produce the digest which cryptographically identifies
+the file contents. This algorithm is the same for all filesystems
+that support fs-verity.
Userspace only needs to be aware of this algorithm if it needs to
-compute the file measurement itself, e.g. in order to sign the file.
+compute fs-verity file digests itself, e.g. in order to sign files.
.. _fsverity_merkle_tree:
@@ -325,26 +325,22 @@
is exactly the top-level hash block of the first file. Ambiguities
also arise from the convention of padding to the next block boundary.
-To solve this problem, the verity file measurement is actually
-computed as a hash of the following structure, which contains the
-Merkle tree root hash as well as other fields such as the file size::
+To solve this problem, the fs-verity file digest is actually computed
+as a hash of the following structure, which contains the Merkle tree
+root hash as well as other fields such as the file size::
struct fsverity_descriptor {
__u8 version; /* must be 1 */
__u8 hash_algorithm; /* Merkle tree hash algorithm */
__u8 log_blocksize; /* log2 of size of data and tree blocks */
__u8 salt_size; /* size of salt in bytes; 0 if none */
- __le32 sig_size; /* must be 0 */
+ __le32 __reserved_0x04; /* must be 0 */
__le64 data_size; /* size of file the Merkle tree is built over */
__u8 root_hash[64]; /* Merkle tree root hash */
__u8 salt[32]; /* salt prepended to each hashed block */
__u8 __reserved[144]; /* must be 0's */
};
-Note that the ``sig_size`` field must be set to 0 for the purpose of
-computing the file measurement, even if a signature was provided (or
-will be provided) to `FS_IOC_ENABLE_VERITY`_.
-
Built-in signature verification
===============================
@@ -359,20 +355,20 @@
certificates from being added.
2. `FS_IOC_ENABLE_VERITY`_ accepts a pointer to a PKCS#7 formatted
- detached signature in DER format of the file measurement. On
- success, this signature is persisted alongside the Merkle tree.
+ detached signature in DER format of the file's fs-verity digest.
+ On success, this signature is persisted alongside the Merkle tree.
Then, any time the file is opened, the kernel will verify the
- file's actual measurement against this signature, using the
- certificates in the ".fs-verity" keyring.
+ file's actual digest against this signature, using the certificates
+ in the ".fs-verity" keyring.
3. A new sysctl "fs.verity.require_signatures" is made available.
When set to 1, the kernel requires that all verity files have a
- correctly signed file measurement as described in (2).
+ correctly signed digest as described in (2).
-File measurements must be signed in the following format, which is
-similar to the structure used by `FS_IOC_MEASURE_VERITY`_::
+fs-verity file digests must be signed in the following format, which
+is similar to the structure used by `FS_IOC_MEASURE_VERITY`_::
- struct fsverity_signed_digest {
+ struct fsverity_formatted_digest {
char magic[8]; /* must be "FSVerity" */
__le16 digest_algorithm;
__le16 digest_size;
@@ -421,8 +417,8 @@
ext4 also supports encryption, which can be used simultaneously with
fs-verity. In this case, the plaintext data is verified rather than
-the ciphertext. This is necessary in order to make the file
-measurement meaningful, since every file is encrypted differently.
+the ciphertext. This is necessary in order to make the fs-verity file
+digest meaningful, since every file is encrypted differently.
ext4 stores the verity metadata (Merkle tree and fsverity_descriptor)
past the end of the file, starting at the first 64K boundary beyond
@@ -592,8 +588,8 @@
:Q: Isn't fs-verity useless because the attacker can just modify the
hashes in the Merkle tree, which is stored on-disk?
:A: To verify the authenticity of an fs-verity file you must verify
- the authenticity of the "file measurement", which is basically the
- root hash of the Merkle tree. See `Use cases`_.
+ the authenticity of the "fs-verity file digest", which
+ incorporates the root hash of the Merkle tree. See `Use cases`_.
:Q: Isn't fs-verity useless because the attacker can just replace a
verity file with a non-verity one?
diff --git a/Documentation/filesystems/gfs2.rst b/Documentation/filesystems/gfs2.rst
index 8d1ab58..1bc48a1 100644
--- a/Documentation/filesystems/gfs2.rst
+++ b/Documentation/filesystems/gfs2.rst
@@ -1,53 +1,52 @@
.. SPDX-License-Identifier: GPL-2.0
-==================
-Global File System
-==================
+====================
+Global File System 2
+====================
-https://fedorahosted.org/cluster/wiki/HomePage
-
-GFS is a cluster file system. It allows a cluster of computers to
+GFS2 is a cluster file system. It allows a cluster of computers to
simultaneously use a block device that is shared between them (with FC,
-iSCSI, NBD, etc). GFS reads and writes to the block device like a local
+iSCSI, NBD, etc). GFS2 reads and writes to the block device like a local
file system, but also uses a lock module to allow the computers coordinate
their I/O so file system consistency is maintained. One of the nifty
-features of GFS is perfect consistency -- changes made to the file system
+features of GFS2 is perfect consistency -- changes made to the file system
on one machine show up immediately on all other machines in the cluster.
-GFS uses interchangeable inter-node locking mechanisms, the currently
+GFS2 uses interchangeable inter-node locking mechanisms, the currently
supported mechanisms are:
lock_nolock
- - allows gfs to be used as a local file system
+ - allows GFS2 to be used as a local file system
lock_dlm
- - uses a distributed lock manager (dlm) for inter-node locking.
+ - uses the distributed lock manager (dlm) for inter-node locking.
The dlm is found at linux/fs/dlm/
-Lock_dlm depends on user space cluster management systems found
+lock_dlm depends on user space cluster management systems found
at the URL above.
-To use gfs as a local file system, no external clustering systems are
+To use GFS2 as a local file system, no external clustering systems are
needed, simply::
$ mkfs -t gfs2 -p lock_nolock -j 1 /dev/block_device
$ mount -t gfs2 /dev/block_device /dir
-If you are using Fedora, you need to install the gfs2-utils package
-and, for lock_dlm, you will also need to install the cman package
-and write a cluster.conf as per the documentation. For F17 and above
-cman has been replaced by the dlm package.
+The gfs2-utils package is required on all cluster nodes and, for lock_dlm, you
+will also need the dlm and corosync user space utilities configured as per the
+documentation.
+
+gfs2-utils can be found at https://pagure.io/gfs2-utils
GFS2 is not on-disk compatible with previous versions of GFS, but it
is pretty close.
-The following man pages can be found at the URL above:
+The following man pages are available from gfs2-utils:
============ =============================================
fsck.gfs2 to repair a filesystem
gfs2_grow to expand a filesystem online
gfs2_jadd to add journals to a filesystem online
tunegfs2 to manipulate, examine and tune a filesystem
- gfs2_convert to convert a gfs filesystem to gfs2 in-place
+ gfs2_convert to convert a gfs filesystem to GFS2 in-place
mkfs.gfs2 to make a filesystem
============ =============================================
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index 98f59a8..7be9b46 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -113,7 +113,7 @@
sysv-fs
tmpfs
ubifs
- ubifs-authentication.rst
+ ubifs-authentication
udf
virtiofs
vfat
diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst
index d7f53d6..eb358a0 100644
--- a/Documentation/filesystems/mount_api.rst
+++ b/Documentation/filesystems/mount_api.rst
@@ -774,7 +774,7 @@
should just be set to lie inside the low-to-high range.
If all is good, true is returned. If the table is invalid, errors are
- logged to dmesg and false is returned.
+ logged to the kernel log buffer and false is returned.
* ::
@@ -782,7 +782,7 @@
This performs some validation checks on a parameter description. It
returns true if the description is good and false if it is not. It will
- log errors to dmesg if validation fails.
+ log errors to the kernel log buffer if validation fails.
* ::
diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst
index 33d588a..0e98edd 100644
--- a/Documentation/filesystems/nfs/exporting.rst
+++ b/Documentation/filesystems/nfs/exporting.rst
@@ -154,6 +154,11 @@
to find potential names, and matches inode numbers to find the correct
match.
+ flags
+ Some filesystems may need to be handled differently than others. The
+ export_operations struct also includes a flags field that allows the
+ filesystem to communicate such information to nfsd. See the Export
+ Operations Flags section below for more explanation.
A filehandle fragment consists of an array of 1 or more 4byte words,
together with a one byte "type".
@@ -163,3 +168,50 @@
nuls. Rather, the encode_fh routine should choose a "type" which
indicates the decode_fh how much of the filehandle is valid, and how
it should be interpreted.
+
+Export Operations Flags
+-----------------------
+In addition to the operation vector pointers, struct export_operations also
+contains a "flags" field that allows the filesystem to communicate to nfsd
+that it may want to do things differently when dealing with it. The
+following flags are defined:
+
+ EXPORT_OP_NOWCC - disable NFSv3 WCC attributes on this filesystem
+ RFC 1813 recommends that servers always send weak cache consistency
+ (WCC) data to the client after each operation. The server should
+ atomically collect attributes about the inode, do an operation on it,
+ and then collect the attributes afterward. This allows the client to
+ skip issuing GETATTRs in some situations but means that the server
+ is calling vfs_getattr for almost all RPCs. On some filesystems
+ (particularly those that are clustered or networked) this is expensive
+ and atomicity is difficult to guarantee. This flag indicates to nfsd
+ that it should skip providing WCC attributes to the client in NFSv3
+ replies when doing operations on this filesystem. Consider enabling
+ this on filesystems that have an expensive ->getattr inode operation,
+ or when atomicity between pre and post operation attribute collection
+ is impossible to guarantee.
+
+ EXPORT_OP_NOSUBTREECHK - disallow subtree checking on this fs
+ Many NFS operations deal with filehandles, which the server must then
+ vet to ensure that they live inside of an exported tree. When the
+ export consists of an entire filesystem, this is trivial. nfsd can just
+ ensure that the filehandle live on the filesystem. When only part of a
+ filesystem is exported however, then nfsd must walk the ancestors of the
+ inode to ensure that it's within an exported subtree. This is an
+ expensive operation and not all filesystems can support it properly.
+ This flag exempts the filesystem from subtree checking and causes
+ exportfs to get back an error if it tries to enable subtree checking
+ on it.
+
+ EXPORT_OP_CLOSE_BEFORE_UNLINK - always close cached files before unlinking
+ On some exportable filesystems (such as NFS) unlinking a file that
+ is still open can cause a fair bit of extra work. For instance,
+ the NFS client will do a "sillyrename" to ensure that the file
+ sticks around while it's still open. When reexporting, that open
+ file is held by nfsd so we usually end up doing a sillyrename, and
+ then immediately deleting the sillyrenamed file just afterward when
+ the link count actually goes to zero. Sometimes this delete can race
+ with other operations (for instance an rmdir of the parent directory).
+ This flag causes nfsd to close any open files for this inode _before_
+ calling into the vfs to do an unlink or a rename that would replace
+ an existing file.
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index 580ab9a..587a939 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -97,11 +97,13 @@
requirement that the root of a filesystem be given for either upper or
lower.
-The lower filesystem can be any filesystem supported by Linux and does
-not need to be writable. The lower filesystem can even be another
-overlayfs. The upper filesystem will normally be writable and if it
-is it must support the creation of trusted.* extended attributes, and
-must provide valid d_type in readdir responses, so NFS is not suitable.
+A wide range of filesystems supported by Linux can be the lower filesystem,
+but not all filesystems that are mountable by Linux have the features
+needed for OverlayFS to work. The lower filesystem does not need to be
+writable. The lower filesystem can even be another overlayfs. The upper
+filesystem will normally be writable and if it is it must support the
+creation of trusted.* and/or user.* extended attributes, and must provide
+valid d_type in readdir responses, so NFS is not suitable.
A read-only overlay of two read-only filesystems may use any
filesystem type.
@@ -467,14 +469,18 @@
Changes to underlying filesystems
---------------------------------
-Offline changes, when the overlay is not mounted, are allowed to either
-the upper or the lower trees.
-
Changes to the underlying filesystems while part of a mounted overlay
filesystem are not allowed. If the underlying filesystem is changed,
the behavior of the overlay is undefined, though it will not result in
a crash or deadlock.
+Offline changes, when the overlay is not mounted, are allowed to the
+upper tree. Offline changes to the lower tree are only allowed if the
+"metadata only copy up", "inode index", and "redirect_dir" features
+have not been used. If the lower tree is modified and any of these
+features has been used, the behavior of the overlay is undefined,
+though it will not result in a crash or deadlock.
+
When the overlay NFS export feature is enabled, overlay filesystems
behavior on offline changes of the underlying lower layer is different
than the behavior when NFS export is disabled.
@@ -563,6 +569,11 @@
Note: the mount options index=off,nfs_export=on are conflicting for a
read-write mount and will result in an error.
+Note: the mount option uuid=off can be used to replace UUID of the underlying
+filesystem in file handles with null, and effectively disable UUID checks. This
+can be useful in case the underlying disk is copied and the UUID of this copy
+is changed. This is only applicable if all lower/upper/work directories are on
+the same filesystem, otherwise it will fallback to normal behaviour.
Volatile mount
--------------
@@ -583,6 +594,15 @@
not crashed and contents of upperdir are intact, The "volatile" directory
can be removed.
+
+User xattr
+----------
+
+The the "-o userxattr" mount option forces overlayfs to use the
+"user.overlay." xattr namespace instead of "trusted.overlay.". This is
+useful for unprivileged mounting of overlayfs.
+
+
Testsuite
---------
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 533c79e..2fa69f7 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -210,6 +210,7 @@
NoNewPrivs: 0
Seccomp: 0
Speculation_Store_Bypass: thread vulnerable
+ SpeculationIndirectBranch: conditional enabled
voluntary_ctxt_switches: 0
nonvoluntary_ctxt_switches: 1
@@ -292,6 +293,7 @@
NoNewPrivs no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...)
Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
Speculation_Store_Bypass speculative store bypass mitigation status
+ SpeculationIndirectBranch indirect branch speculation mode
Cpus_allowed mask of CPUs on which this process may run
Cpus_allowed_list Same as previous, but in "list format"
Mems_allowed mask of memory nodes allowed to this process
@@ -546,6 +548,7 @@
nh no huge page advise flag
mg mergable advise flag
bt arm64 BTI guarded page
+ mt arm64 MTE allocation tags are enabled
== =======================================
Note that there is no guarantee that every flag and associated mnemonic will
diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst
index c44f8b1..0408c24 100644
--- a/Documentation/filesystems/tmpfs.rst
+++ b/Documentation/filesystems/tmpfs.rst
@@ -4,7 +4,7 @@
Tmpfs
=====
-Tmpfs is a file system which keeps all files in virtual memory.
+Tmpfs is a file system which keeps all of its files in virtual memory.
Everything in tmpfs is temporary in the sense that no files will be
@@ -35,7 +35,7 @@
memory.
This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not
- set, the user visible part of tmpfs is not build. But the internal
+ set, the user visible part of tmpfs is not built. But the internal
mechanisms are always present.
2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
@@ -50,7 +50,7 @@
This mount is _not_ needed for SYSV shared memory. The internal
mount is used for that. (In the 2.3 kernel versions it was
necessary to mount the predecessor of tmpfs (shm fs) to use SYSV
- shared memory)
+ shared memory.)
3) Some people (including me) find it very convenient to mount it
e.g. on /tmp and /var/tmp and have a big swap partition. And now
@@ -83,7 +83,7 @@
if nr_inodes=0, inodes will not be limited. It is generally unwise to
mount with such options, since it allows any user with write access to
use up all the memory on the machine; but enhances the scalability of
-that instance in a system with many cpus making intensive use of it.
+that instance in a system with many CPUs making intensive use of it.
tmpfs has a mount option to set the NUMA memory allocation policy for
diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst
index aba1e9a..b99fff8 100644
--- a/Documentation/firmware-guide/acpi/dsd/leds.rst
+++ b/Documentation/firmware-guide/acpi/dsd/leds.rst
@@ -90,10 +90,10 @@
References
==========
-[1] Device tree. <URL:https://www.devicetree.org>, referenced 2019-02-21.
+[1] Device tree. https://www.devicetree.org, referenced 2019-02-21.
[2] Advanced Configuration and Power Interface Specification.
- <URL:https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf>,
+ https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf,
referenced 2019-02-21.
[3] Documentation/devicetree/bindings/leds/common.txt
@@ -101,11 +101,11 @@
[4] Documentation/devicetree/bindings/media/video-interfaces.txt
[5] Device Properties UUID For _DSD.
- <URL:https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
+ https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
referenced 2019-02-21.
[6] Hierarchical Data Extension UUID For _DSD.
- <URL:https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
+ https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf,
referenced 2019-02-21.
[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index c13fee8..9f0d5c8 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -461,3 +461,157 @@
property returned by it is meaningless.
Refer to :doc:`DSD-properties-rules` for more information.
+
+PCI hierarchy representation
+============================
+
+Sometimes could be useful to enumerate a PCI device, knowing its position on the
+PCI bus.
+
+For example, some systems use PCI devices soldered directly on the mother board,
+in a fixed position (ethernet, Wi-Fi, serial ports, etc.). In this conditions it
+is possible to refer to these PCI devices knowing their position on the PCI bus
+topology.
+
+To identify a PCI device, a complete hierarchical description is required, from
+the chipset root port to the final device, through all the intermediate
+bridges/switches of the board.
+
+For example, let us assume to have a system with a PCIe serial port, an
+Exar XR17V3521, soldered on the main board. This UART chip also includes
+16 GPIOs and we want to add the property ``gpio-line-names`` [1] to these pins.
+In this case, the ``lspci`` output for this component is::
+
+ 07:00.0 Serial controller: Exar Corp. XR17V3521 Dual PCIe UART (rev 03)
+
+The complete ``lspci`` output (manually reduced in length) is::
+
+ 00:00.0 Host bridge: Intel Corp... Host Bridge (rev 0d)
+ ...
+ 00:13.0 PCI bridge: Intel Corp... PCI Express Port A #1 (rev fd)
+ 00:13.1 PCI bridge: Intel Corp... PCI Express Port A #2 (rev fd)
+ 00:13.2 PCI bridge: Intel Corp... PCI Express Port A #3 (rev fd)
+ 00:14.0 PCI bridge: Intel Corp... PCI Express Port B #1 (rev fd)
+ 00:14.1 PCI bridge: Intel Corp... PCI Express Port B #2 (rev fd)
+ ...
+ 05:00.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05)
+ 06:01.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05)
+ 06:02.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05)
+ 06:03.0 PCI bridge: Pericom Semiconductor Device 2404 (rev 05)
+ 07:00.0 Serial controller: Exar Corp. XR17V3521 Dual PCIe UART (rev 03) <-- Exar
+ ...
+
+The bus topology is::
+
+ -[0000:00]-+-00.0
+ ...
+ +-13.0-[01]----00.0
+ +-13.1-[02]----00.0
+ +-13.2-[03]--
+ +-14.0-[04]----00.0
+ +-14.1-[05-09]----00.0-[06-09]--+-01.0-[07]----00.0 <-- Exar
+ | +-02.0-[08]----00.0
+ | \-03.0-[09]--
+ ...
+ \-1f.1
+
+To describe this Exar device on the PCI bus, we must start from the ACPI name
+of the chipset bridge (also called "root port") with address::
+
+ Bus: 0 - Device: 14 - Function: 1
+
+To find this information is necessary disassemble the BIOS ACPI tables, in
+particular the DSDT (see also [2])::
+
+ mkdir ~/tables/
+ cd ~/tables/
+ acpidump > acpidump
+ acpixtract -a acpidump
+ iasl -e ssdt?.* -d dsdt.dat
+
+Now, in the dsdt.dsl, we have to search the device whose address is related to
+0x14 (device) and 0x01 (function). In this case we can find the following
+device::
+
+ Scope (_SB.PCI0)
+ {
+ ... other definitions follow ...
+ Device (RP02)
+ {
+ Method (_ADR, 0, NotSerialized) // _ADR: Address
+ {
+ If ((RPA2 != Zero))
+ {
+ Return (RPA2) /* \RPA2 */
+ }
+ Else
+ {
+ Return (0x00140001)
+ }
+ }
+ ... other definitions follow ...
+
+and the _ADR method [3] returns exactly the device/function couple that
+we are looking for. With this information and analyzing the above ``lspci``
+output (both the devices list and the devices tree), we can write the following
+ACPI description for the Exar PCIe UART, also adding the list of its GPIO line
+names::
+
+ Scope (_SB.PCI0.RP02)
+ {
+ Device (BRG1) //Bridge
+ {
+ Name (_ADR, 0x0000)
+
+ Device (BRG2) //Bridge
+ {
+ Name (_ADR, 0x00010000)
+
+ Device (EXAR)
+ {
+ Name (_ADR, 0x0000)
+
+ Name (_DSD, Package ()
+ {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package ()
+ {
+ Package ()
+ {
+ "gpio-line-names",
+ Package ()
+ {
+ "mode_232",
+ "mode_422",
+ "mode_485",
+ "misc_1",
+ "misc_2",
+ "misc_3",
+ "",
+ "",
+ "aux_1",
+ "aux_2",
+ "aux_3",
+ }
+ }
+ }
+ })
+ }
+ }
+ }
+ }
+
+The location "_SB.PCI0.RP02" is obtained by the above investigation in the
+dsdt.dsl table, whereas the device names "BRG1", "BRG2" and "EXAR" are
+created analyzing the position of the Exar UART in the PCI bus topology.
+
+References
+==========
+
+[1] Documentation/firmware-guide/acpi/gpio-properties.rst
+
+[2] Documentation/admin-guide/acpi/initrd_table_override.rst
+
+[3] ACPI Specifications, Version 6.3 - Paragraph 6.1.1 _ADR Address)
+ https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf,
+ referenced 2020-11-18
diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
index 59aad61..b36aa3e 100644
--- a/Documentation/firmware-guide/acpi/gpio-properties.rst
+++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
@@ -133,7 +133,61 @@
- gpio-line-names
-Example::
+The ``gpio-line-names`` declaration is a list of strings ("names"), which
+describes each line/pin of a GPIO controller/expander. This list, contained in
+a package, must be inserted inside the GPIO controller declaration of an ACPI
+table (typically inside the DSDT). The ``gpio-line-names`` list must respect the
+following rules (see also the examples):
+
+ - the first name in the list corresponds with the first line/pin of the GPIO
+ controller/expander
+ - the names inside the list must be consecutive (no "holes" are permitted)
+ - the list can be incomplete and can end before the last GPIO line: in
+ other words, it is not mandatory to fill all the GPIO lines
+ - empty names are allowed (two quotation marks ``""`` correspond to an empty
+ name)
+
+Example of a GPIO controller of 16 lines, with an incomplete list with two
+empty names::
+
+ Package () {
+ "gpio-line-names",
+ Package () {
+ "pin_0",
+ "pin_1",
+ "",
+ "",
+ "pin_3",
+ "pin_4_push_button",
+ }
+ }
+
+At runtime, the above declaration produces the following result (using the
+"libgpiod" tools)::
+
+ root@debian:~# gpioinfo gpiochip4
+ gpiochip4 - 16 lines:
+ line 0: "pin_0" unused input active-high
+ line 1: "pin_1" unused input active-high
+ line 2: unnamed unused input active-high
+ line 3: unnamed unused input active-high
+ line 4: "pin_3" unused input active-high
+ line 5: "pin_4_push_button" unused input active-high
+ line 6: unnamed unused input active-high
+ line 7 unnamed unused input active-high
+ line 8: unnamed unused input active-high
+ line 9: unnamed unused input active-high
+ line 10: unnamed unused input active-high
+ line 11: unnamed unused input active-high
+ line 12: unnamed unused input active-high
+ line 13: unnamed unused input active-high
+ line 14: unnamed unused input active-high
+ line 15: unnamed unused input active-high
+ root@debian:~# gpiofind pin_4_push_button
+ gpiochip4 5
+ root@debian:~#
+
+Another example::
Package () {
"gpio-line-names",
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 9abee15..21be6de 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -182,11 +182,11 @@
respectively.
When the last reference to a GEM object is released the GEM core calls
-the :c:type:`struct drm_driver <drm_driver>` gem_free_object_unlocked
+the :c:type:`struct drm_gem_object_funcs <gem_object_funcs>` free
operation. That operation is mandatory for GEM-enabled drivers and must
free the GEM object and all associated resources.
-void (\*gem_free_object) (struct drm_gem_object \*obj); Drivers are
+void (\*free) (struct drm_gem_object \*obj); Drivers are
responsible for freeing all GEM object resources. This includes the
resources created by the GEM core, which need to be released with
drm_gem_object_release().
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index cff1f15..20868f3 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -118,6 +118,12 @@
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c
:internal:
+Asynchronous Page Flip
+----------------------
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c
+ :doc: asynchronous flip implementation
+
Output Probing
--------------
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b0ea17d..009d8e6 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -105,6 +105,10 @@
One issue with the helpers is that they require that drivers handle completion
events for atomic commits correctly. But fixing these bugs is good anyway.
+Somewhat related is the legacy_cursor_update hack, which should be replaced with
+the new atomic_async_check/commit functionality in the helpers in drivers that
+still look at that flag.
+
Contact: Daniel Vetter, respective driver maintainers
Level: Advanced
@@ -149,7 +153,7 @@
``unreference_locked`` depending upon context.
Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
-and there's a ``gem_free_object_unlocked`` callback for any drivers which are
+and there's a GEM object ``free`` callback for any drivers which are
entirely ``struct_mutex`` free.
For drivers that need ``struct_mutex`` it should be replaced with a driver-
@@ -197,13 +201,28 @@
------------------------------------------------
Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
-atomic modesetting and GEM vmap support. Current generic fbdev emulation
-expects the framebuffer in system memory (or system-like memory).
+atomic modesetting and GEM vmap support. Historically, generic fbdev emulation
+expected the framebuffer in system memory or system-like memory. By employing
+struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
+as well.
Contact: Maintainer of the driver you plan to convert
Level: Intermediate
+Reimplement functions in drm_fbdev_fb_ops without fbdev
+-------------------------------------------------------
+
+A number of callback functions in drm_fbdev_fb_ops could benefit from
+being rewritten without dependencies on the fbdev module. Some of the
+helpers could further benefit from using struct dma_buf_map instead of
+raw pointers.
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
+
+Level: Advanced
+
+
drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
-----------------------------------------------------------------
@@ -273,6 +292,27 @@
Level: Advanced
+Garbage collect fbdev scrolling acceleration
+--------------------------------------------
+
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
+
+- lots of code in fbcon.c
+
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
+ directly instead of the function table (with a switch on p->rotate)
+
+- fb_copyarea is unused after this, and can be deleted from all drivers
+
+Note that not all acceleration code can be deleted, since clearing and cursor
+support is still accelerated, which might be good candidates for further
+deletion projects.
+
+Contact: Daniel Vetter
+
+Level: Intermediate
+
idr_init_base()
---------------
@@ -289,11 +329,8 @@
---------------------------
GEM objects can now have a function table instead of having the callbacks on the
-DRM driver struct. This is now the preferred way and drivers can be moved over.
-
-We also need a 2nd version of the CMA define that doesn't require the
-vmapping to be present (different hook for prime importing). Plus this needs to
-be rolled out to all drivers using their own implementations, too.
+DRM driver struct. This is now the preferred way. Callbacks in drivers have been
+converted, except for struct drm_driver.gem_prime_mmap.
Level: Intermediate
@@ -449,6 +486,24 @@
Level: Intermediate
+Use struct dma_buf_map throughout codebase
+------------------------------------------
+
+Pointers to shared device memory are stored in struct dma_buf_map. Each
+instance knows whether it refers to system or I/O memory. Most of the DRM-wide
+interface have been converted to use struct dma_buf_map, but implementations
+often still use raw pointers.
+
+The task is to use struct dma_buf_map where it makes sense.
+
+* Memory managers should use struct dma_buf_map for dma-buf-imported buffers.
+* TTM might benefit from using struct dma_buf_map internally.
+* Framebuffer copying and blitting helpers should operate on struct dma_buf_map.
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter
+
+Level: Intermediate
+
Core refactorings
=================
@@ -518,9 +573,6 @@
this (together with the drm_minor->drm_device move) would allow us to remove
debugfs_init.
-- Drop the return code and error checking from all debugfs functions. Greg KH is
- working on this already.
-
Contact: Daniel Vetter
Level: Intermediate
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 61586fc..13bab1d 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -10,36 +10,24 @@
TODO
====
-CRC API Improvements
---------------------
+If you want to do any of the items listed below, please share your interest
+with VKMS maintainers.
-- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
+IGT better support
+------------------
-- Use the alpha value to blend vaddr_src with vaddr_dst instead of
- overwriting it in ``blend()``.
+- Investigate: (1) test cases on kms_plane that are failing due to timeout on
+ capturing CRC; (2) when running kms_flip test cases in sequence, some
+ successful individual test cases are failing randomly.
-- Add igt test to check cleared alpha value for XRGB plane format.
-
-- Add igt test to check extreme alpha values i.e. fully opaque and fully
- transparent (intermediate values are affected by hw-specific rounding modes).
-
-Runtime Configuration
----------------------
-
-We want to be able to reconfigure vkms instance without having to reload the
-module. Use/Test-cases:
-
-- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of
- compositors).
-
-- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
- them first).
-
-- Change output configuration: Plug/unplug screens, change EDID, allow changing
- the refresh rate.
-
-The currently proposed solution is to expose vkms configuration through
-configfs. All existing module options should be supported through configfs too.
+- VKMS already has support for vblanks simulated via hrtimers, which can be
+ tested with kms_flip test; in some way, we can say that VKMS already mimics
+ the real hardware vblank. However, we also have virtual hardware that does
+ not support vblank interrupt and completes page_flip events right away; in
+ this case, compositor developers may end up creating a busy loop on virtual
+ hardware. It would be useful to support Virtual Hardware behavior in VKMS
+ because this can help compositor developers to test their features in
+ multiple scenarios.
Add Plane Features
------------------
@@ -55,33 +43,49 @@
- Additional buffer formats, especially YUV formats for video like NV12.
Low/high bpp RGB formats would also be interesting.
-- Async updates (currently only possible on cursor plane using the legacy cursor
- api).
+- Async updates (currently only possible on cursor plane using the legacy
+ cursor api).
-For all of these, we also want to review the igt test coverage and make sure all
-relevant igt testcases work on vkms.
-
-Writeback support
------------------
-
-Currently vkms only computes a CRC for each frame. Once we have additional plane
-features, we could write back the entire composited frame, and expose it as:
-
-- Writeback connector. This is useful for testing compositors if you don't have
- hardware with writeback support.
-
-- As a v4l device. This is useful for debugging compositors on special vkms
- configurations, so that developers see what's really going on.
+For all of these, we also want to review the igt test coverage and make sure
+all relevant igt testcases work on vkms.
Prime Buffer Sharing
--------------------
-We already have vgem, which is a gem driver for testing rendering, similar to
-how vkms is for testing the modeset side. Adding buffer sharing support to vkms
-allows us to test them together, to test synchronization and lots of other
-features. Also, this allows compositors to test whether they work correctly on
-SoC chips, where the display and rendering is very often split between 2
-drivers.
+- Syzbot report - WARNING in vkms_gem_free_object:
+ https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
+
+Runtime Configuration
+---------------------
+
+We want to be able to reconfigure vkms instance without having to reload the
+module. Use/Test-cases:
+
+- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling
+ of compositors).
+
+- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
+ them first).
+
+- Change output configuration: Plug/unplug screens, change EDID, allow changing
+ the refresh rate.
+
+The currently proposed solution is to expose vkms configuration through
+configfs. All existing module options should be supported through configfs
+too.
+
+Writeback support
+-----------------
+
+- The writeback and CRC capture operations share the use of composer_enabled
+ boolean to ensure vblanks. Probably, when these operations work together,
+ composer_enabled needs to refcounting the composer state to proper work.
+
+- Add support for cloned writeback outputs and related test cases using a
+ cloned output in the IGT kms_writeback.
+
+- As a v4l device. This is useful for debugging compositors on special vkms
+ configurations, so that developers see what's really going on.
Output Features
---------------
@@ -93,7 +97,10 @@
- Add support for link status, so that compositors can validate their runtime
fallbacks when e.g. a Display Port link goes bad.
-- All the hotplug handling describe under "Runtime Configuration".
+CRC API Improvements
+--------------------
+
+- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
Atomic Check using eBPF
-----------------------
diff --git a/Documentation/hid/amd-sfh-hid.rst b/Documentation/hid/amd-sfh-hid.rst
new file mode 100644
index 0000000..1f2fe29
--- /dev/null
+++ b/Documentation/hid/amd-sfh-hid.rst
@@ -0,0 +1,145 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+AMD Sensor Fusion Hub
+=====================
+AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen based platforms.
+The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus.
+In terms of architecture it resembles ISH, however the major difference is all
+the HID reports are generated as part of the kernel driver.
+
+1. Block Diagram
+================
+
+::
+
+ ---------------------------------
+ | HID User Space Applications |
+ - -------------------------------
+
+ ---------------------------------------------
+ ---------------------------------
+ | HID Core |
+ ---------------------------------
+
+ ---------------------------------
+ | AMD HID Transport |
+ ---------------------------------
+
+ --------------------------------
+ | AMD HID Client |
+ | with HID Report Generator|
+ --------------------------------
+
+ --------------------------------
+ | AMD MP2 PCIe Driver |
+ --------------------------------
+ OS
+ ---------------------------------------------
+ Hardware + Firmware
+ --------------------------------
+ | SFH MP2 Processor |
+ --------------------------------
+
+
+AMD HID Transport Layer
+-----------------------
+AMD SFH transport is also implemented as a bus. Each client application executing in the AMD MP2 is
+registered as a device on this bus. Here: MP2 which is an ARM core connected to x86 for processing
+sensor data. The layer, which binds each device (AMD SFH HID driver) identifies the device type and
+registers with the hid core. Transport layer attach a constant "struct hid_ll_driver" object with
+each device. Once a device is registered with HID core, the callbacks provided via this struct are
+used by HID core to communicate with the device. AMD HID Transport layer implements the synchronous calls.
+
+AMD HID Client Layer
+--------------------
+This layer is responsible to implement HID request and descriptors. As firmware is OS agnostic, HID
+client layer fills the HID request structure and descriptors. HID client layer is complex as it is
+interface between MP2 PCIe layer and HID. HID client layer initialized the MP2 PCIe layer and holds
+the instance of MP2 layer. It identifies the number of sensors connected using MP2-PCIe layer. Base
+on that allocates the DRAM address for each and every sensor and pass it to MP2-PCIe driver.On
+enumeration of each the sensor, client layer fills the HID Descriptor structure and HID input repor
+structure. HID Feature report structure is optional. The report descriptor structure varies from
+sensor to sensor.
+
+AMD MP2 PCIe layer
+------------------
+MP2 PCIe Layer is responsible for making all transactions with the firmware over PCIe.
+The connection establishment between firmware and PCIe happens here.
+
+The communication between X86 and MP2 is split into three parts.
+1. Command transfer via the C2P mailbox registers.
+2. Data transfer via DRAM.
+3. Supported sensor info via P2C registers.
+
+Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message registers generate
+interrupt to MP2. The client layer allocates the physical memory and the same is sent to MP2 via
+the PCI layer. MP2 firmware writes the command output to the access DRAM memory which the client
+layer has allocated. Firmware always writes minimum of 32 bytes into DRAM. So as a protocol driver
+shall allocate minimum of 32 bytes DRAM space.
+
+Enumeration and Probing flow
+----------------------------
+::
+
+ HID AMD AMD AMD -PCIe MP2
+ Core Transport Client layer layer FW
+ | | | | |
+ | | | on Boot Driver Loaded |
+ | | | | |
+ | | | MP2-PCIe Int |
+ | | | | |
+ | | |---Get Number of sensors-> | |
+ | | | Read P2C |
+ | | | Register |
+ | | | | |
+ | | | Loop(for No of Sensors) | |
+ | | |----------------------| | |
+ | | | Create HID Descriptor| | |
+ | | | Create Input report | | |
+ | | | Descriptor Map | | |
+ | | | the MP2 FW Index to | | |
+ | | | HID Index | | |
+ | | | Allocate the DRAM | Enable |
+ | | | address | Sensors |
+ | | |----------------------| | |
+ | | HID transport| | Enable |
+ | |<--Probe------| |---Sensor CMD--> |
+ | | Create the | | |
+ | | HID device | | |
+ | | (MFD) | | |
+ | | by Populating| | |
+ | | the HID | | |
+ | | ll_driver | | |
+ | HID | | | |
+ | add | | | |
+ |Device | | | |
+ |<------------- | | | |
+
+
+Data Flow from Application to the AMD SFH Driver
+------------------------------------------------
+
+::
+
+ | | | | |
+ | | | | |
+ | | | | |
+ | | | | |
+ | | | | |
+ |HID_req | | | |
+ |get_report | | | |
+ |------------->| | | |
+ | | HID_get_input| | |
+ | | report | | |
+ | |------------->|------------------------| | |
+ | | | Read the DRAM data for| | |
+ | | | requested sensor and | | |
+ | | | create the HID input | | |
+ | | | report | | |
+ | | |------------------------| | |
+ | |Data received | | |
+ | | in HID report| | |
+ To |<-------------|<-------------| | |
+ Applications| | | | |
+ <-------| | | | |
diff --git a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst
index 4a4a0ba..f41c1f0 100644
--- a/Documentation/hid/hidraw.rst
+++ b/Documentation/hid/hidraw.rst
@@ -123,8 +123,49 @@
This ioctl will request a feature report from the device using the control
endpoint. The first byte of the supplied buffer should be set to the report
number of the requested report. For devices which do not use numbered
-reports, set the first byte to 0. The report will be returned starting at
-the first byte of the buffer (ie: the report number is not returned).
+reports, set the first byte to 0. The returned report buffer will contain the
+report number in the first byte, followed by the report data read from the
+device. For devices which do not use numbered reports, the report data will
+begin at the first byte of the returned buffer.
+
+HIDIOCSINPUT(len):
+ Send an Input Report
+
+This ioctl will send an input report to the device, using the control endpoint.
+In most cases, setting an input HID report on a device is meaningless and has
+no effect, but some devices may choose to use this to set or reset an initial
+state of a report. The format of the buffer issued with this report is identical
+to that of HIDIOCSFEATURE.
+
+HIDIOCGINPUT(len):
+ Get an Input Report
+
+This ioctl will request an input report from the device using the control
+endpoint. This is slower on most devices where a dedicated In endpoint exists
+for regular input reports, but allows the host to request the value of a
+specific report number. Typically, this is used to request the initial states of
+an input report of a device, before an application listens for normal reports via
+the regular device read() interface. The format of the buffer issued with this report
+is identical to that of HIDIOCGFEATURE.
+
+HIDIOCSOUTPUT(len):
+ Send an Output Report
+
+This ioctl will send an output report to the device, using the control endpoint.
+This is slower on most devices where a dedicated Out endpoint exists for regular
+output reports, but is added for completeness. Typically, this is used to set
+the initial states of an output report of a device, before an application sends
+updates via the regular device write() interface. The format of the buffer issued
+with this report is identical to that of HIDIOCSFEATURE.
+
+HIDIOCGOUTPUT(len):
+ Get an Output Report
+
+This ioctl will request an output report from the device using the control
+endpoint. Typically, this is used to retrive the initial state of
+an output report of a device, before an application updates it as necessary either
+via a HIDIOCSOUTPUT request, or the regular device write() interface. The format
+of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
Example
-------
diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst
index 737d66d..e50f513 100644
--- a/Documentation/hid/index.rst
+++ b/Documentation/hid/index.rst
@@ -16,3 +16,4 @@
hid-alps
intel-ish-hid
+ amd-sfh-hid
diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst
index ce6528f..804590e 100644
--- a/Documentation/hwmon/adm1275.rst
+++ b/Documentation/hwmon/adm1275.rst
@@ -83,7 +83,7 @@
and will typically have to be scaled.
The shunt value in micro-ohms can be set via device tree at compile-time. Please
-refer to the Documentation/devicetree/bindings/hwmon/adm1275.txt for bindings
+refer to the Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml for bindings
if the device tree is used.
Platform data support
diff --git a/Documentation/hwmon/amd_energy.rst b/Documentation/hwmon/amd_energy.rst
index 86e4ebc..9d58cd5 100644
--- a/Documentation/hwmon/amd_energy.rst
+++ b/Documentation/hwmon/amd_energy.rst
@@ -5,7 +5,9 @@
Supported chips:
-* AMD Family 17h Processors
+* AMD Family 17h Processors: Model 30h
+
+* AMD Family 19h Processors: Model 01h
Prefix: 'amd_energy'
@@ -112,3 +114,6 @@
energy[N]_input EsocketX Socket Energy X = [0] to [nr_socks -1]
Measured input socket energy
=============== ======== ======================================
+
+Note: To address CVE-2020-12912, the visibility of the energy[N]_input
+attributes is restricted to owner and groups only.
diff --git a/Documentation/hwmon/corsair-psu.rst b/Documentation/hwmon/corsair-psu.rst
new file mode 100644
index 0000000..396b95c
--- /dev/null
+++ b/Documentation/hwmon/corsair-psu.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver corsair-psu
+=========================
+
+Supported devices:
+
+* Corsair Power Supplies
+
+ Corsair HX550i
+
+ Corsair HX650i
+
+ Corsair HX750i
+
+ Corsair HX850i
+
+ Corsair HX1000i
+
+ Corsair HX1200i
+
+ Corsair RM550i
+
+ Corsair RM650i
+
+ Corsair RM750i
+
+ Corsair RM850i
+
+ Corsair RM1000i
+
+Author: Wilken Gottwalt
+
+Description
+-----------
+
+This driver implements the sysfs interface for the Corsair PSUs with a HID protocol
+interface of the HXi and RMi series.
+These power supplies provide access to a micro-controller with 2 attached
+temperature sensors, 1 fan rpm sensor, 4 sensors for volt levels, 4 sensors for
+power usage and 4 sensors for current levels and addtional non-sensor information
+like uptimes.
+
+Sysfs entries
+-------------
+
+======================= ========================================================
+curr1_input Total current usage
+curr2_input Current on the 12v psu rail
+curr3_input Current on the 5v psu rail
+curr4_input Current on the 3.3v psu rail
+fan1_input RPM of psu fan
+in0_input Voltage of the psu ac input
+in1_input Voltage of the 12v psu rail
+in2_input Voltage of the 5v psu rail
+in3_input Voltage of the 3.3 psu rail
+power1_input Total power usage
+power2_input Power usage of the 12v psu rail
+power3_input Power usage of the 5v psu rail
+power4_input Power usage of the 3.3v psu rail
+temp1_input Temperature of the psu vrm component
+temp2_input Temperature of the psu case
+======================= ========================================================
+
+Usage Notes
+-----------
+
+It is an USB HID device, so it is auto-detected and supports hot-swapping.
+
+Flickering values in the rail voltage levels can be an indicator for a failing
+PSU. The driver also provides some additional useful values via debugfs, which
+do not fit into the hwmon class.
+
+Debugfs entries
+---------------
+
+======================= ========================================================
+uptime Current uptime of the psu
+uptime_total Total uptime of the psu
+vendor Vendor name of the psu
+product Product name of the psu
+======================= ========================================================
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index b797db7..fcb870c 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -49,6 +49,7 @@
bt1-pvt
coretemp
corsair-cpro
+ corsair-psu
da9052
da9055
dell-smm-hwmon
@@ -100,6 +101,7 @@
lm95234
lm95245
lochnagar
+ ltc2992
ltc2945
ltc2947
ltc2978
@@ -110,6 +112,7 @@
ltc4245
ltc4260
ltc4261
+ max127
max16064
max16065
max1619
@@ -144,11 +147,14 @@
pc87360
pc87427
pcf8591
+ pm6764tr
pmbus
powr1220
pxe1610
pwm-fan
+ q54sj108a2
raspberrypi-hwmon
+ sbtsi_temp
sch5627
sch5636
scpi-hwmon
diff --git a/Documentation/hwmon/ltc2992.rst b/Documentation/hwmon/ltc2992.rst
new file mode 100644
index 0000000..46aa1aa
--- /dev/null
+++ b/Documentation/hwmon/ltc2992.rst
@@ -0,0 +1,56 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver ltc2992
+=====================
+
+Supported chips:
+ * Linear Technology LTC2992
+ Prefix: 'ltc2992'
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2992.pdf
+
+Author: Alexandru Tachici <alexandru.tachici@analog.com>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Linear Technology LTC2992 power monitor.
+
+LTC2992 is a rail-to-rail system monitor that measures current,
+voltage, and power of two supplies.
+
+Two ADCs simultaneously measure each supply’s current. A third ADC monitors
+the input voltages and four auxiliary external voltages.
+
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write,
+all other attributes are read-only.
+
+in_reset_history Reset all highest/lowest values.
+
+inX_input Measured voltage.
+inX_lowest Minimum measured voltage.
+inX_highest Maximum measured voltage.
+inX_min Minimum voltage allowed.
+inX_max Maximum voltage allowed.
+inX_min_alarm An undervoltage occurred. Cleared on read.
+inX_max_alarm An overvoltage occurred. Cleared on read.
+
+currX_input Measured current.
+currX_lowest Minimum measured current.
+currX_highest Maximum measured current.
+currX_min Minimum current allowed.
+currX_max Maximum current allowed.
+currX_min_alarm An undercurrent occurred. Cleared on read.
+currX_max_alarm An overcurrent occurred. Cleared on read.
+
+powerX_input Measured power.
+powerX_input_lowest Minimum measured voltage.
+powerX_input_highest Maximum measured voltage.
+powerX_min Minimum power.
+powerX_max Maximum power.
+powerX_min_alarm An underpower occurred. Cleared on read.
+powerX_max_alarm An overpower occurred. Cleared on read.
diff --git a/Documentation/hwmon/max127.rst b/Documentation/hwmon/max127.rst
new file mode 100644
index 0000000..dc192dd
--- /dev/null
+++ b/Documentation/hwmon/max127.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver max127
+====================
+
+Author:
+
+ * Tao Ren <rentao.bupt@gmail.com>
+
+Supported chips:
+
+ * Maxim MAX127
+
+ Prefix: 'max127'
+
+ Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX127-MAX128.pdf
+
+Description
+-----------
+
+The MAX127 is a multirange, 12-bit data acquisition system (DAS) providing
+8 analog input channels that are independently software programmable for
+a variety of ranges. The available ranges are {0,5V}, {0,10V}, {-5,5V}
+and {-10,10V}.
+
+The MAX127 features a 2-wire, I2C-compatible serial interface that allows
+communication among multiple devices using SDA and SCL lines.
+
+Sysfs interface
+---------------
+
+ ============== ==============================================================
+ in[0-7]_input The input voltage (in mV) of the corresponding channel.
+ RO
+
+ in[0-7]_min The lower input limit (in mV) for the corresponding channel.
+ ADC range and LSB will be updated when the limit is changed.
+ For the MAX127, it will be adjusted to -10000, -5000, or 0.
+ RW
+
+ in[0-7]_max The higher input limit (in mV) for the corresponding channel.
+ ADC range and LSB will be updated when the limit is changed.
+ For the MAX127, it will be adjusted to 0, 5000, or 10000.
+ RW
+ ============== ==============================================================
diff --git a/Documentation/hwmon/nct6683.rst b/Documentation/hwmon/nct6683.rst
index efbf7e9..8646ad5 100644
--- a/Documentation/hwmon/nct6683.rst
+++ b/Documentation/hwmon/nct6683.rst
@@ -3,7 +3,7 @@
Supported chips:
- * Nuvoton NCT6683D
+ * Nuvoton NCT6683D/NCT6687D
Prefix: 'nct6683'
@@ -61,4 +61,5 @@
Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13
Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13
Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13
+MSI B550 NCT6687D EC firmware version 1.0 build 05/07/20
=============== ===============================================
diff --git a/Documentation/hwmon/pm6764tr.rst b/Documentation/hwmon/pm6764tr.rst
new file mode 100644
index 0000000..a1fb8fe
--- /dev/null
+++ b/Documentation/hwmon/pm6764tr.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver pm6764tr
+======================
+
+Supported chips:
+
+ * ST PM6764TR
+
+ Prefix: 'pm6764tr'
+
+ Addresses scanned: -
+
+ Datasheet: http://www.st.com/resource/en/data_brief/pm6764.pdf
+
+Authors:
+ <hsu.yungteng@gmail.com>
+
+Description:
+------------
+
+This driver supports the STMicroelectronics PM6764TR chip. The PM6764TR is a high
+performance digital controller designed to power Intel’s VR12.5 processors and memories.
+
+The device utilizes digital technology to implement all control and power management
+functions to provide maximum flexibility and performance. The NVM is embedded to store
+custom configurations. The PM6764TR device features up to 4-phase programmable operation.
+
+The PM6764TR supports power state transitions featuring VFDE, and programmable DPM
+maintaining the best efficiency over all loading conditions without compromising transient
+response. The device assures fast and independent protection against load overcurrent,
+under/overvoltage and feedback disconnections.
diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst
index e22c4f6..73e23ab 100644
--- a/Documentation/hwmon/pmbus-core.rst
+++ b/Documentation/hwmon/pmbus-core.rst
@@ -279,12 +279,6 @@
::
- void pmbus_do_remove(struct i2c_client *client);
-
-Execute driver remove function. Similar to standard driver remove function.
-
-::
-
const struct pmbus_driver_info
*pmbus_get_driver_info(struct i2c_client *client);
diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst
index fb3ad67..c44f141 100644
--- a/Documentation/hwmon/pmbus.rst
+++ b/Documentation/hwmon/pmbus.rst
@@ -148,11 +148,6 @@
return pmbus_do_probe(client, &ds1200_info);
}
- static int ds1200_remove(struct i2c_client *client)
- {
- return pmbus_do_remove(client);
- }
-
static const struct i2c_device_id ds1200_id[] = {
{"ds1200", 0},
{}
@@ -166,7 +161,6 @@
.name = "ds1200",
},
.probe_new = ds1200_probe,
- .remove = ds1200_remove,
.id_table = ds1200_id,
};
diff --git a/Documentation/hwmon/q54sj108a2.rst b/Documentation/hwmon/q54sj108a2.rst
new file mode 100644
index 0000000..f95d813
--- /dev/null
+++ b/Documentation/hwmon/q54sj108a2.rst
@@ -0,0 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver q54sj108a2
+========================
+
+Supported chips:
+
+ * DELTA Q54SJ108A2NCAH, Q54SJ108A2NCDH, Q54SJ108A2NCPG, Q54SJ108A2NCPH
+
+ Prefix: 'q54sj108a2'
+
+ Addresses scanned: -
+
+ Datasheet: https://filecenter.delta-china.com.cn/products/download/01/0102/datasheet/DS_Q54SJ108A2.pdf
+
+Authors:
+ Xiao.ma <xiao.mx.ma@deltaww.com>
+
+
+Description
+-----------
+
+This driver implements support for DELTA Q54SJ108A2NCAH, Q54SJ108A2NCDH,
+Q54SJ108A2NCPG, and Q54SJ108A2NCPH 1/4 Brick DC/DC Regulated Power Module
+with PMBus support.
+
+The driver is a client driver to the core PMBus driver.
+Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
+details.
+
+
+Sysfs entries
+-------------
+
+===================== ===== ==================================================
+curr1_alarm RO Output current alarm
+curr1_input RO Output current
+curr1_label RO 'iout1'
+in1_alarm RO Input voltage alarm
+in1_input RO Input voltage
+in1_label RO 'vin'
+in2_alarm RO Output voltage alarm
+in2_input RO Output voltage
+in2_label RO 'vout1'
+temp1_alarm RO Temperature alarm
+temp1_input RO Chip temperature
+===================== ===== ==================================================
diff --git a/Documentation/hwmon/sbtsi_temp.rst b/Documentation/hwmon/sbtsi_temp.rst
new file mode 100644
index 0000000..922b3c8
--- /dev/null
+++ b/Documentation/hwmon/sbtsi_temp.rst
@@ -0,0 +1,42 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver sbtsi_temp
+==================
+
+Supported hardware:
+
+ * Sideband interface (SBI) Temperature Sensor Interface (SB-TSI)
+ compliant AMD SoC temperature device.
+
+ Prefix: 'sbtsi_temp'
+
+ Addresses scanned: This driver doesn't support address scanning.
+
+ To instantiate this driver on an AMD CPU with SB-TSI
+ support, the i2c bus number would be the bus connected from the board
+ management controller (BMC) to the CPU. The i2c address is 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.
+
+ Datasheet: The SB-TSI interface and protocol is available as part of
+ the open source SoC register reference at:
+
+ https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf
+
+ The Advanced Platform Management Link (APML) Specification is
+ available at:
+
+ http://developer.amd.com/wordpress/media/2012/10/41918.pdf
+
+Author: Kun Yi <kunyi@google.com>
+
+Description
+-----------
+
+The SBI temperature sensor interface (SB-TSI) is an emulation of the software
+and physical interface of a typical 8-pin remote temperature sensor (RTS) on
+AMD SoCs. It implements one temperature sensor with readings and limit
+registers encode the temperature in increments of 0.125 from 0 to 255.875.
+Limits can be set through the writable thresholds, and if reached will trigger
+corresponding alert signals.
diff --git a/Documentation/ia64/features.rst b/Documentation/ia64/features.rst
new file mode 100644
index 0000000..d7226fd
--- /dev/null
+++ b/Documentation/ia64/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features ia64
diff --git a/Documentation/ia64/index.rst b/Documentation/ia64/index.rst
index 4bdfe28..761f215 100644
--- a/Documentation/ia64/index.rst
+++ b/Documentation/ia64/index.rst
@@ -15,3 +15,5 @@
irq-redir
mca
serial
+
+ features
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 5771974..5888e8a 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -160,7 +160,7 @@
ia64/index
m68k/index
mips/index
- nios2/nios2
+ nios2/index
openrisc/index
parisc/index
powerpc/index
diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst
index 45a4c6e..5938145 100644
--- a/Documentation/input/input-programming.rst
+++ b/Documentation/input/input-programming.rst
@@ -164,6 +164,52 @@
The open() callback should return a 0 in case of success or any nonzero value
in case of failure. The close() callback (which is void) must always succeed.
+Inhibiting input devices
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Inhibiting a device means ignoring input events from it. As such it is about
+maintaining relationships with input handlers - either already existing
+relationships, or relationships to be established while the device is in
+inhibited state.
+
+If a device is inhibited, no input handler will receive events from it.
+
+The fact that nobody wants events from the device is exploited further, by
+calling device's close() (if there are users) and open() (if there are users) on
+inhibit and uninhibit operations, respectively. Indeed, the meaning of close()
+is to stop providing events to the input core and that of open() is to start
+providing events to the input core.
+
+Calling the device's close() method on inhibit (if there are users) allows the
+driver to save power. Either by directly powering down the device or by
+releasing the runtime-pm reference it got in open() when the driver is using
+runtime-pm.
+
+Inhibiting and uninhibiting are orthogonal to opening and closing the device by
+input handlers. Userspace might want to inhibit a device in anticipation before
+any handler is positively matched against it.
+
+Inhibiting and uninhibiting are orthogonal to device's being a wakeup source,
+too. Being a wakeup source plays a role when the system is sleeping, not when
+the system is operating. How drivers should program their interaction between
+inhibiting, sleeping and being a wakeup source is driver-specific.
+
+Taking the analogy with the network devices - bringing a network interface down
+doesn't mean that it should be impossible be wake the system up on LAN through
+this interface. So, there may be input drivers which should be considered wakeup
+sources even when inhibited. Actually, in many I2C input devices their interrupt
+is declared a wakeup interrupt and its handling happens in driver's core, which
+is not aware of input-specific inhibit (nor should it be). Composite devices
+containing several interfaces can be inhibited on a per-interface basis and e.g.
+inhibiting one interface shouldn't affect the device's capability of being a
+wakeup source.
+
+If a device is to be considered a wakeup source while inhibited, special care
+must be taken when programming its suspend(), as it might need to call device's
+open(). Depending on what close() means for the device in question, not
+opening() it before going to sleep might make it impossible to provide any
+wakeup events. The device is going to sleep anyway.
+
Basic event types
~~~~~~~~~~~~~~~~~
diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index 1cf1aeb..226ae07 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -553,6 +553,41 @@
limits FOO to module (=m) or disabled (=n).
+Compile-testing
+~~~~~~~~~~~~~~~
+If a config symbol has a dependency, but the code controlled by the config
+symbol can still be compiled if the dependency is not met, it is encouraged to
+increase build coverage by adding an "|| COMPILE_TEST" clause to the
+dependency. This is especially useful for drivers for more exotic hardware, as
+it allows continuous-integration systems to compile-test the code on a more
+common system, and detect bugs that way.
+Note that compile-tested code should avoid crashing when run on a system where
+the dependency is not met.
+
+Architecture and platform dependencies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Due to the presence of stubs, most drivers can now be compiled on most
+architectures. However, this does not mean it makes sense to have all drivers
+available everywhere, as the actual hardware may only exist on specific
+architectures and platforms. This is especially true for on-SoC IP cores,
+which may be limited to a specific vendor or SoC family.
+
+To prevent asking the user about drivers that cannot be used on the system(s)
+the user is compiling a kernel for, and if it makes sense, config symbols
+controlling the compilation of a driver should contain proper dependencies,
+limiting the visibility of the symbol to (a superset of) the platform(s) the
+driver can be used on. The dependency can be an architecture (e.g. ARM) or
+platform (e.g. ARCH_OMAP4) dependency. This makes life simpler not only for
+distro config owners, but also for every single developer or user who
+configures a kernel.
+
+Such a dependency can be relaxed by combining it with the compile-testing rule
+above, leading to:
+
+ config FOO
+ bool "Support for foo hardware"
+ depends on ARCH_FOO_VENDOR || COMPILE_TEST
+
Kconfig recursive dependency limitations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/kbuild/kconfig-macro-language.rst b/Documentation/kbuild/kconfig-macro-language.rst
index 8b413ef..6163467 100644
--- a/Documentation/kbuild/kconfig-macro-language.rst
+++ b/Documentation/kbuild/kconfig-macro-language.rst
@@ -97,7 +97,7 @@
particular number of arguments.
In Make, every built-in function takes at least one argument. Kconfig allows
-zero argument for built-in functions, such as $(fileno), $(lineno). You could
+zero argument for built-in functions, such as $(filename), $(lineno). You could
consider those as "built-in variable", but it is just a matter of how we call
it after all. Let's say "built-in function" here to refer to natively supported
functionality.
diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
index 0d5dd54..d36768c 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -15,13 +15,15 @@
--- 3.4 Objects which export symbols
--- 3.5 Library file goals - lib-y
--- 3.6 Descending down in directories
- --- 3.7 Compilation flags
- --- 3.8 <deleted>
- --- 3.9 Dependency tracking
- --- 3.10 Special Rules
- --- 3.11 $(CC) support functions
- --- 3.12 $(LD) support functions
- --- 3.13 Script Invocation
+ --- 3.7 Non-builtin vmlinux targets - extra-y
+ --- 3.8 Always built goals - always-y
+ --- 3.9 Compilation flags
+ --- 3.10 Dependency tracking
+ --- 3.11 Custom Rules
+ --- 3.12 Command change detection
+ --- 3.13 $(CC) support functions
+ --- 3.14 $(LD) support functions
+ --- 3.15 Script Invocation
=== 4 Host Program support
--- 4.1 Simple Host Program
@@ -46,7 +48,7 @@
--- 7.5 Architecture-specific boot images
--- 7.6 Building non-kbuild targets
--- 7.7 Commands useful for building a boot image
- --- 7.8 Custom kbuild commands
+ --- 7.8 <deleted>
--- 7.9 Preprocessing linker scripts
--- 7.10 Generic header files
--- 7.11 Post-link pass
@@ -67,11 +69,11 @@
The Makefiles have five parts::
- Makefile the top Makefile.
- .config the kernel configuration file.
- arch/$(ARCH)/Makefile the arch Makefile.
- scripts/Makefile.* common rules etc. for all kbuild Makefiles.
- kbuild Makefiles there are about 500 of these.
+ Makefile the top Makefile.
+ .config the kernel configuration file.
+ arch/$(SRCARCH)/Makefile the arch Makefile.
+ scripts/Makefile.* common rules etc. for all kbuild Makefiles.
+ kbuild Makefiles exist in every subdirectory
The top Makefile reads the .config file, which comes from the kernel
configuration process.
@@ -82,7 +84,7 @@
the kernel source tree.
The list of subdirectories which are visited depends upon the kernel
configuration. The top Makefile textually includes an arch Makefile
-with the name arch/$(ARCH)/Makefile. The arch Makefile supplies
+with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies
architecture-specific information to the top Makefile.
Each subdirectory has a kbuild Makefile which carries out the commands
@@ -278,7 +280,7 @@
actually recognize that there is a lib.a being built, the directory
shall be listed in libs-y.
- See also "6.4 List directories to visit when descending".
+ See also "7.4 List directories to visit when descending".
Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
@@ -317,11 +319,79 @@
that directory specifies obj-y, those objects will be left orphan.
It is very likely a bug of the Makefile or of dependencies in Kconfig.
+ Kbuild also supports dedicated syntax, subdir-y and subdir-m, for
+ descending into subdirectories. It is a good fit when you know they
+ do not contain kernel-space objects at all. A typical usage is to let
+ Kbuild descend into subdirectories to build tools.
+
+ Examples::
+
+ # scripts/Makefile
+ subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
+ subdir-$(CONFIG_MODVERSIONS) += genksyms
+ subdir-$(CONFIG_SECURITY_SELINUX) += selinux
+
+ Unlike obj-y/m, subdir-y/m does not need the trailing slash since this
+ syntax is always used for directories.
+
It is good practice to use a `CONFIG_` variable when assigning directory
names. This allows kbuild to totally skip the directory if the
corresponding `CONFIG_` option is neither 'y' nor 'm'.
-3.7 Compilation flags
+3.7 Non-builtin vmlinux targets - extra-y
+-----------------------------------------
+
+ extra-y specifies targets which are needed for building vmlinux,
+ but not combined into built-in.a.
+
+ Examples are:
+
+ 1) head objects
+
+ Some objects must be placed at the head of vmlinux. They are
+ directly linked to vmlinux without going through built-in.a
+ A typical use-case is an object that contains the entry point.
+
+ arch/$(SRCARCH)/Makefile should specify such objects as head-y.
+
+ Discussion:
+ Given that we can control the section order in the linker script,
+ why do we need head-y?
+
+ 2) vmlinux linker script
+
+ The linker script for vmlinux is located at
+ arch/$(SRCARCH)/kernel/vmlinux.lds
+
+ Example::
+
+ # arch/x86/kernel/Makefile
+ extra-y := head_$(BITS).o
+ extra-y += head$(BITS).o
+ extra-y += ebda.o
+ extra-y += platform-quirks.o
+ extra-y += vmlinux.lds
+
+ $(extra-y) should only contain targets needed for vmlinux.
+
+ Kbuild skips extra-y when vmlinux is apparently not a final goal.
+ (e.g. 'make modules', or building external modules)
+
+ If you intend to build targets unconditionally, always-y (explained
+ in the next section) is the correct syntax to use.
+
+3.8 Always built goals - always-y
+---------------------------------
+
+ always-y specifies targets which are literally always built when
+ Kbuild visits the Makefile.
+
+ Example::
+ # ./Kbuild
+ offsets-file := include/generated/asm-offsets.h
+ always-y += $(offsets-file)
+
+3.9 Compilation flags
---------------------
ccflags-y, asflags-y and ldflags-y
@@ -410,8 +480,8 @@
AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
-3.9 Dependency tracking
------------------------
+3.10 Dependency tracking
+------------------------
Kbuild tracks dependencies on the following:
@@ -422,21 +492,21 @@
Thus, if you change an option to $(CC) all affected files will
be re-compiled.
-3.10 Special Rules
-------------------
+3.11 Custom Rules
+-----------------
- Special rules are used when the kbuild infrastructure does
+ Custom rules are used when the kbuild infrastructure does
not provide the required support. A typical example is
header files generated during the build process.
Another example are the architecture-specific Makefiles which
- need special rules to prepare boot images etc.
+ need custom rules to prepare boot images etc.
- Special rules are written as normal Make rules.
+ Custom rules are written as normal Make rules.
Kbuild is not executing in the directory where the Makefile is
- located, so all special rules shall provide a relative
+ located, so all custom rules shall use a relative
path to prerequisite files and target files.
- Two variables are used when defining special rules:
+ Two variables are used when defining custom rules:
$(src)
$(src) is a relative path which points to the directory
@@ -454,7 +524,7 @@
$(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
$(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
- This is a special rule, following the normal syntax
+ This is a custom rule, following the normal syntax
required by make.
The target file depends on two prerequisite files. References
@@ -471,13 +541,81 @@
Example::
- #arch/blackfin/boot/Makefile
- $(obj)/vmImage: $(obj)/vmlinux.gz
- $(call if_changed,uimage)
- @$(kecho) 'Kernel: $@ is ready'
+ # arch/arm/Makefile
+ $(BOOT_TARGETS): vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+ @$(kecho) ' Kernel: $(boot)/$@ is ready'
+ When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
+ of a command is normally displayed.
+ To enable this behaviour for custom commands kbuild requires
+ two variables to be set::
-3.11 $(CC) support functions
+ quiet_cmd_<command> - what shall be echoed
+ cmd_<command> - the command to execute
+
+ Example::
+
+ # lib/Makefile
+ quiet_cmd_crc32 = GEN $@
+ cmd_crc32 = $< > $@
+
+ $(obj)/crc32table.h: $(obj)/gen_crc32table
+ $(call cmd,crc32)
+
+ When updating the $(obj)/crc32table.h target, the line:
+
+ GEN lib/crc32table.h
+
+ will be displayed with "make KBUILD_VERBOSE=0".
+
+3.12 Command change detection
+-----------------------------
+
+ When the rule is evaluated, timestamps are compared between the target
+ and its prerequisite files. GNU Make updates the target when any of the
+ prerequisites is newer than that.
+
+ The target should be rebuilt also when the command line has changed
+ since the last invocation. This is not supported by Make itself, so
+ Kbuild achieves this by a kind of meta-programming.
+
+ if_changed is the macro used for this purpose, in the following form::
+
+ quiet_cmd_<command> = ...
+ cmd_<command> = ...
+
+ <target>: <source(s)> FORCE
+ $(call if_changed,<command>)
+
+ Any target that utilizes if_changed must be listed in $(targets),
+ otherwise the command line check will fail, and the target will
+ always be built.
+
+ If the target is already listed in the recognized syntax such as
+ obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild
+ automatically adds it to $(targets). Otherwise, the target must be
+ explicitly added to $(targets).
+
+ Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
+ used in conjunction with custom rules as defined in "3.9 Custom Rules".
+
+ Note: It is a typical mistake to forget the FORCE prerequisite.
+ Another common pitfall is that whitespace is sometimes significant; for
+ instance, the below will fail (note the extra space after the comma)::
+
+ target: source(s) FORCE
+
+ **WRONG!** $(call if_changed, objcopy)
+
+ Note:
+ if_changed should not be used more than once per target.
+ It stores the executed command in a corresponding .cmd
+ file and multiple calls would result in overwrites and
+ unwanted results when the target is up to date and only the
+ tests on changed commands trigger execution of commands.
+
+3.13 $(CC) support functions
----------------------------
The kernel may be built with several different versions of
@@ -592,7 +730,7 @@
endif
endif
-3.12 $(LD) support functions
+3.14 $(LD) support functions
----------------------------
ld-option
@@ -606,7 +744,7 @@
#Makefile
LDFLAGS_vmlinux += $(call ld-option, -X)
-3.13 Script invocation
+3.15 Script invocation
----------------------
Make rules may invoke scripts to build the kernel. The rules shall
@@ -744,7 +882,7 @@
as a prerequisite.
This is possible in two ways:
- (1) List the prerequisite explicitly in a special rule.
+ (1) List the prerequisite explicitly in a custom rule.
Example::
@@ -755,11 +893,11 @@
The target $(obj)/devlist.h will not be built before
$(obj)/gen-devlist is updated. Note that references to
- the host programs in special rules must be prefixed with $(obj).
+ the host programs in custom rules must be prefixed with $(obj).
(2) Use always-y
- When there is no suitable special rule, and the host program
+ When there is no suitable custom rule, and the host program
shall be built when a makefile is entered, the always-y
variable shall be used.
@@ -933,7 +1071,7 @@
and clean as usual. The Makefile located in arch/x86/boot/ may use
the subdir- trick to descend further down.
-Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is
+Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is
included in the top level makefile, and the kbuild infrastructure
is not operational at that point.
@@ -946,9 +1084,9 @@
The top level Makefile sets up the environment and does the preparation,
before starting to descend down in the individual directories.
The top level makefile contains the generic part, whereas
-arch/$(ARCH)/Makefile contains what is required to set up kbuild
+arch/$(SRCARCH)/Makefile contains what is required to set up kbuild
for said architecture.
-To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines
+To do so, arch/$(SRCARCH)/Makefile sets up a number of variables and defines
a few targets.
When kbuild executes, the following steps are followed (roughly):
@@ -956,14 +1094,14 @@
1) Configuration of the kernel => produce .config
2) Store kernel version in include/linux/version.h
3) Updating all other prerequisites to the target prepare:
- - Additional prerequisites are specified in arch/$(ARCH)/Makefile
+ - Additional prerequisites are specified in arch/$(SRCARCH)/Makefile
4) Recursively descend down in all directories listed in
init-* core* drivers-* net-* libs-* and build all targets.
- - The values of the above variables are expanded in arch/$(ARCH)/Makefile.
+ - The values of the above variables are expanded in arch/$(SRCARCH)/Makefile.
5) All object files are then linked and the resulting file vmlinux is
located at the root of the obj tree.
The very first objects linked are listed in head-y, assigned by
- arch/$(ARCH)/Makefile.
+ arch/$(SRCARCH)/Makefile.
6) Finally, the architecture-specific part does any required post processing
and builds the final bootimage.
- This includes building boot records
@@ -1154,7 +1292,7 @@
machinery is all architecture-independent.
- head-y, init-y, core-y, libs-y, drivers-y, net-y
+ head-y, core-y, libs-y, drivers-y
$(head-y) lists objects to be linked first in vmlinux.
$(libs-y) lists directories where a lib.a archive can be located.
@@ -1162,23 +1300,24 @@
The rest list directories where a built-in.a object file can be
located.
- $(init-y) objects will be located after $(head-y).
-
Then the rest follows in this order:
- $(core-y), $(libs-y), $(drivers-y) and $(net-y).
+ $(core-y), $(libs-y), $(drivers-y)
The top level Makefile defines values for all generic directories,
- and arch/$(ARCH)/Makefile only adds architecture-specific
+ and arch/$(SRCARCH)/Makefile only adds architecture-specific
directories.
Example::
- #arch/sparc64/Makefile
- core-y += arch/sparc64/kernel/
- libs-y += arch/sparc64/prom/ arch/sparc64/lib/
- drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/
+ # arch/sparc/Makefile
+ core-y += arch/sparc/
+ libs-y += arch/sparc/prom/
+ libs-y += arch/sparc/lib/
+
+ drivers-$(CONFIG_PM) += arch/sparc/power/
+ drivers-$(CONFIG_OPROFILE) += arch/sparc/oprofile/
7.5 Architecture-specific boot images
-------------------------------------
@@ -1189,15 +1328,15 @@
The actual goals are not standardized across architectures.
It is common to locate any additional processing in a boot/
- directory below arch/$(ARCH)/.
+ directory below arch/$(SRCARCH)/.
Kbuild does not provide any smart way to support building a
- target specified in boot/. Therefore arch/$(ARCH)/Makefile shall
+ target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall
call make manually to build a target in boot/.
The recommended approach is to include shortcuts in
- arch/$(ARCH)/Makefile, and use the full path when calling down
- into the arch/$(ARCH)/boot/Makefile.
+ arch/$(SRCARCH)/Makefile, and use the full path when calling down
+ into the arch/$(SRCARCH)/boot/Makefile.
Example::
@@ -1217,7 +1356,7 @@
#arch/x86/Makefile
define archhelp
- echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)'
+ echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
endif
When make is executed without arguments, the first goal encountered
@@ -1235,71 +1374,12 @@
When "make" is executed without arguments, bzImage will be built.
-7.6 Building non-kbuild targets
--------------------------------
-
- extra-y
- extra-y specifies additional targets created in the current
- directory, in addition to any targets specified by `obj-*`.
-
- Listing all targets in extra-y is required for two purposes:
-
- 1) Enable kbuild to check changes in command lines
-
- - When $(call if_changed,xxx) is used
-
- 2) kbuild knows what files to delete during "make clean"
-
- Example::
-
- #arch/x86/kernel/Makefile
- extra-y := head.o init_task.o
-
- In this example, extra-y is used to list object files that
- shall be built, but shall not be linked as part of built-in.a.
-
7.7 Commands useful for building a boot image
---------------------------------------------
Kbuild provides a few macros that are useful when building a
boot image.
- if_changed
- if_changed is the infrastructure used for the following commands.
-
- Usage::
-
- target: source(s) FORCE
- $(call if_changed,ld/objcopy/gzip/...)
-
- When the rule is evaluated, it is checked to see if any files
- need an update, or the command line has changed since the last
- invocation. The latter will force a rebuild if any options
- to the executable have changed.
- Any target that utilises if_changed must be listed in $(targets),
- otherwise the command line check will fail, and the target will
- always be built.
- Assignments to $(targets) are without $(obj)/ prefix.
- if_changed may be used in conjunction with custom commands as
- defined in 7.8 "Custom kbuild commands".
-
- Note: It is a typical mistake to forget the FORCE prerequisite.
- Another common pitfall is that whitespace is sometimes
- significant; for instance, the below will fail (note the extra space
- after the comma)::
-
- target: source(s) FORCE
-
- **WRONG!** $(call if_changed, ld/objcopy/gzip/...)
-
- Note:
- if_changed should not be used more than once per target.
- It stores the executed command in a corresponding .cmd
-
- file and multiple calls would result in overwrites and
- unwanted results when the target is up to date and only the
- tests on changed commands trigger execution of commands.
-
ld
Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
@@ -1332,7 +1412,7 @@
objcopy
Copy binary. Uses OBJCOPYFLAGS usually specified in
- arch/$(ARCH)/Makefile.
+ arch/$(SRCARCH)/Makefile.
OBJCOPYFLAGS_$@ may be used to set additional options.
gzip
@@ -1361,41 +1441,11 @@
targets += $(dtb-y)
DTC_FLAGS ?= -p 1024
-7.8 Custom kbuild commands
---------------------------
-
- When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
- of a command is normally displayed.
- To enable this behaviour for custom commands kbuild requires
- two variables to be set::
-
- quiet_cmd_<command> - what shall be echoed
- cmd_<command> - the command to execute
-
- Example::
-
- #
- quiet_cmd_image = BUILD $@
- cmd_image = $(obj)/tools/build $(BUILDFLAGS) \
- $(obj)/vmlinux.bin > $@
-
- targets += bzImage
- $(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE
- $(call if_changed,image)
- @echo 'Kernel: $@ is ready'
-
- When updating the $(obj)/bzImage target, the line:
-
- BUILD arch/x86/boot/bzImage
-
- will be displayed with "make KBUILD_VERBOSE=0".
-
-
7.9 Preprocessing linker scripts
--------------------------------
When the vmlinux image is built, the linker script
- arch/$(ARCH)/kernel/vmlinux.lds is used.
+ arch/$(SRCARCH)/kernel/vmlinux.lds is used.
The script is a preprocessed variant of the file vmlinux.lds.S
located in the same directory.
kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`.
@@ -1405,9 +1455,6 @@
#arch/x86/kernel/Makefile
extra-y := vmlinux.lds
- #Makefile
- export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
-
The assignment to extra-y is used to tell kbuild to build the
target vmlinux.lds.
The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
@@ -1481,7 +1528,7 @@
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
- arch/$(ARCH)/include/asm/Kbuild like this:
+ arch/$(SRCARCH)/include/asm/Kbuild like this:
Example::
@@ -1492,7 +1539,7 @@
During the prepare phase of the build a wrapper include
file is generated in the directory::
- arch/$(ARCH)/include/generated/asm
+ arch/$(SRCARCH)/include/generated/asm
When a header is exported where the architecture uses
the generic header a similar wrapper is generated as part
@@ -1527,8 +1574,8 @@
to define the minimum set of ASM headers that all architectures must have.
This works like optional generic-y. If a mandatory header is missing
- in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate
- a wrapper of the asm-generic one.
+ in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically
+ generate a wrapper of the asm-generic one.
9 Kbuild Variables
==================
@@ -1564,6 +1611,16 @@
make ARCH=m68k ...
+ SRCARCH
+ This variable specifies the directory in arch/ to build.
+
+ ARCH and SRCARCH may not necessarily match. A couple of arch
+ directories are biarch, that is, a single `arch/*/` directory supports
+ both 32-bit and 64-bit.
+
+ For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86.
+ For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and
+ x86_64.
INSTALL_PATH
This variable defines a place for the arch Makefiles to install
diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst
index 85ccc87..a1f3eb7 100644
--- a/Documentation/kbuild/modules.rst
+++ b/Documentation/kbuild/modules.rst
@@ -332,7 +332,7 @@
There are two notable exceptions to this rule: larger
subsystems have their own directory under include/, such as
include/scsi; and architecture specific headers are located
- under arch/$(ARCH)/include/.
+ under arch/$(SRCARCH)/include/.
4.1 Kernel Includes
-------------------
diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index a0708d3..cd155ea 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -177,13 +177,3 @@
would cause nightmare dependency issues. I see this as a minor issue
compared to the benefits the simple trigger functionality brings. The
rest of the LED subsystem can be modular.
-
-
-Future Development
-==================
-
-At the moment, a trigger can't be created specifically for a single LED.
-There are a number of cases where a trigger might only be mappable to a
-particular LED (ACPI?). The addition of triggers provided by the LED driver
-should cover this option and be possible to add without breaking the
-current interface.
diff --git a/Documentation/locking/seqlock.rst b/Documentation/locking/seqlock.rst
index a334b58..64405e5 100644
--- a/Documentation/locking/seqlock.rst
+++ b/Documentation/locking/seqlock.rst
@@ -89,7 +89,7 @@
.. _seqcount_locktype_t:
-Sequence counters with associated locks (``seqcount_LOCKTYPE_t``)
+Sequence counters with associated locks (``seqcount_LOCKNAME_t``)
-----------------------------------------------------------------
As discussed at :ref:`seqcount_t`, sequence count write side critical
@@ -115,27 +115,26 @@
- ``seqcount_mutex_t``
- ``seqcount_ww_mutex_t``
-The plain seqcount read and write APIs branch out to the specific
-seqcount_LOCKTYPE_t implementation at compile-time. This avoids kernel
-API explosion per each new seqcount LOCKTYPE.
+The sequence counter read and write APIs can take either a plain
+seqcount_t or any of the seqcount_LOCKNAME_t variants above.
-Initialization (replace "LOCKTYPE" with one of the supported locks)::
+Initialization (replace "LOCKNAME" with one of the supported locks)::
/* dynamic */
- seqcount_LOCKTYPE_t foo_seqcount;
- seqcount_LOCKTYPE_init(&foo_seqcount, &lock);
+ seqcount_LOCKNAME_t foo_seqcount;
+ seqcount_LOCKNAME_init(&foo_seqcount, &lock);
/* static */
- static seqcount_LOCKTYPE_t foo_seqcount =
- SEQCNT_LOCKTYPE_ZERO(foo_seqcount, &lock);
+ static seqcount_LOCKNAME_t foo_seqcount =
+ SEQCNT_LOCKNAME_ZERO(foo_seqcount, &lock);
/* C99 struct init */
struct {
- .seq = SEQCNT_LOCKTYPE_ZERO(foo.seq, &lock),
+ .seq = SEQCNT_LOCKNAME_ZERO(foo.seq, &lock),
} foo;
Write path: same as in :ref:`seqcount_t`, while running from a context
-with the associated LOCKTYPE lock acquired.
+with the associated write serialization lock acquired.
Read path: same as in :ref:`seqcount_t`.
diff --git a/Documentation/m68k/features.rst b/Documentation/m68k/features.rst
new file mode 100644
index 0000000..5107a21
--- /dev/null
+++ b/Documentation/m68k/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features m68k
diff --git a/Documentation/m68k/index.rst b/Documentation/m68k/index.rst
index b89cb6a..0f890db 100644
--- a/Documentation/m68k/index.rst
+++ b/Documentation/m68k/index.rst
@@ -10,6 +10,8 @@
kernel-options
buddha-driver
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 17c8e0c..7367ada 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1870,7 +1870,7 @@
These are for use with atomic RMW functions that do not imply memory
barriers, but where the code needs a memory barrier. Examples for atomic
- RMW functions that do not imply are memory barrier are e.g. add,
+ RMW functions that do not imply a memory barrier are e.g. add,
subtract, (failed) conditional operations, _relaxed functions,
but not atomic_read or atomic_set. A common example where a memory
barrier may be required is when atomic ops are used for reference
diff --git a/Documentation/mips/features.rst b/Documentation/mips/features.rst
new file mode 100644
index 0000000..1973d72
--- /dev/null
+++ b/Documentation/mips/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features mips
diff --git a/Documentation/mips/index.rst b/Documentation/mips/index.rst
index 35cceea..037f85a 100644
--- a/Documentation/mips/index.rst
+++ b/Documentation/mips/index.rst
@@ -11,6 +11,8 @@
booting
ingenic-tcu
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst
index ff05cbd..f8dae66 100644
--- a/Documentation/networking/can.rst
+++ b/Documentation/networking/can.rst
@@ -228,20 +228,36 @@
on the socket as usual. There are also CAN specific socket options
described below.
-The basic CAN frame structure and the sockaddr structure are defined
-in include/linux/can.h:
+The Classical CAN frame structure (aka CAN 2.0B), the CAN FD frame structure
+and the sockaddr structure are defined in include/linux/can.h:
.. code-block:: C
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
- __u8 can_dlc; /* frame payload length in byte (0 .. 8) */
+ union {
+ /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
+ * was previously named can_dlc so we need to carry that
+ * name for legacy support
+ */
+ __u8 len;
+ __u8 can_dlc; /* deprecated */
+ };
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
- __u8 __res1; /* reserved / padding */
+ __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */
__u8 data[8] __attribute__((aligned(8)));
};
+Remark: The len element contains the payload length in bytes and should be
+used instead of can_dlc. The deprecated can_dlc was misleadingly named as
+it always contained the plain payload length in bytes and not the so called
+'data length code' (DLC).
+
+To pass the raw DLC from/to a Classical CAN network device the len8_dlc
+element can contain values 9 .. 15 when the len element is 8 (the real
+payload length for all DLC values greater or equal to 8).
+
The alignment of the (linear) payload data[] to a 64bit boundary
allows the user to define their own structs and unions to easily access
the CAN payload. There is no given byteorder on the CAN bus by
@@ -260,6 +276,23 @@
/* transport protocol class address info (e.g. ISOTP) */
struct { canid_t rx_id, tx_id; } tp;
+ /* J1939 address information */
+ struct {
+ /* 8 byte name when using dynamic addressing */
+ __u64 name;
+
+ /* pgn:
+ * 8 bit: PS in PDU2 case, else 0
+ * 8 bit: PF
+ * 1 bit: DP
+ * 1 bit: reserved
+ */
+ __u32 pgn;
+
+ /* 1 byte address */
+ __u8 addr;
+ } j1939;
+
/* reserved for future CAN protocols address information */
} can_addr;
};
@@ -371,7 +404,7 @@
bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g.
the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that
switches the socket into a mode that allows the handling of CAN FD frames
-and (legacy) CAN frames simultaneously (see :ref:`socketcan-rawfd`).
+and Classical CAN frames simultaneously (see :ref:`socketcan-rawfd`).
The struct canfd_frame is defined in include/linux/can.h:
@@ -397,7 +430,7 @@
length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve
the easy handling of the length information the canfd_frame.len element
contains a plain length value from 0 .. 64. So both canfd_frame.len and
-can_frame.can_dlc are equal and contain a length information and no DLC.
+can_frame.len are equal and contain a length information and no DLC.
For details about the distinction of CAN and CAN FD capable devices and
the mapping to the bus-relevant data length code (DLC), see :ref:`socketcan-can-fd-driver`.
@@ -407,7 +440,7 @@
.. code-block:: C
- #define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame
+ #define CAN_MTU (sizeof(struct can_frame)) == 16 => Classical CAN frame
#define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame
@@ -609,7 +642,7 @@
printf("got CAN FD frame with length %d\n", cfd.len);
/* cfd.flags contains valid data */
} else if (nbytes == CAN_MTU) {
- printf("got legacy CAN frame with length %d\n", cfd.len);
+ printf("got Classical CAN frame with length %d\n", cfd.len);
/* cfd.flags is undefined */
} else {
fprintf(stderr, "read: invalid CAN(FD) frame\n");
@@ -623,7 +656,7 @@
printf("%02X ", cfd.data[i]);
When reading with size CANFD_MTU only returns CAN_MTU bytes that have
-been received from the socket a legacy CAN frame has been read into the
+been received from the socket a Classical CAN frame has been read into the
provided CAN FD structure. Note that the canfd_frame.flags data field is
not specified in the struct can_frame and therefore it is only valid in
CANFD_MTU sized CAN FD frames.
@@ -633,7 +666,7 @@
To build a CAN FD aware application use struct canfd_frame as basic CAN
data structure for CAN_RAW based applications. When the application is
executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES
-socket option returns an error: No problem. You'll get legacy CAN frames
+socket option returns an error: No problem. You'll get Classical CAN frames
or CAN FD frames and can process them the same way.
When sending to CAN devices make sure that the device is capable to handle
@@ -842,6 +875,8 @@
RX_RTR_FRAME:
Send reply for RTR-request (placed in op->frames[0]).
+CAN_FD_FRAME:
+ The CAN frames following the bcm_msg_head are struct canfd_frame's
Broadcast Manager Transmission Timers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1026,7 +1061,7 @@
stats - SocketCAN core statistics (rx/tx frames, match ratios, ...)
reset_stats - manual statistic reset
- version - prints the SocketCAN core version and the ABI version
+ version - prints SocketCAN core and ABI version (removed in Linux 5.10)
Writing Own CAN Protocol Modules
@@ -1070,7 +1105,7 @@
dev->type = ARPHRD_CAN; /* the netdevice hardware type */
dev->flags = IFF_NOARP; /* CAN has no arp */
- dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */
+ dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> Classical CAN interface */
or alternative, when the controller supports CAN with flexible data rate:
dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */
@@ -1184,6 +1219,7 @@
[ fd { on | off } ]
[ fd-non-iso { on | off } ]
[ presume-ack { on | off } ]
+ [ cc-len8-dlc { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
@@ -1326,22 +1362,22 @@
second bit timing has to be specified in order to enable the CAN FD bitrate.
Additionally CAN FD capable CAN controllers support up to 64 bytes of
-payload. The representation of this length in can_frame.can_dlc and
+payload. The representation of this length in can_frame.len and
canfd_frame.len for userspace applications and inside the Linux network
layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
-The data length code was a 1:1 mapping to the payload length in the legacy
+The data length code was a 1:1 mapping to the payload length in the Classical
CAN frames anyway. The payload length to the bus-relevant DLC mapping is
only performed inside the CAN drivers, preferably with the helper
-functions can_dlc2len() and can_len2dlc().
+functions can_fd_dlc2len() and can_fd_len2dlc().
The CAN netdevice driver capabilities can be distinguished by the network
devices maximum transfer unit (MTU)::
- MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device
+ MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => Classical CAN device
MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device
The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
-N.B. CAN FD capable devices can also handle and send legacy CAN frames.
+N.B. CAN FD capable devices can also handle and send Classical CAN frames.
When configuring CAN FD capable CAN controllers an additional 'data' bitrate
has to be set. This bitrate for the data phase of the CAN FD frame has to be
diff --git a/Documentation/networking/device_drivers/ethernet/3com/vortex.rst b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
index eab10fc..e89e419 100644
--- a/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
+++ b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
@@ -374,8 +374,8 @@
email address will be in the driver source or in the MAINTAINERS file.
- The contents of your report will vary a lot depending upon the
- problem. If it's a kernel crash then you should refer to the
- admin-guide/reporting-bugs.rst file.
+ problem. If it's a kernel crash then you should refer to
+ 'Documentation/admin-guide/reporting-issues.rst'.
But for most problems it is useful to provide the following:
diff --git a/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst
index d5458da..14eb0a4 100644
--- a/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst
+++ b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst
@@ -34,7 +34,7 @@
two address regions is important (the driver expects these to be address
and then data).
-An example from arch/arm/mach-s3c2410/mach-bast.c is::
+An example from arch/arm/mach-s3c/mach-bast.c is::
static struct resource bast_dm9k_resource[] = {
[0] = {
diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
index 88f5083..d3fcf53 100644
--- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
+++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
@@ -12,6 +12,7 @@
- `Overview`_
- `Drivers`_
- `Basic packet flow`_
+- `Devlink health reporters`_
Overview
========
@@ -157,3 +158,52 @@
3. The SQ descriptor ring is maintained in buffers allocated from SQ mapped pool of NPA block LF.
4. NIX block transmits the pkt on the designated channel.
5. NPC MCAM entries can be installed to divert pkt onto a different channel.
+
+Devlink health reporters
+========================
+
+NPA Reporters
+-------------
+The NPA reporters are responsible for reporting and recovering the following group of errors
+1. GENERAL events
+ - Error due to operation of unmapped PF.
+ - Error due to disabled alloc/free for other HW blocks (NIX, SSO, TIM, DPI and AURA).
+2. ERROR events
+ - Fault due to NPA_AQ_INST_S read or NPA_AQ_RES_S write.
+ - AQ Doorbell Error.
+3. RAS events
+ - RAS Error Reporting for NPA_AQ_INST_S/NPA_AQ_RES_S.
+4. RVU events
+ - Error due to unmapped slot.
+
+Sample Output
+-------------
+~# devlink health
+pci/0002:01:00.0:
+ reporter hw_npa_intr
+ state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true
+ reporter hw_npa_gen
+ state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true
+ reporter hw_npa_err
+ state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true
+ reporter hw_npa_ras
+ state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true
+
+Each reporter dumps the
+ - Error Type
+ - Error Register value
+ - Reason in words
+
+For eg:
+~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen
+ NPA_AF_GENERAL:
+ NPA General Interrupt Reg : 1
+ NIX0: free disabled RX
+~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr
+ NPA_AF_RVU:
+ NPA RVU Interrupt Reg : 1
+ Unmap Slot Error
+~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err
+ NPA_AF_ERR:
+ NPA Error Interrupt Reg : 4096
+ AQ Doorbell Error
diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst
index ef719ce..d875f3e 100644
--- a/Documentation/networking/devlink/devlink-trap.rst
+++ b/Documentation/networking/devlink/devlink-trap.rst
@@ -476,6 +476,10 @@
* - ``esp_parsing``
- ``drop``
- Traps packets dropped due to an error in the ESP header parsing
+ * - ``blackhole_nexthop``
+ - ``drop``
+ - Traps packets that the device decided to drop in case they hit a
+ blackhole nexthop
Driver-specific Packet Traps
============================
diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst
index 2a266b7..02c2d20 100644
--- a/Documentation/networking/devlink/netdevsim.rst
+++ b/Documentation/networking/devlink/netdevsim.rst
@@ -46,7 +46,7 @@
=========
The ``netdevsim`` driver exposes resources to control the number of FIB
-entries and FIB rule entries that the driver will allow.
+entries, FIB rule entries and nexthops that the driver will allow.
.. code:: shell
@@ -54,6 +54,7 @@
$ devlink resource set netdevsim/netdevsim0 path /IPv4/fib-rules size 16
$ devlink resource set netdevsim/netdevsim0 path /IPv6/fib size 64
$ devlink resource set netdevsim/netdevsim0 path /IPv6/fib-rules size 16
+ $ devlink resource set netdevsim/netdevsim0 path /nexthops size 16
$ devlink dev reload netdevsim/netdevsim0
Driver-specific Traps
diff --git a/Documentation/networking/framerelay.rst b/Documentation/networking/framerelay.rst
deleted file mode 100644
index 6d90439..0000000
--- a/Documentation/networking/framerelay.rst
+++ /dev/null
@@ -1,44 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-================
-Frame Relay (FR)
-================
-
-Frame Relay (FR) support for linux is built into a two tiered system of device
-drivers. The upper layer implements RFC1490 FR specification, and uses the
-Data Link Connection Identifier (DLCI) as its hardware address. Usually these
-are assigned by your network supplier, they give you the number/numbers of
-the Virtual Connections (VC) assigned to you.
-
-Each DLCI is a point-to-point link between your machine and a remote one.
-As such, a separate device is needed to accommodate the routing. Within the
-net-tools archives is 'dlcicfg'. This program will communicate with the
-base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'...
-The configuration script will ask you how many DLCIs you need, as well as
-how many DLCIs you want to assign to each Frame Relay Access Device (FRAD).
-
-The DLCI uses a number of function calls to communicate with the FRAD, all
-of which are stored in the FRAD's private data area. assoc/deassoc,
-activate/deactivate and dlci_config. The DLCI supplies a receive function
-to the FRAD to accept incoming packets.
-
-With this initial offering, only 1 FRAD driver is available. With many thanks
-to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E &
-S508 are supported. This driver is currently set up for only FR, but as
-Sangoma makes more firmware modules available, it can be updated to provide
-them as well.
-
-Configuration of the FRAD makes use of another net-tools program, 'fradcfg'.
-This program makes use of a configuration file (which dlcicfg can also read)
-to specify the types of boards to be configured as FRADs, as well as perform
-any board specific configuration. The Sangoma module of fradcfg loads the
-FR firmware into the card, sets the irq/port/memory information, and provides
-an initial configuration.
-
-Additional FRAD device drivers can be added as hardware is available.
-
-At this time, the dlcicfg and fradcfg programs have not been incorporated into
-the net-tools distribution. They can be found at ftp.invlogic.com, in
-/pub/linux. Note that with OS/2 FTPD, you end up in /pub by default, so just
-use 'cd linux'. v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for
-pre-2.0.4 and later.
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 63ef386..b8a2999 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -52,7 +52,6 @@
eql
fib_trie
filter
- framerelay
generic-hdlc
generic_netlink
gen_stats
@@ -70,6 +69,7 @@
lapb-module
mac80211-injection
mpls-sysctl
+ mptcp-sysctl
multiqueue
netconsole
netdev-features
@@ -101,6 +101,7 @@
tcp-thin
team
timestamping
+ tipc
tproxy
tuntap
udplite
diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 25e6673..dd2b12a 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1554,6 +1554,9 @@
Default: 1000 (1 seconds)
+ignore_routes_with_linkdown - BOOLEAN
+ Ignore routes whose link is down when performing a FIB lookup.
+
promote_secondaries - BOOLEAN
When a primary IP address is removed from this interface
promote a corresponding secondary IP address instead of
@@ -2642,6 +2645,37 @@
Default: 1
+udp_port - INTEGER
+ The listening port for the local UDP tunneling sock. Normally it's
+ using the IANA-assigned UDP port number 9899 (sctp-tunneling).
+
+ This UDP sock is used for processing the incoming UDP-encapsulated
+ SCTP packets (from RFC6951), and shared by all applications in the
+ same net namespace. This UDP sock will be closed when the value is
+ set to 0.
+
+ The value will also be used to set the src port of the UDP header
+ for the outgoing UDP-encapsulated SCTP packets. For the dest port,
+ please refer to 'encap_port' below.
+
+ Default: 0
+
+encap_port - INTEGER
+ The default remote UDP encapsulation port.
+
+ This value is used to set the dest port of the UDP header for the
+ outgoing UDP-encapsulated SCTP packets by default. Users can also
+ change the value for each sock/asoc/transport by using setsockopt.
+ For further information, please refer to RFC6951.
+
+ Note that when connecting to a remote server, the client should set
+ this to the port that the UDP tunneling sock on the peer server is
+ listening to and the local UDP tunneling sock on the client also
+ must be started. On the server, it would get the encap_port from
+ the incoming packet's source port.
+
+ Default: 0
+
``/proc/sys/net/core/*``
========================
diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst
index 0a4b73b..b705d28 100644
--- a/Documentation/networking/j1939.rst
+++ b/Documentation/networking/j1939.rst
@@ -69,18 +69,56 @@
PGN
---
+The J1939 protocol uses the 29-bit CAN identifier with the following structure:
+
+ ============ ============== ====================
+ 29 bit CAN-ID
+ --------------------------------------------------
+ Bit positions within the CAN-ID
+ --------------------------------------------------
+ 28 ... 26 25 ... 8 7 ... 0
+ ============ ============== ====================
+ Priority PGN SA (Source Address)
+ ============ ============== ====================
+
The PGN (Parameter Group Number) is a number to identify a packet. The PGN
is composed as follows:
-1 bit : Reserved Bit
-1 bit : Data Page
-8 bits : PF (PDU Format)
-8 bits : PS (PDU Specific)
+
+ ============ ============== ================= =================
+ PGN
+ ------------------------------------------------------------------
+ Bit positions within the CAN-ID
+ ------------------------------------------------------------------
+ 25 24 23 ... 16 15 ... 8
+ ============ ============== ================= =================
+ R (Reserved) DP (Data Page) PF (PDU Format) PS (PDU Specific)
+ ============ ============== ================= =================
In J1939-21 distinction is made between PDU1 format (where PF < 240) and PDU2
format (where PF >= 240). Furthermore, when using the PDU2 format, the PS-field
contains a so-called Group Extension, which is part of the PGN. When using PDU2
format, the Group Extension is set in the PS-field.
+ ============== ========================
+ PDU1 Format (specific) (peer to peer)
+ ----------------------------------------
+ Bit positions within the CAN-ID
+ ----------------------------------------
+ 23 ... 16 15 ... 8
+ ============== ========================
+ 00h ... EFh DA (Destination address)
+ ============== ========================
+
+ ============== ========================
+ PDU2 Format (global) (broadcast)
+ ----------------------------------------
+ Bit positions within the CAN-ID
+ ----------------------------------------
+ 23 ... 16 15 ... 8
+ ============== ========================
+ F0h ... FFh GE (Group Extenstion)
+ ============== ========================
+
On the other hand, when using PDU1 format, the PS-field contains a so-called
Destination Address, which is _not_ part of the PGN. When communicating a PGN
from user space to kernel (or vice versa) and PDU2 format is used, the PS-field
diff --git a/Documentation/networking/kapi.rst b/Documentation/networking/kapi.rst
index d198fa5..ea55f46 100644
--- a/Documentation/networking/kapi.rst
+++ b/Documentation/networking/kapi.rst
@@ -83,27 +83,6 @@
.. kernel-doc:: net/sunrpc/clnt.c
:export:
-WiMAX
------
-
-.. kernel-doc:: net/wimax/op-msg.c
- :export:
-
-.. kernel-doc:: net/wimax/op-reset.c
- :export:
-
-.. kernel-doc:: net/wimax/op-rfkill.c
- :export:
-
-.. kernel-doc:: net/wimax/stack.c
- :export:
-
-.. kernel-doc:: include/net/wimax.h
- :internal:
-
-.. kernel-doc:: include/uapi/linux/wimax.h
- :internal:
-
Network device support
======================
diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst
new file mode 100644
index 0000000..6af0196
--- /dev/null
+++ b/Documentation/networking/mptcp-sysctl.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+MPTCP Sysfs variables
+=====================
+
+/proc/sys/net/mptcp/* Variables
+===============================
+
+enabled - INTEGER
+ Control whether MPTCP sockets can be created.
+
+ MPTCP sockets can be created if the value is nonzero. This is
+ a per-namespace sysctl.
+
+ Default: 1
+
+add_addr_timeout - INTEGER (seconds)
+ Set the timeout after which an ADD_ADDR control message will be
+ resent to an MPTCP peer that has not acknowledged a previous
+ ADD_ADDR message.
+
+ The default value matches TCP_RTO_MAX. This is a per-namespace
+ sysctl.
+
+ Default: 120
diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst
index 43088dd..a147591 100644
--- a/Documentation/networking/page_pool.rst
+++ b/Documentation/networking/page_pool.rst
@@ -97,6 +97,14 @@
* page_pool_get_dma_dir(): Retrieve the stored DMA direction.
+* page_pool_put_page_bulk(): Tries to refill a number of pages into the
+ ptr_ring cache holding ptr_ring producer lock. If the ptr_ring is full,
+ page_pool_put_page_bulk() will release leftover pages to the page allocator.
+ page_pool_put_page_bulk() is suitable to be run inside the driver NAPI tx
+ completion loop for the XDP_REDIRECT use case.
+ Please note the caller must not use data area after running
+ page_pool_put_page_bulk(), as this function overwrites it.
+
Coding examples
===============
diff --git a/Documentation/networking/ppp_generic.rst b/Documentation/networking/ppp_generic.rst
index e605043..5a10abc 100644
--- a/Documentation/networking/ppp_generic.rst
+++ b/Documentation/networking/ppp_generic.rst
@@ -314,6 +314,22 @@
it is connected to. It will return an EINVAL error if the channel
is not connected to an interface.
+* PPPIOCBRIDGECHAN bridges a channel with another. The argument should
+ point to an int containing the channel number of the channel to bridge
+ to. Once two channels are bridged, frames presented to one channel by
+ ppp_input() are passed to the bridge instance for onward transmission.
+ This allows frames to be switched from one channel into another: for
+ example, to pass PPPoE frames into a PPPoL2TP session. Since channel
+ bridging interrupts the normal ppp_input() path, a given channel may
+ not be part of a bridge at the same time as being part of a unit.
+ This ioctl will return an EALREADY error if the channel is already
+ part of a bridge or unit, or ENXIO if the requested channel does not
+ exist.
+
+* PPPIOCUNBRIDGECHAN performs the inverse of PPPIOCBRIDGECHAN, unbridging
+ a channel pair. This ioctl will return an EINVAL error if the channel
+ does not form part of a bridge.
+
* All other ioctl commands are passed to the channel ioctl() function.
The ioctl calls that are available on an instance that is attached to
diff --git a/Documentation/networking/tipc.rst b/Documentation/networking/tipc.rst
new file mode 100644
index 0000000..76775f2
--- /dev/null
+++ b/Documentation/networking/tipc.rst
@@ -0,0 +1,100 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+Linux Kernel TIPC
+=================
+
+TIPC (Transparent Inter Process Communication) is a protocol that is
+specially designed for intra-cluster communication.
+
+For more information about TIPC, see http://tipc.sourceforge.net.
+
+TIPC Base Types
+---------------
+
+.. kernel-doc:: net/tipc/subscr.h
+ :internal:
+
+.. kernel-doc:: net/tipc/bearer.h
+ :internal:
+
+.. kernel-doc:: net/tipc/name_table.h
+ :internal:
+
+.. kernel-doc:: net/tipc/name_distr.h
+ :internal:
+
+.. kernel-doc:: net/tipc/bcast.c
+ :internal:
+
+TIPC Bearer Interfaces
+----------------------
+
+.. kernel-doc:: net/tipc/bearer.c
+ :internal:
+
+.. kernel-doc:: net/tipc/udp_media.c
+ :internal:
+
+TIPC Crypto Interfaces
+----------------------
+
+.. kernel-doc:: net/tipc/crypto.c
+ :internal:
+
+TIPC Discoverer Interfaces
+--------------------------
+
+.. kernel-doc:: net/tipc/discover.c
+ :internal:
+
+TIPC Link Interfaces
+--------------------
+
+.. kernel-doc:: net/tipc/link.c
+ :internal:
+
+TIPC msg Interfaces
+-------------------
+
+.. kernel-doc:: net/tipc/msg.c
+ :internal:
+
+TIPC Name Interfaces
+--------------------
+
+.. kernel-doc:: net/tipc/name_table.c
+ :internal:
+
+.. kernel-doc:: net/tipc/name_distr.c
+ :internal:
+
+TIPC Node Management Interfaces
+-------------------------------
+
+.. kernel-doc:: net/tipc/node.c
+ :internal:
+
+TIPC Socket Interfaces
+----------------------
+
+.. kernel-doc:: net/tipc/socket.c
+ :internal:
+
+TIPC Network Topology Interfaces
+--------------------------------
+
+.. kernel-doc:: net/tipc/subscr.c
+ :internal:
+
+TIPC Server Interfaces
+----------------------
+
+.. kernel-doc:: net/tipc/topsrv.c
+ :internal:
+
+TIPC Trace Interfaces
+---------------------
+
+.. kernel-doc:: net/tipc/trace.c
+ :internal:
diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
index 37773da..0f55c6d 100644
--- a/Documentation/networking/tls-offload.rst
+++ b/Documentation/networking/tls-offload.rst
@@ -524,7 +524,13 @@
TLS device features
-------------------
-Drivers should ignore the changes to TLS the device feature flags.
+Drivers should ignore the changes to the TLS device feature flags.
These flags will be acted upon accordingly by the core ``ktls`` code.
TLS device feature flags only control adding of new TLS connection
offloads, old connections will remain active after flags are cleared.
+
+TLS encryption cannot be offloaded to devices without checksum calculation
+offload. Hence, TLS TX device feature flag requires NETIF_F_HW_CSUM being set.
+Disabling the latter implies clearing the former. Disabling TX checksum offload
+should not affect old connections, and drivers should make sure checksum
+calculation does not break for them.
diff --git a/Documentation/networking/x25.rst b/Documentation/networking/x25.rst
index 00e45d3..e11d9eb 100644
--- a/Documentation/networking/x25.rst
+++ b/Documentation/networking/x25.rst
@@ -19,13 +19,11 @@
unintelligent X.25 card drivers and not by intelligent ones, this would
provide a uniform device driver interface, and simplify configuration.
-To confuse matters a little, an 802.2 LLC implementation for Linux is being
-written which will allow X.25 to be run over an Ethernet (or Token Ring) and
-conform with the JNT "Pink Book", this will have a different interface to
-the Packet Layer but there will be no confusion since the class of device
-being served by the LLC will be completely separate from LAPB. The LLC
-implementation is being done as part of another protocol project (SNA) and
-by a different author.
+To confuse matters a little, an 802.2 LLC implementation is also possible
+which could allow X.25 to be run over an Ethernet (or Token Ring) and
+conform with the JNT "Pink Book", this would have a different interface to
+the Packet Layer but there would be no confusion since the class of device
+being served by the LLC would be completely separate from LAPB.
Just when you thought that it could not become more confusing, another
option appeared, XOT. This allows X.25 Packet Layer frames to operate over
diff --git a/Documentation/nios2/features.rst b/Documentation/nios2/features.rst
new file mode 100644
index 0000000..8449e63
--- /dev/null
+++ b/Documentation/nios2/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features nios2
diff --git a/Documentation/nios2/index.rst b/Documentation/nios2/index.rst
new file mode 100644
index 0000000..4468fe1
--- /dev/null
+++ b/Documentation/nios2/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Nios II Specific Documentation
+==============================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ nios2
+ features
diff --git a/Documentation/openrisc/features.rst b/Documentation/openrisc/features.rst
new file mode 100644
index 0000000..3f7c40d
--- /dev/null
+++ b/Documentation/openrisc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features openrisc
diff --git a/Documentation/openrisc/index.rst b/Documentation/openrisc/index.rst
index 748b3ee..6879f99 100644
--- a/Documentation/openrisc/index.rst
+++ b/Documentation/openrisc/index.rst
@@ -10,6 +10,8 @@
openrisc_port
todo
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/parisc/features.rst b/Documentation/parisc/features.rst
new file mode 100644
index 0000000..501d7c4
--- /dev/null
+++ b/Documentation/parisc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features parisc
diff --git a/Documentation/parisc/index.rst b/Documentation/parisc/index.rst
index aa3ee04..2406857 100644
--- a/Documentation/parisc/index.rst
+++ b/Documentation/parisc/index.rst
@@ -10,6 +10,8 @@
debugging
registers
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst
index a6fb986..60ac091 100644
--- a/Documentation/power/energy-model.rst
+++ b/Documentation/power/energy-model.rst
@@ -20,6 +20,21 @@
abstraction layer which standardizes the format of power cost tables in the
kernel, hence enabling to avoid redundant work.
+The power values might be expressed in milli-Watts or in an 'abstract scale'.
+Multiple subsystems might use the EM and it is up to the system integrator to
+check that the requirements for the power value scale types are met. An example
+can be found in the Energy-Aware Scheduler documentation
+Documentation/scheduler/sched-energy.rst. For some subsystems like thermal or
+powercap power values expressed in an 'abstract scale' might cause issues.
+These subsystems are more interested in estimation of power used in the past,
+thus the real milli-Watts might be needed. An example of these requirements can
+be found in the Intelligent Power Allocation in
+Documentation/driver-api/thermal/power_allocator.rst.
+Kernel subsystems might implement automatic detection to check whether EM
+registered devices have inconsistent scale (based on EM internal flag).
+Important thing to keep in mind is that when the power values are expressed in
+an 'abstract scale' deriving real energy in milli-Joules would not be possible.
+
The figure below depicts an example of drivers (Arm-specific here, but the
approach is applicable to any architecture) providing power costs to the EM
framework, and interested clients reading the data from it::
@@ -73,7 +88,7 @@
calling the following API::
int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
- struct em_data_callback *cb, cpumask_t *cpus);
+ struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts);
Drivers must provide a callback function returning <frequency, power> tuples
for each performance state. The callback function provided by the driver is free
@@ -81,6 +96,10 @@
deemed necessary. Only for CPU devices, drivers must specify the CPUs of the
performance domains using cpumask. For other devices than CPUs the last
argument must be set to NULL.
+The last argument 'milliwatts' is important to set with correct value. Kernel
+subsystems which use EM might rely on this flag to check if all EM devices use
+the same scale. If there are different scales, these subsystems might decide
+to: return warning/error, stop working or panic.
See Section 3. for an example of driver implementing this
callback, and kernel/power/energy_model.c for further documentation on this
API.
@@ -156,7 +175,8 @@
37 nr_opp = foo_get_nr_opp(policy);
38
39 /* And register the new performance domain */
- 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus);
- 41
- 42 return 0;
- 43 }
+ 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus,
+ 41 true);
+ 42
+ 43 return 0;
+ 44 }
diff --git a/Documentation/powerpc/features.rst b/Documentation/powerpc/features.rst
new file mode 100644
index 0000000..aeae73d
--- /dev/null
+++ b/Documentation/powerpc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features powerpc
diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index 6ec64b0..bf5f1a2 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -34,6 +34,8 @@
vas-api
vcpudispatch_stats
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/process/clang-format.rst b/Documentation/process/clang-format.rst
index 82676e5..1d089a8 100644
--- a/Documentation/process/clang-format.rst
+++ b/Documentation/process/clang-format.rst
@@ -97,7 +97,7 @@
There are integrations for many popular text editors. For some of them,
like vim, emacs, BBEdit and Visual Studio you can find support built-in.
-For instructions, read the appropiate section at:
+For instructions, read the appropriate section at:
https://clang.llvm.org/docs/ClangFormat.html
diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst
index 43cdc67..6f8f36e 100644
--- a/Documentation/process/embargoed-hardware-issues.rst
+++ b/Documentation/process/embargoed-hardware-issues.rst
@@ -152,7 +152,7 @@
entities who have already been, or should be, informed about the issue.
This serves several purposes:
- - The list of disclosed entities allows communication accross the
+ - The list of disclosed entities allows communication across the
industry, e.g. other OS vendors, HW vendors, etc.
- The disclosed entities can be contacted to name experts who should
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 20c9e07..7a5c105 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -348,11 +348,10 @@
https://bugzilla.kernel.org/page.cgi?id=faq.html
-The file :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
-in the main kernel source directory has a good
-template for how to report a possible kernel bug, and details what kind
-of information is needed by the kernel developers to help track down the
-problem.
+The file 'Documentation/admin-guide/reporting-issues.rst' in the main kernel
+source directory has a good template for how to report a possible kernel bug,
+and details what kind of information is needed by the kernel developers to help
+track down the problem.
Managing bug reports
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index 64786e5..22d9ace 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -90,7 +90,7 @@
:Date: 2008
:Keywords: patches, review process, types of submissions, basic rules, case studies
:Description: This paper gives several experience values on what types of patches
- there are and how likley they get merged.
+ there are and how likely they get merged.
:Abstract:
[...]. This paper examines some common problems for
submitting larger changes and some strategies to avoid problems.
@@ -328,7 +328,7 @@
block devices, hardware interrupts, scsi, DMA, access to user memory,
memory allocation, timers.
:Description: A guide designed to help you get up to speed on the
- concepts that are not intuitevly obvious, and to document the internal
+ concepts that are not intuitively obvious, and to document the internal
structures of Linux.
* Title: **Dynamic Kernels: Modularized Device Drivers**
diff --git a/Documentation/process/magic-number.rst b/Documentation/process/magic-number.rst
index eee9b44..e02ff5f 100644
--- a/Documentation/process/magic-number.rst
+++ b/Documentation/process/magic-number.rst
@@ -84,7 +84,6 @@
SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h``
SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c``
-X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h``
SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h``
AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h``
TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h``
diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst
index 1879f88..230ee42 100644
--- a/Documentation/process/submit-checklist.rst
+++ b/Documentation/process/submit-checklist.rst
@@ -75,44 +75,44 @@
13) Has been build- and runtime tested with and without ``CONFIG_SMP`` and
``CONFIG_PREEMPT.``
-16) All codepaths have been exercised with all lockdep features enabled.
+14) All codepaths have been exercised with all lockdep features enabled.
-17) All new ``/proc`` entries are documented under ``Documentation/``
+15) All new ``/proc`` entries are documented under ``Documentation/``
-18) All new kernel boot parameters are documented in
+16) All new kernel boot parameters are documented in
``Documentation/admin-guide/kernel-parameters.rst``.
-19) All new module parameters are documented with ``MODULE_PARM_DESC()``
+17) All new module parameters are documented with ``MODULE_PARM_DESC()``
-20) All new userspace interfaces are documented in ``Documentation/ABI/``.
+18) All new userspace interfaces are documented in ``Documentation/ABI/``.
See ``Documentation/ABI/README`` for more information.
Patches that change userspace interfaces should be CCed to
linux-api@vger.kernel.org.
-21) Check that it all passes ``make headers_check``.
+19) Check that it all passes ``make headers_check``.
-22) Has been checked with injection of at least slab and page-allocation
+20) Has been checked with injection of at least slab and page-allocation
failures. See ``Documentation/fault-injection/``.
If the new code is substantial, addition of subsystem-specific fault
injection might be appropriate.
-23) Newly-added code has been compiled with ``gcc -W`` (use
+21) Newly-added code has been compiled with ``gcc -W`` (use
``make EXTRA_CFLAGS=-W``). This will generate lots of noise, but is good
for finding bugs like "warning: comparison between signed and unsigned".
-24) Tested after it has been merged into the -mm patchset to make sure
+22) Tested after it has been merged into the -mm patchset to make sure
that it still works with all of the other queued patches and various
changes in the VM, VFS, and other subsystems.
-25) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a
+23) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a
comment in the source code that explains the logic of what they are doing
and why.
-26) If any ioctl's are added by the patch, then also update
+24) If any ioctl's are added by the patch, then also update
``Documentation/userspace-api/ioctl/ioctl-number.rst``.
-27) If your modified source code depends on or uses any of the kernel
+25) If your modified source code depends on or uses any of the kernel
APIs or features that are related to the following ``Kconfig`` symbols,
then test multiple builds with the related ``Kconfig`` symbols disabled
and/or ``=m`` (if that option is available) [not all of these at the
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 83d9a82..5ba5412 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -404,11 +404,19 @@
using your real name (sorry, no pseudonyms or anonymous contributions.)
This will be done for you automatically if you use ``git commit -s``.
+Reverts should also include "Signed-off-by". ``git revert -s`` does that
+for you.
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
+Any further SoBs (Signed-off-by:'s) following the author's SoB are from
+people handling and transporting the patch, but were not involved in its
+development. SoB chains should reflect the **real** route a patch took
+as it was propagated to the maintainers and ultimately to Linus, with
+the first SoB entry signalling primary authorship of a single author.
+
When to use Acked-by:, Cc:, and Co-developed-by:
------------------------------------------------
@@ -444,7 +452,7 @@
have been included in the discussion.
Co-developed-by: states that the patch was co-created by multiple developers;
-it is a used to give attribution to co-authors (in addition to the author
+it is used to give attribution to co-authors (in addition to the author
attributed by the From: tag) when several people work on a single patch. Since
Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
followed by a Signed-off-by: of the associated co-author. Standard sign-off
diff --git a/Documentation/riscv/features.rst b/Documentation/riscv/features.rst
new file mode 100644
index 0000000..c70ef6a
--- /dev/null
+++ b/Documentation/riscv/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features riscv
diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index fa33bff..6e6e394 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -9,6 +9,8 @@
pmu
patch-acceptance
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/s390/features.rst b/Documentation/s390/features.rst
new file mode 100644
index 0000000..57c296a
--- /dev/null
+++ b/Documentation/s390/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features s390
diff --git a/Documentation/s390/index.rst b/Documentation/s390/index.rst
index cf71df5..b10ca91 100644
--- a/Documentation/s390/index.rst
+++ b/Documentation/s390/index.rst
@@ -19,6 +19,8 @@
text_files
+ features
+
.. only:: subproject and html
Indices
diff --git a/Documentation/scheduler/sched-domains.rst b/Documentation/scheduler/sched-domains.rst
index 5c4b7f4..8582fa5 100644
--- a/Documentation/scheduler/sched-domains.rst
+++ b/Documentation/scheduler/sched-domains.rst
@@ -65,21 +65,17 @@
cpumask of a node. Or, you could do multi-level NUMA or Opteron, for example,
might have just one domain covering its one NUMA level.
-The implementor should read comments in include/linux/sched.h:
-struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
-the specifics and what to tune.
+The implementor should read comments in include/linux/sched/sd_flags.h:
+SD_* to get an idea of the specifics and what to tune for the SD flags
+of a sched_domain.
-Architectures may retain the regular override the default SD_*_INIT flags
-while using the generic domain builder in kernel/sched/core.c if they wish to
-retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
-can be done by #define'ing ARCH_HASH_SCHED_TUNE.
-
-Alternatively, the architecture may completely override the generic domain
-builder by #define'ing ARCH_HASH_SCHED_DOMAIN, and exporting your
-arch_init_sched_domains function. This function will attach domains to all
-CPUs using cpu_attach_domain.
+Architectures may override the generic domain builder and the default SD flags
+for a given topology level by creating a sched_domain_topology_level array and
+calling set_sched_topology() with this array as the parameter.
The sched-domains debugging infrastructure can be enabled by enabling
-CONFIG_SCHED_DEBUG. This enables an error checking parse of the sched domains
-which should catch most possible errors (described above). It also prints out
-the domain structure in a visual format.
+CONFIG_SCHED_DEBUG and adding 'sched_debug' to your cmdline. If you forgot to
+tweak your cmdline, you can also flip the /sys/kernel/debug/sched_debug
+knob. This enables an error checking parse of the sched domains which should
+catch most possible errors (described above). It also prints out the domain
+structure in a visual format.
diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst
index 001e09c..afe02d3 100644
--- a/Documentation/scheduler/sched-energy.rst
+++ b/Documentation/scheduler/sched-energy.rst
@@ -350,6 +350,11 @@
Please also note that the scheduling domains need to be re-built after the
EM has been registered in order to start EAS.
+EAS uses the EM to make a forecasting decision on energy usage and thus it is
+more focused on the difference when checking possible options for task
+placement. For EAS it doesn't matter whether the EM power values are expressed
+in milli-Watts or in an 'abstract scale'.
+
6.3 - Energy Model complexity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/Documentation/sh/features.rst b/Documentation/sh/features.rst
new file mode 100644
index 0000000..f722af3
--- /dev/null
+++ b/Documentation/sh/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features sh
diff --git a/Documentation/sh/index.rst b/Documentation/sh/index.rst
index 7b9a79a..c647767 100644
--- a/Documentation/sh/index.rst
+++ b/Documentation/sh/index.rst
@@ -11,6 +11,8 @@
new-machine
register-banks
+ features
+
Memory Management
=================
diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst
index c755b1c..fe52c31 100644
--- a/Documentation/sound/alsa-configuration.rst
+++ b/Documentation/sound/alsa-configuration.rst
@@ -2227,6 +2227,11 @@
Quirk alias list, pass strings like ``0123abcd:5678beef``, which
applies the existing quirk for the device 5678:beef to a new
device 0123:abcd.
+implicit_fb
+ Apply the generic implicit feedback sync mode. When this is set
+ and the playback stream sync mode is ASYNC, the driver tries to
+ tie an adjacent ASYNC capture stream as the implicit feedback
+ source.
use_vmalloc
Use vmalloc() for allocations of the PCM buffers (default: yes).
For architectures with non-coherent memory like ARM or MIPS, the
diff --git a/Documentation/sparc/features.rst b/Documentation/sparc/features.rst
new file mode 100644
index 0000000..c0c9246
--- /dev/null
+++ b/Documentation/sparc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features sparc
diff --git a/Documentation/sparc/index.rst b/Documentation/sparc/index.rst
index 71cff62..ae88422 100644
--- a/Documentation/sparc/index.rst
+++ b/Documentation/sparc/index.rst
@@ -9,3 +9,5 @@
adi
oradax/oracle-dax
+
+ features
diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py
index 3e81eba..953b24b 100644
--- a/Documentation/sphinx/automarkup.py
+++ b/Documentation/sphinx/automarkup.py
@@ -53,6 +53,8 @@
#
RE_doc = re.compile(r'\bDocumentation(/[\w\-_/]+)(\.\w+)*')
+RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
+
#
# Reserved C words that we should skip when cross-referencing
#
@@ -70,6 +72,8 @@
'select', 'poll', 'fork', 'execve', 'clone', 'ioctl',
'socket' ]
+c_namespace = ''
+
def markup_refs(docname, app, node):
t = node.astext()
done = 0
@@ -128,30 +132,38 @@
#
# Go through the dance of getting an xref out of the C domain
#
- target = match.group(2)
+ base_target = match.group(2)
target_text = nodes.Text(match.group(0))
xref = None
- if not (target in Skipfuncs or target in Skipnames):
- for class_s, reftype_s in zip(class_str, reftype_str):
- lit_text = nodes.literal(classes=['xref', 'c', class_s])
- lit_text += target_text
- pxref = addnodes.pending_xref('', refdomain = 'c',
- reftype = reftype_s,
- reftarget = target, modname = None,
- classname = None)
- #
- # XXX The Latex builder will throw NoUri exceptions here,
- # work around that by ignoring them.
- #
- try:
- xref = cdom.resolve_xref(app.env, docname, app.builder,
- reftype_s, target, pxref,
- lit_text)
- except NoUri:
- xref = None
+ possible_targets = [base_target]
+ # Check if this document has a namespace, and if so, try
+ # cross-referencing inside it first.
+ if c_namespace:
+ possible_targets.insert(0, c_namespace + "." + base_target)
- if xref:
- return xref
+ if base_target not in Skipnames:
+ for target in possible_targets:
+ if target not in Skipfuncs:
+ for class_s, reftype_s in zip(class_str, reftype_str):
+ lit_text = nodes.literal(classes=['xref', 'c', class_s])
+ lit_text += target_text
+ pxref = addnodes.pending_xref('', refdomain = 'c',
+ reftype = reftype_s,
+ reftarget = target, modname = None,
+ classname = None)
+ #
+ # XXX The Latex builder will throw NoUri exceptions here,
+ # work around that by ignoring them.
+ #
+ try:
+ xref = cdom.resolve_xref(app.env, docname, app.builder,
+ reftype_s, target, pxref,
+ lit_text)
+ except NoUri:
+ xref = None
+
+ if xref:
+ return xref
return target_text
@@ -179,34 +191,39 @@
#
# Go through the dance of getting an xref out of the C domain
#
- target = match.group(2)
+ base_target = match.group(2)
target_text = nodes.Text(match.group(0))
xref = None
- if not ((match.re == RE_function and target in Skipfuncs)
- or (target in Skipnames)):
- lit_text = nodes.literal(classes=['xref', 'c', class_str[match.re]])
- lit_text += target_text
- pxref = addnodes.pending_xref('', refdomain = 'c',
- reftype = reftype_str[match.re],
- reftarget = target, modname = None,
- classname = None)
- #
- # XXX The Latex builder will throw NoUri exceptions here,
- # work around that by ignoring them.
- #
- try:
- xref = cdom.resolve_xref(app.env, docname, app.builder,
- reftype_str[match.re], target, pxref,
- lit_text)
- except NoUri:
- xref = None
- #
- # Return the xref if we got it; otherwise just return the plain text.
- #
- if xref:
- return xref
- else:
- return target_text
+ possible_targets = [base_target]
+ # Check if this document has a namespace, and if so, try
+ # cross-referencing inside it first.
+ if c_namespace:
+ possible_targets.insert(0, c_namespace + "." + base_target)
+
+ if base_target not in Skipnames:
+ for target in possible_targets:
+ if not (match.re == RE_function and target in Skipfuncs):
+ lit_text = nodes.literal(classes=['xref', 'c', class_str[match.re]])
+ lit_text += target_text
+ pxref = addnodes.pending_xref('', refdomain = 'c',
+ reftype = reftype_str[match.re],
+ reftarget = target, modname = None,
+ classname = None)
+ #
+ # XXX The Latex builder will throw NoUri exceptions here,
+ # work around that by ignoring them.
+ #
+ try:
+ xref = cdom.resolve_xref(app.env, docname, app.builder,
+ reftype_str[match.re], target, pxref,
+ lit_text)
+ except NoUri:
+ xref = None
+
+ if xref:
+ return xref
+
+ return target_text
#
# Try to replace a documentation reference of the form Documentation/... with a
@@ -239,7 +256,18 @@
else:
return nodes.Text(match.group(0))
+def get_c_namespace(app, docname):
+ source = app.env.doc2path(docname)
+ with open(source) as f:
+ for l in f:
+ match = RE_namespace.search(l)
+ if match:
+ return match.group(1)
+ return ''
+
def auto_markup(app, doctree, name):
+ global c_namespace
+ c_namespace = get_c_namespace(app, name)
#
# This loop could eventually be improved on. Someday maybe we
# want a proper tree traversal with a lot of awareness of which
diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py
new file mode 100644
index 0000000..2fee04f
--- /dev/null
+++ b/Documentation/sphinx/kernel_feat.py
@@ -0,0 +1,169 @@
+# coding=utf-8
+# SPDX-License-Identifier: GPL-2.0
+#
+u"""
+ kernel-feat
+ ~~~~~~~~~~~
+
+ Implementation of the ``kernel-feat`` reST-directive.
+
+ :copyright: Copyright (C) 2016 Markus Heiser
+ :copyright: Copyright (C) 2016-2019 Mauro Carvalho Chehab
+ :maintained-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+ :license: GPL Version 2, June 1991 see Linux/COPYING for details.
+
+ The ``kernel-feat`` (:py:class:`KernelFeat`) directive calls the
+ scripts/get_feat.pl script to parse the Kernel ABI files.
+
+ Overview of directive's argument and options.
+
+ .. code-block:: rst
+
+ .. kernel-feat:: <ABI directory location>
+ :debug:
+
+ The argument ``<ABI directory location>`` is required. It contains the
+ location of the ABI files to be parsed.
+
+ ``debug``
+ Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
+ what reST is generated.
+
+"""
+
+import codecs
+import os
+import subprocess
+import sys
+
+from os import path
+
+from docutils import nodes, statemachine
+from docutils.statemachine import ViewList
+from docutils.parsers.rst import directives, Directive
+from docutils.utils.error_reporting import ErrorString
+
+#
+# AutodocReporter is only good up to Sphinx 1.7
+#
+import sphinx
+
+Use_SSI = sphinx.__version__[:3] >= '1.7'
+if Use_SSI:
+ from sphinx.util.docutils import switch_source_input
+else:
+ from sphinx.ext.autodoc import AutodocReporter
+
+__version__ = '1.0'
+
+def setup(app):
+
+ app.add_directive("kernel-feat", KernelFeat)
+ return dict(
+ version = __version__
+ , parallel_read_safe = True
+ , parallel_write_safe = True
+ )
+
+class KernelFeat(Directive):
+
+ u"""KernelFeat (``kernel-feat``) directive"""
+
+ required_arguments = 1
+ optional_arguments = 2
+ has_content = False
+ final_argument_whitespace = True
+
+ option_spec = {
+ "debug" : directives.flag
+ }
+
+ def warn(self, message, **replace):
+ replace["fname"] = self.state.document.current_source
+ replace["line_no"] = replace.get("line_no", self.lineno)
+ message = ("%(fname)s:%(line_no)s: [kernel-feat WARN] : " + message) % replace
+ self.state.document.settings.env.app.warn(message, prefix="")
+
+ def run(self):
+
+ doc = self.state.document
+ if not doc.settings.file_insertion_enabled:
+ raise self.warning("docutils: file insertion disabled")
+
+ env = doc.settings.env
+ cwd = path.dirname(doc.current_source)
+ cmd = "get_feat.pl rest --dir "
+ cmd += self.arguments[0]
+
+ if len(self.arguments) > 1:
+ cmd += " --arch " + self.arguments[1]
+
+ srctree = path.abspath(os.environ["srctree"])
+
+ fname = cmd
+
+ # extend PATH with $(srctree)/scripts
+ path_env = os.pathsep.join([
+ srctree + os.sep + "scripts",
+ os.environ["PATH"]
+ ])
+ shell_env = os.environ.copy()
+ shell_env["PATH"] = path_env
+ shell_env["srctree"] = srctree
+
+ lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
+ nodeList = self.nestedParse(lines, fname)
+ return nodeList
+
+ def runCmd(self, cmd, **kwargs):
+ u"""Run command ``cmd`` and return it's stdout as unicode."""
+
+ try:
+ proc = subprocess.Popen(
+ cmd
+ , stdout = subprocess.PIPE
+ , stderr = subprocess.PIPE
+ , **kwargs
+ )
+ out, err = proc.communicate()
+
+ out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
+
+ if proc.returncode != 0:
+ raise self.severe(
+ u"command '%s' failed with return code %d"
+ % (cmd, proc.returncode)
+ )
+ except OSError as exc:
+ raise self.severe(u"problems with '%s' directive: %s."
+ % (self.name, ErrorString(exc)))
+ return out
+
+ def nestedParse(self, lines, fname):
+ content = ViewList()
+ node = nodes.section()
+
+ if "debug" in self.options:
+ code_block = "\n\n.. code-block:: rst\n :linenos:\n"
+ for l in lines.split("\n"):
+ code_block += "\n " + l
+ lines = code_block + "\n\n"
+
+ for c, l in enumerate(lines.split("\n")):
+ content.append(l, fname, c)
+
+ buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
+
+ if Use_SSI:
+ with switch_source_input(self.state, content):
+ self.state.nested_parse(content, 0, node, match_titles=1)
+ else:
+ self.state.memo.title_styles = []
+ self.state.memo.section_level = 0
+ self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter)
+ try:
+ self.state.nested_parse(content, 0, node, match_titles=1)
+ finally:
+ self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
+
+ return node.children
diff --git a/Documentation/sphinx/parse-headers.pl b/Documentation/sphinx/parse-headers.pl
index 1910079..b063f2f 100755
--- a/Documentation/sphinx/parse-headers.pl
+++ b/Documentation/sphinx/parse-headers.pl
@@ -1,4 +1,4 @@
-#!/usr/bin/perl
+#!/usr/bin/env perl
use strict;
use Text::Tabs;
use Getopt::Long;
diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt
index 489f662..5030d34 100644
--- a/Documentation/sphinx/requirements.txt
+++ b/Documentation/sphinx/requirements.txt
@@ -1,3 +1,4 @@
docutils
Sphinx==2.4.4
sphinx_rtd_theme
+six
diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py
index 1548d84..54492aa 100755
--- a/Documentation/target/tcm_mod_builder.py
+++ b/Documentation/target/tcm_mod_builder.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
# The TCM v4 multi-protocol fabric module generation script for drivers/target/$NEW_MOD
#
# Copyright (c) 2010 Rising Tide Systems
diff --git a/Documentation/trace/events-kmem.rst b/Documentation/trace/events-kmem.rst
index 5554841..68fa752 100644
--- a/Documentation/trace/events-kmem.rst
+++ b/Documentation/trace/events-kmem.rst
@@ -69,7 +69,7 @@
Broadly speaking, pages are taken off the LRU lock in bulk and
freed in batch with a page list. Significant amounts of activity here could
indicate that the system is under memory pressure and can also indicate
-contention on the zone->lru_lock.
+contention on the lruvec->lru_lock.
4. Per-CPU Allocator Activity
=============================
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index 2a5aa48..8ddb9b0 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -798,13 +798,13 @@
synth_event_trace_start() function is used to 'open' the synthetic
event trace::
- struct synth_trace_state trace_state;
+ struct synth_event_trace_state trace_state;
ret = synth_event_trace_start(schedtest_event_file, &trace_state);
It's passed the trace_event_file representing the synthetic event
using the same methods as described above, along with a pointer to a
-struct synth_trace_state object, which will be zeroed before use and
+struct synth_event_trace_state object, which will be zeroed before use and
used to maintain state between this and following calls.
Once the event has been opened, which means space for it has been
@@ -816,7 +816,7 @@
To assign the values one after the other without lookups,
synth_event_add_next_val() should be used. Each call is passed the
-same synth_trace_state object used in the synth_event_trace_start(),
+same synth_event_trace_state object used in the synth_event_trace_start(),
along with the value to set the next field in the event. After each
field is set, the 'cursor' points to the next field, which will be set
by the subsequent call, continuing until all the fields have been set
@@ -845,7 +845,7 @@
ret = synth_event_add_next_val(395, &trace_state);
To assign the values in any order, synth_event_add_val() should be
-used. Each call is passed the same synth_trace_state object used in
+used. Each call is passed the same synth_event_trace_state object used in
the synth_event_trace_start(), along with the field name of the field
to set and the value to set it to. The same sequence of calls as in
the above examples using this method would be (without error-handling
@@ -867,7 +867,7 @@
Finally, the event won't be actually traced until it's 'closed',
which is done using synth_event_trace_end(), which takes only the
-struct synth_trace_state object used in the previous calls::
+struct synth_event_trace_state object used in the previous calls::
ret = synth_event_trace_end(&trace_state);
diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst
index a4955f7..f7d98ae 100644
--- a/Documentation/trace/ftrace-uses.rst
+++ b/Documentation/trace/ftrace-uses.rst
@@ -30,8 +30,8 @@
This requires extra care to what can be done inside a callback. A callback
can be called outside the protective scope of RCU.
-The ftrace infrastructure has some protections against recursions and RCU
-but one must still be very careful how they use the callbacks.
+There are helper functions to help against recursion, and making sure
+RCU is watching. These are explained below.
The ftrace_ops structure
@@ -108,6 +108,58 @@
at the start of the function where ftrace was tracing. Otherwise it
either contains garbage, or NULL.
+Protect your callback
+=====================
+
+As functions can be called from anywhere, and it is possible that a function
+called by a callback may also be traced, and call that same callback,
+recursion protection must be used. There are two helper functions that
+can help in this regard. If you start your code with:
+
+.. code-block:: c
+
+ int bit;
+
+ bit = ftrace_test_recursion_trylock(ip, parent_ip);
+ if (bit < 0)
+ return;
+
+and end it with:
+
+.. code-block:: c
+
+ ftrace_test_recursion_unlock(bit);
+
+The code in between will be safe to use, even if it ends up calling a
+function that the callback is tracing. Note, on success,
+ftrace_test_recursion_trylock() will disable preemption, and the
+ftrace_test_recursion_unlock() will enable it again (if it was previously
+enabled). The instruction pointer (ip) and its parent (parent_ip) is passed to
+ftrace_test_recursion_trylock() to record where the recursion happened
+(if CONFIG_FTRACE_RECORD_RECURSION is set).
+
+Alternatively, if the FTRACE_OPS_FL_RECURSION flag is set on the ftrace_ops
+(as explained below), then a helper trampoline will be used to test
+for recursion for the callback and no recursion test needs to be done.
+But this is at the expense of a slightly more overhead from an extra
+function call.
+
+If your callback accesses any data or critical section that requires RCU
+protection, it is best to make sure that RCU is "watching", otherwise
+that data or critical section will not be protected as expected. In this
+case add:
+
+.. code-block:: c
+
+ if (!rcu_is_watching())
+ return;
+
+Alternatively, if the FTRACE_OPS_FL_RCU flag is set on the ftrace_ops
+(as explained below), then a helper trampoline will be used to test
+for rcu_is_watching for the callback and no other test needs to be done.
+But this is at the expense of a slightly more overhead from an extra
+function call.
+
The ftrace FLAGS
================
@@ -128,26 +180,20 @@
will not fail with this flag set. But the callback must check if
regs is NULL or not to determine if the architecture supports it.
-FTRACE_OPS_FL_RECURSION_SAFE
- By default, a wrapper is added around the callback to
- make sure that recursion of the function does not occur. That is,
- if a function that is called as a result of the callback's execution
- is also traced, ftrace will prevent the callback from being called
- again. But this wrapper adds some overhead, and if the callback is
- safe from recursion, it can set this flag to disable the ftrace
- protection.
+FTRACE_OPS_FL_RECURSION
+ By default, it is expected that the callback can handle recursion.
+ But if the callback is not that worried about overehead, then
+ setting this bit will add the recursion protection around the
+ callback by calling a helper function that will do the recursion
+ protection and only call the callback if it did not recurse.
- Note, if this flag is set, and recursion does occur, it could cause
- the system to crash, and possibly reboot via a triple fault.
+ Note, if this flag is not set, and recursion does occur, it could
+ cause the system to crash, and possibly reboot via a triple fault.
- It is OK if another callback traces a function that is called by a
- callback that is marked recursion safe. Recursion safe callbacks
- must never trace any function that are called by the callback
- itself or any nested functions that those functions call.
-
- If this flag is set, it is possible that the callback will also
- be called with preemption enabled (when CONFIG_PREEMPTION is set),
- but this is not guaranteed.
+ Not, if this flag is set, then the callback will always be called
+ with preemption disabled. If it is not set, then it is possible
+ (but not guaranteed) that the callback will be called in
+ preemptable context.
FTRACE_OPS_FL_IPMODIFY
Requires FTRACE_OPS_FL_SAVE_REGS set. If the callback is to "hijack"
diff --git a/Documentation/trace/postprocess/decode_msr.py b/Documentation/trace/postprocess/decode_msr.py
index 0ab40e0..aa9cc7a 100644
--- a/Documentation/trace/postprocess/decode_msr.py
+++ b/Documentation/trace/postprocess/decode_msr.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
# add symbolic names to read_msr / write_msr in trace
# decode_msr msr-index.h < trace
import sys
diff --git a/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl b/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl
index 0a120aa..b9b7d80 100644
--- a/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl
@@ -1,4 +1,4 @@
-#!/usr/bin/perl
+#!/usr/bin/env perl
# This is a POC (proof of concept or piece of crap, take your pick) for reading the
# text representation of trace output related to page allocation. It makes an attempt
# to extract some high-level information on what is going on. The accuracy of the parser
diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
index 995da15..2f4e398 100644
--- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
@@ -1,4 +1,4 @@
-#!/usr/bin/perl
+#!/usr/bin/env perl
# This is a POC for reading the text representation of trace output related to
# page reclaim. It makes an attempt to extract some high-level information on
# what is going on. The accuracy of the parser may vary
diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
index 524ad86..009cdac 100644
--- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
+++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
@@ -419,26 +419,24 @@
Riferimenti usando reStructuredText
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Per fare riferimento a funzioni e tipi di dato definiti nei commenti kernel-doc
-all'interno dei documenti reStructuredText, utilizzate i riferimenti dal
-`dominio Sphinx per il C`_. Per esempio::
+Nei documenti reStructuredText non serve alcuna sintassi speciale per
+fare riferimento a funzioni e tipi definiti nei commenti
+kernel-doc. Sarà sufficiente terminare i nomi di funzione con ``()``,
+e scrivere ``struct``, ``union``, ``enum``, o ``typedef`` prima di un
+tipo. Per esempio::
- See function :c:func:`foo` and struct/union/enum/typedef :c:type:`bar`.
+ See foo()
+ See struct foo.
+ See union bar.
+ See enum baz.
+ See typedef meh.
-Nonostante il riferimento ai tipi di dato funzioni col solo nome,
-ovvero senza specificare struct/union/enum/typedef, potreste preferire il
-seguente::
+Tuttavia, la personalizzazione dei collegamenti è possibile solo con
+la seguente sintassi::
- See :c:type:`struct foo <foo>`.
- See :c:type:`union bar <bar>`.
- See :c:type:`enum baz <baz>`.
- See :c:type:`typedef meh <meh>`.
+ See :c:func:`my custom link text for function foo <foo>`.
+ See :c:type:`my custom link text for struct bar <bar>`.
-Questo produce dei collegamenti migliori, ed è in linea con il modo in cui
-kernel-doc gestisce i riferimenti.
-
-Per maggiori informazioni, siete pregati di consultare la documentazione
-del `dominio Sphinx per il C`_.
Commenti per una documentazione generale
----------------------------------------
diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst b/Documentation/translations/it_IT/doc-guide/sphinx.rst
index f1ad450..090d294 100644
--- a/Documentation/translations/it_IT/doc-guide/sphinx.rst
+++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst
@@ -364,6 +364,26 @@
- column 3
+Riferimenti incrociati
+----------------------
+
+Per fare dei riferimenti incrociati da una pagina ad un'altra
+specificando il percorso a partire dalla cartella *Documentation*.
+Per esempio, se volete aggiungere un riferimento a questa pagina
+(l'estensione .rst è opzionale)::
+
+ See Documentation/translations/it_IT/doc-guide/sphinx.rst.
+
+Se preferite usare un percorso relative allora vi serve la direttiva
+Sphinx ``doc``. Per esempio, se volete aggiungere un riferimento a
+questa pagina dalla stessa cartella::
+
+ See :doc:`sphinx`.
+
+Per maggiori informazioni su come aggiungere riferimenti incrociati a
+commenti kernel-doc di funzioni o tipi, leggete
+Documentation/translations/it_IT/doc-guide/sphinx.rst.
+
.. _it_sphinx_kfigure:
Figure ed immagini
diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst
index 30dc172..6282603 100644
--- a/Documentation/translations/it_IT/process/2.Process.rst
+++ b/Documentation/translations/it_IT/process/2.Process.rst
@@ -123,7 +123,7 @@
Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
============== ===============================
- 15 settembre 5.2 rilascio stabile FIXME settembre è sbagliato
+ 7 luglio 5.2 rilascio stabile
14 luglio 5.2.1
21 luglio 5.2.2
26 luglio 5.2.3
@@ -434,7 +434,7 @@
http://vger.kernel.org/vger-lists.html
Esistono liste gestite altrove; un certo numero di queste sono in
-lists.redhat.com.
+redhat.com/mailman/listinfo.
La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst
index 37da444..cc883f8 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -32,9 +32,10 @@
====================== ================= ========================================
Programma Versione minima Comando per verificare la versione
====================== ================= ========================================
-GNU C 4.6 gcc --version
+GNU C 4.9 gcc --version
+Clang/LLVM (optional) 10.0.1 clang --version
GNU make 3.81 make --version
-binutils 2.21 ld -v
+binutils 2.23 ld -v
flex 2.5.35 flex --version
bison 2.0 bison --version
util-linux 2.10o fdformat --version
@@ -71,6 +72,16 @@
La versione necessaria di gcc potrebbe variare a seconda del tipo di CPU nel
vostro calcolatore.
+Clang/LLVM (opzionale)
+----------------------
+
+L'ultima versione di clang e *LLVM utils* (secondo `releases.llvm.org
+<https://releases.llvm.org>`_) sono supportati per la generazione del
+kernel. Non garantiamo che anche i rilasci più vecchi funzionino, inoltre
+potremmo rimuovere gli espedienti che abbiamo implementato per farli
+funzionare. Per maggiori informazioni
+:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
+
Make
----
@@ -79,7 +90,7 @@
Binutils
--------
-Per generare il kernel è necessario avere Binutils 2.21 o superiore.
+Per generare il kernel è necessario avere Binutils 2.23 o superiore.
pkg-config
----------
@@ -338,6 +349,11 @@
- <ftp://ftp.gnu.org/gnu/gcc/>
+Clang/LLVM
+----------
+
+- :ref:`Getting LLVM <getting_llvm>`.
+
Make
----
diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst
index a346f1f..c86c454 100644
--- a/Documentation/translations/it_IT/process/coding-style.rst
+++ b/Documentation/translations/it_IT/process/coding-style.rst
@@ -92,16 +92,22 @@
Lo stile del codice riguarda la leggibilità e la manutenibilità utilizzando
strumenti comuni.
-Il limite delle righe è di 80 colonne e questo e un limite fortemente
-desiderato.
+Come limite di riga si preferiscono le 80 colonne.
-Espressioni più lunghe di 80 colonne saranno spezzettate in pezzi più piccoli,
-a meno che eccedere le 80 colonne non aiuti ad aumentare la leggibilità senza
-nascondere informazioni. I pezzi derivati sono sostanzialmente più corti degli
-originali e vengono posizionati più a destra. Lo stesso si applica, nei file
-d'intestazione, alle funzioni con una lista di argomenti molto lunga. Tuttavia,
-non spezzettate mai le stringhe visibili agli utenti come i messaggi di
-printk, questo perché inibireste la possibilità d'utilizzare grep per cercarle.
+Espressioni più lunghe di 80 colonne dovrebbero essere spezzettate in
+pezzi più piccoli, a meno che eccedere le 80 colonne non aiuti ad
+aumentare la leggibilità senza nascondere informazioni.
+
+I nuovi pezzi derivati sono sostanzialmente più corti degli originali
+e vengono posizionati più a destra. Uno stile molto comune è quello di
+allineare i nuovi pezzi alla parentesi aperta di una funzione.
+
+Lo stesso si applica, nei file d'intestazione, alle funzioni con una
+lista di argomenti molto lunga.
+
+Tuttavia, non spezzettate mai le stringhe visibili agli utenti come i
+messaggi di printk, questo perché inibireste la possibilità
+d'utilizzare grep per cercarle.
3) Posizionamento di parentesi graffe e spazi
---------------------------------------------
diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst
index a642ff3..07c79d4 100644
--- a/Documentation/translations/it_IT/process/deprecated.rst
+++ b/Documentation/translations/it_IT/process/deprecated.rst
@@ -95,6 +95,11 @@
header = kzalloc(struct_size(header, item, count), GFP_KERNEL);
+.. note:: Se per caso state usando struct_size() su una struttura dati che
+ in coda contiene un array di lunghezza zero o uno, allora siete
+ invitati a riorganizzare il vostro codice usando il
+ `flexible array member <#zero-length-and-one-element-arrays>`_.
+
Per maggiori dettagli fate riferimento a array_size(),
array3_size(), e struct_size(), così come la famiglia di
funzioni check_add_overflow() e check_mul_overflow().
@@ -116,7 +121,11 @@
buffer e generare svariati tipi di malfunzionamenti. Nonostante l'opzione
`CONFIG_FORTIFY_SOURCE=y` e svariate opzioni del compilatore aiutano
a ridurne il rischio, non c'è alcuna buona ragione per continuare ad usare
-questa funzione. La versione sicura da usare è strscpy().
+questa funzione. La versione sicura da usare è strscpy(), tuttavia va
+prestata attenzione a tutti quei casi dove viene usato il valore di
+ritorno di strcpy(). La funzione strscpy() non ritorna un puntatore
+alla destinazione, ma un contatore dei byte non NUL copiati (oppure
+un errno negativo se la stringa è stata troncata).
strncpy() su stringe terminate con NUL
--------------------------------------
@@ -127,8 +136,12 @@
terminazione nel buffer di destinazione quando la stringa d'origine è più
corta; questo potrebbe portare ad una penalizzazione delle prestazioni per
chi usa solo stringe terminate. La versione sicura da usare è
-strscpy(). (chi usa strscpy() e necessita di estendere la
-terminazione con NUL deve aggiungere una chiamata a memset())
+strscpy(), tuttavia va prestata attenzione a tutti quei casi dove
+viene usato il valore di ritorno di strncpy(). La funzione strscpy()
+non ritorna un puntatore alla destinazione, ma un contatore dei byte
+non NUL copiati (oppure un errno negativo se la stringa è stata
+troncata). Tutti i casi che necessitano di estendere la
+terminazione con NUL dovrebbero usare strscpy_pad().
Se il chiamate no usa stringhe terminate con NUL, allore strncpy()
può continuare ad essere usata, ma i buffer di destinazione devono essere
@@ -140,7 +153,10 @@
La funzione strlcpy(), per prima cosa, legge interamente il buffer di
origine, magari leggendo più di quanto verrà effettivamente copiato. Questo
è inefficiente e può portare a overflow di lettura quando la stringa non è
-terminata con NUL. La versione sicura da usare è strscpy().
+terminata con NUL. La versione sicura da usare è strscpy(), tuttavia
+va prestata attenzione a tutti quei casi dove viene usato il valore di
+ritorno di strlcpy(), dato che strscpy() ritorna un valore di errno
+negativo quanto la stringa viene troncata.
Segnaposto %p nella stringa di formato
--------------------------------------
@@ -227,3 +243,126 @@
* ``continue;``
* ``goto <label>;``
* ``return [expression];``
+
+Array di lunghezza zero o con un solo elemento
+----------------------------------------------
+All'interno del kernel ricorre spesso la necessita di avere membri
+di dimensione variabile all'interno di una struttura dati. In questi
+casi il codice del kernel dovrebbe usare sempre i `"flexible array
+member" <https://en.wikipedia.org/wiki/Flexible_array_member>`_. La
+tecnica degli array a lunghezza nulla o di un solo elemento non
+dovrebbe essere più usata.
+
+Nel codice C più vecchio, la dichiarazione di un membro di dimensione
+variabile in coda ad una struttura dati veniva fatto dichiarando un
+array di un solo elemento posizionato alla fine della struttura dati::
+
+ struct something {
+ size_t count;
+ struct foo items[1];
+ };
+
+Questo ha portato ad un calcolo di sizeof() traballante (dovrebbe
+rimuovere la dimensione del singolo elemento in coda per calcolare la
+dimensione esatta dell' "intestazione"). Per evitare questi problemi è
+stata introdotta un' `estensione a GNU C
+<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_ che
+permettesse la dichiarazione di array a lungezza zero::
+
+ struct something {
+ size_t count;
+ struct foo items[0];
+ };
+
+Ma questo ha portato nuovi problemi, e non ha risolto alcuni dei
+problemi che affliggono entrambe le tecniche: per esempio
+l'impossibilità di riconoscere se un array di quel tipo viene usato
+nel mezzo di una struttura dati e _non_ alla fine (potrebbe accadere
+sia direttamente, sia indirettamente quando si usano le unioni o le
+strutture di strutture).
+
+Lo standard C99 introduce i "flexible array members". Questi array non
+hanno una dimensione nella loro dichiarazione::
+
+ struct something {
+ size_t count;
+ struct foo items[];
+ };
+
+Questo è il modo con cui ci si aspetta che vengano dichiarati gli
+elementi di lunghezza variabile in coda alle strutture dati. Permette
+al compilatore di produrre errori quando gli array flessibili non si
+trovano alla fine della struttura dati, il che permette di prevenire
+alcuni tipi di bachi dovuti a `comportamenti inaspettati
+<https://git.kernel.org/linus/76497732932f15e7323dc805e8ea8dc11bb587cf>`_.
+Inoltre, permette al compilatore di analizzare correttamente le
+dimensioni degli array (attraverso sizeof(), `CONFIG_FORTIFY_SOURCE`,
+e `CONFIG_UBSAN_BOUNDS`). Per esempio, non esiste alcun meccanismo in
+grado di avvisarci che il seguente uso di sizeof() dia sempre come
+zero come risultato::
+
+ struct something {
+ size_t count;
+ struct foo items[0];
+ };
+
+ struct something *instance;
+
+ instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
+ instance->count = count;
+
+ size = sizeof(instance->items) * instance->count;
+ memcpy(instance->items, source, size);
+
+Il valore di ``size`` nell'ultima riga sarà ``zero``, quando uno
+invece si aspetterebbe che il suo valore sia la dimensione totale in
+byte dell'allocazione dynamica che abbiamo appena fatto per l'array
+``items``. Qui un paio di esempi reali del problema: `collegamento 1
+<https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_,
+`collegamento 2
+<https://git.kernel.org/linus/ab91c2a89f86be2898cee208d492816ec238b2cf>`_.
+Invece, `i flexible array members hanno un tipo incompleto, e quindi
+sizeof() non può essere applicato
+<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_; dunque ogni
+uso scorretto di questo operatore verrà identificato immediatamente
+durante la compilazione.
+
+Per quanto riguarda gli array di un solo elemento, bisogna essere
+consapevoli che `questi array occupano almeno quanto lo spazio di un
+singolo oggetti dello stesso tipo
+<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, e quindi
+contribuiscono al calcolo della dimensione della struttura che li
+contiene. In questo caso è facile commettere errori quando si vuole
+calcolare la dimensione totale della memoria totale da allocare per
+una struttura dati::
+
+ struct something {
+ size_t count;
+ struct foo items[1];
+ };
+
+ struct something *instance;
+
+ instance = kmalloc(struct_size(instance, items, count - 1), GFP_KERNEL);
+ instance->count = count;
+
+ size = sizeof(instance->items) * instance->count;
+ memcpy(instance->items, source, size);
+
+In questo esempio ci siamo dovuti ricordare di usare ``count - 1`` in
+struct_size(), altrimenti avremmo --inavvertitamente-- allocato
+memoria per un oggetti ``items`` in più. Il modo più pulito e meno
+propenso agli errori è quello di usare i `flexible array member`, in
+combinazione con struct_size() e flex_array_size()::
+
+ struct something {
+ size_t count;
+ struct foo items[];
+ };
+
+ struct something *instance;
+
+ instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
+ instance->count = count;
+
+ memcpy(instance->items, source, flex_array_size(instance, items, instance->count));
diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst
index 66d3d65..de7d32f 100644
--- a/Documentation/translations/it_IT/process/email-clients.rst
+++ b/Documentation/translations/it_IT/process/email-clients.rst
@@ -32,6 +32,11 @@
ben apprezzati perché rende più difficile citare porzioni di patch durante il
processo di revisione.
+Inoltre, è vivamente raccomandato l'uso di puro testo nel corpo del
+messaggio, sia per la patch che per qualsiasi altro messaggio. Il sito
+https://useplaintext.email/ può esservi d'aiuto per configurare il
+vostro programma di posta elettronica.
+
I programmi di posta elettronica che vengono usati per inviare le patch per il
kernel Linux dovrebbero inviarle senza alterazioni. Per esempio, non
dovrebbero modificare o rimuovere tabulazioni o spazi, nemmeno all'inizio o
diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst
index 783e0de3..0243d32 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -90,7 +90,6 @@
SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h``
SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c``
-X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h``
SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h``
AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h``
TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h``
diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst
index c4fc9d3..41db259 100644
--- a/Documentation/translations/it_IT/process/programming-language.rst
+++ b/Documentation/translations/it_IT/process/programming-language.rst
@@ -11,13 +11,15 @@
Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_.
Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando
l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU
-dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99)
+dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99).
+Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione
+:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
Questo dialetto contiene diverse estensioni al linguaggio [it-gnu-extensions]_,
e molte di queste vengono usate sistematicamente dal kernel.
-Il kernel offre un certo livello di supporto per la compilazione con ``clang``
-[it-clang]_ e ``icc`` [it-icc]_ su diverse architetture, tuttavia in questo momento
+Il kernel offre un certo livello di supporto per la compilazione con
+``icc`` [it-icc]_ su diverse architetture, tuttavia in questo momento
il supporto non è completo e richiede delle patch aggiuntive.
Attributi
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index 7c23c08e..966cd32 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/Documentation/translations/it_IT/process/submitting-patches.rst
@@ -16,21 +16,19 @@
Questo documento contiene un vasto numero di suggerimenti concisi. Per
maggiori dettagli su come funziona il processo di sviluppo del kernel leggete
-:ref:`Documentation/translations/it_IT/process <it_development_process_main>`.
-Leggete anche :ref:`Documentation/translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`
-per una lista di punti da verificare prima di inviare del codice. Se state
-inviando un driver, allora leggete anche :ref:`Documentation/translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`;
-per delle patch relative alle associazioni per Device Tree leggete
-Documentation/devicetree/bindings/submitting-patches.rst.
+:doc:`development-process`.
+Leggete anche :doc:`submit-checklist` per una lista di punti da
+verificare prima di inviare del codice. Se state inviando un driver,
+allora leggete anche :doc:`submitting-drivers`; per delle patch
+relative alle associazioni per Device Tree leggete
+:doc:`submitting-patches`.
-Molti di questi passi descrivono il comportamento di base del sistema di
-controllo di versione ``git``; se utilizzate ``git`` per preparare le vostre
-patch molto del lavoro più ripetitivo lo troverete già fatto per voi, tuttavia
-dovete preparare e documentare un certo numero di patch. Generalmente, l'uso
-di ``git`` renderà la vostra vita di sviluppatore del kernel più facile.
+Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
+Se non siete pratici di ``git``, allora è bene che lo impariate;
+renderà la vostra vita di sviluppatore del kernel molto più semplice.
-0) Ottenere i sorgenti attuali
-------------------------------
+Ottenere i sorgenti attuali
+---------------------------
Se non avete un repositorio coi sorgenti del kernel più recenti, allora usate
``git`` per ottenerli. Vorrete iniziare col repositorio principale che può
@@ -45,69 +43,10 @@
che troverete nei sorgenti, o semplicemente chiedete al manutentore nel caso
in cui i sorgenti da usare non siano elencati il quel file.
-Esiste ancora la possibilità di scaricare un rilascio del kernel come archivio
-tar (come descritto in una delle prossime sezioni), ma questa è la via più
-complicata per sviluppare per il kernel.
-
-1) ``diff -up``
----------------
-
-Se dovete produrre le vostre patch a mano, usate ``diff -up`` o ``diff -uprN``
-per crearle. Git produce di base le patch in questo formato; se state
-usando ``git``, potete saltare interamente questa sezione.
-
-Tutte le modifiche al kernel Linux avvengono mediate patch, come descritte
-in :manpage:`diff(1)`. Quando create la vostra patch, assicuratevi di
-crearla nel formato "unified diff", come l'argomento ``-u`` di
-:manpage:`diff(1)`.
-Inoltre, per favore usate l'argomento ``-p`` per mostrare la funzione C
-alla quale si riferiscono le diverse modifiche - questo rende il risultato
-di ``diff`` molto più facile da leggere. Le patch dovrebbero essere basate
-sulla radice dei sorgenti del kernel, e non sulle sue sottocartelle.
-
-Per creare una patch per un singolo file, spesso è sufficiente fare::
-
- SRCTREE=linux
- MYFILE=drivers/net/mydriver.c
-
- cd $SRCTREE
- cp $MYFILE $MYFILE.orig
- vi $MYFILE # make your change
- cd ..
- diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
-
-Per creare una patch per molteplici file, dovreste spacchettare i sorgenti
-"vergini", o comunque non modificati, e fare un ``diff`` coi vostri.
-Per esempio::
-
- MYSRC=/devel/linux
-
- tar xvfz linux-3.19.tar.gz
- mv linux-3.19 linux-3.19-vanilla
- diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
- linux-3.19-vanilla $MYSRC > /tmp/patch
-
-``dontdiff`` è una lista di file che sono generati durante il processo di
-compilazione del kernel; questi dovrebbero essere ignorati in qualsiasi
-patch generata con :manpage:`diff(1)`.
-
-Assicuratevi che la vostra patch non includa file che non ne fanno veramente
-parte. Al fine di verificarne la correttezza, assicuratevi anche di
-revisionare la vostra patch -dopo- averla generata con :manpage:`diff(1)`.
-
-Se le vostre modifiche producono molte differenze, allora dovrete dividerle
-in patch indipendenti che modificano le cose in passi logici; leggete
-:ref:`split_changes`. Questo faciliterà la revisione da parte degli altri
-sviluppatori, il che è molto importante se volete che la patch venga accettata.
-
-Se state utilizzando ``git``, ``git rebase -i`` può aiutarvi nel procedimento.
-Se non usate ``git``, un'alternativa popolare è ``quilt``
-<http://savannah.nongnu.org/projects/quilt>.
-
.. _it_describe_changes:
-2) Descrivete le vostre modifiche
----------------------------------
+Descrivete le vostre modifiche
+------------------------------
Descrivete il vostro problema. Esiste sempre un problema che via ha spinto
ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
@@ -208,10 +147,15 @@
[pretty]
fixes = Fixes: %h (\"%s\")
+Un esempio::
+
+ $ git log -1 --pretty=fixes 54a4f0239f2e
+ Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+
.. _it_split_changes:
-3) Separate le vostre modifiche
--------------------------------
+Separate le vostre modifiche
+----------------------------
Separate ogni **cambiamento logico** in patch distinte.
@@ -312,7 +256,8 @@
embargo potrebbe essere preso in considerazione per dare il tempo alle
distribuzioni di prendere la patch e renderla disponibile ai loro utenti;
in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna
-lista di discussione pubblica.
+lista di discussione pubblica. Leggete anche
+:doc:`/admin-guide/security-bugs`.
Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero
essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga::
@@ -354,8 +299,8 @@
"patch monkey" in modalità ritrasmissione)
-6) Niente: MIME, links, compressione, allegati. Solo puro testo
-----------------------------------------------------------------
+Niente: MIME, links, compressione, allegati. Solo puro testo
+-------------------------------------------------------------
Linus e gli altri sviluppatori del kernel devono poter commentare
le modifiche che sottomettete. Per uno sviluppatore è importante
@@ -364,7 +309,11 @@
una porzione specifica del vostro codice.
Per questa ragione tutte le patch devono essere inviate via e-mail
-come testo.
+come testo. Il modo più facile, e quello raccomandato, è con ``git
+send-email``. Al sito https://git-send-email.io è disponibile una
+guida interattiva sull'uso di ``git send-email``.
+
+Se decidete di non usare ``git send-email``:
.. warning::
@@ -381,28 +330,20 @@
Eccezione: se il vostro servizio di posta storpia le patch, allora qualcuno
potrebbe chiedervi di rinviarle come allegato MIME.
-Leggete :ref:`Documentation/translations/it_IT/process/email-clients.rst <it_email_clients>`
+Leggete :doc:`/translations/it_IT/process/email-clients`
per dei suggerimenti sulla configurazione del programmi di posta elettronica
per l'invio di patch intatte.
-7) Dimensione delle e-mail
---------------------------
+Rispondere ai commenti di revisione
+-----------------------------------
-Le grosse modifiche non sono adatte ad una lista di discussione, e nemmeno
-per alcuni manutentori. Se la vostra patch, non compressa, eccede i 300 kB
-di spazio, allora caricatela in una spazio accessibile su internet fornendo
-l'URL (collegamento) ad essa. Ma notate che se la vostra patch eccede i 300 kB
-è quasi certo che necessiti comunque di essere spezzettata.
-
-8) Rispondere ai commenti di revisione
---------------------------------------
-
-Quasi certamente i revisori vi invieranno dei commenti su come migliorare
-la vostra patch. Dovete rispondere a questi commenti; ignorare i revisori
-è un ottimo modo per essere ignorati. Riscontri o domande che non conducono
-ad una modifica del codice quasi certamente dovrebbero portare ad un commento
-nel changelog cosicché il prossimo revisore potrà meglio comprendere cosa stia
-accadendo.
+In risposta alla vostra email, quasi certamente i revisori vi
+invieranno dei commenti su come migliorare la vostra patch. Dovete
+rispondere a questi commenti; ignorare i revisori è un ottimo modo per
+essere ignorati. Riscontri o domande che non conducono ad una
+modifica del codice quasi certamente dovrebbero portare ad un commento
+nel changelog cosicché il prossimo revisore potrà meglio comprendere
+cosa stia accadendo.
Assicuratevi di dire ai revisori quali cambiamenti state facendo e di
ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
@@ -410,8 +351,12 @@
in questo caso, rispondete con educazione e concentratevi sul problema che
hanno evidenziato.
-9) Non scoraggiatevi - o impazientitevi
----------------------------------------
+Leggete :doc:`/translations/it_IT/process/email-clients` per
+le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare
+sulle liste di discussione.
+
+Non scoraggiatevi - o impazientitevi
+------------------------------------
Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate.
I revisori sono persone occupate e potrebbero non ricevere la vostra patch
@@ -424,17 +369,19 @@
rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
durante la finestra d'integrazione.
-10) Aggiungete PATCH nell'oggetto
----------------------------------
+Aggiungete PATCH nell'oggetto
+-----------------------------
Dato l'alto volume di e-mail per Linus, e la lista linux-kernel, è prassi
prefiggere il vostro oggetto con [PATCH]. Questo permette a Linus e agli
altri sviluppatori del kernel di distinguere facilmente le patch dalle altre
discussioni.
+``git send-email`` lo fa automaticamente.
-11) Firmate il vostro lavoro - Il certificato d'origine dello sviluppatore
---------------------------------------------------------------------------
+
+Firmate il vostro lavoro - Il certificato d'origine dello sviluppatore
+----------------------------------------------------------------------
Per migliorare la tracciabilità su "chi ha fatto cosa", specialmente per
quelle patch che per raggiungere lo stadio finale passano attraverso
@@ -477,65 +424,17 @@
Signed-off-by: Random J Developer <random@developer.example.org>
usando il vostro vero nome (spiacenti, non si accettano pseudonimi o
-contributi anonimi).
+contributi anonimi). Questo verrà fatto automaticamente se usate
+``git commit -s``. Anche il ripristino di uno stato precedente dovrebbe
+includere "Signed-off-by", se usate ``git revert -s`` questo verrà
+fatto automaticamente.
Alcune persone aggiungono delle etichette alla fine. Per ora queste verranno
ignorate, ma potete farlo per meglio identificare procedure aziendali interne o
per aggiungere dettagli circa la firma.
-Se siete un manutentore di un sottosistema o di un ramo, qualche volta dovrete
-modificare leggermente le patch che avete ricevuto al fine di poterle
-integrare; questo perché il codice non è esattamente lo stesso nei vostri
-sorgenti e in quelli dei vostri contributori. Se rispettate rigidamente la
-regola (c), dovreste chiedere al mittente di rifare la patch, ma questo è
-controproducente e una totale perdita di tempo ed energia. La regola (b)
-vi permette di correggere il codice, ma poi diventa davvero maleducato cambiare
-la patch di qualcuno e addossargli la responsabilità per i vostri bachi.
-Per risolvere questo problema dovreste aggiungere una riga, fra l'ultimo
-Signed-off-by e il vostro, che spiega la vostra modifica. Nonostante non ci
-sia nulla di obbligatorio, un modo efficace è quello di indicare il vostro
-nome o indirizzo email fra parentesi quadre, seguito da una breve descrizione;
-questo renderà abbastanza visibile chi è responsabile per le modifiche
-dell'ultimo minuto. Per esempio::
-
- Signed-off-by: Random J Developer <random@developer.example.org>
- [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
- Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
-
-Questa pratica è particolarmente utile se siete i manutentori di un ramo
-stabile ma al contempo volete dare credito agli autori, tracciare e integrare
-le modifiche, e proteggere i mittenti dalle lamentele. Notate che in nessuna
-circostanza è permessa la modifica dell'identità dell'autore (l'intestazione
-From), dato che è quella che appare nei changelog.
-
-Un appunto speciale per chi porta il codice su vecchie versioni. Sembra che
-sia comune l'utile pratica di inserire un'indicazione circa l'origine della
-patch all'inizio del messaggio di commit (appena dopo la riga dell'oggetto)
-al fine di migliorare la tracciabilità. Per esempio, questo è quello che si
-vede nel rilascio stabile 3.x-stable::
-
- Date: Tue Oct 7 07:26:38 2014 -0400
-
- libata: Un-break ATA blacklist
-
- commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream.
-
-E qui quello che potrebbe vedersi su un kernel più vecchio dove la patch è
-stata applicata::
-
- Date: Tue May 13 22:12:27 2008 +0200
-
- wireless, airo: waitbusy() won't delay
-
- [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
-
-Qualunque sia il formato, questa informazione fornisce un importante aiuto
-alle persone che vogliono seguire i vostri sorgenti, e quelle che cercano
-dei bachi.
-
-
-12) Quando utilizzare Acked-by:, Cc:, e Co-developed-by:
---------------------------------------------------------
+Quando utilizzare Acked-by:, Cc:, e Co-developed-by:
+----------------------------------------------------
L'etichetta Signed-off-by: indica che il firmatario è stato coinvolto nello
sviluppo della patch, o che era nel suo percorso di consegna.
@@ -604,8 +503,8 @@
Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
-13) Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
------------------------------------------------------------------------------
+Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
+-------------------------------------------------------------------------
L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi
e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro.
@@ -654,6 +553,13 @@
loro serietà nella revisione, accrescerà le probabilità che la vostra patch
venga integrate nel kernel.
+Quando si riceve una email sulla lista di discussione da un tester o
+un revisore, le etichette Tested-by o Reviewd-by devono essere
+aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
+la patch è cambiata in modo significativo, queste etichette potrebbero
+non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia
+della rimozione nel changelog della patch (subito dopo il separatore '---').
+
L'etichetta Suggested-by: indica che l'idea della patch è stata suggerita
dalla persona nominata e le da credito. Tenete a mente che questa etichetta
non dovrebbe essere aggiunta senza un permesso esplicito, specialmente se
@@ -669,8 +575,8 @@
patch. Per maggiori dettagli leggete :ref:`it_describe_changes`
-14) Il formato canonico delle patch
------------------------------------
+Il formato canonico delle patch
+-------------------------------
Questa sezione descrive il formato che dovrebbe essere usato per le patch.
Notate che se state usando un repositorio ``git`` per salvare le vostre patch
@@ -788,8 +694,8 @@
.. _it_explicit_in_reply_to:
-15) Usare esplicitamente In-Reply-To nell'intestazione
-------------------------------------------------------
+Usare esplicitamente In-Reply-To nell'intestazione
+--------------------------------------------------
Aggiungere manualmente In-Reply-To: nell'intestazione dell'e-mail
potrebbe essere d'aiuto per associare una patch ad una discussione
@@ -802,65 +708,6 @@
ad una versione precedente di una serie di patch (per esempio, potete usarlo
per l'email introduttiva alla serie).
-16) Inviare richieste ``git pull``
-----------------------------------
-
-Se avete una serie di patch, potrebbe essere più conveniente per un manutentore
-tirarle dentro al repositorio del sottosistema attraverso l'operazione
-``git pull``. Comunque, tenete presente che prendere patch da uno sviluppatore
-in questo modo richiede un livello di fiducia più alto rispetto a prenderle da
-una lista di discussione. Di conseguenza, molti manutentori sono riluttanti
-ad accettare richieste di *pull*, specialmente dagli sviluppatori nuovi e
-quindi sconosciuti. Se siete in dubbio, potete fare una richiesta di *pull*
-come messaggio introduttivo ad una normale pubblicazione di patch, così
-il manutentore avrà la possibilità di scegliere come integrarle.
-
-Una richiesta di *pull* dovrebbe avere nell'oggetto [GIT] o [PULL].
-La richiesta stessa dovrebbe includere il nome del repositorio e quello del
-ramo su una singola riga; dovrebbe essere più o meno così::
-
- Please pull from
-
- git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
-
- to get these changes:
-
-Una richiesta di *pull* dovrebbe includere anche un messaggio generico
-che dica cos'è incluso, una lista delle patch usando ``git shortlog``, e una
-panoramica sugli effetti della serie di patch con ``diffstat``. Il modo più
-semplice per ottenere tutte queste informazioni è, ovviamente, quello di
-lasciar fare tutto a ``git`` con il comando ``git request-pull``.
-
-Alcuni manutentori (incluso Linus) vogliono vedere le richieste di *pull*
-da commit firmati con GPG; questo fornisce una maggiore garanzia sul fatto
-che siate stati proprio voi a fare la richiesta. In assenza di tale etichetta
-firmata Linus, in particolare, non prenderà alcuna patch da siti pubblici come
-GitHub.
-
-Il primo passo verso la creazione di questa etichetta firmata è quello di
-creare una chiave GNUPG ed averla fatta firmare da uno o più sviluppatori
-principali del kernel. Questo potrebbe essere difficile per i nuovi
-sviluppatori, ma non ci sono altre vie. Andare alle conferenze potrebbe
-essere un buon modo per trovare sviluppatori che possano firmare la vostra
-chiave.
-
-Una volta che avete preparato la vostra serie di patch in ``git``, e volete che
-qualcuno le prenda, create una etichetta firmata col comando ``git tag -s``.
-Questo creerà una nuova etichetta che identifica l'ultimo commit della serie
-contenente una firma creata con la vostra chiave privata. Avrete anche
-l'opportunità di aggiungere un messaggio di changelog all'etichetta; questo è
-il posto ideale per descrivere gli effetti della richiesta di *pull*.
-
-Se i sorgenti da cui il manutentore prenderà le patch non sono gli stessi del
-repositorio su cui state lavorando, allora non dimenticatevi di caricare
-l'etichetta firmata anche sui sorgenti pubblici.
-
-Quando generate una richiesta di *pull*, usate l'etichetta firmata come
-obiettivo. Un comando come il seguente farà il suo dovere::
-
- git request-pull master git://my.public.tree/linux.git my-signed-tag
-
-
Riferimenti
-----------
diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
index ed5ab7e..48bbd3e 100644
--- a/Documentation/translations/zh_CN/admin-guide/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/index.rst
@@ -114,7 +114,6 @@
unicode
vga-softcursor
video-output
- wimax/index
xfs
.. only:: subproject and html
diff --git a/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
new file mode 100644
index 0000000..9aa4637
--- /dev/null
+++ b/Documentation/translations/zh_CN/arm64/elf_hwcaps.rst
@@ -0,0 +1,240 @@
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+
+================
+ARM64 ELF hwcaps
+================
+
+这篇文档描述了 arm64 ELF hwcaps 的用法和语义。
+
+
+1. 简介
+-------
+
+有些硬件或软件功能仅在某些 CPU 实现上和/或在具体某个内核配置上可用，但
+对于处于 EL0 的用户空间代码没有可用的架构发现机制。内核通过在辅助向量表
+公开一组称为 hwcaps 的标志而把这些功能暴露给用户空间。
+
+用户空间软件可以通过获取辅助向量的 AT_HWCAP 或 AT_HWCAP2 条目来测试功能，
+并测试是否设置了相关标志，例如::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+ if (hwcaps & HWCAP_FP)
+ return true;
+
+ return false;
+ }
+
+如果软件依赖于 hwcap 描述的功能，在尝试使用该功能前则应检查相关的 hwcap
+标志以验证该功能是否存在。
+
+不能通过其他方式探查这些功能。当一个功能不可用时，尝试使用它可能导致不可
+预测的行为，并且无法保证能确切的知道该功能不可用，例如 SIGILL。
+
+
+2. Hwcaps 的说明
+----------------
+
+大多数 hwcaps 旨在说明通过架构 ID 寄存器(处于 EL0 的用户空间代码无法访问)
+描述的功能的存在。这些 hwcap 通过 ID 寄存器字段定义，并且应根据 ARM 体系
+结构参考手册（ARM ARM）中定义的字段来解释说明。
+
+这些 hwcaps 以下面的形式描述::
+
+ idreg.field == val 表示有某个功能。
+
+当 idreg.field 中有 val 时，hwcaps 表示 ARM ARM 定义的功能是有效的，但是
+并不是说要完全和 val 相等，也不是说 idreg.field 描述的其他功能就是缺失的。
+
+其他 hwcaps 可能表明无法仅由 ID 寄存器描述的功能的存在。这些 hwcaps 可能
+没有被 ID 寄存器描述，需要参考其他文档。
+
+
+3. AT_HWCAP 中揭示的 hwcaps
+---------------------------
+
+HWCAP_FP
+ ID_AA64PFR0_EL1.FP == 0b0000 表示有此功能。
+
+HWCAP_ASIMD
+ ID_AA64PFR0_EL1.AdvSIMD == 0b0000 表示有此功能。
+
+HWCAP_EVTSTRM
+ 通用计时器频率配置为大约100KHz以生成事件。
+
+HWCAP_AES
+ ID_AA64ISAR0_EL1.AES == 0b0001 表示有此功能。
+
+HWCAP_PMULL
+ ID_AA64ISAR0_EL1.AES == 0b0010 表示有此功能。
+
+HWCAP_SHA1
+ ID_AA64ISAR0_EL1.SHA1 == 0b0001 表示有此功能。
+
+HWCAP_SHA2
+ ID_AA64ISAR0_EL1.SHA2 == 0b0001 表示有此功能。
+
+HWCAP_CRC32
+ ID_AA64ISAR0_EL1.CRC32 == 0b0001 表示有此功能。
+
+HWCAP_ATOMICS
+ ID_AA64ISAR0_EL1.Atomic == 0b0010 表示有此功能。
+
+HWCAP_FPHP
+ ID_AA64PFR0_EL1.FP == 0b0001 表示有此功能。
+
+HWCAP_ASIMDHP
+ ID_AA64PFR0_EL1.AdvSIMD == 0b0001 表示有此功能。
+
+HWCAP_CPUID
+ 根据 Documentation/arm64/cpu-feature-registers.rst 描述，EL0 可以访问
+ 某些 ID 寄存器。
+
+ 这些 ID 寄存器可能表示功能的可用性。
+
+HWCAP_ASIMDRDM
+ ID_AA64ISAR0_EL1.RDM == 0b0001 表示有此功能。
+
+HWCAP_JSCVT
+ ID_AA64ISAR1_EL1.JSCVT == 0b0001 表示有此功能。
+
+HWCAP_FCMA
+ ID_AA64ISAR1_EL1.FCMA == 0b0001 表示有此功能。
+
+HWCAP_LRCPC
+ ID_AA64ISAR1_EL1.LRCPC == 0b0001 表示有此功能。
+
+HWCAP_DCPOP
+ ID_AA64ISAR1_EL1.DPB == 0b0001 表示有此功能。
+
+HWCAP_SHA3
+ ID_AA64ISAR0_EL1.SHA3 == 0b0001 表示有此功能。
+
+HWCAP_SM3
+ ID_AA64ISAR0_EL1.SM3 == 0b0001 表示有此功能。
+
+HWCAP_SM4
+ ID_AA64ISAR0_EL1.SM4 == 0b0001 表示有此功能。
+
+HWCAP_ASIMDDP
+ ID_AA64ISAR0_EL1.DP == 0b0001 表示有此功能。
+
+HWCAP_SHA512
+ ID_AA64ISAR0_EL1.SHA2 == 0b0010 表示有此功能。
+
+HWCAP_SVE
+ ID_AA64PFR0_EL1.SVE == 0b0001 表示有此功能。
+
+HWCAP_ASIMDFHM
+ ID_AA64ISAR0_EL1.FHM == 0b0001 表示有此功能。
+
+HWCAP_DIT
+ ID_AA64PFR0_EL1.DIT == 0b0001 表示有此功能。
+
+HWCAP_USCAT
+ ID_AA64MMFR2_EL1.AT == 0b0001 表示有此功能。
+
+HWCAP_ILRCPC
+ ID_AA64ISAR1_EL1.LRCPC == 0b0010 表示有此功能。
+
+HWCAP_FLAGM
+ ID_AA64ISAR0_EL1.TS == 0b0001 表示有此功能。
+
+HWCAP_SSBS
+ ID_AA64PFR1_EL1.SSBS == 0b0010 表示有此功能。
+
+HWCAP_SB
+ ID_AA64ISAR1_EL1.SB == 0b0001 表示有此功能。
+
+HWCAP_PACA
+ 如 Documentation/arm64/pointer-authentication.rst 所描述，
+ ID_AA64ISAR1_EL1.APA == 0b0001 或 ID_AA64ISAR1_EL1.API == 0b0001
+ 表示有此功能。
+
+HWCAP_PACG
+ 如 Documentation/arm64/pointer-authentication.rst 所描述，
+ ID_AA64ISAR1_EL1.GPA == 0b0001 或 ID_AA64ISAR1_EL1.GPI == 0b0001
+ 表示有此功能。
+
+HWCAP2_DCPODP
+
+ ID_AA64ISAR1_EL1.DPB == 0b0010 表示有此功能。
+
+HWCAP2_SVE2
+
+ ID_AA64ZFR0_EL1.SVEVer == 0b0001 表示有此功能。
+
+HWCAP2_SVEAES
+
+ ID_AA64ZFR0_EL1.AES == 0b0001 表示有此功能。
+
+HWCAP2_SVEPMULL
+
+ ID_AA64ZFR0_EL1.AES == 0b0010 表示有此功能。
+
+HWCAP2_SVEBITPERM
+
+ ID_AA64ZFR0_EL1.BitPerm == 0b0001 表示有此功能。
+
+HWCAP2_SVESHA3
+
+ ID_AA64ZFR0_EL1.SHA3 == 0b0001 表示有此功能。
+
+HWCAP2_SVESM4
+
+ ID_AA64ZFR0_EL1.SM4 == 0b0001 表示有此功能。
+
+HWCAP2_FLAGM2
+
+ ID_AA64ISAR0_EL1.TS == 0b0010 表示有此功能。
+
+HWCAP2_FRINT
+
+ ID_AA64ISAR1_EL1.FRINTTS == 0b0001 表示有此功能。
+
+HWCAP2_SVEI8MM
+
+ ID_AA64ZFR0_EL1.I8MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEF32MM
+
+ ID_AA64ZFR0_EL1.F32MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEF64MM
+
+ ID_AA64ZFR0_EL1.F64MM == 0b0001 表示有此功能。
+
+HWCAP2_SVEBF16
+
+ ID_AA64ZFR0_EL1.BF16 == 0b0001 表示有此功能。
+
+HWCAP2_I8MM
+
+ ID_AA64ISAR1_EL1.I8MM == 0b0001 表示有此功能。
+
+HWCAP2_BF16
+
+ ID_AA64ISAR1_EL1.BF16 == 0b0001 表示有此功能。
+
+HWCAP2_DGH
+
+ ID_AA64ISAR1_EL1.DGH == 0b0001 表示有此功能。
+
+HWCAP2_RNG
+
+ ID_AA64ISAR0_EL1.RNDR == 0b0001 表示有此功能。
+
+HWCAP2_BTI
+
+ ID_AA64PFR0_EL1.BT == 0b0001 表示有此功能。
+
+
+4. 未使用的 AT_HWCAP 位
+-----------------------
+
+为了与用户空间交互，内核保证 AT_HWCAP 的第62、63位将始终返回0。
diff --git a/Documentation/translations/zh_CN/arm64/index.rst b/Documentation/translations/zh_CN/arm64/index.rst
index e31a609..57dc5de 100644
--- a/Documentation/translations/zh_CN/arm64/index.rst
+++ b/Documentation/translations/zh_CN/arm64/index.rst
@@ -15,3 +15,5 @@
amu
hugetlbpage
+ perf
+ elf_hwcaps
diff --git a/Documentation/translations/zh_CN/arm64/perf.rst b/Documentation/translations/zh_CN/arm64/perf.rst
new file mode 100644
index 0000000..9bf21d7
--- /dev/null
+++ b/Documentation/translations/zh_CN/arm64/perf.rst
@@ -0,0 +1,86 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: :ref:`Documentation/arm64/perf.rst <perf_index>`
+
+Translator: Bailu Lin <bailu.lin@vivo.com>
+
+=============
+Perf 事件属性
+=============
+
+:作者: Andrew Murray <andrew.murray@arm.com>
+:日期: 2019-03-06
+
+exclude_user
+------------
+
+该属性排除用户空间。
+
+用户空间始终运行在 EL0，因此该属性将排除 EL0。
+
+
+exclude_kernel
+--------------
+
+该属性排除内核空间。
+
+打开 VHE 时内核运行在 EL2，不打开 VHE 时内核运行在 EL1。客户机
+内核总是运行在 EL1。
+
+对于宿主机，该属性排除 EL1 和 VHE 上的 EL2。
+
+对于客户机，该属性排除 EL1。请注意客户机从来不会运行在 EL2。
+
+
+exclude_hv
+----------
+
+该属性排除虚拟机监控器。
+
+对于 VHE 宿主机该属性将被忽略，此时我们认为宿主机内核是虚拟机监
+控器。
+
+对于 non-VHE 宿主机该属性将排除 EL2，因为虚拟机监控器运行在 EL2
+的任何代码主要用于客户机和宿主机的切换。
+
+对于客户机该属性无效。请注意客户机从来不会运行在 EL2。
+
+
+exclude_host / exclude_guest
+----------------------------
+
+这些属性分别排除了 KVM 宿主机和客户机。
+
+KVM 宿主机可能运行在 EL0（用户空间），EL1（non-VHE 内核）和
+EL2（VHE 内核 或 non-VHE 虚拟机监控器）。
+
+KVM 客户机可能运行在 EL0（用户空间）和 EL1（内核）。
+
+由于宿主机和客户机之间重叠的异常级别，我们不能仅仅依靠 PMU 的硬件异
+常过滤机制-因此我们必须启用/禁用对于客户机进入和退出的计数。而这在
+VHE 和 non-VHE 系统上表现不同。
+
+对于 non-VHE 系统的 exclude_host 属性排除 EL2 - 在进入和退出客户
+机时，我们会根据 exclude_host 和 exclude_guest 属性在适当的情况下
+禁用/启用该事件。
+
+对于 VHE 系统的 exclude_guest 属性排除 EL1，而对其中的 exclude_host
+属性同时排除 EL0，EL2。在进入和退出客户机时，我们会适当地根据
+exclude_host 和 exclude_guest 属性包括/排除 EL0。
+
+以上声明也适用于在 not-VHE 客户机使用这些属性时，但是请注意客户机从
+来不会运行在 EL2。
+
+
+准确性
+------
+
+在 non-VHE 宿主机上，我们在 EL2 进入/退出宿主机/客户机的切换时启用/
+关闭计数器 -但是在启用/禁用计数器和进入/退出客户机之间存在一段延时。
+对于 exclude_host， 我们可以通过过滤 EL2 消除在客户机进入/退出边界
+上用于计数客户机事件的宿主机事件计数器。但是当使用 !exclude_hv 时，
+在客户机进入/退出有一个小的停电窗口无法捕获到宿主机的事件。
+
+在 VHE 系统没有停电窗口。
diff --git a/Documentation/translations/zh_CN/filesystems/index.rst b/Documentation/translations/zh_CN/filesystems/index.rst
index 186501d..9f2a8b0 100644
--- a/Documentation/translations/zh_CN/filesystems/index.rst
+++ b/Documentation/translations/zh_CN/filesystems/index.rst
@@ -25,4 +25,5 @@
virtiofs
debugfs
+ tmpfs
diff --git a/Documentation/translations/zh_CN/filesystems/tmpfs.rst b/Documentation/translations/zh_CN/filesystems/tmpfs.rst
new file mode 100644
index 0000000..6fd9d83
--- /dev/null
+++ b/Documentation/translations/zh_CN/filesystems/tmpfs.rst
@@ -0,0 +1,146 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/filesystems/tmpfs.rst
+
+translated by Wang Qing<wangqing@vivo.com>
+
+=====
+Tmpfs
+=====
+
+Tmpfs是一个将所有文件都保存在虚拟内存中的文件系统。
+
+tmpfs中的所有内容都是临时的，也就是说没有任何文件会在硬盘上创建。
+如果卸载tmpfs实例，所有保存在其中的文件都会丢失。
+
+tmpfs将所有文件保存在内核缓存中，随着文件内容增长或缩小可以将不需要的
+页面swap出去。它具有最大限制，可以通过“mount -o remount ...”调整。
+
+和ramfs（创建tmpfs的模板）相比，tmpfs包含交换和限制检查。和tmpfs相似的另
+一个东西是RAM磁盘（/dev/ram*），可以在物理RAM中模拟固定大小的硬盘，并在
+此之上创建一个普通的文件系统。Ramdisks无法swap，因此无法调整它们的大小。
+
+由于tmpfs完全保存于页面缓存和swap中，因此所有tmpfs页面将在/proc/meminfo
+中显示为“Shmem”，而在free(1)中显示为“Shared”。请注意，这些计数还包括
+共享内存(shmem，请参阅ipcs(1))。获得计数的最可靠方法是使用df(1)和du(1)。
+
+tmpfs具有以下用途：
+
+1) 内核总有一个无法看到的内部挂载，用于共享匿名映射和SYSV共享内存。
+
+ 挂载不依赖于CONFIG_TMPFS。如果CONFIG_TMPFS未设置，tmpfs对用户不可见。
+ 但是内部机制始终存在。
+
+2) glibc 2.2及更高版本期望将tmpfs挂载在/dev/shm上以用于POSIX共享内存
+ (shm_open，shm_unlink)。添加内容到/etc/fstab应注意如下：
+
+ tmpfs /dev/shm tmpfs defaults 0 0
+
+ 使用时需要记住创建挂载tmpfs的目录。
+
+ SYSV共享内存无需挂载，内部已默认支持。(在2.3内核版本中，必须挂载
+ tmpfs的前身(shm fs)才能使用SYSV共享内存)
+
+3) 很多人（包括我）都觉的在/tmp和/var/tmp上挂载非常方便，并具有较大的
+ swap分区。目前循环挂载tmpfs可以正常工作，所以大多数发布都应当可以
+ 使用mkinitrd通过/tmp访问/tmp。
+
+4) 也许还有更多我不知道的地方:-)
+
+
+tmpfs有三个用于调整大小的挂载选项：
+
+========= ===========================================================
+size tmpfs实例分配的字节数限制。默认值是不swap时物理RAM的一半。
+ 如果tmpfs实例过大，机器将死锁，因为OOM处理将无法释放该内存。
+nr_blocks 与size相同，但以PAGE_SIZE为单位。
+nr_inodes tmpfs实例的最大inode个数。默认值是物理内存页数的一半，或者
+ (有高端内存的机器)低端内存RAM的页数，二者以较低者为准。
+========= ===========================================================
+
+这些参数接受后缀k，m或g表示千，兆和千兆字节，可以在remount时更改。
+size参数也接受后缀％用来限制tmpfs实例占用物理RAM的百分比：
+未指定size或nr_blocks时，默认值为size=50％
+
+如果nr_blocks=0（或size=0），block个数将不受限制；如果nr_inodes=0，
+inode个数将不受限制。这样挂载通常是不明智的，因为它允许任何具有写权限的
+用户通过访问tmpfs耗尽机器上的所有内存；但同时这样做也会增强在多个CPU的
+场景下的访问。
+
+tmpfs具有为所有文件设置NUMA内存分配策略挂载选项(如果启用了CONFIG_NUMA),
+可以通过“mount -o remount ...”调整
+
+======================== =========================
+mpol=default 采用进程分配策略
+ (请参阅 set_mempolicy(2))
+mpol=prefer:Node 倾向从给定的节点分配
+mpol=bind:NodeList 只允许从指定的链表分配
+mpol=interleave 倾向于依次从每个节点分配
+mpol=interleave:NodeList 依次从每个节点分配
+mpol=local 优先本地节点分配内存
+======================== =========================
+
+NodeList格式是以逗号分隔的十进制数字表示大小和范围，最大和最小范围是用-
+分隔符的十进制数来表示。例如，mpol=bind0-3,5,7,9-15
+
+带有有效NodeList的内存策略将按指定格式保存，在创建文件时使用。当任务在该
+文件系统上创建文件时，会使用到挂载时的内存策略NodeList选项，如果设置的话，
+由调用任务的cpuset[请参见Documentation/admin-guide/cgroup-v1/cpusets.rst]
+以及下面列出的可选标志约束。如果NodeLists为设置为空集，则文件的内存策略将
+恢复为“默认”策略。
+
+NUMA内存分配策略有可选标志，可以用于模式结合。在挂载tmpfs时指定这些可选
+标志可以在NodeList之前生效。
+Documentation/admin-guide/mm/numa_memory_policy.rst列出所有可用的内存
+分配策略模式标志及其对内存策略。
+
+::
+
+ =static 相当于 MPOL_F_STATIC_NODES
+ =relative 相当于 MPOL_F_RELATIVE_NODES
+
+例如，mpol=bind=staticNodeList相当于MPOL_BIND|MPOL_F_STATIC_NODES的分配策略
+
+请注意，如果内核不支持NUMA，那么使用mpol选项挂载tmpfs将会失败；nodelist指定不
+在线的节点也会失败。如果您的系统依赖于此，但内核会运行不带NUMA功能(也许是安全
+revocery内核)，或者具有较少的节点在线，建议从自动模式中省略mpol选项挂载选项。
+可以在以后通过“mount -o remount,mpol=Policy:NodeList MountPoint”添加到挂载点。
+
+要指定初始根目录，可以使用如下挂载选项：
+
+==== ====================
+模式 权限用八进制数字表示
+uid 用户ID
+gid 组ID
+==== ====================
+
+这些选项对remount没有任何影响。您可以通过chmod(1),chown(1)和chgrp(1)的更改
+已经挂载的参数。
+
+tmpfs具有选择32位还是64位inode的挂载选项：
+
+======= =============
+inode64 使用64位inode
+inode32 使用32位inode
+======= =============
+
+在32位内核上，默认是inode32，挂载时指定inode64会被拒绝。
+在64位内核上，默认配置是CONFIG_TMPFS_INODE64。inode64避免了单个设备上可能有多个
+具有相同inode编号的文件；比如32位应用程序使用glibc如果长期访问tmpfs，一旦达到33
+位inode编号，就有EOVERFLOW失败的危险，无法打开大于2GiB的文件，并返回EINVAL。
+
+所以'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'将在
+/mytmpfs上挂载tmpfs实例，分配只能由root用户访问的10GB RAM/SWAP，可以有10240个
+inode的实例。
+
+
+:作者:
+ Christoph Rohland <cr@sap.com>, 1.12.01
+:更新:
+ Hugh Dickins, 4 June 2007
+:更新:
+ KOSAKI Motohiro, 16 Mar 2010
+:更新:
+ Chris Down, 13 July 2020
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst
index e4c2259..de182bf 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -73,7 +73,6 @@
SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h``
SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c``
-X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h``
SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h``
AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h``
TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h``
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 55a2d9b..a4c75a2 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -323,6 +323,7 @@
<mailto:tlewis@mindspring.com>
0xA3 90-9F linux/dtlk.h
0xA4 00-1F uapi/linux/tee.h Generic TEE subsystem
+0xA4 00-1F uapi/asm/sgx.h <mailto:linux-sgx@vger.kernel.org>
0xAA 00-3F linux/uapi/linux/userfaultfd.h
0xAB 00-1F linux/nbd.h
0xAC 00-1F linux/raw.h
diff --git a/Documentation/userspace-api/media/cec/cec-ioc-g-mode.rst b/Documentation/userspace-api/media/cec/cec-ioc-g-mode.rst
index d3387b1..663bdef 100644
--- a/Documentation/userspace-api/media/cec/cec-ioc-g-mode.rst
+++ b/Documentation/userspace-api/media/cec/cec-ioc-g-mode.rst
@@ -188,7 +188,7 @@
in combination with :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>`, otherwise
the ``EINVAL`` error code will be returned. In 'monitor all' mode all messages
this CEC device transmits and all messages it receives, including
- directed messages for other CEC devices will be reported. This is
+ directed messages for other CEC devices, will be reported. This is
very useful for debugging, but not all devices support this. This
mode requires that the :ref:`CEC_CAP_MONITOR_ALL <CEC-CAP-MONITOR-ALL>` capability is set,
otherwise the ``EINVAL`` error code is returned. This is only allowed if
diff --git a/Documentation/userspace-api/media/dvb/audio.rst b/Documentation/userspace-api/media/dvb/audio.rst
index 071abac..eaae567 100644
--- a/Documentation/userspace-api/media/dvb/audio.rst
+++ b/Documentation/userspace-api/media/dvb/audio.rst
@@ -8,7 +8,7 @@
The Digital TV audio device controls the MPEG2 audio decoder of the Digital
TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data
-types and and ioctl definitions can be accessed by including
+types and ioctl definitions can be accessed by including
``linux/dvb/audio.h`` in your application.
Please note that some Digital TV cards don’t have their own MPEG decoder, which
diff --git a/Documentation/userspace-api/media/dvb/ca.rst b/Documentation/userspace-api/media/dvb/ca.rst
index 6f6821e..0dc00e5 100644
--- a/Documentation/userspace-api/media/dvb/ca.rst
+++ b/Documentation/userspace-api/media/dvb/ca.rst
@@ -7,7 +7,7 @@
####################
The Digital TV CA device controls the conditional access hardware. It
-can be accessed through ``/dev/dvb/adapter?/ca?``. Data types and and ioctl
+can be accessed through ``/dev/dvb/adapter?/ca?``. Data types and ioctl
definitions can be accessed by including ``linux/dvb/ca.h`` in your
application.
diff --git a/Documentation/userspace-api/media/dvb/demux.rst b/Documentation/userspace-api/media/dvb/demux.rst
index 364ef48..ef05abc 100644
--- a/Documentation/userspace-api/media/dvb/demux.rst
+++ b/Documentation/userspace-api/media/dvb/demux.rst
@@ -11,7 +11,7 @@
implemented at the hardware. Otherwise, the Kernel provides a software
emulation.
-It can be accessed through ``/dev/adapter?/demux?``. Data types and and
+It can be accessed through ``/dev/adapter?/demux?``. Data types and
ioctl definitions can be accessed by including ``linux/dvb/dmx.h`` in
your application.
diff --git a/Documentation/userspace-api/media/dvb/dmx-qbuf.rst b/Documentation/userspace-api/media/dvb/dmx-qbuf.rst
index 17e7014..1a13a33 100644
--- a/Documentation/userspace-api/media/dvb/dmx-qbuf.rst
+++ b/Documentation/userspace-api/media/dvb/dmx-qbuf.rst
@@ -50,7 +50,7 @@
When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
memory pages of the buffer in physical memory, so they cannot be swapped
out to disk. Buffers remain locked until dequeued, until the
-the device is closed.
+device is closed.
Applications call the ``DMX_DQBUF`` ioctl to dequeue a filled
(capturing) buffer from the driver's outgoing queue.
diff --git a/Documentation/userspace-api/media/dvb/net.rst b/Documentation/userspace-api/media/dvb/net.rst
index 33368f5..020a023 100644
--- a/Documentation/userspace-api/media/dvb/net.rst
+++ b/Documentation/userspace-api/media/dvb/net.rst
@@ -23,7 +23,7 @@
virtual ``dvb?_?`` network interfaces, and will be controlled/routed via
the standard ip tools (like ip, route, netstat, ifconfig, etc).
-Data types and and ioctl definitions are defined via ``linux/dvb/net.h``
+Data types and ioctl definitions are defined via ``linux/dvb/net.h``
header.
diff --git a/Documentation/userspace-api/media/dvb/video.rst b/Documentation/userspace-api/media/dvb/video.rst
index 3ed1bbf..38a8d39 100644
--- a/Documentation/userspace-api/media/dvb/video.rst
+++ b/Documentation/userspace-api/media/dvb/video.rst
@@ -8,7 +8,7 @@
The Digital TV video device controls the MPEG2 video decoder of the Digital
TV hardware. It can be accessed through **/dev/dvb/adapter0/video0**. Data
-types and and ioctl definitions can be accessed by including
+types and ioctl definitions can be accessed by including
**linux/dvb/video.h** in your application.
Note that the Digital TV video device only controls decoding of the MPEG video
diff --git a/Documentation/userspace-api/media/lirc.h.rst.exceptions b/Documentation/userspace-api/media/lirc.h.rst.exceptions
index ac768d7..e74b73c 100644
--- a/Documentation/userspace-api/media/lirc.h.rst.exceptions
+++ b/Documentation/userspace-api/media/lirc.h.rst.exceptions
@@ -64,6 +64,7 @@
ignore symbol RC_PROTO_RCMM24
ignore symbol RC_PROTO_RCMM32
ignore symbol RC_PROTO_XBOX_DVD
+ignore symbol RC_PROTO_MAX
# Undocumented macros
diff --git a/Documentation/userspace-api/media/rc/keytable.c.rst b/Documentation/userspace-api/media/rc/keytable.c.rst
index 0b50cfaf..243e02d 100644
--- a/Documentation/userspace-api/media/rc/keytable.c.rst
+++ b/Documentation/userspace-api/media/rc/keytable.c.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
file: uapi/v4l/keytable.c
=========================
diff --git a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst
index 167b354..c889737 100644
--- a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst
+++ b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_dev_intro:
@@ -57,12 +57,12 @@
This mode is for both sending and receiving IR.
- For transmitting (aka sending), create a ``struct lirc_scancode`` with
+ For transmitting (aka sending), create a struct lirc_scancode with
the desired scancode set in the ``scancode`` member, :c:type:`rc_proto`
set to the :ref:`IR protocol <Remote_controllers_Protocols>`, and all other
members set to 0. Write this struct to the lirc device.
- For receiving, you read ``struct lirc_scancode`` from the LIRC device.
+ For receiving, you read struct lirc_scancode from the LIRC device.
The ``scancode`` field is set to the received scancode and the
:ref:`IR protocol <Remote_controllers_Protocols>` is set in
:c:type:`rc_proto`. If the scancode maps to a valid key code, this is set
@@ -136,6 +136,13 @@
This mode is used only for IR send.
+*************************************
+Data types used by LIRC_MODE_SCANCODE
+*************************************
+
+.. kernel-doc:: include/uapi/linux/lirc.h
+ :identifiers: lirc_scancode rc_proto
+
********************
BPF based IR decoder
********************
diff --git a/Documentation/userspace-api/media/rc/lirc-dev.rst b/Documentation/userspace-api/media/rc/lirc-dev.rst
index 5510dc0..978f86d 100644
--- a/Documentation/userspace-api/media/rc/lirc-dev.rst
+++ b/Documentation/userspace-api/media/rc/lirc-dev.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_dev:
diff --git a/Documentation/userspace-api/media/rc/lirc-func.rst b/Documentation/userspace-api/media/rc/lirc-func.rst
index 420a3db..793f295 100644
--- a/Documentation/userspace-api/media/rc/lirc-func.rst
+++ b/Documentation/userspace-api/media/rc/lirc-func.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_func:
diff --git a/Documentation/userspace-api/media/rc/lirc-get-features.rst b/Documentation/userspace-api/media/rc/lirc-get-features.rst
index 66a243d..4bf2586 100644
--- a/Documentation/userspace-api/media/rc/lirc-get-features.rst
+++ b/Documentation/userspace-api/media/rc/lirc-get-features.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_features:
diff --git a/Documentation/userspace-api/media/rc/lirc-get-rec-mode.rst b/Documentation/userspace-api/media/rc/lirc-get-rec-mode.rst
index 188478e..628fe31 100644
--- a/Documentation/userspace-api/media/rc/lirc-get-rec-mode.rst
+++ b/Documentation/userspace-api/media/rc/lirc-get-rec-mode.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_rec_mode:
diff --git a/Documentation/userspace-api/media/rc/lirc-get-rec-resolution.rst b/Documentation/userspace-api/media/rc/lirc-get-rec-resolution.rst
index e29445c..4dfa9c2 100644
--- a/Documentation/userspace-api/media/rc/lirc-get-rec-resolution.rst
+++ b/Documentation/userspace-api/media/rc/lirc-get-rec-resolution.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_rec_resolution:
diff --git a/Documentation/userspace-api/media/rc/lirc-get-send-mode.rst b/Documentation/userspace-api/media/rc/lirc-get-send-mode.rst
index 77472fb..6378718 100644
--- a/Documentation/userspace-api/media/rc/lirc-get-send-mode.rst
+++ b/Documentation/userspace-api/media/rc/lirc-get-send-mode.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_send_mode:
diff --git a/Documentation/userspace-api/media/rc/lirc-get-timeout.rst b/Documentation/userspace-api/media/rc/lirc-get-timeout.rst
index f5f3e06..597c328 100644
--- a/Documentation/userspace-api/media/rc/lirc-get-timeout.rst
+++ b/Documentation/userspace-api/media/rc/lirc-get-timeout.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_min_timeout:
diff --git a/Documentation/userspace-api/media/rc/lirc-header.rst b/Documentation/userspace-api/media/rc/lirc-header.rst
index 8bd0acc..54cb40b 100644
--- a/Documentation/userspace-api/media/rc/lirc-header.rst
+++ b/Documentation/userspace-api/media/rc/lirc-header.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_header:
diff --git a/Documentation/userspace-api/media/rc/lirc-read.rst b/Documentation/userspace-api/media/rc/lirc-read.rst
index d589560..ce34318 100644
--- a/Documentation/userspace-api/media/rc/lirc-read.rst
+++ b/Documentation/userspace-api/media/rc/lirc-read.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc-read:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-measure-carrier-mode.rst b/Documentation/userspace-api/media/rc/lirc-set-measure-carrier-mode.rst
index 9bf9811..04ced1a 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-measure-carrier-mode.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-measure-carrier-mode.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_measure_carrier_mode:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-rec-carrier-range.rst b/Documentation/userspace-api/media/rc/lirc-set-rec-carrier-range.rst
index 530bc22..7512dc8 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-rec-carrier-range.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-rec-carrier-range.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_carrier_range:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-rec-carrier.rst b/Documentation/userspace-api/media/rc/lirc-set-rec-carrier.rst
index 28c928f..60e3214 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-rec-carrier.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-rec-carrier.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_carrier:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst b/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst
index 83e7155..aebe810 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_timeout_reports:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-rec-timeout.rst b/Documentation/userspace-api/media/rc/lirc-set-rec-timeout.rst
index 8f3f9ad..bf9fb2c 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-rec-timeout.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-rec-timeout.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_timeout:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-send-carrier.rst b/Documentation/userspace-api/media/rc/lirc-set-send-carrier.rst
index e3810ba..a003f94 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-send-carrier.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-send-carrier.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_send_carrier:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-send-duty-cycle.rst b/Documentation/userspace-api/media/rc/lirc-set-send-duty-cycle.rst
index 52a0725..2979752 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-send-duty-cycle.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-send-duty-cycle.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_send_duty_cycle:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-transmitter-mask.rst b/Documentation/userspace-api/media/rc/lirc-set-transmitter-mask.rst
index 68f4cc2..38acbcd 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-transmitter-mask.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-transmitter-mask.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_transmitter_mask:
diff --git a/Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst b/Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst
index be5321c..c9d578e 100644
--- a/Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst
+++ b/Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_wideband_receiver:
diff --git a/Documentation/userspace-api/media/rc/lirc-write.rst b/Documentation/userspace-api/media/rc/lirc-write.rst
index c1c3230..970a8b3 100644
--- a/Documentation/userspace-api/media/rc/lirc-write.rst
+++ b/Documentation/userspace-api/media/rc/lirc-write.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc-write:
diff --git a/Documentation/userspace-api/media/rc/rc-intro.rst b/Documentation/userspace-api/media/rc/rc-intro.rst
index 1338478..2ba62cd 100644
--- a/Documentation/userspace-api/media/rc/rc-intro.rst
+++ b/Documentation/userspace-api/media/rc/rc-intro.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_Intro:
diff --git a/Documentation/userspace-api/media/rc/rc-protos.rst b/Documentation/userspace-api/media/rc/rc-protos.rst
index 2e29058..a2eab3b 100644
--- a/Documentation/userspace-api/media/rc/rc-protos.rst
+++ b/Documentation/userspace-api/media/rc/rc-protos.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_Protocols:
diff --git a/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst b/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst
index 43c4426..34d6a0a 100644
--- a/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst
+++ b/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _remote_controllers_sysfs_nodes:
diff --git a/Documentation/userspace-api/media/rc/rc-table-change.rst b/Documentation/userspace-api/media/rc/rc-table-change.rst
index 61c77b0..d7de8a5 100644
--- a/Documentation/userspace-api/media/rc/rc-table-change.rst
+++ b/Documentation/userspace-api/media/rc/rc-table-change.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_table_change:
diff --git a/Documentation/userspace-api/media/rc/rc-tables.rst b/Documentation/userspace-api/media/rc/rc-tables.rst
index 8dc1165..aafbfda 100644
--- a/Documentation/userspace-api/media/rc/rc-tables.rst
+++ b/Documentation/userspace-api/media/rc/rc-tables.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_tables:
diff --git a/Documentation/userspace-api/media/rc/remote_controllers.rst b/Documentation/userspace-api/media/rc/remote_controllers.rst
index 2d9078a..f892918 100644
--- a/Documentation/userspace-api/media/rc/remote_controllers.rst
+++ b/Documentation/userspace-api/media/rc/remote_controllers.rst
@@ -1,4 +1,4 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. include:: <isonum.txt>
.. _remote_controllers:
diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst
index 7869b6f..64d241d 100644
--- a/Documentation/userspace-api/media/v4l/biblio.rst
+++ b/Documentation/userspace-api/media/v4l/biblio.rst
@@ -270,7 +270,17 @@
=============
-:title: E.B.U. Standard for Chromaticity Tolerances for Studio Monitors"
+:title: E.B.U. Standard for Chromaticity Tolerances for Studio Monitors
+
+:author: European Broadcast Union (http://www.ebu.ch)
+
+.. _tech3321:
+
+EBU Tech 3321
+=============
+
+
+:title: E.B.U. guidelines for Consumer Flat Panel Displays (FPDs)
:author: European Broadcast Union (http://www.ebu.ch)
diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst
index 7dbdfbb..1b0fdc1 100644
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@@ -604,7 +604,7 @@
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. Due to
hardware limitations, the last buffer may be empty. In this case
the driver will set the ``bytesused`` field to 0, regardless of
- the format. Any Any subsequent call to the
+ the format. Any subsequent call to the
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
but return an ``EPIPE`` error code.
* .. _`V4L2-BUF-FLAG-REQUEST-FD`:
diff --git a/Documentation/userspace-api/media/v4l/colorspaces-details.rst b/Documentation/userspace-api/media/v4l/colorspaces-details.rst
index 014e7c9..126f664 100644
--- a/Documentation/userspace-api/media/v4l/colorspaces-details.rst
+++ b/Documentation/userspace-api/media/v4l/colorspaces-details.rst
@@ -674,8 +674,9 @@
=========================================================
The :ref:`tech3213` standard defines the colorspace used by PAL/SECAM
-in 1975. In practice this colorspace is obsolete and SMPTE 170M should
-be used instead. The default transfer function is
+in 1975. Note that this colorspace is not supported by the HDMI interface.
+Instead :ref:`tech3321` recommends that Rec. 709 is used instead for HDMI.
+The default transfer function is
``V4L2_XFER_FUNC_709``. The default Y'CbCr encoding is
``V4L2_YCBCR_ENC_601``. The default Y'CbCr quantization is limited
range. The chromaticities of the primary colors and the white reference
diff --git a/Documentation/userspace-api/media/v4l/common.rst b/Documentation/userspace-api/media/v4l/common.rst
index d84aeb7..8c263c5 100644
--- a/Documentation/userspace-api/media/v4l/common.rst
+++ b/Documentation/userspace-api/media/v4l/common.rst
@@ -44,6 +44,7 @@
ext-ctrls-image-source
ext-ctrls-image-process
ext-ctrls-codec
+ ext-ctrls-codec-stateless
ext-ctrls-jpeg
ext-ctrls-dv
ext-ctrls-rf-tuner
diff --git a/Documentation/userspace-api/media/v4l/dev-mem2mem.rst b/Documentation/userspace-api/media/v4l/dev-mem2mem.rst
index d8db468..7041bb3 100644
--- a/Documentation/userspace-api/media/v4l/dev-mem2mem.rst
+++ b/Documentation/userspace-api/media/v4l/dev-mem2mem.rst
@@ -32,7 +32,7 @@
One of the most common memory-to-memory device is the codec. Codecs
are more complicated than most and require additional setup for
their codec parameters. This is done through codec controls.
-See :ref:`mpeg-controls`. More details on how to use codec memory-to-memory
+See :ref:`codec-controls`. More details on how to use codec memory-to-memory
devices are given in the following sections.
.. toctree::
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
new file mode 100644
index 0000000..01e3b1a
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -0,0 +1,793 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _codec-stateless-controls:
+
+*********************************
+Stateless Codec Control Reference
+*********************************
+
+The Stateless Codec control class is intended to support
+stateless decoder and encoders (i.e. hardware accelerators).
+
+These drivers are typically supported by the :ref:`stateless_decoder`,
+and deal with parsed pixel formats such as V4L2_PIX_FMT_H264_SLICE.
+
+Stateless Codec Control ID
+==========================
+
+.. _codec-stateless-control-id:
+
+``V4L2_CID_CODEC_STATELESS_CLASS (class)``
+ The Stateless Codec class descriptor.
+
+.. _v4l2-codec-stateless-h264:
+
+``V4L2_CID_STATELESS_H264_SPS (struct)``
+ Specifies the sequence parameter set (as extracted from the
+ bitstream) for the associated H264 slice data. This includes the
+ necessary parameters for configuring a stateless hardware decoding
+ pipeline for H264. The bitstream parameters are defined according
+ to :ref:`h264`, section 7.4.2.1.1 "Sequence Parameter Set Data
+ Semantics". For further documentation, refer to the above
+ specification, unless there is an explicit comment stating
+ otherwise.
+
+.. c:type:: v4l2_ctrl_h264_sps
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_h264_sps
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``profile_idc``
+ -
+ * - __u8
+ - ``constraint_set_flags``
+ - See :ref:`Sequence Parameter Set Constraints Set Flags <h264_sps_constraints_set_flags>`
+ * - __u8
+ - ``level_idc``
+ -
+ * - __u8
+ - ``seq_parameter_set_id``
+ -
+ * - __u8
+ - ``chroma_format_idc``
+ -
+ * - __u8
+ - ``bit_depth_luma_minus8``
+ -
+ * - __u8
+ - ``bit_depth_chroma_minus8``
+ -
+ * - __u8
+ - ``log2_max_frame_num_minus4``
+ -
+ * - __u8
+ - ``pic_order_cnt_type``
+ -
+ * - __u8
+ - ``log2_max_pic_order_cnt_lsb_minus4``
+ -
+ * - __u8
+ - ``max_num_ref_frames``
+ -
+ * - __u8
+ - ``num_ref_frames_in_pic_order_cnt_cycle``
+ -
+ * - __s32
+ - ``offset_for_ref_frame[255]``
+ -
+ * - __s32
+ - ``offset_for_non_ref_pic``
+ -
+ * - __s32
+ - ``offset_for_top_to_bottom_field``
+ -
+ * - __u16
+ - ``pic_width_in_mbs_minus1``
+ -
+ * - __u16
+ - ``pic_height_in_map_units_minus1``
+ -
+ * - __u32
+ - ``flags``
+ - See :ref:`Sequence Parameter Set Flags <h264_sps_flags>`
+
+.. _h264_sps_constraints_set_flags:
+
+``Sequence Parameter Set Constraints Set Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_SPS_CONSTRAINT_SET0_FLAG``
+ - 0x00000001
+ -
+ * - ``V4L2_H264_SPS_CONSTRAINT_SET1_FLAG``
+ - 0x00000002
+ -
+ * - ``V4L2_H264_SPS_CONSTRAINT_SET2_FLAG``
+ - 0x00000004
+ -
+ * - ``V4L2_H264_SPS_CONSTRAINT_SET3_FLAG``
+ - 0x00000008
+ -
+ * - ``V4L2_H264_SPS_CONSTRAINT_SET4_FLAG``
+ - 0x00000010
+ -
+ * - ``V4L2_H264_SPS_CONSTRAINT_SET5_FLAG``
+ - 0x00000020
+ -
+
+.. _h264_sps_flags:
+
+``Sequence Parameter Set Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE``
+ - 0x00000001
+ -
+ * - ``V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS``
+ - 0x00000002
+ -
+ * - ``V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO``
+ - 0x00000004
+ -
+ * - ``V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED``
+ - 0x00000008
+ -
+ * - ``V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY``
+ - 0x00000010
+ -
+ * - ``V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD``
+ - 0x00000020
+ -
+ * - ``V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE``
+ - 0x00000040
+ -
+
+``V4L2_CID_STATELESS_H264_PPS (struct)``
+ Specifies the picture parameter set (as extracted from the
+ bitstream) for the associated H264 slice data. This includes the
+ necessary parameters for configuring a stateless hardware decoding
+ pipeline for H264. The bitstream parameters are defined according
+ to :ref:`h264`, section 7.4.2.2 "Picture Parameter Set RBSP
+ Semantics". For further documentation, refer to the above
+ specification, unless there is an explicit comment stating
+ otherwise.
+
+.. c:type:: v4l2_ctrl_h264_pps
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_h264_pps
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``pic_parameter_set_id``
+ -
+ * - __u8
+ - ``seq_parameter_set_id``
+ -
+ * - __u8
+ - ``num_slice_groups_minus1``
+ -
+ * - __u8
+ - ``num_ref_idx_l0_default_active_minus1``
+ -
+ * - __u8
+ - ``num_ref_idx_l1_default_active_minus1``
+ -
+ * - __u8
+ - ``weighted_bipred_idc``
+ -
+ * - __s8
+ - ``pic_init_qp_minus26``
+ -
+ * - __s8
+ - ``pic_init_qs_minus26``
+ -
+ * - __s8
+ - ``chroma_qp_index_offset``
+ -
+ * - __s8
+ - ``second_chroma_qp_index_offset``
+ -
+ * - __u16
+ - ``flags``
+ - See :ref:`Picture Parameter Set Flags <h264_pps_flags>`
+
+.. _h264_pps_flags:
+
+``Picture Parameter Set Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE``
+ - 0x00000001
+ -
+ * - ``V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT``
+ - 0x00000002
+ -
+ * - ``V4L2_H264_PPS_FLAG_WEIGHTED_PRED``
+ - 0x00000004
+ -
+ * - ``V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
+ - 0x00000008
+ -
+ * - ``V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED``
+ - 0x00000010
+ -
+ * - ``V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT``
+ - 0x00000020
+ -
+ * - ``V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE``
+ - 0x00000040
+ -
+ * - ``V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT``
+ - 0x00000080
+ - Indicates that ``V4L2_CID_STATELESS_H264_SCALING_MATRIX``
+ must be used for this picture.
+
+``V4L2_CID_STATELESS_H264_SCALING_MATRIX (struct)``
+ Specifies the scaling matrix (as extracted from the bitstream) for
+ the associated H264 slice data. The bitstream parameters are
+ defined according to :ref:`h264`, section 7.4.2.1.1.1 "Scaling
+ List Semantics". For further documentation, refer to the above
+ specification, unless there is an explicit comment stating
+ otherwise.
+
+.. c:type:: v4l2_ctrl_h264_scaling_matrix
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_h264_scaling_matrix
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``scaling_list_4x4[6][16]``
+ - Scaling matrix after applying the inverse scanning process.
+ Expected list order is Intra Y, Intra Cb, Intra Cr, Inter Y,
+ Inter Cb, Inter Cr. The values on each scaling list are
+ expected in raster scan order.
+ * - __u8
+ - ``scaling_list_8x8[6][64]``
+ - Scaling matrix after applying the inverse scanning process.
+ Expected list order is Intra Y, Inter Y, Intra Cb, Inter Cb,
+ Intra Cr, Inter Cr. The values on each scaling list are
+ expected in raster scan order.
+
+``V4L2_CID_STATELESS_H264_SLICE_PARAMS (struct)``
+ Specifies the slice parameters (as extracted from the bitstream)
+ for the associated H264 slice data. This includes the necessary
+ parameters for configuring a stateless hardware decoding pipeline
+ for H264. The bitstream parameters are defined according to
+ :ref:`h264`, section 7.4.3 "Slice Header Semantics". For further
+ documentation, refer to the above specification, unless there is
+ an explicit comment stating otherwise.
+
+.. c:type:: v4l2_ctrl_h264_slice_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_h264_slice_params
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u32
+ - ``header_bit_size``
+ - Offset in bits to slice_data() from the beginning of this slice.
+ * - __u32
+ - ``first_mb_in_slice``
+ -
+ * - __u8
+ - ``slice_type``
+ -
+ * - __u8
+ - ``colour_plane_id``
+ -
+ * - __u8
+ - ``redundant_pic_cnt``
+ -
+ * - __u8
+ - ``cabac_init_idc``
+ -
+ * - __s8
+ - ``slice_qp_delta``
+ -
+ * - __s8
+ - ``slice_qs_delta``
+ -
+ * - __u8
+ - ``disable_deblocking_filter_idc``
+ -
+ * - __s8
+ - ``slice_alpha_c0_offset_div2``
+ -
+ * - __s8
+ - ``slice_beta_offset_div2``
+ -
+ * - __u8
+ - ``num_ref_idx_l0_active_minus1``
+ - If num_ref_idx_active_override_flag is not set, this field must be
+ set to the value of num_ref_idx_l0_default_active_minus1.
+ * - __u8
+ - ``num_ref_idx_l1_active_minus1``
+ - If num_ref_idx_active_override_flag is not set, this field must be
+ set to the value of num_ref_idx_l1_default_active_minus1.
+ * - __u8
+ - ``reserved``
+ - Applications and drivers must set this to zero.
+ * - struct :c:type:`v4l2_h264_reference`
+ - ``ref_pic_list0[32]``
+ - Reference picture list after applying the per-slice modifications
+ * - struct :c:type:`v4l2_h264_reference`
+ - ``ref_pic_list1[32]``
+ - Reference picture list after applying the per-slice modifications
+ * - __u32
+ - ``flags``
+ - See :ref:`Slice Parameter Flags <h264_slice_flags>`
+
+.. _h264_slice_flags:
+
+``Slice Parameter Set Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED``
+ - 0x00000001
+ -
+ * - ``V4L2_H264_SLICE_FLAG_SP_FOR_SWITCH``
+ - 0x00000002
+ -
+
+``V4L2_CID_STATELESS_H264_PRED_WEIGHTS (struct)``
+ Prediction weight table defined according to :ref:`h264`,
+ section 7.4.3.2 "Prediction Weight Table Semantics".
+ The prediction weight table must be passed by applications
+ under the conditions explained in section 7.3.3 "Slice header
+ syntax".
+
+.. c:type:: v4l2_ctrl_h264_pred_weights
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_h264_pred_weights
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u16
+ - ``luma_log2_weight_denom``
+ -
+ * - __u16
+ - ``chroma_log2_weight_denom``
+ -
+ * - struct :c:type:`v4l2_h264_weight_factors`
+ - ``weight_factors[2]``
+ - The weight factors at index 0 are the weight factors for the reference
+ list 0, the one at index 1 for the reference list 1.
+
+.. c:type:: v4l2_h264_weight_factors
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_h264_weight_factors
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __s16
+ - ``luma_weight[32]``
+ -
+ * - __s16
+ - ``luma_offset[32]``
+ -
+ * - __s16
+ - ``chroma_weight[32][2]``
+ -
+ * - __s16
+ - ``chroma_offset[32][2]``
+ -
+
+``Picture Reference``
+
+.. c:type:: v4l2_h264_reference
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_h264_reference
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u8
+ - ``fields``
+ - Specifies how the picture is referenced. See :ref:`Reference Fields <h264_ref_fields>`
+ * - __u8
+ - ``index``
+ - Index into the :c:type:`v4l2_ctrl_h264_decode_params`.dpb array.
+
+.. _h264_ref_fields:
+
+``Reference Fields``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_TOP_FIELD_REF``
+ - 0x1
+ - The top field in field pair is used for short-term reference.
+ * - ``V4L2_H264_BOTTOM_FIELD_REF``
+ - 0x2
+ - The bottom field in field pair is used for short-term reference.
+ * - ``V4L2_H264_FRAME_REF``
+ - 0x3
+ - The frame (or the top/bottom fields, if it's a field pair)
+ is used for short-term reference.
+
+``V4L2_CID_STATELESS_H264_DECODE_PARAMS (struct)``
+ Specifies the decode parameters (as extracted from the bitstream)
+ for the associated H264 slice data. This includes the necessary
+ parameters for configuring a stateless hardware decoding pipeline
+ for H264. The bitstream parameters are defined according to
+ :ref:`h264`. For further documentation, refer to the above
+ specification, unless there is an explicit comment stating
+ otherwise.
+
+.. c:type:: v4l2_ctrl_h264_decode_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_h264_decode_params
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - struct :c:type:`v4l2_h264_dpb_entry`
+ - ``dpb[16]``
+ -
+ * - __u16
+ - ``nal_ref_idc``
+ - NAL reference ID value coming from the NAL Unit header
+ * - __u16
+ - ``frame_num``
+ -
+ * - __s32
+ - ``top_field_order_cnt``
+ - Picture Order Count for the coded top field
+ * - __s32
+ - ``bottom_field_order_cnt``
+ - Picture Order Count for the coded bottom field
+ * - __u16
+ - ``idr_pic_id``
+ -
+ * - __u16
+ - ``pic_order_cnt_lsb``
+ -
+ * - __s32
+ - ``delta_pic_order_cnt_bottom``
+ -
+ * - __s32
+ - ``delta_pic_order_cnt0``
+ -
+ * - __s32
+ - ``delta_pic_order_cnt1``
+ -
+ * - __u32
+ - ``dec_ref_pic_marking_bit_size``
+ - Size in bits of the dec_ref_pic_marking() syntax element.
+ * - __u32
+ - ``pic_order_cnt_bit_size``
+ - Combined size in bits of the picture order count related syntax
+ elements: pic_order_cnt_lsb, delta_pic_order_cnt_bottom,
+ delta_pic_order_cnt0, and delta_pic_order_cnt1.
+ * - __u32
+ - ``slice_group_change_cycle``
+ -
+ * - __u32
+ - ``reserved``
+ - Applications and drivers must set this to zero.
+ * - __u32
+ - ``flags``
+ - See :ref:`Decode Parameters Flags <h264_decode_params_flags>`
+
+.. _h264_decode_params_flags:
+
+``Decode Parameters Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC``
+ - 0x00000001
+ - That picture is an IDR picture
+ * - ``V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC``
+ - 0x00000002
+ -
+ * - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD``
+ - 0x00000004
+ -
+
+.. c:type:: v4l2_h264_dpb_entry
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_h264_dpb_entry
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u64
+ - ``reference_ts``
+ - Timestamp of the V4L2 capture buffer to use as reference, used
+ with B-coded and P-coded frames. The timestamp refers to the
+ ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
+ :c:func:`v4l2_timeval_to_ns()` function to convert the struct
+ :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
+ * - __u32
+ - ``pic_num``
+ -
+ * - __u16
+ - ``frame_num``
+ -
+ * - __u8
+ - ``fields``
+ - Specifies how the DPB entry is referenced. See :ref:`Reference Fields <h264_ref_fields>`
+ * - __u8
+ - ``reserved[5]``
+ - Applications and drivers must set this to zero.
+ * - __s32
+ - ``top_field_order_cnt``
+ -
+ * - __s32
+ - ``bottom_field_order_cnt``
+ -
+ * - __u32
+ - ``flags``
+ - See :ref:`DPB Entry Flags <h264_dpb_flags>`
+
+.. _h264_dpb_flags:
+
+``DPB Entries Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_H264_DPB_ENTRY_FLAG_VALID``
+ - 0x00000001
+ - The DPB entry is valid (non-empty) and should be considered.
+ * - ``V4L2_H264_DPB_ENTRY_FLAG_ACTIVE``
+ - 0x00000002
+ - The DPB entry is used for reference.
+ * - ``V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM``
+ - 0x00000004
+ - The DPB entry is used for long-term reference.
+ * - ``V4L2_H264_DPB_ENTRY_FLAG_FIELD``
+ - 0x00000008
+ - The DPB entry is a single field or a complementary field pair.
+
+``V4L2_CID_STATELESS_H264_DECODE_MODE (enum)``
+ Specifies the decoding mode to use. Currently exposes slice-based and
+ frame-based decoding but new modes might be added later on.
+ This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
+ pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
+ are required to set this control in order to specify the decoding mode
+ that is expected for the buffer.
+ Drivers may expose a single or multiple decoding modes, depending
+ on what they can support.
+
+.. c:type:: v4l2_stateless_h264_decode_mode
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_STATELESS_H264_DECODE_MODE_SLICE_BASED``
+ - 0
+ - Decoding is done at the slice granularity.
+ The OUTPUT buffer must contain a single slice.
+ When this mode is selected, the ``V4L2_CID_STATELESS_H264_SLICE_PARAMS``
+ control shall be set. When multiple slices compose a frame,
+ use of ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` flag
+ is required.
+ * - ``V4L2_STATELESS_H264_DECODE_MODE_FRAME_BASED``
+ - 1
+ - Decoding is done at the frame granularity,
+ The OUTPUT buffer must contain all slices needed to decode the
+ frame. The OUTPUT buffer must also contain both fields.
+ This mode will be supported by devices that
+ parse the slice(s) header(s) in hardware. When this mode is
+ selected, the ``V4L2_CID_STATELESS_H264_SLICE_PARAMS``
+ control shall not be set.
+
+``V4L2_CID_STATELESS_H264_START_CODE (enum)``
+ Specifies the H264 slice start code expected for each slice.
+ This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
+ pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
+ are required to set this control in order to specify the start code
+ that is expected for the buffer.
+ Drivers may expose a single or multiple start codes, depending
+ on what they can support.
+
+.. c:type:: v4l2_stateless_h264_start_code
+
+.. cssclass:: longtable
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - ``V4L2_STATELESS_H264_START_CODE_NONE``
+ - 0
+ - Selecting this value specifies that H264 slices are passed
+ to the driver without any start code.
+ * - ``V4L2_STATELESS_H264_START_CODE_ANNEX_B``
+ - 1
+ - Selecting this value specifies that H264 slices are expected
+ to be prefixed by Annex B start codes. According to :ref:`h264`
+ valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001.
+
+
+.. _codec-stateless-fwht:
+
+``V4L2_CID_STATELESS_FWHT_PARAMS (struct)``
+ Specifies the FWHT (Fast Walsh Hadamard Transform) parameters (as extracted
+ from the bitstream) for the associated FWHT data. This includes the necessary
+ parameters for configuring a stateless hardware decoding pipeline for FWHT.
+ This codec is specific to the vicodec test driver.
+
+.. c:type:: v4l2_ctrl_fwht_params
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.4cm}|p{4.3cm}|p{11.8cm}|
+
+.. flat-table:: struct v4l2_ctrl_fwht_params
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u64
+ - ``backward_ref_ts``
+ - Timestamp of the V4L2 capture buffer to use as backward reference, used
+ with P-coded frames. The timestamp refers to the
+ ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
+ :c:func:`v4l2_timeval_to_ns()` function to convert the struct
+ :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
+ * - __u32
+ - ``version``
+ - The version of the codec. Set to ``V4L2_FWHT_VERSION``.
+ * - __u32
+ - ``width``
+ - The width of the frame.
+ * - __u32
+ - ``height``
+ - The height of the frame.
+ * - __u32
+ - ``flags``
+ - The flags of the frame, see :ref:`fwht-flags`.
+ * - __u32
+ - ``colorspace``
+ - The colorspace of the frame, from enum :c:type:`v4l2_colorspace`.
+ * - __u32
+ - ``xfer_func``
+ - The transfer function, from enum :c:type:`v4l2_xfer_func`.
+ * - __u32
+ - ``ycbcr_enc``
+ - The Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
+ * - __u32
+ - ``quantization``
+ - The quantization range, from enum :c:type:`v4l2_quantization`.
+
+
+
+.. _fwht-flags:
+
+FWHT Flags
+==========
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.3cm}|
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 3 1 4
+
+ * - ``V4L2_FWHT_FL_IS_INTERLACED``
+ - 0x00000001
+ - Set if this is an interlaced format.
+ * - ``V4L2_FWHT_FL_IS_BOTTOM_FIRST``
+ - 0x00000002
+ - Set if this is a bottom-first (NTSC) interlaced format.
+ * - ``V4L2_FWHT_FL_IS_ALTERNATE``
+ - 0x00000004
+ - Set if each 'frame' contains just one field.
+ * - ``V4L2_FWHT_FL_IS_BOTTOM_FIELD``
+ - 0x00000008
+ - If V4L2_FWHT_FL_IS_ALTERNATE was set, then this is set if this 'frame' is the
+ bottom field, else it is the top field.
+ * - ``V4L2_FWHT_FL_LUMA_IS_UNCOMPRESSED``
+ - 0x00000010
+ - Set if the Y' (luma) plane is uncompressed.
+ * - ``V4L2_FWHT_FL_CB_IS_UNCOMPRESSED``
+ - 0x00000020
+ - Set if the Cb plane is uncompressed.
+ * - ``V4L2_FWHT_FL_CR_IS_UNCOMPRESSED``
+ - 0x00000040
+ - Set if the Cr plane is uncompressed.
+ * - ``V4L2_FWHT_FL_CHROMA_FULL_HEIGHT``
+ - 0x00000080
+ - Set if the chroma plane has the same height as the luma plane,
+ else the chroma plane is half the height of the luma plane.
+ * - ``V4L2_FWHT_FL_CHROMA_FULL_WIDTH``
+ - 0x00000100
+ - Set if the chroma plane has the same width as the luma plane,
+ else the chroma plane is half the width of the luma plane.
+ * - ``V4L2_FWHT_FL_ALPHA_IS_UNCOMPRESSED``
+ - 0x00000200
+ - Set if the alpha plane is uncompressed.
+ * - ``V4L2_FWHT_FL_I_FRAME``
+ - 0x00000400
+ - Set if this is an I-frame.
+ * - ``V4L2_FWHT_FL_COMPONENTS_NUM_MSK``
+ - 0x00070000
+ - The number of color components - 1.
+ * - ``V4L2_FWHT_FL_PIXENC_MSK``
+ - 0x00180000
+ - The mask for the pixel encoding.
+ * - ``V4L2_FWHT_FL_PIXENC_YUV``
+ - 0x00080000
+ - Set if the pixel encoding is YUV.
+ * - ``V4L2_FWHT_FL_PIXENC_RGB``
+ - 0x00100000
+ - Set if the pixel encoding is RGB.
+ * - ``V4L2_FWHT_FL_PIXENC_HSV``
+ - 0x00180000
+ - Set if the pixel encoding is HSV.
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index ce728c75..454ecd9 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1,6 +1,6 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-.. _mpeg-controls:
+.. _codec-controls:
***********************
Codec Control Reference
@@ -26,7 +26,7 @@
Codec Control IDs
-----------------
-``V4L2_CID_MPEG_CLASS (class)``
+``V4L2_CID_CODEC_CLASS (class)``
The Codec class descriptor. Calling
:ref:`VIDIOC_QUERYCTRL` for this control will
return a description of this control class. This description can be
@@ -1502,698 +1502,6 @@
- Layer number
-.. _v4l2-mpeg-h264:
-
-``V4L2_CID_MPEG_VIDEO_H264_SPS (struct)``
- Specifies the sequence parameter set (as extracted from the
- bitstream) for the associated H264 slice data. This includes the
- necessary parameters for configuring a stateless hardware decoding
- pipeline for H264. The bitstream parameters are defined according
- to :ref:`h264`, section 7.4.2.1.1 "Sequence Parameter Set Data
- Semantics". For further documentation, refer to the above
- specification, unless there is an explicit comment stating
- otherwise.
-
- .. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_h264_sps
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_h264_sps
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u8
- - ``profile_idc``
- -
- * - __u8
- - ``constraint_set_flags``
- - See :ref:`Sequence Parameter Set Constraints Set Flags <h264_sps_constraints_set_flags>`
- * - __u8
- - ``level_idc``
- -
- * - __u8
- - ``seq_parameter_set_id``
- -
- * - __u8
- - ``chroma_format_idc``
- -
- * - __u8
- - ``bit_depth_luma_minus8``
- -
- * - __u8
- - ``bit_depth_chroma_minus8``
- -
- * - __u8
- - ``log2_max_frame_num_minus4``
- -
- * - __u8
- - ``pic_order_cnt_type``
- -
- * - __u8
- - ``log2_max_pic_order_cnt_lsb_minus4``
- -
- * - __u8
- - ``max_num_ref_frames``
- -
- * - __u8
- - ``num_ref_frames_in_pic_order_cnt_cycle``
- -
- * - __s32
- - ``offset_for_ref_frame[255]``
- -
- * - __s32
- - ``offset_for_non_ref_pic``
- -
- * - __s32
- - ``offset_for_top_to_bottom_field``
- -
- * - __u16
- - ``pic_width_in_mbs_minus1``
- -
- * - __u16
- - ``pic_height_in_map_units_minus1``
- -
- * - __u32
- - ``flags``
- - See :ref:`Sequence Parameter Set Flags <h264_sps_flags>`
-
-.. _h264_sps_constraints_set_flags:
-
-``Sequence Parameter Set Constraints Set Flags``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_SPS_CONSTRAINT_SET0_FLAG``
- - 0x00000001
- -
- * - ``V4L2_H264_SPS_CONSTRAINT_SET1_FLAG``
- - 0x00000002
- -
- * - ``V4L2_H264_SPS_CONSTRAINT_SET2_FLAG``
- - 0x00000004
- -
- * - ``V4L2_H264_SPS_CONSTRAINT_SET3_FLAG``
- - 0x00000008
- -
- * - ``V4L2_H264_SPS_CONSTRAINT_SET4_FLAG``
- - 0x00000010
- -
- * - ``V4L2_H264_SPS_CONSTRAINT_SET5_FLAG``
- - 0x00000020
- -
-
-.. _h264_sps_flags:
-
-``Sequence Parameter Set Flags``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE``
- - 0x00000001
- -
- * - ``V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS``
- - 0x00000002
- -
- * - ``V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO``
- - 0x00000004
- -
- * - ``V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED``
- - 0x00000008
- -
- * - ``V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY``
- - 0x00000010
- -
- * - ``V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD``
- - 0x00000020
- -
- * - ``V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE``
- - 0x00000040
- -
-
-``V4L2_CID_MPEG_VIDEO_H264_PPS (struct)``
- Specifies the picture parameter set (as extracted from the
- bitstream) for the associated H264 slice data. This includes the
- necessary parameters for configuring a stateless hardware decoding
- pipeline for H264. The bitstream parameters are defined according
- to :ref:`h264`, section 7.4.2.2 "Picture Parameter Set RBSP
- Semantics". For further documentation, refer to the above
- specification, unless there is an explicit comment stating
- otherwise.
-
- .. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_h264_pps
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_h264_pps
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u8
- - ``pic_parameter_set_id``
- -
- * - __u8
- - ``seq_parameter_set_id``
- -
- * - __u8
- - ``num_slice_groups_minus1``
- -
- * - __u8
- - ``num_ref_idx_l0_default_active_minus1``
- -
- * - __u8
- - ``num_ref_idx_l1_default_active_minus1``
- -
- * - __u8
- - ``weighted_bipred_idc``
- -
- * - __s8
- - ``pic_init_qp_minus26``
- -
- * - __s8
- - ``pic_init_qs_minus26``
- -
- * - __s8
- - ``chroma_qp_index_offset``
- -
- * - __s8
- - ``second_chroma_qp_index_offset``
- -
- * - __u16
- - ``flags``
- - See :ref:`Picture Parameter Set Flags <h264_pps_flags>`
-
-.. _h264_pps_flags:
-
-``Picture Parameter Set Flags``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE``
- - 0x00000001
- -
- * - ``V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT``
- - 0x00000002
- -
- * - ``V4L2_H264_PPS_FLAG_WEIGHTED_PRED``
- - 0x00000004
- -
- * - ``V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
- - 0x00000008
- -
- * - ``V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED``
- - 0x00000010
- -
- * - ``V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT``
- - 0x00000020
- -
- * - ``V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE``
- - 0x00000040
- -
- * - ``V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT``
- - 0x00000080
- - Indicates that ``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX``
- must be used for this picture.
-
-``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX (struct)``
- Specifies the scaling matrix (as extracted from the bitstream) for
- the associated H264 slice data. The bitstream parameters are
- defined according to :ref:`h264`, section 7.4.2.1.1.1 "Scaling
- List Semantics". For further documentation, refer to the above
- specification, unless there is an explicit comment stating
- otherwise.
-
- .. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_h264_scaling_matrix
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_h264_scaling_matrix
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u8
- - ``scaling_list_4x4[6][16]``
- - Scaling matrix after applying the inverse scanning process.
- Expected list order is Intra Y, Intra Cb, Intra Cr, Inter Y,
- Inter Cb, Inter Cr. The values on each scaling list are
- expected in raster scan order.
- * - __u8
- - ``scaling_list_8x8[6][64]``
- - Scaling matrix after applying the inverse scanning process.
- Expected list order is Intra Y, Inter Y, Intra Cb, Inter Cb,
- Intra Cr, Inter Cr. The values on each scaling list are
- expected in raster scan order.
-
-``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS (struct)``
- Specifies the slice parameters (as extracted from the bitstream)
- for the associated H264 slice data. This includes the necessary
- parameters for configuring a stateless hardware decoding pipeline
- for H264. The bitstream parameters are defined according to
- :ref:`h264`, section 7.4.3 "Slice Header Semantics". For further
- documentation, refer to the above specification, unless there is
- an explicit comment stating otherwise.
-
- .. note::
-
- This compound control is not yet part of the public kernel API
- and it is expected to change.
-
-.. c:type:: v4l2_ctrl_h264_slice_params
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_h264_slice_params
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u32
- - ``header_bit_size``
- - Offset in bits to slice_data() from the beginning of this slice.
- * - __u32
- - ``first_mb_in_slice``
- -
- * - __u8
- - ``slice_type``
- -
- * - __u8
- - ``colour_plane_id``
- -
- * - __u8
- - ``redundant_pic_cnt``
- -
- * - __u8
- - ``cabac_init_idc``
- -
- * - __s8
- - ``slice_qp_delta``
- -
- * - __s8
- - ``slice_qs_delta``
- -
- * - __u8
- - ``disable_deblocking_filter_idc``
- -
- * - __s8
- - ``slice_alpha_c0_offset_div2``
- -
- * - __s8
- - ``slice_beta_offset_div2``
- -
- * - __u8
- - ``num_ref_idx_l0_active_minus1``
- - If num_ref_idx_active_override_flag is not set, this field must be
- set to the value of num_ref_idx_l0_default_active_minus1.
- * - __u8
- - ``num_ref_idx_l1_active_minus1``
- - If num_ref_idx_active_override_flag is not set, this field must be
- set to the value of num_ref_idx_l1_default_active_minus1.
- * - __u8
- - ``reserved``
- - Applications and drivers must set this to zero.
- * - struct :c:type:`v4l2_h264_reference`
- - ``ref_pic_list0[32]``
- - Reference picture list after applying the per-slice modifications
- * - struct :c:type:`v4l2_h264_reference`
- - ``ref_pic_list1[32]``
- - Reference picture list after applying the per-slice modifications
- * - __u32
- - ``flags``
- - See :ref:`Slice Parameter Flags <h264_slice_flags>`
-
-.. _h264_slice_flags:
-
-``Slice Parameter Set Flags``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED``
- - 0x00000001
- -
- * - ``V4L2_H264_SLICE_FLAG_SP_FOR_SWITCH``
- - 0x00000002
- -
-
-``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)``
- Prediction weight table defined according to :ref:`h264`,
- section 7.4.3.2 "Prediction Weight Table Semantics".
- The prediction weight table must be passed by applications
- under the conditions explained in section 7.3.3 "Slice header
- syntax".
-
- .. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_h264_pred_weights
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_h264_pred_weights
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u16
- - ``luma_log2_weight_denom``
- -
- * - __u16
- - ``chroma_log2_weight_denom``
- -
- * - struct :c:type:`v4l2_h264_weight_factors`
- - ``weight_factors[2]``
- - The weight factors at index 0 are the weight factors for the reference
- list 0, the one at index 1 for the reference list 1.
-
-.. c:type:: v4l2_h264_weight_factors
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_h264_weight_factors
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __s16
- - ``luma_weight[32]``
- -
- * - __s16
- - ``luma_offset[32]``
- -
- * - __s16
- - ``chroma_weight[32][2]``
- -
- * - __s16
- - ``chroma_offset[32][2]``
- -
-
-``Picture Reference``
-
-.. c:type:: v4l2_h264_reference
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_h264_reference
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u8
- - ``fields``
- - Specifies how the picture is referenced. See :ref:`Reference Fields <h264_ref_fields>`
- * - __u8
- - ``index``
- - Index into the :c:type:`v4l2_ctrl_h264_decode_params`.dpb array.
-
-.. _h264_ref_fields:
-
-``Reference Fields``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_TOP_FIELD_REF``
- - 0x1
- - The top field in field pair is used for short-term reference.
- * - ``V4L2_H264_BOTTOM_FIELD_REF``
- - 0x2
- - The bottom field in field pair is used for short-term reference.
- * - ``V4L2_H264_FRAME_REF``
- - 0x3
- - The frame (or the top/bottom fields, if it's a field pair)
- is used for short-term reference.
-
-``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
- Specifies the decode parameters (as extracted from the bitstream)
- for the associated H264 slice data. This includes the necessary
- parameters for configuring a stateless hardware decoding pipeline
- for H264. The bitstream parameters are defined according to
- :ref:`h264`. For further documentation, refer to the above
- specification, unless there is an explicit comment stating
- otherwise.
-
- .. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_h264_decode_params
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_h264_decode_params
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - struct :c:type:`v4l2_h264_dpb_entry`
- - ``dpb[16]``
- -
- * - __u16
- - ``nal_ref_idc``
- - NAL reference ID value coming from the NAL Unit header
- * - __u16
- - ``frame_num``
- -
- * - __s32
- - ``top_field_order_cnt``
- - Picture Order Count for the coded top field
- * - __s32
- - ``bottom_field_order_cnt``
- - Picture Order Count for the coded bottom field
- * - __u16
- - ``idr_pic_id``
- -
- * - __u16
- - ``pic_order_cnt_lsb``
- -
- * - __s32
- - ``delta_pic_order_cnt_bottom``
- -
- * - __s32
- - ``delta_pic_order_cnt0``
- -
- * - __s32
- - ``delta_pic_order_cnt1``
- -
- * - __u32
- - ``dec_ref_pic_marking_bit_size``
- - Size in bits of the dec_ref_pic_marking() syntax element.
- * - __u32
- - ``pic_order_cnt_bit_size``
- - Combined size in bits of the picture order count related syntax
- elements: pic_order_cnt_lsb, delta_pic_order_cnt_bottom,
- delta_pic_order_cnt0, and delta_pic_order_cnt1.
- * - __u32
- - ``slice_group_change_cycle``
- -
- * - __u32
- - ``reserved``
- - Applications and drivers must set this to zero.
- * - __u32
- - ``flags``
- - See :ref:`Decode Parameters Flags <h264_decode_params_flags>`
-
-.. _h264_decode_params_flags:
-
-``Decode Parameters Flags``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC``
- - 0x00000001
- - That picture is an IDR picture
- * - ``V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC``
- - 0x00000002
- -
- * - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD``
- - 0x00000004
- -
-
-.. c:type:: v4l2_h264_dpb_entry
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_h264_dpb_entry
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u64
- - ``reference_ts``
- - Timestamp of the V4L2 capture buffer to use as reference, used
- with B-coded and P-coded frames. The timestamp refers to the
- ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
- :c:func:`v4l2_timeval_to_ns()` function to convert the struct
- :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
- * - __u32
- - ``pic_num``
- -
- * - __u16
- - ``frame_num``
- -
- * - __u8
- - ``fields``
- - Specifies how the DPB entry is referenced. See :ref:`Reference Fields <h264_ref_fields>`
- * - __u8
- - ``reserved[5]``
- - Applications and drivers must set this to zero.
- * - __s32
- - ``top_field_order_cnt``
- -
- * - __s32
- - ``bottom_field_order_cnt``
- -
- * - __u32
- - ``flags``
- - See :ref:`DPB Entry Flags <h264_dpb_flags>`
-
-.. _h264_dpb_flags:
-
-``DPB Entries Flags``
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_H264_DPB_ENTRY_FLAG_VALID``
- - 0x00000001
- - The DPB entry is valid (non-empty) and should be considered.
- * - ``V4L2_H264_DPB_ENTRY_FLAG_ACTIVE``
- - 0x00000002
- - The DPB entry is used for reference.
- * - ``V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM``
- - 0x00000004
- - The DPB entry is used for long-term reference.
- * - ``V4L2_H264_DPB_ENTRY_FLAG_FIELD``
- - 0x00000008
- - The DPB entry is a single field or a complementary field pair.
-
-``V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE (enum)``
- Specifies the decoding mode to use. Currently exposes slice-based and
- frame-based decoding but new modes might be added later on.
- This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
- pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
- are required to set this control in order to specify the decoding mode
- that is expected for the buffer.
- Drivers may expose a single or multiple decoding modes, depending
- on what they can support.
-
- .. note::
-
- This menu control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_mpeg_video_h264_decode_mode
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED``
- - 0
- - Decoding is done at the slice granularity.
- The OUTPUT buffer must contain a single slice.
- When this mode is selected, the ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS``
- control shall be set. When multiple slices compose a frame,
- use of ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` flag
- is required.
- * - ``V4L2_MPEG_VIDEO_H264_DECODE_MODE_FRAME_BASED``
- - 1
- - Decoding is done at the frame granularity,
- The OUTPUT buffer must contain all slices needed to decode the
- frame. The OUTPUT buffer must also contain both fields.
- This mode will be supported by devices that
- parse the slice(s) header(s) in hardware. When this mode is
- selected, the ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS``
- control shall not be set.
-
-``V4L2_CID_MPEG_VIDEO_H264_START_CODE (enum)``
- Specifies the H264 slice start code expected for each slice.
- This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
- pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
- are required to set this control in order to specify the start code
- that is expected for the buffer.
- Drivers may expose a single or multiple start codes, depending
- on what they can support.
-
- .. note::
-
- This menu control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_mpeg_video_h264_start_code
-
-.. cssclass:: longtable
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - ``V4L2_MPEG_VIDEO_H264_START_CODE_NONE``
- - 0
- - Selecting this value specifies that H264 slices are passed
- to the driver without any start code.
- * - ``V4L2_MPEG_VIDEO_H264_START_CODE_ANNEX_B``
- - 1
- - Selecting this value specifies that H264 slices are expected
- to be prefixed by Annex B start codes. According to :ref:`h264`
- valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001.
-
.. _v4l2-mpeg-mpeg2:
``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)``
@@ -2905,127 +2213,6 @@
- Force a non-coded frame.
-.. _v4l2-mpeg-fwht:
-
-``V4L2_CID_MPEG_VIDEO_FWHT_PARAMS (struct)``
- Specifies the fwht parameters (as extracted from the bitstream) for the
- associated FWHT data. This includes the necessary parameters for
- configuring a stateless hardware decoding pipeline for FWHT.
-
- .. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_fwht_params
-
-.. cssclass:: longtable
-
-.. tabularcolumns:: |p{1.4cm}|p{4.3cm}|p{11.8cm}|
-
-.. flat-table:: struct v4l2_ctrl_fwht_params
- :header-rows: 0
- :stub-columns: 0
- :widths: 1 1 2
-
- * - __u64
- - ``backward_ref_ts``
- - Timestamp of the V4L2 capture buffer to use as backward reference, used
- with P-coded frames. The timestamp refers to the
- ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
- :c:func:`v4l2_timeval_to_ns()` function to convert the struct
- :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
- * - __u32
- - ``version``
- - The version of the codec
- * - __u32
- - ``width``
- - The width of the frame
- * - __u32
- - ``height``
- - The height of the frame
- * - __u32
- - ``flags``
- - The flags of the frame, see :ref:`fwht-flags`.
- * - __u32
- - ``colorspace``
- - The colorspace of the frame, from enum :c:type:`v4l2_colorspace`.
- * - __u32
- - ``xfer_func``
- - The transfer function, from enum :c:type:`v4l2_xfer_func`.
- * - __u32
- - ``ycbcr_enc``
- - The Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
- * - __u32
- - ``quantization``
- - The quantization range, from enum :c:type:`v4l2_quantization`.
-
-
-
-.. _fwht-flags:
-
-FWHT Flags
-============
-
-.. cssclass:: longtable
-
-.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.3cm}|
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 3 1 4
-
- * - ``FWHT_FL_IS_INTERLACED``
- - 0x00000001
- - Set if this is an interlaced format
- * - ``FWHT_FL_IS_BOTTOM_FIRST``
- - 0x00000002
- - Set if this is a bottom-first (NTSC) interlaced format
- * - ``FWHT_FL_IS_ALTERNATE``
- - 0x00000004
- - Set if each 'frame' contains just one field
- * - ``FWHT_FL_IS_BOTTOM_FIELD``
- - 0x00000008
- - If FWHT_FL_IS_ALTERNATE was set, then this is set if this 'frame' is the
- bottom field, else it is the top field.
- * - ``FWHT_FL_LUMA_IS_UNCOMPRESSED``
- - 0x00000010
- - Set if the luma plane is uncompressed
- * - ``FWHT_FL_CB_IS_UNCOMPRESSED``
- - 0x00000020
- - Set if the cb plane is uncompressed
- * - ``FWHT_FL_CR_IS_UNCOMPRESSED``
- - 0x00000040
- - Set if the cr plane is uncompressed
- * - ``FWHT_FL_CHROMA_FULL_HEIGHT``
- - 0x00000080
- - Set if the chroma plane has the same height as the luma plane,
- else the chroma plane is half the height of the luma plane
- * - ``FWHT_FL_CHROMA_FULL_WIDTH``
- - 0x00000100
- - Set if the chroma plane has the same width as the luma plane,
- else the chroma plane is half the width of the luma plane
- * - ``FWHT_FL_ALPHA_IS_UNCOMPRESSED``
- - 0x00000200
- - Set if the alpha plane is uncompressed
- * - ``FWHT_FL_I_FRAME``
- - 0x00000400
- - Set if this is an I-frame
- * - ``FWHT_FL_COMPONENTS_NUM_MSK``
- - 0x00070000
- - A 4-values flag - the number of components - 1
- * - ``FWHT_FL_PIXENC_YUV``
- - 0x00080000
- - Set if the pixel encoding is YUV
- * - ``FWHT_FL_PIXENC_RGB``
- - 0x00100000
- - Set if the pixel encoding is RGB
- * - ``FWHT_FL_PIXENC_HSV``
- - 0x00180000
- - Set if the pixel encoding is HSV
-
-
CX2341x MPEG Controls
=====================
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst
index 9457dc3..de43f5c 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst
@@ -58,3 +58,17 @@
The unit cell consists of the whole area of the pixel, sensitive and
non-sensitive.
This control is required for automatic calibration of sensors/cameras.
+
+.. c:type:: v4l2_area
+
+.. flat-table:: struct v4l2_area
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __u32
+ - ``width``
+ - Width of the area.
+ * - __u32
+ - ``height``
+ - Height of the area.
diff --git a/Documentation/userspace-api/media/v4l/extended-controls.rst b/Documentation/userspace-api/media/v4l/extended-controls.rst
index 7030153..44fcd67 100644
--- a/Documentation/userspace-api/media/v4l/extended-controls.rst
+++ b/Documentation/userspace-api/media/v4l/extended-controls.rst
@@ -55,8 +55,8 @@
group similar controls into a single class. For example, control class
``V4L2_CTRL_CLASS_USER`` contains all user controls (i. e. all controls
that can also be set using the old :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>`
-ioctl). Control class ``V4L2_CTRL_CLASS_MPEG`` contains all controls
-relating to MPEG encoding, etc.
+ioctl). Control class ``V4L2_CTRL_CLASS_CODEC`` contains controls
+relating to codecs.
All controls in the control array must belong to the specified control
class. An error is returned if this is not the case.
@@ -130,9 +130,9 @@
.. code-block:: c
- qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL;
+ qctrl.id = V4L2_CTRL_CLASS_CODEC | V4L2_CTRL_FLAG_NEXT_CTRL;
while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &qctrl)) {
- if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_MPEG)
+ if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_CODEC)
break;
/* ... */
qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
index d585909..acad5f3 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
@@ -57,18 +57,18 @@
- H264 parsed slice data, including slice headers, either with or
without the start code, as extracted from the H264 bitstream.
This format is adapted for stateless video decoders that implement an
- H264 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`).
+ H264 pipeline with the :ref:`stateless_decoder`.
This pixelformat has two modifiers that must be set at least once
- through the ``V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE``
- and ``V4L2_CID_MPEG_VIDEO_H264_START_CODE`` controls.
+ through the ``V4L2_CID_STATELESS_H264_DECODE_MODE``
+ and ``V4L2_CID_STATELESS_H264_START_CODE`` controls.
In addition, metadata associated with the frame to decode are
- required to be passed through the ``V4L2_CID_MPEG_VIDEO_H264_SPS``,
- ``V4L2_CID_MPEG_VIDEO_H264_PPS``,
- ``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX``,
- ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS`` and
- ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS`` controls. See the
- :ref:`associated Codec Control IDs <v4l2-mpeg-h264>`. Exactly
- one output and one capture buffer must be provided for use
+ required to be passed through the ``V4L2_CID_STATELESS_H264_SPS``,
+ ``V4L2_CID_STATELESS_H264_PPS``,
+ ``V4L2_CID_STATELESS_H264_SCALING_MATRIX``,
+ ``V4L2_CID_STATELESS_H264_SLICE_PARAMS`` and
+ ``V4L2_CID_STATELESS_H264_DECODE_PARAMS`` controls. See the
+ :ref:`associated Codec Control IDs <v4l2-codec-stateless-h264>`.
+ Exactly one output and one capture buffer must be provided for use
with this pixel format. The output buffer must contain the
appropriate number of macroblocks to decode a full
corresponding frame to the matching capture buffer.
@@ -77,11 +77,6 @@
7.3.2.8 "Slice layer without partitioning RBSP syntax" and the following
sections.
- .. note::
-
- This format is not yet part of the public kernel API and it
- is expected to change.
-
* .. _V4L2-PIX-FMT-H263:
- ``V4L2_PIX_FMT_H263``
@@ -196,10 +191,10 @@
through the ``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE``
and ``V4L2_CID_MPEG_VIDEO_HEVC_START_CODE`` controls.
Metadata associated with the frame to decode is required to be passed
- through the following controls :
- * ``V4L2_CID_MPEG_VIDEO_HEVC_SPS``
- * ``V4L2_CID_MPEG_VIDEO_HEVC_PPS``
- * ``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS``
+ through the following controls:
+ ``V4L2_CID_MPEG_VIDEO_HEVC_SPS``,
+ ``V4L2_CID_MPEG_VIDEO_HEVC_PPS``, and
+ ``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS``.
See the :ref:`associated Codec Control IDs <v4l2-mpeg-hevc>`.
Buffers associated with this pixel format must contain the appropriate
number of macroblocks to decode a full corresponding frame.
@@ -222,4 +217,6 @@
- ``V4L2_PIX_FMT_FWHT_STATELESS``
- 'SFWH'
- Same format as V4L2_PIX_FMT_FWHT but requires stateless codec implementation.
- See the :ref:`associated Codec Control IDs <v4l2-mpeg-fwht>`.
+ Metadata associated with the frame to decode is required to be passed
+ through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control.
+ See the :ref:`associated Codec Control ID <codec-stateless-fwht>`.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-grey.rst b/Documentation/userspace-api/media/v4l/pixfmt-grey.rst
deleted file mode 100644
index 121365b..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-grey.rst
+++ /dev/null
@@ -1,44 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-GREY:
-
-**************************
-V4L2_PIX_FMT_GREY ('GREY')
-**************************
-
-Grey-scale image
-
-
-Description
-===========
-
-This is a grey-scale image. It is really a degenerate Y'CbCr format
-which simply contains no Cb or Cr data.
-
-**Byte Order.**
-Each cell is one byte.
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-m420.rst b/Documentation/userspace-api/media/v4l/pixfmt-m420.rst
index 13cf36a..c01a949 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-m420.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-m420.rst
@@ -67,60 +67,5 @@
**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- * - 2
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- - Y
- -
- - Y
+Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
+horizontally and vertically.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst b/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
index 7e43837..fa04f00 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
@@ -1,7 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _v4l2-meta-fmt-params-rkisp1:
-.. _v4l2-meta-fmt-stat-rkisp1:
+.. _v4l2-meta-fmt-rk-isp1-params:
+
+.. _v4l2-meta-fmt-rk-isp1-stat-3a:
*****************************************************************************
V4L2_META_FMT_RK_ISP1_PARAMS ('rk1p'), V4L2_META_FMT_RK_ISP1_STAT_3A ('rk1s')
@@ -46,4 +47,4 @@
rkisp1 uAPI data types
======================
-.. kernel-doc:: drivers/staging/media/rkisp1/uapi/rkisp1-config.h
+.. kernel-doc:: include/uapi/linux/rkisp1-config.h
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-nv12.rst b/Documentation/userspace-api/media/v4l/pixfmt-nv12.rst
deleted file mode 100644
index dd2f381..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-nv12.rst
+++ /dev/null
@@ -1,129 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-NV12:
-.. _V4L2-PIX-FMT-NV21:
-
-******************************************************
-V4L2_PIX_FMT_NV12 ('NV12'), V4L2_PIX_FMT_NV21 ('NV21')
-******************************************************
-
-
-V4L2_PIX_FMT_NV21
-Formats with ½ horizontal and vertical chroma resolution, also known as
-YUV 4:2:0. One luminance and one chrominance plane with alternating
-chroma samples as opposed to ``V4L2_PIX_FMT_YVU420``
-
-
-Description
-===========
-
-These are two-plane versions of the YUV 4:2:0 format. The three
-components are separated into two sub-images or planes. The Y plane is
-first. The Y plane has one byte per pixel. For ``V4L2_PIX_FMT_NV12``, a
-combined CbCr plane immediately follows the Y plane in memory. The CbCr
-plane is the same width, in bytes, as the Y plane (and of the image),
-but is half as tall in pixels. Each CbCr pair belongs to four pixels.
-For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
-Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`. ``V4L2_PIX_FMT_NV21`` is
-the same except the Cb and Cr bytes are swapped, the CrCb plane starts
-with a Cr byte.
-
-If the Y plane has pad bytes after each row, then the CbCr plane has as
-many pad bytes after its rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cb\ :sub:`00`
- - Cr\ :sub:`00`
- - Cb\ :sub:`01`
- - Cr\ :sub:`01`
- * - start + 20:
- - Cb\ :sub:`10`
- - Cr\ :sub:`10`
- - Cb\ :sub:`11`
- - Cr\ :sub:`11`
-
-
-**Color Sample Location:**
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- * - 2
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- - Y
- -
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-nv12m.rst b/Documentation/userspace-api/media/v4l/pixfmt-nv12m.rst
deleted file mode 100644
index 250f8b9..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-nv12m.rst
+++ /dev/null
@@ -1,144 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-NV12M:
-.. _v4l2-pix-fmt-nv12mt-16x16:
-.. _V4L2-PIX-FMT-NV21M:
-
-***********************************************************************************
-V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16
-***********************************************************************************
-
-
-V4L2_PIX_FMT_NV21M
-V4L2_PIX_FMT_NV12MT_16X16
-Variation of ``V4L2_PIX_FMT_NV12`` and ``V4L2_PIX_FMT_NV21`` with planes
-non contiguous in memory.
-
-
-Description
-===========
-
-This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
-three components are separated into two sub-images or planes.
-``V4L2_PIX_FMT_NV12M`` differs from ``V4L2_PIX_FMT_NV12`` in that the
-two planes are non-contiguous in memory, i.e. the chroma plane do not
-necessarily immediately follows the luma plane. The luminance data
-occupies the first plane. The Y plane has one byte per pixel. In the
-second plane there is a chrominance data with alternating chroma
-samples. The CbCr plane is the same width, in bytes, as the Y plane (and
-of the image), but is half as tall in pixels. Each CbCr pair belongs to
-four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
-Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
-``V4L2_PIX_FMT_NV12MT_16X16`` is the tiled version of
-``V4L2_PIX_FMT_NV12M`` with 16x16 macroblock tiles. Here pixels are
-arranged in 16x16 2D tiles and tiles are arranged in linear order in
-memory. ``V4L2_PIX_FMT_NV21M`` is the same as ``V4L2_PIX_FMT_NV12M``
-except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
-byte.
-
-``V4L2_PIX_FMT_NV12M`` is intended to be used only in drivers and
-applications that support the multi-planar API, described in
-:ref:`planar-apis`.
-
-If the Y plane has pad bytes after each row, then the CbCr plane has as
-many pad bytes after its rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start0 + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start0 + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start0 + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start0 + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * -
- * - start1 + 0:
- - Cb\ :sub:`00`
- - Cr\ :sub:`00`
- - Cb\ :sub:`01`
- - Cr\ :sub:`01`
- * - start1 + 4:
- - Cb\ :sub:`10`
- - Cr\ :sub:`10`
- - Cb\ :sub:`11`
- - Cr\ :sub:`11`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- * - 2
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- - Y
- -
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-nv12mt.rst b/Documentation/userspace-api/media/v4l/pixfmt-nv12mt.rst
deleted file mode 100644
index 46f63d7..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-nv12mt.rst
+++ /dev/null
@@ -1,60 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-NV12MT:
-
-****************************
-V4L2_PIX_FMT_NV12MT ('TM12')
-****************************
-
-Formats with ½ horizontal and vertical chroma resolution. This format
-has two planes - one for luminance and one for chrominance. Chroma
-samples are interleaved. The difference to ``V4L2_PIX_FMT_NV12`` is the
-memory layout. Pixels are grouped in macroblocks of 64x32 size. The
-order of macroblocks in memory is also not standard.
-
-
-Description
-===========
-
-This is the two-plane versions of the YUV 4:2:0 format where data is
-grouped into 64x32 macroblocks. The three components are separated into
-two sub-images or planes. The Y plane has one byte per pixel and pixels
-are grouped into 64x32 macroblocks. The CbCr plane has the same width,
-in bytes, as the Y plane (and the image), but is half as tall in pixels.
-The chroma plane is also grouped into 64x32 macroblocks.
-
-Width of the buffer has to be aligned to the multiple of 128, and height
-alignment is 32. Every four adjacent buffers - two horizontally and two
-vertically are grouped together and are located in memory in Z or
-flipped Z order.
-
-Layout of macroblocks in memory is presented in the following figure.
-
-
-.. _nv12mt:
-
-.. kernel-figure:: nv12mt.svg
- :alt: nv12mt.svg
- :align: center
-
- V4L2_PIX_FMT_NV12MT macroblock Z shape memory layout
-
-The requirement that width is multiple of 128 is implemented because,
-the Z shape cannot be cut in half horizontally. In case the vertical
-resolution of macroblocks is odd then the last row of macroblocks is
-arranged in a linear order.
-
-In case of chroma the layout is identical. Cb and Cr samples are
-interleaved. Height of the buffer is aligned to 32.
-
-
-.. _nv12mt_ex:
-
-.. kernel-figure:: nv12mt_example.svg
- :alt: nv12mt_example.svg
- :align: center
-
- Example V4L2_PIX_FMT_NV12MT memory layout of macroblocks
-
-Memory layout of macroblocks of ``V4L2_PIX_FMT_NV12MT`` format in most
-extreme case.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-nv16.rst b/Documentation/userspace-api/media/v4l/pixfmt-nv16.rst
deleted file mode 100644
index 22295fc..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-nv16.rst
+++ /dev/null
@@ -1,153 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-NV16:
-.. _V4L2-PIX-FMT-NV61:
-
-******************************************************
-V4L2_PIX_FMT_NV16 ('NV16'), V4L2_PIX_FMT_NV61 ('NV61')
-******************************************************
-
-V4L2_PIX_FMT_NV61
-Formats with ½ horizontal chroma resolution, also known as YUV 4:2:2.
-One luminance and one chrominance plane with alternating chroma samples
-as opposed to ``V4L2_PIX_FMT_YVU420``
-
-
-Description
-===========
-
-These are two-plane versions of the YUV 4:2:2 format. The three
-components are separated into two sub-images or planes. The Y plane is
-first. The Y plane has one byte per pixel. For ``V4L2_PIX_FMT_NV16``, a
-combined CbCr plane immediately follows the Y plane in memory. The CbCr
-plane is the same width and height, in bytes, as the Y plane (and of the
-image). Each CbCr pair belongs to two pixels. For example,
-Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`, Y'\ :sub:`01`.
-``V4L2_PIX_FMT_NV61`` is the same except the Cb and Cr bytes are
-swapped, the CrCb plane starts with a Cr byte.
-
-If the Y plane has pad bytes after each row, then the CbCr plane has as
-many pad bytes after its rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cb\ :sub:`00`
- - Cr\ :sub:`00`
- - Cb\ :sub:`01`
- - Cr\ :sub:`01`
- * - start + 20:
- - Cb\ :sub:`10`
- - Cr\ :sub:`10`
- - Cb\ :sub:`11`
- - Cr\ :sub:`11`
- * - start + 24:
- - Cb\ :sub:`20`
- - Cr\ :sub:`20`
- - Cb\ :sub:`21`
- - Cr\ :sub:`21`
- * - start + 28:
- - Cb\ :sub:`30`
- - Cr\ :sub:`30`
- - Cb\ :sub:`31`
- - Cr\ :sub:`31`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * -
- * - 2
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-nv16m.rst b/Documentation/userspace-api/media/v4l/pixfmt-nv16m.rst
deleted file mode 100644
index 812bf2c..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-nv16m.rst
+++ /dev/null
@@ -1,157 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-NV16M:
-.. _v4l2-pix-fmt-nv61m:
-
-********************************************************
-V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61')
-********************************************************
-
-V4L2_PIX_FMT_NV61M
-Variation of ``V4L2_PIX_FMT_NV16`` and ``V4L2_PIX_FMT_NV61`` with planes
-non contiguous in memory.
-
-
-Description
-===========
-
-This is a multi-planar, two-plane version of the YUV 4:2:2 format. The
-three components are separated into two sub-images or planes.
-``V4L2_PIX_FMT_NV16M`` differs from ``V4L2_PIX_FMT_NV16`` in that the
-two planes are non-contiguous in memory, i.e. the chroma plane does not
-necessarily immediately follow the luma plane. The luminance data
-occupies the first plane. The Y plane has one byte per pixel. In the
-second plane there is chrominance data with alternating chroma samples.
-The CbCr plane is the same width and height, in bytes, as the Y plane.
-Each CbCr pair belongs to two pixels. For example,
-Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`, Y'\ :sub:`01`.
-``V4L2_PIX_FMT_NV61M`` is the same as ``V4L2_PIX_FMT_NV16M`` except the
-Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.
-
-``V4L2_PIX_FMT_NV16M`` and ``V4L2_PIX_FMT_NV61M`` are intended to be
-used only in drivers and applications that support the multi-planar API,
-described in :ref:`planar-apis`.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start0 + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start0 + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start0 + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start0 + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * -
- * - start1 + 0:
- - Cb\ :sub:`00`
- - Cr\ :sub:`00`
- - Cb\ :sub:`02`
- - Cr\ :sub:`02`
- * - start1 + 4:
- - Cb\ :sub:`10`
- - Cr\ :sub:`10`
- - Cb\ :sub:`12`
- - Cr\ :sub:`12`
- * - start1 + 8:
- - Cb\ :sub:`20`
- - Cr\ :sub:`20`
- - Cb\ :sub:`22`
- - Cr\ :sub:`22`
- * - start1 + 12:
- - Cb\ :sub:`30`
- - Cr\ :sub:`30`
- - Cb\ :sub:`32`
- - Cr\ :sub:`32`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * -
- * - 2
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- - C
- -
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-nv24.rst b/Documentation/userspace-api/media/v4l/pixfmt-nv24.rst
deleted file mode 100644
index bf1b940..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-nv24.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-NV24:
-.. _V4L2-PIX-FMT-NV42:
-
-******************************************************
-V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42')
-******************************************************
-
-V4L2_PIX_FMT_NV42
-Formats with full horizontal and vertical chroma resolutions, also known
-as YUV 4:4:4. One luminance and one chrominance plane with alternating
-chroma samples as opposed to ``V4L2_PIX_FMT_YVU420``
-
-
-Description
-===========
-
-These are two-plane versions of the YUV 4:4:4 format. The three
-components are separated into two sub-images or planes. The Y plane is
-first, with each Y sample stored in one byte per pixel. For
-``V4L2_PIX_FMT_NV24``, a combined CbCr plane immediately follows the Y
-plane in memory. The CbCr plane has the same width and height, in
-pixels, as the Y plane (and the image). Each line contains one CbCr pair
-per pixel, with each Cb and Cr sample stored in one byte.
-``V4L2_PIX_FMT_NV42`` is the same except that the Cb and Cr samples are
-swapped, the CrCb plane starts with a Cr sample.
-
-If the Y plane has pad bytes after each row, then the CbCr plane has
-twice as many pad bytes after its rows.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cb\ :sub:`00`
- - Cr\ :sub:`00`
- - Cb\ :sub:`01`
- - Cr\ :sub:`01`
- - Cb\ :sub:`02`
- - Cr\ :sub:`02`
- - Cb\ :sub:`03`
- - Cr\ :sub:`03`
- * - start + 24:
- - Cb\ :sub:`10`
- - Cr\ :sub:`10`
- - Cb\ :sub:`11`
- - Cr\ :sub:`11`
- - Cb\ :sub:`12`
- - Cr\ :sub:`12`
- - Cb\ :sub:`13`
- - Cr\ :sub:`13`
- * - start + 32:
- - Cb\ :sub:`20`
- - Cr\ :sub:`20`
- - Cb\ :sub:`21`
- - Cr\ :sub:`21`
- - Cb\ :sub:`22`
- - Cr\ :sub:`22`
- - Cb\ :sub:`23`
- - Cr\ :sub:`23`
- * - start + 40:
- - Cb\ :sub:`30`
- - Cr\ :sub:`30`
- - Cb\ :sub:`31`
- - Cr\ :sub:`31`
- - Cb\ :sub:`32`
- - Cr\ :sub:`32`
- - Cb\ :sub:`33`
- - Cr\ :sub:`33`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
index 8426220..eb551b5 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
@@ -6,12 +6,32 @@
Packed YUV formats
******************
-Description
-===========
+Similarly to the packed RGB formats, the packed YUV formats store the Y, Cb and
+Cr components consecutively in memory. They may apply subsampling to the chroma
+components and thus differ in how they interlave the three components.
-Similar to the packed RGB formats these formats store the Y, Cb and Cr
-component of each pixel in one 16 or 32 bit word.
+.. note::
+ - In all the tables that follow, bit 7 is the most significant bit in a byte.
+ - 'Y', 'Cb' and 'Cr' denote bits of the luma, blue chroma (also known as
+ 'U') and red chroma (also known as 'V') components respectively. 'A'
+ denotes bits of the alpha component (if supported by the format), and 'X'
+ denotes padding bits.
+
+
+4:4:4 Subsampling
+=================
+
+These formats do not subsample the chroma components and store each pixels as a
+full triplet of Y, Cb and Cr values.
+
+The next table lists the packed YUV 4:4:4 formats with less than 8 bits per
+component. They are named based on the order of the Y, Cb and Cr components as
+seen in a 16-bit word, which is then stored in memory in little endian byte
+order, and on the number of bits for each component. For instance the YUV565
+format stores a pixel in a 16-bit word [15:0] laid out at as [Y'\ :sub:`4-0`
+Cb\ :sub:`5-0` Cr\ :sub:`4-0`], and stored in memory in two bytes,
+[Cb\ :sub:`2-0` Cr\ :sub:`4-0`] followed by [Y'\ :sub:`4-0` Cb\ :sub:`5-3`].
.. raw:: latex
@@ -19,11 +39,9 @@
\tiny
\setlength{\tabcolsep}{2pt}
-.. _packed-yuv-formats:
+.. tabularcolumns:: |p{2.5cm}|p{0.69cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|
-.. tabularcolumns:: |p{2.5cm}|p{0.69cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|
-
-.. flat-table:: Packed YUV Image Formats
+.. flat-table:: Packed YUV 4:4:4 Image Formats (less than 8bpc)
:header-rows: 2
:stub-columns: 0
@@ -34,10 +52,6 @@
- :cspan:`7` Byte 1
- - :cspan:`7` Byte 2
-
- - :cspan:`7` Byte 3
-
* -
-
- 7
@@ -58,24 +72,6 @@
- 1
- 0
- - 7
- - 6
- - 5
- - 4
- - 3
- - 2
- - 1
- - 0
-
- - 7
- - 6
- - 5
- - 4
- - 3
- - 2
- - 1
- - 0
-
* .. _V4L2-PIX-FMT-YUV444:
- ``V4L2_PIX_FMT_YUV444``
@@ -99,8 +95,6 @@
- Y'\ :sub:`1`
- Y'\ :sub:`0`
- - :cspan:`15`
-
* .. _V4L2-PIX-FMT-YUV555:
- ``V4L2_PIX_FMT_YUV555``
@@ -124,7 +118,6 @@
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- - :cspan:`15`
* .. _V4L2-PIX-FMT-YUV565:
- ``V4L2_PIX_FMT_YUV565``
@@ -148,226 +141,219 @@
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- - :cspan:`15`
-
- * .. _V4L2-PIX-FMT-YUV32:
-
- - ``V4L2_PIX_FMT_YUV32``
- - 'YUV4'
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
-
- - Y'\ :sub:`7`
- - Y'\ :sub:`6`
- - Y'\ :sub:`5`
- - Y'\ :sub:`4`
- - Y'\ :sub:`3`
- - Y'\ :sub:`2`
- - Y'\ :sub:`1`
- - Y'\ :sub:`0`
-
- - Cb\ :sub:`7`
- - Cb\ :sub:`6`
- - Cb\ :sub:`5`
- - Cb\ :sub:`4`
- - Cb\ :sub:`3`
- - Cb\ :sub:`2`
- - Cb\ :sub:`1`
- - Cb\ :sub:`0`
-
- - Cr\ :sub:`7`
- - Cr\ :sub:`6`
- - Cr\ :sub:`5`
- - Cr\ :sub:`4`
- - Cr\ :sub:`3`
- - Cr\ :sub:`2`
- - Cr\ :sub:`1`
- - Cr\ :sub:`0`
-
- * .. _V4L2-PIX-FMT-AYUV32:
-
- - ``V4L2_PIX_FMT_AYUV32``
- - 'AYUV'
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
-
- - Y'\ :sub:`7`
- - Y'\ :sub:`6`
- - Y'\ :sub:`5`
- - Y'\ :sub:`4`
- - Y'\ :sub:`3`
- - Y'\ :sub:`2`
- - Y'\ :sub:`1`
- - Y'\ :sub:`0`
-
- - Cb\ :sub:`7`
- - Cb\ :sub:`6`
- - Cb\ :sub:`5`
- - Cb\ :sub:`4`
- - Cb\ :sub:`3`
- - Cb\ :sub:`2`
- - Cb\ :sub:`1`
- - Cb\ :sub:`0`
-
- - Cr\ :sub:`7`
- - Cr\ :sub:`6`
- - Cr\ :sub:`5`
- - Cr\ :sub:`4`
- - Cr\ :sub:`3`
- - Cr\ :sub:`2`
- - Cr\ :sub:`1`
- - Cr\ :sub:`0`
-
- * .. _V4L2-PIX-FMT-XYUV32:
-
- - ``V4L2_PIX_FMT_XYUV32``
- - 'XYUV'
-
- -
- -
- -
- -
- -
- -
- -
- -
-
- - Y'\ :sub:`7`
- - Y'\ :sub:`6`
- - Y'\ :sub:`5`
- - Y'\ :sub:`4`
- - Y'\ :sub:`3`
- - Y'\ :sub:`2`
- - Y'\ :sub:`1`
- - Y'\ :sub:`0`
-
- - Cb\ :sub:`7`
- - Cb\ :sub:`6`
- - Cb\ :sub:`5`
- - Cb\ :sub:`4`
- - Cb\ :sub:`3`
- - Cb\ :sub:`2`
- - Cb\ :sub:`1`
- - Cb\ :sub:`0`
-
- - Cr\ :sub:`7`
- - Cr\ :sub:`6`
- - Cr\ :sub:`5`
- - Cr\ :sub:`4`
- - Cr\ :sub:`3`
- - Cr\ :sub:`2`
- - Cr\ :sub:`1`
- - Cr\ :sub:`0`
-
- * .. _V4L2-PIX-FMT-VUYA32:
-
- - ``V4L2_PIX_FMT_VUYA32``
- - 'VUYA'
-
- - Cr\ :sub:`7`
- - Cr\ :sub:`6`
- - Cr\ :sub:`5`
- - Cr\ :sub:`4`
- - Cr\ :sub:`3`
- - Cr\ :sub:`2`
- - Cr\ :sub:`1`
- - Cr\ :sub:`0`
-
- - Cb\ :sub:`7`
- - Cb\ :sub:`6`
- - Cb\ :sub:`5`
- - Cb\ :sub:`4`
- - Cb\ :sub:`3`
- - Cb\ :sub:`2`
- - Cb\ :sub:`1`
- - Cb\ :sub:`0`
-
- - Y'\ :sub:`7`
- - Y'\ :sub:`6`
- - Y'\ :sub:`5`
- - Y'\ :sub:`4`
- - Y'\ :sub:`3`
- - Y'\ :sub:`2`
- - Y'\ :sub:`1`
- - Y'\ :sub:`0`
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
-
- * .. _V4L2-PIX-FMT-VUYX32:
-
- - ``V4L2_PIX_FMT_VUYX32``
- - 'VUYX'
-
- - Cr\ :sub:`7`
- - Cr\ :sub:`6`
- - Cr\ :sub:`5`
- - Cr\ :sub:`4`
- - Cr\ :sub:`3`
- - Cr\ :sub:`2`
- - Cr\ :sub:`1`
- - Cr\ :sub:`0`
-
- - Cb\ :sub:`7`
- - Cb\ :sub:`6`
- - Cb\ :sub:`5`
- - Cb\ :sub:`4`
- - Cb\ :sub:`3`
- - Cb\ :sub:`2`
- - Cb\ :sub:`1`
- - Cb\ :sub:`0`
-
- - Y'\ :sub:`7`
- - Y'\ :sub:`6`
- - Y'\ :sub:`5`
- - Y'\ :sub:`4`
- - Y'\ :sub:`3`
- - Y'\ :sub:`2`
- - Y'\ :sub:`1`
- - Y'\ :sub:`0`
-
- -
- -
- -
- -
- -
- -
- -
- -
-
.. raw:: latex
\endgroup
.. note::
- #) Bit 7 is the most significant bit;
+ For the YUV444 and YUV555 formats, the value of alpha bits is undefined
+ when reading from the driver, ignored when writing to the driver, except
+ when alpha blending has been negotiated for a :ref:`Video Overlay
+ <overlay>` or :ref:`Video Output Overlay <osd>`.
- #) The value of a = alpha bits is undefined when reading from the driver,
- ignored when writing to the driver, except when alpha blending has
- been negotiated for a :ref:`Video Overlay <overlay>` or
- :ref:`Video Output Overlay <osd>` for the formats Y444, YUV555 and
- YUV4. However, for formats AYUV32 and VUYA32, the alpha component is
- expected to contain a meaningful value that can be used by drivers
- and applications. And, the formats XYUV32 and VUYX32 contain undefined
- alpha values that must be ignored by all applications and drivers.
+
+The next table lists the packed YUV 4:4:4 formats with 8 bits per component.
+They are named based on the order of the Y, Cb and Cr components as stored in
+memory, and on the total number of bits per pixel. For instance, the VUYX32
+format stores a pixel with Cr\ :sub:`7-0` in the first byte, Cb\ :sub:`7-0` in
+the second byte and Y'\ :sub:`7-0` in the third byte.
+
+.. flat-table:: Packed YUV Image Formats (8bpc)
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Byte 0
+ - Byte 1
+ - Byte 2
+ - Byte 3
+
+ * .. _V4L2-PIX-FMT-YUV32:
+
+ - ``V4L2_PIX_FMT_YUV32``
+ - 'YUV4'
+
+ - A\ :sub:`7-0`
+ - Y'\ :sub:`7-0`
+ - Cb\ :sub:`7-0`
+ - Cr\ :sub:`7-0`
+
+ * .. _V4L2-PIX-FMT-AYUV32:
+
+ - ``V4L2_PIX_FMT_AYUV32``
+ - 'AYUV'
+
+ - A\ :sub:`7-0`
+ - Y'\ :sub:`7-0`
+ - Cb\ :sub:`7-0`
+ - Cr\ :sub:`7-0`
+
+ * .. _V4L2-PIX-FMT-XYUV32:
+
+ - ``V4L2_PIX_FMT_XYUV32``
+ - 'XYUV'
+
+ - X\ :sub:`7-0`
+ - Y'\ :sub:`7-0`
+ - Cb\ :sub:`7-0`
+ - Cr\ :sub:`7-0`
+
+ * .. _V4L2-PIX-FMT-VUYA32:
+
+ - ``V4L2_PIX_FMT_VUYA32``
+ - 'VUYA'
+
+ - Cr\ :sub:`7-0`
+ - Cb\ :sub:`7-0`
+ - Y'\ :sub:`7-0`
+ - A\ :sub:`7-0`
+
+ * .. _V4L2-PIX-FMT-VUYX32:
+
+ - ``V4L2_PIX_FMT_VUYX32``
+ - 'VUYX'
+
+ - Cr\ :sub:`7-0`
+ - Cb\ :sub:`7-0`
+ - Y'\ :sub:`7-0`
+ - X\ :sub:`7-0`
+
+.. note::
+
+ - The alpha component is expected to contain a meaningful value that can be
+ used by drivers and applications.
+ - The padding bits contain undefined values that must be ignored by all
+ applications and drivers.
+
+
+4:2:2 Subsampling
+=================
+
+These formats, commonly referred to as YUYV or YUY2, subsample the chroma
+components horizontally by 2, storing 2 pixels in 4 bytes.
+
+.. flat-table:: Packed YUV 4:2:2 Formats
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Byte 0
+ - Byte 1
+ - Byte 2
+ - Byte 3
+ - Byte 4
+ - Byte 5
+ - Byte 6
+ - Byte 7
+ * .. _V4L2-PIX-FMT-UYVY:
+
+ - ``V4L2_PIX_FMT_UYVY``
+ - 'UYVY'
+
+ - Cb\ :sub:`0`
+ - Y'\ :sub:`0`
+ - Cr\ :sub:`0`
+ - Y'\ :sub:`1`
+ - Cb\ :sub:`2`
+ - Y'\ :sub:`2`
+ - Cr\ :sub:`2`
+ - Y'\ :sub:`3`
+ * .. _V4L2-PIX-FMT-VYUY:
+
+ - ``V4L2_PIX_FMT_VYUY``
+ - 'VYUY'
+
+ - Cr\ :sub:`0`
+ - Y'\ :sub:`0`
+ - Cb\ :sub:`0`
+ - Y'\ :sub:`1`
+ - Cr\ :sub:`2`
+ - Y'\ :sub:`2`
+ - Cb\ :sub:`2`
+ - Y'\ :sub:`3`
+ * .. _V4L2-PIX-FMT-YUYV:
+
+ - ``V4L2_PIX_FMT_YUYV``
+ - 'YUYV'
+
+ - Y'\ :sub:`0`
+ - Cb\ :sub:`0`
+ - Y'\ :sub:`1`
+ - Cr\ :sub:`0`
+ - Y'\ :sub:`2`
+ - Cb\ :sub:`2`
+ - Y'\ :sub:`3`
+ - Cr\ :sub:`2`
+ * .. _V4L2-PIX-FMT-YVYU:
+
+ - ``V4L2_PIX_FMT_YVYU``
+ - 'YVYU'
+
+ - Y'\ :sub:`0`
+ - Cr\ :sub:`0`
+ - Y'\ :sub:`1`
+ - Cb\ :sub:`0`
+ - Y'\ :sub:`2`
+ - Cr\ :sub:`2`
+ - Y'\ :sub:`3`
+ - Cb\ :sub:`2`
+
+**Color Sample Location:**
+Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
+horizontally.
+
+
+4:1:1 Subsampling
+=================
+
+This format subsamples the chroma components horizontally by 4, storing 8
+pixels in 12 bytes.
+
+.. flat-table:: Packed YUV 4:1:1 Formats
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Byte 0
+ - Byte 1
+ - Byte 2
+ - Byte 3
+ - Byte 4
+ - Byte 5
+ - Byte 6
+ - Byte 7
+ - Byte 8
+ - Byte 9
+ - Byte 10
+ - Byte 11
+ * .. _V4L2-PIX-FMT-Y41P:
+
+ - ``V4L2_PIX_FMT_Y41P``
+ - 'Y41P'
+
+ - Cb\ :sub:`0`
+ - Y'\ :sub:`0`
+ - Cr\ :sub:`0`
+ - Y'\ :sub:`1`
+ - Cb\ :sub:`4`
+ - Y'\ :sub:`2`
+ - Cr\ :sub:`4`
+ - Y'\ :sub:`3`
+ - Y'\ :sub:`4`
+ - Y'\ :sub:`5`
+ - Y'\ :sub:`6`
+ - Y'\ :sub:`7`
+
+.. note::
+
+ Do not confuse ``V4L2_PIX_FMT_Y41P`` with
+ :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>`. Y41P is derived from
+ "YUV 4:1:1 *packed*", while YUV411P stands for "YUV 4:1:1 *planar*".
+
+**Color Sample Location:**
+Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
+horizontally.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
index 9d82709..897676e 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
@@ -6,13 +6,62 @@
RGB Formats
***********
-Description
-===========
+These formats encode each pixel as a triplet of RGB values. They are packed
+formats, meaning that the RGB values for one pixel are stored consecutively in
+memory and each pixel consumes an integer number of bytes. When the number of
+bits required to store a pixel is not aligned to a byte boundary, the data is
+padded with additional bits to fill the remaining byte.
-These formats are designed to match the pixel formats of typical PC
-graphics frame buffers. They occupy 8, 16, 24 or 32 bits per pixel.
-These are all packed-pixel formats, meaning all the data for a pixel lie
-next to each other in memory.
+The formats differ by the number of bits per RGB component (typically but not
+always the same for all components), the order of components in memory, and the
+presence of an alpha component or additional padding bits.
+
+The usage and value of the alpha bits in formats that support them (named ARGB
+or a permutation thereof, collectively referred to as alpha formats) depend on
+the device type and hardware operation. :ref:`Capture <capture>` devices
+(including capture queues of mem-to-mem devices) fill the alpha component in
+memory. When the device captures an alpha channel the alpha component will have
+a meaningful value. Otherwise, when the device doesn't capture an alpha channel
+but can set the alpha bit to a user-configurable value, the
+:ref:`V4L2_CID_ALPHA_COMPONENT <v4l2-alpha-component>` control is used to
+specify that alpha value, and the alpha component of all pixels will be set to
+the value specified by that control. Otherwise a corresponding format without
+an alpha component (XRGB or XBGR) must be used instead of an alpha format.
+
+:ref:`Output <output>` devices (including output queues of mem-to-mem devices
+and :ref:`video output overlay <osd>` devices) read the alpha component from
+memory. When the device processes the alpha channel the alpha component must be
+filled with meaningful values by applications. Otherwise a corresponding format
+without an alpha component (XRGB or XBGR) must be used instead of an alpha
+format.
+
+Formats that contain padding bits are named XRGB (or a permutation thereof).
+The padding bits contain undefined values and must be ignored by applications,
+devices and drivers, for both :ref:`capture` and :ref:`output` devices.
+
+.. note::
+
+ - In all the tables that follow, bit 7 is the most significant bit in a byte.
+ - 'r', 'g' and 'b' denote bits of the red, green and blue components
+ respectively. 'a' denotes bits of the alpha component (if supported by the
+ format), and 'x' denotes padding bits.
+
+
+Less Than 8 Bits Per Component
+==============================
+
+These formats store an RGB triplet in one, two or four bytes. They are named
+based on the order of the RGB components as seen in a 8-, 16- or 32-bit word,
+which is then stored in memory in little endian byte order (unless otherwise
+noted by the presence of bit 31 in the 4CC value), and on the number of bits
+for each component. For instance, the RGB565 format stores a pixel in a 16-bit
+word [15:0] laid out at as [R\ :sub:`4` R\ :sub:`3` R\ :sub:`2` R\ :sub:`1`
+R\ :sub:`0` G\ :sub:`5` G\ :sub:`4` G\ :sub:`3` G\ :sub:`2` G\ :sub:`1`
+G\ :sub:`0` B\ :sub:`4` B\ :sub:`3` B\ :sub:`2` B\ :sub:`1` B\ :sub:`0`], and
+stored in memory in two bytes, [R\ :sub:`4` R\ :sub:`3` R\ :sub:`2` R\ :sub:`1`
+R\ :sub:`0` G\ :sub:`5` G\ :sub:`4` G\ :sub:`3`] followed by [G\ :sub:`2`
+G\ :sub:`1` G\ :sub:`0` B\ :sub:`4` B\ :sub:`3` B\ :sub:`2` B\ :sub:`1`
+B\ :sub:`0`].
.. raw:: latex
@@ -23,7 +72,7 @@
.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
-.. flat-table:: RGB Image Formats
+.. flat-table:: RGB Formats With Less Than 8 Bits Per Component
:header-rows: 2
:stub-columns: 0
@@ -121,10 +170,10 @@
- b\ :sub:`1`
- b\ :sub:`0`
- - `-`
- - `-`
- - `-`
- - `-`
+ - x
+ - x
+ - x
+ - x
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
@@ -162,10 +211,10 @@
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- - `-`
- - `-`
- - `-`
- - `-`
+ - x
+ - x
+ - x
+ - x
- r\ :sub:`3`
- r\ :sub:`2`
@@ -213,10 +262,10 @@
- r\ :sub:`1`
- r\ :sub:`0`
- - `-`
- - `-`
- - `-`
- - `-`
+ - x
+ - x
+ - x
+ - x
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
@@ -254,10 +303,10 @@
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- - `-`
- - `-`
- - `-`
- - `-`
+ - x
+ - x
+ - x
+ - x
- b\ :sub:`3`
- b\ :sub:`2`
@@ -305,7 +354,7 @@
- b\ :sub:`1`
- b\ :sub:`0`
- - `-`
+ - x
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
@@ -349,7 +398,7 @@
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- - `-`
+ - x
- r\ :sub:`4`
- r\ :sub:`3`
@@ -397,7 +446,7 @@
- r\ :sub:`1`
- r\ :sub:`0`
- - `-`
+ - x
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
@@ -441,7 +490,7 @@
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- - `-`
+ - x
- b\ :sub:`4`
- b\ :sub:`3`
@@ -503,7 +552,7 @@
- ``V4L2_PIX_FMT_XRGB555X``
- 'XR15' | (1 << 31)
- - `-`
+ - x
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
@@ -544,70 +593,6 @@
- b\ :sub:`1`
- b\ :sub:`0`
-
- * .. _V4L2-PIX-FMT-BGR24:
-
- - ``V4L2_PIX_FMT_BGR24``
- - 'BGR3'
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
- -
- * .. _V4L2-PIX-FMT-RGB24:
-
- - ``V4L2_PIX_FMT_RGB24``
- - 'RGB3'
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
- -
* .. _V4L2-PIX-FMT-BGR666:
- ``V4L2_PIX_FMT_BGR666``
@@ -633,449 +618,163 @@
- r\ :sub:`1`
- r\ :sub:`0`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
+ - x
+ - x
+ - x
+ - x
+ - x
+ - x
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- * .. _V4L2-PIX-FMT-ABGR32:
-
- - ``V4L2_PIX_FMT_ABGR32``
- - 'AR24'
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
- * .. _V4L2-PIX-FMT-XBGR32:
-
- - ``V4L2_PIX_FMT_XBGR32``
- - 'XR24'
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- * .. _V4L2-PIX-FMT-BGRA32:
-
- - ``V4L2_PIX_FMT_BGRA32``
- - 'RA24'
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
- * .. _V4L2-PIX-FMT-BGRX32:
-
- - ``V4L2_PIX_FMT_BGRX32``
- - 'RX24'
-
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
- * .. _V4L2-PIX-FMT-RGBA32:
-
- - ``V4L2_PIX_FMT_RGBA32``
- - 'AB24'
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
- * .. _V4L2-PIX-FMT-RGBX32:
-
- - ``V4L2_PIX_FMT_RGBX32``
- - 'XB24'
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
-
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- * .. _V4L2-PIX-FMT-ARGB32:
-
- - ``V4L2_PIX_FMT_ARGB32``
- - 'BA24'
-
- - a\ :sub:`7`
- - a\ :sub:`6`
- - a\ :sub:`5`
- - a\ :sub:`4`
- - a\ :sub:`3`
- - a\ :sub:`2`
- - a\ :sub:`1`
- - a\ :sub:`0`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
- * .. _V4L2-PIX-FMT-XRGB32:
-
- - ``V4L2_PIX_FMT_XRGB32``
- - 'BX24'
-
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
- - `-`
-
- - r\ :sub:`7`
- - r\ :sub:`6`
- - r\ :sub:`5`
- - r\ :sub:`4`
- - r\ :sub:`3`
- - r\ :sub:`2`
- - r\ :sub:`1`
- - r\ :sub:`0`
-
- - g\ :sub:`7`
- - g\ :sub:`6`
- - g\ :sub:`5`
- - g\ :sub:`4`
- - g\ :sub:`3`
- - g\ :sub:`2`
- - g\ :sub:`1`
- - g\ :sub:`0`
-
- - b\ :sub:`7`
- - b\ :sub:`6`
- - b\ :sub:`5`
- - b\ :sub:`4`
- - b\ :sub:`3`
- - b\ :sub:`2`
- - b\ :sub:`1`
- - b\ :sub:`0`
+ - x
+ - x
+ - x
+ - x
+ - x
+ - x
+ - x
+ - x
.. raw:: latex
\endgroup
-.. note:: Bit 7 is the most significant bit.
-The usage and value of the alpha bits (a) in the ARGB and ABGR formats
-(collectively referred to as alpha formats) depend on the device type
-and hardware operation. :ref:`Capture <capture>` devices (including
-capture queues of mem-to-mem devices) fill the alpha component in
-memory. When the device outputs an alpha channel the alpha component
-will have a meaningful value. Otherwise, when the device doesn't output
-an alpha channel but can set the alpha bit to a user-configurable value,
-the :ref:`V4L2_CID_ALPHA_COMPONENT <v4l2-alpha-component>` control
-is used to specify that alpha value, and the alpha component of all
-pixels will be set to the value specified by that control. Otherwise a
-corresponding format without an alpha component (XRGB or XBGR) must be
-used instead of an alpha format.
+8 Bits Per Component
+====================
-:ref:`Output <output>` devices (including output queues of mem-to-mem
-devices and :ref:`video output overlay <osd>` devices) read the alpha
-component from memory. When the device processes the alpha channel the
-alpha component must be filled with meaningful values by applications.
-Otherwise a corresponding format without an alpha component (XRGB or
-XBGR) must be used instead of an alpha format.
-
-The XRGB and XBGR formats contain undefined bits (-). Applications,
-devices and drivers must ignore those bits, for both
-:ref:`capture` and :ref:`output` devices.
-
-**Byte Order.**
-Each cell is one byte.
-
+These formats store an RGB triplet in three or four bytes. They are named based
+on the order of the RGB components as stored in memory, and on the total number
+of bits per pixel. For instance, RGB24 format stores a pixel with [R\ :sub:`7`
+R\ :sub:`6` R\ :sub:`5` R\ :sub:`4` R\ :sub:`3` R\ :sub:`2` R\ :sub:`1`
+R\ :sub:`0`] in the first byte, [G\ :sub:`7` G\ :sub:`6` G\ :sub:`5` G\ :sub:`4`
+G\ :sub:`3` G\ :sub:`2` G\ :sub:`1` G\ :sub:`0`] in the second byte and
+[B\ :sub:`7` B\ :sub:`6` B\ :sub:`5` B\ :sub:`4` B\ :sub:`3` B\ :sub:`2`
+B\ :sub:`1` B\ :sub:`0`] in the third byte. This differs from the DRM format
+nomenclature that instead use the order of components as seen in a 24- or
+32-bit little endian word.
.. raw:: latex
- \small
+ \begingroup
+ \tiny
+ \setlength{\tabcolsep}{2pt}
-.. tabularcolumns:: |p{3.1cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
+.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|
-.. flat-table:: RGB byte order
- :header-rows: 0
+
+.. flat-table:: RGB Formats With 8 Bits Per Component
+ :header-rows: 1
:stub-columns: 0
- :widths: 11 3 3 3 3 3 3 3 3 3 3 3 3
- * - start + 0:
- - B\ :sub:`00`
- - G\ :sub:`00`
- - R\ :sub:`00`
- - B\ :sub:`01`
- - G\ :sub:`01`
- - R\ :sub:`01`
- - B\ :sub:`02`
- - G\ :sub:`02`
- - R\ :sub:`02`
- - B\ :sub:`03`
- - G\ :sub:`03`
- - R\ :sub:`03`
- * - start + 12:
- - B\ :sub:`10`
- - G\ :sub:`10`
- - R\ :sub:`10`
- - B\ :sub:`11`
- - G\ :sub:`11`
- - R\ :sub:`11`
- - B\ :sub:`12`
- - G\ :sub:`12`
- - R\ :sub:`12`
- - B\ :sub:`13`
- - G\ :sub:`13`
- - R\ :sub:`13`
- * - start + 24:
- - B\ :sub:`20`
- - G\ :sub:`20`
- - R\ :sub:`20`
- - B\ :sub:`21`
- - G\ :sub:`21`
- - R\ :sub:`21`
- - B\ :sub:`22`
- - G\ :sub:`22`
- - R\ :sub:`22`
- - B\ :sub:`23`
- - G\ :sub:`23`
- - R\ :sub:`23`
- * - start + 36:
- - B\ :sub:`30`
- - G\ :sub:`30`
- - R\ :sub:`30`
- - B\ :sub:`31`
- - G\ :sub:`31`
- - R\ :sub:`31`
- - B\ :sub:`32`
- - G\ :sub:`32`
- - R\ :sub:`32`
- - B\ :sub:`33`
- - G\ :sub:`33`
- - R\ :sub:`33`
+ * - Identifier
+ - Code
+ - Byte 0 in memory
+ - Byte 1
+ - Byte 2
+ - Byte 3
+ * .. _V4L2-PIX-FMT-BGR24:
+
+ - ``V4L2_PIX_FMT_BGR24``
+ - 'BGR3'
+
+ - G\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ -
+ * .. _V4L2-PIX-FMT-RGB24:
+
+ - ``V4L2_PIX_FMT_RGB24``
+ - 'RGB3'
+
+ - R\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ -
+ * .. _V4L2-PIX-FMT-ABGR32:
+
+ - ``V4L2_PIX_FMT_ABGR32``
+ - 'AR24'
+
+ - B\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ - A\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-XBGR32:
+
+ - ``V4L2_PIX_FMT_XBGR32``
+ - 'XR24'
+
+ - B\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ - X\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-BGRA32:
+
+ - ``V4L2_PIX_FMT_BGRA32``
+ - 'RA24'
+
+ - A\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-BGRX32:
+
+ - ``V4L2_PIX_FMT_BGRX32``
+ - 'RX24'
+
+ - X\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-RGBA32:
+
+ - ``V4L2_PIX_FMT_RGBA32``
+ - 'AB24'
+
+ - R\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ - A\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-RGBX32:
+
+ - ``V4L2_PIX_FMT_RGBX32``
+ - 'XB24'
+
+ - R\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ - X\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-ARGB32:
+
+ - ``V4L2_PIX_FMT_ARGB32``
+ - 'BA24'
+
+ - A\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - B\ :sub:`7-0`
+ * .. _V4L2-PIX-FMT-XRGB32:
+
+ - ``V4L2_PIX_FMT_XRGB32``
+ - 'BX24'
+
+ - X\ :sub:`7-0`
+ - R\ :sub:`7-0`
+ - G\ :sub:`7-0`
+ - B\ :sub:`7-0`
.. raw:: latex
- \normalsize
+ \endgroup
-Formats defined in :ref:`pixfmt-rgb-deprecated` are deprecated and
-must not be used by new drivers. They are documented here for reference.
-The meaning of their alpha bits ``(a)`` are ill-defined and interpreted as in
-either the corresponding ARGB or XRGB format, depending on the driver.
+Deprecated RGB Formats
+======================
+
+Formats defined in :ref:`pixfmt-rgb-deprecated` are deprecated and must not be
+used by new drivers. They are documented here for reference. The meaning of
+their alpha bits ``(a)`` is ill-defined and they are interpreted as in either
+the corresponding ARGB or XRGB format, depending on the driver.
.. raw:: latex
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-uyvy.rst b/Documentation/userspace-api/media/v4l/pixfmt-uyvy.rst
deleted file mode 100644
index bae975f..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-uyvy.rst
+++ /dev/null
@@ -1,110 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-UYVY:
-
-**************************
-V4L2_PIX_FMT_UYVY ('UYVY')
-**************************
-
-
-Variation of ``V4L2_PIX_FMT_YUYV`` with different order of samples in
-memory
-
-
-Description
-===========
-
-In this format each four bytes is two pixels. Each four bytes is two
-Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
-belong to both pixels. As you can see, the Cr and Cb components have
-half the horizontal resolution of the Y component.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Cb\ :sub:`00`
- - Y'\ :sub:`00`
- - Cr\ :sub:`00`
- - Y'\ :sub:`01`
- - Cb\ :sub:`01`
- - Y'\ :sub:`02`
- - Cr\ :sub:`01`
- - Y'\ :sub:`03`
- * - start + 8:
- - Cb\ :sub:`10`
- - Y'\ :sub:`10`
- - Cr\ :sub:`10`
- - Y'\ :sub:`11`
- - Cb\ :sub:`11`
- - Y'\ :sub:`12`
- - Cr\ :sub:`11`
- - Y'\ :sub:`13`
- * - start + 16:
- - Cb\ :sub:`20`
- - Y'\ :sub:`20`
- - Cr\ :sub:`20`
- - Y'\ :sub:`21`
- - Cb\ :sub:`21`
- - Y'\ :sub:`22`
- - Cr\ :sub:`21`
- - Y'\ :sub:`23`
- * - start + 24:
- - Cb\ :sub:`30`
- - Y'\ :sub:`30`
- - Cr\ :sub:`30`
- - Y'\ :sub:`31`
- - Cb\ :sub:`31`
- - Y'\ :sub:`32`
- - Cr\ :sub:`31`
- - Y'\ :sub:`33`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 1
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 2
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 3
- - Y
- - C
- - Y
- - Y
- - C
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-vyuy.rst b/Documentation/userspace-api/media/v4l/pixfmt-vyuy.rst
deleted file mode 100644
index aff8588..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-vyuy.rst
+++ /dev/null
@@ -1,108 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-VYUY:
-
-**************************
-V4L2_PIX_FMT_VYUY ('VYUY')
-**************************
-
-
-Variation of ``V4L2_PIX_FMT_YUYV`` with different order of samples in
-memory
-
-
-Description
-===========
-
-In this format each four bytes is two pixels. Each four bytes is two
-Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
-belong to both pixels. As you can see, the Cr and Cb components have
-half the horizontal resolution of the Y component.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Cr\ :sub:`00`
- - Y'\ :sub:`00`
- - Cb\ :sub:`00`
- - Y'\ :sub:`01`
- - Cr\ :sub:`01`
- - Y'\ :sub:`02`
- - Cb\ :sub:`01`
- - Y'\ :sub:`03`
- * - start + 8:
- - Cr\ :sub:`10`
- - Y'\ :sub:`10`
- - Cb\ :sub:`10`
- - Y'\ :sub:`11`
- - Cr\ :sub:`11`
- - Y'\ :sub:`12`
- - Cb\ :sub:`11`
- - Y'\ :sub:`13`
- * - start + 16:
- - Cr\ :sub:`20`
- - Y'\ :sub:`20`
- - Cb\ :sub:`20`
- - Y'\ :sub:`21`
- - Cr\ :sub:`21`
- - Y'\ :sub:`22`
- - Cb\ :sub:`21`
- - Y'\ :sub:`23`
- * - start + 24:
- - Cr\ :sub:`30`
- - Y'\ :sub:`30`
- - Cb\ :sub:`30`
- - Y'\ :sub:`31`
- - Cr\ :sub:`31`
- - Y'\ :sub:`32`
- - Cb\ :sub:`31`
- - Y'\ :sub:`33`
-
-
-**Color Sample Location:**
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- -
- - 2
- - 3
- * - 0
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 1
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 2
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 3
- - Y
- - C
- - Y
- - Y
- - C
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y10.rst b/Documentation/userspace-api/media/v4l/pixfmt-y10.rst
deleted file mode 100644
index 05f018d..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y10.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y10:
-
-*************************
-V4L2_PIX_FMT_Y10 ('Y10 ')
-*************************
-
-
-Grey-scale image
-
-
-Description
-===========
-
-This is a grey-scale image with a depth of 10 bits per pixel. Pixels are
-stored in 16-bit words with unused high bits padded with 0. The least
-significant byte is stored at lower memory addresses (little-endian).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00low`
- - Y'\ :sub:`00high`
- - Y'\ :sub:`01low`
- - Y'\ :sub:`01high`
- - Y'\ :sub:`02low`
- - Y'\ :sub:`02high`
- - Y'\ :sub:`03low`
- - Y'\ :sub:`03high`
- * - start + 8:
- - Y'\ :sub:`10low`
- - Y'\ :sub:`10high`
- - Y'\ :sub:`11low`
- - Y'\ :sub:`11high`
- - Y'\ :sub:`12low`
- - Y'\ :sub:`12high`
- - Y'\ :sub:`13low`
- - Y'\ :sub:`13high`
- * - start + 16:
- - Y'\ :sub:`20low`
- - Y'\ :sub:`20high`
- - Y'\ :sub:`21low`
- - Y'\ :sub:`21high`
- - Y'\ :sub:`22low`
- - Y'\ :sub:`22high`
- - Y'\ :sub:`23low`
- - Y'\ :sub:`23high`
- * - start + 24:
- - Y'\ :sub:`30low`
- - Y'\ :sub:`30high`
- - Y'\ :sub:`31low`
- - Y'\ :sub:`31high`
- - Y'\ :sub:`32low`
- - Y'\ :sub:`32high`
- - Y'\ :sub:`33low`
- - Y'\ :sub:`33high`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y10b.rst b/Documentation/userspace-api/media/v4l/pixfmt-y10b.rst
deleted file mode 100644
index 38d353b..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y10b.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y10BPACK:
-
-******************************
-V4L2_PIX_FMT_Y10BPACK ('Y10B')
-******************************
-
-Grey-scale image as a bit-packed array
-
-
-Description
-===========
-
-This is a packed grey-scale image format with a depth of 10 bits per
-pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel,
-with no padding between them and with the most significant bits coming
-first from the left.
-
-**Bit-packed representation.**
-
-pixels cross the byte boundary and have a ratio of 5 bytes for each 4
-pixels.
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - Y'\ :sub:`00[9:2]`
- - Y'\ :sub:`00[1:0]`\ Y'\ :sub:`01[9:4]`
- - Y'\ :sub:`01[3:0]`\ Y'\ :sub:`02[9:6]`
- - Y'\ :sub:`02[5:0]`\ Y'\ :sub:`03[9:8]`
- - Y'\ :sub:`03[7:0]`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y10p.rst b/Documentation/userspace-api/media/v4l/pixfmt-y10p.rst
deleted file mode 100644
index dd20d343..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y10p.rst
+++ /dev/null
@@ -1,43 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y10P:
-
-******************************
-V4L2_PIX_FMT_Y10P ('Y10P')
-******************************
-
-Grey-scale image as a MIPI RAW10 packed array
-
-
-Description
-===========
-
-This is a packed grey-scale image format with a depth of 10 bits per
-pixel. Every four consecutive pixels are packed into 5 bytes. Each of
-the first 4 bytes contain the 8 high order bits of the pixels, and
-the 5th byte contains the 2 least significants bits of each pixel,
-in the same order.
-
-**Bit-packed representation.**
-
-.. raw:: latex
-
- \small
-
-.. tabularcolumns:: |p{1.2cm}||p{1.2cm}||p{1.2cm}||p{1.2cm}|p{3.2cm}|p{3.2cm}|
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
- :widths: 8 8 8 8 64
-
- * - Y'\ :sub:`00[9:2]`
- - Y'\ :sub:`01[9:2]`
- - Y'\ :sub:`02[9:2]`
- - Y'\ :sub:`03[9:2]`
- - Y'\ :sub:`03[1:0]`\ (bits 7--6) Y'\ :sub:`02[1:0]`\ (bits 5--4)
- Y'\ :sub:`01[1:0]`\ (bits 3--2) Y'\ :sub:`00[1:0]`\ (bits 1--0)
-
-.. raw:: latex
-
- \normalsize
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y12.rst b/Documentation/userspace-api/media/v4l/pixfmt-y12.rst
deleted file mode 100644
index 20e12a1..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y12.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y12:
-
-*************************
-V4L2_PIX_FMT_Y12 ('Y12 ')
-*************************
-
-
-Grey-scale image
-
-
-Description
-===========
-
-This is a grey-scale image with a depth of 12 bits per pixel. Pixels are
-stored in 16-bit words with unused high bits padded with 0. The least
-significant byte is stored at lower memory addresses (little-endian).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00low`
- - Y'\ :sub:`00high`
- - Y'\ :sub:`01low`
- - Y'\ :sub:`01high`
- - Y'\ :sub:`02low`
- - Y'\ :sub:`02high`
- - Y'\ :sub:`03low`
- - Y'\ :sub:`03high`
- * - start + 8:
- - Y'\ :sub:`10low`
- - Y'\ :sub:`10high`
- - Y'\ :sub:`11low`
- - Y'\ :sub:`11high`
- - Y'\ :sub:`12low`
- - Y'\ :sub:`12high`
- - Y'\ :sub:`13low`
- - Y'\ :sub:`13high`
- * - start + 16:
- - Y'\ :sub:`20low`
- - Y'\ :sub:`20high`
- - Y'\ :sub:`21low`
- - Y'\ :sub:`21high`
- - Y'\ :sub:`22low`
- - Y'\ :sub:`22high`
- - Y'\ :sub:`23low`
- - Y'\ :sub:`23high`
- * - start + 24:
- - Y'\ :sub:`30low`
- - Y'\ :sub:`30high`
- - Y'\ :sub:`31low`
- - Y'\ :sub:`31high`
- - Y'\ :sub:`32low`
- - Y'\ :sub:`32high`
- - Y'\ :sub:`33low`
- - Y'\ :sub:`33high`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y14.rst b/Documentation/userspace-api/media/v4l/pixfmt-y14.rst
deleted file mode 100644
index 2a4826b..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y14.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y14:
-
-*************************
-V4L2_PIX_FMT_Y14 ('Y14 ')
-*************************
-
-
-Grey-scale image
-
-
-Description
-===========
-
-This is a grey-scale image with a depth of 14 bits per pixel. Pixels are
-stored in 16-bit words with unused high bits padded with 0. The least
-significant byte is stored at lower memory addresses (little-endian).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00low`
- - Y'\ :sub:`00high`
- - Y'\ :sub:`01low`
- - Y'\ :sub:`01high`
- - Y'\ :sub:`02low`
- - Y'\ :sub:`02high`
- - Y'\ :sub:`03low`
- - Y'\ :sub:`03high`
- * - start + 8:
- - Y'\ :sub:`10low`
- - Y'\ :sub:`10high`
- - Y'\ :sub:`11low`
- - Y'\ :sub:`11high`
- - Y'\ :sub:`12low`
- - Y'\ :sub:`12high`
- - Y'\ :sub:`13low`
- - Y'\ :sub:`13high`
- * - start + 16:
- - Y'\ :sub:`20low`
- - Y'\ :sub:`20high`
- - Y'\ :sub:`21low`
- - Y'\ :sub:`21high`
- - Y'\ :sub:`22low`
- - Y'\ :sub:`22high`
- - Y'\ :sub:`23low`
- - Y'\ :sub:`23high`
- * - start + 24:
- - Y'\ :sub:`30low`
- - Y'\ :sub:`30high`
- - Y'\ :sub:`31low`
- - Y'\ :sub:`31high`
- - Y'\ :sub:`32low`
- - Y'\ :sub:`32high`
- - Y'\ :sub:`33low`
- - Y'\ :sub:`33high`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y16-be.rst b/Documentation/userspace-api/media/v4l/pixfmt-y16-be.rst
deleted file mode 100644
index 6d70cd7..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y16-be.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y16-BE:
-
-****************************************
-V4L2_PIX_FMT_Y16_BE ('Y16 ' | (1 << 31))
-****************************************
-
-
-Grey-scale image
-
-
-Description
-===========
-
-This is a grey-scale image with a depth of 16 bits per pixel. The most
-significant byte is stored at lower memory addresses (big-endian).
-
-.. note::
-
- The actual sampling precision may be lower than 16 bits, for
- example 10 bits per pixel with values in range 0 to 1023.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00high`
- - Y'\ :sub:`00low`
- - Y'\ :sub:`01high`
- - Y'\ :sub:`01low`
- - Y'\ :sub:`02high`
- - Y'\ :sub:`02low`
- - Y'\ :sub:`03high`
- - Y'\ :sub:`03low`
- * - start + 8:
- - Y'\ :sub:`10high`
- - Y'\ :sub:`10low`
- - Y'\ :sub:`11high`
- - Y'\ :sub:`11low`
- - Y'\ :sub:`12high`
- - Y'\ :sub:`12low`
- - Y'\ :sub:`13high`
- - Y'\ :sub:`13low`
- * - start + 16:
- - Y'\ :sub:`20high`
- - Y'\ :sub:`20low`
- - Y'\ :sub:`21high`
- - Y'\ :sub:`21low`
- - Y'\ :sub:`22high`
- - Y'\ :sub:`22low`
- - Y'\ :sub:`23high`
- - Y'\ :sub:`23low`
- * - start + 24:
- - Y'\ :sub:`30high`
- - Y'\ :sub:`30low`
- - Y'\ :sub:`31high`
- - Y'\ :sub:`31low`
- - Y'\ :sub:`32high`
- - Y'\ :sub:`32low`
- - Y'\ :sub:`33high`
- - Y'\ :sub:`33low`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y16.rst b/Documentation/userspace-api/media/v4l/pixfmt-y16.rst
deleted file mode 100644
index 398ad8b..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y16.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y16:
-
-*************************
-V4L2_PIX_FMT_Y16 ('Y16 ')
-*************************
-
-
-Grey-scale image
-
-
-Description
-===========
-
-This is a grey-scale image with a depth of 16 bits per pixel. The least
-significant byte is stored at lower memory addresses (little-endian).
-
-.. note::
-
- The actual sampling precision may be lower than 16 bits, for
- example 10 bits per pixel with values in range 0 to 1023.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00low`
- - Y'\ :sub:`00high`
- - Y'\ :sub:`01low`
- - Y'\ :sub:`01high`
- - Y'\ :sub:`02low`
- - Y'\ :sub:`02high`
- - Y'\ :sub:`03low`
- - Y'\ :sub:`03high`
- * - start + 8:
- - Y'\ :sub:`10low`
- - Y'\ :sub:`10high`
- - Y'\ :sub:`11low`
- - Y'\ :sub:`11high`
- - Y'\ :sub:`12low`
- - Y'\ :sub:`12high`
- - Y'\ :sub:`13low`
- - Y'\ :sub:`13high`
- * - start + 16:
- - Y'\ :sub:`20low`
- - Y'\ :sub:`20high`
- - Y'\ :sub:`21low`
- - Y'\ :sub:`21high`
- - Y'\ :sub:`22low`
- - Y'\ :sub:`22high`
- - Y'\ :sub:`23low`
- - Y'\ :sub:`23high`
- * - start + 24:
- - Y'\ :sub:`30low`
- - Y'\ :sub:`30high`
- - Y'\ :sub:`31low`
- - Y'\ :sub:`31high`
- - Y'\ :sub:`32low`
- - Y'\ :sub:`32high`
- - Y'\ :sub:`33low`
- - Y'\ :sub:`33high`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-y41p.rst b/Documentation/userspace-api/media/v4l/pixfmt-y41p.rst
deleted file mode 100644
index d14cedf..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-y41p.rst
+++ /dev/null
@@ -1,151 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-Y41P:
-
-**************************
-V4L2_PIX_FMT_Y41P ('Y41P')
-**************************
-
-
-Format with ¼ horizontal chroma resolution, also known as YUV 4:1:1
-
-
-Description
-===========
-
-In this format each 12 bytes is eight pixels. In the twelve bytes are
-two CbCr pairs and eight Y's. The first CbCr pair goes with the first
-four Y's, and the second CbCr pair goes with the other four Y's. The Cb
-and Cr components have one fourth the horizontal resolution of the Y
-component.
-
-Do not confuse this format with
-:ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>`. Y41P is derived
-from "YUV 4:1:1 *packed*", while YUV411P stands for "YUV 4:1:1
-*planar*".
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Cb\ :sub:`00`
- - Y'\ :sub:`00`
- - Cr\ :sub:`00`
- - Y'\ :sub:`01`
- - Cb\ :sub:`01`
- - Y'\ :sub:`02`
- - Cr\ :sub:`01`
- - Y'\ :sub:`03`
- - Y'\ :sub:`04`
- - Y'\ :sub:`05`
- - Y'\ :sub:`06`
- - Y'\ :sub:`07`
- * - start + 12:
- - Cb\ :sub:`10`
- - Y'\ :sub:`10`
- - Cr\ :sub:`10`
- - Y'\ :sub:`11`
- - Cb\ :sub:`11`
- - Y'\ :sub:`12`
- - Cr\ :sub:`11`
- - Y'\ :sub:`13`
- - Y'\ :sub:`14`
- - Y'\ :sub:`15`
- - Y'\ :sub:`16`
- - Y'\ :sub:`17`
- * - start + 24:
- - Cb\ :sub:`20`
- - Y'\ :sub:`20`
- - Cr\ :sub:`20`
- - Y'\ :sub:`21`
- - Cb\ :sub:`21`
- - Y'\ :sub:`22`
- - Cr\ :sub:`21`
- - Y'\ :sub:`23`
- - Y'\ :sub:`24`
- - Y'\ :sub:`25`
- - Y'\ :sub:`26`
- - Y'\ :sub:`27`
- * - start + 36:
- - Cb\ :sub:`30`
- - Y'\ :sub:`30`
- - Cr\ :sub:`30`
- - Y'\ :sub:`31`
- - Cb\ :sub:`31`
- - Y'\ :sub:`32`
- - Cr\ :sub:`31`
- - Y'\ :sub:`33`
- - Y'\ :sub:`34`
- - Y'\ :sub:`35`
- - Y'\ :sub:`36`
- - Y'\ :sub:`37`
-
-
-**Color Sample Location:**
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- - 1
- -
- - 2
- - 3
- - 4
- - 5
- -
- - 6
- - 7
- * - 0
- - Y
- - Y
- - C
- - Y
- - Y
- - Y
- - Y
- - C
- - Y
- - Y
- * - 1
- - Y
- - Y
- - C
- - Y
- - Y
- - Y
- - Y
- - C
- - Y
- - Y
- * - 2
- - Y
- - Y
- - C
- - Y
- - Y
- - Y
- - Y
- - C
- - Y
- - Y
- * - 3
- - Y
- - Y
- - C
- - Y
- - Y
- - Y
- - Y
- - C
- - Y
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst
new file mode 100644
index 0000000..0c8c5e0
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _yuv-luma-only:
+
+*****************
+Luma-Only Formats
+*****************
+
+This family of formats only store the luma component of a Y'CbCr image. They
+are often referred to as greyscale formats.
+
+.. note::
+
+ - In all the tables that follow, bit 7 is the most significant bit in a byte.
+ - Formats are described with the minimum number of pixels needed to create a
+ byte-aligned repeating pattern. `...` indicates repetition of the pattern.
+ - Y'\ :sub:`x`\ [9:2] denotes bits 9 to 2 of the Y' value for pixel at colum
+ `x`.
+ - `0` denotes padding bits set to 0.
+
+
+.. flat-table:: Luma-Only Image Formats
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Byte 0
+ - Byte 1
+ - Byte 2
+ - Byte 3
+ - Byte 4
+
+ * .. _V4L2-PIX-FMT-GREY:
+
+ - ``V4L2_PIX_FMT_GREY``
+ - 'GREY'
+
+ - Y'\ :sub:`0`\ [7:0]
+ - ...
+ - ...
+ - ...
+ - ...
+
+ * .. _V4L2-PIX-FMT-Y10:
+
+ - ``V4L2_PIX_FMT_Y10``
+ - 'Y10 '
+
+ - Y'\ :sub:`0`\ [7:0]
+ - `000000` Y'\ :sub:`0`\ [9:8]
+ - ...
+ - ...
+ - ...
+
+ * .. _V4L2-PIX-FMT-Y10BPACK:
+
+ - ``V4L2_PIX_FMT_Y10BPACK``
+ - 'Y10B'
+
+ - Y'\ :sub:`0`\ [9:2]
+ - Y'\ :sub:`0`\ [1:0] Y'\ :sub:`1`\ [9:4]
+ - Y'\ :sub:`1`\ [3:0] Y'\ :sub:`2`\ [9:6]
+ - Y'\ :sub:`2`\ [5:0] Y'\ :sub:`3`\ [9:8]
+ - Y'\ :sub:`3`\ [7:0]
+
+ * .. _V4L2-PIX-FMT-Y10P:
+
+ - ``V4L2_PIX_FMT_Y10P``
+ - 'Y10P'
+
+ - Y'\ :sub:`0`\ [7:0]
+ - Y'\ :sub:`1`\ [9:8]
+ - Y'\ :sub:`2`\ [9:2]
+ - Y'\ :sub:`3`\ [9:2]
+ - Y'\ :sub:`3`\ [1:0] Y'\ :sub:`2`\ [1:0] Y'\ :sub:`1`\ [1:0] Y'\ :sub:`0`\ [1:0]
+
+ * .. _V4L2-PIX-FMT-Y12:
+
+ - ``V4L2_PIX_FMT_Y12``
+ - 'Y12 '
+
+ - Y'\ :sub:`0`\ [7:0]
+ - `0000` Y'\ :sub:`0`\ [11:8]
+ - ...
+ - ...
+ - ...
+
+ * .. _V4L2-PIX-FMT-Y14:
+
+ - ``V4L2_PIX_FMT_Y14``
+ - 'Y14 '
+
+ - Y'\ :sub:`0`\ [7:0]
+ - `00` Y'\ :sub:`0`\ [13:8]
+ - ...
+ - ...
+ - ...
+
+ * .. _V4L2-PIX-FMT-Y16:
+
+ - ``V4L2_PIX_FMT_Y16``
+ - 'Y16 '
+
+ - Y'\ :sub:`0`\ [7:0]
+ - Y'\ :sub:`0`\ [15:8]
+ - ...
+ - ...
+ - ...
+
+ * .. _V4L2-PIX-FMT-Y16-BE:
+
+ - ``V4L2_PIX_FMT_Y16_BE``
+ - 'Y16 ' | (1U << 31)
+
+ - Y'\ :sub:`0`\ [15:8]
+ - Y'\ :sub:`0`\ [7:0]
+ - ...
+ - ...
+ - ...
+
+.. note::
+
+ For the Y16 and Y16_BE formats, the actual sampling precision may be lower
+ than 16 bits. For example, 10 bits per pixel uses values in the range 0 to
+ 1023.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
new file mode 100644
index 0000000..7d4d392
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
@@ -0,0 +1,950 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. planar-yuv:
+
+******************
+Planar YUV formats
+******************
+
+Planar formats split luma and chroma data in separate memory regions. They
+exist in two variants:
+
+- Semi-planar formats use two planes. The first plane is the luma plane and
+ stores the Y components. The second plane is the chroma plane and stores the
+ Cb and Cr components interleaved.
+
+- Fully planar formats use three planes to store the Y, Cb and Cr components
+ separately.
+
+Within a plane, components are stored in pixel order, which may be linear or
+tiled. Padding may be supported at the end of the lines, and the line stride of
+the chroma planes may be constrained by the line stride of the luma plane.
+
+Some planar formats allow planes to be placed in independent memory locations.
+They are identified by an 'M' suffix in their name (such as in
+``V4L2_PIX_FMT_NV12M``). Those formats are intended to be used only in drivers
+and applications that support the multi-planar API, described in
+:ref:`planar-apis`. Unless explicitly documented as supporting non-contiguous
+planes, formats require the planes to follow each other immediately in memory.
+
+
+Semi-Planar YUV Formats
+=======================
+
+These formats are commonly referred to as NV formats (NV12, NV16, ...). They
+use two planes, and store the luma components in the first plane and the chroma
+components in the second plane. The Cb and Cr components are interleaved in the
+chroma plane, with Cb and Cr always stored in pairs. The chroma order is
+exposed as different formats.
+
+For memory contiguous formats, the number of padding pixels at the end of the
+chroma lines is identical to the padding of the luma lines. Without horizontal
+subsampling, the chroma line stride (in bytes) is thus equal to twice the luma
+line stride. With horizontal subsampling by 2, the chroma line stride is equal
+to the luma line stride. Vertical subsampling doesn't affect the line stride.
+
+For non-contiguous formats, no constraints are enforced by the format on the
+relationship between the luma and chroma line padding and stride.
+
+All components are stored with the same number of bits per component.
+
+.. flat-table:: Overview of Semi-Planar YUV Formats
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Bits per component
+ - Subsampling
+ - Chroma order [1]_
+ - Contiguous [2]_
+ - Tiling [3]_
+ * - V4L2_PIX_FMT_NV12
+ - 'NV12'
+ - 8
+ - 4:2:0
+ - Cb, Cr
+ - Yes
+ - Linear
+ * - V4L2_PIX_FMT_NV21
+ - 'NV21'
+ - 8
+ - 4:2:0
+ - Cr, Cr
+ - Yes
+ - Linear
+ * - V4L2_PIX_FMT_NV12M
+ - 'NM12'
+ - 8
+ - 4:2:0
+ - Cb, Cr
+ - No
+ - Linear
+ * - V4L2_PIX_FMT_NV21M
+ - 'NM21'
+ - 8
+ - 4:2:0
+ - Cr, Cr
+ - No
+ - Linear
+ * - V4L2_PIX_FMT_NV12MT
+ - 'TM12'
+ - 8
+ - 4:2:0
+ - Cb, Cr
+ - No
+ - 64x32 macroblocks
+
+ Horizontal Z order
+ * - V4L2_PIX_FMT_NV12MT_16X16
+ - 'VM12'
+ - 8
+ - 4:2:2
+ - Cb, Cr
+ - No
+ - 16x16 macroblocks
+ * - V4L2_PIX_FMT_NV16
+ - 'NV16'
+ - 8
+ - 4:2:2
+ - Cb, Cr
+ - Yes
+ - Linear
+ * - V4L2_PIX_FMT_NV61
+ - 'NV61'
+ - 8
+ - 4:2:2
+ - Cr, Cr
+ - Yes
+ - Linear
+ * - V4L2_PIX_FMT_NV16M
+ - 'NM16'
+ - 8
+ - 4:2:2
+ - Cb, Cr
+ - No
+ - Linear
+ * - V4L2_PIX_FMT_NV61M
+ - 'NM61'
+ - 8
+ - 4:2:2
+ - Cr, Cr
+ - No
+ - Linear
+ * - V4L2_PIX_FMT_NV24
+ - 'NV24'
+ - 8
+ - 4:4:4
+ - Cb, Cr
+ - Yes
+ - Linear
+ * - V4L2_PIX_FMT_NV42
+ - 'NV42'
+ - 8
+ - 4:4:4
+ - Cr, Cr
+ - Yes
+ - Linear
+
+.. note::
+
+ .. [1] Order of chroma samples in the second plane
+ .. [2] Indicates if planes have to be contiguous in memory or can be
+ disjoint
+ .. [3] Macroblock size in pixels
+
+
+**Color Sample Location:**
+Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
+horizontally.
+
+
+.. _V4L2-PIX-FMT-NV12:
+.. _V4L2-PIX-FMT-NV21:
+.. _V4L2-PIX-FMT-NV12M:
+.. _V4L2-PIX-FMT-NV21M:
+
+NV12, NV21, NV12M and NV21M
+---------------------------
+
+Semi-planar YUV 4:2:0 formats. The chroma plane is subsampled by 2 in each
+direction. Chroma lines contain half the number of pixels and the same number
+of bytes as luma lines, and the chroma plane contains half the number of lines
+of the luma plane.
+
+.. flat-table:: Sample 4x4 NV12 Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+ * - start + 20:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+
+.. flat-table:: Sample 4x4 NV12M Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start0 + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start0 + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start0 + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start0 + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * -
+ * - start1 + 0:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+ * - start1 + 4:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+
+
+.. _V4L2-PIX-FMT-NV12MT:
+.. _V4L2-PIX-FMT-NV12MT-16X16:
+
+NV12MT and MV12MT_16X16
+-----------------------
+
+Semi-planar YUV 4:2:0 formats, using macroblock tiling. The chroma plane is
+subsampled by 2 in each direction. Chroma lines contain half the number of
+pixels and the same number of bytes as luma lines, and the chroma plane
+contains half the number of lines of the luma plane.
+
+``V4L2_PIX_FMT_NV12MT_16X16`` stores pixel in 2D 16x16 macroblocks, and stores
+macroblocks linearly in memory. The line stride and image height must be
+aligned to a multiple of 16. The layouts of the luma and chroma planes are
+identical.
+
+``V4L2_PIX_FMT_NV12MT`` stores pixels in 2D 64x32 macroblocks, and stores 2x2
+groups of macroblocks in Z-order in memory, alternating Z and mirrored Z shapes
+horizontally. The line stride must be a multiple of 128 pixels to ensure an
+integer number of Z shapes. The image height must be a multiple of 32 pixels.
+If the vertical resolution is an odd number of macroblocks, the last row of
+macroblocks is stored in linear order. The layouts of the luma and chroma
+planes are identical.
+
+.. _nv12mt:
+
+.. kernel-figure:: nv12mt.svg
+ :alt: nv12mt.svg
+ :align: center
+
+ V4L2_PIX_FMT_NV12MT macroblock Z shape memory layout
+
+.. _nv12mt_ex:
+
+.. kernel-figure:: nv12mt_example.svg
+ :alt: nv12mt_example.svg
+ :align: center
+
+ Example V4L2_PIX_FMT_NV12MT memory layout of macroblocks
+
+
+.. _V4L2-PIX-FMT-NV16:
+.. _V4L2-PIX-FMT-NV61:
+.. _V4L2-PIX-FMT-NV16M:
+.. _V4L2-PIX-FMT-NV61M:
+
+NV16, NV61, NV16M and NV61M
+---------------------------
+
+Semi-planar YUV 4:2:2 formats. The chroma plane is subsampled by 2 in the
+horizontal direction. Chroma lines contain half the number of pixels and the
+same number of bytes as luma lines, and the chroma plane contains the same
+number of lines as the luma plane.
+
+.. flat-table:: Sample 4x4 NV16 Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+ * - start + 20:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+ * - start + 24:
+ - Cb\ :sub:`20`
+ - Cr\ :sub:`20`
+ - Cb\ :sub:`21`
+ - Cr\ :sub:`21`
+ * - start + 28:
+ - Cb\ :sub:`30`
+ - Cr\ :sub:`30`
+ - Cb\ :sub:`31`
+ - Cr\ :sub:`31`
+
+.. flat-table:: Sample 4x4 NV16M Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start0 + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start0 + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start0 + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start0 + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * -
+ * - start1 + 0:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`02`
+ - Cr\ :sub:`02`
+ * - start1 + 4:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`12`
+ - Cr\ :sub:`12`
+ * - start1 + 8:
+ - Cb\ :sub:`20`
+ - Cr\ :sub:`20`
+ - Cb\ :sub:`22`
+ - Cr\ :sub:`22`
+ * - start1 + 12:
+ - Cb\ :sub:`30`
+ - Cr\ :sub:`30`
+ - Cb\ :sub:`32`
+ - Cr\ :sub:`32`
+
+
+.. _V4L2-PIX-FMT-NV24:
+.. _V4L2-PIX-FMT-NV42:
+
+NV24 and NV42
+-------------
+
+Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
+horizontal direction. Chroma lines contain half the number of pixels and the
+same number of bytes as luma lines, and the chroma plane contains the same
+number of lines as the luma plane.
+
+.. flat-table:: Sample 4x4 NV24 Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cb\ :sub:`00`
+ - Cr\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cr\ :sub:`01`
+ - Cb\ :sub:`02`
+ - Cr\ :sub:`02`
+ - Cb\ :sub:`03`
+ - Cr\ :sub:`03`
+ * - start + 24:
+ - Cb\ :sub:`10`
+ - Cr\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cr\ :sub:`11`
+ - Cb\ :sub:`12`
+ - Cr\ :sub:`12`
+ - Cb\ :sub:`13`
+ - Cr\ :sub:`13`
+ * - start + 32:
+ - Cb\ :sub:`20`
+ - Cr\ :sub:`20`
+ - Cb\ :sub:`21`
+ - Cr\ :sub:`21`
+ - Cb\ :sub:`22`
+ - Cr\ :sub:`22`
+ - Cb\ :sub:`23`
+ - Cr\ :sub:`23`
+ * - start + 40:
+ - Cb\ :sub:`30`
+ - Cr\ :sub:`30`
+ - Cb\ :sub:`31`
+ - Cr\ :sub:`31`
+ - Cb\ :sub:`32`
+ - Cr\ :sub:`32`
+ - Cb\ :sub:`33`
+ - Cr\ :sub:`33`
+
+
+Fully Planar YUV Formats
+========================
+
+These formats store the Y, Cb and Cr components in three separate planes. The
+luma plane comes first, and the order of the two chroma planes varies between
+formats. The two chroma planes always use the same subsampling.
+
+For memory contiguous formats, the number of padding pixels at the end of the
+chroma lines is identical to the padding of the luma lines. The chroma line
+stride (in bytes) is thus equal to the luma line stride divided by the
+horizontal subsampling factor. Vertical subsampling doesn't affect the line
+stride.
+
+For non-contiguous formats, no constraints are enforced by the format on the
+relationship between the luma and chroma line padding and stride.
+
+All components are stored with the same number of bits per component.
+
+.. flat-table:: Overview of Fully Planar YUV Formats
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Bits per component
+ - Subsampling
+ - Planes order [4]_
+ - Contiguous [5]_
+
+ * - V4L2_PIX_FMT_YUV410
+ - 'YUV9'
+ - 8
+ - 4:1:0
+ - Y, Cb, Cr
+ - Yes
+ * - V4L2_PIX_FMT_YVU410
+ - 'YVU9'
+ - 8
+ - 4:1:0
+ - Y, Cr, Cb
+ - Yes
+ * - V4L2_PIX_FMT_YUV411P
+ - '411P'
+ - 8
+ - 4:1:1
+ - Y, Cb, Cr
+ - Yes
+ * - V4L2_PIX_FMT_YUV420M
+ - 'YM12'
+ - 8
+ - 4:2:0
+ - Y, Cb, Cr
+ - No
+ * - V4L2_PIX_FMT_YVU420M
+ - 'YM21'
+ - 8
+ - 4:2:0
+ - Y, Cr, Cb
+ - No
+ * - V4L2_PIX_FMT_YUV420
+ - 'YU12'
+ - 8
+ - 4:2:0
+ - Y, Cb, Cr
+ - Yes
+ * - V4L2_PIX_FMT_YVU420
+ - 'YV12'
+ - 8
+ - 4:2:0
+ - Y, Cr, Cb
+ - Yes
+ * - V4L2_PIX_FMT_YUV422P
+ - '422P'
+ - 8
+ - 4:2:2
+ - Y, Cb, Cr
+ - Yes
+ * - V4L2_PIX_FMT_YUV422M
+ - 'YM16'
+ - 8
+ - 4:2:2
+ - Y, Cb, Cr
+ - No
+ * - V4L2_PIX_FMT_YVU422M
+ - 'YM61'
+ - 8
+ - 4:2:2
+ - Y, Cr, Cb
+ - No
+ * - V4L2_PIX_FMT_YUV444M
+ - 'YM24'
+ - 8
+ - 4:4:4
+ - Y, Cb, Cr
+ - No
+ * - V4L2_PIX_FMT_YVU444M
+ - 'YM42'
+ - 8
+ - 4:4:4
+ - Y, Cr, Cb
+ - No
+
+.. note::
+
+ .. [4] Order of luma and chroma planes
+ .. [5] Indicates if planes have to be contiguous in memory or can be
+ disjoint
+
+
+**Color Sample Location:**
+Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
+horizontally.
+
+.. _V4L2-PIX-FMT-YUV410:
+.. _V4L2-PIX-FMT-YVU410:
+
+YUV410 and YVU410
+-----------------
+
+Planar YUV 4:1:0 formats. The chroma planes are subsampled by 4 in each
+direction. Chroma lines contain a quarter of the number of pixels and bytes of
+the luma lines, and the chroma planes contain a quarter of the number of lines
+of the luma plane.
+
+.. flat-table:: Sample 4x4 YUV410 Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cr\ :sub:`00`
+ * - start + 17:
+ - Cb\ :sub:`00`
+
+
+.. _V4L2-PIX-FMT-YUV411P:
+
+YUV411P
+-------
+
+Planar YUV 4:1:1 formats. The chroma planes are subsampled by 4 in the
+horizontal direction. Chroma lines contain a quarter of the number of pixels
+and bytes of the luma lines, and the chroma planes contain the same number of
+lines as the luma plane.
+
+.. flat-table:: Sample 4x4 YUV411P Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cb\ :sub:`00`
+ * - start + 17:
+ - Cb\ :sub:`10`
+ * - start + 18:
+ - Cb\ :sub:`20`
+ * - start + 19:
+ - Cb\ :sub:`30`
+ * - start + 20:
+ - Cr\ :sub:`00`
+ * - start + 21:
+ - Cr\ :sub:`10`
+ * - start + 22:
+ - Cr\ :sub:`20`
+ * - start + 23:
+ - Cr\ :sub:`30`
+
+
+.. _V4L2-PIX-FMT-YUV420:
+.. _V4L2-PIX-FMT-YVU420:
+.. _V4L2-PIX-FMT-YUV420M:
+.. _V4L2-PIX-FMT-YVU420M:
+
+YUV420, YVU420, YUV420M and YVU420M
+-----------------------------------
+
+Planar YUV 4:2:0 formats. The chroma planes are subsampled by 2 in each
+direction. Chroma lines contain half of the number of pixels and bytes of the
+luma lines, and the chroma planes contain half of the number of lines of the
+luma plane.
+
+.. flat-table:: Sample 4x4 YUV420 Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cr\ :sub:`00`
+ - Cr\ :sub:`01`
+ * - start + 18:
+ - Cr\ :sub:`10`
+ - Cr\ :sub:`11`
+ * - start + 20:
+ - Cb\ :sub:`00`
+ - Cb\ :sub:`01`
+ * - start + 22:
+ - Cb\ :sub:`10`
+ - Cb\ :sub:`11`
+
+.. flat-table:: Sample 4x4 YUV420M Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start0 + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start0 + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start0 + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start0 + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * -
+ * - start1 + 0:
+ - Cb\ :sub:`00`
+ - Cb\ :sub:`01`
+ * - start1 + 2:
+ - Cb\ :sub:`10`
+ - Cb\ :sub:`11`
+ * -
+ * - start2 + 0:
+ - Cr\ :sub:`00`
+ - Cr\ :sub:`01`
+ * - start2 + 2:
+ - Cr\ :sub:`10`
+ - Cr\ :sub:`11`
+
+
+.. _V4L2-PIX-FMT-YUV422P:
+.. _V4L2-PIX-FMT-YUV422M:
+.. _V4L2-PIX-FMT-YVU422M:
+
+YUV422P, YUV422M and YVU422M
+----------------------------
+
+Planar YUV 4:2:2 formats. The chroma planes are subsampled by 2 in the
+horizontal direction. Chroma lines contain half of the number of pixels and
+bytes of the luma lines, and the chroma planes contain the same number of lines
+as the luma plane.
+
+.. flat-table:: Sample 4x4 YUV422P Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * - start + 16:
+ - Cb\ :sub:`00`
+ - Cb\ :sub:`01`
+ * - start + 18:
+ - Cb\ :sub:`10`
+ - Cb\ :sub:`11`
+ * - start + 20:
+ - Cb\ :sub:`20`
+ - Cb\ :sub:`21`
+ * - start + 22:
+ - Cb\ :sub:`30`
+ - Cb\ :sub:`31`
+ * - start + 24:
+ - Cr\ :sub:`00`
+ - Cr\ :sub:`01`
+ * - start + 26:
+ - Cr\ :sub:`10`
+ - Cr\ :sub:`11`
+ * - start + 28:
+ - Cr\ :sub:`20`
+ - Cr\ :sub:`21`
+ * - start + 30:
+ - Cr\ :sub:`30`
+ - Cr\ :sub:`31`
+
+.. flat-table:: Sample 4x4 YUV422M Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start0 + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start0 + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start0 + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start0 + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * -
+ * - start1 + 0:
+ - Cb\ :sub:`00`
+ - Cb\ :sub:`01`
+ * - start1 + 2:
+ - Cb\ :sub:`10`
+ - Cb\ :sub:`11`
+ * - start1 + 4:
+ - Cb\ :sub:`20`
+ - Cb\ :sub:`21`
+ * - start1 + 6:
+ - Cb\ :sub:`30`
+ - Cb\ :sub:`31`
+ * -
+ * - start2 + 0:
+ - Cr\ :sub:`00`
+ - Cr\ :sub:`01`
+ * - start2 + 2:
+ - Cr\ :sub:`10`
+ - Cr\ :sub:`11`
+ * - start2 + 4:
+ - Cr\ :sub:`20`
+ - Cr\ :sub:`21`
+ * - start2 + 6:
+ - Cr\ :sub:`30`
+ - Cr\ :sub:`31`
+
+
+.. _V4L2-PIX-FMT-YUV444M:
+.. _V4L2-PIX-FMT-YVU444M:
+
+YUV444M and YVU444M
+-------------------
+
+Planar YUV 4:4:4 formats. The chroma planes are no subsampled. Chroma lines
+contain the same number of pixels and bytes of the luma lines, and the chroma
+planes contain the same number of lines as the luma plane.
+
+.. flat-table:: Sample 4x4 YUV444M Image
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - start0 + 0:
+ - Y'\ :sub:`00`
+ - Y'\ :sub:`01`
+ - Y'\ :sub:`02`
+ - Y'\ :sub:`03`
+ * - start0 + 4:
+ - Y'\ :sub:`10`
+ - Y'\ :sub:`11`
+ - Y'\ :sub:`12`
+ - Y'\ :sub:`13`
+ * - start0 + 8:
+ - Y'\ :sub:`20`
+ - Y'\ :sub:`21`
+ - Y'\ :sub:`22`
+ - Y'\ :sub:`23`
+ * - start0 + 12:
+ - Y'\ :sub:`30`
+ - Y'\ :sub:`31`
+ - Y'\ :sub:`32`
+ - Y'\ :sub:`33`
+ * -
+ * - start1 + 0:
+ - Cb\ :sub:`00`
+ - Cb\ :sub:`01`
+ - Cb\ :sub:`02`
+ - Cb\ :sub:`03`
+ * - start1 + 4:
+ - Cb\ :sub:`10`
+ - Cb\ :sub:`11`
+ - Cb\ :sub:`12`
+ - Cb\ :sub:`13`
+ * - start1 + 8:
+ - Cb\ :sub:`20`
+ - Cb\ :sub:`21`
+ - Cb\ :sub:`22`
+ - Cb\ :sub:`23`
+ * - start1 + 12:
+ - Cb\ :sub:`20`
+ - Cb\ :sub:`21`
+ - Cb\ :sub:`32`
+ - Cb\ :sub:`33`
+ * -
+ * - start2 + 0:
+ - Cr\ :sub:`00`
+ - Cr\ :sub:`01`
+ - Cr\ :sub:`02`
+ - Cr\ :sub:`03`
+ * - start2 + 4:
+ - Cr\ :sub:`10`
+ - Cr\ :sub:`11`
+ - Cr\ :sub:`12`
+ - Cr\ :sub:`13`
+ * - start2 + 8:
+ - Cr\ :sub:`20`
+ - Cr\ :sub:`21`
+ - Cr\ :sub:`22`
+ - Cr\ :sub:`23`
+ * - start2 + 12:
+ - Cr\ :sub:`30`
+ - Cr\ :sub:`31`
+ - Cr\ :sub:`32`
+ - Cr\ :sub:`33`
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv410.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv410.rst
deleted file mode 100644
index de2e519..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv410.rst
+++ /dev/null
@@ -1,127 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YVU410:
-.. _v4l2-pix-fmt-yuv410:
-
-**********************************************************
-V4L2_PIX_FMT_YVU410 ('YVU9'), V4L2_PIX_FMT_YUV410 ('YUV9')
-**********************************************************
-
-
-V4L2_PIX_FMT_YUV410
-Planar formats with ¼ horizontal and vertical chroma resolution, also
-known as YUV 4:1:0
-
-
-Description
-===========
-
-These are planar formats, as opposed to a packed format. The three
-components are separated into three sub-images or planes. The Y plane is
-first. The Y plane has one byte per pixel. For ``V4L2_PIX_FMT_YVU410``,
-the Cr plane immediately follows the Y plane in memory. The Cr plane is
-¼ the width and ¼ the height of the Y plane (and of the image). Each Cr
-belongs to 16 pixels, a four-by-four square of the image. Following the
-Cr plane is the Cb plane, just like the Cr plane.
-``V4L2_PIX_FMT_YUV410`` is the same, except the Cb plane comes first,
-then the Cr plane.
-
-If the Y plane has pad bytes after each row, then the Cr and Cb planes
-have ¼ as many pad bytes after their rows. In other words, four Cx rows
-(including padding) are exactly as long as one Y row (including
-padding).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cr\ :sub:`00`
- * - start + 17:
- - Cb\ :sub:`00`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- -
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- * - 1
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- -
- -
- -
- - C
- -
- -
- -
- * - 2
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- * - 3
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv411p.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv411p.rst
deleted file mode 100644
index 998aa9b..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv411p.rst
+++ /dev/null
@@ -1,115 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YUV411P:
-
-*****************************
-V4L2_PIX_FMT_YUV411P ('411P')
-*****************************
-
-
-Format with ¼ horizontal chroma resolution, also known as YUV 4:1:1.
-Planar layout as opposed to ``V4L2_PIX_FMT_Y41P``
-
-
-Description
-===========
-
-This format is not commonly used. This is a planar format similar to the
-4:2:2 planar format except with half as many chroma. The three
-components are separated into three sub-images or planes. The Y plane is
-first. The Y plane has one byte per pixel. The Cb plane immediately
-follows the Y plane in memory. The Cb plane is ¼ the width of the Y
-plane (and of the image). Each Cb belongs to 4 pixels all on the same
-row. For example, Cb\ :sub:`0` belongs to Y'\ :sub:`00`, Y'\ :sub:`01`,
-Y'\ :sub:`02` and Y'\ :sub:`03`. Following the Cb plane is the Cr plane,
-just like the Cb plane.
-
-If the Y plane has pad bytes after each row, then the Cr and Cb planes
-have ¼ as many pad bytes after their rows. In other words, four C x rows
-(including padding) is exactly as long as one Y row (including padding).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cb\ :sub:`00`
- * - start + 17:
- - Cb\ :sub:`10`
- * - start + 18:
- - Cb\ :sub:`20`
- * - start + 19:
- - Cb\ :sub:`30`
- * - start + 20:
- - Cr\ :sub:`00`
- * - start + 21:
- - Cr\ :sub:`10`
- * - start + 22:
- - Cr\ :sub:`20`
- * - start + 23:
- - Cr\ :sub:`30`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- - 1
- -
- - 2
- - 3
- * - 0
- - Y
- - Y
- - C
- - Y
- - Y
- * - 1
- - Y
- - Y
- - C
- - Y
- - Y
- * - 2
- - Y
- - Y
- - C
- - Y
- - Y
- * - 3
- - Y
- - Y
- - C
- - Y
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv420.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv420.rst
deleted file mode 100644
index f1c7baf..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv420.rst
+++ /dev/null
@@ -1,143 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YVU420:
-.. _V4L2-PIX-FMT-YUV420:
-
-**********************************************************
-V4L2_PIX_FMT_YVU420 ('YV12'), V4L2_PIX_FMT_YUV420 ('YU12')
-**********************************************************
-
-
-V4L2_PIX_FMT_YUV420
-Planar formats with ½ horizontal and vertical chroma resolution, also
-known as YUV 4:2:0
-
-
-Description
-===========
-
-These are planar formats, as opposed to a packed format. The three
-components are separated into three sub- images or planes. The Y plane
-is first. The Y plane has one byte per pixel. For
-``V4L2_PIX_FMT_YVU420``, the Cr plane immediately follows the Y plane in
-memory. The Cr plane is half the width and half the height of the Y
-plane (and of the image). Each Cr belongs to four pixels, a two-by-two
-square of the image. For example, Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
-Y'\ :sub:`01`, Y'\ :sub:`10`, and Y'\ :sub:`11`. Following the Cr plane
-is the Cb plane, just like the Cr plane. ``V4L2_PIX_FMT_YUV420`` is the
-same except the Cb plane comes first, then the Cr plane.
-
-If the Y plane has pad bytes after each row, then the Cr and Cb planes
-have half as many pad bytes after their rows. In other words, two Cx
-rows (including padding) is exactly as long as one Y row (including
-padding).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cr\ :sub:`00`
- - Cr\ :sub:`01`
- * - start + 18:
- - Cr\ :sub:`10`
- - Cr\ :sub:`11`
- * - start + 20:
- - Cb\ :sub:`00`
- - Cb\ :sub:`01`
- * - start + 22:
- - Cb\ :sub:`10`
- - Cb\ :sub:`11`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- -
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- * - 2
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv420m.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv420m.rst
deleted file mode 100644
index cd20a57..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv420m.rst
+++ /dev/null
@@ -1,152 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YUV420M:
-.. _v4l2-pix-fmt-yvu420m:
-
-************************************************************
-V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')
-************************************************************
-
-
-V4L2_PIX_FMT_YVU420M
-Variation of ``V4L2_PIX_FMT_YUV420`` and ``V4L2_PIX_FMT_YVU420`` with
-planes non contiguous in memory.
-
-
-Description
-===========
-
-This is a multi-planar format, as opposed to a packed format. The three
-components are separated into three sub-images or planes.
-
-The Y plane is first. The Y plane has one byte per pixel. For
-``V4L2_PIX_FMT_YUV420M`` the Cb data constitutes the second plane which
-is half the width and half the height of the Y plane (and of the image).
-Each Cb belongs to four pixels, a two-by-two square of the image. For
-example, Cb\ :sub:`0` belongs to Y'\ :sub:`00`, Y'\ :sub:`01`,
-Y'\ :sub:`10`, and Y'\ :sub:`11`. The Cr data, just like the Cb plane,
-is in the third plane.
-
-``V4L2_PIX_FMT_YVU420M`` is the same except the Cr data is stored in the
-second plane and the Cb data in the third plane.
-
-If the Y plane has pad bytes after each row, then the Cb and Cr planes
-have half as many pad bytes after their rows. In other words, two Cx
-rows (including padding) is exactly as long as one Y row (including
-padding).
-
-``V4L2_PIX_FMT_YUV420M`` and ``V4L2_PIX_FMT_YVU420M`` are intended to be
-used only in drivers and applications that support the multi-planar API,
-described in :ref:`planar-apis`.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start0 + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start0 + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start0 + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start0 + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * -
- * - start1 + 0:
- - Cb\ :sub:`00`
- - Cb\ :sub:`01`
- * - start1 + 2:
- - Cb\ :sub:`10`
- - Cb\ :sub:`11`
- * -
- * - start2 + 0:
- - Cr\ :sub:`00`
- - Cr\ :sub:`01`
- * - start2 + 2:
- - Cr\ :sub:`10`
- - Cr\ :sub:`11`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- -
- - 2
- -
- - 3
- * - 0
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- -
- - C
- -
- * - 1
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- * - 2
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
- * -
- -
- - C
- -
- -
- -
- - C
- -
- * - 3
- - Y
- -
- - Y
- -
- - Y
- -
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv422m.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv422m.rst
deleted file mode 100644
index 32bf15e..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv422m.rst
+++ /dev/null
@@ -1,141 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YUV422M:
-.. _v4l2-pix-fmt-yvu422m:
-
-************************************************************
-V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')
-************************************************************
-
-
-V4L2_PIX_FMT_YVU422M
-Planar formats with ½ horizontal resolution, also known as YUV and YVU
-4:2:2
-
-
-Description
-===========
-
-This is a multi-planar format, as opposed to a packed format. The three
-components are separated into three sub-images or planes.
-
-The Y plane is first. The Y plane has one byte per pixel. For
-``V4L2_PIX_FMT_YUV422M`` the Cb data constitutes the second plane which
-is half the width of the Y plane (and of the image). Each Cb belongs to
-two pixels. For example, Cb\ :sub:`0` belongs to Y'\ :sub:`00`,
-Y'\ :sub:`01`. The Cr data, just like the Cb plane, is in the third
-plane.
-
-``V4L2_PIX_FMT_YVU422M`` is the same except the Cr data is stored in the
-second plane and the Cb data in the third plane.
-
-If the Y plane has pad bytes after each row, then the Cb and Cr planes
-have half as many pad bytes after their rows. In other words, two Cx
-rows (including padding) is exactly as long as one Y row (including
-padding).
-
-``V4L2_PIX_FMT_YUV422M`` and ``V4L2_PIX_FMT_YVU422M`` are intended to be
-used only in drivers and applications that support the multi-planar API,
-described in :ref:`planar-apis`.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start0 + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start0 + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start0 + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start0 + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * -
- * - start1 + 0:
- - Cb\ :sub:`00`
- - Cb\ :sub:`01`
- * - start1 + 2:
- - Cb\ :sub:`10`
- - Cb\ :sub:`11`
- * - start1 + 4:
- - Cb\ :sub:`20`
- - Cb\ :sub:`21`
- * - start1 + 6:
- - Cb\ :sub:`30`
- - Cb\ :sub:`31`
- * -
- * - start2 + 0:
- - Cr\ :sub:`00`
- - Cr\ :sub:`01`
- * - start2 + 2:
- - Cr\ :sub:`10`
- - Cr\ :sub:`11`
- * - start2 + 4:
- - Cr\ :sub:`20`
- - Cr\ :sub:`21`
- * - start2 + 6:
- - Cr\ :sub:`30`
- - Cr\ :sub:`31`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 1
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 2
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 3
- - Y
- - C
- - Y
- - Y
- - C
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv422p.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv422p.rst
deleted file mode 100644
index b178be5..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv422p.rst
+++ /dev/null
@@ -1,129 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YUV422P:
-
-*****************************
-V4L2_PIX_FMT_YUV422P ('422P')
-*****************************
-
-
-Format with ½ horizontal chroma resolution, also known as YUV 4:2:2.
-Planar layout as opposed to ``V4L2_PIX_FMT_YUYV``
-
-
-Description
-===========
-
-This format is not commonly used. This is a planar version of the YUYV
-format. The three components are separated into three sub-images or
-planes. The Y plane is first. The Y plane has one byte per pixel. The Cb
-plane immediately follows the Y plane in memory. The Cb plane is half
-the width of the Y plane (and of the image). Each Cb belongs to two
-pixels. For example, Cb\ :sub:`0` belongs to Y'\ :sub:`00`,
-Y'\ :sub:`01`. Following the Cb plane is the Cr plane, just like the Cb
-plane.
-
-If the Y plane has pad bytes after each row, then the Cr and Cb planes
-have half as many pad bytes after their rows. In other words, two Cx
-rows (including padding) is exactly as long as one Y row (including
-padding).
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * - start + 16:
- - Cb\ :sub:`00`
- - Cb\ :sub:`01`
- * - start + 18:
- - Cb\ :sub:`10`
- - Cb\ :sub:`11`
- * - start + 20:
- - Cb\ :sub:`20`
- - Cb\ :sub:`21`
- * - start + 22:
- - Cb\ :sub:`30`
- - Cb\ :sub:`31`
- * - start + 24:
- - Cr\ :sub:`00`
- - Cr\ :sub:`01`
- * - start + 26:
- - Cr\ :sub:`10`
- - Cr\ :sub:`11`
- * - start + 28:
- - Cr\ :sub:`20`
- - Cr\ :sub:`21`
- * - start + 30:
- - Cr\ :sub:`30`
- - Cr\ :sub:`31`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 1
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 2
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 3
- - Y
- - C
- - Y
- - Y
- - C
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv444m.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv444m.rst
deleted file mode 100644
index 90bdee2..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv444m.rst
+++ /dev/null
@@ -1,141 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YUV444M:
-.. _v4l2-pix-fmt-yvu444m:
-
-************************************************************
-V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')
-************************************************************
-
-
-V4L2_PIX_FMT_YVU444M
-Planar formats with full horizontal resolution, also known as YUV and
-YVU 4:4:4
-
-
-Description
-===========
-
-This is a multi-planar format, as opposed to a packed format. The three
-components are separated into three sub-images or planes.
-
-The Y plane is first. The Y plane has one byte per pixel. For
-``V4L2_PIX_FMT_YUV444M`` the Cb data constitutes the second plane which
-is the same width and height as the Y plane (and as the image). The Cr
-data, just like the Cb plane, is in the third plane.
-
-``V4L2_PIX_FMT_YVU444M`` is the same except the Cr data is stored in the
-second plane and the Cb data in the third plane.
-
-If the Y plane has pad bytes after each row, then the Cb and Cr planes
-have the same number of pad bytes after their rows.
-
-``V4L2_PIX_FMT_YUV444M`` and ``V4L2_PIX_FMT_YUV444M`` are intended to be
-used only in drivers and applications that support the multi-planar API,
-described in :ref:`planar-apis`.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start0 + 0:
- - Y'\ :sub:`00`
- - Y'\ :sub:`01`
- - Y'\ :sub:`02`
- - Y'\ :sub:`03`
- * - start0 + 4:
- - Y'\ :sub:`10`
- - Y'\ :sub:`11`
- - Y'\ :sub:`12`
- - Y'\ :sub:`13`
- * - start0 + 8:
- - Y'\ :sub:`20`
- - Y'\ :sub:`21`
- - Y'\ :sub:`22`
- - Y'\ :sub:`23`
- * - start0 + 12:
- - Y'\ :sub:`30`
- - Y'\ :sub:`31`
- - Y'\ :sub:`32`
- - Y'\ :sub:`33`
- * -
- * - start1 + 0:
- - Cb\ :sub:`00`
- - Cb\ :sub:`01`
- - Cb\ :sub:`02`
- - Cb\ :sub:`03`
- * - start1 + 4:
- - Cb\ :sub:`10`
- - Cb\ :sub:`11`
- - Cb\ :sub:`12`
- - Cb\ :sub:`13`
- * - start1 + 8:
- - Cb\ :sub:`20`
- - Cb\ :sub:`21`
- - Cb\ :sub:`22`
- - Cb\ :sub:`23`
- * - start1 + 12:
- - Cb\ :sub:`20`
- - Cb\ :sub:`21`
- - Cb\ :sub:`32`
- - Cb\ :sub:`33`
- * -
- * - start2 + 0:
- - Cr\ :sub:`00`
- - Cr\ :sub:`01`
- - Cr\ :sub:`02`
- - Cr\ :sub:`03`
- * - start2 + 4:
- - Cr\ :sub:`10`
- - Cr\ :sub:`11`
- - Cr\ :sub:`12`
- - Cr\ :sub:`13`
- * - start2 + 8:
- - Cr\ :sub:`20`
- - Cr\ :sub:`21`
- - Cr\ :sub:`22`
- - Cr\ :sub:`23`
- * - start2 + 12:
- - Cr\ :sub:`30`
- - Cr\ :sub:`31`
- - Cr\ :sub:`32`
- - Cr\ :sub:`33`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- - 1
- - 2
- - 3
- * - 0
- - YC
- - YC
- - YC
- - YC
- * - 1
- - YC
- - YC
- - YC
- - YC
- * - 2
- - YC
- - YC
- - YC
- - YC
- * - 3
- - YC
- - YC
- - YC
- - YC
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuyv.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuyv.rst
deleted file mode 100644
index ca073a5..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuyv.rst
+++ /dev/null
@@ -1,118 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YUYV:
-
-**************************
-V4L2_PIX_FMT_YUYV ('YUYV')
-**************************
-
-
-Packed format with ½ horizontal chroma resolution, also known as YUV
-4:2:2
-
-
-Description
-===========
-
-In this format each four bytes is two pixels. Each four bytes is two
-Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
-belong to both pixels. As you can see, the Cr and Cb components have
-half the horizontal resolution of the Y component. ``V4L2_PIX_FMT_YUYV``
-is known in the Windows environment as YUY2.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Cb\ :sub:`00`
- - Y'\ :sub:`01`
- - Cr\ :sub:`00`
- - Y'\ :sub:`02`
- - Cb\ :sub:`01`
- - Y'\ :sub:`03`
- - Cr\ :sub:`01`
- * - start + 8:
- - Y'\ :sub:`10`
- - Cb\ :sub:`10`
- - Y'\ :sub:`11`
- - Cr\ :sub:`10`
- - Y'\ :sub:`12`
- - Cb\ :sub:`11`
- - Y'\ :sub:`13`
- - Cr\ :sub:`11`
- * - start + 16:
- - Y'\ :sub:`20`
- - Cb\ :sub:`20`
- - Y'\ :sub:`21`
- - Cr\ :sub:`20`
- - Y'\ :sub:`22`
- - Cb\ :sub:`21`
- - Y'\ :sub:`23`
- - Cr\ :sub:`21`
- * - start + 24:
- - Y'\ :sub:`30`
- - Cb\ :sub:`30`
- - Y'\ :sub:`31`
- - Cr\ :sub:`30`
- - Y'\ :sub:`32`
- - Cb\ :sub:`31`
- - Y'\ :sub:`33`
- - Cr\ :sub:`31`
-
-
-**Color Sample Location:**
-
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- -
- - 2
- -
- - 3
- * - 0
- - Y
- - C
- - Y
- -
- - Y
- - C
- - Y
- * - 1
- - Y
- - C
- - Y
- -
- - Y
- - C
- - Y
- * - 2
- - Y
- - C
- - Y
- -
- - Y
- - C
- - Y
- * - 3
- - Y
- - C
- - Y
- -
- - Y
- - C
- - Y
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yvyu.rst b/Documentation/userspace-api/media/v4l/pixfmt-yvyu.rst
deleted file mode 100644
index 81ebec5..0000000
--- a/Documentation/userspace-api/media/v4l/pixfmt-yvyu.rst
+++ /dev/null
@@ -1,108 +0,0 @@
-.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
-
-.. _V4L2-PIX-FMT-YVYU:
-
-**************************
-V4L2_PIX_FMT_YVYU ('YVYU')
-**************************
-
-
-Variation of ``V4L2_PIX_FMT_YUYV`` with different order of samples in
-memory
-
-
-Description
-===========
-
-In this format each four bytes is two pixels. Each four bytes is two
-Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
-belong to both pixels. As you can see, the Cr and Cb components have
-half the horizontal resolution of the Y component.
-
-**Byte Order.**
-Each cell is one byte.
-
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * - start + 0:
- - Y'\ :sub:`00`
- - Cr\ :sub:`00`
- - Y'\ :sub:`01`
- - Cb\ :sub:`00`
- - Y'\ :sub:`02`
- - Cr\ :sub:`01`
- - Y'\ :sub:`03`
- - Cb\ :sub:`01`
- * - start + 8:
- - Y'\ :sub:`10`
- - Cr\ :sub:`10`
- - Y'\ :sub:`11`
- - Cb\ :sub:`10`
- - Y'\ :sub:`12`
- - Cr\ :sub:`11`
- - Y'\ :sub:`13`
- - Cb\ :sub:`11`
- * - start + 16:
- - Y'\ :sub:`20`
- - Cr\ :sub:`20`
- - Y'\ :sub:`21`
- - Cb\ :sub:`20`
- - Y'\ :sub:`22`
- - Cr\ :sub:`21`
- - Y'\ :sub:`23`
- - Cb\ :sub:`21`
- * - start + 24:
- - Y'\ :sub:`30`
- - Cr\ :sub:`30`
- - Y'\ :sub:`31`
- - Cb\ :sub:`30`
- - Y'\ :sub:`32`
- - Cr\ :sub:`31`
- - Y'\ :sub:`33`
- - Cb\ :sub:`31`
-
-
-**Color Sample Location:**
-
-.. flat-table::
- :header-rows: 0
- :stub-columns: 0
-
- * -
- - 0
- -
- - 1
- - 2
- -
- - 3
- * - 0
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 1
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 2
- - Y
- - C
- - Y
- - Y
- - C
- - Y
- * - 3
- - Y
- - C
- - Y
- - Y
- - C
- - Y
diff --git a/Documentation/userspace-api/media/v4l/selection-api-configuration.rst b/Documentation/userspace-api/media/v4l/selection-api-configuration.rst
index 37617ed..fee49bf 100644
--- a/Documentation/userspace-api/media/v4l/selection-api-configuration.rst
+++ b/Documentation/userspace-api/media/v4l/selection-api-configuration.rst
@@ -94,7 +94,7 @@
The top left corner, width and height of the source rectangle, that is
the area from which image date are processed by the hardware, is given
-by the ``V4L2_SEL_TGT_CROP``. Its coordinates are expressed in in the
+by the ``V4L2_SEL_TGT_CROP``. Its coordinates are expressed in the
same coordinate system as the bounds rectangle. The active cropping area
must lie completely inside the crop boundaries and the driver may
further adjust the requested size and/or position according to hardware
diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index c9b7bb3..7f16cbe 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -7899,3 +7899,30 @@
- 0x5001
- Interleaved raw UYVY and JPEG image format with embedded meta-data
used by Samsung S3C73MX camera sensors.
+
+.. _v4l2-mbus-metadata-fmts:
+
+Metadata Formats
+^^^^^^^^^^^^^^^^
+
+This section lists all metadata formats.
+
+The following table lists the existing metadata formats.
+
+.. tabularcolumns:: |p{8.0cm}|p{1.4cm}|p{7.7cm}|
+
+.. flat-table:: Metadata formats
+ :header-rows: 1
+ :stub-columns: 0
+
+ * - Identifier
+ - Code
+ - Comments
+ * .. _MEDIA-BUS-FMT-METADATA-FIXED:
+
+ - MEDIA_BUS_FMT_METADATA_FIXED
+ - 0x7001
+ - This format should be used when the same driver handles
+ both sides of the link and the bus format is a fixed
+ metadata format that is not configurable from userspace.
+ Width and height will be set to 0 for this format.
diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
index f2173e31..b9c62af 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
@@ -53,7 +53,7 @@
To get the current value of a set of controls applications initialize
the ``id``, ``size`` and ``reserved2`` fields of each struct
:c:type:`v4l2_ext_control` and call the
-:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` ioctl. String controls controls must also set the
+:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` ioctl. String controls must also set the
``string`` field. Controls of compound types
(``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set) must set the ``ptr`` field.
@@ -180,10 +180,38 @@
- ``p_u32``
- A pointer to a matrix control of unsigned 32-bit values. Valid if
this control is of type ``V4L2_CTRL_TYPE_U32``.
- * - :c:type:`v4l2_area` *
+ * - struct :c:type:`v4l2_area` *
- ``p_area``
- A pointer to a struct :c:type:`v4l2_area`. Valid if this control is
of type ``V4L2_CTRL_TYPE_AREA``.
+ * - struct :c:type:`v4l2_ctrl_h264_sps` *
+ - ``p_h264_sps``
+ - A pointer to a struct :c:type:`v4l2_ctrl_h264_sps`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_H264_SPS``.
+ * - struct :c:type:`v4l2_ctrl_h264_pps` *
+ - ``p_h264_pps``
+ - A pointer to a struct :c:type:`v4l2_ctrl_h264_pps`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_H264_PPS``.
+ * - struct :c:type:`v4l2_ctrl_h264_scaling_matrix` *
+ - ``p_h264_scaling_matrix``
+ - A pointer to a struct :c:type:`v4l2_ctrl_h264_scaling_matrix`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_H264_SCALING_MATRIX``.
+ * - struct :c:type:`v4l2_ctrl_h264_pred_weights` *
+ - ``p_h264_pred_weights``
+ - A pointer to a struct :c:type:`v4l2_ctrl_h264_pred_weights`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_H264_PRED_WEIGHTS``.
+ * - struct :c:type:`v4l2_ctrl_h264_slice_params` *
+ - ``p_h264_slice_params``
+ - A pointer to a struct :c:type:`v4l2_ctrl_h264_slice_params`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_H264_SLICE_PARAMS``.
+ * - struct :c:type:`v4l2_ctrl_h264_decode_params` *
+ - ``p_h264_decode_params``
+ - A pointer to a struct :c:type:`v4l2_ctrl_h264_decode_params`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_H264_DECODE_PARAMS``.
+ * - struct :c:type:`v4l2_ctrl_fwht_params` *
+ - ``p_fwht_params``
+ - A pointer to a struct :c:type:`v4l2_ctrl_fwht_params`. Valid if this control is
+ of type ``V4L2_CTRL_TYPE_FWHT_PARAMS``.
* - void *
- ``ptr``
- A pointer to a compound type which can be an N-dimensional array
@@ -322,10 +350,10 @@
:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` and
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` ioctl belong to this
class.
- * - ``V4L2_CTRL_CLASS_MPEG``
+ * - ``V4L2_CTRL_CLASS_CODEC``
- 0x990000
- - The class containing MPEG compression controls. These controls are
- described in :ref:`mpeg-controls`.
+ - The class containing stateful codec controls. These controls are
+ described in :ref:`codec-controls`.
* - ``V4L2_CTRL_CLASS_CAMERA``
- 0x9a0000
- The class containing camera controls. These controls are described
@@ -358,6 +386,14 @@
- 0xa20000
- The class containing RF tuner controls. These controls are
described in :ref:`rf-tuner-controls`.
+ * - ``V4L2_CTRL_CLASS_DETECT``
+ - 0xa30000
+ - The class containing motion or object detection controls. These controls
+ are described in :ref:`detect-controls`.
+ * - ``V4L2_CTRL_CLASS_CODEC_STATELESS``
+ - 0xa40000
+ - The class containing stateless codec controls. These controls are
+ described in :ref:`codec-stateless-controls`.
Return Value
============
diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-output.rst b/Documentation/userspace-api/media/v4l/vidioc-g-output.rst
index 3138c4c..dbcdd51 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-g-output.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-g-output.rst
@@ -46,7 +46,7 @@
output in an integer and call the :ref:`VIDIOC_S_OUTPUT <VIDIOC_G_OUTPUT>` ioctl with a
pointer to this integer. Side effects are possible. For example outputs
may support different video standards, so the driver may implicitly
-switch the current standard. standard. Because of these possible side
+switch the current standard. Because of these possible side
effects applications must select an output before querying or
negotiating any other parameters.
diff --git a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst
index fbf8c59..77e0747 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst
@@ -163,7 +163,7 @@
The buffer ``type`` is not supported, or the ``index`` is out of
bounds, or no buffers have been allocated yet, or the ``userptr`` or
``length`` are invalid, or the ``V4L2_BUF_FLAG_REQUEST_FD`` flag was
- set but the the given ``request_fd`` was invalid, or ``m.fd`` was
+ set but the given ``request_fd`` was invalid, or ``m.fd`` was
an invalid DMABUF file descriptor.
EIO
diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
index 9b8716f..82f61f1 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
@@ -462,6 +462,12 @@
- n/a
- A struct :c:type:`v4l2_ctrl_h264_decode_params`, containing H264
decode parameters for stateless video decoders.
+ * - ``V4L2_CTRL_TYPE_FWHT_PARAMS``
+ - n/a
+ - n/a
+ - n/a
+ - A struct :c:type:`v4l2_ctrl_fwht_params`, containing FWHT
+ parameters for stateless video decoders.
* - ``V4L2_CTRL_TYPE_HEVC_SPS``
- n/a
- n/a
diff --git a/Documentation/userspace-api/media/v4l/yuv-formats.rst b/Documentation/userspace-api/media/v4l/yuv-formats.rst
index 4a05a10..24b34cd 100644
--- a/Documentation/userspace-api/media/v4l/yuv-formats.rst
+++ b/Documentation/userspace-api/media/v4l/yuv-formats.rst
@@ -14,44 +14,260 @@
:ref:`colorspaces` for conversion examples. YUV was chosen because
early television would only transmit brightness information. To add
color in a way compatible with existing receivers a new signal carrier
-was added to transmit the color difference signals. Secondary in the YUV
-format the U and V components usually have lower resolution than the Y
-component. This is an analog video compression technique taking
-advantage of a property of the human visual system, being more sensitive
-to brightness information.
+was added to transmit the color difference signals.
+
+
+Subsampling
+===========
+
+YUV formats commonly encode images with a lower resolution for the chroma
+components than for the luma component. This compression technique, taking
+advantage of the human eye being more sensitive to luminance than color
+differences, is called chroma subsampling.
+
+While many combinations of subsampling factors in the horizontal and vertical
+direction are possible, common factors are 1 (no subsampling), 2 and 4, with
+horizontal subsampling always larger than or equal to vertical subsampling.
+Common combinations are named as follows.
+
+- `4:4:4`: No subsampling
+- `4:2:2`: Horizontal subsampling by 2, no vertical subsampling
+- `4:2:0`: Horizontal subsampling by 2, vertical subsampling by 2
+- `4:1:1`: Horizontal subsampling by 4, no vertical subsampling
+- `4:1:0`: Horizontal subsampling by 4, vertical subsampling by 4
+
+Subsampling the chroma component effectively creates chroma values that can be
+located in different spatial locations:
+
+- .. _yuv-chroma-centered:
+
+ The subsampled chroma value may be calculated by simply averaging the chroma
+ value of two consecutive pixels. It effectively models the chroma of a pixel
+ sited between the two original pixels. This is referred to as centered or
+ interstitially sited chroma.
+
+- .. _yuv-chroma-cosited:
+
+ The other option is to subsample chroma values in a way that place them in
+ the same spatial sites as the pixels. This may be performed by skipping every
+ other chroma sample (creating aliasing artifacts), or with filters using an
+ odd number of taps. This is referred to as co-sited chroma.
+
+The following examples show different combination of chroma siting in a 4x4
+image.
+
+.. flat-table:: 4:2:2 subsampling, interstitially sited
+ :header-rows: 1
+ :stub-columns: 1
+
+ * -
+ - 0
+ -
+ - 1
+ -
+ - 2
+ -
+ - 3
+ * - 0
+ - Y
+ - C
+ - Y
+ -
+ - Y
+ - C
+ - Y
+ * - 1
+ - Y
+ - C
+ - Y
+ -
+ - Y
+ - C
+ - Y
+ * - 2
+ - Y
+ - C
+ - Y
+ -
+ - Y
+ - C
+ - Y
+ * - 3
+ - Y
+ - C
+ - Y
+ -
+ - Y
+ - C
+ - Y
+
+.. flat-table:: 4:2:2 subsampling, co-sited
+ :header-rows: 1
+ :stub-columns: 1
+
+ * -
+ - 0
+ -
+ - 1
+ -
+ - 2
+ -
+ - 3
+ * - 0
+ - Y/C
+ -
+ - Y
+ -
+ - Y/C
+ -
+ - Y
+ * - 1
+ - Y/C
+ -
+ - Y
+ -
+ - Y/C
+ -
+ - Y
+ * - 2
+ - Y/C
+ -
+ - Y
+ -
+ - Y/C
+ -
+ - Y
+ * - 3
+ - Y/C
+ -
+ - Y
+ -
+ - Y/C
+ -
+ - Y
+
+.. flat-table:: 4:2:0 subsampling, horizontally interstitially sited, vertically co-sited
+ :header-rows: 1
+ :stub-columns: 1
+
+ * -
+ - 0
+ -
+ - 1
+ -
+ - 2
+ -
+ - 3
+ * - 0
+ - Y
+ - C
+ - Y
+ -
+ - Y
+ - C
+ - Y
+ * - 1
+ - Y
+ -
+ - Y
+ -
+ - Y
+ -
+ - Y
+ * - 2
+ - Y
+ - C
+ - Y
+ -
+ - Y
+ - C
+ - Y
+ * - 3
+ - Y
+ -
+ - Y
+ -
+ - Y
+ -
+ - Y
+
+.. flat-table:: 4:1:0 subsampling, horizontally and vertically interstitially sited
+ :header-rows: 1
+ :stub-columns: 1
+
+ * -
+ - 0
+ -
+ - 1
+ -
+ - 2
+ -
+ - 3
+ * - 0
+ - Y
+ -
+ - Y
+ -
+ - Y
+ -
+ - Y
+ * -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ * - 1
+ - Y
+ -
+ - Y
+ -
+ - Y
+ -
+ - Y
+ * -
+ -
+ -
+ -
+ - C
+ -
+ -
+ -
+ * - 2
+ - Y
+ -
+ - Y
+ -
+ - Y
+ -
+ - Y
+ * -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ * - 3
+ - Y
+ -
+ - Y
+ -
+ - Y
+ -
+ - Y
.. toctree::
:maxdepth: 1
pixfmt-packed-yuv
- pixfmt-grey
- pixfmt-y10
- pixfmt-y12
- pixfmt-y14
- pixfmt-y10b
- pixfmt-y10p
- pixfmt-y16
- pixfmt-y16-be
+ pixfmt-yuv-planar
+ pixfmt-yuv-luma
pixfmt-y8i
pixfmt-y12i
pixfmt-uv8
- pixfmt-yuyv
- pixfmt-uyvy
- pixfmt-yvyu
- pixfmt-vyuy
- pixfmt-y41p
- pixfmt-yuv420
- pixfmt-yuv420m
- pixfmt-yuv422m
- pixfmt-yuv444m
- pixfmt-yuv410
- pixfmt-yuv422p
- pixfmt-yuv411p
- pixfmt-nv12
- pixfmt-nv12m
- pixfmt-nv12mt
- pixfmt-nv16
- pixfmt-nv16m
- pixfmt-nv24
pixfmt-m420
diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
index 121e396..0ed170c 100644
--- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
+++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
@@ -139,12 +139,14 @@
replace symbol V4L2_CTRL_TYPE_H264_SPS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_PPS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_SCALING_MATRIX :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_H264_PRED_WEIGHTS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_H264_DECODE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_HEVC_SPS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_HEVC_PPS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_AREA :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_FWHT_PARAMS :c:type:`v4l2_ctrl_type`
# V4L2 capability defines
replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index e00a66d..70254ea 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -262,6 +262,18 @@
memory region. This ioctl returns the size of that region. See the
KVM_RUN documentation for details.
+Besides the size of the KVM_RUN communication region, other areas of
+the VCPU file descriptor can be mmap-ed, including:
+
+- if KVM_CAP_COALESCED_MMIO is available, a page at
+ KVM_COALESCED_MMIO_PAGE_OFFSET * PAGE_SIZE; for historical reasons,
+ this page is included in the result of KVM_GET_VCPU_MMAP_SIZE.
+ KVM_CAP_COALESCED_MMIO is not documented yet.
+
+- if KVM_CAP_DIRTY_LOG_RING is available, a number of pages at
+ KVM_DIRTY_LOG_PAGE_OFFSET * PAGE_SIZE. For more information on
+ KVM_CAP_DIRTY_LOG_RING, see section 8.3.
+
4.6 KVM_SET_MEMORY_REGION
-------------------------
@@ -4455,9 +4467,9 @@
4.118 KVM_GET_SUPPORTED_HV_CPUID
--------------------------------
-:Capability: KVM_CAP_HYPERV_CPUID
+:Capability: KVM_CAP_HYPERV_CPUID (vcpu), KVM_CAP_SYS_HYPERV_CPUID (system)
:Architectures: x86
-:Type: vcpu ioctl
+:Type: system ioctl, vcpu ioctl
:Parameters: struct kvm_cpuid2 (in/out)
:Returns: 0 on success, -1 on error
@@ -4502,9 +4514,6 @@
- HYPERV_CPUID_SYNDBG_INTERFACE
- HYPERV_CPUID_SYNDBG_PLATFORM_CAPABILITIES
-HYPERV_CPUID_NESTED_FEATURES leaf is only exposed when Enlightened VMCS was
-enabled on the corresponding vCPU (KVM_CAP_HYPERV_ENLIGHTENED_VMCS).
-
Userspace invokes KVM_GET_SUPPORTED_HV_CPUID by passing a kvm_cpuid2 structure
with the 'nent' field indicating the number of entries in the variable-size
array 'entries'. If the number of entries is too low to describe all Hyper-V
@@ -4515,6 +4524,15 @@
'index' and 'flags' fields in 'struct kvm_cpuid_entry2' are currently reserved,
userspace should not expect to get any particular value there.
+Note, vcpu version of KVM_GET_SUPPORTED_HV_CPUID is currently deprecated. Unlike
+system ioctl which exposes all supported feature bits unconditionally, vcpu
+version has the following quirks:
+- HYPERV_CPUID_NESTED_FEATURES leaf and HV_X64_ENLIGHTENED_VMCS_RECOMMENDED
+ feature bit are only exposed when Enlightened VMCS was previously enabled
+ on the corresponding vCPU (KVM_CAP_HYPERV_ENLIGHTENED_VMCS).
+- HV_STIMER_DIRECT_MODE_AVAILABLE bit is only exposed with in-kernel LAPIC.
+ (presumes KVM_CREATE_IRQCHIP has already been called).
+
4.119 KVM_ARM_VCPU_FINALIZE
---------------------------
@@ -6390,3 +6408,91 @@
guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf
(0x40000001). Otherwise, a guest may use the paravirtual features
regardless of what has actually been exposed through the CPUID leaf.
+
+
+8.29 KVM_CAP_DIRTY_LOG_RING
+---------------------------
+
+:Architectures: x86
+:Parameters: args[0] - size of the dirty log ring
+
+KVM is capable of tracking dirty memory using ring buffers that are
+mmaped into userspace; there is one dirty ring per vcpu.
+
+The dirty ring is available to userspace as an array of
+``struct kvm_dirty_gfn``. Each dirty entry it's defined as::
+
+ struct kvm_dirty_gfn {
+ __u32 flags;
+ __u32 slot; /* as_id | slot_id */
+ __u64 offset;
+ };
+
+The following values are defined for the flags field to define the
+current state of the entry::
+
+ #define KVM_DIRTY_GFN_F_DIRTY BIT(0)
+ #define KVM_DIRTY_GFN_F_RESET BIT(1)
+ #define KVM_DIRTY_GFN_F_MASK 0x3
+
+Userspace should call KVM_ENABLE_CAP ioctl right after KVM_CREATE_VM
+ioctl to enable this capability for the new guest and set the size of
+the rings. Enabling the capability is only allowed before creating any
+vCPU, and the size of the ring must be a power of two. The larger the
+ring buffer, the less likely the ring is full and the VM is forced to
+exit to userspace. The optimal size depends on the workload, but it is
+recommended that it be at least 64 KiB (4096 entries).
+
+Just like for dirty page bitmaps, the buffer tracks writes to
+all user memory regions for which the KVM_MEM_LOG_DIRTY_PAGES flag was
+set in KVM_SET_USER_MEMORY_REGION. Once a memory region is registered
+with the flag set, userspace can start harvesting dirty pages from the
+ring buffer.
+
+An entry in the ring buffer can be unused (flag bits ``00``),
+dirty (flag bits ``01``) or harvested (flag bits ``1X``). The
+state machine for the entry is as follows::
+
+ dirtied harvested reset
+ 00 -----------> 01 -------------> 1X -------+
+ ^ |
+ | |
+ +------------------------------------------+
+
+To harvest the dirty pages, userspace accesses the mmaped ring buffer
+to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage
+the RESET bit must be cleared), then it means this GFN is a dirty GFN.
+The userspace should harvest this GFN and mark the flags from state
+``01b`` to ``1Xb`` (bit 0 will be ignored by KVM, but bit 1 must be set
+to show that this GFN is harvested and waiting for a reset), and move
+on to the next GFN. The userspace should continue to do this until the
+flags of a GFN have the DIRTY bit cleared, meaning that it has harvested
+all the dirty GFNs that were available.
+
+It's not necessary for userspace to harvest the all dirty GFNs at once.
+However it must collect the dirty GFNs in sequence, i.e., the userspace
+program cannot skip one dirty GFN to collect the one next to it.
+
+After processing one or more entries in the ring buffer, userspace
+calls the VM ioctl KVM_RESET_DIRTY_RINGS to notify the kernel about
+it, so that the kernel will reprotect those collected GFNs.
+Therefore, the ioctl must be called *before* reading the content of
+the dirty pages.
+
+The dirty ring can get full. When it happens, the KVM_RUN of the
+vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL.
+
+The dirty ring interface has a major difference comparing to the
+KVM_GET_DIRTY_LOG interface in that, when reading the dirty ring from
+userspace, it's still possible that the kernel has not yet flushed the
+processor's dirty page buffers into the kernel buffer (with dirty bitmaps, the
+flushing is done by the KVM_GET_DIRTY_LOG ioctl). To achieve that, one
+needs to kick the vcpu out of KVM_RUN using a signal. The resulting
+vmexit ensures that all dirty GFNs are flushed to the dirty rings.
+
+NOTE: the capability KVM_CAP_DIRTY_LOG_RING and the corresponding
+ioctl KVM_RESET_DIRTY_RINGS are mutual exclusive to the existing ioctls
+KVM_GET_DIRTY_LOG and KVM_CLEAR_DIRTY_LOG. After enabling
+KVM_CAP_DIRTY_LOG_RING with an acceptable dirty ring size, the virtual
+machine will switch to ring-buffer dirty page tracking and further
+KVM_GET_DIRTY_LOG or KVM_CLEAR_DIRTY_LOG ioctls will fail.
diff --git a/Documentation/virt/kvm/arm/pvtime.rst b/Documentation/virt/kvm/arm/pvtime.rst
index 687b60d..392521a 100644
--- a/Documentation/virt/kvm/arm/pvtime.rst
+++ b/Documentation/virt/kvm/arm/pvtime.rst
@@ -19,8 +19,8 @@
These are only available in the SMC64/HVC64 calling convention as
paravirtualized time is not available to 32 bit Arm guests. The existence of
-the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
-mechanism before calling it.
+the PV_TIME_FEATURES hypercall should be probed using the SMCCC 1.1
+ARCH_FEATURES mechanism before calling it.
PV_TIME_FEATURES
============= ======== ==========
diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst
index 9daadf9..ce398a7 100644
--- a/Documentation/vm/memory-model.rst
+++ b/Documentation/vm/memory-model.rst
@@ -51,8 +51,7 @@
usable until the call to :c:func:`memblock_free_all` that hands all the
memory to the page allocator.
-If an architecture enables `CONFIG_ARCH_HAS_HOLES_MEMORYMODEL` option,
-it may free parts of the `mem_map` array that do not cover the
+An architecture may free parts of the `mem_map` array that do not cover the
actual physical pages. In such case, the architecture specific
:c:func:`pfn_valid` implementation should take the holes in the
`mem_map` into account.
diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst
index 02deac7..4e67c2e 100644
--- a/Documentation/vm/page_owner.rst
+++ b/Documentation/vm/page_owner.rst
@@ -41,17 +41,17 @@
- Without page owner::
text data bss dec hex filename
- 40662 1493 644 42799 a72f mm/page_alloc.o
+ 48392 2333 644 51369 c8a9 mm/page_alloc.o
- With page owner::
text data bss dec hex filename
- 40892 1493 644 43029 a815 mm/page_alloc.o
- 1427 24 8 1459 5b3 mm/page_ext.o
- 2722 50 0 2772 ad4 mm/page_owner.o
+ 48800 2445 644 51889 cab1 mm/page_alloc.o
+ 6574 108 29 6711 1a37 mm/page_owner.o
+ 1025 8 8 1041 411 mm/page_ext.o
-Although, roughly, 4 KB code is added in total, page_alloc.o increase by
-230 bytes and only half of it is in hotpath. Building the kernel with
+Although, roughly, 8 KB code is added in total, page_alloc.o increase by
+520 bytes and less than half of it is in hotpath. Building the kernel with
page owner and turning it on if needed would be great option to debug
kernel memory problem.
diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst
index 17d0861..0e14905 100644
--- a/Documentation/vm/unevictable-lru.rst
+++ b/Documentation/vm/unevictable-lru.rst
@@ -33,7 +33,7 @@
memory x86_64 systems.
To illustrate this with an example, a non-NUMA x86_64 platform with 128GB of
-main memory will have over 32 million 4k pages in a single zone. When a large
+main memory will have over 32 million 4k pages in a single node. When a large
fraction of these pages are not evictable for any reason [see below], vmscan
will spend a lot of time scanning the LRU lists looking for the small fraction
of pages that are evictable. This can result in a situation where all CPUs are
@@ -55,7 +55,7 @@
The Unevictable Page List
-------------------------
-The Unevictable LRU infrastructure consists of an additional, per-zone, LRU list
+The Unevictable LRU infrastructure consists of an additional, per-node, LRU list
called the "unevictable" list and an associated page flag, PG_unevictable, to
indicate that the page is being managed on the unevictable list.
@@ -84,15 +84,9 @@
swap-backed pages. This differentiation is only important while the pages are,
in fact, evictable.
-The unevictable list benefits from the "arrayification" of the per-zone LRU
+The unevictable list benefits from the "arrayification" of the per-node LRU
lists and statistics originally proposed and posted by Christoph Lameter.
-The unevictable list does not use the LRU pagevec mechanism. Rather,
-unevictable pages are placed directly on the page's zone's unevictable list
-under the zone lru_lock. This allows us to prevent the stranding of pages on
-the unevictable list when one task has the page isolated from the LRU and other
-tasks are changing the "evictability" state of the page.
-
Memory Control Group Interaction
--------------------------------
@@ -101,8 +95,8 @@
memory controller; see Documentation/admin-guide/cgroup-v1/memory.rst] by extending the
lru_list enum.
-The memory controller data structure automatically gets a per-zone unevictable
-list as a result of the "arrayification" of the per-zone LRU lists (one per
+The memory controller data structure automatically gets a per-node unevictable
+list as a result of the "arrayification" of the per-node LRU lists (one per
lru_list enum element). The memory controller tracks the movement of pages to
and from the unevictable list.
@@ -196,7 +190,7 @@
active/inactive LRU lists for vmscan to deal with. vmscan checks for such
pages in all of the shrink_{active|inactive|page}_list() functions and will
"cull" such pages that it encounters: that is, it diverts those pages to the
-unevictable list for the zone being scanned.
+unevictable list for the node being scanned.
There may be situations where a page is mapped into a VM_LOCKED VMA, but the
page is not marked as PG_mlocked. Such pages will make it all the way to
@@ -328,7 +322,7 @@
page from the LRU, as it is likely on the appropriate active or inactive list
at that time. If the isolate_lru_page() succeeds, mlock_vma_page() will put
back the page - by calling putback_lru_page() - which will notice that the page
-is now mlocked and divert the page to the zone's unevictable list. If
+is now mlocked and divert the page to the node's unevictable list. If
mlock_vma_page() is unable to isolate the page from the LRU, vmscan will handle
it later if and when it attempts to reclaim the page.
@@ -603,7 +597,7 @@
unevictable list in mlock_vma_page().
shrink_inactive_list() also diverts any unevictable pages that it finds on the
-inactive lists to the appropriate zone's unevictable list.
+inactive lists to the appropriate node's unevictable list.
shrink_inactive_list() should only see SHM_LOCK'd pages that became SHM_LOCK'd
after shrink_active_list() had moved them to the inactive list, or pages mapped
diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst
index e39202e..c3c9ed7 100644
--- a/Documentation/w1/slaves/w1_therm.rst
+++ b/Documentation/w1/slaves/w1_therm.rst
@@ -82,7 +82,7 @@
Note: Changing the resolution reverts the conversion time to default.
-The write-only sysfs entry ``eeprom`` is an alternative for EEPROM operations.
+The write-only sysfs entry ``eeprom_cmd`` is an alternative for EEPROM operations.
Write ``save`` to save device RAM to EEPROM. Write ``restore`` to restore EEPROM
data in device RAM.
diff --git a/Documentation/x86/features.rst b/Documentation/x86/features.rst
new file mode 100644
index 0000000..b663f15
--- /dev/null
+++ b/Documentation/x86/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features x86
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index b224d12..4693e19 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -27,9 +27,11 @@
pti
mds
microcode
- resctrl_ui
+ resctrl
tsx_async_abort
usb-legacy-support
i386/index
x86_64/index
sva
+ sgx
+ features
diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
new file mode 100644
index 0000000..71a5310
--- /dev/null
+++ b/Documentation/x86/resctrl.rst
@@ -0,0 +1,1304 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===========================================
+User Interface for Resource Control feature
+===========================================
+
+:Copyright: |copy| 2016 Intel Corporation
+:Authors: - Fenghua Yu <fenghua.yu@intel.com>
+ - Tony Luck <tony.luck@intel.com>
+ - Vikas Shivappa <vikas.shivappa@intel.com>
+
+
+Intel refers to this feature as Intel Resource Director Technology(Intel(R) RDT).
+AMD refers to this feature as AMD Platform Quality of Service(AMD QoS).
+
+This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
+flag bits:
+
+============================================= ================================
+RDT (Resource Director Technology) Allocation "rdt_a"
+CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
+CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
+CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
+MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
+MBA (Memory Bandwidth Allocation) "mba"
+============================================= ================================
+
+To use the feature mount the file system::
+
+ # mount -t resctrl resctrl [-o cdp[,cdpl2][,mba_MBps]] /sys/fs/resctrl
+
+mount options are:
+
+"cdp":
+ Enable code/data prioritization in L3 cache allocations.
+"cdpl2":
+ Enable code/data prioritization in L2 cache allocations.
+"mba_MBps":
+ Enable the MBA Software Controller(mba_sc) to specify MBA
+ bandwidth in MBps
+
+L2 and L3 CDP are controlled separately.
+
+RDT features are orthogonal. A particular system may support only
+monitoring, only control, or both monitoring and control. Cache
+pseudo-locking is a unique way of using cache control to "pin" or
+"lock" data in the cache. Details can be found in
+"Cache Pseudo-Locking".
+
+
+The mount succeeds if either of allocation or monitoring is present, but
+only those files and directories supported by the system will be created.
+For more details on the behavior of the interface during monitoring
+and allocation, see the "Resource alloc and monitor groups" section.
+
+Info directory
+==============
+
+The 'info' directory contains information about the enabled
+resources. Each resource has its own subdirectory. The subdirectory
+names reflect the resource names.
+
+Each subdirectory contains the following files with respect to
+allocation:
+
+Cache resource(L3/L2) subdirectory contains the following files
+related to allocation:
+
+"num_closids":
+ The number of CLOSIDs which are valid for this
+ resource. The kernel uses the smallest number of
+ CLOSIDs of all enabled resources as limit.
+"cbm_mask":
+ The bitmask which is valid for this resource.
+ This mask is equivalent to 100%.
+"min_cbm_bits":
+ The minimum number of consecutive bits which
+ must be set when writing a mask.
+
+"shareable_bits":
+ Bitmask of shareable resource with other executing
+ entities (e.g. I/O). User can use this when
+ setting up exclusive cache partitions. Note that
+ some platforms support devices that have their
+ own settings for cache use which can over-ride
+ these bits.
+"bit_usage":
+ Annotated capacity bitmasks showing how all
+ instances of the resource are used. The legend is:
+
+ "0":
+ Corresponding region is unused. When the system's
+ resources have been allocated and a "0" is found
+ in "bit_usage" it is a sign that resources are
+ wasted.
+
+ "H":
+ Corresponding region is used by hardware only
+ but available for software use. If a resource
+ has bits set in "shareable_bits" but not all
+ of these bits appear in the resource groups'
+ schematas then the bits appearing in
+ "shareable_bits" but no resource group will
+ be marked as "H".
+ "X":
+ Corresponding region is available for sharing and
+ used by hardware and software. These are the
+ bits that appear in "shareable_bits" as
+ well as a resource group's allocation.
+ "S":
+ Corresponding region is used by software
+ and available for sharing.
+ "E":
+ Corresponding region is used exclusively by
+ one resource group. No sharing allowed.
+ "P":
+ Corresponding region is pseudo-locked. No
+ sharing allowed.
+
+Memory bandwidth(MB) subdirectory contains the following files
+with respect to allocation:
+
+"min_bandwidth":
+ The minimum memory bandwidth percentage which
+ user can request.
+
+"bandwidth_gran":
+ The granularity in which the memory bandwidth
+ percentage is allocated. The allocated
+ b/w percentage is rounded off to the next
+ control step available on the hardware. The
+ available bandwidth control steps are:
+ min_bandwidth + N * bandwidth_gran.
+
+"delay_linear":
+ Indicates if the delay scale is linear or
+ non-linear. This field is purely informational
+ only.
+
+"thread_throttle_mode":
+ Indicator on Intel systems of how tasks running on threads
+ of a physical core are throttled in cases where they
+ request different memory bandwidth percentages:
+
+ "max":
+ the smallest percentage is applied
+ to all threads
+ "per-thread":
+ bandwidth percentages are directly applied to
+ the threads running on the core
+
+If RDT monitoring is available there will be an "L3_MON" directory
+with the following files:
+
+"num_rmids":
+ The number of RMIDs available. This is the
+ upper bound for how many "CTRL_MON" + "MON"
+ groups can be created.
+
+"mon_features":
+ Lists the monitoring events if
+ monitoring is enabled for the resource.
+
+"max_threshold_occupancy":
+ Read/write file provides the largest value (in
+ bytes) at which a previously used LLC_occupancy
+ counter can be considered for re-use.
+
+Finally, in the top level of the "info" directory there is a file
+named "last_cmd_status". This is reset with every "command" issued
+via the file system (making new directories or writing to any of the
+control files). If the command was successful, it will read as "ok".
+If the command failed, it will provide more information that can be
+conveyed in the error returns from file operations. E.g.
+::
+
+ # echo L3:0=f7 > schemata
+ bash: echo: write error: Invalid argument
+ # cat info/last_cmd_status
+ mask f7 has non-consecutive 1-bits
+
+Resource alloc and monitor groups
+=================================
+
+Resource groups are represented as directories in the resctrl file
+system. The default group is the root directory which, immediately
+after mounting, owns all the tasks and cpus in the system and can make
+full use of all resources.
+
+On a system with RDT control features additional directories can be
+created in the root directory that specify different amounts of each
+resource (see "schemata" below). The root and these additional top level
+directories are referred to as "CTRL_MON" groups below.
+
+On a system with RDT monitoring the root directory and other top level
+directories contain a directory named "mon_groups" in which additional
+directories can be created to monitor subsets of tasks in the CTRL_MON
+group that is their ancestor. These are called "MON" groups in the rest
+of this document.
+
+Removing a directory will move all tasks and cpus owned by the group it
+represents to the parent. Removing one of the created CTRL_MON groups
+will automatically remove all MON groups below it.
+
+All groups contain the following files:
+
+"tasks":
+ Reading this file shows the list of all tasks that belong to
+ this group. Writing a task id to the file will add a task to the
+ group. If the group is a CTRL_MON group the task is removed from
+ whichever previous CTRL_MON group owned the task and also from
+ any MON group that owned the task. If the group is a MON group,
+ then the task must already belong to the CTRL_MON parent of this
+ group. The task is removed from any previous MON group.
+
+
+"cpus":
+ Reading this file shows a bitmask of the logical CPUs owned by
+ this group. Writing a mask to this file will add and remove
+ CPUs to/from this group. As with the tasks file a hierarchy is
+ maintained where MON groups may only include CPUs owned by the
+ parent CTRL_MON group.
+ When the resource group is in pseudo-locked mode this file will
+ only be readable, reflecting the CPUs associated with the
+ pseudo-locked region.
+
+
+"cpus_list":
+ Just like "cpus", only using ranges of CPUs instead of bitmasks.
+
+
+When control is enabled all CTRL_MON groups will also contain:
+
+"schemata":
+ A list of all the resources available to this group.
+ Each resource has its own line and format - see below for details.
+
+"size":
+ Mirrors the display of the "schemata" file to display the size in
+ bytes of each allocation instead of the bits representing the
+ allocation.
+
+"mode":
+ The "mode" of the resource group dictates the sharing of its
+ allocations. A "shareable" resource group allows sharing of its
+ allocations while an "exclusive" resource group does not. A
+ cache pseudo-locked region is created by first writing
+ "pseudo-locksetup" to the "mode" file before writing the cache
+ pseudo-locked region's schemata to the resource group's "schemata"
+ file. On successful pseudo-locked region creation the mode will
+ automatically change to "pseudo-locked".
+
+When monitoring is enabled all MON groups will also contain:
+
+"mon_data":
+ This contains a set of files organized by L3 domain and by
+ RDT event. E.g. on a system with two L3 domains there will
+ be subdirectories "mon_L3_00" and "mon_L3_01". Each of these
+ directories have one file per event (e.g. "llc_occupancy",
+ "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these
+ files provide a read out of the current value of the event for
+ all tasks in the group. In CTRL_MON groups these files provide
+ the sum for all tasks in the CTRL_MON group and all tasks in
+ MON groups. Please see example section for more details on usage.
+
+Resource allocation rules
+-------------------------
+
+When a task is running the following rules define which resources are
+available to it:
+
+1) If the task is a member of a non-default group, then the schemata
+ for that group is used.
+
+2) Else if the task belongs to the default group, but is running on a
+ CPU that is assigned to some specific group, then the schemata for the
+ CPU's group is used.
+
+3) Otherwise the schemata for the default group is used.
+
+Resource monitoring rules
+-------------------------
+1) If a task is a member of a MON group, or non-default CTRL_MON group
+ then RDT events for the task will be reported in that group.
+
+2) If a task is a member of the default CTRL_MON group, but is running
+ on a CPU that is assigned to some specific group, then the RDT events
+ for the task will be reported in that group.
+
+3) Otherwise RDT events for the task will be reported in the root level
+ "mon_data" group.
+
+
+Notes on cache occupancy monitoring and control
+===============================================
+When moving a task from one group to another you should remember that
+this only affects *new* cache allocations by the task. E.g. you may have
+a task in a monitor group showing 3 MB of cache occupancy. If you move
+to a new group and immediately check the occupancy of the old and new
+groups you will likely see that the old group is still showing 3 MB and
+the new group zero. When the task accesses locations still in cache from
+before the move, the h/w does not update any counters. On a busy system
+you will likely see the occupancy in the old group go down as cache lines
+are evicted and re-used while the occupancy in the new group rises as
+the task accesses memory and loads into the cache are counted based on
+membership in the new group.
+
+The same applies to cache allocation control. Moving a task to a group
+with a smaller cache partition will not evict any cache lines. The
+process may continue to use them from the old partition.
+
+Hardware uses CLOSid(Class of service ID) and an RMID(Resource monitoring ID)
+to identify a control group and a monitoring group respectively. Each of
+the resource groups are mapped to these IDs based on the kind of group. The
+number of CLOSid and RMID are limited by the hardware and hence the creation of
+a "CTRL_MON" directory may fail if we run out of either CLOSID or RMID
+and creation of "MON" group may fail if we run out of RMIDs.
+
+max_threshold_occupancy - generic concepts
+------------------------------------------
+
+Note that an RMID once freed may not be immediately available for use as
+the RMID is still tagged the cache lines of the previous user of RMID.
+Hence such RMIDs are placed on limbo list and checked back if the cache
+occupancy has gone down. If there is a time when system has a lot of
+limbo RMIDs but which are not ready to be used, user may see an -EBUSY
+during mkdir.
+
+max_threshold_occupancy is a user configurable value to determine the
+occupancy at which an RMID can be freed.
+
+Schemata files - general concepts
+---------------------------------
+Each line in the file describes one resource. The line starts with
+the name of the resource, followed by specific values to be applied
+in each of the instances of that resource on the system.
+
+Cache IDs
+---------
+On current generation systems there is one L3 cache per socket and L2
+caches are generally just shared by the hyperthreads on a core, but this
+isn't an architectural requirement. We could have multiple separate L3
+caches on a socket, multiple cores could share an L2 cache. So instead
+of using "socket" or "core" to define the set of logical cpus sharing
+a resource we use a "Cache ID". At a given cache level this will be a
+unique number across the whole system (but it isn't guaranteed to be a
+contiguous sequence, there may be gaps). To find the ID for each logical
+CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id
+
+Cache Bit Masks (CBM)
+---------------------
+For cache resources we describe the portion of the cache that is available
+for allocation using a bitmask. The maximum value of the mask is defined
+by each cpu model (and may be different for different cache levels). It
+is found using CPUID, but is also provided in the "info" directory of
+the resctrl file system in "info/{resource}/cbm_mask". Intel hardware
+requires that these masks have all the '1' bits in a contiguous block. So
+0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
+and 0xA are not. On a system with a 20-bit mask each bit represents 5%
+of the capacity of the cache. You could partition the cache into four
+equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000.
+
+Memory bandwidth Allocation and monitoring
+==========================================
+
+For Memory bandwidth resource, by default the user controls the resource
+by indicating the percentage of total memory bandwidth.
+
+The minimum bandwidth percentage value for each cpu model is predefined
+and can be looked up through "info/MB/min_bandwidth". The bandwidth
+granularity that is allocated is also dependent on the cpu model and can
+be looked up at "info/MB/bandwidth_gran". The available bandwidth
+control steps are: min_bw + N * bw_gran. Intermediate values are rounded
+to the next control step available on the hardware.
+
+The bandwidth throttling is a core specific mechanism on some of Intel
+SKUs. Using a high bandwidth and a low bandwidth setting on two threads
+sharing a core may result in both threads being throttled to use the
+low bandwidth (see "thread_throttle_mode").
+
+The fact that Memory bandwidth allocation(MBA) may be a core
+specific mechanism where as memory bandwidth monitoring(MBM) is done at
+the package level may lead to confusion when users try to apply control
+via the MBA and then monitor the bandwidth to see if the controls are
+effective. Below are such scenarios:
+
+1. User may *not* see increase in actual bandwidth when percentage
+ values are increased:
+
+This can occur when aggregate L2 external bandwidth is more than L3
+external bandwidth. Consider an SKL SKU with 24 cores on a package and
+where L2 external is 10GBps (hence aggregate L2 external bandwidth is
+240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20
+threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3
+bandwidth of 100GBps although the percentage value specified is only 50%
+<< 100%. Hence increasing the bandwidth percentage will not yield any
+more bandwidth. This is because although the L2 external bandwidth still
+has capacity, the L3 external bandwidth is fully used. Also note that
+this would be dependent on number of cores the benchmark is run on.
+
+2. Same bandwidth percentage may mean different actual bandwidth
+ depending on # of threads:
+
+For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
+thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
+they have same percentage bandwidth of 10%. This is simply because as
+threads start using more cores in an rdtgroup, the actual bandwidth may
+increase or vary although user specified bandwidth percentage is same.
+
+In order to mitigate this and make the interface more user friendly,
+resctrl added support for specifying the bandwidth in MBps as well. The
+kernel underneath would use a software feedback mechanism or a "Software
+Controller(mba_sc)" which reads the actual bandwidth using MBM counters
+and adjust the memory bandwidth percentages to ensure::
+
+ "actual bandwidth < user specified bandwidth".
+
+By default, the schemata would take the bandwidth percentage values
+where as user can switch to the "MBA software controller" mode using
+a mount option 'mba_MBps'. The schemata format is specified in the below
+sections.
+
+L3 schemata file details (code and data prioritization disabled)
+----------------------------------------------------------------
+With CDP disabled the L3 schemata format is::
+
+ L3:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+L3 schemata file details (CDP enabled via mount option to resctrl)
+------------------------------------------------------------------
+When CDP is enabled L3 control is split into two separate resources
+so you can specify independent masks for code and data like this::
+
+ L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+L2 schemata file details
+------------------------
+CDP is supported at L2 using the 'cdpl2' mount option. The schemata
+format is either::
+
+ L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+or
+
+ L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+
+Memory bandwidth Allocation (default mode)
+------------------------------------------
+
+Memory b/w domain is L3 cache.
+::
+
+ MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
+
+Memory bandwidth Allocation specified in MBps
+---------------------------------------------
+
+Memory bandwidth domain is L3 cache.
+::
+
+ MB:<cache_id0>=bw_MBps0;<cache_id1>=bw_MBps1;...
+
+Reading/writing the schemata file
+---------------------------------
+Reading the schemata file will show the state of all resources
+on all domains. When writing you only need to specify those values
+which you wish to change. E.g.
+::
+
+ # cat schemata
+ L3DATA:0=fffff;1=fffff;2=fffff;3=fffff
+ L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
+ # echo "L3DATA:2=3c0;" > schemata
+ # cat schemata
+ L3DATA:0=fffff;1=fffff;2=3c0;3=fffff
+ L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
+
+Cache Pseudo-Locking
+====================
+CAT enables a user to specify the amount of cache space that an
+application can fill. Cache pseudo-locking builds on the fact that a
+CPU can still read and write data pre-allocated outside its current
+allocated area on a cache hit. With cache pseudo-locking, data can be
+preloaded into a reserved portion of cache that no application can
+fill, and from that point on will only serve cache hits. The cache
+pseudo-locked memory is made accessible to user space where an
+application can map it into its virtual address space and thus have
+a region of memory with reduced average read latency.
+
+The creation of a cache pseudo-locked region is triggered by a request
+from the user to do so that is accompanied by a schemata of the region
+to be pseudo-locked. The cache pseudo-locked region is created as follows:
+
+- Create a CAT allocation CLOSNEW with a CBM matching the schemata
+ from the user of the cache region that will contain the pseudo-locked
+ memory. This region must not overlap with any current CAT allocation/CLOS
+ on the system and no future overlap with this cache region is allowed
+ while the pseudo-locked region exists.
+- Create a contiguous region of memory of the same size as the cache
+ region.
+- Flush the cache, disable hardware prefetchers, disable preemption.
+- Make CLOSNEW the active CLOS and touch the allocated memory to load
+ it into the cache.
+- Set the previous CLOS as active.
+- At this point the closid CLOSNEW can be released - the cache
+ pseudo-locked region is protected as long as its CBM does not appear in
+ any CAT allocation. Even though the cache pseudo-locked region will from
+ this point on not appear in any CBM of any CLOS an application running with
+ any CLOS will be able to access the memory in the pseudo-locked region since
+ the region continues to serve cache hits.
+- The contiguous region of memory loaded into the cache is exposed to
+ user-space as a character device.
+
+Cache pseudo-locking increases the probability that data will remain
+in the cache via carefully configuring the CAT feature and controlling
+application behavior. There is no guarantee that data is placed in
+cache. Instructions like INVD, WBINVD, CLFLUSH, etc. can still evict
+“locked” data from cache. Power management C-states may shrink or
+power off cache. Deeper C-states will automatically be restricted on
+pseudo-locked region creation.
+
+It is required that an application using a pseudo-locked region runs
+with affinity to the cores (or a subset of the cores) associated
+with the cache on which the pseudo-locked region resides. A sanity check
+within the code will not allow an application to map pseudo-locked memory
+unless it runs with affinity to cores associated with the cache on which the
+pseudo-locked region resides. The sanity check is only done during the
+initial mmap() handling, there is no enforcement afterwards and the
+application self needs to ensure it remains affine to the correct cores.
+
+Pseudo-locking is accomplished in two stages:
+
+1) During the first stage the system administrator allocates a portion
+ of cache that should be dedicated to pseudo-locking. At this time an
+ equivalent portion of memory is allocated, loaded into allocated
+ cache portion, and exposed as a character device.
+2) During the second stage a user-space application maps (mmap()) the
+ pseudo-locked memory into its address space.
+
+Cache Pseudo-Locking Interface
+------------------------------
+A pseudo-locked region is created using the resctrl interface as follows:
+
+1) Create a new resource group by creating a new directory in /sys/fs/resctrl.
+2) Change the new resource group's mode to "pseudo-locksetup" by writing
+ "pseudo-locksetup" to the "mode" file.
+3) Write the schemata of the pseudo-locked region to the "schemata" file. All
+ bits within the schemata should be "unused" according to the "bit_usage"
+ file.
+
+On successful pseudo-locked region creation the "mode" file will contain
+"pseudo-locked" and a new character device with the same name as the resource
+group will exist in /dev/pseudo_lock. This character device can be mmap()'ed
+by user space in order to obtain access to the pseudo-locked memory region.
+
+An example of cache pseudo-locked region creation and usage can be found below.
+
+Cache Pseudo-Locking Debugging Interface
+----------------------------------------
+The pseudo-locking debugging interface is enabled by default (if
+CONFIG_DEBUG_FS is enabled) and can be found in /sys/kernel/debug/resctrl.
+
+There is no explicit way for the kernel to test if a provided memory
+location is present in the cache. The pseudo-locking debugging interface uses
+the tracing infrastructure to provide two ways to measure cache residency of
+the pseudo-locked region:
+
+1) Memory access latency using the pseudo_lock_mem_latency tracepoint. Data
+ from these measurements are best visualized using a hist trigger (see
+ example below). In this test the pseudo-locked region is traversed at
+ a stride of 32 bytes while hardware prefetchers and preemption
+ are disabled. This also provides a substitute visualization of cache
+ hits and misses.
+2) Cache hit and miss measurements using model specific precision counters if
+ available. Depending on the levels of cache on the system the pseudo_lock_l2
+ and pseudo_lock_l3 tracepoints are available.
+
+When a pseudo-locked region is created a new debugfs directory is created for
+it in debugfs as /sys/kernel/debug/resctrl/<newdir>. A single
+write-only file, pseudo_lock_measure, is present in this directory. The
+measurement of the pseudo-locked region depends on the number written to this
+debugfs file:
+
+1:
+ writing "1" to the pseudo_lock_measure file will trigger the latency
+ measurement captured in the pseudo_lock_mem_latency tracepoint. See
+ example below.
+2:
+ writing "2" to the pseudo_lock_measure file will trigger the L2 cache
+ residency (cache hits and misses) measurement captured in the
+ pseudo_lock_l2 tracepoint. See example below.
+3:
+ writing "3" to the pseudo_lock_measure file will trigger the L3 cache
+ residency (cache hits and misses) measurement captured in the
+ pseudo_lock_l3 tracepoint.
+
+All measurements are recorded with the tracing infrastructure. This requires
+the relevant tracepoints to be enabled before the measurement is triggered.
+
+Example of latency debugging interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In this example a pseudo-locked region named "newlock" was created. Here is
+how we can measure the latency in cycles of reading from this region and
+visualize this data with a histogram that is available if CONFIG_HIST_TRIGGERS
+is set::
+
+ # :> /sys/kernel/debug/tracing/trace
+ # echo 'hist:keys=latency' > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/trigger
+ # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable
+ # echo 1 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure
+ # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable
+ # cat /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/hist
+
+ # event histogram
+ #
+ # trigger info: hist:keys=latency:vals=hitcount:sort=hitcount:size=2048 [active]
+ #
+
+ { latency: 456 } hitcount: 1
+ { latency: 50 } hitcount: 83
+ { latency: 36 } hitcount: 96
+ { latency: 44 } hitcount: 174
+ { latency: 48 } hitcount: 195
+ { latency: 46 } hitcount: 262
+ { latency: 42 } hitcount: 693
+ { latency: 40 } hitcount: 3204
+ { latency: 38 } hitcount: 3484
+
+ Totals:
+ Hits: 8192
+ Entries: 9
+ Dropped: 0
+
+Example of cache hits/misses debugging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In this example a pseudo-locked region named "newlock" was created on the L2
+cache of a platform. Here is how we can obtain details of the cache hits
+and misses using the platform's precision counters.
+::
+
+ # :> /sys/kernel/debug/tracing/trace
+ # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable
+ # echo 2 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure
+ # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable
+ # cat /sys/kernel/debug/tracing/trace
+
+ # tracer: nop
+ #
+ # _-----=> irqs-off
+ # / _----=> need-resched
+ # | / _---=> hardirq/softirq
+ # || / _--=> preempt-depth
+ # ||| / delay
+ # TASK-PID CPU# |||| TIMESTAMP FUNCTION
+ # | | | |||| | |
+ pseudo_lock_mea-1672 [002] .... 3132.860500: pseudo_lock_l2: hits=4097 miss=0
+
+
+Examples for RDT allocation usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1) Example 1
+
+On a two socket machine (one L3 cache per socket) with just four bits
+for cache bit masks, minimum b/w of 10% with a memory bandwidth
+granularity of 10%.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p0 p1
+ # echo "L3:0=3;1=c\nMB:0=50;1=50" > /sys/fs/resctrl/p0/schemata
+ # echo "L3:0=3;1=3\nMB:0=50;1=50" > /sys/fs/resctrl/p1/schemata
+
+The default resource group is unmodified, so we have access to all parts
+of all caches (its schemata file reads "L3:0=f;1=f").
+
+Tasks that are under the control of group "p0" may only allocate from the
+"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
+Tasks in group "p1" use the "lower" 50% of cache on both sockets.
+
+Similarly, tasks that are under the control of group "p0" may use a
+maximum memory b/w of 50% on socket0 and 50% on socket 1.
+Tasks in group "p1" may also use 50% memory b/w on both sockets.
+Note that unlike cache masks, memory b/w cannot specify whether these
+allocations can overlap or not. The allocations specifies the maximum
+b/w that the group may be able to use and the system admin can configure
+the b/w accordingly.
+
+If resctrl is using the software controller (mba_sc) then user can enter the
+max b/w in MB rather than the percentage values.
+::
+
+ # echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata
+ # echo "L3:0=3;1=3\nMB:0=1024;1=500" > /sys/fs/resctrl/p1/schemata
+
+In the above example the tasks in "p1" and "p0" on socket 0 would use a max b/w
+of 1024MB where as on socket 1 they would use 500MB.
+
+2) Example 2
+
+Again two sockets, but this time with a more realistic 20-bit mask.
+
+Two real time tasks pid=1234 running on processor 0 and pid=5678 running on
+processor 1 on socket 0 on a 2-socket and dual core machine. To avoid noisy
+neighbors, each of the two real-time tasks exclusively occupies one quarter
+of L3 cache on socket 0.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+
+First we reset the schemata for the default group so that the "upper"
+50% of the L3 cache on socket 0 and 50% of memory b/w cannot be used by
+ordinary tasks::
+
+ # echo "L3:0=3ff;1=fffff\nMB:0=50;1=100" > schemata
+
+Next we make a resource group for our first real time task and give
+it access to the "top" 25% of the cache on socket 0.
+::
+
+ # mkdir p0
+ # echo "L3:0=f8000;1=fffff" > p0/schemata
+
+Finally we move our first real time task into this resource group. We
+also use taskset(1) to ensure the task always runs on a dedicated CPU
+on socket 0. Most uses of resource groups will also constrain which
+processors tasks run on.
+::
+
+ # echo 1234 > p0/tasks
+ # taskset -cp 1 1234
+
+Ditto for the second real time task (with the remaining 25% of cache)::
+
+ # mkdir p1
+ # echo "L3:0=7c00;1=fffff" > p1/schemata
+ # echo 5678 > p1/tasks
+ # taskset -cp 2 5678
+
+For the same 2 socket system with memory b/w resource and CAT L3 the
+schemata would look like(Assume min_bandwidth 10 and bandwidth_gran is
+10):
+
+For our first real time task this would request 20% memory b/w on socket 0.
+::
+
+ # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
+
+For our second real time task this would request an other 20% memory b/w
+on socket 0.
+::
+
+ # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
+
+3) Example 3
+
+A single socket system which has real-time tasks running on core 4-7 and
+non real-time workload assigned to core 0-3. The real-time tasks share text
+and data, so a per task association is not required and due to interaction
+with the kernel it's desired that the kernel on these cores shares L3 with
+the tasks.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+
+First we reset the schemata for the default group so that the "upper"
+50% of the L3 cache on socket 0, and 50% of memory bandwidth on socket 0
+cannot be used by ordinary tasks::
+
+ # echo "L3:0=3ff\nMB:0=50" > schemata
+
+Next we make a resource group for our real time cores and give it access
+to the "top" 50% of the cache on socket 0 and 50% of memory bandwidth on
+socket 0.
+::
+
+ # mkdir p0
+ # echo "L3:0=ffc00\nMB:0=50" > p0/schemata
+
+Finally we move core 4-7 over to the new group and make sure that the
+kernel and the tasks running there get 50% of the cache. They should
+also get 50% of memory bandwidth assuming that the cores 4-7 are SMT
+siblings and only the real time threads are scheduled on the cores 4-7.
+::
+
+ # echo F0 > p0/cpus
+
+4) Example 4
+
+The resource groups in previous examples were all in the default "shareable"
+mode allowing sharing of their cache allocations. If one resource group
+configures a cache allocation then nothing prevents another resource group
+to overlap with that allocation.
+
+In this example a new exclusive resource group will be created on a L2 CAT
+system with two L2 cache instances that can be configured with an 8-bit
+capacity bitmask. The new exclusive resource group will be configured to use
+25% of each cache instance.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl/
+ # cd /sys/fs/resctrl
+
+First, we observe that the default group is configured to allocate to all L2
+cache::
+
+ # cat schemata
+ L2:0=ff;1=ff
+
+We could attempt to create the new resource group at this point, but it will
+fail because of the overlap with the schemata of the default group::
+
+ # mkdir p0
+ # echo 'L2:0=0x3;1=0x3' > p0/schemata
+ # cat p0/mode
+ shareable
+ # echo exclusive > p0/mode
+ -sh: echo: write error: Invalid argument
+ # cat info/last_cmd_status
+ schemata overlaps
+
+To ensure that there is no overlap with another resource group the default
+resource group's schemata has to change, making it possible for the new
+resource group to become exclusive.
+::
+
+ # echo 'L2:0=0xfc;1=0xfc' > schemata
+ # echo exclusive > p0/mode
+ # grep . p0/*
+ p0/cpus:0
+ p0/mode:exclusive
+ p0/schemata:L2:0=03;1=03
+ p0/size:L2:0=262144;1=262144
+
+A new resource group will on creation not overlap with an exclusive resource
+group::
+
+ # mkdir p1
+ # grep . p1/*
+ p1/cpus:0
+ p1/mode:shareable
+ p1/schemata:L2:0=fc;1=fc
+ p1/size:L2:0=786432;1=786432
+
+The bit_usage will reflect how the cache is used::
+
+ # cat info/L2/bit_usage
+ 0=SSSSSSEE;1=SSSSSSEE
+
+A resource group cannot be forced to overlap with an exclusive resource group::
+
+ # echo 'L2:0=0x1;1=0x1' > p1/schemata
+ -sh: echo: write error: Invalid argument
+ # cat info/last_cmd_status
+ overlaps with exclusive group
+
+Example of Cache Pseudo-Locking
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Lock portion of L2 cache from cache id 1 using CBM 0x3. Pseudo-locked
+region is exposed at /dev/pseudo_lock/newlock that can be provided to
+application for argument to mmap().
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl/
+ # cd /sys/fs/resctrl
+
+Ensure that there are bits available that can be pseudo-locked, since only
+unused bits can be pseudo-locked the bits to be pseudo-locked needs to be
+removed from the default resource group's schemata::
+
+ # cat info/L2/bit_usage
+ 0=SSSSSSSS;1=SSSSSSSS
+ # echo 'L2:1=0xfc' > schemata
+ # cat info/L2/bit_usage
+ 0=SSSSSSSS;1=SSSSSS00
+
+Create a new resource group that will be associated with the pseudo-locked
+region, indicate that it will be used for a pseudo-locked region, and
+configure the requested pseudo-locked region capacity bitmask::
+
+ # mkdir newlock
+ # echo pseudo-locksetup > newlock/mode
+ # echo 'L2:1=0x3' > newlock/schemata
+
+On success the resource group's mode will change to pseudo-locked, the
+bit_usage will reflect the pseudo-locked region, and the character device
+exposing the pseudo-locked region will exist::
+
+ # cat newlock/mode
+ pseudo-locked
+ # cat info/L2/bit_usage
+ 0=SSSSSSSS;1=SSSSSSPP
+ # ls -l /dev/pseudo_lock/newlock
+ crw------- 1 root root 243, 0 Apr 3 05:01 /dev/pseudo_lock/newlock
+
+::
+
+ /*
+ * Example code to access one page of pseudo-locked cache region
+ * from user space.
+ */
+ #define _GNU_SOURCE
+ #include <fcntl.h>
+ #include <sched.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <unistd.h>
+ #include <sys/mman.h>
+
+ /*
+ * It is required that the application runs with affinity to only
+ * cores associated with the pseudo-locked region. Here the cpu
+ * is hardcoded for convenience of example.
+ */
+ static int cpuid = 2;
+
+ int main(int argc, char *argv[])
+ {
+ cpu_set_t cpuset;
+ long page_size;
+ void *mapping;
+ int dev_fd;
+ int ret;
+
+ page_size = sysconf(_SC_PAGESIZE);
+
+ CPU_ZERO(&cpuset);
+ CPU_SET(cpuid, &cpuset);
+ ret = sched_setaffinity(0, sizeof(cpuset), &cpuset);
+ if (ret < 0) {
+ perror("sched_setaffinity");
+ exit(EXIT_FAILURE);
+ }
+
+ dev_fd = open("/dev/pseudo_lock/newlock", O_RDWR);
+ if (dev_fd < 0) {
+ perror("open");
+ exit(EXIT_FAILURE);
+ }
+
+ mapping = mmap(0, page_size, PROT_READ | PROT_WRITE, MAP_SHARED,
+ dev_fd, 0);
+ if (mapping == MAP_FAILED) {
+ perror("mmap");
+ close(dev_fd);
+ exit(EXIT_FAILURE);
+ }
+
+ /* Application interacts with pseudo-locked memory @mapping */
+
+ ret = munmap(mapping, page_size);
+ if (ret < 0) {
+ perror("munmap");
+ close(dev_fd);
+ exit(EXIT_FAILURE);
+ }
+
+ close(dev_fd);
+ exit(EXIT_SUCCESS);
+ }
+
+Locking between applications
+----------------------------
+
+Certain operations on the resctrl filesystem, composed of read/writes
+to/from multiple files, must be atomic.
+
+As an example, the allocation of an exclusive reservation of L3 cache
+involves:
+
+ 1. Read the cbmmasks from each directory or the per-resource "bit_usage"
+ 2. Find a contiguous set of bits in the global CBM bitmask that is clear
+ in any of the directory cbmmasks
+ 3. Create a new directory
+ 4. Set the bits found in step 2 to the new directory "schemata" file
+
+If two applications attempt to allocate space concurrently then they can
+end up allocating the same bits so the reservations are shared instead of
+exclusive.
+
+To coordinate atomic operations on the resctrlfs and to avoid the problem
+above, the following locking procedure is recommended:
+
+Locking is based on flock, which is available in libc and also as a shell
+script command
+
+Write lock:
+
+ A) Take flock(LOCK_EX) on /sys/fs/resctrl
+ B) Read/write the directory structure.
+ C) funlock
+
+Read lock:
+
+ A) Take flock(LOCK_SH) on /sys/fs/resctrl
+ B) If success read the directory structure.
+ C) funlock
+
+Example with bash::
+
+ # Atomically read directory structure
+ $ flock -s /sys/fs/resctrl/ find /sys/fs/resctrl
+
+ # Read directory contents and create new subdirectory
+
+ $ cat create-dir.sh
+ find /sys/fs/resctrl/ > output.txt
+ mask = function-of(output.txt)
+ mkdir /sys/fs/resctrl/newres/
+ echo mask > /sys/fs/resctrl/newres/schemata
+
+ $ flock /sys/fs/resctrl/ ./create-dir.sh
+
+Example with C::
+
+ /*
+ * Example code do take advisory locks
+ * before accessing resctrl filesystem
+ */
+ #include <sys/file.h>
+ #include <stdlib.h>
+
+ void resctrl_take_shared_lock(int fd)
+ {
+ int ret;
+
+ /* take shared lock on resctrl filesystem */
+ ret = flock(fd, LOCK_SH);
+ if (ret) {
+ perror("flock");
+ exit(-1);
+ }
+ }
+
+ void resctrl_take_exclusive_lock(int fd)
+ {
+ int ret;
+
+ /* release lock on resctrl filesystem */
+ ret = flock(fd, LOCK_EX);
+ if (ret) {
+ perror("flock");
+ exit(-1);
+ }
+ }
+
+ void resctrl_release_lock(int fd)
+ {
+ int ret;
+
+ /* take shared lock on resctrl filesystem */
+ ret = flock(fd, LOCK_UN);
+ if (ret) {
+ perror("flock");
+ exit(-1);
+ }
+ }
+
+ void main(void)
+ {
+ int fd, ret;
+
+ fd = open("/sys/fs/resctrl", O_DIRECTORY);
+ if (fd == -1) {
+ perror("open");
+ exit(-1);
+ }
+ resctrl_take_shared_lock(fd);
+ /* code to read directory contents */
+ resctrl_release_lock(fd);
+
+ resctrl_take_exclusive_lock(fd);
+ /* code to read and write directory contents */
+ resctrl_release_lock(fd);
+ }
+
+Examples for RDT Monitoring along with allocation usage
+=======================================================
+Reading monitored data
+----------------------
+Reading an event file (for ex: mon_data/mon_L3_00/llc_occupancy) would
+show the current snapshot of LLC occupancy of the corresponding MON
+group or CTRL_MON group.
+
+
+Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group)
+------------------------------------------------------------------------
+On a two socket machine (one L3 cache per socket) with just four bits
+for cache bit masks::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p0 p1
+ # echo "L3:0=3;1=c" > /sys/fs/resctrl/p0/schemata
+ # echo "L3:0=3;1=3" > /sys/fs/resctrl/p1/schemata
+ # echo 5678 > p1/tasks
+ # echo 5679 > p1/tasks
+
+The default resource group is unmodified, so we have access to all parts
+of all caches (its schemata file reads "L3:0=f;1=f").
+
+Tasks that are under the control of group "p0" may only allocate from the
+"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
+Tasks in group "p1" use the "lower" 50% of cache on both sockets.
+
+Create monitor groups and assign a subset of tasks to each monitor group.
+::
+
+ # cd /sys/fs/resctrl/p1/mon_groups
+ # mkdir m11 m12
+ # echo 5678 > m11/tasks
+ # echo 5679 > m12/tasks
+
+fetch data (data shown in bytes)
+::
+
+ # cat m11/mon_data/mon_L3_00/llc_occupancy
+ 16234000
+ # cat m11/mon_data/mon_L3_01/llc_occupancy
+ 14789000
+ # cat m12/mon_data/mon_L3_00/llc_occupancy
+ 16789000
+
+The parent ctrl_mon group shows the aggregated data.
+::
+
+ # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy
+ 31234000
+
+Example 2 (Monitor a task from its creation)
+--------------------------------------------
+On a two socket machine (one L3 cache per socket)::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p0 p1
+
+An RMID is allocated to the group once its created and hence the <cmd>
+below is monitored from its creation.
+::
+
+ # echo $$ > /sys/fs/resctrl/p1/tasks
+ # <cmd>
+
+Fetch the data::
+
+ # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy
+ 31789000
+
+Example 3 (Monitor without CAT support or before creating CAT groups)
+---------------------------------------------------------------------
+
+Assume a system like HSW has only CQM and no CAT support. In this case
+the resctrl will still mount but cannot create CTRL_MON directories.
+But user can create different MON groups within the root group thereby
+able to monitor all tasks including kernel threads.
+
+This can also be used to profile jobs cache size footprint before being
+able to allocate them to different allocation groups.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir mon_groups/m01
+ # mkdir mon_groups/m02
+
+ # echo 3478 > /sys/fs/resctrl/mon_groups/m01/tasks
+ # echo 2467 > /sys/fs/resctrl/mon_groups/m02/tasks
+
+Monitor the groups separately and also get per domain data. From the
+below its apparent that the tasks are mostly doing work on
+domain(socket) 0.
+::
+
+ # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_00/llc_occupancy
+ 31234000
+ # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_01/llc_occupancy
+ 34555
+ # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_00/llc_occupancy
+ 31234000
+ # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_01/llc_occupancy
+ 32789
+
+
+Example 4 (Monitor real time tasks)
+-----------------------------------
+
+A single socket system which has real time tasks running on cores 4-7
+and non real time tasks on other cpus. We want to monitor the cache
+occupancy of the real time threads on these cores.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p1
+
+Move the cpus 4-7 over to p1::
+
+ # echo f0 > p1/cpus
+
+View the llc occupancy snapshot::
+
+ # cat /sys/fs/resctrl/p1/mon_data/mon_L3_00/llc_occupancy
+ 11234000
+
+Intel RDT Errata
+================
+
+Intel MBM Counters May Report System Memory Bandwidth Incorrectly
+-----------------------------------------------------------------
+
+Errata SKX99 for Skylake server and BDF102 for Broadwell server.
+
+Problem: Intel Memory Bandwidth Monitoring (MBM) counters track metrics
+according to the assigned Resource Monitor ID (RMID) for that logical
+core. The IA32_QM_CTR register (MSR 0xC8E), used to report these
+metrics, may report incorrect system bandwidth for certain RMID values.
+
+Implication: Due to the errata, system memory bandwidth may not match
+what is reported.
+
+Workaround: MBM total and local readings are corrected according to the
+following correction factor table:
+
++---------------+---------------+---------------+-----------------+
+|core count |rmid count |rmid threshold |correction factor|
++---------------+---------------+---------------+-----------------+
+|1 |8 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|2 |16 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|3 |24 |15 |0.969650 |
++---------------+---------------+---------------+-----------------+
+|4 |32 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|6 |48 |31 |0.969650 |
++---------------+---------------+---------------+-----------------+
+|7 |56 |47 |1.142857 |
++---------------+---------------+---------------+-----------------+
+|8 |64 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|9 |72 |63 |1.185115 |
++---------------+---------------+---------------+-----------------+
+|10 |80 |63 |1.066553 |
++---------------+---------------+---------------+-----------------+
+|11 |88 |79 |1.454545 |
++---------------+---------------+---------------+-----------------+
+|12 |96 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|13 |104 |95 |1.230769 |
++---------------+---------------+---------------+-----------------+
+|14 |112 |95 |1.142857 |
++---------------+---------------+---------------+-----------------+
+|15 |120 |95 |1.066667 |
++---------------+---------------+---------------+-----------------+
+|16 |128 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|17 |136 |127 |1.254863 |
++---------------+---------------+---------------+-----------------+
+|18 |144 |127 |1.185255 |
++---------------+---------------+---------------+-----------------+
+|19 |152 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|20 |160 |127 |1.066667 |
++---------------+---------------+---------------+-----------------+
+|21 |168 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|22 |176 |159 |1.454334 |
++---------------+---------------+---------------+-----------------+
+|23 |184 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|24 |192 |127 |0.969744 |
++---------------+---------------+---------------+-----------------+
+|25 |200 |191 |1.280246 |
++---------------+---------------+---------------+-----------------+
+|26 |208 |191 |1.230921 |
++---------------+---------------+---------------+-----------------+
+|27 |216 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|28 |224 |191 |1.143118 |
++---------------+---------------+---------------+-----------------+
+
+If rmid > rmid threshold, MBM total and local values should be multiplied
+by the correction factor.
+
+See:
+
+1. Erratum SKX99 in Intel Xeon Processor Scalable Family Specification Update:
+http://web.archive.org/web/20200716124958/https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html
+
+2. Erratum BDF102 in Intel Xeon E5-2600 v4 Processor Product Family Specification Update:
+http://web.archive.org/web/20191125200531/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v4-spec-update.pdf
+
+3. The errata in Intel Resource Director Technology (Intel RDT) on 2nd Generation Intel Xeon Scalable Processors Reference Manual:
+https://software.intel.com/content/www/us/en/develop/articles/intel-resource-director-technology-rdt-reference-manual.html
+
+for further information.
diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst
deleted file mode 100644
index e59b7b9..0000000
--- a/Documentation/x86/resctrl_ui.rst
+++ /dev/null
@@ -1,1211 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-.. include:: <isonum.txt>
-
-===========================================
-User Interface for Resource Control feature
-===========================================
-
-:Copyright: |copy| 2016 Intel Corporation
-:Authors: - Fenghua Yu <fenghua.yu@intel.com>
- - Tony Luck <tony.luck@intel.com>
- - Vikas Shivappa <vikas.shivappa@intel.com>
-
-
-Intel refers to this feature as Intel Resource Director Technology(Intel(R) RDT).
-AMD refers to this feature as AMD Platform Quality of Service(AMD QoS).
-
-This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
-flag bits:
-
-============================================= ================================
-RDT (Resource Director Technology) Allocation "rdt_a"
-CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
-CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
-CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
-MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
-MBA (Memory Bandwidth Allocation) "mba"
-============================================= ================================
-
-To use the feature mount the file system::
-
- # mount -t resctrl resctrl [-o cdp[,cdpl2][,mba_MBps]] /sys/fs/resctrl
-
-mount options are:
-
-"cdp":
- Enable code/data prioritization in L3 cache allocations.
-"cdpl2":
- Enable code/data prioritization in L2 cache allocations.
-"mba_MBps":
- Enable the MBA Software Controller(mba_sc) to specify MBA
- bandwidth in MBps
-
-L2 and L3 CDP are controlled separately.
-
-RDT features are orthogonal. A particular system may support only
-monitoring, only control, or both monitoring and control. Cache
-pseudo-locking is a unique way of using cache control to "pin" or
-"lock" data in the cache. Details can be found in
-"Cache Pseudo-Locking".
-
-
-The mount succeeds if either of allocation or monitoring is present, but
-only those files and directories supported by the system will be created.
-For more details on the behavior of the interface during monitoring
-and allocation, see the "Resource alloc and monitor groups" section.
-
-Info directory
-==============
-
-The 'info' directory contains information about the enabled
-resources. Each resource has its own subdirectory. The subdirectory
-names reflect the resource names.
-
-Each subdirectory contains the following files with respect to
-allocation:
-
-Cache resource(L3/L2) subdirectory contains the following files
-related to allocation:
-
-"num_closids":
- The number of CLOSIDs which are valid for this
- resource. The kernel uses the smallest number of
- CLOSIDs of all enabled resources as limit.
-"cbm_mask":
- The bitmask which is valid for this resource.
- This mask is equivalent to 100%.
-"min_cbm_bits":
- The minimum number of consecutive bits which
- must be set when writing a mask.
-
-"shareable_bits":
- Bitmask of shareable resource with other executing
- entities (e.g. I/O). User can use this when
- setting up exclusive cache partitions. Note that
- some platforms support devices that have their
- own settings for cache use which can over-ride
- these bits.
-"bit_usage":
- Annotated capacity bitmasks showing how all
- instances of the resource are used. The legend is:
-
- "0":
- Corresponding region is unused. When the system's
- resources have been allocated and a "0" is found
- in "bit_usage" it is a sign that resources are
- wasted.
-
- "H":
- Corresponding region is used by hardware only
- but available for software use. If a resource
- has bits set in "shareable_bits" but not all
- of these bits appear in the resource groups'
- schematas then the bits appearing in
- "shareable_bits" but no resource group will
- be marked as "H".
- "X":
- Corresponding region is available for sharing and
- used by hardware and software. These are the
- bits that appear in "shareable_bits" as
- well as a resource group's allocation.
- "S":
- Corresponding region is used by software
- and available for sharing.
- "E":
- Corresponding region is used exclusively by
- one resource group. No sharing allowed.
- "P":
- Corresponding region is pseudo-locked. No
- sharing allowed.
-
-Memory bandwidth(MB) subdirectory contains the following files
-with respect to allocation:
-
-"min_bandwidth":
- The minimum memory bandwidth percentage which
- user can request.
-
-"bandwidth_gran":
- The granularity in which the memory bandwidth
- percentage is allocated. The allocated
- b/w percentage is rounded off to the next
- control step available on the hardware. The
- available bandwidth control steps are:
- min_bandwidth + N * bandwidth_gran.
-
-"delay_linear":
- Indicates if the delay scale is linear or
- non-linear. This field is purely informational
- only.
-
-"thread_throttle_mode":
- Indicator on Intel systems of how tasks running on threads
- of a physical core are throttled in cases where they
- request different memory bandwidth percentages:
-
- "max":
- the smallest percentage is applied
- to all threads
- "per-thread":
- bandwidth percentages are directly applied to
- the threads running on the core
-
-If RDT monitoring is available there will be an "L3_MON" directory
-with the following files:
-
-"num_rmids":
- The number of RMIDs available. This is the
- upper bound for how many "CTRL_MON" + "MON"
- groups can be created.
-
-"mon_features":
- Lists the monitoring events if
- monitoring is enabled for the resource.
-
-"max_threshold_occupancy":
- Read/write file provides the largest value (in
- bytes) at which a previously used LLC_occupancy
- counter can be considered for re-use.
-
-Finally, in the top level of the "info" directory there is a file
-named "last_cmd_status". This is reset with every "command" issued
-via the file system (making new directories or writing to any of the
-control files). If the command was successful, it will read as "ok".
-If the command failed, it will provide more information that can be
-conveyed in the error returns from file operations. E.g.
-::
-
- # echo L3:0=f7 > schemata
- bash: echo: write error: Invalid argument
- # cat info/last_cmd_status
- mask f7 has non-consecutive 1-bits
-
-Resource alloc and monitor groups
-=================================
-
-Resource groups are represented as directories in the resctrl file
-system. The default group is the root directory which, immediately
-after mounting, owns all the tasks and cpus in the system and can make
-full use of all resources.
-
-On a system with RDT control features additional directories can be
-created in the root directory that specify different amounts of each
-resource (see "schemata" below). The root and these additional top level
-directories are referred to as "CTRL_MON" groups below.
-
-On a system with RDT monitoring the root directory and other top level
-directories contain a directory named "mon_groups" in which additional
-directories can be created to monitor subsets of tasks in the CTRL_MON
-group that is their ancestor. These are called "MON" groups in the rest
-of this document.
-
-Removing a directory will move all tasks and cpus owned by the group it
-represents to the parent. Removing one of the created CTRL_MON groups
-will automatically remove all MON groups below it.
-
-All groups contain the following files:
-
-"tasks":
- Reading this file shows the list of all tasks that belong to
- this group. Writing a task id to the file will add a task to the
- group. If the group is a CTRL_MON group the task is removed from
- whichever previous CTRL_MON group owned the task and also from
- any MON group that owned the task. If the group is a MON group,
- then the task must already belong to the CTRL_MON parent of this
- group. The task is removed from any previous MON group.
-
-
-"cpus":
- Reading this file shows a bitmask of the logical CPUs owned by
- this group. Writing a mask to this file will add and remove
- CPUs to/from this group. As with the tasks file a hierarchy is
- maintained where MON groups may only include CPUs owned by the
- parent CTRL_MON group.
- When the resource group is in pseudo-locked mode this file will
- only be readable, reflecting the CPUs associated with the
- pseudo-locked region.
-
-
-"cpus_list":
- Just like "cpus", only using ranges of CPUs instead of bitmasks.
-
-
-When control is enabled all CTRL_MON groups will also contain:
-
-"schemata":
- A list of all the resources available to this group.
- Each resource has its own line and format - see below for details.
-
-"size":
- Mirrors the display of the "schemata" file to display the size in
- bytes of each allocation instead of the bits representing the
- allocation.
-
-"mode":
- The "mode" of the resource group dictates the sharing of its
- allocations. A "shareable" resource group allows sharing of its
- allocations while an "exclusive" resource group does not. A
- cache pseudo-locked region is created by first writing
- "pseudo-locksetup" to the "mode" file before writing the cache
- pseudo-locked region's schemata to the resource group's "schemata"
- file. On successful pseudo-locked region creation the mode will
- automatically change to "pseudo-locked".
-
-When monitoring is enabled all MON groups will also contain:
-
-"mon_data":
- This contains a set of files organized by L3 domain and by
- RDT event. E.g. on a system with two L3 domains there will
- be subdirectories "mon_L3_00" and "mon_L3_01". Each of these
- directories have one file per event (e.g. "llc_occupancy",
- "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these
- files provide a read out of the current value of the event for
- all tasks in the group. In CTRL_MON groups these files provide
- the sum for all tasks in the CTRL_MON group and all tasks in
- MON groups. Please see example section for more details on usage.
-
-Resource allocation rules
--------------------------
-
-When a task is running the following rules define which resources are
-available to it:
-
-1) If the task is a member of a non-default group, then the schemata
- for that group is used.
-
-2) Else if the task belongs to the default group, but is running on a
- CPU that is assigned to some specific group, then the schemata for the
- CPU's group is used.
-
-3) Otherwise the schemata for the default group is used.
-
-Resource monitoring rules
--------------------------
-1) If a task is a member of a MON group, or non-default CTRL_MON group
- then RDT events for the task will be reported in that group.
-
-2) If a task is a member of the default CTRL_MON group, but is running
- on a CPU that is assigned to some specific group, then the RDT events
- for the task will be reported in that group.
-
-3) Otherwise RDT events for the task will be reported in the root level
- "mon_data" group.
-
-
-Notes on cache occupancy monitoring and control
-===============================================
-When moving a task from one group to another you should remember that
-this only affects *new* cache allocations by the task. E.g. you may have
-a task in a monitor group showing 3 MB of cache occupancy. If you move
-to a new group and immediately check the occupancy of the old and new
-groups you will likely see that the old group is still showing 3 MB and
-the new group zero. When the task accesses locations still in cache from
-before the move, the h/w does not update any counters. On a busy system
-you will likely see the occupancy in the old group go down as cache lines
-are evicted and re-used while the occupancy in the new group rises as
-the task accesses memory and loads into the cache are counted based on
-membership in the new group.
-
-The same applies to cache allocation control. Moving a task to a group
-with a smaller cache partition will not evict any cache lines. The
-process may continue to use them from the old partition.
-
-Hardware uses CLOSid(Class of service ID) and an RMID(Resource monitoring ID)
-to identify a control group and a monitoring group respectively. Each of
-the resource groups are mapped to these IDs based on the kind of group. The
-number of CLOSid and RMID are limited by the hardware and hence the creation of
-a "CTRL_MON" directory may fail if we run out of either CLOSID or RMID
-and creation of "MON" group may fail if we run out of RMIDs.
-
-max_threshold_occupancy - generic concepts
-------------------------------------------
-
-Note that an RMID once freed may not be immediately available for use as
-the RMID is still tagged the cache lines of the previous user of RMID.
-Hence such RMIDs are placed on limbo list and checked back if the cache
-occupancy has gone down. If there is a time when system has a lot of
-limbo RMIDs but which are not ready to be used, user may see an -EBUSY
-during mkdir.
-
-max_threshold_occupancy is a user configurable value to determine the
-occupancy at which an RMID can be freed.
-
-Schemata files - general concepts
----------------------------------
-Each line in the file describes one resource. The line starts with
-the name of the resource, followed by specific values to be applied
-in each of the instances of that resource on the system.
-
-Cache IDs
----------
-On current generation systems there is one L3 cache per socket and L2
-caches are generally just shared by the hyperthreads on a core, but this
-isn't an architectural requirement. We could have multiple separate L3
-caches on a socket, multiple cores could share an L2 cache. So instead
-of using "socket" or "core" to define the set of logical cpus sharing
-a resource we use a "Cache ID". At a given cache level this will be a
-unique number across the whole system (but it isn't guaranteed to be a
-contiguous sequence, there may be gaps). To find the ID for each logical
-CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id
-
-Cache Bit Masks (CBM)
----------------------
-For cache resources we describe the portion of the cache that is available
-for allocation using a bitmask. The maximum value of the mask is defined
-by each cpu model (and may be different for different cache levels). It
-is found using CPUID, but is also provided in the "info" directory of
-the resctrl file system in "info/{resource}/cbm_mask". Intel hardware
-requires that these masks have all the '1' bits in a contiguous block. So
-0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
-and 0xA are not. On a system with a 20-bit mask each bit represents 5%
-of the capacity of the cache. You could partition the cache into four
-equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000.
-
-Memory bandwidth Allocation and monitoring
-==========================================
-
-For Memory bandwidth resource, by default the user controls the resource
-by indicating the percentage of total memory bandwidth.
-
-The minimum bandwidth percentage value for each cpu model is predefined
-and can be looked up through "info/MB/min_bandwidth". The bandwidth
-granularity that is allocated is also dependent on the cpu model and can
-be looked up at "info/MB/bandwidth_gran". The available bandwidth
-control steps are: min_bw + N * bw_gran. Intermediate values are rounded
-to the next control step available on the hardware.
-
-The bandwidth throttling is a core specific mechanism on some of Intel
-SKUs. Using a high bandwidth and a low bandwidth setting on two threads
-sharing a core may result in both threads being throttled to use the
-low bandwidth (see "thread_throttle_mode").
-
-The fact that Memory bandwidth allocation(MBA) may be a core
-specific mechanism where as memory bandwidth monitoring(MBM) is done at
-the package level may lead to confusion when users try to apply control
-via the MBA and then monitor the bandwidth to see if the controls are
-effective. Below are such scenarios:
-
-1. User may *not* see increase in actual bandwidth when percentage
- values are increased:
-
-This can occur when aggregate L2 external bandwidth is more than L3
-external bandwidth. Consider an SKL SKU with 24 cores on a package and
-where L2 external is 10GBps (hence aggregate L2 external bandwidth is
-240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20
-threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3
-bandwidth of 100GBps although the percentage value specified is only 50%
-<< 100%. Hence increasing the bandwidth percentage will not yield any
-more bandwidth. This is because although the L2 external bandwidth still
-has capacity, the L3 external bandwidth is fully used. Also note that
-this would be dependent on number of cores the benchmark is run on.
-
-2. Same bandwidth percentage may mean different actual bandwidth
- depending on # of threads:
-
-For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
-thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although
-they have same percentage bandwidth of 10%. This is simply because as
-threads start using more cores in an rdtgroup, the actual bandwidth may
-increase or vary although user specified bandwidth percentage is same.
-
-In order to mitigate this and make the interface more user friendly,
-resctrl added support for specifying the bandwidth in MBps as well. The
-kernel underneath would use a software feedback mechanism or a "Software
-Controller(mba_sc)" which reads the actual bandwidth using MBM counters
-and adjust the memory bandwidth percentages to ensure::
-
- "actual bandwidth < user specified bandwidth".
-
-By default, the schemata would take the bandwidth percentage values
-where as user can switch to the "MBA software controller" mode using
-a mount option 'mba_MBps'. The schemata format is specified in the below
-sections.
-
-L3 schemata file details (code and data prioritization disabled)
-----------------------------------------------------------------
-With CDP disabled the L3 schemata format is::
-
- L3:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
-
-L3 schemata file details (CDP enabled via mount option to resctrl)
-------------------------------------------------------------------
-When CDP is enabled L3 control is split into two separate resources
-so you can specify independent masks for code and data like this::
-
- L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
- L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
-
-L2 schemata file details
-------------------------
-CDP is supported at L2 using the 'cdpl2' mount option. The schemata
-format is either::
-
- L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
-
-or
-
- L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
- L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
-
-
-Memory bandwidth Allocation (default mode)
-------------------------------------------
-
-Memory b/w domain is L3 cache.
-::
-
- MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
-
-Memory bandwidth Allocation specified in MBps
----------------------------------------------
-
-Memory bandwidth domain is L3 cache.
-::
-
- MB:<cache_id0>=bw_MBps0;<cache_id1>=bw_MBps1;...
-
-Reading/writing the schemata file
----------------------------------
-Reading the schemata file will show the state of all resources
-on all domains. When writing you only need to specify those values
-which you wish to change. E.g.
-::
-
- # cat schemata
- L3DATA:0=fffff;1=fffff;2=fffff;3=fffff
- L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
- # echo "L3DATA:2=3c0;" > schemata
- # cat schemata
- L3DATA:0=fffff;1=fffff;2=3c0;3=fffff
- L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
-
-Cache Pseudo-Locking
-====================
-CAT enables a user to specify the amount of cache space that an
-application can fill. Cache pseudo-locking builds on the fact that a
-CPU can still read and write data pre-allocated outside its current
-allocated area on a cache hit. With cache pseudo-locking, data can be
-preloaded into a reserved portion of cache that no application can
-fill, and from that point on will only serve cache hits. The cache
-pseudo-locked memory is made accessible to user space where an
-application can map it into its virtual address space and thus have
-a region of memory with reduced average read latency.
-
-The creation of a cache pseudo-locked region is triggered by a request
-from the user to do so that is accompanied by a schemata of the region
-to be pseudo-locked. The cache pseudo-locked region is created as follows:
-
-- Create a CAT allocation CLOSNEW with a CBM matching the schemata
- from the user of the cache region that will contain the pseudo-locked
- memory. This region must not overlap with any current CAT allocation/CLOS
- on the system and no future overlap with this cache region is allowed
- while the pseudo-locked region exists.
-- Create a contiguous region of memory of the same size as the cache
- region.
-- Flush the cache, disable hardware prefetchers, disable preemption.
-- Make CLOSNEW the active CLOS and touch the allocated memory to load
- it into the cache.
-- Set the previous CLOS as active.
-- At this point the closid CLOSNEW can be released - the cache
- pseudo-locked region is protected as long as its CBM does not appear in
- any CAT allocation. Even though the cache pseudo-locked region will from
- this point on not appear in any CBM of any CLOS an application running with
- any CLOS will be able to access the memory in the pseudo-locked region since
- the region continues to serve cache hits.
-- The contiguous region of memory loaded into the cache is exposed to
- user-space as a character device.
-
-Cache pseudo-locking increases the probability that data will remain
-in the cache via carefully configuring the CAT feature and controlling
-application behavior. There is no guarantee that data is placed in
-cache. Instructions like INVD, WBINVD, CLFLUSH, etc. can still evict
-“locked” data from cache. Power management C-states may shrink or
-power off cache. Deeper C-states will automatically be restricted on
-pseudo-locked region creation.
-
-It is required that an application using a pseudo-locked region runs
-with affinity to the cores (or a subset of the cores) associated
-with the cache on which the pseudo-locked region resides. A sanity check
-within the code will not allow an application to map pseudo-locked memory
-unless it runs with affinity to cores associated with the cache on which the
-pseudo-locked region resides. The sanity check is only done during the
-initial mmap() handling, there is no enforcement afterwards and the
-application self needs to ensure it remains affine to the correct cores.
-
-Pseudo-locking is accomplished in two stages:
-
-1) During the first stage the system administrator allocates a portion
- of cache that should be dedicated to pseudo-locking. At this time an
- equivalent portion of memory is allocated, loaded into allocated
- cache portion, and exposed as a character device.
-2) During the second stage a user-space application maps (mmap()) the
- pseudo-locked memory into its address space.
-
-Cache Pseudo-Locking Interface
-------------------------------
-A pseudo-locked region is created using the resctrl interface as follows:
-
-1) Create a new resource group by creating a new directory in /sys/fs/resctrl.
-2) Change the new resource group's mode to "pseudo-locksetup" by writing
- "pseudo-locksetup" to the "mode" file.
-3) Write the schemata of the pseudo-locked region to the "schemata" file. All
- bits within the schemata should be "unused" according to the "bit_usage"
- file.
-
-On successful pseudo-locked region creation the "mode" file will contain
-"pseudo-locked" and a new character device with the same name as the resource
-group will exist in /dev/pseudo_lock. This character device can be mmap()'ed
-by user space in order to obtain access to the pseudo-locked memory region.
-
-An example of cache pseudo-locked region creation and usage can be found below.
-
-Cache Pseudo-Locking Debugging Interface
-----------------------------------------
-The pseudo-locking debugging interface is enabled by default (if
-CONFIG_DEBUG_FS is enabled) and can be found in /sys/kernel/debug/resctrl.
-
-There is no explicit way for the kernel to test if a provided memory
-location is present in the cache. The pseudo-locking debugging interface uses
-the tracing infrastructure to provide two ways to measure cache residency of
-the pseudo-locked region:
-
-1) Memory access latency using the pseudo_lock_mem_latency tracepoint. Data
- from these measurements are best visualized using a hist trigger (see
- example below). In this test the pseudo-locked region is traversed at
- a stride of 32 bytes while hardware prefetchers and preemption
- are disabled. This also provides a substitute visualization of cache
- hits and misses.
-2) Cache hit and miss measurements using model specific precision counters if
- available. Depending on the levels of cache on the system the pseudo_lock_l2
- and pseudo_lock_l3 tracepoints are available.
-
-When a pseudo-locked region is created a new debugfs directory is created for
-it in debugfs as /sys/kernel/debug/resctrl/<newdir>. A single
-write-only file, pseudo_lock_measure, is present in this directory. The
-measurement of the pseudo-locked region depends on the number written to this
-debugfs file:
-
-1:
- writing "1" to the pseudo_lock_measure file will trigger the latency
- measurement captured in the pseudo_lock_mem_latency tracepoint. See
- example below.
-2:
- writing "2" to the pseudo_lock_measure file will trigger the L2 cache
- residency (cache hits and misses) measurement captured in the
- pseudo_lock_l2 tracepoint. See example below.
-3:
- writing "3" to the pseudo_lock_measure file will trigger the L3 cache
- residency (cache hits and misses) measurement captured in the
- pseudo_lock_l3 tracepoint.
-
-All measurements are recorded with the tracing infrastructure. This requires
-the relevant tracepoints to be enabled before the measurement is triggered.
-
-Example of latency debugging interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In this example a pseudo-locked region named "newlock" was created. Here is
-how we can measure the latency in cycles of reading from this region and
-visualize this data with a histogram that is available if CONFIG_HIST_TRIGGERS
-is set::
-
- # :> /sys/kernel/debug/tracing/trace
- # echo 'hist:keys=latency' > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/trigger
- # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable
- # echo 1 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure
- # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable
- # cat /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/hist
-
- # event histogram
- #
- # trigger info: hist:keys=latency:vals=hitcount:sort=hitcount:size=2048 [active]
- #
-
- { latency: 456 } hitcount: 1
- { latency: 50 } hitcount: 83
- { latency: 36 } hitcount: 96
- { latency: 44 } hitcount: 174
- { latency: 48 } hitcount: 195
- { latency: 46 } hitcount: 262
- { latency: 42 } hitcount: 693
- { latency: 40 } hitcount: 3204
- { latency: 38 } hitcount: 3484
-
- Totals:
- Hits: 8192
- Entries: 9
- Dropped: 0
-
-Example of cache hits/misses debugging
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In this example a pseudo-locked region named "newlock" was created on the L2
-cache of a platform. Here is how we can obtain details of the cache hits
-and misses using the platform's precision counters.
-::
-
- # :> /sys/kernel/debug/tracing/trace
- # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable
- # echo 2 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure
- # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable
- # cat /sys/kernel/debug/tracing/trace
-
- # tracer: nop
- #
- # _-----=> irqs-off
- # / _----=> need-resched
- # | / _---=> hardirq/softirq
- # || / _--=> preempt-depth
- # ||| / delay
- # TASK-PID CPU# |||| TIMESTAMP FUNCTION
- # | | | |||| | |
- pseudo_lock_mea-1672 [002] .... 3132.860500: pseudo_lock_l2: hits=4097 miss=0
-
-
-Examples for RDT allocation usage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-1) Example 1
-
-On a two socket machine (one L3 cache per socket) with just four bits
-for cache bit masks, minimum b/w of 10% with a memory bandwidth
-granularity of 10%.
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
- # mkdir p0 p1
- # echo "L3:0=3;1=c\nMB:0=50;1=50" > /sys/fs/resctrl/p0/schemata
- # echo "L3:0=3;1=3\nMB:0=50;1=50" > /sys/fs/resctrl/p1/schemata
-
-The default resource group is unmodified, so we have access to all parts
-of all caches (its schemata file reads "L3:0=f;1=f").
-
-Tasks that are under the control of group "p0" may only allocate from the
-"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
-Tasks in group "p1" use the "lower" 50% of cache on both sockets.
-
-Similarly, tasks that are under the control of group "p0" may use a
-maximum memory b/w of 50% on socket0 and 50% on socket 1.
-Tasks in group "p1" may also use 50% memory b/w on both sockets.
-Note that unlike cache masks, memory b/w cannot specify whether these
-allocations can overlap or not. The allocations specifies the maximum
-b/w that the group may be able to use and the system admin can configure
-the b/w accordingly.
-
-If resctrl is using the software controller (mba_sc) then user can enter the
-max b/w in MB rather than the percentage values.
-::
-
- # echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata
- # echo "L3:0=3;1=3\nMB:0=1024;1=500" > /sys/fs/resctrl/p1/schemata
-
-In the above example the tasks in "p1" and "p0" on socket 0 would use a max b/w
-of 1024MB where as on socket 1 they would use 500MB.
-
-2) Example 2
-
-Again two sockets, but this time with a more realistic 20-bit mask.
-
-Two real time tasks pid=1234 running on processor 0 and pid=5678 running on
-processor 1 on socket 0 on a 2-socket and dual core machine. To avoid noisy
-neighbors, each of the two real-time tasks exclusively occupies one quarter
-of L3 cache on socket 0.
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
-
-First we reset the schemata for the default group so that the "upper"
-50% of the L3 cache on socket 0 and 50% of memory b/w cannot be used by
-ordinary tasks::
-
- # echo "L3:0=3ff;1=fffff\nMB:0=50;1=100" > schemata
-
-Next we make a resource group for our first real time task and give
-it access to the "top" 25% of the cache on socket 0.
-::
-
- # mkdir p0
- # echo "L3:0=f8000;1=fffff" > p0/schemata
-
-Finally we move our first real time task into this resource group. We
-also use taskset(1) to ensure the task always runs on a dedicated CPU
-on socket 0. Most uses of resource groups will also constrain which
-processors tasks run on.
-::
-
- # echo 1234 > p0/tasks
- # taskset -cp 1 1234
-
-Ditto for the second real time task (with the remaining 25% of cache)::
-
- # mkdir p1
- # echo "L3:0=7c00;1=fffff" > p1/schemata
- # echo 5678 > p1/tasks
- # taskset -cp 2 5678
-
-For the same 2 socket system with memory b/w resource and CAT L3 the
-schemata would look like(Assume min_bandwidth 10 and bandwidth_gran is
-10):
-
-For our first real time task this would request 20% memory b/w on socket 0.
-::
-
- # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
-
-For our second real time task this would request an other 20% memory b/w
-on socket 0.
-::
-
- # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
-
-3) Example 3
-
-A single socket system which has real-time tasks running on core 4-7 and
-non real-time workload assigned to core 0-3. The real-time tasks share text
-and data, so a per task association is not required and due to interaction
-with the kernel it's desired that the kernel on these cores shares L3 with
-the tasks.
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
-
-First we reset the schemata for the default group so that the "upper"
-50% of the L3 cache on socket 0, and 50% of memory bandwidth on socket 0
-cannot be used by ordinary tasks::
-
- # echo "L3:0=3ff\nMB:0=50" > schemata
-
-Next we make a resource group for our real time cores and give it access
-to the "top" 50% of the cache on socket 0 and 50% of memory bandwidth on
-socket 0.
-::
-
- # mkdir p0
- # echo "L3:0=ffc00\nMB:0=50" > p0/schemata
-
-Finally we move core 4-7 over to the new group and make sure that the
-kernel and the tasks running there get 50% of the cache. They should
-also get 50% of memory bandwidth assuming that the cores 4-7 are SMT
-siblings and only the real time threads are scheduled on the cores 4-7.
-::
-
- # echo F0 > p0/cpus
-
-4) Example 4
-
-The resource groups in previous examples were all in the default "shareable"
-mode allowing sharing of their cache allocations. If one resource group
-configures a cache allocation then nothing prevents another resource group
-to overlap with that allocation.
-
-In this example a new exclusive resource group will be created on a L2 CAT
-system with two L2 cache instances that can be configured with an 8-bit
-capacity bitmask. The new exclusive resource group will be configured to use
-25% of each cache instance.
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl/
- # cd /sys/fs/resctrl
-
-First, we observe that the default group is configured to allocate to all L2
-cache::
-
- # cat schemata
- L2:0=ff;1=ff
-
-We could attempt to create the new resource group at this point, but it will
-fail because of the overlap with the schemata of the default group::
-
- # mkdir p0
- # echo 'L2:0=0x3;1=0x3' > p0/schemata
- # cat p0/mode
- shareable
- # echo exclusive > p0/mode
- -sh: echo: write error: Invalid argument
- # cat info/last_cmd_status
- schemata overlaps
-
-To ensure that there is no overlap with another resource group the default
-resource group's schemata has to change, making it possible for the new
-resource group to become exclusive.
-::
-
- # echo 'L2:0=0xfc;1=0xfc' > schemata
- # echo exclusive > p0/mode
- # grep . p0/*
- p0/cpus:0
- p0/mode:exclusive
- p0/schemata:L2:0=03;1=03
- p0/size:L2:0=262144;1=262144
-
-A new resource group will on creation not overlap with an exclusive resource
-group::
-
- # mkdir p1
- # grep . p1/*
- p1/cpus:0
- p1/mode:shareable
- p1/schemata:L2:0=fc;1=fc
- p1/size:L2:0=786432;1=786432
-
-The bit_usage will reflect how the cache is used::
-
- # cat info/L2/bit_usage
- 0=SSSSSSEE;1=SSSSSSEE
-
-A resource group cannot be forced to overlap with an exclusive resource group::
-
- # echo 'L2:0=0x1;1=0x1' > p1/schemata
- -sh: echo: write error: Invalid argument
- # cat info/last_cmd_status
- overlaps with exclusive group
-
-Example of Cache Pseudo-Locking
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Lock portion of L2 cache from cache id 1 using CBM 0x3. Pseudo-locked
-region is exposed at /dev/pseudo_lock/newlock that can be provided to
-application for argument to mmap().
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl/
- # cd /sys/fs/resctrl
-
-Ensure that there are bits available that can be pseudo-locked, since only
-unused bits can be pseudo-locked the bits to be pseudo-locked needs to be
-removed from the default resource group's schemata::
-
- # cat info/L2/bit_usage
- 0=SSSSSSSS;1=SSSSSSSS
- # echo 'L2:1=0xfc' > schemata
- # cat info/L2/bit_usage
- 0=SSSSSSSS;1=SSSSSS00
-
-Create a new resource group that will be associated with the pseudo-locked
-region, indicate that it will be used for a pseudo-locked region, and
-configure the requested pseudo-locked region capacity bitmask::
-
- # mkdir newlock
- # echo pseudo-locksetup > newlock/mode
- # echo 'L2:1=0x3' > newlock/schemata
-
-On success the resource group's mode will change to pseudo-locked, the
-bit_usage will reflect the pseudo-locked region, and the character device
-exposing the pseudo-locked region will exist::
-
- # cat newlock/mode
- pseudo-locked
- # cat info/L2/bit_usage
- 0=SSSSSSSS;1=SSSSSSPP
- # ls -l /dev/pseudo_lock/newlock
- crw------- 1 root root 243, 0 Apr 3 05:01 /dev/pseudo_lock/newlock
-
-::
-
- /*
- * Example code to access one page of pseudo-locked cache region
- * from user space.
- */
- #define _GNU_SOURCE
- #include <fcntl.h>
- #include <sched.h>
- #include <stdio.h>
- #include <stdlib.h>
- #include <unistd.h>
- #include <sys/mman.h>
-
- /*
- * It is required that the application runs with affinity to only
- * cores associated with the pseudo-locked region. Here the cpu
- * is hardcoded for convenience of example.
- */
- static int cpuid = 2;
-
- int main(int argc, char *argv[])
- {
- cpu_set_t cpuset;
- long page_size;
- void *mapping;
- int dev_fd;
- int ret;
-
- page_size = sysconf(_SC_PAGESIZE);
-
- CPU_ZERO(&cpuset);
- CPU_SET(cpuid, &cpuset);
- ret = sched_setaffinity(0, sizeof(cpuset), &cpuset);
- if (ret < 0) {
- perror("sched_setaffinity");
- exit(EXIT_FAILURE);
- }
-
- dev_fd = open("/dev/pseudo_lock/newlock", O_RDWR);
- if (dev_fd < 0) {
- perror("open");
- exit(EXIT_FAILURE);
- }
-
- mapping = mmap(0, page_size, PROT_READ | PROT_WRITE, MAP_SHARED,
- dev_fd, 0);
- if (mapping == MAP_FAILED) {
- perror("mmap");
- close(dev_fd);
- exit(EXIT_FAILURE);
- }
-
- /* Application interacts with pseudo-locked memory @mapping */
-
- ret = munmap(mapping, page_size);
- if (ret < 0) {
- perror("munmap");
- close(dev_fd);
- exit(EXIT_FAILURE);
- }
-
- close(dev_fd);
- exit(EXIT_SUCCESS);
- }
-
-Locking between applications
-----------------------------
-
-Certain operations on the resctrl filesystem, composed of read/writes
-to/from multiple files, must be atomic.
-
-As an example, the allocation of an exclusive reservation of L3 cache
-involves:
-
- 1. Read the cbmmasks from each directory or the per-resource "bit_usage"
- 2. Find a contiguous set of bits in the global CBM bitmask that is clear
- in any of the directory cbmmasks
- 3. Create a new directory
- 4. Set the bits found in step 2 to the new directory "schemata" file
-
-If two applications attempt to allocate space concurrently then they can
-end up allocating the same bits so the reservations are shared instead of
-exclusive.
-
-To coordinate atomic operations on the resctrlfs and to avoid the problem
-above, the following locking procedure is recommended:
-
-Locking is based on flock, which is available in libc and also as a shell
-script command
-
-Write lock:
-
- A) Take flock(LOCK_EX) on /sys/fs/resctrl
- B) Read/write the directory structure.
- C) funlock
-
-Read lock:
-
- A) Take flock(LOCK_SH) on /sys/fs/resctrl
- B) If success read the directory structure.
- C) funlock
-
-Example with bash::
-
- # Atomically read directory structure
- $ flock -s /sys/fs/resctrl/ find /sys/fs/resctrl
-
- # Read directory contents and create new subdirectory
-
- $ cat create-dir.sh
- find /sys/fs/resctrl/ > output.txt
- mask = function-of(output.txt)
- mkdir /sys/fs/resctrl/newres/
- echo mask > /sys/fs/resctrl/newres/schemata
-
- $ flock /sys/fs/resctrl/ ./create-dir.sh
-
-Example with C::
-
- /*
- * Example code do take advisory locks
- * before accessing resctrl filesystem
- */
- #include <sys/file.h>
- #include <stdlib.h>
-
- void resctrl_take_shared_lock(int fd)
- {
- int ret;
-
- /* take shared lock on resctrl filesystem */
- ret = flock(fd, LOCK_SH);
- if (ret) {
- perror("flock");
- exit(-1);
- }
- }
-
- void resctrl_take_exclusive_lock(int fd)
- {
- int ret;
-
- /* release lock on resctrl filesystem */
- ret = flock(fd, LOCK_EX);
- if (ret) {
- perror("flock");
- exit(-1);
- }
- }
-
- void resctrl_release_lock(int fd)
- {
- int ret;
-
- /* take shared lock on resctrl filesystem */
- ret = flock(fd, LOCK_UN);
- if (ret) {
- perror("flock");
- exit(-1);
- }
- }
-
- void main(void)
- {
- int fd, ret;
-
- fd = open("/sys/fs/resctrl", O_DIRECTORY);
- if (fd == -1) {
- perror("open");
- exit(-1);
- }
- resctrl_take_shared_lock(fd);
- /* code to read directory contents */
- resctrl_release_lock(fd);
-
- resctrl_take_exclusive_lock(fd);
- /* code to read and write directory contents */
- resctrl_release_lock(fd);
- }
-
-Examples for RDT Monitoring along with allocation usage
-=======================================================
-Reading monitored data
-----------------------
-Reading an event file (for ex: mon_data/mon_L3_00/llc_occupancy) would
-show the current snapshot of LLC occupancy of the corresponding MON
-group or CTRL_MON group.
-
-
-Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group)
-------------------------------------------------------------------------
-On a two socket machine (one L3 cache per socket) with just four bits
-for cache bit masks::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
- # mkdir p0 p1
- # echo "L3:0=3;1=c" > /sys/fs/resctrl/p0/schemata
- # echo "L3:0=3;1=3" > /sys/fs/resctrl/p1/schemata
- # echo 5678 > p1/tasks
- # echo 5679 > p1/tasks
-
-The default resource group is unmodified, so we have access to all parts
-of all caches (its schemata file reads "L3:0=f;1=f").
-
-Tasks that are under the control of group "p0" may only allocate from the
-"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
-Tasks in group "p1" use the "lower" 50% of cache on both sockets.
-
-Create monitor groups and assign a subset of tasks to each monitor group.
-::
-
- # cd /sys/fs/resctrl/p1/mon_groups
- # mkdir m11 m12
- # echo 5678 > m11/tasks
- # echo 5679 > m12/tasks
-
-fetch data (data shown in bytes)
-::
-
- # cat m11/mon_data/mon_L3_00/llc_occupancy
- 16234000
- # cat m11/mon_data/mon_L3_01/llc_occupancy
- 14789000
- # cat m12/mon_data/mon_L3_00/llc_occupancy
- 16789000
-
-The parent ctrl_mon group shows the aggregated data.
-::
-
- # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy
- 31234000
-
-Example 2 (Monitor a task from its creation)
---------------------------------------------
-On a two socket machine (one L3 cache per socket)::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
- # mkdir p0 p1
-
-An RMID is allocated to the group once its created and hence the <cmd>
-below is monitored from its creation.
-::
-
- # echo $$ > /sys/fs/resctrl/p1/tasks
- # <cmd>
-
-Fetch the data::
-
- # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy
- 31789000
-
-Example 3 (Monitor without CAT support or before creating CAT groups)
----------------------------------------------------------------------
-
-Assume a system like HSW has only CQM and no CAT support. In this case
-the resctrl will still mount but cannot create CTRL_MON directories.
-But user can create different MON groups within the root group thereby
-able to monitor all tasks including kernel threads.
-
-This can also be used to profile jobs cache size footprint before being
-able to allocate them to different allocation groups.
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
- # mkdir mon_groups/m01
- # mkdir mon_groups/m02
-
- # echo 3478 > /sys/fs/resctrl/mon_groups/m01/tasks
- # echo 2467 > /sys/fs/resctrl/mon_groups/m02/tasks
-
-Monitor the groups separately and also get per domain data. From the
-below its apparent that the tasks are mostly doing work on
-domain(socket) 0.
-::
-
- # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_00/llc_occupancy
- 31234000
- # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_01/llc_occupancy
- 34555
- # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_00/llc_occupancy
- 31234000
- # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_01/llc_occupancy
- 32789
-
-
-Example 4 (Monitor real time tasks)
------------------------------------
-
-A single socket system which has real time tasks running on cores 4-7
-and non real time tasks on other cpus. We want to monitor the cache
-occupancy of the real time threads on these cores.
-::
-
- # mount -t resctrl resctrl /sys/fs/resctrl
- # cd /sys/fs/resctrl
- # mkdir p1
-
-Move the cpus 4-7 over to p1::
-
- # echo f0 > p1/cpus
-
-View the llc occupancy snapshot::
-
- # cat /sys/fs/resctrl/p1/mon_data/mon_L3_00/llc_occupancy
- 11234000
diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
new file mode 100644
index 0000000..eaee136
--- /dev/null
+++ b/Documentation/x86/sgx.rst
@@ -0,0 +1,211 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================
+Software Guard eXtensions (SGX)
+===============================
+
+Overview
+========
+
+Software Guard eXtensions (SGX) hardware enables for user space applications
+to set aside private memory regions of code and data:
+
+* Privileged (ring-0) ENCLS functions orchestrate the construction of the.
+ regions.
+* Unprivileged (ring-3) ENCLU functions allow an application to enter and
+ execute inside the regions.
+
+These memory regions are called enclaves. An enclave can be only entered at a
+fixed set of entry points. Each entry point can hold a single hardware thread
+at a time. While the enclave is loaded from a regular binary file by using
+ENCLS functions, only the threads inside the enclave can access its memory. The
+region is denied from outside access by the CPU, and encrypted before it leaves
+from LLC.
+
+The support can be determined by
+
+ ``grep sgx /proc/cpuinfo``
+
+SGX must both be supported in the processor and enabled by the BIOS. If SGX
+appears to be unsupported on a system which has hardware support, ensure
+support is enabled in the BIOS. If a BIOS presents a choice between "Enabled"
+and "Software Enabled" modes for SGX, choose "Enabled".
+
+Enclave Page Cache
+==================
+
+SGX utilizes an *Enclave Page Cache (EPC)* to store pages that are associated
+with an enclave. It is contained in a BIOS-reserved region of physical memory.
+Unlike pages used for regular memory, pages can only be accessed from outside of
+the enclave during enclave construction with special, limited SGX instructions.
+
+Only a CPU executing inside an enclave can directly access enclave memory.
+However, a CPU executing inside an enclave may access normal memory outside the
+enclave.
+
+The kernel manages enclave memory similar to how it treats device memory.
+
+Enclave Page Types
+------------------
+
+**SGX Enclave Control Structure (SECS)**
+ Enclave's address range, attributes and other global data are defined
+ by this structure.
+
+**Regular (REG)**
+ Regular EPC pages contain the code and data of an enclave.
+
+**Thread Control Structure (TCS)**
+ Thread Control Structure pages define the entry points to an enclave and
+ track the execution state of an enclave thread.
+
+**Version Array (VA)**
+ Version Array pages contain 512 slots, each of which can contain a version
+ number for a page evicted from the EPC.
+
+Enclave Page Cache Map
+----------------------
+
+The processor tracks EPC pages in a hardware metadata structure called the
+*Enclave Page Cache Map (EPCM)*. The EPCM contains an entry for each EPC page
+which describes the owning enclave, access rights and page type among the other
+things.
+
+EPCM permissions are separate from the normal page tables. This prevents the
+kernel from, for instance, allowing writes to data which an enclave wishes to
+remain read-only. EPCM permissions may only impose additional restrictions on
+top of normal x86 page permissions.
+
+For all intents and purposes, the SGX architecture allows the processor to
+invalidate all EPCM entries at will. This requires that software be prepared to
+handle an EPCM fault at any time. In practice, this can happen on events like
+power transitions when the ephemeral key that encrypts enclave memory is lost.
+
+Application interface
+=====================
+
+Enclave build functions
+-----------------------
+
+In addition to the traditional compiler and linker build process, SGX has a
+separate enclave “build” process. Enclaves must be built before they can be
+executed (entered). The first step in building an enclave is opening the
+**/dev/sgx_enclave** device. Since enclave memory is protected from direct
+access, special privileged instructions are Then used to copy data into enclave
+pages and establish enclave page permissions.
+
+.. kernel-doc:: arch/x86/kernel/cpu/sgx/ioctl.c
+ :functions: sgx_ioc_enclave_create
+ sgx_ioc_enclave_add_pages
+ sgx_ioc_enclave_init
+ sgx_ioc_enclave_provision
+
+Enclave vDSO
+------------
+
+Entering an enclave can only be done through SGX-specific EENTER and ERESUME
+functions, and is a non-trivial process. Because of the complexity of
+transitioning to and from an enclave, enclaves typically utilize a library to
+handle the actual transitions. This is roughly analogous to how glibc
+implementations are used by most applications to wrap system calls.
+
+Another crucial characteristic of enclaves is that they can generate exceptions
+as part of their normal operation that need to be handled in the enclave or are
+unique to SGX.
+
+Instead of the traditional signal mechanism to handle these exceptions, SGX
+can leverage special exception fixup provided by the vDSO. The kernel-provided
+vDSO function wraps low-level transitions to/from the enclave like EENTER and
+ERESUME. The vDSO function intercepts exceptions that would otherwise generate
+a signal and return the fault information directly to its caller. This avoids
+the need to juggle signal handlers.
+
+.. kernel-doc:: arch/x86/include/uapi/asm/sgx.h
+ :functions: vdso_sgx_enter_enclave_t
+
+ksgxd
+=====
+
+SGX support includes a kernel thread called *ksgxwapd*.
+
+EPC sanitization
+----------------
+
+ksgxd is started when SGX initializes. Enclave memory is typically ready
+For use when the processor powers on or resets. However, if SGX has been in
+use since the reset, enclave pages may be in an inconsistent state. This might
+occur after a crash and kexec() cycle, for instance. At boot, ksgxd
+reinitializes all enclave pages so that they can be allocated and re-used.
+
+The sanitization is done by going through EPC address space and applying the
+EREMOVE function to each physical page. Some enclave pages like SECS pages have
+hardware dependencies on other pages which prevents EREMOVE from functioning.
+Executing two EREMOVE passes removes the dependencies.
+
+Page reclaimer
+--------------
+
+Similar to the core kswapd, ksgxd, is responsible for managing the
+overcommitment of enclave memory. If the system runs out of enclave memory,
+*ksgxwapd* “swaps” enclave memory to normal memory.
+
+Launch Control
+==============
+
+SGX provides a launch control mechanism. After all enclave pages have been
+copied, kernel executes EINIT function, which initializes the enclave. Only after
+this the CPU can execute inside the enclave.
+
+ENIT function takes an RSA-3072 signature of the enclave measurement. The function
+checks that the measurement is correct and signature is signed with the key
+hashed to the four **IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}** MSRs representing the
+SHA256 of a public key.
+
+Those MSRs can be configured by the BIOS to be either readable or writable.
+Linux supports only writable configuration in order to give full control to the
+kernel on launch control policy. Before calling EINIT function, the driver sets
+the MSRs to match the enclave's signing key.
+
+Encryption engines
+==================
+
+In order to conceal the enclave data while it is out of the CPU package, the
+memory controller has an encryption engine to transparently encrypt and decrypt
+enclave memory.
+
+In CPUs prior to Ice Lake, the Memory Encryption Engine (MEE) is used to
+encrypt pages leaving the CPU caches. MEE uses a n-ary Merkle tree with root in
+SRAM to maintain integrity of the encrypted data. This provides integrity and
+anti-replay protection but does not scale to large memory sizes because the time
+required to update the Merkle tree grows logarithmically in relation to the
+memory size.
+
+CPUs starting from Icelake use Total Memory Encryption (TME) in the place of
+MEE. TME-based SGX implementations do not have an integrity Merkle tree, which
+means integrity and replay-attacks are not mitigated. B, it includes
+additional changes to prevent cipher text from being returned and SW memory
+aliases from being Created.
+
+DMA to enclave memory is blocked by range registers on both MEE and TME systems
+(SDM section 41.10).
+
+Usage Models
+============
+
+Shared Library
+--------------
+
+Sensitive data and the code that acts on it is partitioned from the application
+into a separate library. The library is then linked as a DSO which can be loaded
+into an enclave. The application can then make individual function calls into
+the enclave through special SGX instructions. A run-time within the enclave is
+configured to marshal function parameters into and out of the enclave and to
+call the correct library function.
+
+Application Container
+---------------------
+
+An application may be loaded into a container enclave which is specially
+configured with a library OS and run-time which permits the application to run.
+The enclave run-time and library OS work together to execute the application
+when a thread enters the enclave.
diff --git a/Documentation/x86/topology.rst b/Documentation/x86/topology.rst
index e297399..7f58010 100644
--- a/Documentation/x86/topology.rst
+++ b/Documentation/x86/topology.rst
@@ -41,6 +41,8 @@
Packages contain a number of cores plus shared resources, e.g. DRAM
controller, shared caches etc.
+Modern systems may also use the term 'Die' for package.
+
AMD nomenclature for package is 'Node'.
Package-related topology information in the kernel:
@@ -53,11 +55,18 @@
The number of dies in a package. This information is retrieved via CPUID.
+ - cpuinfo_x86.cpu_die_id:
+
+ The physical ID of the die. This information is retrieved via CPUID.
+
- cpuinfo_x86.phys_proc_id:
The physical ID of the package. This information is retrieved via CPUID
and deduced from the APIC IDs of the cores in the package.
+ Modern systems use this value for the socket. There may be multiple
+ packages within a socket. This value may differ from cpu_die_id.
+
- cpuinfo_x86.logical_proc_id:
The logical ID of the package. As we do not trust BIOSes to enumerate the
diff --git a/Documentation/xtensa/features.rst b/Documentation/xtensa/features.rst
new file mode 100644
index 0000000..6b92c7b
--- /dev/null
+++ b/Documentation/xtensa/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: $srctree/Documentation/features xtensa
diff --git a/Documentation/xtensa/index.rst b/Documentation/xtensa/index.rst
index 52fa04e..6995244 100644
--- a/Documentation/xtensa/index.rst
+++ b/Documentation/xtensa/index.rst
@@ -10,3 +10,5 @@
atomctl
booting
mmu
+
+ features
diff --git a/LICENSES/dual/CC-BY-4.0 b/LICENSES/dual/CC-BY-4.0
new file mode 100644
index 0000000..45a81b8
--- /dev/null
+++ b/LICENSES/dual/CC-BY-4.0
@@ -0,0 +1,410 @@
+Valid-License-Identifier: CC-BY-4.0
+SPDX-URL: https://spdx.org/licenses/CC-BY-4.0
+Usage-Guide:
+ Do NOT use this license for code, but it's acceptable for content like artwork
+ or documentation. When using it for the latter, it's best to use it together
+ with a GPL2 compatible license using "OR", as CC-BY-4.0 texts processed by
+ the kernel's build system might combine it with content taken from more
+ restrictive licenses.
+ To use the Creative Commons Attribution 4.0 International license put
+ the following SPDX tag/value pair into a comment according to the
+ placement guidelines in the licensing rules documentation:
+ SPDX-License-Identifier: CC-BY-4.0
+License-Text:
+
+Creative Commons Attribution 4.0 International
+
+=======================================================================
+
+Creative Commons Corporation ("Creative Commons") is not a law firm and
+does not provide legal services or legal advice. Distribution of
+Creative Commons public licenses does not create a lawyer-client or
+other relationship. Creative Commons makes its licenses and related
+information available on an "as-is" basis. Creative Commons gives no
+warranties regarding its licenses, any material licensed under their
+terms and conditions, or any related information. Creative Commons
+disclaims all liability for damages resulting from their use to the
+fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and
+conditions that creators and other rights holders may use to share
+original works of authorship and other material subject to copyright
+and certain other rights specified in the public license below. The
+following considerations are for informational purposes only, are not
+exhaustive, and do not form part of our licenses.
+
+ Considerations for licensors: Our public licenses are
+ intended for use by those authorized to give the public
+ permission to use material in ways otherwise restricted by
+ copyright and certain other rights. Our licenses are
+ irrevocable. Licensors should read and understand the terms
+ and conditions of the license they choose before applying it.
+ Licensors should also secure all rights necessary before
+ applying our licenses so that the public can reuse the
+ material as expected. Licensors should clearly mark any
+ material not subject to the license. This includes other CC-
+ licensed material, or material used under an exception or
+ limitation to copyright. More considerations for licensors:
+ wiki.creativecommons.org/Considerations_for_licensors
+
+ Considerations for the public: By using one of our public
+ licenses, a licensor grants the public permission to use the
+ licensed material under specified terms and conditions. If
+ the licensor's permission is not necessary for any reason--for
+ example, because of any applicable exception or limitation to
+ copyright--then that use is not regulated by the license. Our
+ licenses grant only permissions under copyright and certain
+ other rights that a licensor has authority to grant. Use of
+ the licensed material may still be restricted for other
+ reasons, including because others have copyright or other
+ rights in the material. A licensor may make special requests,
+ such as asking that all changes be marked or described.
+ Although not required by our licenses, you are encouraged to
+ respect those requests where reasonable. More considerations
+ for the public:
+ wiki.creativecommons.org/Considerations_for_licensees
+
+=======================================================================
+
+Creative Commons Attribution 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree
+to be bound by the terms and conditions of this Creative Commons
+Attribution 4.0 International Public License ("Public License"). To the
+extent this Public License may be interpreted as a contract, You are
+granted the Licensed Rights in consideration of Your acceptance of
+these terms and conditions, and the Licensor grants You such rights in
+consideration of benefits the Licensor receives from making the
+Licensed Material available under these terms and conditions.
+
+
+Section 1 -- Definitions.
+
+ a. Adapted Material means material subject to Copyright and Similar
+ Rights that is derived from or based upon the Licensed Material
+ and in which the Licensed Material is translated, altered,
+ arranged, transformed, or otherwise modified in a manner requiring
+ permission under the Copyright and Similar Rights held by the
+ Licensor. For purposes of this Public License, where the Licensed
+ Material is a musical work, performance, or sound recording,
+ Adapted Material is always produced where the Licensed Material is
+ synched in timed relation with a moving image.
+
+ b. Adapter's License means the license You apply to Your Copyright
+ and Similar Rights in Your contributions to Adapted Material in
+ accordance with the terms and conditions of this Public License.
+
+ c. Copyright and Similar Rights means copyright and/or similar rights
+ closely related to copyright including, without limitation,
+ performance, broadcast, sound recording, and Sui Generis Database
+ Rights, without regard to how the rights are labeled or
+ categorized. For purposes of this Public License, the rights
+ specified in Section 2(b)(1)-(2) are not Copyright and Similar
+ Rights.
+
+ d. Effective Technological Measures means those measures that, in the
+ absence of proper authority, may not be circumvented under laws
+ fulfilling obligations under Article 11 of the WIPO Copyright
+ Treaty adopted on December 20, 1996, and/or similar international
+ agreements.
+
+ e. Exceptions and Limitations means fair use, fair dealing, and/or
+ any other exception or limitation to Copyright and Similar Rights
+ that applies to Your use of the Licensed Material.
+
+ f. Licensed Material means the artistic or literary work, database,
+ or other material to which the Licensor applied this Public
+ License.
+
+ g. Licensed Rights means the rights granted to You subject to the
+ terms and conditions of this Public License, which are limited to
+ all Copyright and Similar Rights that apply to Your use of the
+ Licensed Material and that the Licensor has authority to license.
+
+ h. Licensor means the individual(s) or entity(ies) granting rights
+ under this Public License.
+
+ i. Share means to provide material to the public by any means or
+ process that requires permission under the Licensed Rights, such
+ as reproduction, public display, public performance, distribution,
+ dissemination, communication, or importation, and to make material
+ available to the public including in ways that members of the
+ public may access the material from a place and at a time
+ individually chosen by them.
+
+ j. Sui Generis Database Rights means rights other than copyright
+ resulting from Directive 96/9/EC of the European Parliament and of
+ the Council of 11 March 1996 on the legal protection of databases,
+ as amended and/or succeeded, as well as other essentially
+ equivalent rights anywhere in the world.
+
+ k. You means the individual or entity exercising the Licensed Rights
+ under this Public License. Your has a corresponding meaning.
+
+
+Section 2 -- Scope.
+
+ a. License grant.
+
+ 1. Subject to the terms and conditions of this Public License,
+ the Licensor hereby grants You a worldwide, royalty-free,
+ non-sublicensable, non-exclusive, irrevocable license to
+ exercise the Licensed Rights in the Licensed Material to:
+
+ a. reproduce and Share the Licensed Material, in whole or
+ in part; and
+
+ b. produce, reproduce, and Share Adapted Material.
+
+ 2. Exceptions and Limitations. For the avoidance of doubt, where
+ Exceptions and Limitations apply to Your use, this Public
+ License does not apply, and You do not need to comply with
+ its terms and conditions.
+
+ 3. Term. The term of this Public License is specified in Section
+ 6(a).
+
+ 4. Media and formats; technical modifications allowed. The
+ Licensor authorizes You to exercise the Licensed Rights in
+ all media and formats whether now known or hereafter created,
+ and to make technical modifications necessary to do so. The
+ Licensor waives and/or agrees not to assert any right or
+ authority to forbid You from making technical modifications
+ necessary to exercise the Licensed Rights, including
+ technical modifications necessary to circumvent Effective
+ Technological Measures. For purposes of this Public License,
+ simply making modifications authorized by this Section 2(a)
+ (4) never produces Adapted Material.
+
+ 5. Downstream recipients.
+
+ a. Offer from the Licensor -- Licensed Material. Every
+ recipient of the Licensed Material automatically
+ receives an offer from the Licensor to exercise the
+ Licensed Rights under the terms and conditions of this
+ Public License.
+
+ b. No downstream restrictions. You may not offer or impose
+ any additional or different terms or conditions on, or
+ apply any Effective Technological Measures to, the
+ Licensed Material if doing so restricts exercise of the
+ Licensed Rights by any recipient of the Licensed
+ Material.
+
+ 6. No endorsement. Nothing in this Public License constitutes or
+ may be construed as permission to assert or imply that You
+ are, or that Your use of the Licensed Material is, connected
+ with, or sponsored, endorsed, or granted official status by,
+ the Licensor or others designated to receive attribution as
+ provided in Section 3(a)(1)(A)(i).
+
+ b. Other rights.
+
+ 1. Moral rights, such as the right of integrity, are not
+ licensed under this Public License, nor are publicity,
+ privacy, and/or other similar personality rights; however, to
+ the extent possible, the Licensor waives and/or agrees not to
+ assert any such rights held by the Licensor to the limited
+ extent necessary to allow You to exercise the Licensed
+ Rights, but not otherwise.
+
+ 2. Patent and trademark rights are not licensed under this
+ Public License.
+
+ 3. To the extent possible, the Licensor waives any right to
+ collect royalties from You for the exercise of the Licensed
+ Rights, whether directly or through a collecting society
+ under any voluntary or waivable statutory or compulsory
+ licensing scheme. In all other cases the Licensor expressly
+ reserves any right to collect such royalties.
+
+
+Section 3 -- License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the
+following conditions.
+
+ a. Attribution.
+
+ 1. If You Share the Licensed Material (including in modified
+ form), You must:
+
+ a. retain the following if it is supplied by the Licensor
+ with the Licensed Material:
+
+ i. identification of the creator(s) of the Licensed
+ Material and any others designated to receive
+ attribution, in any reasonable manner requested by
+ the Licensor (including by pseudonym if
+ designated);
+
+ ii. a copyright notice;
+
+ iii. a notice that refers to this Public License;
+
+ iv. a notice that refers to the disclaimer of
+ warranties;
+
+ v. a URI or hyperlink to the Licensed Material to the
+ extent reasonably practicable;
+
+ b. indicate if You modified the Licensed Material and
+ retain an indication of any previous modifications; and
+
+ c. indicate the Licensed Material is licensed under this
+ Public License, and include the text of, or the URI or
+ hyperlink to, this Public License.
+
+ 2. You may satisfy the conditions in Section 3(a)(1) in any
+ reasonable manner based on the medium, means, and context in
+ which You Share the Licensed Material. For example, it may be
+ reasonable to satisfy the conditions by providing a URI or
+ hyperlink to a resource that includes the required
+ information.
+
+ 3. If requested by the Licensor, You must remove any of the
+ information required by Section 3(a)(1)(A) to the extent
+ reasonably practicable.
+
+ 4. If You Share Adapted Material You produce, the Adapter's
+ License You apply must not prevent recipients of the Adapted
+ Material from complying with this Public License.
+
+
+Section 4 -- Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that
+apply to Your use of the Licensed Material:
+
+ a. for the avoidance of doubt, Section 2(a)(1) grants You the right
+ to extract, reuse, reproduce, and Share all or a substantial
+ portion of the contents of the database;
+
+ b. if You include all or a substantial portion of the database
+ contents in a database in which You have Sui Generis Database
+ Rights, then the database in which You have Sui Generis Database
+ Rights (but not its individual contents) is Adapted Material; and
+
+ c. You must comply with the conditions in Section 3(a) if You Share
+ all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not
+replace Your obligations under this Public License where the Licensed
+Rights include other Copyright and Similar Rights.
+
+
+Section 5 -- Disclaimer of Warranties and Limitation of Liability.
+
+ a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
+ EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
+ AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
+ ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
+ IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
+ WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
+ PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
+ ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
+ KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
+ ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
+
+ b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
+ TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
+ NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
+ INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
+ COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
+ USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
+ ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
+ DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
+ IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
+
+ c. The disclaimer of warranties and limitation of liability provided
+ above shall be interpreted in a manner that, to the extent
+ possible, most closely approximates an absolute disclaimer and
+ waiver of all liability.
+
+
+Section 6 -- Term and Termination.
+
+ a. This Public License applies for the term of the Copyright and
+ Similar Rights licensed here. However, if You fail to comply with
+ this Public License, then Your rights under this Public License
+ terminate automatically.
+
+ b. Where Your right to use the Licensed Material has terminated under
+ Section 6(a), it reinstates:
+
+ 1. automatically as of the date the violation is cured, provided
+ it is cured within 30 days of Your discovery of the
+ violation; or
+
+ 2. upon express reinstatement by the Licensor.
+
+ For the avoidance of doubt, this Section 6(b) does not affect any
+ right the Licensor may have to seek remedies for Your violations
+ of this Public License.
+
+ c. For the avoidance of doubt, the Licensor may also offer the
+ Licensed Material under separate terms or conditions or stop
+ distributing the Licensed Material at any time; however, doing so
+ will not terminate this Public License.
+
+ d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
+ License.
+
+
+Section 7 -- Other Terms and Conditions.
+
+ a. The Licensor shall not be bound by any additional or different
+ terms or conditions communicated by You unless expressly agreed.
+
+ b. Any arrangements, understandings, or agreements regarding the
+ Licensed Material not stated herein are separate from and
+ independent of the terms and conditions of this Public License.
+
+
+Section 8 -- Interpretation.
+
+ a. For the avoidance of doubt, this Public License does not, and
+ shall not be interpreted to, reduce, limit, restrict, or impose
+ conditions on any use of the Licensed Material that could lawfully
+ be made without permission under this Public License.
+
+ b. To the extent possible, if any provision of this Public License is
+ deemed unenforceable, it shall be automatically reformed to the
+ minimum extent necessary to make it enforceable. If the provision
+ cannot be reformed, it shall be severed from this Public License
+ without affecting the enforceability of the remaining terms and
+ conditions.
+
+ c. No term or condition of this Public License will be waived and no
+ failure to comply consented to unless expressly agreed to by the
+ Licensor.
+
+ d. Nothing in this Public License constitutes or may be interpreted
+ as a limitation upon, or waiver of, any privileges and immunities
+ that apply to the Licensor or You, including from the legal
+ processes of any jurisdiction or authority.
+
+
+=======================================================================
+
+Creative Commons is not a party to its public
+licenses. Notwithstanding, Creative Commons may elect to apply one of
+its public licenses to material it publishes and in those instances
+will be considered the “Licensor.” The text of the Creative Commons
+public licenses is dedicated to the public domain under the CC0 Public
+Domain Dedication. Except for the limited purpose of indicating that
+material is shared under a Creative Commons public license or as
+otherwise permitted by the Creative Commons policies published at
+creativecommons.org/policies, Creative Commons does not authorize the
+use of the trademark "Creative Commons" or any other trademark or logo
+of Creative Commons without its prior written consent including,
+without limitation, in connection with any unauthorized modifications
+to any of its public licenses or any other arrangements,
+understandings, or agreements concerning use of licensed material. For
+the avoidance of doubt, this paragraph does not form part of the
+public licenses.
+
+Creative Commons may be contacted at creativecommons.org.
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 281de21..546aa66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -929,6 +929,12 @@
S: Maintained
F: drivers/i2c/busses/i2c-amd-mp2*
+AMD PMC DRIVER
+M: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/amd-pmc.*
+
AMD POWERPLAY
M: Evan Quan <evan.quan@amd.com>
L: amd-gfx@lists.freedesktop.org
@@ -950,6 +956,14 @@
F: arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
F: drivers/net/ethernet/amd/xgbe/
+AMD SENSOR FUSION HUB DRIVER
+M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
+M: Sandeep Singh <sandeep.singh@amd.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: Documentation/hid/amd-sfh*
+F: drivers/hid/amd-sfh-hid/
+
AMS AS73211 DRIVER
M: Christian Eggers <ceggers@arri.de>
L: linux-iio@vger.kernel.org
@@ -1073,6 +1087,7 @@
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/i2c/adv7604*
+F: Documentation/devicetree/bindings/media/i2c/adv7604.yaml
ANALOG DEVICES INC ADV7842 DRIVER
M: Hans Verkuil <hverkuil-cisco@xs4all.nl>
@@ -1168,21 +1183,11 @@
F: drivers/irqchip/irq-goldfish-pic.c
ANDROID GOLDFISH RTC DRIVER
-M: Miodrag Dinic <miodrag.dinic@mips.com>
+M: Jiaxun Yang <jiaxun.yang@flygoat.com>
S: Supported
F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
F: drivers/rtc/rtc-goldfish.c
-ANDROID ION DRIVER
-M: Laura Abbott <labbott@redhat.com>
-M: Sumit Semwal <sumit.semwal@linaro.org>
-L: devel@driverdev.osuosl.org
-L: dri-devel@lists.freedesktop.org
-L: linaro-mm-sig@lists.linaro.org (moderated for non-subscribers)
-S: Supported
-F: drivers/staging/android/ion
-F: drivers/staging/android/uapi/ion.h
-
AOA (Apple Onboard Audio) ALSA DRIVER
M: Johannes Berg <johannes@sipsolutions.net>
L: linuxppc-dev@lists.ozlabs.org
@@ -1511,7 +1516,7 @@
F: Documentation/devicetree/bindings/arm/actions.yaml
F: Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
F: Documentation/devicetree/bindings/dma/owl-dma.yaml
-F: Documentation/devicetree/bindings/i2c/i2c-owl.txt
+F: Documentation/devicetree/bindings/i2c/i2c-owl.yaml
F: Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml
F: Documentation/devicetree/bindings/mmc/owl-mmc.yaml
F: Documentation/devicetree/bindings/pinctrl/actions,*
@@ -1802,14 +1807,6 @@
F: drivers/gpio/gpio-moxtet.c
F: include/linux/moxtet.h
-ARM/EBSA110 MACHINE SUPPORT
-M: Russell King <linux@armlinux.org.uk>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
-W: http://www.armlinux.org.uk/
-F: arch/arm/mach-ebsa110/
-F: drivers/net/ethernet/amd/am79c961a.*
-
ARM/ENERGY MICRO (SILICON LABS) EFM32 SUPPORT
M: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
@@ -2029,7 +2026,7 @@
M: Gregory Clement <gregory.clement@bootlin.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://git.infradead.org/linux-mvebu.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
F: Documentation/devicetree/bindings/soc/dove/
F: arch/arm/boot/dts/dove*
F: arch/arm/boot/dts/orion5x*
@@ -2045,7 +2042,7 @@
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: git git://git.infradead.org/linux-mvebu.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git
F: arch/arm/boot/dts/armada*
F: arch/arm/boot/dts/kirkwood*
F: arch/arm/configs/mvebu_*_defconfig
@@ -2077,7 +2074,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-W: https://mtk.bcnfs.org/
+W: https://mtk.wiki.kernel.org/
C: irc://chat.freenode.net/linux-mediatek
F: arch/arm/boot/dts/mt6*
F: arch/arm/boot/dts/mt7*
@@ -2127,8 +2124,16 @@
S: Supported
T: git git://github.com/microchip-ung/linux-upstream.git
F: arch/arm64/boot/dts/microchip/
+F: drivers/pinctrl/pinctrl-microchip-sgpio.c
N: sparx5
+Microchip Timer Counter Block (TCB) Capture Driver
+M: Kamel Bouhara <kamel.bouhara@bootlin.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: drivers/counter/microchip-tcb-capture.c
+
ARM/MIOA701 MACHINE SUPPORT
M: Robert Jarzmik <robert.jarzmik@free.fr>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -2141,8 +2146,11 @@
S: Maintained
W: http://linux-chenxing.org/
F: Documentation/devicetree/bindings/arm/mstar/*
+F: Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
F: arch/arm/boot/dts/mstar-*
F: arch/arm/mach-mstar/
+F: drivers/gpio/gpio-msc313.c
+F: include/dt-bindings/gpio/msc313-gpio.h
ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
M: Michael Petchkovsky <mkpetch@internode.on.net>
@@ -2484,7 +2492,7 @@
ARM/SOCFPGA EDAC SUPPORT
M: Dinh Nguyen <dinguyen@kernel.org>
S: Maintained
-F: drivers/edac/altera_edac.
+F: drivers/edac/altera_edac.[ch]
ARM/SPREADTRUM SoC SUPPORT
M: Orson Zhai <orsonzhai@gmail.com>
@@ -2962,7 +2970,7 @@
M: Nick Dyer <nick@shmanahar.org>
S: Maintained
T: git git://github.com/ndyer/linux.git
-F: Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+F: Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
F: drivers/input/touchscreen/atmel_mxt_ts.c
ATMEL WIRELESS DRIVER
@@ -2981,6 +2989,8 @@
S: Maintained
F: arch/*/include/asm/atomic*.h
F: include/*/atomic*.h
+F: include/linux/refcount.h
+F: Documentation/atomic_*.txt
F: scripts/atomic/
ATTO EXPRESSSAS SAS/SATA RAID SCSI DRIVER
@@ -3119,8 +3129,6 @@
B: https://www.open-mesh.org/projects/batman-adv/issues
C: irc://chat.freenode.net/batman
T: git https://git.open-mesh.org/linux-merge.git
-F: Documentation/ABI/obsolete/sysfs-class-net-batman-adv
-F: Documentation/ABI/obsolete/sysfs-class-net-mesh
F: Documentation/networking/batman-adv.rst
F: include/uapi/linux/batadv_packet.h
F: include/uapi/linux/batman_adv.h
@@ -3191,6 +3199,7 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
F: block/
F: drivers/block/
+F: fs/block_dev.c
F: include/linux/blk*
F: kernel/trace/blktrace.c
F: lib/sbitmap.c
@@ -3204,8 +3213,9 @@
BLUETOOTH DRIVERS
M: Marcel Holtmann <marcel@holtmann.org>
M: Johan Hedberg <johan.hedberg@gmail.com>
+M: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
L: linux-bluetooth@vger.kernel.org
-S: Maintained
+S: Supported
W: http://www.bluez.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
@@ -3214,8 +3224,9 @@
BLUETOOTH SUBSYSTEM
M: Marcel Holtmann <marcel@holtmann.org>
M: Johan Hedberg <johan.hedberg@gmail.com>
+M: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
L: linux-bluetooth@vger.kernel.org
-S: Maintained
+S: Supported
W: http://www.bluez.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
@@ -3387,7 +3398,7 @@
L: netdev@vger.kernel.org
L: openwrt-devel@lists.openwrt.org (subscribers-only)
S: Supported
-F: Documentation/devicetree/bindings/net/dsa/b53.txt
+F: Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
F: drivers/net/dsa/b53/*
F: include/linux/platform_data/b53.h
@@ -3580,6 +3591,14 @@
F: Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
F: drivers/usb/host/ehci-brcm.*
+BROADCOM BRCMSTB USB PIN MAP DRIVER
+M: Al Cooper <alcooperx@gmail.com>
+L: linux-usb@vger.kernel.org
+L: bcm-kernel-feedback-list@broadcom.com
+S: Maintained
+F: Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
+F: drivers/usb/misc/brcmstb-usb-pinmap.c
+
BROADCOM BRCMSTB USB2 and USB3 PHY DRIVER
M: Al Cooper <alcooperx@gmail.com>
L: linux-kernel@vger.kernel.org
@@ -3865,6 +3884,7 @@
M: Peter Chen <peter.chen@nxp.com>
M: Pawel Laszczak <pawell@cadence.com>
M: Roger Quadros <rogerq@ti.com>
+R: Aswath Govindraju <a-govindraju@ti.com>
L: linux-usb@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
@@ -3880,9 +3900,8 @@
F: drivers/media/radio/radio-cadet*
CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER
-M: Jonathan Corbet <corbet@lwn.net>
L: linux-media@vger.kernel.org
-S: Maintained
+S: Orphan
T: git git://linuxtv.org/media_tree.git
F: Documentation/admin-guide/media/cafe_ccic*
F: drivers/media/platform/marvell-ccic/
@@ -4336,8 +4355,8 @@
F: drivers/media/pci/cobalt/
COCCINELLE/Semantic Patches (SmPL)
-M: Julia Lawall <Julia.Lawall@lip6.fr>
-M: Gilles Muller <Gilles.Muller@lip6.fr>
+M: Julia Lawall <Julia.Lawall@inria.fr>
+M: Gilles Muller <Gilles.Muller@inria.fr>
M: Nicolas Palix <nicolas.palix@imag.fr>
M: Michal Marek <michal.lkml@markovi.net>
L: cocci@systeme.lip6.fr (moderated for non-subscribers)
@@ -4363,7 +4382,7 @@
M: Philipp Zabel <p.zabel@pengutronix.de>
L: linux-media@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/media/coda.txt
+F: Documentation/devicetree/bindings/media/coda.yaml
F: drivers/media/platform/coda/
CODE OF CONDUCT
@@ -4505,6 +4524,13 @@
S: Maintained
F: drivers/hwmon/corsair-cpro.c
+CORSAIR-PSU HARDWARE MONITOR DRIVER
+M: Wilken Gottwalt <wilken.gottwalt@posteo.net>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/corsair-psu.rst
+F: drivers/hwmon/corsair-psu.c
+
COSA/SRP SYNC SERIAL DRIVER
M: Jan "Yenya" Kasprzak <kas@fi.muni.cz>
S: Maintained
@@ -5000,6 +5026,15 @@
S: Maintained
F: drivers/platform/x86/dell-wmi-descriptor.c
+DELL WMI SYSMAN DRIVER
+M: Divya Bharathi <divya.bharathi@dell.com>
+M: Mario Limonciello <mario.limonciello@dell.com>
+M: Prasanth Ksr <prasanth.ksr@dell.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: Documentation/ABI/testing/sysfs-class-firmware-attributes
+F: drivers/platform/x86/dell-wmi-sysman/
+
DELL WMI NOTIFICATIONS DRIVER
M: Matthew Garrett <mjg59@srcf.ucam.org>
M: Pali Rohár <pali@kernel.org>
@@ -5129,7 +5164,9 @@
S: Supported
W: http://www.dialog-semiconductor.com/products
F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/input/dlg,da72??.txt
F: Documentation/devicetree/bindings/mfd/da90*.txt
+F: Documentation/devicetree/bindings/regulator/dlg,da9*.yaml
F: Documentation/devicetree/bindings/regulator/da92*.txt
F: Documentation/devicetree/bindings/regulator/slg51000.txt
F: Documentation/devicetree/bindings/sound/da[79]*.txt
@@ -5139,6 +5176,7 @@
F: drivers/gpio/gpio-da90??.c
F: drivers/hwmon/da90??-hwmon.c
F: drivers/iio/adc/da91??-*.c
+F: drivers/input/misc/da72??.[ch]
F: drivers/input/misc/da90??_onkey.c
F: drivers/input/touchscreen/da9052_tsi.c
F: drivers/leds/leds-da90??.c
@@ -5154,6 +5192,7 @@
F: drivers/thermal/da90??-thermal.c
F: drivers/video/backlight/da90??_bl.c
F: drivers/watchdog/da90??_wdt.c
+F: include/dt-bindings/regulator/dlg,da9*-regulator.h
F: include/linux/mfd/da903x.h
F: include/linux/mfd/da9052/
F: include/linux/mfd/da9055/
@@ -5259,6 +5298,12 @@
F: include/linux/dma-map-ops.h
F: kernel/dma/
+DMA MAPPING BENCHMARK
+M: Barry Song <song.bao.hua@hisilicon.com>
+L: iommu@lists.linux-foundation.org
+F: kernel/dma/map_benchmark.c
+F: tools/testing/selftests/dma/
+
DMA-BUF HEAPS FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Benjamin Gaignard <benjamin.gaignard@linaro.org>
@@ -5588,6 +5633,13 @@
F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
F: drivers/gpu/drm/panel/panel-novatek-nt35510.c
+DRM DRIVER FOR NOVATEK NT36672A PANELS
+M: Sumit Semwal <sumit.semwal@linaro.org>
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
+F: drivers/gpu/drm/panel/panel-novatek-nt36672a.c
+
DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
M: Ben Skeggs <bskeggs@redhat.com>
L: dri-devel@lists.freedesktop.org
@@ -5875,6 +5927,7 @@
F: Documentation/devicetree/bindings/display/mediatek/
F: drivers/gpu/drm/mediatek/
F: drivers/phy/mediatek/phy-mtk-hdmi*
+F: drivers/phy/mediatek/phy-mtk-mipi*
DRM DRIVERS FOR NVIDIA TEGRA
M: Thierry Reding <thierry.reding@gmail.com>
@@ -5967,6 +6020,7 @@
DRM DRIVERS FOR VC4
M: Eric Anholt <eric@anholt.net>
+M: Maxime Ripard <mripard@kernel.org>
S: Supported
T: git git://github.com/anholt/linux
T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -6361,6 +6415,13 @@
S: Maintained
F: drivers/edac/ie31200_edac.c
+EDAC-IGEN6
+M: Tony Luck <tony.luck@intel.com>
+R: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
+L: linux-edac@vger.kernel.org
+S: Maintained
+F: drivers/edac/igen6_edac.c
+
EDAC-MPC85XX
M: Johannes Thumshirn <morbidrsa@gmail.com>
L: linux-edac@vger.kernel.org
@@ -6410,7 +6471,7 @@
M: Tony Luck <tony.luck@intel.com>
L: linux-edac@vger.kernel.org
S: Maintained
-F: drivers/edac/skx_*.c
+F: drivers/edac/skx_*.[ch]
EDAC-TI
M: Tero Kristo <t-kristo@ti.com>
@@ -6694,6 +6755,7 @@
F: fs/f2fs/
F: include/linux/f2fs_fs.h
F: include/trace/events/f2fs.h
+F: include/uapi/linux/f2fs.h
F71805F HARDWARE MONITORING DRIVER
M: Jean Delvare <jdelvare@suse.com>
@@ -6917,17 +6979,10 @@
W: http://floatingpoint.sourceforge.net/emulator/index.html
F: arch/x86/math-emu/
-FRAME RELAY DLCI/FRAD (Sangoma drivers too)
-L: netdev@vger.kernel.org
-S: Orphan
-F: drivers/net/wan/dlci.c
-F: drivers/net/wan/sdla.c
-
FRAMEBUFFER LAYER
-M: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
L: dri-devel@lists.freedesktop.org
L: linux-fbdev@vger.kernel.org
-S: Maintained
+S: Orphan
Q: http://patchwork.kernel.org/project/linux-fbdev/list/
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/fb/
@@ -7304,7 +7359,6 @@
GCC PLUGINS
M: Kees Cook <keescook@chromium.org>
-R: Emese Revfy <re.emese@gmail.com>
L: linux-hardening@vger.kernel.org
S: Maintained
F: Documentation/kbuild/gcc-plugins.rst
@@ -7346,6 +7400,17 @@
F: drivers/base/arch_topology.c
F: include/linux/arch_topology.h
+GENERIC ENTRY CODE
+M: Thomas Gleixner <tglx@linutronix.de>
+M: Peter Zijlstra <peterz@infradead.org>
+M: Andy Lutomirski <luto@kernel.org>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/entry
+F: include/linux/entry-common.h
+F: include/linux/entry-kvm.h
+F: kernel/entry/
+
GENERIC GPIO I2C DRIVER
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
S: Supported
@@ -7444,7 +7509,7 @@
M: Andreas Gruenbacher <agruenba@redhat.com>
L: cluster-devel@redhat.com
S: Supported
-W: http://sources.redhat.com/cluster/
+B: https://bugzilla.kernel.org/enter_bug.cgi?product=File%20System&component=gfs2
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git
F: Documentation/filesystems/gfs2*
F: fs/gfs2/
@@ -7492,6 +7557,7 @@
L: linux-gpio@vger.kernel.org
L: linux-acpi@vger.kernel.org
S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel.git
F: Documentation/firmware-guide/acpi/gpio-properties.rst
F: drivers/gpio/gpiolib-acpi.c
F: drivers/gpio/gpiolib-acpi.h
@@ -7710,9 +7776,9 @@
F: drivers/irqchip/irq-renesas-h8*.c
HABANALABS PCI DRIVER
-M: Oded Gabbay <oded.gabbay@gmail.com>
+M: Oded Gabbay <ogabbay@kernel.org>
S: Supported
-T: git https://github.com/HabanaAI/linux.git
+T: git https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git
F: Documentation/ABI/testing/debugfs-driver-habanalabs
F: Documentation/ABI/testing/sysfs-driver-habanalabs
F: drivers/misc/habanalabs/
@@ -7910,12 +7976,27 @@
F: include/uapi/linux/if_hippi.h
F: net/802/hippi.c
+HIRSCHMANN HELLCREEK ETHERNET SWITCH DRIVER
+M: Kurt Kanzenbach <kurt@linutronix.de>
+L: netdev@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
+F: drivers/net/dsa/hirschmann/*
+F: include/linux/platform_data/hirschmann-hellcreek.h
+F: net/dsa/tag_hellcreek.c
+
HISILICON DMA DRIVER
M: Zhou Wang <wangzhou1@hisilicon.com>
L: dmaengine@vger.kernel.org
S: Maintained
F: drivers/dma/hisi_dma.c
+HISILICON GPIO DRIVER
+M: Luo Jiaxing <luojiaxing@huawei.com>
+L: linux-gpio@vger.kernel.org
+S: Maintained
+F: drivers/gpio/gpio-hisi.c
+
HISILICON HIGH PERFORMANCE RSA ENGINE DRIVER (HPRE)
M: Zaibo Xu <xuzaibo@huawei.com>
L: linux-crypto@vger.kernel.org
@@ -8008,7 +8089,7 @@
HISILICON TRUE RANDOM NUMBER GENERATOR V2 SUPPORT
M: Zaibo Xu <xuzaibo@huawei.com>
S: Maintained
-F: drivers/char/hw_random/hisi-trng-v2.c
+F: drivers/crypto/hisilicon/trng/trng.c
HISILICON V3XX SPI NOR FLASH Controller Driver
M: John Garry <john.garry@huawei.com>
@@ -8342,7 +8423,7 @@
F: drivers/i3c/master/dw*
I3C SUBSYSTEM
-M: Boris Brezillon <bbrezillon@kernel.org>
+M: Alexandre Belloni <alexandre.belloni@bootlin.com>
L: linux-i3c@lists.infradead.org (moderated for non-subscribers)
S: Maintained
C: irc://chat.freenode.net/linux-i3c
@@ -8636,7 +8717,7 @@
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/hwmon/ina2xx.txt
+F: Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
F: Documentation/hwmon/ina209.rst
F: drivers/hwmon/ina209.c
@@ -8682,19 +8763,16 @@
F: samples/bpf/ibumad_kern.c
F: samples/bpf/ibumad_user.c
-INGENIC JZ4780 DMA Driver
-M: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
-S: Maintained
-F: drivers/dma/dma-jz4780.c
-
INGENIC JZ4780 NAND DRIVER
M: Harvey Hunt <harveyhuntnexus@gmail.com>
L: linux-mtd@lists.infradead.org
+L: linux-mips@vger.kernel.org
S: Maintained
F: drivers/mtd/nand/raw/ingenic/
INGENIC JZ47xx SoCs
M: Paul Cercueil <paul@crapouillou.net>
+L: linux-mips@vger.kernel.org
S: Maintained
F: arch/mips/boot/dts/ingenic/
F: arch/mips/generic/board-ingenic.c
@@ -8967,6 +9045,23 @@
S: Maintained
F: drivers/char/hw_random/ixp4xx-rng.c
+INTEL KEEM BAY DRM DRIVER
+M: Anitha Chrisanthus <anitha.chrisanthus@intel.com>
+M: Edmund Dea <edmund.j.dea@intel.com>
+S: Maintained
+F: Documentation/devicetree/bindings/display/intel,kmb_display.yaml
+F: drivers/gpu/drm/kmb/
+
+INTEL KEEM BAY OCS AES/SM4 CRYPTO DRIVER
+M: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
+S: Maintained
+F: Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
+F: drivers/crypto/keembay/Kconfig
+F: drivers/crypto/keembay/Makefile
+F: drivers/crypto/keembay/keembay-ocs-aes-core.c
+F: drivers/crypto/keembay/ocs-aes.c
+F: drivers/crypto/keembay/ocs-aes.h
+
INTEL MANAGEMENT ENGINE (mei)
M: Tomas Winkler <tomas.winkler@intel.com>
L: linux-kernel@vger.kernel.org
@@ -9014,6 +9109,12 @@
F: include/linux/mfd/intel_msic.h
F: include/linux/mfd/intel_soc_pmic*
+INTEL PMT DRIVER
+M: "David E. Box" <david.e.box@linux.intel.com>
+S: Maintained
+F: drivers/mfd/intel_pmt.c
+F: drivers/platform/x86/intel_pmt_*
+
INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
M: Stanislav Yakovlev <stas.yakovlev@gmail.com>
L: linux-wireless@vger.kernel.org
@@ -9096,16 +9197,6 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi.git
F: drivers/net/wireless/intel/iwlwifi/
-INTEL WIRELESS WIMAX CONNECTION 2400
-M: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
-M: linux-wimax@intel.com
-L: wimax@linuxwimax.org (subscribers-only)
-S: Supported
-W: http://linuxwimax.org
-F: Documentation/admin-guide/wimax/i2400m.rst
-F: drivers/net/wimax/i2400m/
-F: include/uapi/linux/wimax/i2400m.h
-
INTEL WMI SLIM BOOTLOADER (SBL) FIRMWARE UPDATE DRIVER
M: Jithu Joseph <jithu.joseph@intel.com>
R: Maurice Ma <maurice.ma@intel.com>
@@ -9135,6 +9226,19 @@
F: arch/x86/kernel/tboot.c
F: include/linux/tboot.h
+INTEL SGX
+M: Jarkko Sakkinen <jarkko@kernel.org>
+L: linux-sgx@vger.kernel.org
+S: Supported
+Q: https://patchwork.kernel.org/project/intel-sgx/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git
+F: Documentation/x86/sgx.rst
+F: arch/x86/entry/vdso/vsgx.S
+F: arch/x86/include/uapi/asm/sgx.h
+F: arch/x86/kernel/cpu/sgx/*
+F: tools/testing/selftests/sgx/*
+K: \bSGX_
+
INTERCONNECT API
M: Georgi Djakov <georgi.djakov@linaro.org>
L: linux-pm@vger.kernel.org
@@ -9150,7 +9254,7 @@
M: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
L: linux-iio@vger.kernel.org
S: Maintained
-W https://invensense.tdk.com/
+W: https://invensense.tdk.com/
F: Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
F: drivers/iio/imu/inv_icm42600/
@@ -9630,7 +9734,7 @@
F: include/kvm/arm_*
KERNEL VIRTUAL MACHINE FOR MIPS (KVM/mips)
-M: Huacai Chen <chenhc@lemote.com>
+M: Huacai Chen <chenhuacai@kernel.org>
M: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
L: linux-mips@vger.kernel.org
L: kvm@vger.kernel.org
@@ -10176,6 +10280,16 @@
S: Maintained
F: lib/list-test.c
+LITEX PLATFORM
+M: Karol Gugala <kgugala@antmicro.com>
+M: Mateusz Holenko <mholenko@antmicro.com>
+S: Maintained
+F: Documentation/devicetree/bindings/*/litex,*.yaml
+F: arch/openrisc/boot/dts/or1klitex.dts
+F: drivers/soc/litex/litex_soc_ctrl.c
+F: drivers/tty/serial/liteuart.c
+F: include/linux/litex.h
+
LIVE PATCHING
M: Josh Poimboeuf <jpoimboe@redhat.com>
M: Jiri Kosina <jikos@kernel.org>
@@ -10381,6 +10495,8 @@
S: Maintained
W: http://www.mac.linux-m68k.org/
F: arch/m68k/mac/
+F: drivers/macintosh/adb-iop.c
+F: drivers/macintosh/via-macii.c
M68K ON HP9000/300
M: Philip Blundell <philb@gnu.org>
@@ -10434,6 +10550,15 @@
F: include/linux/mailbox_client.h
F: include/linux/mailbox_controller.h
+MAILBOX ARM MHUv2
+M: Viresh Kumar <viresh.kumar@linaro.org>
+M: Tushar Khandelwal <Tushar.Khandelwal@arm.com>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/mailbox/arm_mhuv2.c
+F: include/linux/mailbox/arm_mhuv2_message.h
+F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+
MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
M: Michael Kerrisk <mtk.manpages@gmail.com>
L: linux-man@vger.kernel.org
@@ -10480,6 +10605,7 @@
L: linux-crypto@vger.kernel.org
S: Maintained
F: drivers/crypto/marvell/
+F: include/linux/soc/marvell/octeontx2/
MARVELL GIGABIT ETHERNET DRIVERS (skge/sky2)
M: Mirko Lindner <mlindner@marvell.com>
@@ -10523,6 +10649,14 @@
S: Maintained
F: drivers/net/ethernet/marvell/mvneta.*
+MARVELL MVPP2 ETHERNET DRIVER
+M: Marcin Wojtas <mw@semihalf.com>
+M: Russell King <linux@armlinux.org.uk>
+L: netdev@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/net/marvell-pp2.txt
+F: drivers/net/ethernet/marvell/mvpp2/
+
MARVELL MWIFIEX WIRELESS DRIVER
M: Amitkumar Karwar <amitkarwar@gmail.com>
M: Ganapathi Bhat <ganapathi.bhat@nxp.com>
@@ -10552,6 +10686,7 @@
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/marvell/octeontx2/nic/
+F: include/linux/soc/marvell/octeontx2/
MARVELL OCTEONTX2 RVU ADMIN FUNCTION DRIVER
M: Sunil Goutham <sgoutham@marvell.com>
@@ -10839,8 +10974,8 @@
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/admin-guide/media/imx7.rst
-F: Documentation/devicetree/bindings/media/imx7-csi.txt
-F: Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
+F: Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+F: Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
F: drivers/staging/media/imx/imx7-media-csi.c
F: drivers/staging/media/imx/imx7-mipi-csis.c
@@ -11099,6 +11234,12 @@
F: Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
F: drivers/i2c/busses/i2c-mt7621.c
+MEDIATEK MT7621 PHY PCI DRIVER
+M: Sergio Paracuellos <sergio.paracuellos@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
+F: drivers/phy/ralink/phy-mt7621-pci.c
+
MEDIATEK NAND CONTROLLER DRIVER
L: linux-mtd@lists.infradead.org
S: Orphan
@@ -11177,6 +11318,7 @@
M: Khalil Blaiech <kblaiech@nvidia.com>
L: linux-i2c@vger.kernel.org
S: Supported
+F: Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml
F: drivers/i2c/busses/i2c-mlxbf.c
MELLANOX ETHERNET DRIVER (mlx4_en)
@@ -11323,6 +11465,7 @@
T: git git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git
F: Documentation/devicetree/bindings/memory-controllers/
F: drivers/memory/
+F: include/dt-bindings/memory/
MEMORY FREQUENCY SCALING DRIVERS FOR NVIDIA TEGRA
M: Dmitry Osipenko <digetx@gmail.com>
@@ -11330,7 +11473,6 @@
L: linux-tegra@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git
S: Maintained
-F: drivers/devfreq/tegra20-devfreq.c
F: drivers/devfreq/tegra30-devfreq.c
MEMORY MANAGEMENT
@@ -11403,6 +11545,15 @@
F: drivers/media/cec/platform/meson/ao-cec-g12a.c
F: drivers/media/cec/platform/meson/ao-cec.c
+MESON GE2D DRIVER FOR AMLOGIC SOCS
+M: Neil Armstrong <narmstrong@baylibre.com>
+L: linux-media@vger.kernel.org
+L: linux-amlogic@lists.infradead.org
+S: Supported
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
+F: drivers/media/meson/ge2d/
+
MESON NAND CONTROLLER DRIVER FOR AMLOGIC SOCS
M: Liang Yang <liang.yang@amlogic.com>
L: linux-mtd@lists.infradead.org
@@ -11519,7 +11670,7 @@
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/net/dsa/ksz.txt
+F: Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
F: drivers/net/dsa/microchip/*
F: include/linux/platform_data/microchip-ksz.h
F: net/dsa/tag_ksz.c
@@ -11641,17 +11792,54 @@
F: include/linux/cciss*.h
F: include/uapi/linux/cciss*.h
+MICROSOFT SURFACE GPE LID SUPPORT DRIVER
+M: Maximilian Luz <luzmaximilian@gmail.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/surface/surface_gpe.c
+
+MICROSOFT SURFACE HARDWARE PLATFORM SUPPORT
+M: Hans de Goede <hdegoede@redhat.com>
+M: Mark Gross <mgross@linux.intel.com>
+M: Maximilian Luz <luzmaximilian@gmail.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
+F: drivers/platform/surface/
+
MICROSOFT SURFACE PRO 3 BUTTON DRIVER
M: Chen Yu <yu.c.chen@intel.com>
L: platform-driver-x86@vger.kernel.org
S: Supported
-F: drivers/platform/x86/surfacepro3_button.c
+F: drivers/platform/surface/surfacepro3_button.c
MICROTEK X6 SCANNER
M: Oliver Neukum <oliver@neukum.org>
S: Maintained
F: drivers/usb/image/microtek.*
+MIKROTIK CRS3XX 98DX3236 BOARD SUPPORT
+M: Luka Kovacic <luka.kovacic@sartura.hr>
+M: Luka Perkov <luka.perkov@sartura.hr>
+S: Maintained
+F: arch/arm/boot/dts/armada-xp-crs305-1g-4s-bit.dts
+F: arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts
+F: arch/arm/boot/dts/armada-xp-crs326-24g-2s-bit.dts
+F: arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts
+F: arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s-bit.dts
+F: arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dts
+
+MIPI CCS, SMIA AND SMIA++ IMAGE SENSOR DRIVER
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
+F: Documentation/driver-api/media/drivers/ccs/
+F: drivers/media/i2c/ccs-pll.c
+F: drivers/media/i2c/ccs-pll.h
+F: drivers/media/i2c/ccs/
+F: include/uapi/linux/smiapp.h
+
MIPS
M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
L: linux-mips@vger.kernel.org
@@ -11719,7 +11907,7 @@
F: drivers/*/*loongson2*
MIPS/LOONGSON64 ARCHITECTURE
-M: Huacai Chen <chenhc@lemote.com>
+M: Huacai Chen <chenhuacai@kernel.org>
M: Jiaxun Yang <jiaxun.yang@flygoat.com>
L: linux-mips@vger.kernel.org
S: Maintained
@@ -11922,7 +12110,7 @@
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
+F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
F: drivers/media/i2c/mt9v111.c
MULTIFUNCTION DEVICES (MFD)
@@ -12266,6 +12454,7 @@
S: Maintained
W: https://github.com/multipath-tcp/mptcp_net-next/wiki
B: https://github.com/multipath-tcp/mptcp_net-next/issues
+F: Documentation/networking/mptcp-sysctl.rst
F: include/net/mptcp.h
F: include/uapi/linux/mptcp.h
F: net/mptcp/
@@ -12556,7 +12745,7 @@
M: Rui Miguel Silva <rmfrfs@gmail.com>
L: linux-iio@vger.kernel.org
S: Maintained
-F: Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt
+F: Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
F: drivers/iio/gyro/fxas21002c.h
F: drivers/iio/gyro/fxas21002c_core.c
F: drivers/iio/gyro/fxas21002c_i2c.c
@@ -12570,6 +12759,12 @@
F: Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
F: drivers/gpu/drm/imx/dcss/
+NXP PF8100/PF8121A/PF8200 PMIC REGULATOR DEVICE DRIVER
+M: Jagan Teki <jagan@amarulasolutions.com>
+S: Maintained
+F: Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
+F: drivers/regulator/pf8x00-regulator.c
+
NXP PTN5150A CC LOGIC AND EXTCON DRIVER
M: Krzysztof Kozlowski <krzk@kernel.org>
L: linux-kernel@vger.kernel.org
@@ -12867,6 +13062,14 @@
S: Maintained
F: drivers/char/pcmcia/cm4040_cs.*
+OMNIVISION OV02A10 SENSOR DRIVER
+M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+F: drivers/media/i2c/ov02a10.c
+
OMNIVISION OV13858 SENSOR DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
@@ -12879,7 +13082,7 @@
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/i2c/ov2680.txt
+F: Documentation/devicetree/bindings/media/i2c/ov2680.yaml
F: drivers/media/i2c/ov2680.c
OMNIVISION OV2685 SENSOR DRIVER
@@ -12937,9 +13140,8 @@
F: drivers/media/i2c/ov5695.c
OMNIVISION OV7670 SENSOR DRIVER
-M: Jonathan Corbet <corbet@lwn.net>
L: linux-media@vger.kernel.org
-S: Maintained
+S: Orphan
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ov7670.txt
F: drivers/media/i2c/ov7670.c
@@ -12949,7 +13151,7 @@
L: linux-media@vger.kernel.org
S: Odd fixes
T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/i2c/ov772x.txt
+F: Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
F: drivers/media/i2c/ov772x.c
F: include/media/i2c/ov772x.h
@@ -12985,6 +13187,14 @@
F: Documentation/devicetree/bindings/media/i2c/ov9650.txt
F: drivers/media/i2c/ov9650.c
+OMNIVISION OV9734 SENSOR DRIVER
+M: Tianshu Qiu <tian.shu.qiu@intel.com>
+R: Bingbu Cao <bingbu.cao@intel.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: drivers/media/i2c/ov9734.c
+
ONENAND FLASH DRIVER
M: Kyungmin Park <kyungmin.park@samsung.com>
L: linux-mtd@lists.infradead.org
@@ -13193,7 +13403,7 @@
F: net/core/page_pool.c
PANASONIC LAPTOP ACPI EXTRAS DRIVER
-M: Harald Welte <laforge@gnumonks.org>
+M: Kenneth Chan <kenneth.t.chan@gmail.com>
L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/panasonic-laptop.c
@@ -13492,6 +13702,8 @@
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
L: linux-pci@vger.kernel.org
S: Supported
+F: Documentation/PCI/endpoint/*
+F: Documentation/misc-devices/pci-endpoint-test.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git
F: drivers/misc/pci_endpoint_test.c
F: drivers/pci/endpoint/
@@ -13915,6 +14127,13 @@
S: Maintained
F: drivers/dma/plx_dma.c
+PM6764TR DRIVER
+M: Charles Hsu <hsu.yungteng@gmail.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/pm6764tr.rst
+F: drivers/hwmon/pmbus/pm6764tr.c
+
PM-GRAPH UTILITY
M: "Todd E Brandt" <todd.e.brandt@linux.intel.com>
L: linux-pm@vger.kernel.org
@@ -14457,6 +14676,7 @@
F: drivers/net/wireless/ath/ath9k/
QUALCOMM CAMERA SUBSYSTEM DRIVER
+M: Robert Foss <robert.foss@linaro.org>
M: Todor Tomov <todor.too@gmail.com>
L: linux-media@vger.kernel.org
S: Maintained
@@ -14538,6 +14758,14 @@
F: drivers/mailbox/qcom-ipcc.c
F: include/dt-bindings/mailbox/qcom-ipcc.h
+QUALCOMM IPQ4019 USB PHY DRIVER
+M: Robert Marko <robert.marko@sartura.hr>
+M: Luka Perkov <luka.perkov@sartura.hr>
+L: linux-arm-msm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml
+F: drivers/phy/qualcomm/phy-qcom-ipq4019-usb.c
+
QUALCOMM IPQ4019 VQMMC REGULATOR DRIVER
M: Robert Marko <robert.marko@sartura.hr>
M: Luka Perkov <luka.perkov@sartura.hr>
@@ -14887,7 +15115,7 @@
M: Geert Uytterhoeven <geert+renesas@glider.be>
L: linux-renesas-soc@vger.kernel.org
S: Supported
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git clk-renesas
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git renesas-clk
F: Documentation/devicetree/bindings/clock/renesas,*
F: drivers/clk/renesas/
@@ -14946,6 +15174,7 @@
S: Maintained
T: git git://git.pengutronix.de/git/pza/linux
F: Documentation/devicetree/bindings/reset/
+F: Documentation/driver-api/reset.rst
F: drivers/reset/
F: include/dt-bindings/reset/
F: include/linux/reset-controller.h
@@ -15030,10 +15259,13 @@
M: Helen Koike <helen.koike@collabora.com>
M: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
L: linux-media@vger.kernel.org
+L: linux-rockchip@lists.infradead.org
S: Maintained
F: Documentation/admin-guide/media/rkisp1.rst
+F: Documentation/devicetree/bindings/media/rockchip-isp1.yaml
F: Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
-F: drivers/staging/media/rkisp1/
+F: drivers/media/platform/rockchip/rkisp1
+F: include/uapi/linux/rkisp1-config.h
ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
M: Jacob Chen <jacob-chen@iotwrt.com>
@@ -15395,6 +15627,14 @@
S: Maintained
F: drivers/video/fbdev/s3c-fb.c
+SAMSUNG INTERCONNECT DRIVERS
+M: Sylwester Nawrocki <s.nawrocki@samsung.com>
+M: Artur Świgoń <a.swigon@samsung.com>
+L: linux-pm@vger.kernel.org
+L: linux-samsung-soc@vger.kernel.org
+S: Supported
+F: drivers/interconnect/samsung/
+
SAMSUNG LAPTOP DRIVER
M: Corentin Chary <corentin.chary@gmail.com>
L: platform-driver-x86@vger.kernel.org
@@ -15598,6 +15838,15 @@
F: drivers/scsi/st.*
F: drivers/scsi/st_*.h
+SCSI TARGET CORE USER DRIVER
+M: Bodo Stroesser <bostroesser@gmail.com>
+L: linux-scsi@vger.kernel.org
+L: target-devel@vger.kernel.org
+S: Supported
+F: Documentation/target/tcmu-design.rst
+F: drivers/target/target_core_user.c
+F: include/uapi/linux/target_core_user.h
+
SCSI TARGET SUBSYSTEM
M: "Martin K. Petersen" <martin.petersen@oracle.com>
L: linux-scsi@vger.kernel.org
@@ -15821,13 +16070,14 @@
K: phylink\.h|struct\s+phylink|\.phylink|>phylink_|phylink_(autoneg|clear|connect|create|destroy|disconnect|ethtool|helper|mac|mii|of|set|start|stop|test|validate)
SGI GRU DRIVER
-M: Dimitri Sivanich <sivanich@sgi.com>
+M: Dimitri Sivanich <dimitri.sivanich@hpe.com>
S: Maintained
F: drivers/misc/sgi-gru/
SGI XP/XPC/XPNET DRIVER
-M: Cliff Whickman <cpw@sgi.com>
M: Robin Holt <robinmholt@gmail.com>
+M: Steve Wahl <steve.wahl@hpe.com>
+R: Mike Travis <mike.travis@hpe.com>
S: Maintained
F: drivers/misc/sgi-xp/
@@ -16112,16 +16362,6 @@
F: drivers/firmware/smccc/
F: include/linux/arm-smccc.h
-SMIA AND SMIA++ IMAGE SENSOR DRIVER
-M: Sakari Ailus <sakari.ailus@linux.intel.com>
-L: linux-media@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
-F: drivers/media/i2c/smiapp-pll.c
-F: drivers/media/i2c/smiapp-pll.h
-F: drivers/media/i2c/smiapp/
-F: include/uapi/linux/smiapp.h
-
SMM665 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
@@ -16217,7 +16457,7 @@
F: include/uapi/rdma/siw-abi.h
SOFT-ROCE DRIVER (rxe)
-M: Zhu Yanjun <yanjunz@nvidia.com>
+M: Zhu Yanjun <zyjzyj2000@gmail.com>
L: linux-rdma@vger.kernel.org
S: Supported
F: drivers/infiniband/sw/rxe/
@@ -16284,7 +16524,7 @@
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
-F: Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
+F: Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
F: drivers/media/i2c/imx214.c
SONY IMX219 SENSOR DRIVER
@@ -16520,8 +16760,10 @@
F: drivers/net/ethernet/toshiba/spider_net*
SPMI SUBSYSTEM
-R: Stephen Boyd <sboyd@kernel.org>
-L: linux-arm-msm@vger.kernel.org
+M: Stephen Boyd <sboyd@kernel.org>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
F: Documentation/devicetree/bindings/spmi/
F: drivers/spmi/
F: include/dt-bindings/spmi/spmi.h
@@ -16675,6 +16917,22 @@
S: Odd Fixes
F: drivers/net/ethernet/adaptec/starfire*
+STATIC BRANCH/CALL
+M: Peter Zijlstra <peterz@infradead.org>
+M: Josh Poimboeuf <jpoimboe@redhat.com>
+M: Jason Baron <jbaron@akamai.com>
+R: Steven Rostedt <rostedt@goodmis.org>
+R: Ard Biesheuvel <ardb@kernel.org>
+S: Supported
+F: arch/*/include/asm/jump_label*.h
+F: arch/*/include/asm/static_call*.h
+F: arch/*/kernel/jump_label.c
+F: arch/*/kernel/static_call.c
+F: include/linux/jump_label*.h
+F: include/linux/static_call*.h
+F: kernel/jump_label.c
+F: kernel/static_call.c
+
STEC S1220 SKD DRIVER
M: Damien Le Moal <Damien.LeMoal@wdc.com>
L: linux-block@vger.kernel.org
@@ -17381,6 +17639,12 @@
T: git git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
F: drivers/platform/x86/thinkpad_acpi.c
+THUNDERBOLT DMA TRAFFIC TEST DRIVER
+M: Isaac Hazan <isaac.hazan@intel.com>
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/thunderbolt/dma_test.c
+
THUNDERBOLT DRIVER
M: Andreas Noever <andreas.noever@gmail.com>
M: Michael Jamet <michael.jamet@intel.com>
@@ -17761,6 +18025,7 @@
F: Documentation/trace/ftrace.rst
F: arch/*/*/*/ftrace.h
F: arch/*/kernel/ftrace.c
+F: fs/tracefs/
F: include/*/ftrace.h
F: include/linux/trace*.h
F: include/trace/
@@ -18380,6 +18645,12 @@
F: lib/test_uuid.c
F: lib/uuid.c
+UV SYSFS DRIVER
+M: Justin Ernst <justin.ernst@hpe.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/uv_sysfs.c
+
UVESAFB DRIVER
M: Michal Januszewski <spock@gentoo.org>
L: linux-fbdev@vger.kernel.org
@@ -18902,18 +19173,6 @@
W: https://wireless.wiki.kernel.org/en/users/Drivers/wil6210
F: drivers/net/wireless/ath/wil6210/
-WIMAX STACK
-M: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
-M: linux-wimax@intel.com
-L: wimax@linuxwimax.org (subscribers-only)
-S: Supported
-W: http://linuxwimax.org
-F: Documentation/admin-guide/wimax/wimax.rst
-F: include/linux/wimax/debug.h
-F: include/net/wimax.h
-F: include/uapi/linux/wimax.h
-F: net/wimax/
-
WINBOND CIR DRIVER
M: David Härdeman <david@hardeman.nu>
S: Maintained
@@ -19086,6 +19345,7 @@
X86 PLATFORM UV HPE SUPERDOME FLEX
M: Steve Wahl <steve.wahl@hpe.com>
+R: Mike Travis <mike.travis@hpe.com>
R: Dimitri Sivanich <dimitri.sivanich@hpe.com>
R: Russ Anderson <russ.anderson@hpe.com>
S: Supported
@@ -19272,6 +19532,16 @@
F: Documentation/devicetree/bindings/net/can/xilinx_can.txt
F: drivers/net/can/xilinx_can.c
+XILINX GPIO DRIVER
+M: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
+R: Srinivas Neeli <srinivas.neeli@xilinx.com>
+R: Michal Simek <michal.simek@xilinx.com>
+S: Maintained
+F: Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+F: Documentation/devicetree/bindings/gpio/gpio-zynq.txt
+F: drivers/gpio/gpio-xilinx.c
+F: drivers/gpio/gpio-zynq.c
+
XILINX SD-FEC IP CORES
M: Derek Kiernan <derek.kiernan@xilinx.com>
M: Dragan Cvetic <dragan.cvetic@xilinx.com>
@@ -19428,6 +19698,13 @@
F: Documentation/filesystems/zonefs.rst
F: fs/zonefs/
+ZPOOL COMPRESSED PAGE STORAGE API
+M: Dan Streetman <ddstreet@ieee.org>
+L: linux-mm@kvack.org
+S: Maintained
+F: include/linux/zpool.h
+F: mm/zpool.c
+
ZR36067 VIDEO FOR LINUX DRIVER
M: Corentin Labbe <clabbe@baylibre.com>
L: mjpeg-users@lists.sourceforge.net
@@ -19438,13 +19715,6 @@
F: Documentation/driver-api/media/drivers/zoran.rst
F: drivers/staging/media/zoran/
-ZPOOL COMPRESSED PAGE STORAGE API
-M: Dan Streetman <ddstreet@ieee.org>
-L: linux-mm@kvack.org
-S: Maintained
-F: include/linux/zpool.h
-F: mm/zpool.c
-
ZRAM COMPRESSED RAM BLOCK DEVICE DRVIER
M: Minchan Kim <minchan@kernel.org>
M: Nitin Gupta <ngupta@vflare.org>
diff --git a/Makefile b/Makefile
index e30cf02..29c3eec 100644
--- a/Makefile
+++ b/Makefile
@@ -450,7 +450,7 @@
YACC = bison
AWK = awk
INSTALLKERNEL := installkernel
-DEPMOD = /sbin/depmod
+DEPMOD = depmod
PERL = perl
PYTHON = python
PYTHON3 = python3
diff --git a/arch/Kconfig b/arch/Kconfig
index ba4e966..78c6f05 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -143,6 +143,22 @@
managed by the kernel and kept transparent to the probed
application. )
+config HAVE_64BIT_ALIGNED_ACCESS
+ def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
+ help
+ Some architectures require 64 bit accesses to be 64 bit
+ aligned, which also requires structs containing 64 bit values
+ to be 64 bit aligned too. This includes some 32 bit
+ architectures which can do 64 bit accesses, as well as 64 bit
+ architectures without unaligned access.
+
+ This symbol should be selected by an architecture if 64 bit
+ accesses are required to be 64 bit aligned in this way even
+ though it is not a 64 bit architecture.
+
+ See Documentation/unaligned-memory-access.txt for more
+ information on the topic of unaligned memory accesses.
+
config HAVE_EFFICIENT_UNALIGNED_ACCESS
bool
help
@@ -261,7 +277,7 @@
#
# Select if the architecture provides the arch_dma_set_uncached symbol to
-# either provide an uncached segement alias for a DMA allocation, or
+# either provide an uncached segment alias for a DMA allocation, or
# to remap the page tables in place.
#
config ARCH_HAS_DMA_SET_UNCACHED
@@ -314,14 +330,14 @@
config HAVE_ASM_MODVERSIONS
bool
help
- This symbol should be selected by an architecure if it provides
+ This symbol should be selected by an architecture if it provides
<asm/asm-prototypes.h> to support the module versioning for symbols
exported from assembly code.
config HAVE_REGS_AND_STACK_ACCESS_API
bool
help
- This symbol should be selected by an architecure if it supports
+ This symbol should be selected by an architecture if it supports
the API needed to access registers and stack entries from pt_regs,
declared in asm/ptrace.h
For example the kprobes-based event tracer needs this API.
@@ -336,7 +352,7 @@
config HAVE_FUNCTION_ARG_ACCESS_API
bool
help
- This symbol should be selected by an architecure if it supports
+ This symbol should be selected by an architecture if it supports
the API needed to access function arguments from pt_regs,
declared in asm/ptrace.h
@@ -486,6 +502,9 @@
- secure_computing return value is checked and a return value of -1
results in the system call being skipped immediately.
- seccomp syscall wired up
+ - if !HAVE_SPARSE_SYSCALL_NR, have SECCOMP_ARCH_NATIVE,
+ SECCOMP_ARCH_NATIVE_NR, SECCOMP_ARCH_NATIVE_NAME defined. If
+ COMPAT is supported, have the SECCOMP_ARCH_COMPAT* defines too.
config SECCOMP
prompt "Enable seccomp to safely execute untrusted bytecode"
@@ -514,6 +533,20 @@
See Documentation/userspace-api/seccomp_filter.rst for details.
+config SECCOMP_CACHE_DEBUG
+ bool "Show seccomp filter cache status in /proc/pid/seccomp_cache"
+ depends on SECCOMP_FILTER && !HAVE_SPARSE_SYSCALL_NR
+ depends on PROC_FS
+ help
+ This enables the /proc/pid/seccomp_cache interface to monitor
+ seccomp cache data. The file format is subject to change. Reading
+ the file requires CAP_SYS_ADMIN.
+
+ This option is for debugging only. Enabling presents the risk that
+ an adversary may be able to infer the seccomp filter logic.
+
+ If unsure, say N.
+
config HAVE_ARCH_STACKLEAK
bool
help
@@ -618,6 +651,23 @@
protected inside rcu_irq_enter/rcu_irq_exit() but preemption or signal
handling on irq exit still need to be protected.
+config HAVE_CONTEXT_TRACKING_OFFSTACK
+ bool
+ help
+ Architecture neither relies on exception_enter()/exception_exit()
+ nor on schedule_user(). Also preempt_schedule_notrace() and
+ preempt_schedule_irq() can't be called in a preemptible section
+ while context tracking is CONTEXT_USER. This feature reflects a sane
+ entry implementation where the following requirements are met on
+ critical entry code, ie: before user_exit() or after user_enter():
+
+ - Critical entry code isn't preemptible (or better yet:
+ not interruptible).
+ - No use of RCU read side critical sections, unless rcu_nmi_enter()
+ got called.
+ - No use of instrumentation, unless instrumentation_begin() got
+ called.
+
config HAVE_TIF_NOHZ
bool
help
@@ -627,6 +677,12 @@
config HAVE_VIRT_CPU_ACCOUNTING
bool
+config HAVE_VIRT_CPU_ACCOUNTING_IDLE
+ bool
+ help
+ Architecture has its own way to account idle CPU time and therefore
+ doesn't implement vtime_account_idle().
+
config ARCH_HAS_SCALED_CPUTIME
bool
@@ -641,13 +697,19 @@
some 32-bit arches may require multiple accesses, so proper
locking is needed to protect against concurrent accesses.
-
config HAVE_IRQ_TIME_ACCOUNTING
bool
help
Archs need to ensure they use a high enough resolution clock to
support irq time accounting and then call enable_sched_clock_irqtime().
+config HAVE_MOVE_PUD
+ bool
+ help
+ Architectures that select this are able to move page tables at the
+ PUD level. If there are only 3 page table levels, the move effectively
+ happens at the PGD level.
+
config HAVE_MOVE_PMD
bool
help
@@ -914,16 +976,16 @@
default y
bool "Use a virtually-mapped stack"
depends on HAVE_ARCH_VMAP_STACK
- depends on !KASAN || KASAN_VMALLOC
+ depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC
help
Enable this if you want the use virtually-mapped kernel stacks
with guard pages. This causes kernel stack overflows to be
caught immediately rather than causing difficult-to-diagnose
corruption.
- To use this with KASAN, the architecture must support backing
- virtual mappings with real shadow memory, and KASAN_VMALLOC must
- be enabled.
+ To use this with software KASAN modes, the architecture must support
+ backing virtual mappings with real shadow memory, and KASAN_VMALLOC
+ must be enabled.
config ARCH_OPTIONAL_KERNEL_RWX
def_bool n
@@ -1037,6 +1099,12 @@
by the linker, since the locations of such sections can change between linker
versions.
+config HAVE_ARCH_PFN_VALID
+ bool
+
+config ARCH_SUPPORTS_DEBUG_PAGEALLOC
+ bool
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index d6e9fc7..1f51437 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -27,7 +27,6 @@
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select AUDIT_ARCH
- select GENERIC_CLOCKEVENTS
select GENERIC_CPU_VULNERABILITIES
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
@@ -40,6 +39,7 @@
select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
select MMU_GATHER_NO_RANGE
select SET_FS
+ select SPARSEMEM_EXTREME if SPARSEMEM
help
The Alpha is a 64-bit general-purpose processor designed and
marketed by the Digital Equipment Corporation of blessed memory,
@@ -551,12 +551,19 @@
config ARCH_DISCONTIGMEM_ENABLE
bool "Discontiguous Memory Support"
+ depends on BROKEN
help
Say Y to support efficient handling of discontiguous physical memory,
for architectures which are either NUMA (Non-Uniform Memory Access)
or have huge holes in the physical address space for other reasons.
See <file:Documentation/vm/numa.rst> for more.
+config ARCH_SPARSEMEM_ENABLE
+ bool "Sparse Memory Support"
+ help
+ Say Y to support efficient handling of discontiguous physical memory,
+ for systems that have huge holes in the physical address space.
+
config NUMA
bool "NUMA Support (EXPERIMENTAL)"
depends on DISCONTIGMEM && BROKEN
diff --git a/arch/alpha/include/asm/kmap_types.h b/arch/alpha/include/asm/kmap_types.h
deleted file mode 100644
index 651714b..0000000
--- a/arch/alpha/include/asm/kmap_types.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_KMAP_TYPES_H
-#define _ASM_KMAP_TYPES_H
-
-/* Dummy header just to define km_type. */
-
-#ifdef CONFIG_DEBUG_HIGHMEM
-#define __WITH_KM_FENCE
-#endif
-
-#include <asm-generic/kmap_types.h>
-
-#undef __WITH_KM_FENCE
-
-#endif
diff --git a/arch/alpha/include/asm/mmu_context.h b/arch/alpha/include/asm/mmu_context.h
index 6d7d9bc1..4eea7c6 100644
--- a/arch/alpha/include/asm/mmu_context.h
+++ b/arch/alpha/include/asm/mmu_context.h
@@ -214,8 +214,6 @@ ev4_activate_mm(struct mm_struct *prev_mm, struct mm_struct *next_mm)
tbiap();
}
-#define deactivate_mm(tsk,mm) do { } while (0)
-
#ifdef CONFIG_ALPHA_GENERIC
# define switch_mm(a,b,c) alpha_mv.mv_switch_mm((a),(b),(c))
# define activate_mm(x,y) alpha_mv.mv_activate_mm((x),(y))
@@ -229,6 +227,7 @@ ev4_activate_mm(struct mm_struct *prev_mm, struct mm_struct *next_mm)
# endif
#endif
+#define init_new_context init_new_context
static inline int
init_new_context(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -242,12 +241,7 @@ init_new_context(struct task_struct *tsk, struct mm_struct *mm)
return 0;
}
-extern inline void
-destroy_context(struct mm_struct *mm)
-{
- /* Nothing to do. */
-}
-
+#define enter_lazy_tlb enter_lazy_tlb
static inline void
enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
{
@@ -255,6 +249,8 @@ enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
= ((unsigned long)mm->pgd - IDENT_ADDR) >> PAGE_SHIFT;
}
+#include <asm-generic/mmu_context.h>
+
#ifdef __MMU_EXTERN_INLINE
#undef __EXTERN_INLINE
#undef __MMU_EXTERN_INLINE
diff --git a/arch/alpha/include/asm/mmzone.h b/arch/alpha/include/asm/mmzone.h
index 9b521c8..8664460 100644
--- a/arch/alpha/include/asm/mmzone.h
+++ b/arch/alpha/include/asm/mmzone.h
@@ -6,6 +6,8 @@
#ifndef _ASM_MMZONE_H_
#define _ASM_MMZONE_H_
+#ifdef CONFIG_DISCONTIGMEM
+
#include <asm/smp.h>
/*
@@ -45,8 +47,6 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p, int n)
}
#endif
-#ifdef CONFIG_DISCONTIGMEM
-
/*
* Following are macros that each numa implementation must define.
*/
@@ -68,11 +68,6 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p, int n)
/* XXX: FIXME -- nyc */
#define kern_addr_valid(kaddr) (0)
-#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
-
-#define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> 32))
-#define pte_pfn(pte) (pte_val(pte) >> 32)
-
#define mk_pte(page, pgprot) \
({ \
pte_t pte; \
@@ -95,16 +90,11 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p, int n)
__xx; \
})
-#define page_to_pa(page) \
- (page_to_pfn(page) << PAGE_SHIFT)
-
#define pfn_to_nid(pfn) pa_to_nid(((u64)(pfn) << PAGE_SHIFT))
#define pfn_valid(pfn) \
(((pfn) - node_start_pfn(pfn_to_nid(pfn))) < \
node_spanned_pages(pfn_to_nid(pfn))) \
-#define virt_addr_valid(kaddr) pfn_valid((__pa(kaddr) >> PAGE_SHIFT))
-
#endif /* CONFIG_DISCONTIGMEM */
#endif /* _ASM_MMZONE_H_ */
diff --git a/arch/alpha/include/asm/page.h b/arch/alpha/include/asm/page.h
index e241bd8..268f99b4 100644
--- a/arch/alpha/include/asm/page.h
+++ b/arch/alpha/include/asm/page.h
@@ -83,12 +83,13 @@ typedef struct page *pgtable_t;
#define __pa(x) ((unsigned long) (x) - PAGE_OFFSET)
#define __va(x) ((void *)((unsigned long) (x) + PAGE_OFFSET))
-#ifndef CONFIG_DISCONTIGMEM
-#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+#define virt_addr_valid(kaddr) pfn_valid((__pa(kaddr) >> PAGE_SHIFT))
+
+#ifdef CONFIG_FLATMEM
#define pfn_valid(pfn) ((pfn) < max_mapnr)
-#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
-#endif /* CONFIG_DISCONTIGMEM */
+#endif /* CONFIG_FLATMEM */
#include <asm-generic/memory_model.h>
#include <asm-generic/getorder.h>
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 660b14c..8d856c6 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -203,10 +203,10 @@ extern unsigned long __zero_page(void);
* Conversion functions: convert a page and protection to a page entry,
* and a page entry and page directory to the page they refer to.
*/
-#ifndef CONFIG_DISCONTIGMEM
-#define page_to_pa(page) (((page) - mem_map) << PAGE_SHIFT)
-
+#define page_to_pa(page) (page_to_pfn(page) << PAGE_SHIFT)
#define pte_pfn(pte) (pte_val(pte) >> 32)
+
+#ifndef CONFIG_DISCONTIGMEM
#define pte_page(pte) pfn_to_page(pte_pfn(pte))
#define mk_pte(page, pgprot) \
({ \
@@ -236,10 +236,8 @@ pmd_page_vaddr(pmd_t pmd)
return ((pmd_val(pmd) & _PFN_MASK) >> (32-PAGE_SHIFT)) + PAGE_OFFSET;
}
-#ifndef CONFIG_DISCONTIGMEM
-#define pmd_page(pmd) (mem_map + ((pmd_val(pmd) & _PFN_MASK) >> 32))
-#define pud_page(pud) (mem_map + ((pud_val(pud) & _PFN_MASK) >> 32))
-#endif
+#define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> 32))
+#define pud_page(pud) (pfn_to_page(pud_val(pud) >> 32))
extern inline unsigned long pud_page_vaddr(pud_t pgd)
{ return PAGE_OFFSET + ((pud_val(pgd) & _PFN_MASK) >> (32-PAGE_SHIFT)); }
diff --git a/arch/alpha/include/asm/sparsemem.h b/arch/alpha/include/asm/sparsemem.h
new file mode 100644
index 0000000..a0820fd
--- /dev/null
+++ b/arch/alpha/include/asm/sparsemem.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ALPHA_SPARSEMEM_H
+#define _ASM_ALPHA_SPARSEMEM_H
+
+#ifdef CONFIG_SPARSEMEM
+
+#define SECTION_SIZE_BITS 27
+
+/*
+ * According to "Alpha Architecture Reference Manual" physical
+ * addresses are at most 48 bits.
+ * https://download.majix.org/dec/alpha_arch_ref.pdf
+ */
+#define MAX_PHYSMEM_BITS 48
+
+#endif /* CONFIG_SPARSEMEM */
+
+#endif /* _ASM_ALPHA_SPARSEMEM_H */
diff --git a/arch/alpha/include/asm/thread_info.h b/arch/alpha/include/asm/thread_info.h
index 807d7b9..2592356 100644
--- a/arch/alpha/include/asm/thread_info.h
+++ b/arch/alpha/include/asm/thread_info.h
@@ -62,6 +62,7 @@ register struct thread_info *__current_thread_info __asm__("$8");
#define TIF_SIGPENDING 2 /* signal pending */
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
#define TIF_SYSCALL_AUDIT 4 /* syscall audit active */
+#define TIF_NOTIFY_SIGNAL 5 /* signal notifications exist */
#define TIF_DIE_IF_KERNEL 9 /* dik recursion lock */
#define TIF_MEMDIE 13 /* is terminating due to OOM killer */
#define TIF_POLLING_NRFLAG 14 /* idle is polling for TIF_NEED_RESCHED */
@@ -71,6 +72,7 @@ register struct thread_info *__current_thread_info __asm__("$8");
#define _TIF_NEED_RESCHED (1<<TIF_NEED_RESCHED)
#define _TIF_NOTIFY_RESUME (1<<TIF_NOTIFY_RESUME)
#define _TIF_SYSCALL_AUDIT (1<<TIF_SYSCALL_AUDIT)
+#define _TIF_NOTIFY_SIGNAL (1<<TIF_NOTIFY_SIGNAL)
#define _TIF_POLLING_NRFLAG (1<<TIF_POLLING_NRFLAG)
/* Work to do on interrupt/exception return. */
diff --git a/arch/alpha/include/uapi/asm/signal.h b/arch/alpha/include/uapi/asm/signal.h
index 74c750b..a69dd8d 100644
--- a/arch/alpha/include/uapi/asm/signal.h
+++ b/arch/alpha/include/uapi/asm/signal.h
@@ -60,20 +60,6 @@ typedef unsigned long sigset_t;
#define SIGRTMIN 32
#define SIGRTMAX _NSIG
-/*
- * SA_FLAGS values:
- *
- * SA_ONSTACK indicates that a registered stack_t will be used.
- * SA_RESTART flag to get restarting signals (which were the default long ago)
- * SA_NOCLDSTOP flag to turn off SIGCHLD when children stop.
- * SA_RESETHAND clears the handler when the signal is delivered.
- * SA_NOCLDWAIT flag on SIGCHLD to inhibit zombies.
- * SA_NODEFER prevents the current signal from being masked in the handler.
- *
- * SA_ONESHOT and SA_NOMASK are the historical Linux names for the Single
- * Unix names RESETHAND and NODEFER respectively.
- */
-
#define SA_ONSTACK 0x00000001
#define SA_RESTART 0x00000002
#define SA_NOCLDSTOP 0x00000004
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index de6c4df..5742035 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -124,6 +124,9 @@
#define SO_DETACH_REUSEPORT_BPF 68
+#define SO_PREFER_BUSY_POLL 69
+#define SO_BUSY_POLL_BUDGET 70
+
#if !defined(__KERNEL__)
#if __BITS_PER_LONG == 64
diff --git a/arch/alpha/kernel/entry.S b/arch/alpha/kernel/entry.S
index 2e09248..e227f3a 100644
--- a/arch/alpha/kernel/entry.S
+++ b/arch/alpha/kernel/entry.S
@@ -544,7 +544,7 @@
.align 4
.type work_pending, @function
work_pending:
- and $17, _TIF_NOTIFY_RESUME | _TIF_SIGPENDING, $2
+ and $17, _TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL, $2
bne $2, $work_notifysig
$work_resched:
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 4c7b041..6c71554 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -134,7 +134,7 @@ common_shutdown_1(void *generic_ptr)
#ifdef CONFIG_DUMMY_CONSOLE
/* If we've gotten here after SysRq-b, leave interrupt
context before taking over the console. */
- if (in_interrupt())
+ if (in_irq())
irq_exit();
/* This has the effect of resetting the VGA video origin. */
console_lock();
diff --git a/arch/alpha/kernel/rtc.c b/arch/alpha/kernel/rtc.c
index 1b1d596..ce30779 100644
--- a/arch/alpha/kernel/rtc.c
+++ b/arch/alpha/kernel/rtc.c
@@ -216,6 +216,6 @@ alpha_rtc_init(void)
rtc->ops = &remote_rtc_ops;
#endif
- return rtc_register_device(rtc);
+ return devm_rtc_register_device(rtc);
}
device_initcall(alpha_rtc_init);
diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index 916e42d..03dda3b 100644
--- a/arch/alpha/kernel/setup.c
+++ b/arch/alpha/kernel/setup.c
@@ -648,6 +648,7 @@ setup_arch(char **cmdline_p)
/* Find our memory. */
setup_memory(kernel_end);
memblock_set_bottom_up(true);
+ sparse_init();
/* First guess at cpu cache sizes. Do this before init_arch. */
determine_cpu_caches(cpu->type);
diff --git a/arch/alpha/kernel/signal.c b/arch/alpha/kernel/signal.c
index 3739efc..948b897 100644
--- a/arch/alpha/kernel/signal.c
+++ b/arch/alpha/kernel/signal.c
@@ -527,7 +527,7 @@ do_work_pending(struct pt_regs *regs, unsigned long thread_flags,
schedule();
} else {
local_irq_enable();
- if (thread_flags & _TIF_SIGPENDING) {
+ if (thread_flags & (_TIF_SIGPENDING|_TIF_NOTIFY_SIGNAL)) {
do_signal(regs, r0, r19);
r0 = 0;
} else {
diff --git a/arch/alpha/kernel/sys_jensen.c b/arch/alpha/kernel/sys_jensen.c
index 0a2ab6c..e5d870f 100644
--- a/arch/alpha/kernel/sys_jensen.c
+++ b/arch/alpha/kernel/sys_jensen.c
@@ -7,7 +7,7 @@
*
* Code supporting the Jensen.
*/
-
+#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/mm.h>
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index ee7b01b..a661706 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -480,3 +480,4 @@
548 common pidfd_getfd sys_pidfd_getfd
549 common faccessat2 sys_faccessat2
550 common process_madvise sys_process_madvise
+551 common epoll_pwait2 sys_epoll_pwait2
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 0a89cc9..b55ca77 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -19,7 +19,6 @@
select COMMON_CLK
select DMA_DIRECT_REMAP
select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
- select GENERIC_CLOCKEVENTS
select GENERIC_FIND_FIRST_BIT
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
@@ -67,6 +66,7 @@
config ARCH_DISCONTIGMEM_ENABLE
def_bool n
+ depends on BROKEN
config ARCH_FLATMEM_ENABLE
def_bool y
@@ -506,7 +506,8 @@
config HIGHMEM
bool "High Memory Support"
- select ARCH_DISCONTIGMEM_ENABLE
+ select HAVE_ARCH_PFN_VALID
+ select KMAP_LOCAL
help
With ARC 2G:2G address split, only upper 2G is directly addressable by
kernel. Enable this to potentially allow access to rest of 2G and PAE
diff --git a/arch/arc/include/asm/highmem.h b/arch/arc/include/asm/highmem.h
index 6e5eafb..a6b8e2c 100644
--- a/arch/arc/include/asm/highmem.h
+++ b/arch/arc/include/asm/highmem.h
@@ -9,17 +9,29 @@
#ifdef CONFIG_HIGHMEM
#include <uapi/asm/page.h>
-#include <asm/kmap_types.h>
+#include <asm/kmap_size.h>
+
+#define FIXMAP_SIZE PGDIR_SIZE
+#define PKMAP_SIZE PGDIR_SIZE
/* start after vmalloc area */
#define FIXMAP_BASE (PAGE_OFFSET - FIXMAP_SIZE - PKMAP_SIZE)
-#define FIXMAP_SIZE PGDIR_SIZE /* only 1 PGD worth */
-#define KM_TYPE_NR ((FIXMAP_SIZE >> PAGE_SHIFT)/NR_CPUS)
-#define FIXMAP_ADDR(nr) (FIXMAP_BASE + ((nr) << PAGE_SHIFT))
+
+#define FIX_KMAP_SLOTS (KM_MAX_IDX * NR_CPUS)
+#define FIX_KMAP_BEGIN (0UL)
+#define FIX_KMAP_END ((FIX_KMAP_BEGIN + FIX_KMAP_SLOTS) - 1)
+
+#define FIXADDR_TOP (FIXMAP_BASE + (FIX_KMAP_END << PAGE_SHIFT))
+
+/*
+ * This should be converted to the asm-generic version, but of course this
+ * is needlessly different from all other architectures. Sigh - tglx
+ */
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) (((FIXADDR_TOP - ((x) & PAGE_MASK))) >> PAGE_SHIFT)
/* start after fixmap area */
#define PKMAP_BASE (FIXMAP_BASE + FIXMAP_SIZE)
-#define PKMAP_SIZE PGDIR_SIZE
#define LAST_PKMAP (PKMAP_SIZE >> PAGE_SHIFT)
#define LAST_PKMAP_MASK (LAST_PKMAP - 1)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
@@ -29,11 +41,13 @@
extern void kmap_init(void);
+#define arch_kmap_local_post_unmap(vaddr) \
+ local_flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE)
+
static inline void flush_cache_kmaps(void)
{
flush_cache_all();
}
-
#endif
#endif
diff --git a/arch/arc/include/asm/kmap_types.h b/arch/arc/include/asm/kmap_types.h
deleted file mode 100644
index fecf785..0000000
--- a/arch/arc/include/asm/kmap_types.h
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) 2015 Synopsys, Inc. (www.synopsys.com)
- */
-
-#ifndef _ASM_KMAP_TYPES_H
-#define _ASM_KMAP_TYPES_H
-
-/*
- * We primarily need to define KM_TYPE_NR here but that in turn
- * is a function of PGDIR_SIZE etc.
- * To avoid circular deps issue, put everything in asm/highmem.h
- */
-#endif
diff --git a/arch/arc/include/asm/mmu_context.h b/arch/arc/include/asm/mmu_context.h
index 3a5e6a5..df16406 100644
--- a/arch/arc/include/asm/mmu_context.h
+++ b/arch/arc/include/asm/mmu_context.h
@@ -102,6 +102,7 @@ static inline void get_new_mmu_context(struct mm_struct *mm)
* Initialize the context related info for a new mm_struct
* instance.
*/
+#define init_new_context init_new_context
static inline int
init_new_context(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -113,6 +114,7 @@ init_new_context(struct task_struct *tsk, struct mm_struct *mm)
return 0;
}
+#define destroy_context destroy_context
static inline void destroy_context(struct mm_struct *mm)
{
unsigned long flags;
@@ -153,13 +155,13 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
}
/*
- * Called at the time of execve() to get a new ASID
- * Note the subtlety here: get_new_mmu_context() behaves differently here
- * vs. in switch_mm(). Here it always returns a new ASID, because mm has
- * an unallocated "initial" value, while in latter, it moves to a new ASID,
- * only if it was unallocated
+ * activate_mm defaults (in asm-generic) to switch_mm and is called at the
+ * time of execve() to get a new ASID Note the subtlety here:
+ * get_new_mmu_context() behaves differently here vs. in switch_mm(). Here
+ * it always returns a new ASID, because mm has an unallocated "initial"
+ * value, while in latter, it moves to a new ASID, only if it was
+ * unallocated
*/
-#define activate_mm(prev, next) switch_mm(prev, next, NULL)
/* it seemed that deactivate_mm( ) is a reasonable place to do book-keeping
* for retiring-mm. However destroy_context( ) still needs to do that because
@@ -168,8 +170,7 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
* there is a good chance that task gets sched-out/in, making it's ASID valid
* again (this teased me for a whole day).
*/
-#define deactivate_mm(tsk, mm) do { } while (0)
-#define enter_lazy_tlb(mm, tsk)
+#include <asm-generic/mmu_context.h>
#endif /* __ASM_ARC_MMU_CONTEXT_H */
diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h
index b0dfed0..23e41e8 100644
--- a/arch/arc/include/asm/page.h
+++ b/arch/arc/include/asm/page.h
@@ -82,11 +82,25 @@ typedef pte_t * pgtable_t;
*/
#define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT)
-#define ARCH_PFN_OFFSET virt_to_pfn(CONFIG_LINUX_RAM_BASE)
+/*
+ * When HIGHMEM is enabled we have holes in the memory map so we need
+ * pfn_valid() that takes into account the actual extents of the physical
+ * memory
+ */
+#ifdef CONFIG_HIGHMEM
-#ifdef CONFIG_FLATMEM
+extern unsigned long arch_pfn_offset;
+#define ARCH_PFN_OFFSET arch_pfn_offset
+
+extern int pfn_valid(unsigned long pfn);
+#define pfn_valid pfn_valid
+
+#else /* CONFIG_HIGHMEM */
+
+#define ARCH_PFN_OFFSET virt_to_pfn(CONFIG_LINUX_RAM_BASE)
#define pfn_valid(pfn) (((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
-#endif
+
+#endif /* CONFIG_HIGHMEM */
/*
* __pa, __va, virt_to_page (ALERT: deprecated, don't use them)
diff --git a/arch/arc/include/asm/thread_info.h b/arch/arc/include/asm/thread_info.h
index f9eef0e..c0942c2 100644
--- a/arch/arc/include/asm/thread_info.h
+++ b/arch/arc/include/asm/thread_info.h
@@ -79,6 +79,7 @@ static inline __attribute_const__ struct thread_info *current_thread_info(void)
#define TIF_SIGPENDING 2 /* signal pending */
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
#define TIF_SYSCALL_AUDIT 4 /* syscall auditing active */
+#define TIF_NOTIFY_SIGNAL 5 /* signal notifications exist */
#define TIF_SYSCALL_TRACE 15 /* syscall trace active */
/* true if poll_idle() is polling TIF_NEED_RESCHED */
@@ -89,11 +90,12 @@ static inline __attribute_const__ struct thread_info *current_thread_info(void)
#define _TIF_SIGPENDING (1<<TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1<<TIF_NEED_RESCHED)
#define _TIF_SYSCALL_AUDIT (1<<TIF_SYSCALL_AUDIT)
+#define _TIF_NOTIFY_SIGNAL (1<<TIF_NOTIFY_SIGNAL)
#define _TIF_MEMDIE (1<<TIF_MEMDIE)
/* work to do on interrupt/exception return */
#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
- _TIF_NOTIFY_RESUME)
+ _TIF_NOTIFY_RESUME | _TIF_NOTIFY_SIGNAL)
/*
* _TIF_ALLWORK_MASK includes SYSCALL_TRACE, but we don't need it.
diff --git a/arch/arc/kernel/entry.S b/arch/arc/kernel/entry.S
index ea00c8a..1f5308a 100644
--- a/arch/arc/kernel/entry.S
+++ b/arch/arc/kernel/entry.S
@@ -307,7 +307,8 @@
mov r0, sp ; pt_regs for arg to do_signal()/do_notify_resume()
GET_CURR_THR_INFO_FLAGS r9
- bbit0 r9, TIF_SIGPENDING, .Lchk_notify_resume
+ and.f 0, r9, TIF_SIGPENDING|TIF_NOTIFY_SIGNAL
+ bz .Lchk_notify_resume
; Normal Trap/IRQ entry only saves Scratch (caller-saved) regs
; in pt_reg since the "C" ABI (kernel code) will automatically
diff --git a/arch/arc/kernel/signal.c b/arch/arc/kernel/signal.c
index 2be55fb..a78d8f7 100644
--- a/arch/arc/kernel/signal.c
+++ b/arch/arc/kernel/signal.c
@@ -362,7 +362,7 @@ void do_signal(struct pt_regs *regs)
restart_scall = in_syscall(regs) && syscall_restartable(regs);
- if (get_signal(&ksig)) {
+ if (test_thread_flag(TIF_SIGPENDING) && get_signal(&ksig)) {
if (restart_scall) {
arc_restart_syscall(&ksig.ka, regs);
syscall_wont_restart(regs); /* No more restarts */
diff --git a/arch/arc/mm/highmem.c b/arch/arc/mm/highmem.c
index 1b9f473..c79912a 100644
--- a/arch/arc/mm/highmem.c
+++ b/arch/arc/mm/highmem.c
@@ -36,9 +36,8 @@
* This means each only has 1 PGDIR_SIZE worth of kvaddr mappings, which means
* 2M of kvaddr space for typical config (8K page and 11:8:13 traversal split)
*
- * - fixmap anyhow needs a limited number of mappings. So 2M kvaddr == 256 PTE
- * slots across NR_CPUS would be more than sufficient (generic code defines
- * KM_TYPE_NR as 20).
+ * - The fixed KMAP slots for kmap_local/atomic() require KM_MAX_IDX slots per
+ * CPU. So the number of CPUs sharing a single PTE page is limited.
*
* - pkmap being preemptible, in theory could do with more than 256 concurrent
* mappings. However, generic pkmap code: map_new_virtual(), doesn't traverse
@@ -47,48 +46,6 @@
*/
extern pte_t * pkmap_page_table;
-static pte_t * fixmap_page_table;
-
-void *kmap_atomic_high_prot(struct page *page, pgprot_t prot)
-{
- int idx, cpu_idx;
- unsigned long vaddr;
-
- cpu_idx = kmap_atomic_idx_push();
- idx = cpu_idx + KM_TYPE_NR * smp_processor_id();
- vaddr = FIXMAP_ADDR(idx);
-
- set_pte_at(&init_mm, vaddr, fixmap_page_table + idx,
- mk_pte(page, prot));
-
- return (void *)vaddr;
-}
-EXPORT_SYMBOL(kmap_atomic_high_prot);
-
-void kunmap_atomic_high(void *kv)
-{
- unsigned long kvaddr = (unsigned long)kv;
-
- if (kvaddr >= FIXMAP_BASE && kvaddr < (FIXMAP_BASE + FIXMAP_SIZE)) {
-
- /*
- * Because preemption is disabled, this vaddr can be associated
- * with the current allocated index.
- * But in case of multiple live kmap_atomic(), it still relies on
- * callers to unmap in right order.
- */
- int cpu_idx = kmap_atomic_idx();
- int idx = cpu_idx + KM_TYPE_NR * smp_processor_id();
-
- WARN_ON(kvaddr != FIXMAP_ADDR(idx));
-
- pte_clear(&init_mm, kvaddr, fixmap_page_table + idx);
- local_flush_tlb_kernel_range(kvaddr, kvaddr + PAGE_SIZE);
-
- kmap_atomic_idx_pop();
- }
-}
-EXPORT_SYMBOL(kunmap_atomic_high);
static noinline pte_t * __init alloc_kmap_pgtable(unsigned long kvaddr)
{
@@ -108,10 +65,9 @@ void __init kmap_init(void)
{
/* Due to recursive include hell, we can't do this in processor.h */
BUILD_BUG_ON(PAGE_OFFSET < (VMALLOC_END + FIXMAP_SIZE + PKMAP_SIZE));
-
- BUILD_BUG_ON(KM_TYPE_NR > PTRS_PER_PTE);
- pkmap_page_table = alloc_kmap_pgtable(PKMAP_BASE);
-
BUILD_BUG_ON(LAST_PKMAP > PTRS_PER_PTE);
- fixmap_page_table = alloc_kmap_pgtable(FIXMAP_BASE);
+ BUILD_BUG_ON(FIX_KMAP_SLOTS > PTRS_PER_PTE);
+
+ pkmap_page_table = alloc_kmap_pgtable(PKMAP_BASE);
+ alloc_kmap_pgtable(FIXMAP_BASE);
}
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 3a35b82..ce07e69 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -28,6 +28,8 @@ static unsigned long low_mem_sz;
static unsigned long min_high_pfn, max_high_pfn;
static phys_addr_t high_mem_start;
static phys_addr_t high_mem_sz;
+unsigned long arch_pfn_offset;
+EXPORT_SYMBOL(arch_pfn_offset);
#endif
#ifdef CONFIG_DISCONTIGMEM
@@ -98,16 +100,11 @@ void __init setup_arch_memory(void)
init_mm.brk = (unsigned long)_end;
/* first page of system - kernel .vector starts here */
- min_low_pfn = ARCH_PFN_OFFSET;
+ min_low_pfn = virt_to_pfn(CONFIG_LINUX_RAM_BASE);
/* Last usable page of low mem */
max_low_pfn = max_pfn = PFN_DOWN(low_mem_start + low_mem_sz);
-#ifdef CONFIG_FLATMEM
- /* pfn_valid() uses this */
- max_mapnr = max_low_pfn - min_low_pfn;
-#endif
-
/*------------- bootmem allocator setup -----------------------*/
/*
@@ -153,7 +150,9 @@ void __init setup_arch_memory(void)
* DISCONTIGMEM in turns requires multiple nodes. node 0 above is
* populated with normal memory zone while node 1 only has highmem
*/
+#ifdef CONFIG_DISCONTIGMEM
node_set_online(1);
+#endif
min_high_pfn = PFN_DOWN(high_mem_start);
max_high_pfn = PFN_DOWN(high_mem_start + high_mem_sz);
@@ -161,8 +160,15 @@ void __init setup_arch_memory(void)
max_zone_pfn[ZONE_HIGHMEM] = min_low_pfn;
high_memory = (void *)(min_high_pfn << PAGE_SHIFT);
+
+ arch_pfn_offset = min(min_low_pfn, min_high_pfn);
kmap_init();
-#endif
+
+#else /* CONFIG_HIGHMEM */
+ /* pfn_valid() uses this when FLATMEM=y and HIGHMEM=n */
+ max_mapnr = max_low_pfn - min_low_pfn;
+
+#endif /* CONFIG_HIGHMEM */
free_area_init(max_zone_pfn);
}
@@ -190,3 +196,12 @@ void __init mem_init(void)
highmem_init();
mem_init_print_info(NULL);
}
+
+#ifdef CONFIG_HIGHMEM
+int pfn_valid(unsigned long pfn)
+{
+ return (pfn >= min_high_pfn && pfn <= max_high_pfn) ||
+ (pfn >= min_low_pfn && pfn <= max_low_pfn);
+}
+EXPORT_SYMBOL(pfn_valid);
+#endif
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 002e0cf..1382489 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -5,7 +5,6 @@
select ARCH_32BIT_OFF_T
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
- select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
@@ -25,7 +24,7 @@
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_HAS_GCOV_PROFILE_ALL
- select ARCH_KEEP_MEMBLOCK if HAVE_ARCH_PFN_VALID || KEXEC
+ select ARCH_KEEP_MEMBLOCK
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_NO_SG_CHAIN if !ARM_HAS_SG_CHAIN
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
@@ -57,6 +56,7 @@
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
+ select GENERIC_LIB_DEVMEM_IS_ALLOWED
select GENERIC_PCI_IOMAP
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
@@ -68,7 +68,9 @@
select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
+ select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
select HAVE_ARCH_MMAP_RND_BITS if MMU
+ select HAVE_ARCH_PFN_VALID
select HAVE_ARCH_SECCOMP
select HAVE_ARCH_SECCOMP_FILTER if AEABI && !OABI_COMPAT
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
@@ -244,7 +246,7 @@
kernel in system memory.
This can only be used with non-XIP MMU kernels where the base
- of physical memory is at a 16MB boundary.
+ of physical memory is at a 2 MiB boundary.
Only disable this option if you know that you do not require
this feature (eg, building a kernel for a single machine) and
@@ -268,8 +270,7 @@
hex "Physical address of main memory" if MMU
depends on !ARM_PATCH_PHYS_VIRT
default DRAM_BASE if !MMU
- default 0x00000000 if ARCH_EBSA110 || \
- ARCH_FOOTBRIDGE
+ default 0x00000000 if ARCH_FOOTBRIDGE
default 0x10000000 if ARCH_OMAP1 || ARCH_RPC
default 0x20000000 if ARCH_S5PV210
default 0xc0000000 if ARCH_SA1100
@@ -323,7 +324,6 @@
select AUTO_ZRELADDR
select TIMER_OF
select COMMON_CLK
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select HAVE_PCI
select PCI_DOMAINS_GENERIC if PCI
@@ -338,25 +338,10 @@
select TIMER_OF
select COMMON_CLK
select CPU_V7M
- select GENERIC_CLOCKEVENTS
select NO_IOPORT_MAP
select SPARSE_IRQ
select USE_OF
-config ARCH_EBSA110
- bool "EBSA-110"
- select ARCH_USES_GETTIMEOFFSET
- select CPU_SA110
- select ISA
- select NEED_MACH_IO_H
- select NEED_MACH_MEMORY_H
- select NO_IOPORT_MAP
- help
- This is an evaluation board for the StrongARM processor available
- from Digital. It has limited hardware on-board, including an
- Ethernet interface, two PCMCIA sockets, two serial ports and a
- parallel port.
-
config ARCH_EP93XX
bool "EP93xx-based"
select ARCH_SPARSEMEM_ENABLE
@@ -367,7 +352,6 @@
select CLKDEV_LOOKUP
select CLKSRC_MMIO
select CPU_ARM920T
- select GENERIC_CLOCKEVENTS
select GPIOLIB
select HAVE_LEGACY_CLK
help
@@ -377,7 +361,6 @@
bool "FootBridge"
select CPU_SA110
select FOOTBRIDGE
- select GENERIC_CLOCKEVENTS
select HAVE_IDE
select NEED_MACH_IO_H if !MMU
select NEED_MACH_MEMORY_H
@@ -405,7 +388,6 @@
select ARCH_SUPPORTS_BIG_ENDIAN
select CPU_XSCALE
select DMABOUNCE if PCI
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIO_IXP4XX
select GPIOLIB
@@ -421,7 +403,6 @@
config ARCH_DOVE
bool "Marvell Dove"
select CPU_PJ4
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
select HAVE_PCI
@@ -445,7 +426,6 @@
select CLKSRC_MMIO
select TIMER_OF
select CPU_XSCALE if !CPU_XSC3
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIO_PXA
select GPIOLIB
@@ -468,6 +448,7 @@
select HAVE_IDE
select HAVE_PATA_PLATFORM
select ISA_DMA_API
+ select LEGACY_TIMER_TICK
select NEED_MACH_IO_H
select NEED_MACH_MEMORY_H
select NO_IOPORT_MAP
@@ -485,7 +466,6 @@
select COMMON_CLK
select CPU_FREQ
select CPU_SA1100
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
select HAVE_IDE
@@ -500,7 +480,6 @@
bool "Samsung S3C24XX SoCs"
select ATAGS
select CLKSRC_SAMSUNG_PWM
- select GENERIC_CLOCKEVENTS
select GPIO_SAMSUNG
select GPIOLIB
select GENERIC_IRQ_MULTI_HANDLER
@@ -520,11 +499,9 @@
config ARCH_OMAP1
bool "TI OMAP1"
depends on MMU
- select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_OMAP
select CLKDEV_LOOKUP
select CLKSRC_MMIO
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_MULTI_HANDLER
select GPIOLIB
@@ -787,7 +764,6 @@
config PLAT_IOP
bool
- select GENERIC_CLOCKEVENTS
config PLAT_ORION
bool
@@ -1178,7 +1154,6 @@
config SMP
bool "Symmetric Multi-Processing"
depends on CPU_V6K || CPU_V7
- depends on GENERIC_CLOCKEVENTS
depends on HAVE_SMP
depends on MMU || ARM_MPU
select IRQ_WORK
@@ -1324,6 +1299,15 @@
default 0xB0000000 if VMSPLIT_3G_OPT
default 0xC0000000
+config KASAN_SHADOW_OFFSET
+ hex
+ depends on KASAN
+ default 0x1f000000 if PAGE_OFFSET=0x40000000
+ default 0x5f000000 if PAGE_OFFSET=0x80000000
+ default 0x9f000000 if PAGE_OFFSET=0xC0000000
+ default 0x8f000000 if PAGE_OFFSET=0xB0000000
+ default 0xffffffff
+
config NR_CPUS
int "Maximum number of CPUs (2-32)"
range 2 32
@@ -1372,7 +1356,6 @@
config HZ_FIXED
int
- default 200 if ARCH_EBSA110
default 128 if SOC_AT91RM9200
default 0
@@ -1480,9 +1463,6 @@
UNPREDICTABLE (in fact it can be predicted that it won't work
at all). If in doubt say N.
-config ARCH_HAS_HOLES_MEMORYMODEL
- bool
-
config ARCH_SELECT_MEMORY_MODEL
bool
@@ -1493,12 +1473,10 @@
bool
select SPARSEMEM_STATIC if SPARSEMEM
-config HAVE_ARCH_PFN_VALID
- def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
-
config HIGHMEM
bool "High Memory Support"
depends on MMU
+ select KMAP_LOCAL
help
The address space of ARM processors is only 4 Gigabytes large
and it has to accommodate user address space, kernel address
@@ -1588,9 +1566,7 @@
a value of 11 means that the largest free memory block is 2^10 pages.
config ALIGNMENT_TRAP
- bool
- depends on CPU_CP15_MMU
- default y if !ARCH_EBSA110
+ def_bool CPU_CP15_MMU
select HAVE_PROC_CPU if PROC_FS
help
ARM processors cannot fetch/store information which is not
@@ -1785,7 +1761,7 @@
string "Default kernel command string"
default ""
help
- On some architectures (EBSA110 and CATS), there is currently no way
+ On some architectures (e.g. CATS), there is currently no way
for the boot loader to pass arguments to the kernel. For these
architectures, you should supply some command-line options at build
time by entering them here. As a minimum, you should specify the
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 8986a91..4ff0420 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1567,7 +1567,7 @@
config DEBUG_UART_FLOW_CONTROL
bool "Enable flow control (CTS) for the debug UART"
depends on DEBUG_LL
- default y if ARCH_EBSA110 || DEBUG_FOOTBRIDGE_COM1 || DEBUG_GEMINI || ARCH_RPC
+ default y if DEBUG_FOOTBRIDGE_COM1 || DEBUG_GEMINI || ARCH_RPC
help
Some UART ports are connected to terminals that will use modem
control signals to indicate whether they are ready to receive text.
@@ -1639,7 +1639,7 @@
# Compatibility options for 8250
config DEBUG_UART_8250
- def_bool ARCH_EBSA110 || ARCH_IOP32X || ARCH_IXP4XX || ARCH_RPC
+ def_bool ARCH_IOP32X || ARCH_IXP4XX || ARCH_RPC
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
@@ -1743,7 +1743,6 @@
default 0xe8008000 if DEBUG_R7S72100_SCIF2 || DEBUG_R7S9210_SCIF2
default 0xe8009000 if DEBUG_R7S9210_SCIF4
default 0xf0000000 if DEBUG_DIGICOLOR_UA0
- default 0xf0000be0 if ARCH_EBSA110
default 0xf1012000 if DEBUG_MVEBU_UART0_ALTERNATE
default 0xf1012100 if DEBUG_MVEBU_UART1_ALTERNATE
default 0xf7fc9000 if DEBUG_BERLIN_UART
@@ -1790,7 +1789,6 @@
default 0xc8821000 if DEBUG_RV1108_UART1
default 0xc8912000 if DEBUG_RV1108_UART0
default 0xe0010fe0 if ARCH_RPC
- default 0xf0000be0 if ARCH_EBSA110
default 0xf0010000 if DEBUG_ASM9260_UART
default 0xf0100000 if DEBUG_DIGICOLOR_UA0
default 0xf01fb000 if DEBUG_NOMADIK_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e15f76c..4aaec95 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -10,7 +10,7 @@
#
# Copyright (C) 1995-2001 by Russell King
-LDFLAGS_vmlinux := --no-undefined -X --pic-veneer
+LDFLAGS_vmlinux := --no-undefined -X --pic-veneer -z norelro
ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
@@ -168,7 +168,6 @@
machine-$(CONFIG_ARCH_DAVINCI) += davinci
machine-$(CONFIG_ARCH_DIGICOLOR) += digicolor
machine-$(CONFIG_ARCH_DOVE) += dove
-machine-$(CONFIG_ARCH_EBSA110) += ebsa110
machine-$(CONFIG_ARCH_EFM32) += efm32
machine-$(CONFIG_ARCH_EP93XX) += ep93xx
machine-$(CONFIG_ARCH_EXYNOS) += exynos
@@ -235,13 +234,6 @@
plat-$(CONFIG_PLAT_PXA) += pxa
plat-$(CONFIG_PLAT_VERSATILE) += versatile
-ifeq ($(CONFIG_ARCH_EBSA110),y)
-# This is what happens if you forget the IOCS16 line.
-# PCMCIA cards stop working.
-CFLAGS_3c589_cs.o :=-DISA_SIXTEEN_BIT_PERIPHERAL
-export CFLAGS_3c589_cs.o
-endif
-
# The byte offset of the kernel image in RAM from the start of RAM.
TEXT_OFFSET := $(textofs-y)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index e156741..fb521ef 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -24,6 +24,7 @@
endif
GCOV_PROFILE := n
+KASAN_SANITIZE := n
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index caa2732..d9cce72 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -11,6 +11,12 @@
#include "efi-header.S"
+#ifdef __ARMEB__
+#define OF_DT_MAGIC 0xd00dfeed
+#else
+#define OF_DT_MAGIC 0xedfe0dd0
+#endif
+
AR_CLASS( .arch armv7-a )
M_CLASS( .arch armv7-m )
@@ -116,7 +122,7 @@
/*
* Debug print of the final appended DTB location
*/
- .macro dbgadtb, begin, end
+ .macro dbgadtb, begin, size
#ifdef DEBUG
kputc #'D'
kputc #'T'
@@ -129,7 +135,7 @@
kputc #'('
kputc #'0'
kputc #'x'
- kphex \end, 8 /* End of appended DTB */
+ kphex \size, 8 /* Size of appended DTB */
kputc #')'
kputc #'\n'
#endif
@@ -165,6 +171,16 @@
orr \res, \res, \tmp1, lsl #24
.endm
+ .macro be32tocpu, val, tmp
+#ifndef __ARMEB__
+ /* convert to little endian */
+ eor \tmp, \val, \val, ror #16
+ bic \tmp, \tmp, #0x00ff0000
+ mov \val, \val, ror #8
+ eor \val, \val, \tmp, lsr #8
+#endif
+ .endm
+
.section ".start", "ax"
/*
* sort out different calling conventions
@@ -325,11 +341,7 @@
*/
ldr lr, [r6, #0]
-#ifndef __ARMEB__
- ldr r1, =0xedfe0dd0 @ sig is 0xd00dfeed big endian
-#else
- ldr r1, =0xd00dfeed
-#endif
+ ldr r1, =OF_DT_MAGIC
cmp lr, r1
bne dtb_check_done @ not found
@@ -345,13 +357,7 @@
/* Get the initial DTB size */
ldr r5, [r6, #4]
-#ifndef __ARMEB__
- /* convert to little endian */
- eor r1, r5, r5, ror #16
- bic r1, r1, #0x00ff0000
- mov r5, r5, ror #8
- eor r5, r5, r1, lsr #8
-#endif
+ be32tocpu r5, r1
dbgadtb r6, r5
/* 50% DTB growth should be good enough */
add r5, r5, r5, lsr #1
@@ -403,13 +409,7 @@
/* Get the current DTB size */
ldr r5, [r6, #4]
-#ifndef __ARMEB__
- /* convert r5 (dtb size) to little endian */
- eor r1, r5, r5, ror #16
- bic r1, r1, #0x00ff0000
- mov r5, r5, ror #8
- eor r5, r5, r1, lsr #8
-#endif
+ be32tocpu r5, r1
/* preserve 64-bit alignment */
add r5, r5, #7
@@ -468,15 +468,10 @@
/*
* Compute the address of the hyp vectors after relocation.
- * This requires some arithmetic since we cannot directly
- * reference __hyp_stub_vectors in a PC-relative way.
* Call __hyp_set_vectors with the new address so that we
* can HVC again after the copy.
*/
-0: adr r0, 0b
- movw r1, #:lower16:__hyp_stub_vectors - 0b
- movt r1, #:upper16:__hyp_stub_vectors - 0b
- add r0, r0, r1
+ adr_l r0, __hyp_stub_vectors
sub r0, r0, r5
add r0, r0, r10
bl __hyp_set_vectors
@@ -627,17 +622,11 @@
cmp r0, #HYP_MODE @ if not booted in HYP mode...
bne __enter_kernel @ boot kernel directly
- adr r12, .L__hyp_reentry_vectors_offset
- ldr r0, [r12]
- add r0, r0, r12
-
+ adr_l r0, __hyp_reentry_vectors
bl __hyp_set_vectors
__HVC(0) @ otherwise bounce to hyp mode
b . @ should never be reached
-
- .align 2
-.L__hyp_reentry_vectors_offset: .long __hyp_reentry_vectors - .
#else
b __enter_kernel
#endif
@@ -1440,8 +1429,7 @@
mov r4, r0 @ preserve image base
mov r8, r1 @ preserve DT pointer
- ARM( adrl r0, call_cache_fn )
- THUMB( adr r0, call_cache_fn )
+ adr_l r0, call_cache_fn
adr r1, 0f @ clean the region of code we
bl cache_clean_flush @ may run with the MMU off
diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
index ade5079..8c0fa27 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -7,6 +7,25 @@
#include <linux/string.h>
+/*
+ * The decompressor is built without KASan but uses the same redirects as the
+ * rest of the kernel when CONFIG_KASAN is enabled, defining e.g. memcpy()
+ * to __memcpy() but since we are not linking with the main kernel string
+ * library in the decompressor, that will lead to link failures.
+ *
+ * Undefine KASan's versions, define the wrapped functions and alias them to
+ * the right names so that when e.g. __memcpy() appear in the code, it will
+ * still be linked to this local version of memcpy().
+ */
+#ifdef CONFIG_KASAN
+#undef memcpy
+#undef memmove
+#undef memset
+void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias(memcpy);
+void *__memmove(void *__dest, __const void *__src, size_t count) __alias(memmove);
+void *__memset(void *s, int c, size_t count) __alias(memset);
+#endif
+
void *memcpy(void *__dest, __const void *__src, size_t __n)
{
int i = 0;
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ce66ffd..3d1ea0b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -197,6 +197,7 @@
exynos4412-odroidx.dtb \
exynos4412-odroidx2.dtb \
exynos4412-origen.dtb \
+ exynos4412-p4note-n8010.dtb \
exynos4412-smdk4412.dtb \
exynos4412-tiny4412.dtb \
exynos4412-trats2.dtb
@@ -339,7 +340,10 @@
lpc3250-ea3250.dtb \
lpc3250-phy3250.dtb
dtb-$(CONFIG_ARCH_NPCM7XX) += \
- nuvoton-npcm750-evb.dtb
+ nuvoton-npcm730-gsj.dtb \
+ nuvoton-npcm730-kudo.dtb \
+ nuvoton-npcm750-evb.dtb \
+ nuvoton-npcm750-runbmc-olympus.dtb
dtb-$(CONFIG_MACH_MESON6) += \
meson6-atv1200.dtb
dtb-$(CONFIG_MACH_MESON8) += \
@@ -414,6 +418,7 @@
imx53-usbarmory.dtb \
imx53-voipac-bsb.dtb
dtb-$(CONFIG_SOC_IMX6Q) += \
+ imx6dl-alti6p.dtb \
imx6dl-apf6dev.dtb \
imx6dl-aristainetos_4.dtb \
imx6dl-aristainetos_7.dtb \
@@ -450,6 +455,7 @@
imx6dl-icore.dtb \
imx6dl-icore-mipi.dtb \
imx6dl-icore-rqs.dtb \
+ imx6dl-lanmcu.dtb \
imx6dl-mamoj.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
@@ -581,6 +587,7 @@
imx6qp-nitrogen6_max.dtb \
imx6qp-nitrogen6_som2.dtb \
imx6qp-phytec-mira-rdk-nand.dtb \
+ imx6qp-prtwd3.dtb \
imx6qp-sabreauto.dtb \
imx6qp-sabresd.dtb \
imx6qp-tx6qp-8037.dtb \
@@ -622,6 +629,7 @@
imx6ul-pico-dwarf.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-pico-pi.dtb \
+ imx6ul-phytec-segin-ff-rdk-emmc.dtb \
imx6ul-phytec-segin-ff-rdk-nand.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
@@ -641,6 +649,8 @@
imx7d-colibri-emmc-aster.dtb \
imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
+ imx7d-flex-concentrator.dtb \
+ imx7d-flex-concentrator-mfg.dtb \
imx7d-mba7.dtb \
imx7d-meerkat96.dtb \
imx7d-nitrogen7.dtb \
@@ -1066,6 +1076,7 @@
stm32mp157a-iot-box.dtb \
stm32mp157a-stinger96.dtb \
stm32mp157c-dhcom-pdk2.dtb \
+ stm32mp157c-dhcom-picoitx.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb \
@@ -1192,6 +1203,7 @@
sun8i-h3-nanopi-m1-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-nanopi-neo-air.dtb \
+ sun8i-h3-nanopi-r1.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
sun8i-h3-orangepi-one.dtb \
@@ -1201,12 +1213,14 @@
sun8i-h3-orangepi-plus2e.dtb \
sun8i-h3-orangepi-zero-plus2.dtb \
sun8i-h3-rervision-dvk.dtb \
+ sun8i-h3-zeropi.dtb \
sun8i-h3-emlid-neutis-n5h3-devboard.dtb \
sun8i-r16-bananapi-m2m.dtb \
sun8i-r16-nintendo-nes-classic.dtb \
sun8i-r16-nintendo-super-nes-classic.dtb \
sun8i-r16-parrot.dtb \
sun8i-r40-bananapi-m2-ultra.dtb \
+ sun8i-s3-elimo-initium.dtb \
sun8i-s3-lichee-zero-plus.dtb \
sun8i-s3-pinecube.dtb \
sun8i-t3-cqa3t-bv3.dtb \
@@ -1241,7 +1255,8 @@
tegra30-beaver.dtb \
tegra30-cardhu-a02.dtb \
tegra30-cardhu-a04.dtb \
- tegra30-colibri-eval-v3.dtb
+ tegra30-colibri-eval-v3.dtb \
+ tegra30-ouya.dtb
dtb-$(CONFIG_ARCH_TEGRA_114_SOC) += \
tegra114-dalmore.dtb \
tegra114-roth.dtb \
@@ -1302,6 +1317,7 @@
zynq-zc770-xm013.dtb \
zynq-zed.dtb \
zynq-zturn.dtb \
+ zynq-zturn-v5.dtb \
zynq-zybo.dtb \
zynq-zybo-z7.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
@@ -1319,6 +1335,7 @@
dtb-$(CONFIG_MACH_ARMADA_375) += \
armada-375-db.dtb
dtb-$(CONFIG_MACH_ARMADA_38X) += \
+ armada-382-rd-ac3x-48g4x2xl.dtb \
armada-385-clearfog-gtr-s4.dtb \
armada-385-clearfog-gtr-l8.dtb \
armada-385-db-88f6820-amc.dtb \
@@ -1340,6 +1357,12 @@
armada-398-db.dtb
dtb-$(CONFIG_MACH_ARMADA_XP) += \
armada-xp-axpwifiap.dtb \
+ armada-xp-crs305-1g-4s.dtb \
+ armada-xp-crs305-1g-4s-bit.dtb \
+ armada-xp-crs326-24g-2s.dtb \
+ armada-xp-crs326-24g-2s-bit.dtb \
+ armada-xp-crs328-4c-20s-4s.dtb \
+ armada-xp-crs328-4c-20s-4s-bit.dtb \
armada-xp-db.dtb \
armada-xp-db-dxbc2.dtb \
armada-xp-db-xc3-24g4xg.dtb \
@@ -1372,6 +1395,7 @@
dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
dtb-$(CONFIG_ARCH_MSTARV7) += \
mstar-infinity-msc313-breadbee_crust.dtb \
+ mstar-infinity2m-ssd202d-ssd201htv2.dtb \
mstar-infinity3-msc313e-breadbee.dtb \
mstar-mercury5-ssc8336n-midrived08.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
@@ -1381,7 +1405,9 @@
aspeed-bmc-amd-ethanolx.dtb \
aspeed-bmc-arm-centriq2400-rep.dtb \
aspeed-bmc-arm-stardragon4800-rep2.dtb \
+ aspeed-bmc-bytedance-g220a.dtb \
aspeed-bmc-facebook-cmm.dtb \
+ aspeed-bmc-facebook-galaxy100.dtb \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
aspeed-bmc-facebook-wedge40.dtb \
@@ -1390,6 +1416,7 @@
aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-facebook-yosemitev2.dtb \
aspeed-bmc-ibm-rainier.dtb \
+ aspeed-bmc-ibm-rainier-4u.dtb \
aspeed-bmc-intel-s2600wf.dtb \
aspeed-bmc-inspur-fp5280g2.dtb \
aspeed-bmc-lenovo-hr630.dtb \
diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
index b7f64c7..3ea2861 100644
--- a/arch/arm/boot/dts/am335x-baltos.dtsi
+++ b/arch/arm/boot/dts/am335x-baltos.dtsi
@@ -168,7 +168,7 @@ AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad5.gpm
AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0) /* gpmc_wait0.gpmc_wait0 */
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_30 */
+ AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_31 */
AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0) /* gpmc_csn0.gpmc_csn0 */
AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0) /* gpmc_advn_ale.gpmc_advn_ale */
AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE0) /* gpmc_oen_ren.gpmc_oen_ren */
diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
index c696d57..69acaf4 100644
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ b/arch/arm/boot/dts/am335x-boneblue.dts
@@ -241,6 +241,30 @@ AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT, MUX_MODE2) /* (E18) uart0_cts
AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_OUTPUT, MUX_MODE7) /* (M16) gmii1_rxd0.gpio2[21] */
>;
};
+
+ /* E1 */
+ eqep0_pins: pinmux_eqep0_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_MCASP0_AXR0, PIN_INPUT, MUX_MODE1) /* (B12) mcasp0_aclkr.eQEP0A_in */
+ AM33XX_PADCONF(AM335X_PIN_MCASP0_FSR, PIN_INPUT, MUX_MODE1) /* (C13) mcasp0_fsr.eQEP0B_in */
+ >;
+ };
+
+ /* E2 */
+ eqep1_pins: pinmux_eqep1_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_INPUT, MUX_MODE2) /* (V2) lcd_data12.eQEP1A_in */
+ AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_INPUT, MUX_MODE2) /* (V3) lcd_data13.eQEP1B_in */
+ >;
+ };
+
+ /* E3 */
+ eqep2_pins: pinmux_eqep2_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT, MUX_MODE4) /* (T12) gpmc_ad12.eQEP2A_in */
+ AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT, MUX_MODE4) /* (R12) gpmc_ad13.eQEP2B_in */
+ >;
+ };
};
&uart0 {
@@ -419,3 +443,33 @@ ls_buf_en {
line-name = "LS_BUF_EN";
};
};
+
+&epwmss0 {
+ status = "okay";
+};
+
+&eqep0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&eqep0_pins>;
+ status = "okay";
+};
+
+&epwmss1 {
+ status = "okay";
+};
+
+&eqep1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&eqep1_pins>;
+ status = "okay";
+};
+
+&epwmss2 {
+ status = "okay";
+};
+
+&eqep2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&eqep2_pins>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts b/arch/arm/boot/dts/am335x-cm-t335.dts
index c6fe9db..36d963d 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -122,7 +122,7 @@ AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0)
- /* gpmc_wpn.gpio0_30 */
+ /* gpmc_wpn.gpio0_31 */
AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 12dffcc..7c6f2c1 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -229,7 +229,7 @@ AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_30 */
+ AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_31 */
AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE0)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi b/arch/arm/boot/dts/am335x-igep0033.dtsi
index c9f354f..7ec23d4 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -70,7 +70,7 @@ AM33XX_PADCONF(AM335X_PIN_GPMC_AD5, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_AD6, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_AD7, PIN_INPUT_PULLUP, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE0)
- AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_30 */
+ AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_INPUT_PULLUP, MUX_MODE7) /* gpmc_wpn.gpio0_31 */
AM33XX_PADCONF(AM335X_PIN_GPMC_CSN0, PIN_OUTPUT, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_ADVN_ALE, PIN_OUTPUT, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_GPMC_OEN_REN, PIN_OUTPUT, MUX_MODE0)
diff --git a/arch/arm/boot/dts/am335x-nano.dts b/arch/arm/boot/dts/am335x-nano.dts
index 0946fbf..0dbc72d 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -238,7 +238,6 @@ &elm {
&gpmc {
compatible = "ti,am3352-gpmc";
- ti,hwmods = "gpmc";
status = "okay";
gpmc,num-waitpins = <2>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index ea20e4b..7808850 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -1,5 +1,8 @@
&l4_wkup { /* 0x44c00000 */
- compatible = "ti,am33xx-l4-wkup", "simple-bus";
+ compatible = "ti,am33xx-l4-wkup", "simple-pm-bus";
+ power-domains = <&prm_wkup>;
+ clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_L4_WKUP_CLKCTRL 0>;
+ clock-names = "fck";
reg = <0x44c00000 0x800>,
<0x44c00800 0x800>,
<0x44c01000 0x400>,
@@ -12,7 +15,7 @@
<0x00200000 0x44e00000 0x100000>; /* segment 2 */
segment@0 { /* 0x44c00000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
@@ -22,7 +25,7 @@ segment@0 { /* 0x44c00000 */
};
segment@100000 { /* 0x44d00000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00100000 0x004000>, /* ap 4 */
@@ -34,23 +37,27 @@ target-module@0 { /* 0x44d00000, ap 4 28.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x0 0x4>;
reg-names = "rev";
+ clocks = <&l4_wkup_aon_clkctrl AM3_L4_WKUP_AON_WKUP_M3_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x0 0x4000>;
- status = "disabled";
- };
+ ranges = <0x00000000 0x00000000 0x4000>,
+ <0x00080000 0x00080000 0x2000>;
- target-module@80000 { /* 0x44d80000, ap 6 10.0 */
- compatible = "ti,sysc";
- status = "disabled";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80000 0x2000>;
+ wkup_m3: cpu@0 {
+ compatible = "ti,am3352-wkup-m3";
+ reg = <0x00000000 0x4000>,
+ <0x00080000 0x2000>;
+ reg-names = "umem", "dmem";
+ resets = <&prm_wkup 3>;
+ reset-names = "rstctrl";
+ ti,pm-firmware = "am335x-pm-firmware.elf";
+ };
};
};
segment@200000 { /* 0x44e00000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00200000 0x002000>, /* ap 8 */
@@ -274,6 +281,9 @@ target-module@10000 { /* 0x44e10000, ap 22 0c.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x10000 0x4>;
reg-names = "rev";
+ clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_CONTROL_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00010000 0x00010000>,
@@ -433,6 +443,7 @@ target-module@3e000 { /* 0x44e3e000, ap 35 60.0 */
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): rtc_pwrdm, l4_rtc_clkdm */
+ power-domains = <&prm_rtc>;
clocks = <&l4_rtc_clkctrl AM3_L4_RTC_RTC_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
@@ -658,7 +669,10 @@ target-module@46000 { /* 0x47c46000, ap 25 2c.0 */
};
&l4_fast { /* 0x4a000000 */
- compatible = "ti,am33xx-l4-fast", "simple-bus";
+ compatible = "ti,am33xx-l4-fast", "simple-pm-bus";
+ power-domains = <&prm_per>;
+ clocks = <&l4hs_clkctrl AM3_L4HS_L4_HS_CLKCTRL 0>;
+ clock-names = "fck";
reg = <0x4a000000 0x800>,
<0x4a000800 0x800>,
<0x4a001000 0x400>;
@@ -668,7 +682,7 @@ &l4_fast { /* 0x4a000000 */
ranges = <0x00000000 0x4a000000 0x1000000>; /* segment 0 */
segment@0 { /* 0x4a000000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
@@ -837,7 +851,10 @@ target-module@3000 { /* 0x4b143000, ap 6 04.0 */
};
&l4_per { /* 0x48000000 */
- compatible = "ti,am33xx-l4-per", "simple-bus";
+ compatible = "ti,am33xx-l4-per", "simple-pm-bus";
+ power-domains = <&prm_per>;
+ clocks = <&l4ls_clkctrl AM3_L4LS_L4_LS_CLKCTRL 0>;
+ clock-names = "fck";
reg = <0x48000000 0x800>,
<0x48000800 0x800>,
<0x48001000 0x400>,
@@ -855,7 +872,7 @@ &l4_per { /* 0x48000000 */
<0x46400000 0x46400000 0x400000>; /* l3 data port */
segment@0 { /* 0x48000000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
@@ -1466,7 +1483,7 @@ target-module@cc000 { /* 0x480cc000, ap 89 0e.0 */
};
segment@100000 { /* 0x48100000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0008c000 0x0018c000 0x001000>, /* ap 42 */
@@ -1850,13 +1867,31 @@ mmc2: mmc@0 {
};
segment@200000 { /* 0x48200000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0x00000000 0x00200000 0x010000>;
+
+ target-module@0 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ power-domains = <&prm_mpu>;
+ clocks = <&mpu_clkctrl AM3_MPU_MPU_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x10000>;
+
+ mpu@0 {
+ compatible = "ti,omap3-mpu";
+ pm-sram = <&pm_sram_code
+ &pm_sram_data>;
+ };
+ };
};
segment@300000 { /* 0x48300000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00300000 0x001000>, /* ap 66 */
@@ -1923,6 +1958,15 @@ ecap0: ecap@100 {
status = "disabled";
};
+ eqep0: counter@180 {
+ compatible = "ti,am3352-eqep";
+ reg = <0x180 0x80>;
+ clocks = <&l4ls_gclk>;
+ clock-names = "sysclkout";
+ interrupts = <79>;
+ status = "disabled";
+ };
+
ehrpwm0: pwm@200 {
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
@@ -1975,6 +2019,15 @@ ecap1: ecap@100 {
status = "disabled";
};
+ eqep1: counter@180 {
+ compatible = "ti,am3352-eqep";
+ reg = <0x180 0x80>;
+ clocks = <&l4ls_gclk>;
+ clock-names = "sysclkout";
+ interrupts = <88>;
+ status = "disabled";
+ };
+
ehrpwm1: pwm@200 {
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
@@ -2027,6 +2080,15 @@ ecap2: ecap@100 {
status = "disabled";
};
+ eqep2: counter@180 {
+ compatible = "ti,am3352-eqep";
+ reg = <0x180 0x80>;
+ clocks = <&l4ls_gclk>;
+ clock-names = "sysclkout";
+ interrupts = <89>;
+ status = "disabled";
+ };
+
ehrpwm2: pwm@200 {
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4c22980..5b213a1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -144,11 +144,28 @@ oppnitro-1000000000 {
};
};
- pmu@4b000000 {
- compatible = "arm,cortex-a8-pmu";
- interrupts = <3>;
- reg = <0x4b000000 0x1000000>;
- ti,hwmods = "debugss";
+ target-module@4b000000 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ clocks = <&l3_clkctrl AM3_L3_L3_INSTR_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x4b000000 0x1000000>;
+
+ target-module@140000 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ clocks = <&l3_aon_clkctrl AM3_L3_AON_DEBUGSS_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x140000 0xec0000>;
+
+ pmu@0 {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ };
+ };
};
/*
@@ -157,12 +174,6 @@ pmu@4b000000 {
*/
soc {
compatible = "ti,omap-infra";
- mpu {
- compatible = "ti,omap3-mpu";
- ti,hwmods = "mpu";
- pm-sram = <&pm_sram_code
- &pm_sram_data>;
- };
};
/*
@@ -173,21 +184,15 @@ mpu {
* the whole bus hierarchy.
*/
ocp: ocp {
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
+ power-domains = <&prm_per>;
+ clocks = <&l3_clkctrl AM3_L3_L3_MAIN_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges;
- ti,hwmods = "l3_main";
l4_wkup: interconnect@44c00000 {
- wkup_m3: wkup_m3@100000 {
- compatible = "ti,am3352-wkup-m3";
- reg = <0x100000 0x4000>,
- <0x180000 0x2000>;
- reg-names = "umem", "dmem";
- ti,hwmods = "wkup_m3";
- ti,pm-firmware = "am335x-pm-firmware.elf";
- };
};
l4_per: interconnect@48000000 {
};
@@ -458,53 +463,89 @@ cppi41dma: dma-controller@2000 {
};
};
- ocmcram: sram@40300000 {
- compatible = "mmio-sram";
- reg = <0x40300000 0x10000>; /* 64k */
- ranges = <0x0 0x40300000 0x10000>;
+ target-module@40300000 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ clocks = <&l3_clkctrl AM3_L3_OCMCRAM_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0x40300000 0x10000>;
- pm_sram_code: pm-code-sram@0 {
- compatible = "ti,sram";
- reg = <0x0 0x1000>;
- protect-exec;
- };
+ ocmcram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0 0x10000>; /* 64k */
+ ranges = <0 0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
- pm_sram_data: pm-data-sram@1000 {
- compatible = "ti,sram";
- reg = <0x1000 0x1000>;
- pool;
+ pm_sram_code: pm-code-sram@0 {
+ compatible = "ti,sram";
+ reg = <0x0 0x1000>;
+ protect-exec;
+ };
+
+ pm_sram_data: pm-data-sram@1000 {
+ compatible = "ti,sram";
+ reg = <0x1000 0x1000>;
+ pool;
+ };
};
};
- emif: emif@4c000000 {
- compatible = "ti,emif-am3352";
- reg = <0x4c000000 0x1000000>;
- ti,hwmods = "emif";
- interrupts = <101>;
- sram = <&pm_sram_code
- &pm_sram_data>;
+ target-module@4c000000 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ reg = <0x4c000000 0x4>;
+ reg-names = "rev";
+ clocks = <&l3_clkctrl AM3_L3_EMIF_CLKCTRL 0>;
+ clock-names = "fck";
ti,no-idle;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x4c000000 0x1000000>;
+
+ emif: emif@0 {
+ compatible = "ti,emif-am3352";
+ reg = <0 0x1000000>;
+ interrupts = <101>;
+ sram = <&pm_sram_code
+ &pm_sram_data>;
+ };
};
- gpmc: gpmc@50000000 {
- compatible = "ti,am3352-gpmc";
- ti,hwmods = "gpmc";
- ti,no-idle-on-init;
- reg = <0x50000000 0x2000>;
- interrupts = <100>;
- dmas = <&edma 52 0>;
- dma-names = "rxtx";
- gpmc,num-cs = <7>;
- gpmc,num-waitpins = <2>;
- #address-cells = <2>;
+ target-module@50000000 {
+ compatible = "ti,sysc-omap2", "ti,sysc";
+ reg = <0x50000000 4>,
+ <0x50000010 4>,
+ <0x50000014 4>;
+ reg-names = "rev", "sysc", "syss";
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,syss-mask = <1>;
+ clocks = <&l3s_clkctrl AM3_L3S_GPMC_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
#size-cells = <1>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- status = "disabled";
+ ranges = <0x50000000 0x50000000 0x00001000>, /* regs */
+ <0x00000000 0x00000000 0x40000000>; /* data */
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ reg = <0x50000000 0x2000>;
+ interrupts = <100>;
+ dmas = <&edma 52 0>;
+ dma-names = "rxtx";
+ gpmc,num-cs = <7>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ status = "disabled";
+ };
};
sham_target: target-module@53100000 {
@@ -601,12 +642,20 @@ prm_per: prm@c00 {
compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
reg = <0xc00 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
};
prm_wkup: prm@d00 {
compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
reg = <0xd00 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_mpu: prm@e00 {
+ compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
+ reg = <0xe00 0x100>;
+ #power-domain-cells = <0>;
};
prm_device: prm@f00 {
@@ -615,16 +664,31 @@ prm_device: prm@f00 {
#reset-cells = <1>;
};
+ prm_rtc: prm@1000 {
+ compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1000 0x100>;
+ #power-domain-cells = <0>;
+ };
+
prm_gfx: prm@1100 {
compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
reg = <0x1100 0x100>;
#power-domain-cells = <0>;
#reset-cells = <1>;
};
+
+ prm_cefuse: prm@1200 {
+ compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1200 0x100>;
+ #power-domain-cells = <0>;
+ };
};
/* Preferred always-on timer for clocksource */
&timer1_target {
+ clocks = <&l4_wkup_clkctrl AM3_L4_WKUP_TIMER1_CLKCTRL 0>,
+ <&l4_wkup_clkctrl AM3_L4_WKUP_L4_WKUP_CLKCTRL 0>;
+ clock-names = "fck", "ick";
ti,no-reset-on-init;
ti,no-idle;
timer@0 {
@@ -635,6 +699,9 @@ timer@0 {
/* Preferred timer for clockevent */
&timer2_target {
+ clocks = <&l4ls_clkctrl AM3_L4LS_TIMER2_CLKCTRL 0>,
+ <&l4ls_clkctrl AM3_L4LS_L4_LS_CLKCTRL 0>;
+ clock-names = "fck", "ick";
ti,no-reset-on-init;
ti,no-idle;
timer@0 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 878406b..57a85a6 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -107,12 +107,6 @@ oppnitro-1000000000 {
soc {
compatible = "ti,omap-infra";
- mpu {
- compatible = "ti,omap4-mpu";
- ti,hwmods = "mpu";
- pm-sram = <&pm_sram_code
- &pm_sram_data>;
- };
};
gic: interrupt-controller@48241000 {
@@ -161,40 +155,48 @@ cache-controller@48242000 {
};
ocp@44000000 {
- compatible = "ti,am4372-l3-noc", "simple-bus";
+ compatible = "simple-pm-bus";
+ power-domains = <&prm_per>;
+ clocks = <&l3_clkctrl AM4_L3_L3_MAIN_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges;
- ti,hwmods = "l3_main";
ti,no-idle;
- reg = <0x44000000 0x400000
- 0x44800000 0x400000>;
- interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+
+ l3-noc@44000000 {
+ compatible = "ti,am4372-l3-noc";
+ reg = <0x44000000 0x400000>,
+ <0x44800000 0x400000>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ };
l4_wkup: interconnect@44c00000 {
- wkup_m3: wkup_m3@100000 {
- compatible = "ti,am4372-wkup-m3";
- reg = <0x100000 0x4000>,
- <0x180000 0x2000>;
- reg-names = "umem", "dmem";
- ti,hwmods = "wkup_m3";
- ti,pm-firmware = "am335x-pm-firmware.elf";
- };
};
l4_per: interconnect@48000000 {
};
l4_fast: interconnect@4a000000 {
};
- emif: emif@4c000000 {
- compatible = "ti,emif-am4372";
- reg = <0x4c000000 0x1000000>;
- ti,hwmods = "emif";
- interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ target-module@4c000000 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ reg = <0x4c000000 0x4>;
+ reg-names = "rev";
+ clocks = <&emif_clkctrl AM4_EMIF_EMIF_CLKCTRL 0>;
+ clock-names = "fck";
ti,no-idle;
- sram = <&pm_sram_code
- &pm_sram_data>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x4c000000 0x1000000>;
+
+ emif: emif@0 {
+ compatible = "ti,emif-am4372";
+ reg = <0 0x1000000>;
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ sram = <&pm_sram_code
+ &pm_sram_data>;
+ };
};
target-module@49000000 {
@@ -434,24 +436,41 @@ pruss_tm: target-module@54400000 {
ranges = <0x0 0x54400000 0x80000>;
};
- gpmc: gpmc@50000000 {
- compatible = "ti,am3352-gpmc";
- ti,hwmods = "gpmc";
- dmas = <&edma 52 0>;
- dma-names = "rxtx";
- clocks = <&l3s_gclk>;
+ target-module@50000000 {
+ compatible = "ti,sysc-omap2", "ti,sysc";
+ reg = <0x50000000 4>,
+ <0x50000010 4>,
+ <0x50000014 4>;
+ reg-names = "rev", "sysc", "syss";
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,syss-mask = <1>;
+ clocks = <&l3s_clkctrl AM4_L3S_GPMC_CLKCTRL 0>;
clock-names = "fck";
- reg = <0x50000000 0x2000>;
- interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
- gpmc,num-cs = <7>;
- gpmc,num-waitpins = <2>;
- #address-cells = <2>;
+ #address-cells = <1>;
#size-cells = <1>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- status = "disabled";
+ ranges = <0x50000000 0x50000000 0x00001000>, /* regs */
+ <0x00000000 0x00000000 0x40000000>; /* data */
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ dmas = <&edma 52 0>;
+ dma-names = "rxtx";
+ clocks = <&l3s_gclk>;
+ clock-names = "fck";
+ reg = <0x50000000 0x2000>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+ gpmc,num-cs = <7>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ status = "disabled";
+ };
};
target-module@47900000 {
@@ -484,23 +503,33 @@ qspi: spi@0 {
};
};
- ocmcram: sram@40300000 {
- compatible = "mmio-sram";
- reg = <0x40300000 0x40000>; /* 256k */
- ranges = <0x0 0x40300000 0x40000>;
+ target-module@40300000 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ clocks = <&l3_clkctrl AM4_L3_OCMCRAM_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0x40300000 0x40000>;
- pm_sram_code: pm-code-sram@0 {
- compatible = "ti,sram";
- reg = <0x0 0x1000>;
- protect-exec;
- };
+ ocmcram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0 0x40000>; /* 256k */
+ ranges = <0 0 0x40000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
- pm_sram_data: pm-data-sram@1000 {
- compatible = "ti,sram";
- reg = <0x1000 0x1000>;
- pool;
+ pm_sram_code: pm-code-sram@0 {
+ compatible = "ti,sram";
+ reg = <0x0 0x1000>;
+ protect-exec;
+ };
+
+ pm_sram_data: pm-data-sram@1000 {
+ compatible = "ti,sram";
+ reg = <0x1000 0x1000>;
+ pool;
+ };
};
};
@@ -531,6 +560,12 @@ target-module@56000000 {
#include "am43xx-clocks.dtsi"
&prcm {
+ prm_mpu: prm@300 {
+ compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
+ reg = <0x300 0x100>;
+ #power-domain-cells = <0>;
+ };
+
prm_gfx: prm@400 {
compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
reg = <0x400 0x100>;
@@ -538,16 +573,36 @@ prm_gfx: prm@400 {
#reset-cells = <1>;
};
+ prm_rtc: prm@500 {
+ compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
+ reg = <0x500 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_tamper: prm@600 {
+ compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
+ reg = <0x600 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_cefuse: prm@700 {
+ compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
+ reg = <0x700 0x100>;
+ #power-domain-cells = <0>;
+ };
+
prm_per: prm@800 {
compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
reg = <0x800 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
};
prm_wkup: prm@2000 {
compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
reg = <0x2000 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
};
prm_device: prm@4000 {
@@ -561,6 +616,9 @@ prm_device: prm@4000 {
&timer1_target {
ti,no-reset-on-init;
ti,no-idle;
+ clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_TIMER1_CLKCTRL 0>,
+ <&l4_wkup_clkctrl AM4_L4_WKUP_L4_WKUP_CLKCTRL 0>;
+ clock-names = "fck", "ick";
timer@0 {
assigned-clocks = <&timer1_fck>;
assigned-clock-parents = <&sys_clkin_ck>;
@@ -571,6 +629,9 @@ timer@0 {
&timer2_target {
ti,no-reset-on-init;
ti,no-idle;
+ clocks = <&l4ls_clkctrl AM4_L4LS_TIMER2_CLKCTRL 0>,
+ <&l4ls_clkctrl AM4_L4LS_L4_LS_CLKCTRL 0>;
+ clock-names = "fck", "ick";
timer@0 {
assigned-clocks = <&timer2_fck>;
assigned-clock-parents = <&sys_clkin_ck>;
diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
index 243e35f..e217ffc 100644
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -1,5 +1,8 @@
&l4_wkup { /* 0x44c00000 */
- compatible = "ti,am4-l4-wkup", "simple-bus";
+ compatible = "ti,am4-l4-wkup", "simple-pm-bus";
+ power-domains = <&prm_wkup>;
+ clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_L4_WKUP_CLKCTRL 0>;
+ clock-names = "fck";
reg = <0x44c00000 0x800>,
<0x44c00800 0x800>,
<0x44c01000 0x400>,
@@ -12,7 +15,7 @@
<0x00200000 0x44e00000 0x100000>; /* segment 2 */
segment@0 { /* 0x44c00000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
@@ -22,7 +25,7 @@ segment@0 { /* 0x44c00000 */
};
segment@100000 { /* 0x44d00000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00100000 0x004000>, /* ap 4 */
@@ -32,19 +35,25 @@ segment@100000 { /* 0x44d00000 */
<0x000f0000 0x001f0000 0x010000>; /* ap 8 */
target-module@0 { /* 0x44d00000, ap 4 28.0 */
- compatible = "ti,sysc";
- status = "disabled";
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x0 0x4>;
+ reg-names = "rev";
+ clocks = <&l4_wkup_aon_clkctrl AM4_L4_WKUP_AON_WKUP_M3_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x0 0x4000>;
- };
+ ranges = <0x00000000 0x00000000 0x4000>,
+ <0x00080000 0x00080000 0x2000>;
- target-module@80000 { /* 0x44d80000, ap 6 10.0 */
- compatible = "ti,sysc";
- status = "disabled";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80000 0x2000>;
+ wkup_m3: cpu@0 {
+ compatible = "ti,am4372-wkup-m3";
+ reg = <0x00000000 0x4000>,
+ <0x00080000 0x2000>;
+ reg-names = "umem", "dmem";
+ resets = <&prm_wkup 3>;
+ reset-names = "rstctrl";
+ ti,pm-firmware = "am335x-pm-firmware.elf";
+ };
};
target-module@f0000 { /* 0x44df0000, ap 8 58.0 */
@@ -75,7 +84,7 @@ prcm_clockdomains: clockdomains {
};
segment@200000 { /* 0x44e00000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00200000 0x001000>, /* ap 9 */
@@ -265,6 +274,9 @@ target-module@10000 { /* 0x44e10000, ap 22 0c.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x10000 0x4>;
reg-names = "rev";
+ clocks = <&l4_wkup_clkctrl AM4_L4_WKUP_CONTROL_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x10000 0x10000>;
@@ -419,6 +431,7 @@ rtc_target: target-module@3e000 { /* 0x44e3e000, ap 34 60.0 */
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
/* Domains (P, C): rtc_pwrdm, l4_rtc_clkdm */
+ power-domains = <&prm_rtc>;
clocks = <&l4_rtc_clkctrl AM4_L4_RTC_RTC_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
@@ -479,7 +492,10 @@ target-module@88000 { /* 0x44e88000, ap 38 12.0 */
};
&l4_fast { /* 0x4a000000 */
- compatible = "ti,am4-l4-fast", "simple-bus";
+ compatible = "ti,am4-l4-fast", "simple-pm-bus";
+ power-domains = <&prm_per>;
+ clocks = <&l3_clkctrl AM4_L3_L4_HS_CLKCTRL 0>;
+ clock-names = "fck";
reg = <0x4a000000 0x800>,
<0x4a000800 0x800>,
<0x4a001000 0x400>;
@@ -489,7 +505,7 @@ &l4_fast { /* 0x4a000000 */
ranges = <0x00000000 0x4a000000 0x1000000>; /* segment 0 */
segment@0 { /* 0x4a000000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
@@ -594,7 +610,10 @@ target-module@400000 { /* 0x4a400000, ap 5 08.0 */
};
&l4_per { /* 0x48000000 */
- compatible = "ti,am4-l4-per", "simple-bus";
+ compatible = "ti,am4-l4-per", "simple-pm-bus";
+ power-domains = <&prm_per>;
+ clocks = <&l4ls_clkctrl AM4_L4LS_L4_LS_CLKCTRL 0>;
+ clock-names = "fck";
reg = <0x48000000 0x800>,
<0x48000800 0x800>,
<0x48001000 0x400>,
@@ -612,7 +631,7 @@ &l4_per { /* 0x48000000 */
<0x46400000 0x46400000 0x400000>; /* l3 data port */
segment@0 { /* 0x48000000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00000000 0x000800>, /* ap 0 */
@@ -1187,7 +1206,7 @@ hwspinlock: spinlock@0 {
};
segment@100000 { /* 0x48100000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0008c000 0x0018c000 0x001000>, /* ap 34 */
@@ -1618,13 +1637,31 @@ mmc2: mmc@0 {
};
segment@200000 { /* 0x48200000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0x00000000 0x00200000 0x010000>;
+
+ target-module@0 {
+ compatible = "ti,sysc-omap4-simple", "ti,sysc";
+ power-domains = <&prm_mpu>;
+ clocks = <&mpu_clkctrl AM4_MPU_MPU_CLKCTRL 0>;
+ clock-names = "fck";
+ ti,no-idle;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x10000>;
+
+ mpu@0 {
+ compatible = "ti,omap4-mpu";
+ pm-sram = <&pm_sram_code
+ &pm_sram_data>;
+ };
+ };
};
segment@300000 { /* 0x48300000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x00300000 0x001000>, /* ap 56 */
@@ -2388,7 +2425,7 @@ dwc3_1: omap_dwc3@0 {
ranges = <0 0 0x20000>;
usb1: usb@10000 {
- compatible = "synopsys,dwc3";
+ compatible = "snps,dwc3";
reg = <0x10000 0x10000>;
interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
@@ -2468,7 +2505,7 @@ dwc3_2: omap_dwc3@0 {
ranges = <0 0 0x20000>;
usb2: usb@10000 {
- compatible = "synopsys,dwc3";
+ compatible = "snps,dwc3";
reg = <0x10000 0x10000>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 9805e507..7f2f24a 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -426,7 +426,7 @@ usb1: usb@54000 {
status = "disabled";
};
- usb2: usb3@58000 {
+ usb2: usb@58000 {
compatible = "marvell,armada-375-xhci";
reg = <0x58000 0x20000>,<0x5b880 0x80>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
new file mode 100644
index 0000000..584f0d0
--- /dev/null
+++ b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Marvell Armada 382 reference board
+ * (RD-AC3X-48G4X2XL)
+ *
+ * Copyright (C) 2020 Allied Telesis Labs
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Marvell Armada 382 RD-AC3X";
+ compatible = "marvell,rd-ac3x-48g4x2xl", "marvell,rd-ac3x",
+ "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliases {
+ ethernet0 = ð1;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>; /* 512MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+ };
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ eeprom@53{
+ compatible = "atmel,24c64";
+ reg = <0x53>;
+ };
+
+ /* CPLD device present at 0x3c. Function unknown */
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+ð1 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&pciec {
+ status = "okay";
+};
+
+&pcie1 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+};
+
+&nand_controller {
+ status = "okay";
+
+ nand@0 {
+ reg = <0>;
+ label = "pxa3xx_nand-0";
+ nand-rb = <0>;
+ nand-on-flash-bbt;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ reg = <0x00000000 0x00500000>;
+ label = "u-boot";
+ };
+ partition@500000{
+ reg = <0x00500000 0x00400000>;
+ label = "u-boot env";
+ };
+ partition@900000{
+ reg = <0x00900000 0x3F700000>;
+ label = "user";
+ };
+ };
+ };
+};
+
+&refclk {
+ clock-frequency = <200000000>;
+};
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index 768b6c5..646a064 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -12,6 +12,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include "armada-385.dtsi"
/ {
@@ -82,6 +83,32 @@ pcie@3,0 {
};
};
};
+
+ sfp: sfp {
+ compatible = "sff,sfp";
+ i2c-bus = <&sfp_i2c>;
+ tx-fault-gpios = <&pcawan 0 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = <&pcawan 1 GPIO_ACTIVE_HIGH>;
+ rate-select0-gpios = <&pcawan 2 GPIO_ACTIVE_HIGH>;
+ los-gpios = <&pcawan 3 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpios = <&pcawan 4 GPIO_ACTIVE_LOW>;
+ maximum-power-milliwatt = <3000>;
+
+ /*
+ * For now this has to be enabled at boot time by U-Boot when
+ * a SFP module is present. Read more in the comment in the
+ * eth2 node below.
+ */
+ status = "disabled";
+ };
+};
+
+&bm {
+ status = "okay";
+};
+
+&bm_bppi {
+ status = "okay";
};
/* Connected to 88E6176 switch, port 6 */
@@ -90,6 +117,9 @@ ð0 {
pinctrl-0 = <&ge0_rgmii_pins>;
status = "okay";
phy-mode = "rgmii";
+ buffer-manager = <&bm>;
+ bm,pool-long = <0>;
+ bm,pool-short = <3>;
fixed-link {
speed = <1000>;
@@ -103,6 +133,9 @@ ð1 {
pinctrl-0 = <&ge1_rgmii_pins>;
status = "okay";
phy-mode = "rgmii";
+ buffer-manager = <&bm>;
+ bm,pool-long = <1>;
+ bm,pool-short = <3>;
fixed-link {
speed = <1000>;
@@ -112,9 +145,23 @@ fixed-link {
/* WAN port */
ð2 {
+ /*
+ * eth2 is connected via a multiplexor to both the SFP cage and to
+ * ethernet-phy@1. The multiplexor switches the signal to SFP cage when
+ * a SFP module is present, as determined by the mode-def0 GPIO.
+ *
+ * Until kernel supports this configuration properly, in case SFP module
+ * is present, U-Boot has to enable the sfp node above, remove phy
+ * handle and add managed = "in-band-status" property.
+ */
status = "okay";
phy-mode = "sgmii";
- phy = <&phy1>;
+ phy-handle = <&phy1>;
+ phys = <&comphy5 2>;
+ sfp = <&sfp>;
+ buffer-manager = <&bm>;
+ bm,pool-long = <2>;
+ bm,pool-short = <3>;
};
&i2c0 {
@@ -127,7 +174,6 @@ i2cmux@70 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
- status = "okay";
i2c@0 {
#address-cells = <1>;
@@ -135,7 +181,115 @@ i2c@0 {
reg = <0>;
/* STM32F0 command interface at address 0x2a */
- /* leds device (in STM32F0) at address 0x2b */
+
+ led-controller@2b {
+ compatible = "cznic,turris-omnia-leds";
+ reg = <0x2b>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * LEDs are controlled by MCU (STM32F0) at
+ * address 0x2b.
+ *
+ * The driver does not support HW control mode
+ * for the LEDs yet. Disable the LEDs for now.
+ *
+ * Also LED functions are not stable yet:
+ * - there are 3 LEDs connected via MCU to PCIe
+ * ports. One of these ports supports mSATA.
+ * There is no mSATA nor PCIe function.
+ * For now we use LED_FUNCTION_WLAN, since
+ * in most cases users have wifi cards in
+ * these slots
+ * - there are 2 LEDs dedicated for user: A and
+ * B. Again there is no such function defined.
+ * For now we use LED_FUNCTION_INDICATOR
+ */
+ status = "disabled";
+
+ multi-led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <2>;
+ };
+
+ multi-led@1 {
+ reg = <0x1>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <1>;
+ };
+
+ multi-led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_WLAN;
+ function-enumerator = <3>;
+ };
+
+ multi-led@3 {
+ reg = <0x3>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_WLAN;
+ function-enumerator = <2>;
+ };
+
+ multi-led@4 {
+ reg = <0x4>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_WLAN;
+ function-enumerator = <1>;
+ };
+
+ multi-led@5 {
+ reg = <0x5>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_WAN;
+ };
+
+ multi-led@6 {
+ reg = <0x6>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <4>;
+ };
+
+ multi-led@7 {
+ reg = <0x7>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <3>;
+ };
+
+ multi-led@8 {
+ reg = <0x8>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <2>;
+ };
+
+ multi-led@9 {
+ reg = <0x9>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ };
+
+ multi-led@a {
+ reg = <0xa>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ };
+
+ multi-led@b {
+ reg = <0xb>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_POWER;
+ };
+ };
eeprom@54 {
compatible = "atmel,24c64";
@@ -177,7 +331,7 @@ i2c@3 {
/* routed to PCIe2 connector (CN62A) */
};
- i2c@4 {
+ sfp_i2c: i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
@@ -232,9 +386,8 @@ &mdio {
pinctrl-0 = <&mdio_pins>;
status = "okay";
- phy1: phy@1 {
- status = "okay";
- compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
/* irq is connected to &pcawan pin 7 */
@@ -242,13 +395,18 @@ phy1: phy@1 {
/* Switch MV88E6176 at address 0x10 */
switch@10 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&swint_pins>;
compatible = "marvell,mv88e6085";
#address-cells = <1>;
#size-cells = <0>;
- dsa,member = <0 0>;
+ dsa,member = <0 0>;
reg = <0x10>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -301,6 +459,11 @@ pcawan_pins: pcawan-pins {
marvell,function = "gpio";
};
+ swint_pins: swint-pins {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+
spi0cs0_pins: spi0cs0-pins {
marvell,pins = "mpp25";
marvell,function = "spi0";
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index 20f8d46..4140a53 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -73,13 +73,13 @@ &expander0 {
* 14-SFP_TX_DISABLE
* 15-SFP_MOD_DEF0
*/
- pcie2_0_clkreq {
+ pcie2-0-clkreq-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_LOW>;
input;
line-name = "pcie2.0-clkreq";
};
- pcie2_0_w_disable {
+ pcie2-0-w-disable-hog {
gpio-hog;
gpios = <7 GPIO_ACTIVE_LOW>;
output-low;
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index a0aa1d1..f8a06ae 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -141,31 +141,31 @@ expander0: gpio-expander@20 {
#gpio-cells = <2>;
reg = <0x20>;
- pcie1_0_clkreq {
+ pcie1-0-clkreq-hog {
gpio-hog;
gpios = <0 GPIO_ACTIVE_LOW>;
input;
line-name = "pcie1.0-clkreq";
};
- pcie1_0_w_disable {
+ pcie1-0-w-disable-hog {
gpio-hog;
gpios = <3 GPIO_ACTIVE_LOW>;
output-low;
line-name = "pcie1.0-w-disable";
};
- usb3_ilimit {
+ usb3-ilimit-hog {
gpio-hog;
gpios = <5 GPIO_ACTIVE_LOW>;
input;
line-name = "usb3-current-limit";
};
- usb3_power {
+ usb3-power-hog {
gpio-hog;
gpios = <6 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "usb3-power";
};
- m2_devslp {
+ m2-devslp-hog {
gpio-hog;
gpios = <11 GPIO_ACTIVE_HIGH>;
output-low;
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
index fb49df2..b3728de 100644
--- a/arch/arm/boot/dts/armada-388-helios4.dts
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -166,19 +166,19 @@ expander0: gpio-expander@20 {
interrupt-controller;
#interrupt-cells = <2>;
- board_rev_bit_0 {
+ board-rev-bit-0-hog {
gpio-hog;
gpios = <0 GPIO_ACTIVE_LOW>;
input;
line-name = "board-rev-0";
};
- board_rev_bit_1 {
+ board-rev-bit-1-hog {
gpio-hog;
gpios = <1 GPIO_ACTIVE_LOW>;
input;
line-name = "board-rev-1";
};
- usb3_ilimit {
+ usb3-ilimit-hog {
gpio-hog;
gpios = <5 GPIO_ACTIVE_HIGH>;
input;
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index 654648b..38a052a 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -264,11 +264,8 @@ refclk: oscillator {
&i2c0 {
compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
reg = <0x11000 0x100>;
-};
-
-&i2c1 {
- compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
- reg = <0x11100 0x100>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
};
&mpic {
@@ -324,6 +321,11 @@ spi0_pins: spi0-pins {
"mpp2", "mpp3";
marvell,function = "spi0";
};
+
+ i2c0_pins: i2c-pins-0 {
+ marvell,pins = "mpp14", "mpp15";
+ marvell,function = "i2c0";
+ };
};
&spi0 {
diff --git a/arch/arm/boot/dts/armada-xp-crs305-1g-4s-bit.dts b/arch/arm/boot/dts/armada-xp-crs305-1g-4s-bit.dts
new file mode 100644
index 0000000..a022c68
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs305-1g-4s-bit.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for MikroTik CRS305-1G-4S+ Bit board
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic <luka.kovacic@sartura.hr>
+ */
+
+#include "armada-xp-crs305-1g-4s.dtsi"
+
+/ {
+ model = "MikroTik CRS305-1G-4S+ Bit";
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x00000000 0x001f0000>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x001f0000 0x00010000>;
+ label = "u-boot-env";
+ };
+ partition@ubi1 {
+ reg = <0x00200000 0x03f00000>;
+ label = "ubi1";
+ };
+ partition@ubi2 {
+ reg = <0x04100000 0x03f00000>;
+ label = "ubi2";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts b/arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts
new file mode 100644
index 0000000..010b83b
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for MikroTik CRS305-1G-4S+ board
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic <luka.kovacic@sartura.hr>
+ */
+
+#include "armada-xp-crs305-1g-4s.dtsi"
+
+/ {
+ model = "MikroTik CRS305-1G-4S+";
+};
+
+&spi0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs305-1g-4s.dtsi b/arch/arm/boot/dts/armada-xp-crs305-1g-4s.dtsi
new file mode 100644
index 0000000..32fb21b
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs305-1g-4s.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS305-1G-4S board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ * Copyright (C) 2020 Sartura Ltd.
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf1000000 (instead of the default
+ * 0xd0000000). The 0xf1000000 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd0000000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3236.dtsi"
+
+/ {
+ model = "CRS305-1G-4S+";
+ compatible = "mikrotik,crs305-1g-4s", "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x20000000>; /* 512 MB */
+ };
+};
+
+&L2 {
+ arm,parity-enable;
+ marvell,ecc-enable;
+};
+
+&devbus_bootcs {
+ status = "okay";
+
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <60000>;
+ devbus,wr-low-ps = <60000>;
+ devbus,ale-wr-ps = <60000>;
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x00000000 0x001f0000>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x001f0000 0x00010000>;
+ label = "u-boot-env";
+ };
+ partition@ubi1 {
+ reg = <0x00200000 0x00e00000>;
+ label = "ubi1";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs326-24g-2s-bit.dts b/arch/arm/boot/dts/armada-xp-crs326-24g-2s-bit.dts
new file mode 100644
index 0000000..21f442a
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs326-24g-2s-bit.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for MikroTik CRS326-24G-2S+ Bit board
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic <luka.kovacic@sartura.hr>
+ */
+
+#include "armada-xp-crs326-24g-2s.dtsi"
+
+/ {
+ model = "MikroTik CRS326-24G-2S+ Bit";
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x00000000 0x001f0000>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x001f0000 0x00010000>;
+ label = "u-boot-env";
+ };
+ partition@ubi1 {
+ reg = <0x00200000 0x03f00000>;
+ label = "ubi1";
+ };
+ partition@ubi2 {
+ reg = <0x04100000 0x03f00000>;
+ label = "ubi2";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts b/arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts
new file mode 100644
index 0000000..83aef43
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for MikroTik CRS326-24G-2S+ board
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic <luka.kovacic@sartura.hr>
+ */
+
+#include "armada-xp-crs326-24g-2s.dtsi"
+
+/ {
+ model = "MikroTik CRS326-24G-2S+";
+};
+
+&spi0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs326-24g-2s.dtsi b/arch/arm/boot/dts/armada-xp-crs326-24g-2s.dtsi
new file mode 100644
index 0000000..f3e1a25
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs326-24g-2s.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS326-24G-2S board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ * Copyright (C) 2020 Sartura Ltd.
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf1000000 (instead of the default
+ * 0xd0000000). The 0xf1000000 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd0000000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3236.dtsi"
+
+/ {
+ model = "CRS326-24G-2S+";
+ compatible = "mikrotik,crs326-24g-2s", "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x20000000>; /* 512 MB */
+ };
+};
+
+&L2 {
+ arm,parity-enable;
+ marvell,ecc-enable;
+};
+
+&devbus_bootcs {
+ status = "okay";
+
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <60000>;
+ devbus,wr-low-ps = <60000>;
+ devbus,ale-wr-ps = <60000>;
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x00000000 0x001f0000>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x001f0000 0x00010000>;
+ label = "u-boot-env";
+ };
+ partition@ubi1 {
+ reg = <0x00200000 0x00e00000>;
+ label = "ubi1";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s-bit.dts b/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s-bit.dts
new file mode 100644
index 0000000..e05aee6
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s-bit.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for MikroTik CRS328-4C-20S-4S+ Bit board
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic <luka.kovacic@sartura.hr>
+ */
+
+#include "armada-xp-crs328-4c-20s-4s.dtsi"
+
+/ {
+ model = "MikroTik CRS328-4C-20S-4S+ Bit";
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x00000000 0x001f0000>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x001f0000 0x00010000>;
+ label = "u-boot-env";
+ };
+ partition@ubi1 {
+ reg = <0x00200000 0x03f00000>;
+ label = "ubi1";
+ };
+ partition@ubi2 {
+ reg = <0x04100000 0x03f00000>;
+ label = "ubi2";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dts b/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dts
new file mode 100644
index 0000000..665757f
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for MikroTik CRS328-4C-20S-4S+ board
+ *
+ * Copyright (C) 2020 Sartura Ltd.
+ * Author: Luka Kovacic <luka.kovacic@sartura.hr>
+ */
+
+#include "armada-xp-crs328-4c-20s-4s.dtsi"
+
+/ {
+ model = "MikroTik CRS328-4C-20S-4S+";
+};
+
+&spi0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dtsi b/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dtsi
new file mode 100644
index 0000000..c8b1355
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for CRS328-4C-20S-4S+ board
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ * Copyright (C) 2020 Sartura Ltd.
+ *
+ * Based on armada-xp-db.dts
+ *
+ * Note: this Device Tree assumes that the bootloader has remapped the
+ * internal registers to 0xf1000000 (instead of the default
+ * 0xd0000000). The 0xf1000000 is the default used by the recent,
+ * DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
+ * boards were delivered with an older version of the bootloader that
+ * left internal registers mapped at 0xd0000000. If you are in this
+ * situation, you should either update your bootloader (preferred
+ * solution) or the below Device Tree should be adjusted.
+ */
+
+/dts-v1/;
+#include "armada-xp-98dx3236.dtsi"
+
+/ {
+ model = "CRS328-4C-20S-4S+";
+ compatible = "mikrotik,crs328-4c-20s-4s", "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x20000000>; /* 512 MB */
+ };
+};
+
+&L2 {
+ arm,parity-enable;
+ marvell,ecc-enable;
+};
+
+&devbus_bootcs {
+ status = "okay";
+
+ /* Device Bus parameters are required */
+
+ /* Read parameters */
+ devbus,bus-width = <16>;
+ devbus,turn-off-ps = <60000>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <60000>;
+ devbus,wr-low-ps = <60000>;
+ devbus,ale-wr-ps = <60000>;
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ m25p,fast-read;
+
+ partition@u-boot {
+ reg = <0x00000000 0x001f0000>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x001f0000 0x00010000>;
+ label = "u-boot-env";
+ };
+ partition@ubi1 {
+ reg = <0x00200000 0x00e00000>;
+ label = "ubi1";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
index 8d0f465..89be131 100644
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -23,6 +23,15 @@ memory@80000000 {
};
};
+&mdio0 {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
&mdio1 {
status = "okay";
@@ -50,6 +59,17 @@ ethphy3: ethernet-phy@0 {
};
};
+&mac0 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii1_default>;
+};
+
+
&mac1 {
status = "okay";
diff --git a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
index 60ba86f..96ff0ae 100644
--- a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
@@ -13,6 +13,21 @@ / {
memory@80000000 {
reg = <0x80000000 0x20000000>;
};
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ video_engine_memory: jpegbuffer {
+ size = <0x02000000>; /* 32M */
+ alignment = <0x01000000>;
+ compatible = "shared-dma-pool";
+ reusable;
+ };
+ };
+
+
aliases {
serial0 = &uart1;
serial4 = &uart5;
@@ -82,6 +97,50 @@ &pinctrl_adc3_default
&pinctrl_adc4_default>;
};
+&gpio {
+ status = "okay";
+ gpio-line-names =
+ /*A0-A7*/ "","","FAULT_LED","CHASSIS_ID_LED","","","","",
+ /*B0-B7*/ "","","","","","","","",
+ /*C0-C7*/ "CHASSIS_ID_BTN","INTRUDER","AC_LOSS","","","","","",
+ /*D0-D7*/ "HDT_DBREQ","LOCAL_SPI_ROM_SEL","FPGA_SPI_ROM_SEL","JTAG_MUX_S",
+ "JTAG_MUX_OE","HDT_SEL","ASERT_WARM_RST_BTN","FPGA_RSVD",
+ /*E0-E7*/ "","","MON_P0_PWR_BTN","MON_P0_RST_BTN","MON_P0_NMI_BTN",
+ "MON_P0_PWR_GOOD","MON_PWROK","MON_RESET",
+ /*F0-F7*/ "MON_P0_PROCHOT","MON_P1_PROCHOT","MON_P0_THERMTRIP",
+ "MON_P1_THERMTRIP","P0_PRESENT","P1_PRESENT","MON_ATX_PWR_OK","",
+ /*G0-G7*/ "BRD_REV_ID_3","BRD_REV_ID_2","BRD_REV_ID_1","BRD_REV_ID_0",
+ "P0_APML_ALERT","P1_APML_ALERT","FPGA ALERT","",
+ /*H0-H7*/ "BRD_ID_0","BRD_ID_1","BRD_ID_2","BRD_ID_3",
+ "PCIE_DISCONNECTED","USB_DISCONNECTED","SPARE_0","SPARE_1",
+ /*I0-I7*/ "","","","","","","","",
+ /*J0-J7*/ "","","","","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "","","","","","","","",
+ /*M0-M7*/ "ASSERT_PWR_BTN","ASSERT_RST_BTN","ASSERT_NMI_BTN",
+ "ASSERT_LOCAL_LOCK","ASSERT_P0_PROCHOT","ASSERT_P1_PROCHOT",
+ "ASSERT_CLR_CMOS","ASSERT_BMC_READY",
+ /*N0-N7*/ "","","","","","","","",
+ /*O0-O7*/ "","","","","","","","",
+ /*P0-P7*/ "P0_VDD_CORE_RUN_VRHOT","P0_VDD_SOC_RUN_VRHOT",
+ "P0_VDD_MEM_ABCD_SUS_VRHOT","P0_VDD_MEM_EFGH_SUS_VRHOT",
+ "P1_VDD_CORE_RUN_VRHOT","P1_VDD_SOC_RUN_VRHOT",
+ "P1_VDD_MEM_ABCD_SUS_VRHOT","P1_VDD_MEM_EFGH_SUS_VRHOT",
+ /*Q0-Q7*/ "","","","","","","","",
+ /*R0-R7*/ "","","","","","","","",
+ /*S0-S7*/ "","","","","","","","",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "","","","","","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","","","","",
+ /*Y0-Y7*/ "","","","","","","","",
+ /*Z0-Z7*/ "","","","","","","","",
+ /*AA0-AA7*/ "","SENSOR THERM","","","","","","",
+ /*AB0-AB7*/ "","","","","","","","",
+ /*AC0-AC7*/ "","","","","","","","";
+};
+
//APML for P0
&i2c0 {
status = "okay";
@@ -139,17 +198,22 @@ lm75a@4f {
&kcs1 {
status = "okay";
- kcs_addr = <0x60>;
+ aspeed,lpc-io-reg = <0x60>;
};
&kcs2 {
status = "okay";
- kcs_addr = <0x62>;
+ aspeed,lpc-io-reg = <0x62>;
+};
+
+&kcs3 {
+ status = "okay";
+ aspeed,lpc-io-reg = <0xCA2>;
};
&kcs4 {
status = "okay";
- kcs_addr = <0x97DE>;
+ aspeed,lpc-io-reg = <0x97DE>;
};
&lpc_snoop {
@@ -215,5 +279,12 @@ fan@7 {
};
};
+&video {
+ status = "okay";
+ memory-region = <&video_engine_memory>;
+};
+&vhub {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/aspeed-bmc-bytedance-g220a.dts b/arch/arm/boot/dts/aspeed-bmc-bytedance-g220a.dts
new file mode 100644
index 0000000..2feb25b
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-bytedance-g220a.dts
@@ -0,0 +1,924 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2020 Bytedance.
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/leds/leds-pca955x.h>
+
+/ {
+ model = "Bytedance G220A BMC";
+ compatible = "bytedance,g220a-bmc", "aspeed,ast2500";
+
+ aliases {
+ serial4 = &uart5;
+ i2c14 = &channel_3_0;
+ i2c15 = &channel_3_1;
+ i2c16 = &channel_3_2;
+ i2c17 = &channel_3_3;
+ i2c18 = &channel_6_0;
+ i2c19 = &channel_6_1;
+ i2c20 = &channel_6_2;
+ i2c21 = &channel_6_3;
+ i2c22 = &channel_6_4;
+ i2c23 = &channel_6_5;
+ i2c24 = &channel_6_6;
+ i2c25 = &channel_6_7;
+ i2c26 = &channel_6_8;
+ i2c27 = &channel_6_9;
+ i2c28 = &channel_6_10;
+ i2c29 = &channel_6_11;
+ i2c30 = &channel_6_12;
+ i2c31 = &channel_6_13;
+ i2c32 = &channel_6_14;
+ i2c33 = &channel_6_15;
+ i2c34 = &channel_6_16;
+ i2c35 = &channel_6_17;
+ i2c36 = &channel_6_18;
+ i2c37 = &channel_6_19;
+ i2c38 = &channel_6_20;
+ i2c39 = &channel_6_21;
+ i2c40 = &channel_6_22;
+ i2c41 = &channel_6_23;
+ i2c42 = &channel_6_24;
+ i2c43 = &channel_6_25;
+ i2c44 = &channel_10_0;
+ i2c45 = &channel_10_1;
+ i2c46 = &channel_10_2;
+ i2c47 = &channel_10_3;
+ i2c48 = &channel_10_4;
+ i2c49 = &channel_10_5;
+ i2c50 = &channel_10_6;
+ i2c51 = &channel_10_7;
+ };
+
+ chosen {
+ stdout-path = &uart5;
+ bootargs = "console=ttyS4,115200 earlyprintk";
+ };
+
+ memory@80000000 {
+ reg = <0x80000000 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ vga_memory: framebuffer@bc000000 {
+ no-map;
+ reg = <0xbc000000 0x04000000>; /* 64M */
+ };
+
+ video_engine_memory: jpegbuffer {
+ size = <0x02000000>; /* 32M */
+ alignment = <0x01000000>;
+ compatible = "shared-dma-pool";
+ reusable;
+ };
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 3>,
+ <&adc 4>, <&adc 5>, <&adc 6>, <&adc 7>,
+ <&adc 8>, <&adc 9>, <&adc 10>, <&adc 11>,
+ <&adc 12>, <&adc 13>, <&adc 14>, <&adc 15>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ bmc_alive {
+ label = "bmc_alive";
+ gpios = <&gpio ASPEED_GPIO(B, 0) GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "timer";
+ led-pattern = <1000 1000>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ burn-in-signal {
+ label = "burn-in";
+ gpios = <&gpio ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(R, 5)>;
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ poll-interval = <1000>;
+
+ rear-riser1-presence {
+ label = "rear-riser1-presence";
+ gpios = <&pca0 1 GPIO_ACTIVE_LOW>;
+ linux,code = <1>;
+ };
+
+ alrt-pvddq-cpu0 {
+ label = "alrt-pvddq-cpu0";
+ gpios = <&pca0 8 GPIO_ACTIVE_LOW>;
+ linux,code = <2>;
+ };
+
+ rear-riser0-presence {
+ label = "rear-riser0-presence";
+ gpios = <&pca0 9 GPIO_ACTIVE_LOW>;
+ linux,code = <3>;
+ };
+
+ fault-pvddq-cpu0 {
+ label = "fault-pvddq-cpu0";
+ gpios = <&pca0 10 GPIO_ACTIVE_LOW>;
+ linux,code = <4>;
+ };
+
+ alrt-pvddq-cpu1 {
+ label = "alrt-pvddq-cpu1";
+ gpios = <&pca0 11 GPIO_ACTIVE_LOW>;
+ linux,code = <5>;
+ };
+
+ fault-pvddq-cpu1 {
+ label = "alrt-pvddq-cpu1";
+ gpios = <&pca0 12 GPIO_ACTIVE_LOW>;
+ linux,code = <6>;
+ };
+
+ fault-pvccin-cpu1 {
+ label = "fault-pvccin-cpuq";
+ gpios = <&pca0 13 GPIO_ACTIVE_LOW>;
+ linux,code = <7>;
+ };
+
+ bmc-rom0-wp {
+ label = "bmc-rom0-wp";
+ gpios = <&pca1 0 GPIO_ACTIVE_LOW>;
+ linux,code = <8>;
+ };
+
+ bmc-rom1-wp {
+ label = "bmc-rom1-wp";
+ gpios = <&pca1 1 GPIO_ACTIVE_LOW>;
+ linux,code = <9>;
+ };
+
+ fan0-presence {
+ label = "fan0-presence";
+ gpios = <&pca1 2 GPIO_ACTIVE_LOW>;
+ linux,code = <10>;
+ };
+
+ fan1-presence {
+ label = "fan1-presence";
+ gpios = <&pca1 3 GPIO_ACTIVE_LOW>;
+ linux,code = <11>;
+ };
+
+ fan2-presence {
+ label = "fan2-presence";
+ gpios = <&pca1 4 GPIO_ACTIVE_LOW>;
+ linux,code = <12>;
+ };
+
+ fan3-presence {
+ label = "fan3-presence";
+ gpios = <&pca1 5 GPIO_ACTIVE_LOW>;
+ linux,code = <13>;
+ };
+
+ fan4-presence {
+ label = "fan4-presence";
+ gpios = <&pca1 6 GPIO_ACTIVE_LOW>;
+ linux,code = <14>;
+ };
+
+ fan5-presence {
+ label = "fan5-presence";
+ gpios = <&pca1 7 GPIO_ACTIVE_LOW>;
+ linux,code = <15>;
+ };
+
+ front-bp1-presence {
+ label = "front-bp1-presence";
+ gpios = <&pca1 8 GPIO_ACTIVE_LOW>;
+ linux,code = <16>;
+ };
+
+ rear-bp-presence {
+ label = "rear-bp-presence";
+ gpios = <&pca1 9 GPIO_ACTIVE_LOW>;
+ linux,code = <17>;
+ };
+
+ fault-pvccin-cpu0 {
+ label = "fault-pvccin-cpu0";
+ gpios = <&pca1 10 GPIO_ACTIVE_LOW>;
+ linux,code = <18>;
+ };
+
+ alrt-p1v05-pvcc {
+ label = "alrt-p1v05-pvcc1";
+ gpios = <&pca1 11 GPIO_ACTIVE_LOW>;
+ linux,code = <19>;
+ };
+
+ fault-p1v05-pvccio {
+ label = "alrt-p1v05-pvcc1";
+ gpios = <&pca1 12 GPIO_ACTIVE_LOW>;
+ linux,code = <20>;
+ };
+
+ alrt-p1v8-pvccio {
+ label = "alrt-p1v8-pvccio";
+ gpios = <&pca1 13 GPIO_ACTIVE_LOW>;
+ linux,code = <21>;
+ };
+
+ fault-p1v8-pvccio {
+ label = "fault-p1v8-pvccio";
+ gpios = <&pca1 14 GPIO_ACTIVE_LOW>;
+ linux,code = <22>;
+ };
+
+ front-bp0-presence {
+ label = "front-bp0-presence";
+ gpios = <&pca1 15 GPIO_ACTIVE_LOW>;
+ linux,code = <23>;
+ };
+ };
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ label = "bmc";
+ m25p,fast-read;
+ spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-64.dtsi"
+ };
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi1_default>;
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bios";
+ spi-max-frequency = <100000000>;
+ };
+};
+
+&adc {
+ status = "okay";
+};
+
+&gpio {
+ status = "okay";
+ gpio-line-names =
+ /*A0-A7*/ "SMRST_OCP_N","MAC2_LINK","BMC_CPLD_SMB_RST_R_N","BMC_CPLD_GPIO0",
+ "","","","",
+ /*B0-B7*/ "BMC_INIT_R_OK","FM_BOARD_REV_ID2","FM_PROJECT_ID7","FAULT_P12V_STBY_N",
+ "","CPU0_PROCHOT_LVT3_N","","BIOS_LOAD_DEFAULT_R_N",
+ /*C0-C7*/ "","","","","","","","",
+ /*D0-D7*/ "","","","","","","","",
+ /*E0-E7*/ "FM_PROJECT_ID0","FM_PROJECT_ID1","FM_PROJECT_ID2","FM_PROJECT_ID3",
+ "FM_PROJECT_ID4","FM_PROJECT_ID5","","",
+ /*F0-F7*/ "PSU0_PRSNT_N","PSU1_PRSNT_N","","FAULT_P12V_NVME_N",
+ "BIOS_DEBUG_MODE_R_N","DISABLE_CPU_DDR_R_SPD","COOLING_STRATEGY",
+ "PCH_GLB_RST_N",
+ /*G0-G7*/ "P12V_PMBUS_ALERT_N","CPLD_ALERT_N","BMC_RELOAD_N",
+ "P12V_PVDDQ_PMBUS_ALERT_N","BMC_JTAG_TCK_MUX_R_SEL","","NMI_OUT",
+ "NMI_BUTTON",
+ /*H0-H7*/ "BMC_CPLD_JTAG_TDI","BMC_CPLD_JTAG_TDO","BMC_CPLD_JTAG_TCK",
+ "BMC_CPLD_JTAG_TMS","FM_PROJECT_ID6","FM_BOARD_REV_ID0",
+ "PCA9546_U70_RST_N","IRQ_SML0_ALERT_N",
+ /*I0-I7*/ "FAULT_FRONT_RISER_P12V_N","FAULT_OCP_P12V_N","FM_BMC_PCH_SCI_R_N",
+ "","","","","",
+ /*J0-J7*/ "FM_CPU0_SKTOCC_N","FM_CPU1_SKTOCC_N","FM_CPU1_DISABLE_COD_N",
+ "","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "P12V_FAULT_N","PWRGD_P12V_PCIE_RISER","","LEAKAGE_DETECT_INPUT_N",
+ "","IRQ_SML1_PMBUS_ALERT_N","","",
+ /*M0-M7*/ "","","","","","","","",
+ /*N0-N7*/ "","","","","","","","",
+ /*O0-O7*/ "","","","","","","","",
+ /*P0-P7*/ "","","","","","","","",
+ /*Q0-Q7*/ "","","","","","","FM_PCH_THERMTRIP_N","CHASSIS_INTRUSION",
+ /*R0-R7*/ "","PVCCIN_CPU1_SMBALERT_N","BMC_PREQ_R_N","FAULT_P12V_PCIE_RISER_N",
+ "ALT_P12V_PCIE_RISER_N","BURN_BOARD_N","PVCCIN_CPU0_SMBALERT_N","",
+ /*S0-S7*/ "BMC_PRDY_N","SIO_POWER_GOOD","FM_BMC_PWR_DEBUG_R_N",
+ "FM_BMC_XDP_DEBUG_EN","","STRAP_BMC_BATTERY_GPIOS5","","",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "","","","","","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","","","","",
+ /*Y0-Y7*/ "","PWRGD_PSU0_PWROK","CPU1_PROCHOT_LVT3_N","IRQ_BMC_PCH_SMI_LPC_N",
+ "","","","",
+ /*Z0-Z7*/ "XDP_PRSNT_N","BMC_XDP_SYS_PWROK","BMC_XDP_JTAG_SEL",
+ "PCH_BMC_SMI_ACTIVE_R_N","","","","",
+ /*AA0-AA7*/ "PWRGD_P12V_STBY_OCP","PS_PWROK","RST_PLTRST_BMC_R_N","HDA_SDO_R",
+ "FM_SLPS4_R_N","PWRGD_PSU1_PWROK","POWER_BUTTON","POWER_OUT",
+ /*AB0-AB7*/ "","RESET_OUT","SPI_BIOS_MODE_SELECT","POST_COMPLETE","","","","",
+ /*AC0-AC7*/ "","","","","","","","CPLD_PLTRST_B_N";
+};
+
+&kcs3 {
+ aspeed,lpc-io-reg = <0xCA2>;
+ status = "okay";
+};
+
+&kcs4 {
+ aspeed,lpc-io-reg = <0xCA4>;
+ status = "okay";
+};
+
+&lpc_snoop {
+ snoop-ports = <0x80>;
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd1_default
+ &pinctrl_rxd1_default
+ &pinctrl_nrts1_default
+ &pinctrl_ndtr1_default
+ &pinctrl_ndsr1_default
+ &pinctrl_ncts1_default
+ &pinctrl_ndcd1_default
+ &pinctrl_nri1_default>;
+};
+
+&uart2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd2_default
+ &pinctrl_rxd2_default
+ &pinctrl_nrts2_default
+ &pinctrl_ndtr2_default
+ &pinctrl_ndsr2_default
+ &pinctrl_ncts2_default
+ &pinctrl_ndcd2_default
+ &pinctrl_nri2_default>;
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&mac0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii1_default>;
+ clocks = <&syscon ASPEED_CLK_GATE_MAC1CLK>,
+ <&syscon ASPEED_CLK_MAC1RCLK>;
+ clock-names = "MACCLK", "RCLK";
+ use-ncsi;
+};
+
+&mac1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+ i2c-switch@70 {
+ compatible = "nxp,pca9546";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel_3_0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ channel_3_1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_3_2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_3_3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&i2c4 {
+ status = "okay";
+
+};
+
+&i2c5 {
+ status = "okay";
+};
+
+&i2c6 {
+ status = "okay";
+ i2c-switch@72 {
+ compatible = "nxp,pca9548";
+ reg = <0x72>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_6_0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ channel_6_1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_6_2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_6_3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ channel_6_4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ channel_6_5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ channel_6_6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ channel_6_7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
+
+ i2c-switch@70 {
+ compatible = "nxp,pca9546";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_6_8: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ i2c-switch@71 {
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_6_12: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ };
+
+ channel_6_13: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_6_14: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_6_15: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+ };
+
+ channel_6_9: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ i2c-switch@71 {
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_6_16: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ };
+
+ channel_6_17: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_6_18: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_6_19: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+ };
+
+ channel_6_10: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ i2c-switch@71 {
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_6_20: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ channel_6_21: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_6_22: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_6_23: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+ };
+
+ channel_6_11: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ i2c-switch@71 {
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_6_24: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ channel_6_25: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+ };
+};
+
+&i2c7 {
+ status = "okay";
+};
+
+&i2c8 {
+ status = "okay";
+ pca0:pca9555@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio@1 {
+ reg = <1>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@8 {
+ reg = <8>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@9 {
+ reg = <9>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@10 {
+ reg = <10>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@11 {
+ reg = <11>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@12 {
+ reg = <12>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@13 {
+ reg = <13>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+ };
+
+ pca1:pca9555@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio@0 {
+ reg = <0>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@1 {
+ reg = <1>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@2 {
+ reg = <2>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@3 {
+ reg = <3>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@4 {
+ reg = <4>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@5 {
+ reg = <5>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@6 {
+ reg = <6>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@7 {
+ reg = <7>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+ gpio@8 {
+ reg = <8>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@9 {
+ reg = <9>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@10 {
+ reg = <10>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@11 {
+ reg = <11>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@12 {
+ reg = <12>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@13 {
+ reg = <13>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@14 {
+ reg = <14>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio@15 {
+ reg = <15>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+ };
+};
+
+&i2c9 {
+ status = "okay";
+};
+
+&i2c10 {
+ status = "okay";
+ i2c-switch@70 {
+ compatible = "nxp,pca9546";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_10_0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ channel_10_1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_10_2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_10_3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+
+ i2c-switch@71 {
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel_10_4: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ channel_10_5: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ channel_10_6: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ channel_10_7: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&i2c11 {
+ status = "okay";
+};
+
+&i2c12 {
+ status = "okay";
+};
+
+&i2c13 {
+ status = "okay";
+};
+
+&pwm_tacho {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default
+ &pinctrl_pwm2_default &pinctrl_pwm3_default
+ &pinctrl_pwm4_default &pinctrl_pwm5_default>;
+
+ fan@0 {
+ reg = <0x00>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x00 0x01>;
+ };
+ fan@1 {
+ reg = <0x01>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x02 0x03>;
+ };
+ fan@2 {
+ reg = <0x02>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x04 0x05>;
+ };
+ fan@3 {
+ reg = <0x03>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x06 0x07>;
+ };
+ fan@4 {
+ reg = <0x04>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x08 0x09>;
+ };
+ fan@5 {
+ reg = <0x05>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x0a 0x0b>;
+ };
+};
+
+&gpio {
+ pin_gpio_i3 {
+ gpio-hog;
+ gpios = <ASPEED_GPIO(I, 3) GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "NCSI_BMC_R_SEL";
+ };
+
+ pin_gpio_b6 {
+ gpio-hog;
+ gpios = <ASPEED_GPIO(B, 6) GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "EN_NCSI_SWITCH_N";
+ };
+};
+
+&video {
+ status = "okay";
+ memory-region = <&video_engine_memory>;
+};
+
+&vhub {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-galaxy100.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-galaxy100.dts
new file mode 100644
index 0000000..dcf2134
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-galaxy100.dts
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2020 Facebook Inc.
+/dts-v1/;
+
+#include "ast2400-facebook-netbmc-common.dtsi"
+
+/ {
+ model = "Facebook Galaxy 100 BMC";
+ compatible = "facebook,galaxy100-bmc", "aspeed,ast2400";
+
+ chosen {
+ stdout-path = &uart5;
+ bootargs = "console=ttyS0,9600n8 root=/dev/ram rw";
+ };
+
+ ast-adc-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc 3>, <&adc 4>, <&adc 8>, <&adc 9>;
+ };
+};
+
+&wdt2 {
+ status = "okay";
+ aspeed,reset-type = "system";
+};
+
+&fmc {
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "spi0.1";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ flash1@0 {
+ reg = <0x0 0x2000000>;
+ label = "flash1";
+ };
+ };
+ };
+};
+
+
+&i2c9 {
+ status = "okay";
+};
+
+&vhub {
+ status = "okay";
+};
+
+&adc {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-minipack.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-minipack.dts
index c34741d..9eb23e8 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-minipack.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-minipack.dts
@@ -70,6 +70,162 @@ aliases {
i2c45 = &imux45;
i2c46 = &imux46;
i2c47 = &imux47;
+
+ /*
+ * I2C Switch 24-0071 (channel #0 of 8-0070): 8 channels for
+ * connecting to left PDB (Power Distribution Board).
+ */
+ i2c48 = &imux48;
+ i2c49 = &imux49;
+ i2c50 = &imux50;
+ i2c51 = &imux51;
+ i2c52 = &imux52;
+ i2c53 = &imux53;
+ i2c54 = &imux54;
+ i2c55 = &imux55;
+
+ /*
+ * I2C Switch 25-0072 (channel #1 of 8-0070): 8 channels for
+ * connecting to right PDB (Power Distribution Board).
+ */
+ i2c56 = &imux56;
+ i2c57 = &imux57;
+ i2c58 = &imux58;
+ i2c59 = &imux59;
+ i2c60 = &imux60;
+ i2c61 = &imux61;
+ i2c62 = &imux62;
+ i2c63 = &imux63;
+
+ /*
+ * I2C Switch 26-0076 (channel #2 of 8-0070): 8 channels for
+ * connecting to top FCM (Fan Control Module).
+ */
+ i2c64 = &imux64;
+ i2c65 = &imux65;
+ i2c66 = &imux66;
+ i2c67 = &imux67;
+ i2c68 = &imux68;
+ i2c69 = &imux69;
+ i2c70 = &imux70;
+ i2c71 = &imux71;
+
+ /*
+ * I2C Switch 27-0076 (channel #3 of 8-0070): 8 channels for
+ * connecting to bottom FCM (Fan Control Module).
+ */
+ i2c72 = &imux72;
+ i2c73 = &imux73;
+ i2c74 = &imux74;
+ i2c75 = &imux75;
+ i2c76 = &imux76;
+ i2c77 = &imux77;
+ i2c78 = &imux78;
+ i2c79 = &imux79;
+
+ /*
+ * I2C Switch 40-0073 (channel #0 of 11-0070): connecting
+ * to PIM (Port Interface Module) #1 (1-based).
+ */
+ i2c80 = &imux80;
+ i2c81 = &imux81;
+ i2c82 = &imux82;
+ i2c83 = &imux83;
+ i2c84 = &imux84;
+ i2c85 = &imux85;
+ i2c86 = &imux86;
+ i2c87 = &imux87;
+
+ /*
+ * I2C Switch 41-0073 (channel #1 of 11-0070): connecting
+ * to PIM (Port Interface Module) #2 (1-based).
+ */
+ i2c88 = &imux88;
+ i2c89 = &imux89;
+ i2c90 = &imux90;
+ i2c91 = &imux91;
+ i2c92 = &imux92;
+ i2c93 = &imux93;
+ i2c94 = &imux94;
+ i2c95 = &imux95;
+
+ /*
+ * I2C Switch 42-0073 (channel #2 of 11-0070): connecting
+ * to PIM (Port Interface Module) #3 (1-based).
+ */
+ i2c96 = &imux96;
+ i2c97 = &imux97;
+ i2c98 = &imux98;
+ i2c99 = &imux99;
+ i2c100 = &imux100;
+ i2c101 = &imux101;
+ i2c102 = &imux102;
+ i2c103 = &imux103;
+
+ /*
+ * I2C Switch 43-0073 (channel #3 of 11-0070): connecting
+ * to PIM (Port Interface Module) #4 (1-based).
+ */
+ i2c104 = &imux104;
+ i2c105 = &imux105;
+ i2c106 = &imux106;
+ i2c107 = &imux107;
+ i2c108 = &imux108;
+ i2c109 = &imux109;
+ i2c110 = &imux110;
+ i2c111 = &imux111;
+
+ /*
+ * I2C Switch 44-0073 (channel #4 of 11-0070): connecting
+ * to PIM (Port Interface Module) #5 (1-based).
+ */
+ i2c112 = &imux112;
+ i2c113 = &imux113;
+ i2c114 = &imux114;
+ i2c115 = &imux115;
+ i2c116 = &imux116;
+ i2c117 = &imux117;
+ i2c118 = &imux118;
+ i2c119 = &imux119;
+
+ /*
+ * I2C Switch 45-0073 (channel #5 of 11-0070): connecting
+ * to PIM (Port Interface Module) #6 (1-based).
+ */
+ i2c120 = &imux120;
+ i2c121 = &imux121;
+ i2c122 = &imux122;
+ i2c123 = &imux123;
+ i2c124 = &imux124;
+ i2c125 = &imux125;
+ i2c126 = &imux126;
+ i2c127 = &imux127;
+
+ /*
+ * I2C Switch 46-0073 (channel #6 of 11-0070): connecting
+ * to PIM (Port Interface Module) #7 (1-based).
+ */
+ i2c128 = &imux128;
+ i2c129 = &imux129;
+ i2c130 = &imux130;
+ i2c131 = &imux131;
+ i2c132 = &imux132;
+ i2c133 = &imux133;
+ i2c134 = &imux134;
+ i2c135 = &imux135;
+
+ /*
+ * I2C Switch 47-0073 (channel #7 of 11-0070): connecting
+ * to PIM (Port Interface Module) #8 (1-based).
+ */
+ i2c136 = &imux136;
+ i2c137 = &imux137;
+ i2c138 = &imux138;
+ i2c139 = &imux139;
+ i2c140 = &imux140;
+ i2c141 = &imux141;
+ i2c142 = &imux142;
+ i2c143 = &imux143;
};
chosen {
@@ -184,11 +340,16 @@ &i2c1 {
&i2c2 {
status = "okay";
+ /*
+ * I2C Switch 2-0070 is connecting to SCM (System Controller
+ * Module).
+ */
i2c-switch@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+ i2c-mux-idle-disconnect;
imux16: i2c@0 {
#address-cells = <1>;
@@ -269,29 +430,270 @@ i2c-switch@70 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+ i2c-mux-idle-disconnect;
+ /*
+ * I2C Switch 8-0070 channel #0: connecting to left PDB
+ * (Power Distribution Board).
+ */
imux24: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+
+ i2c-switch@71 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+
+ imux48: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux49: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux50: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux51: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux52: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux53: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux54: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux55: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 8-0070 channel #1: connecting to right PDB
+ * (Power Distribution Board).
+ */
imux25: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+ i2c-switch@72 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72>;
+ i2c-mux-idle-disconnect;
+
+ imux56: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux57: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux58: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux59: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux60: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux61: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux62: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux63: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 8-0070 channel #2: connecting to top FCM
+ * (Fan Control Module).
+ */
imux26: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
+
+ i2c-switch@76 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x76>;
+ i2c-mux-idle-disconnect;
+
+ imux64: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux65: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux66: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux67: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux68: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux69: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux70: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux71: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 8-0070 channel #3: connecting to bottom
+ * FCM (Fan Control Module).
+ */
imux27: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
+
+ i2c-switch@76 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x76>;
+ i2c-mux-idle-disconnect;
+
+ imux72: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux73: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux74: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux75: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux76: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux77: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux78: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux79: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
imux28: i2c@4 {
@@ -323,11 +725,16 @@ imux31: i2c@7 {
&i2c9 {
status = "okay";
+ /*
+ * I2C Switch 9-0070 is connecting to MAC/PHY EEPROMs on SMB
+ * (Switch Main Board).
+ */
i2c-switch@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+ i2c-mux-idle-disconnect;
imux32: i2c@0 {
#address-cells = <1>;
@@ -391,53 +798,534 @@ i2c-switch@70 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+ i2c-mux-idle-disconnect;
+ /*
+ * I2C Switch 11-0070 channel #0: connecting to PIM
+ * (Port Interface Module) #1 (1-based).
+ */
imux40: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux80: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux81: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux82: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux83: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux84: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux85: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux86: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux87: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #1: connecting to PIM
+ * (Port Interface Module) #2 (1-based).
+ */
imux41: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux88: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux89: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux90: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux91: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux92: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux93: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux94: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux95: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #2: connecting to PIM
+ * (Port Interface Module) #3 (1-based).
+ */
imux42: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux96: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux97: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux98: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux99: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux100: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux101: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux102: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux103: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #3: connecting to PIM
+ * (Port Interface Module) #4 (1-based).
+ */
imux43: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux104: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux105: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux106: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux107: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux108: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux109: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux110: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux111: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #4: connecting to PIM
+ * (Port Interface Module) #5 (1-based).
+ */
imux44: i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux112: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux113: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux114: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux115: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux116: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux117: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux118: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux119: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #5: connecting to PIM
+ * (Port Interface Module) #6 (1-based).
+ */
imux45: i2c@5 {
#address-cells = <1>;
#size-cells = <0>;
reg = <5>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux120: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux121: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux122: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux123: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux124: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux125: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux126: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux127: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #6: connecting to PIM
+ * (Port Interface Module) #7 (1-based).
+ */
imux46: i2c@6 {
#address-cells = <1>;
#size-cells = <0>;
reg = <6>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux128: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux129: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux130: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux131: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux132: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux133: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux134: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux135: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
+ /*
+ * I2C Switch 11-0070 channel #7: connecting to PIM
+ * (Port Interface Module) #8 (1-based).
+ */
imux47: i2c@7 {
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
+
+ i2c-switch@73 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x73>;
+ i2c-mux-idle-disconnect;
+
+ imux136: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ imux137: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ imux138: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ imux139: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+
+ imux140: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ };
+
+ imux141: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ };
+
+ imux142: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ };
+
+ imux143: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ };
+ };
};
};
};
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index 2d44d9a..cd18641 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -82,11 +82,6 @@ &lpc_ctrl {
status = "okay";
};
-&vuart {
- // VUART Host Console
- status = "okay";
-};
-
&uart1 {
// Host Console
status = "okay";
@@ -196,6 +191,14 @@ &mac0 {
use-ncsi;
};
+&mac1 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii2_default>;
+ use-ncsi;
+};
+
&adc {
status = "okay";
};
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
index 322587b..39c6be9 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
@@ -2,36 +2,16 @@
// Copyright (c) 2018 Facebook Inc.
/dts-v1/;
-#include "aspeed-g4.dtsi"
+#include "ast2400-facebook-netbmc-common.dtsi"
/ {
model = "Facebook Wedge 100 BMC";
compatible = "facebook,wedge100-bmc", "aspeed,ast2400";
- aliases {
- /*
- * Override the default uart aliases to avoid breaking
- * the legacy applications.
- */
- serial0 = &uart5;
- serial1 = &uart1;
- serial2 = &uart3;
- serial3 = &uart4;
- };
-
chosen {
stdout-path = &uart3;
bootargs = "console=ttyS2,9600n8 root=/dev/ram rw";
};
-
- memory@40000000 {
- reg = <0x40000000 0x20000000>;
- };
-};
-
-&wdt1 {
- status = "okay";
- aspeed,reset-type = "system";
};
&wdt2 {
@@ -40,108 +20,38 @@ &wdt2 {
};
&fmc {
- status = "okay";
- flash@0 {
+ flash@1 {
status = "okay";
m25p,fast-read;
- label = "fmc0";
-#include "facebook-bmc-flash-layout.dtsi"
+ label = "spi0.1";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ flash1@0 {
+ reg = <0x0 0x2000000>;
+ label = "flash1";
+ };
+ };
};
};
-&uart1 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_txd1_default
- &pinctrl_rxd1_default>;
-};
-
-&uart3 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_txd3_default
- &pinctrl_rxd3_default>;
-};
-
-&uart4 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_txd4_default
- &pinctrl_rxd4_default>;
-};
-
-&uart5 {
- status = "okay";
-};
-
-&mac1 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
-};
-
-&i2c0 {
- status = "okay";
-};
-
-&i2c1 {
- status = "okay";
-};
-
-&i2c2 {
- status = "okay";
-};
-
-&i2c3 {
- status = "okay";
-};
-
-&i2c4 {
- status = "okay";
-};
-
-&i2c5 {
- status = "okay";
-};
-
-&i2c6 {
- status = "okay";
-};
-
&i2c7 {
- status = "okay";
-
i2c-switch@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+ i2c-mux-idle-disconnect;
};
};
-&i2c8 {
- status = "okay";
-};
-
&i2c9 {
status = "okay";
};
-&i2c10 {
- status = "okay";
-};
-
-&i2c11 {
- status = "okay";
-};
-
-&i2c12 {
- status = "okay";
-};
-
-&i2c13 {
- status = "okay";
-};
&vhub {
status = "okay";
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
index 8c426ba..2dcfeae 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
@@ -2,137 +2,27 @@
// Copyright (c) 2018 Facebook Inc.
/dts-v1/;
-#include "aspeed-g4.dtsi"
+#include "ast2400-facebook-netbmc-common.dtsi"
/ {
model = "Facebook Wedge 40 BMC";
compatible = "facebook,wedge40-bmc", "aspeed,ast2400";
- aliases {
- /*
- * Override the default uart aliases to avoid breaking
- * the legacy applications.
- */
- serial0 = &uart5;
- serial1 = &uart1;
- serial2 = &uart3;
- serial3 = &uart4;
- };
-
chosen {
stdout-path = &uart3;
bootargs = "console=ttyS2,9600n8 root=/dev/ram rw";
};
- memory@40000000 {
- reg = <0x40000000 0x20000000>;
- };
-
ast-adc-hwmon {
compatible = "iio-hwmon";
io-channels = <&adc 5>, <&adc 6>, <&adc 7>, <&adc 8>, <&adc 9>;
};
};
-&wdt1 {
- status = "okay";
- aspeed,reset-type = "system";
-};
-
&wdt2 {
status = "disabled";
};
-&fmc {
- status = "okay";
- flash@0 {
- status = "okay";
- m25p,fast-read;
- label = "spi0.0";
-#include "facebook-bmc-flash-layout.dtsi"
- };
-};
-
-&uart1 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_txd1_default
- &pinctrl_rxd1_default>;
-};
-
-&uart3 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_txd3_default
- &pinctrl_rxd3_default>;
-};
-
-&uart4 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_txd4_default
- &pinctrl_rxd4_default
- &pinctrl_ndts4_default>;
-};
-
-&uart5 {
- status = "okay";
-};
-
-&mac1 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
-};
-
-&i2c0 {
- status = "okay";
-};
-
-&i2c1 {
- status = "okay";
-};
-
-&i2c2 {
- status = "okay";
-};
-
-&i2c3 {
- status = "okay";
-};
-
-&i2c4 {
- status = "okay";
-};
-
-&i2c5 {
- status = "okay";
-};
-
-&i2c6 {
- status = "okay";
-};
-
-&i2c7 {
- status = "okay";
-};
-
-&i2c8 {
- status = "okay";
-};
-
-&i2c11 {
- status = "okay";
-};
-
-&i2c12 {
- status = "okay";
-};
-
-&vhub {
- status = "okay";
-};
-
&adc {
status = "okay";
};
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts
index ad1fcad..63a3dd5 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts
@@ -124,8 +124,8 @@ fit@80000 {
* "data0" partition (4MB) is reserved for persistent
* data store.
*/
- data0@3800000 {
- reg = <0x7c00000 0x800000>;
+ data0@7c00000 {
+ reg = <0x7c00000 0x400000>;
label = "data0";
};
diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier-4u.dts b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier-4u.dts
new file mode 100644
index 0000000..291f7d6
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier-4u.dts
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2020 IBM Corp.
+/dts-v1/;
+
+#include "aspeed-bmc-ibm-rainier.dts"
+
+/ {
+ model = "Rainier 4U";
+};
+
+&i2c3 {
+ power-supply@6a {
+ compatible = "ibm,cffps";
+ reg = <0x6a>;
+ };
+
+ power-supply@6b {
+ compatible = "ibm,cffps";
+ reg = <0x6b>;
+ };
+};
+
+&fan0 {
+ tach-pulses = <4>;
+};
+
+&fan1 {
+ tach-pulses = <4>;
+};
+
+&fan2 {
+ tach-pulses = <4>;
+};
+
+&fan3 {
+ tach-pulses = <4>;
+};
diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
index 21ae880..a4b77ae 100644
--- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
@@ -8,7 +8,7 @@
#include <dt-bindings/leds/leds-pca955x.h>
/ {
- model = "Rainier";
+ model = "Rainier 2U";
compatible = "ibm,rainier-bmc", "aspeed,ast2600";
aliases {
@@ -47,9 +47,18 @@ reserved-memory {
#size-cells = <1>;
ranges;
- flash_memory: region@B8000000 {
+ flash_memory: region@b8000000 {
no-map;
- reg = <0xB8000000 0x04000000>; /* 64M */
+ reg = <0xb8000000 0x04000000>; /* 64M */
+ };
+
+ ramoops@bc000000 {
+ compatible = "ramoops";
+ reg = <0xbc000000 0x180000>; /* 16 * (3 * 0x8000) */
+ record-size = <0x8000>;
+ console-size = <0x8000>;
+ pmsg-size = <0x8000>;
+ max-reason = <3>; /* KMSG_DUMP_EMERG */
};
vga_memory: region@bf000000 {
@@ -258,6 +267,7 @@ eeprom@0 {
cfam0_spi2: spi@40 {
reg = <0x40>;
+ compatible = "ibm,fsi2spi-restricted";
#address-cells = <1>;
#size-cells = <0>;
@@ -274,6 +284,7 @@ eeprom@0 {
cfam0_spi3: spi@60 {
reg = <0x60>;
+ compatible = "ibm,fsi2spi-restricted";
#address-cells = <1>;
#size-cells = <0>;
@@ -370,6 +381,7 @@ eeprom@0 {
cfam1_spi2: spi@40 {
reg = <0x40>;
+ compatible = "ibm,fsi2spi-restricted";
#address-cells = <1>;
#size-cells = <0>;
@@ -386,6 +398,7 @@ eeprom@0 {
cfam1_spi3: spi@60 {
reg = <0x60>;
+ compatible = "ibm,fsi2spi-restricted";
#address-cells = <1>;
#size-cells = <0>;
@@ -480,6 +493,7 @@ eeprom@0 {
cfam2_spi2: spi@40 {
reg = <0x40>;
+ compatible = "ibm,fsi2spi-restricted";
#address-cells = <1>;
#size-cells = <0>;
@@ -496,6 +510,7 @@ eeprom@0 {
cfam2_spi3: spi@60 {
reg = <0x60>;
+ compatible = "ibm,fsi2spi-restricted";
#address-cells = <1>;
#size-cells = <0>;
@@ -594,16 +609,6 @@ power-supply@69 {
compatible = "ibm,cffps";
reg = <0x69>;
};
-
- power-supply@6a {
- compatible = "ibm,cffps";
- reg = <0x6a>;
- };
-
- power-supply@6b {
- compatible = "ibm,cffps";
- reg = <0x6b>;
- };
};
&i2c4 {
@@ -723,25 +728,25 @@ max31785@52 {
#address-cells = <1>;
#size-cells = <0>;
- fan@0 {
+ fan0: fan@0 {
compatible = "pmbus-fan";
reg = <0>;
tach-pulses = <2>;
};
- fan@1 {
+ fan1: fan@1 {
compatible = "pmbus-fan";
reg = <1>;
tach-pulses = <2>;
};
- fan@2 {
+ fan2: fan@2 {
compatible = "pmbus-fan";
reg = <2>;
tach-pulses = <2>;
};
- fan@3 {
+ fan3: fan@3 {
compatible = "pmbus-fan";
reg = <3>;
tach-pulses = <2>;
diff --git a/arch/arm/boot/dts/aspeed-bmc-intel-s2600wf.dts b/arch/arm/boot/dts/aspeed-bmc-intel-s2600wf.dts
index 1deb30e..6e9baf3 100644
--- a/arch/arm/boot/dts/aspeed-bmc-intel-s2600wf.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-intel-s2600wf.dts
@@ -22,9 +22,9 @@ reserved-memory {
#size-cells = <1>;
ranges;
- vga_memory: framebuffer@7f000000 {
+ vga_memory: framebuffer@9f000000 {
no-map;
- reg = <0x7f000000 0x01000000>;
+ reg = <0x9f000000 0x01000000>; /* 16M */
};
};
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
index 4d070d6..c1478d2 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
@@ -26,11 +26,20 @@ reserved-memory {
#size-cells = <1>;
ranges;
- flash_memory: region@ba000000 {
+ flash_memory: region@b8000000 {
no-map;
reg = <0xb8000000 0x4000000>; /* 64M */
};
+ ramoops@bc000000 {
+ compatible = "ramoops";
+ reg = <0xbc000000 0x180000>; /* 16 * (3 * 0x8000) */
+ record-size = <0x8000>;
+ console-size = <0x8000>;
+ pmsg-size = <0x8000>;
+ max-reason = <3>; /* KMSG_DUMP_EMERG */
+ };
+
vga_memory: region@bf000000 {
no-map;
compatible = "shared-dma-pool";
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 82f0213..b3dafbc 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -192,6 +192,11 @@ p2a: p2a-control@2c {
status = "disabled";
};
+ silicon-id@7c {
+ compatible = "aspeed,ast2400-silicon-id", "aspeed,silicon-id";
+ reg = <0x7c 0x4>;
+ };
+
pinctrl: pinctrl@80 {
reg = <0x80 0x18>, <0xa0 0x10>;
compatible = "aspeed,ast2400-pinctrl";
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index a93009a..5bc0de0 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -239,6 +239,11 @@ p2a: p2a-control@2c {
status = "disabled";
};
+ silicon-id@7c {
+ compatible = "aspeed,ast2500-silicon-id", "aspeed,silicon-id";
+ reg = <0x7c 0x4 0x150 0x8>;
+ };
+
pinctrl: pinctrl@80 {
compatible = "aspeed,ast2500-pinctrl";
reg = <0x80 0x18>, <0xa0 0x10>;
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index b58220a..810b067 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -69,6 +69,12 @@ timer {
always-on;
};
+ edac: sdram@1e6e0000 {
+ compatible = "aspeed,ast2600-sdram-edac", "syscon";
+ reg = <0x1e6e0000 0x174>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -311,6 +317,11 @@ pinctrl: pinctrl {
compatible = "aspeed,ast2600-pinctrl";
};
+ silicon-id@14 {
+ compatible = "aspeed,ast2600-silicon-id", "aspeed,silicon-id";
+ reg = <0x14 0x4 0x5b0 0x8>;
+ };
+
smp-memram@180 {
compatible = "aspeed,ast2600-smpmem";
reg = <0x180 0x40>;
@@ -357,7 +368,7 @@ gpio0: gpio@1e780000 {
#gpio-cells = <2>;
gpio-controller;
compatible = "aspeed,ast2600-gpio";
- reg = <0x1e780000 0x800>;
+ reg = <0x1e780000 0x400>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
gpio-ranges = <&pinctrl 0 0 208>;
ngpios = <208>;
diff --git a/arch/arm/boot/dts/ast2400-facebook-netbmc-common.dtsi b/arch/arm/boot/dts/ast2400-facebook-netbmc-common.dtsi
new file mode 100644
index 0000000..73a5503
--- /dev/null
+++ b/arch/arm/boot/dts/ast2400-facebook-netbmc-common.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2020 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g4.dtsi"
+
+/ {
+ aliases {
+ /*
+ * Override the default uart aliases to avoid breaking
+ * the legacy applications.
+ */
+ serial0 = &uart5;
+ serial1 = &uart1;
+ serial2 = &uart3;
+ serial3 = &uart4;
+ };
+
+ memory@40000000 {
+ reg = <0x40000000 0x20000000>;
+ };
+};
+
+&wdt1 {
+ status = "okay";
+ aspeed,reset-type = "system";
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "spi0.0";
+#include "facebook-bmc-flash-layout.dtsi"
+ };
+};
+
+&uart1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd1_default
+ &pinctrl_rxd1_default>;
+};
+
+&uart3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd3_default
+ &pinctrl_rxd3_default>;
+};
+
+&uart4 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd4_default
+ &pinctrl_rxd4_default
+ &pinctrl_ndts4_default>;
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&mac1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+};
+
+&i2c6 {
+ status = "okay";
+};
+
+&i2c7 {
+ status = "okay";
+};
+
+&i2c8 {
+ status = "okay";
+};
+
+&i2c11 {
+ status = "okay";
+};
+
+&i2c12 {
+ status = "okay";
+};
+
+&vhub {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/at91-kizbox.dts b/arch/arm/boot/dts/at91-kizbox.dts
index 7add151..3b8812f 100644
--- a/arch/arm/boot/dts/at91-kizbox.dts
+++ b/arch/arm/boot/dts/at91-kizbox.dts
@@ -48,48 +48,37 @@ user {
};
};
- pwm_leds {
+ led-controller {
compatible = "pwm-leds";
- network_green {
+ led-1 {
label = "pwm:green:network";
- pwms = <&tcb_pwm 2 10000000 PWM_POLARITY_INVERTED>;
+ pwms = <&tcb1_pwm1 0 10000000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "default-on";
};
- network_red {
+ led-2 {
label = "pwm:red:network";
- pwms = <&tcb_pwm 4 10000000 PWM_POLARITY_INVERTED>;
+ pwms = <&tcb1_pwm2 0 10000000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "default-on";
};
- user_green {
+ led-3 {
label = "pwm:green:user";
- pwms = <&tcb_pwm 0 10000000 PWM_POLARITY_INVERTED>;
+ pwms = <&tcb1_pwm0 0 10000000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "default-on";
};
- user_red {
+ led-4 {
label = "pwm:red:user";
- pwms = <&tcb_pwm 1 10000000 PWM_POLARITY_INVERTED>;
+ pwms = <&tcb1_pwm0 1 10000000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "default-on";
};
};
-
- tcb_pwm: pwm {
- compatible = "atmel,tcb-pwm";
- #pwm-cells = <3>;
- tc-block = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_tcb1_tioa0
- &pinctrl_tcb1_tioa1
- &pinctrl_tcb1_tioa2
- &pinctrl_tcb1_tiob0>;
- };
};
&tcb0 {
@@ -104,6 +93,32 @@ timer@2 {
};
};
+&tcb1 {
+ tcb1_pwm0: pwm@0 {
+ compatible = "atmel,tcb-pwm";
+ reg = <0>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tcb1_tioa0 &pinctrl_tcb1_tiob0>;
+ };
+
+ tcb1_pwm1: pwm@1 {
+ compatible = "atmel,tcb-pwm";
+ reg = <1>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tcb1_tioa1>;
+ };
+
+ tcb1_pwm2: pwm@2 {
+ compatible = "atmel,tcb-pwm";
+ reg = <2>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tcb1_tioa2>;
+ };
+};
+
&ebi {
status = "okay";
};
diff --git a/arch/arm/boot/dts/at91-kizbox2-common.dtsi b/arch/arm/boot/dts/at91-kizbox2-common.dtsi
index 25f7610..c08834dd 100644
--- a/arch/arm/boot/dts/at91-kizbox2-common.dtsi
+++ b/arch/arm/boot/dts/at91-kizbox2-common.dtsi
@@ -58,24 +58,24 @@ user {
};
};
- pwm_leds {
+ led-controller {
compatible = "pwm-leds";
- blue {
+ led-1 {
label = "pwm:blue:user";
pwms = <&pwm0 2 10000000 0>;
max-brightness = <255>;
linux,default-trigger = "none";
};
- green {
+ led-2 {
label = "pwm:green:user";
pwms = <&pwm0 1 10000000 0>;
max-brightness = <255>;
linux,default-trigger = "default-on";
};
- red {
+ led-3 {
label = "pwm:red:user";
pwms = <&pwm0 0 10000000 0>;
max-brightness = <255>;
diff --git a/arch/arm/boot/dts/at91-kizbox3-hs.dts b/arch/arm/boot/dts/at91-kizbox3-hs.dts
index 0da1f05..2799b2a 100644
--- a/arch/arm/boot/dts/at91-kizbox3-hs.dts
+++ b/arch/arm/boot/dts/at91-kizbox3-hs.dts
@@ -15,40 +15,40 @@ / {
model = "Overkiz KIZBOX3-HS";
compatible = "overkiz,kizbox3-hs", "atmel,sama5d2", "atmel,sama5";
- pwm_leds {
+ led-controller-1 {
status = "okay";
- red {
+ led-1 {
status = "okay";
};
- green {
+ led-2 {
status = "okay";
};
- blue {
+ led-3 {
status = "okay";
};
- white {
+ led-4 {
status = "okay";
};
};
- leds {
+ led-controller-2 {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_led_red
&pinctrl_led_white>;
status = "okay";
- red {
+ led-5 {
label = "pio:red:user";
gpios = <&pioA PIN_PB1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- white {
+ led-6 {
label = "pio:white:user";
gpios = <&pioA PIN_PB8 GPIO_ACTIVE_HIGH>;
default-state = "off";
diff --git a/arch/arm/boot/dts/at91-kizbox3_common.dtsi b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
index 7c3076e..9ce513d 100644
--- a/arch/arm/boot/dts/at91-kizbox3_common.dtsi
+++ b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
@@ -62,7 +62,7 @@ vdd_adc_vref: supply_3v3_ref {
regulator-always-on;
};
- pwm_leds {
+ led-controller-1 {
compatible = "pwm-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0_pwm_h0
@@ -71,7 +71,7 @@ &pinctrl_pwm0_pwm_h2
&pinctrl_pwm0_pwm_h3>;
status = "disabled";
- red {
+ led-1 {
label = "pwm:red:user";
pwms = <&pwm0 0 10000000 0>;
max-brightness = <255>;
@@ -79,7 +79,7 @@ red {
status = "disabled";
};
- green {
+ led-2 {
label = "pwm:green:user";
pwms = <&pwm0 1 10000000 0>;
max-brightness = <255>;
@@ -87,14 +87,14 @@ green {
status = "disabled";
};
- blue {
+ led-3 {
label = "pwm:blue:user";
pwms = <&pwm0 2 10000000 0>;
max-brightness = <255>;
status = "disabled";
};
- white {
+ led-4 {
label = "pwm:white:user";
pwms = <&pwm0 3 10000000 0>;
max-brightness = <255>;
diff --git a/arch/arm/boot/dts/at91-kizboxmini-common.dtsi b/arch/arm/boot/dts/at91-kizboxmini-common.dtsi
index d37724c..9c62289 100644
--- a/arch/arm/boot/dts/at91-kizboxmini-common.dtsi
+++ b/arch/arm/boot/dts/at91-kizboxmini-common.dtsi
@@ -54,10 +54,10 @@ reset {
};
};
- leds: pwm_leds {
+ leds: led-controller-1 {
compatible = "pwm-leds";
- led_blue: pwm_blue {
+ led_blue: led-1 {
label = "pwm:blue:user";
pwms = <&pwm0 2 10000000 0>;
max-brightness = <255>;
@@ -65,14 +65,14 @@ led_blue: pwm_blue {
status = "disabled";
};
- led_green: pwm_green {
+ led_green: led-2 {
label = "pwm:green:user";
pwms = <&pwm0 0 10000000 0>;
max-brightness = <255>;
linux,default-trigger = "default-on";
};
- led_red: pwm_red {
+ led_red: led-3 {
label = "pwm:red:user";
pwms = <&pwm0 1 10000000 0>;
max-brightness = <255>;
diff --git a/arch/arm/boot/dts/at91-sam9x60ek.dts b/arch/arm/boot/dts/at91-sam9x60ek.dts
index eae28b8..73b6b1f 100644
--- a/arch/arm/boot/dts/at91-sam9x60ek.dts
+++ b/arch/arm/boot/dts/at91-sam9x60ek.dts
@@ -569,11 +569,14 @@ pinctrl_usba_vbus: usba_vbus {
atmel,pins = <AT91_PIOB 16 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
};
};
-}; /* pinctrl */
-&pmc {
- atmel,osc-bypass;
-};
+ usb1 {
+ pinctrl_usb_default: usb_default {
+ atmel,pins = <AT91_PIOD 15 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
+ AT91_PIOD 16 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+ };
+}; /* pinctrl */
&pwm0 {
pinctrl-names = "default";
@@ -684,6 +687,8 @@ &usb1 {
atmel,vbus-gpio = <0
&pioD 15 GPIO_ACTIVE_HIGH
&pioD 16 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_default>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
index b1f994c..1b11638 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
@@ -100,7 +100,7 @@ i2c0: i2c@f8028000 {
status = "okay";
at24@50 {
- compatible = "24c02";
+ compatible = "atmel,24c02";
reg = <0x50>;
pagesize = <8>;
};
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index cf13632..5179258 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -242,6 +242,11 @@ pinctrl_usba_vbus: usba_vbus {
atmel,pins =
<AT91_PIOE 9 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PE9, conflicts with A9 */
};
+ pinctrl_usb_default: usb_default {
+ atmel,pins =
+ <AT91_PIOE 3 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
+ AT91_PIOE 4 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
};
};
};
@@ -259,6 +264,8 @@ usb1: ohci@600000 {
&pioE 3 GPIO_ACTIVE_LOW
&pioE 4 GPIO_ACTIVE_LOW
>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_default>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index e5974a1..0b3ad1b 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -134,6 +134,11 @@ pinctrl_usba_vbus: usba_vbus {
atmel,pins =
<AT91_PIOE 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
};
+ pinctrl_usb_default: usb_default {
+ atmel,pins =
+ <AT91_PIOE 11 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
+ AT91_PIOE 14 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
pinctrl_key_gpio: key_gpio_0 {
atmel,pins =
<AT91_PIOE 8 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
@@ -159,6 +164,8 @@ usb1: ohci@500000 {
&pioE 11 GPIO_ACTIVE_HIGH
&pioE 14 GPIO_ACTIVE_HIGH
>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_default>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/at91-smartkiz.dts b/arch/arm/boot/dts/at91-smartkiz.dts
index 106f23b..b76a6b5 100644
--- a/arch/arm/boot/dts/at91-smartkiz.dts
+++ b/arch/arm/boot/dts/at91-smartkiz.dts
@@ -84,10 +84,8 @@ &rtc {
status = "okay";
};
-&leds {
- blue {
- status = "okay";
- };
+&led_blue {
+ status = "okay";
};
&adc0 {
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 82c5d7fd..019f1c3 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -697,8 +697,6 @@ spi1: spi@fffcc000 {
};
adc0: adc@fffe0000 {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "atmel,at91sam9260-adc";
reg = <0xfffe0000 0x100>;
interrupts = <5 IRQ_TYPE_LEVEL_HIGH 0>;
@@ -708,29 +706,6 @@ adc0: adc@fffe0000 {
atmel,adc-channels-used = <0xf>;
atmel,adc-vref = <3300>;
atmel,adc-startup-time = <15>;
- atmel,adc-res = <8 10>;
- atmel,adc-res-names = "lowres", "highres";
- atmel,adc-use-res = "highres";
-
- trigger0 {
- trigger-name = "timer-counter-0";
- trigger-value = <0x1>;
- };
- trigger1 {
- trigger-name = "timer-counter-1";
- trigger-value = <0x3>;
- };
-
- trigger2 {
- trigger-name = "timer-counter-2";
- trigger-value = <0x5>;
- };
-
- trigger3 {
- trigger-name = "external";
- trigger-value = <0xd>;
- trigger-external;
- };
};
rtc@fffffd20 {
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 19fc748..2ab730f 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -812,8 +812,6 @@ ac97: sound@fffac000 {
};
adc0: adc@fffb0000 {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "atmel,at91sam9g45-adc";
reg = <0xfffb0000 0x100>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
@@ -822,31 +820,6 @@ adc0: adc@fffb0000 {
atmel,adc-channels-used = <0xff>;
atmel,adc-vref = <3300>;
atmel,adc-startup-time = <40>;
- atmel,adc-res = <8 10>;
- atmel,adc-res-names = "lowres", "highres";
- atmel,adc-use-res = "highres";
-
- 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>;
- };
};
isi@fffb4000 {
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 9734667..b6256a2 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -315,27 +315,27 @@ usb1: ehci@800000 {
};
};
- leds {
+ led-controller-1 {
compatible = "gpio-leds";
- d8 {
+ led-1 {
label = "d8";
gpios = <&pioD 30 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
};
- pwmleds {
+ led-controller-2 {
compatible = "pwm-leds";
- d6 {
+ led-2 {
label = "d6";
pwms = <&pwm0 3 5000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
linux,default-trigger = "nand-disk";
};
- d7 {
+ led-3 {
label = "d7";
pwms = <&pwm0 1 5000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
diff --git a/arch/arm/boot/dts/at91sam9rl.dtsi b/arch/arm/boot/dts/at91sam9rl.dtsi
index 5653e70c..730d118 100644
--- a/arch/arm/boot/dts/at91sam9rl.dtsi
+++ b/arch/arm/boot/dts/at91sam9rl.dtsi
@@ -266,8 +266,6 @@ spi0: spi@fffcc000 {
};
adc0: adc@fffd0000 {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "atmel,at91sam9rl-adc";
reg = <0xfffd0000 0x100>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
@@ -277,29 +275,6 @@ adc0: adc@fffd0000 {
atmel,adc-channels-used = <0x3f>;
atmel,adc-vref = <3300>;
atmel,adc-startup-time = <40>;
- atmel,adc-res = <8 10>;
- atmel,adc-res-names = "lowres", "highres";
- atmel,adc-use-res = "highres";
-
- trigger0 {
- trigger-name = "timer-counter-0";
- trigger-value = <0x1>;
- };
- trigger1 {
- trigger-name = "timer-counter-1";
- trigger-value = <0x3>;
- };
-
- trigger2 {
- trigger-name = "timer-counter-2";
- trigger-value = <0x5>;
- };
-
- trigger3 {
- trigger-name = "external";
- trigger-value = <0x13>;
- trigger-external;
- };
};
usb0: gadget@fffd4000 {
diff --git a/arch/arm/boot/dts/at91sam9rlek.dts b/arch/arm/boot/dts/at91sam9rlek.dts
index 1590862..62981b3 100644
--- a/arch/arm/boot/dts/at91sam9rlek.dts
+++ b/arch/arm/boot/dts/at91sam9rlek.dts
@@ -218,26 +218,26 @@ rtc@fffffe00 {
};
};
- pwmleds {
+ led-controller-1 {
compatible = "pwm-leds";
- ds1 {
+ led-1 {
label = "ds1";
pwms = <&pwm0 1 5000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
};
- ds2 {
+ led-2 {
label = "ds2";
pwms = <&pwm0 2 5000 PWM_POLARITY_INVERTED>;
max-brightness = <255>;
};
};
- leds {
+ led-controller-2 {
compatible = "gpio-leds";
- ds3 {
+ led-3 {
label = "ds3";
gpios = <&pioD 14 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 4cdb050..395e883 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -795,8 +795,6 @@ uart1: serial@f8044000 {
};
adc0: adc@f804c000 {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "atmel,at91sam9x5-adc";
reg = <0xf804c000 0x100>;
interrupts = <19 IRQ_TYPE_LEVEL_HIGH 0>;
@@ -808,32 +806,6 @@ adc0: adc@f804c000 {
atmel,adc-vref = <3300>;
atmel,adc-startup-time = <40>;
atmel,adc-sample-hold-time = <11>;
- atmel,adc-res = <8 10>;
- atmel,adc-res-names = "lowres", "highres";
- atmel,adc-use-res = "highres";
-
- 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>;
- };
};
spi0: spi@f0000000 {
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index dacaef2..0025c88 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -591,7 +591,6 @@ touchscreen: touchscreen@180a6000 {
adc: adc@180a6000 {
compatible = "brcm,iproc-static-adc";
#io-channel-cells = <1>;
- io-channel-ranges;
adc-syscon = <&ts_adc_syscon>;
clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
clock-names = "tsc_clk";
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index e895f7c..b4d2cc7 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -385,12 +385,12 @@ ccbtimer1: timer@35000 {
clock-names = "apb_pclk";
};
- srab: srab@36000 {
+ srab: ethernet-switch@36000 {
compatible = "brcm,nsp-srab";
reg = <0x36000 0x1000>,
<0x3f308 0x8>,
<0x3f410 0xc>;
- reg-names = "srab", "mux_config", "sgmii";
+ reg-names = "srab", "mux_config", "sgmii_config";
interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
@@ -420,6 +420,10 @@ srab: srab@36000 {
status = "disabled";
/* ports are defined in board DTS */
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
i2c0: i2c@38000 {
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182..403bacf 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -181,12 +181,14 @@ &gpio {
&hdmi0 {
clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 0>, <&clk_27MHz>;
clock-names = "hdmi", "bvb", "audio", "cec";
+ wifi-2.4ghz-coexistence;
status = "okay";
};
&hdmi1 {
clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>, <&clk_27MHz>;
clock-names = "hdmi", "bvb", "audio", "cec";
+ wifi-2.4ghz-coexistence;
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi b/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi
index e2fd961..20322de 100644
--- a/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi
+++ b/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
&usb {
dr_mode = "otg";
- g-rx-fifo-size = <256>;
+ g-rx-fifo-size = <558>;
g-np-tx-fifo-size = <32>;
/*
* According to dwc2 the sum of all device EP
diff --git a/arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi b/arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi
index 0ff0e9e..1409d1b 100644
--- a/arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi
+++ b/arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
&usb {
dr_mode = "peripheral";
- g-rx-fifo-size = <256>;
+ g-rx-fifo-size = <558>;
g-np-tx-fifo-size = <32>;
g-tx-fifo-size = <256 256 512 512 512 768 768>;
};
diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
index 810fc32..5b4a481 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
@@ -57,17 +57,10 @@ &spi_nor {
status = "okay";
};
-&usb3_phy {
- status = "okay";
-};
-
&srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "poe";
diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
index 7604b44..8636600 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
@@ -64,17 +64,10 @@ &spi_nor {
status = "okay";
};
-&usb3_phy {
- status = "okay";
-};
-
&srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@4 {
reg = <4>;
label = "lan";
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index abd35a51..51c64f0 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -122,9 +122,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "lan4";
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index 4dcec68..2f2d2b0 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -117,7 +117,3 @@ eject {
};
};
};
-
-&usb3_phy {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts b/arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts
index 1ec6558..68aaf0a 100644
--- a/arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts
+++ b/arch/arm/boot/dts/bcm47081-luxul-xap-1410.dts
@@ -57,17 +57,10 @@ &spi_nor {
status = "okay";
};
-&usb3_phy {
- status = "okay";
-};
-
&srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@4 {
reg = <4>;
label = "poe";
diff --git a/arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts b/arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts
index 04bfd58..4322543 100644
--- a/arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts
+++ b/arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts
@@ -105,17 +105,10 @@ &spi_nor {
status = "okay";
};
-&usb3_phy {
- status = "okay";
-};
-
&srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "lan4";
diff --git a/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts b/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
index 01c390e..12e34a0 100644
--- a/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
+++ b/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
@@ -126,7 +126,3 @@ nvram@ff0000 {
&usb2 {
vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
};
-
-&usb3_phy {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
index e1bb866..cba3d91 100644
--- a/arch/arm/boot/dts/bcm4709.dtsi
+++ b/arch/arm/boot/dts/bcm4709.dtsi
@@ -9,3 +9,7 @@ &uart0 {
clock-frequency = <125000000>;
status = "okay";
};
+
+&srab {
+ compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
+};
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 0faae89..3725f2b 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -123,33 +123,13 @@ bluebar8 {
};
};
- mdio-bus-mux {
- #address-cells = <1>;
- #size-cells = <0>;
+ mdio-bus-mux@18003000 {
/* BIT(9) = 1 => external mdio */
- mdio_ext: mdio@200 {
+ mdio@200 {
reg = <0x200>;
#address-cells = <1>;
#size-cells = <0>;
- };
- };
-
- mdio-mii-mux {
- compatible = "mdio-mux-mmioreg";
- mdio-parent-bus = <&mdio_ext>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x1800c1c0 0x4>;
-
- /* BIT(6) = mdc, BIT(7) = mdio */
- mux-mask = <0xc0>;
-
- mdio-mii@0 {
- /* Enable MII function */
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
switch@0 {
compatible = "brcm,bcm53125";
@@ -159,6 +139,8 @@ switch@0 {
reset-names = "robo_reset";
reg = <0>;
dsa,member = <1 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinmux_mdio>;
ports {
#address-cells = <1>;
@@ -219,9 +201,6 @@ &srab {
dsa,member = <0 0>;
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@1 {
reg = <1>;
label = "lan7";
@@ -242,6 +221,30 @@ port@4 {
label = "wan";
};
+ port@5 {
+ reg = <5>;
+ ethernet = <&gmac0>;
+ label = "cpu";
+ status = "disabled";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@7 {
+ reg = <7>;
+ ethernet = <&gmac1>;
+ label = "cpu";
+ status = "disabled";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
port@8 {
reg = <8>;
ethernet = <&gmac2>;
@@ -268,3 +271,44 @@ fixed-link {
&usb3_phy {
status = "okay";
};
+
+&nandcs {
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "boot";
+ reg = <0x0000000 0x0080000>;
+ read-only;
+ };
+
+ partition@80000 {
+ label = "nvram";
+ reg = <0x080000 0x0100000>;
+ };
+
+ partition@180000{
+ label = "devinfo";
+ reg = <0x0180000 0x080000>;
+ };
+
+ partition@200000 {
+ label = "firmware";
+ reg = <0x0200000 0x01D00000>;
+ compatible = "brcm,trx";
+ };
+
+ partition@1F00000 {
+ label = "failsafe";
+ reg = <0x01F00000 0x01D00000>;
+ read-only;
+ };
+
+ partition@5200000 {
+ label = "system";
+ reg = <0x05200000 0x02E00000>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xap-1610.dts b/arch/arm/boot/dts/bcm47094-luxul-xap-1610.dts
index 068e384..6fa101f 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xap-1610.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xap-1610.dts
@@ -59,9 +59,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "poe";
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dts b/arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dts
index 9ae815d..4f8d777 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dts
@@ -57,9 +57,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "lan";
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index a21b2d1..e17e9a1 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -108,9 +108,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "lan4";
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts
index 4d5c5aa..60cc87e 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts
@@ -71,6 +71,10 @@ &usb3 {
vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
};
+&usb3_phy {
+ status = "okay";
+};
+
&spi_nor {
status = "okay";
};
@@ -79,9 +83,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "lan4";
diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
index cdc5ff5..2a8f731 100644
--- a/arch/arm/boot/dts/bcm47094.dtsi
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -8,6 +8,15 @@
/ {
};
+&pinctrl {
+ compatible = "brcm,bcm4709-pinmux";
+
+ pinmux_mdio: mdio {
+ groups = "mdio_grp";
+ function = "mdio";
+ };
+};
+
&usb3_phy {
compatible = "brcm,ns-bx-usb3-phy";
};
@@ -16,3 +25,7 @@ &uart0 {
clock-frequency = <125000000>;
status = "okay";
};
+
+&srab {
+ compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
+};
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index ac3a99c..7db72a2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -265,7 +265,7 @@ usb2: usb2@21000 {
interrupt-parent = <&gic>;
- ehci: ehci@21000 {
+ ehci: usb@21000 {
#usb-cells = <0>;
compatible = "generic-ehci";
@@ -287,7 +287,7 @@ ehci_port2: port@2 {
};
};
- ohci: ohci@22000 {
+ ohci: usb@22000 {
#usb-cells = <0>;
compatible = "generic-ohci";
@@ -318,7 +318,7 @@ usb3: usb3@23000 {
interrupt-parent = <&gic>;
- xhci: xhci@23000 {
+ xhci: usb@23000 {
#usb-cells = <0>;
compatible = "generic-xhci";
@@ -428,7 +428,27 @@ cru@100 {
#address-cells = <1>;
#size-cells = <1>;
- pin-controller@1c0 {
+ lcpll0: lcpll0@100 {
+ #clock-cells = <1>;
+ compatible = "brcm,nsp-lcpll0";
+ reg = <0x100 0x14>;
+ clocks = <&osc>;
+ clock-output-names = "lcpll0", "pcie_phy",
+ "sdio", "ddr_phy";
+ };
+
+ genpll: genpll@140 {
+ #clock-cells = <1>;
+ compatible = "brcm,nsp-genpll";
+ reg = <0x140 0x24>;
+ clocks = <&osc>;
+ clock-output-names = "genpll", "phy",
+ "ethernetclk",
+ "usbclk", "iprocfast",
+ "sata1", "sata2";
+ };
+
+ pinctrl: pin-controller@1c0 {
compatible = "brcm,bcm4708-pinmux";
reg = <0x1c0 0x24>;
reg-names = "cru_gpio_control";
@@ -454,41 +474,26 @@ pinmux_uart1: uart1 {
function = "uart1";
};
};
+
+ thermal: thermal@2c0 {
+ compatible = "brcm,ns-thermal";
+ reg = <0x2c0 0x10>;
+ #thermal-sensor-cells = <0>;
+ };
};
};
- lcpll0: lcpll0@1800c100 {
- #clock-cells = <1>;
- compatible = "brcm,nsp-lcpll0";
- reg = <0x1800c100 0x14>;
- clocks = <&osc>;
- clock-output-names = "lcpll0", "pcie_phy", "sdio",
- "ddr_phy";
- };
-
- genpll: genpll@1800c140 {
- #clock-cells = <1>;
- compatible = "brcm,nsp-genpll";
- reg = <0x1800c140 0x24>;
- clocks = <&osc>;
- clock-output-names = "genpll", "phy", "ethernetclk",
- "usbclk", "iprocfast", "sata1",
- "sata2";
- };
-
- thermal: thermal@1800c2c0 {
- compatible = "brcm,ns-thermal";
- reg = <0x1800c2c0 0x10>;
- #thermal-sensor-cells = <0>;
- };
-
- srab: srab@18007000 {
- compatible = "brcm,bcm5301x-srab";
+ srab: ethernet-switch@18007000 {
+ compatible = "brcm,bcm53011-srab", "brcm,bcm5301x-srab";
reg = <0x18007000 0x1000>;
status = "disabled";
/* ports are defined in board DTS */
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
rng: rng@18004000 {
diff --git a/arch/arm/boot/dts/bcm53573.dtsi b/arch/arm/boot/dts/bcm53573.dtsi
index 4af8e32..51546fc 100644
--- a/arch/arm/boot/dts/bcm53573.dtsi
+++ b/arch/arm/boot/dts/bcm53573.dtsi
@@ -135,7 +135,7 @@ usb2: usb2@4000 {
#address-cells = <1>;
#size-cells = <1>;
- ehci: ehci@4000 {
+ ehci: usb@4000 {
compatible = "generic-ehci";
reg = <0x4000 0x1000>;
interrupt-parent = <&gic>;
@@ -155,7 +155,7 @@ ehci_port2: port@2 {
};
};
- ohci: ohci@d000 {
+ ohci: usb@d000 {
#usb-cells = <0>;
compatible = "generic-ohci";
diff --git a/arch/arm/boot/dts/bcm953012er.dts b/arch/arm/boot/dts/bcm953012er.dts
index 9574682..52feca0 100644
--- a/arch/arm/boot/dts/bcm953012er.dts
+++ b/arch/arm/boot/dts/bcm953012er.dts
@@ -69,9 +69,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
reg = <0>;
label = "port0";
diff --git a/arch/arm/boot/dts/bcm958522er.dts b/arch/arm/boot/dts/bcm958522er.dts
index 7be4c4e..5443fc0 100644
--- a/arch/arm/boot/dts/bcm958522er.dts
+++ b/arch/arm/boot/dts/bcm958522er.dts
@@ -178,3 +178,7 @@ &usb3_phy {
&xhci {
status = "okay";
};
+
+&srab {
+ compatible = "brcm,bcm58522-srab", "brcm,nsp-srab";
+};
diff --git a/arch/arm/boot/dts/bcm958525er.dts b/arch/arm/boot/dts/bcm958525er.dts
index e58ed7e..e1e3c26 100644
--- a/arch/arm/boot/dts/bcm958525er.dts
+++ b/arch/arm/boot/dts/bcm958525er.dts
@@ -190,3 +190,7 @@ &usb3_phy {
&xhci {
status = "okay";
};
+
+&srab {
+ compatible = "brcm,bcm58525-srab", "brcm,nsp-srab";
+};
diff --git a/arch/arm/boot/dts/bcm958525xmc.dts b/arch/arm/boot/dts/bcm958525xmc.dts
index 21f922d..f161ba2 100644
--- a/arch/arm/boot/dts/bcm958525xmc.dts
+++ b/arch/arm/boot/dts/bcm958525xmc.dts
@@ -210,3 +210,7 @@ &usb3_phy {
&xhci {
status = "okay";
};
+
+&srab {
+ compatible = "brcm,bcm58525-srab", "brcm,nsp-srab";
+};
diff --git a/arch/arm/boot/dts/bcm958622hr.dts b/arch/arm/boot/dts/bcm958622hr.dts
index a49c2fd..83cb877d 100644
--- a/arch/arm/boot/dts/bcm958622hr.dts
+++ b/arch/arm/boot/dts/bcm958622hr.dts
@@ -176,9 +176,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
label = "port0";
reg = <0>;
diff --git a/arch/arm/boot/dts/bcm958623hr.dts b/arch/arm/boot/dts/bcm958623hr.dts
index dd6dff6..4e106ce 100644
--- a/arch/arm/boot/dts/bcm958623hr.dts
+++ b/arch/arm/boot/dts/bcm958623hr.dts
@@ -180,9 +180,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
label = "port0";
reg = <0>;
diff --git a/arch/arm/boot/dts/bcm958625hr.dts b/arch/arm/boot/dts/bcm958625hr.dts
index a71371b..cda6cc2 100644
--- a/arch/arm/boot/dts/bcm958625hr.dts
+++ b/arch/arm/boot/dts/bcm958625hr.dts
@@ -195,9 +195,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
label = "port0";
reg = <0>;
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index 7782b61..ffbff00 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -216,9 +216,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
label = "port0";
reg = <0>;
diff --git a/arch/arm/boot/dts/bcm988312hr.dts b/arch/arm/boot/dts/bcm988312hr.dts
index edd0f63..3fd39c4 100644
--- a/arch/arm/boot/dts/bcm988312hr.dts
+++ b/arch/arm/boot/dts/bcm988312hr.dts
@@ -184,9 +184,6 @@ &srab {
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
port@0 {
label = "port0";
reg = <0>;
diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
index 2bb85a9..df021f9 100644
--- a/arch/arm/boot/dts/dove-sbc-a510.dts
+++ b/arch/arm/boot/dts/dove-sbc-a510.dts
@@ -143,6 +143,7 @@ &i2c1 {
gpio_ext: gpio@20 {
compatible = "nxp,pca9555";
reg = <0x20>;
+ gpio-controller;
#gpio-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 4e1bbc0..ce11947 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -724,22 +724,40 @@ sata: sata@4a141100 {
/* OCP2SCP1 */
/* IRQ for DWC3_3 and DWC3_4 need IRQ crossbar */
- gpmc: gpmc@50000000 {
- compatible = "ti,am3352-gpmc";
- ti,hwmods = "gpmc";
- reg = <0x50000000 0x37c>; /* device IO registers */
- interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&edma_xbar 4 0>;
- dma-names = "rxtx";
- gpmc,num-cs = <8>;
- gpmc,num-waitpins = <2>;
- #address-cells = <2>;
+
+ target-module@50000000 {
+ compatible = "ti,sysc-omap2", "ti,sysc";
+ reg = <0x50000000 4>,
+ <0x50000010 4>,
+ <0x50000014 4>;
+ reg-names = "rev", "sysc", "syss";
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,syss-mask = <1>;
+ clocks = <&l3main1_clkctrl DRA7_L3MAIN1_GPMC_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
#size-cells = <1>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- status = "disabled";
+ ranges = <0x50000000 0x50000000 0x00001000>, /* regs */
+ <0x00000000 0x00000000 0x40000000>; /* data */
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ reg = <0x50000000 0x37c>; /* device IO registers */
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&edma_xbar 4 0>;
+ dma-names = "rxtx";
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ status = "disabled";
+ };
};
target-module@56000000 {
@@ -932,7 +950,7 @@ aes2: aes@0 {
};
};
- sham_target: target-module@4b101000 {
+ sham1_target: target-module@4b101000 {
compatible = "ti,sysc-omap3-sham", "ti,sysc";
reg = <0x4b101100 0x4>,
<0x4b101110 0x4>,
@@ -951,7 +969,7 @@ sham_target: target-module@4b101000 {
#size-cells = <1>;
ranges = <0x0 0x4b101000 0x1000>;
- sham: sham@0 {
+ sham1: sham@0 {
compatible = "ti,omap5-sham";
reg = <0 0x300>;
interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
@@ -962,6 +980,62 @@ sham: sham@0 {
};
};
+ sham2_target: target-module@42701000 {
+ compatible = "ti,sysc-omap3-sham", "ti,sysc";
+ reg = <0x42701100 0x4>,
+ <0x42701110 0x4>,
+ <0x42701114 0x4>;
+ reg-names = "rev", "sysc", "syss";
+ ti,sysc-mask = <(SYSC_OMAP2_SOFTRESET |
+ SYSC_OMAP2_AUTOIDLE)>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,syss-mask = <1>;
+ /* Domains (P, C): l4per_pwrdm, l4sec_clkdm */
+ clocks = <&l4sec_clkctrl DRA7_L4SEC_SHAM2_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x42701000 0x1000>;
+
+ sham2: sham@0 {
+ compatible = "ti,omap5-sham";
+ reg = <0 0x300>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&edma_xbar 165 0>;
+ dma-names = "rx";
+ clocks = <&l3_iclk_div>;
+ clock-names = "fck";
+ };
+ };
+
+ iva_hd_target: target-module@5a000000 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x5a05a400 0x4>,
+ <0x5a05a410 0x4>;
+ reg-names = "rev", "sysc";
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ power-domains = <&prm_iva>;
+ resets = <&prm_iva 2>;
+ reset-names = "rstctrl";
+ clocks = <&iva_clkctrl DRA7_IVA_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x5a000000 0x5a000000 0x1000000>,
+ <0x5b000000 0x5b000000 0x1000000>;
+
+ iva {
+ compatible = "ti,ivahd";
+ };
+ };
+
opp_supply_mpu: opp-supply@4a003b20 {
compatible = "ti,omap5-opp-supply";
reg = <0x4a003b20 0xc>;
@@ -1031,53 +1105,130 @@ &iva_crit {
#include "dra7xx-clocks.dtsi"
&prm {
+ prm_mpu: prm@300 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x300 0x100>;
+ #power-domain-cells = <0>;
+ };
+
prm_dsp1: prm@400 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x400 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
};
prm_ipu: prm@500 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x500 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_coreaon: prm@628 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x628 0xd8>;
+ #power-domain-cells = <0>;
};
prm_core: prm@700 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x700 0x100>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
};
prm_iva: prm@f00 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0xf00 0x100>;
+ #reset-cells = <1>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_cam: prm@1000 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1000 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_dss: prm@1100 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1100 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_gpu: prm@1200 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1200 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_l3init: prm@1300 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1300 0x100>;
+ #reset-cells = <1>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_l4per: prm@1400 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1400 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_custefuse: prm@1600 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1600 0x100>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_wkupaon: prm@1724 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1724 0x100>;
+ #power-domain-cells = <0>;
};
prm_dsp2: prm@1b00 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1b00 0x40>;
#reset-cells = <1>;
+ #power-domain-cells = <0>;
};
prm_eve1: prm@1b40 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1b40 0x40>;
+ #power-domain-cells = <0>;
};
prm_eve2: prm@1b80 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1b80 0x40>;
+ #power-domain-cells = <0>;
};
prm_eve3: prm@1bc0 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1bc0 0x40>;
+ #power-domain-cells = <0>;
};
prm_eve4: prm@1c00 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1c00 0x60>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_rtc: prm@1c60 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1c60 0x20>;
+ #power-domain-cells = <0>;
+ };
+
+ prm_vpe: prm@1c80 {
+ compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
+ reg = <0x1c80 0x80>;
+ #power-domain-cells = <0>;
};
};
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index dc0a93b..2365554 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1726,6 +1726,20 @@ l3instr_clkctrl: l3instr-clkctrl@20 {
};
};
+ iva_cm: iva-cm@f00 {
+ compatible = "ti,omap4-cm";
+ reg = <0xf00 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xf00 0x100>;
+
+ iva_clkctrl: iva-clkctrl@20 {
+ compatible = "ti,clkctrl";
+ reg = <0x20 0xc>;
+ #clock-cells = <2>;
+ };
+ };
+
cam_cm: cam-cm@1000 {
compatible = "ti,omap4-cm";
reg = <0x1000 0x100>;
diff --git a/arch/arm/boot/dts/exynos-mfc-reserved-memory.dtsi b/arch/arm/boot/dts/exynos-mfc-reserved-memory.dtsi
index 1dbf3bb..597ade3 100644
--- a/arch/arm/boot/dts/exynos-mfc-reserved-memory.dtsi
+++ b/arch/arm/boot/dts/exynos-mfc-reserved-memory.dtsi
@@ -11,14 +11,14 @@ reserved-memory {
#size-cells = <1>;
ranges;
- mfc_left: region_mfc_left {
+ mfc_left: region-mfc-left {
compatible = "shared-dma-pool";
no-map;
size = <0x2400000>;
alignment = <0x100000>;
};
- mfc_right: region_mfc_right {
+ mfc_right: region-mfc-right {
compatible = "shared-dma-pool";
no-map;
size = <0x800000>;
diff --git a/arch/arm/boot/dts/exynos3250-artik5-eval.dts b/arch/arm/boot/dts/exynos3250-artik5-eval.dts
index 20446a8..a1e22f6 100644
--- a/arch/arm/boot/dts/exynos3250-artik5-eval.dts
+++ b/arch/arm/boot/dts/exynos3250-artik5-eval.dts
@@ -37,3 +37,29 @@ &mshc_2 {
&serial_2 {
status = "okay";
};
+
+&spi_0 {
+ status = "okay";
+ cs-gpios = <&gpx3 4 GPIO_ACTIVE_LOW>, <0>;
+
+ assigned-clocks = <&cmu CLK_MOUT_SPI0>, <&cmu CLK_DIV_SPI0>,
+ <&cmu CLK_DIV_SPI0_PRE>, <&cmu CLK_SCLK_SPI0>;
+ assigned-clock-parents = <&cmu CLK_DIV_MPLL_PRE>, /* for: CLK_MOUT_SPI0 */
+ <&cmu CLK_MOUT_SPI0>, /* for: CLK_DIV_SPI0 */
+ <&cmu CLK_DIV_SPI0>, /* for: CLK_DIV_SPI0_PRE */
+ <&cmu CLK_DIV_SPI0_PRE>; /* for: CLK_SCLK_SPI0 */
+
+ ethernet@0 {
+ compatible = "asix,ax88796c";
+ reg = <0x0>;
+ local-mac-address = [00 00 00 00 00 00]; /* Filled in by a boot-loader */
+ interrupt-parent = <&gpx2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <40000000>;
+ reset-gpios = <&gpe0 2 GPIO_ACTIVE_LOW>;
+
+ controller-data {
+ samsung,spi-feedback-delay = <2>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos3250-artik5.dtsi b/arch/arm/boot/dts/exynos3250-artik5.dtsi
index 12887b3..04290ec 100644
--- a/arch/arm/boot/dts/exynos3250-artik5.dtsi
+++ b/arch/arm/boot/dts/exynos3250-artik5.dtsi
@@ -76,7 +76,7 @@ &i2c_0 {
samsung,i2c-max-bus-freq = <100000>;
status = "okay";
- s2mps14_pmic@66 {
+ pmic@66 {
compatible = "samsung,s2mps14-pmic";
interrupt-parent = <&gpx3>;
interrupts = <5 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts b/arch/arm/boot/dts/exynos3250-monk.dts
index c1a68e6..6945156 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -34,10 +34,10 @@ firmware@205f000 {
reg = <0x0205F000 0x1000>;
};
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
- power_key {
+ power-key {
gpios = <&gpx2 7 GPIO_ACTIVE_LOW>;
linux,code = <KEY_POWER>;
label = "power key";
@@ -62,7 +62,7 @@ i2c_max77836: i2c-gpio-0 {
#address-cells = <1>;
#size-cells = <0>;
- max77836: subpmic@25 {
+ max77836: pmic@25 {
compatible = "maxim,max77836";
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_NONE>;
@@ -197,7 +197,7 @@ &i2c_0 {
samsung,i2c-max-bus-freq = <100000>;
status = "okay";
- s2mps14_pmic@66 {
+ pmic@66 {
compatible = "samsung,s2mps14-pmic";
interrupt-parent = <&gpx0>;
interrupts = <7 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts b/arch/arm/boot/dts/exynos3250-rinato.dts
index b55afaa..a26e3e5 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -38,10 +38,10 @@ firmware@205f000 {
reg = <0x0205F000 0x1000>;
};
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
- power_key {
+ power-key {
gpios = <&gpx2 7 GPIO_ACTIVE_LOW>;
linux,code = <KEY_POWER>;
label = "power key";
@@ -62,7 +62,7 @@ i2c_max77836: i2c-gpio-0 {
#address-cells = <1>;
#size-cells = <0>;
- max77836: subpmic@25 {
+ max77836: pmic@25 {
compatible = "maxim,max77836";
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_NONE>;
@@ -267,7 +267,7 @@ &i2c_0 {
samsung,i2c-max-bus-freq = <100000>;
status = "okay";
- s2mps14_pmic@66 {
+ pmic@66 {
compatible = "samsung,s2mps14-pmic";
interrupt-parent = <&gpx0>;
interrupts = <7 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index a1e93fb..77ab719 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -439,7 +439,6 @@ adc: adc@126c0000 {
clock-names = "adc", "sclk";
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
#io-channel-cells = <1>;
- io-channel-ranges;
samsung,syscon-phandle = <&pmu_system_controller>;
status = "disabled";
};
@@ -691,25 +690,25 @@ pwm: pwm@139d0000 {
status = "disabled";
};
- ppmu_dmc0: ppmu_dmc0@106a0000 {
+ ppmu_dmc0: ppmu@106a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106a0000 0x2000>;
status = "disabled";
};
- ppmu_dmc1: ppmu_dmc1@106b0000 {
+ ppmu_dmc1: ppmu@106b0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106b0000 0x2000>;
status = "disabled";
};
- ppmu_cpu: ppmu_cpu@106c0000 {
+ ppmu_cpu: ppmu@106c0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106c0000 0x2000>;
status = "disabled";
};
- ppmu_rightbus: ppmu_rightbus@112a0000 {
+ ppmu_rightbus: ppmu@112a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x112a0000 0x2000>;
clocks = <&cmu CLK_PPMURIGHT>;
@@ -717,7 +716,7 @@ ppmu_rightbus: ppmu_rightbus@112a0000 {
status = "disabled";
};
- ppmu_leftbus: ppmu_leftbus0@116a0000 {
+ ppmu_leftbus: ppmu@116a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x116a0000 0x2000>;
clocks = <&cmu CLK_PPMULEFT>;
@@ -725,7 +724,7 @@ ppmu_leftbus: ppmu_leftbus0@116a0000 {
status = "disabled";
};
- ppmu_camif: ppmu_camif@11ac0000 {
+ ppmu_camif: ppmu@11ac0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x11ac0000 0x2000>;
clocks = <&cmu CLK_PPMUCAMIF>;
@@ -733,7 +732,7 @@ ppmu_camif: ppmu_camif@11ac0000 {
status = "disabled";
};
- ppmu_lcd0: ppmu_lcd0@11e40000 {
+ ppmu_lcd0: ppmu@11e40000 {
compatible = "samsung,exynos-ppmu";
reg = <0x11e40000 0x2000>;
clocks = <&cmu CLK_PPMULCD0>;
@@ -741,7 +740,7 @@ ppmu_lcd0: ppmu_lcd0@11e40000 {
status = "disabled";
};
- ppmu_fsys: ppmu_fsys@12630000 {
+ ppmu_fsys: ppmu@12630000 {
compatible = "samsung,exynos-ppmu";
reg = <0x12630000 0x2000>;
clocks = <&cmu CLK_PPMUFILE>;
@@ -749,7 +748,7 @@ ppmu_fsys: ppmu_fsys@12630000 {
status = "disabled";
};
- ppmu_g3d: ppmu_g3d@13220000 {
+ ppmu_g3d: ppmu@13220000 {
compatible = "samsung,exynos-ppmu";
reg = <0x13220000 0x2000>;
clocks = <&cmu CLK_PPMUG3D>;
@@ -757,7 +756,7 @@ ppmu_g3d: ppmu_g3d@13220000 {
status = "disabled";
};
- ppmu_mfc: ppmu_mfc@13660000 {
+ ppmu_mfc: ppmu@13660000 {
compatible = "samsung,exynos-ppmu";
reg = <0x13660000 0x2000>;
clocks = <&cmu CLK_PPMUMFC_L>;
@@ -765,7 +764,7 @@ ppmu_mfc: ppmu_mfc@13660000 {
status = "disabled";
};
- bus_dmc: bus_dmc {
+ bus_dmc: bus-dmc {
compatible = "samsung,exynos-bus";
clocks = <&cmu_dmc CLK_DIV_DMC>;
clock-names = "bus";
@@ -773,9 +772,8 @@ bus_dmc: bus_dmc {
status = "disabled";
};
- bus_dmc_opp_table: opp_table1 {
+ bus_dmc_opp_table: opp-table1 {
compatible = "operating-points-v2";
- opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
@@ -799,7 +797,7 @@ opp-400000000 {
};
};
- bus_leftbus: bus_leftbus {
+ bus_leftbus: bus-leftbus {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_GDL>;
clock-names = "bus";
@@ -807,7 +805,7 @@ bus_leftbus: bus_leftbus {
status = "disabled";
};
- bus_rightbus: bus_rightbus {
+ bus_rightbus: bus-rightbus {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_GDR>;
clock-names = "bus";
@@ -815,7 +813,7 @@ bus_rightbus: bus_rightbus {
status = "disabled";
};
- bus_lcd0: bus_lcd0 {
+ bus_lcd0: bus-lcd0 {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_160>;
clock-names = "bus";
@@ -823,7 +821,7 @@ bus_lcd0: bus_lcd0 {
status = "disabled";
};
- bus_fsys: bus_fsys {
+ bus_fsys: bus-fsys {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_200>;
clock-names = "bus";
@@ -831,7 +829,7 @@ bus_fsys: bus_fsys {
status = "disabled";
};
- bus_mcuisp: bus_mcuisp {
+ bus_mcuisp: bus-mcuisp {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
clock-names = "bus";
@@ -839,7 +837,7 @@ bus_mcuisp: bus_mcuisp {
status = "disabled";
};
- bus_isp: bus_isp {
+ bus_isp: bus-isp {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_266>;
clock-names = "bus";
@@ -847,7 +845,7 @@ bus_isp: bus_isp {
status = "disabled";
};
- bus_peril: bus_peril {
+ bus_peril: bus-peril {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_100>;
clock-names = "bus";
@@ -855,7 +853,7 @@ bus_peril: bus_peril {
status = "disabled";
};
- bus_mfc: bus_mfc {
+ bus_mfc: bus-mfc {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_SCLK_MFC>;
clock-names = "bus";
@@ -863,9 +861,8 @@ bus_mfc: bus_mfc {
status = "disabled";
};
- bus_leftbus_opp_table: opp_table2 {
+ bus_leftbus_opp_table: opp-table2 {
compatible = "operating-points-v2";
- opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
@@ -889,9 +886,8 @@ opp-200000000 {
};
};
- bus_mcuisp_opp_table: opp_table3 {
+ bus_mcuisp_opp_table: opp-table3 {
compatible = "operating-points-v2";
- opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
@@ -910,9 +906,8 @@ opp-400000000 {
};
};
- bus_isp_opp_table: opp_table4 {
+ bus_isp_opp_table: opp-table4 {
compatible = "operating-points-v2";
- opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
@@ -931,9 +926,8 @@ opp-300000000 {
};
};
- bus_peril_opp_table: opp_table5 {
+ bus_peril_opp_table: opp-table5 {
compatible = "operating-points-v2";
- opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index a1e5444..eab77a6 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -782,7 +782,7 @@ mixer: mixer@12c10000 {
status = "disabled";
};
- ppmu_dmc0: ppmu_dmc0@106a0000 {
+ ppmu_dmc0: ppmu@106a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106a0000 0x2000>;
clocks = <&clock CLK_PPMUDMC0>;
@@ -790,7 +790,7 @@ ppmu_dmc0: ppmu_dmc0@106a0000 {
status = "disabled";
};
- ppmu_dmc1: ppmu_dmc1@106b0000 {
+ ppmu_dmc1: ppmu@106b0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106b0000 0x2000>;
clocks = <&clock CLK_PPMUDMC1>;
@@ -798,7 +798,7 @@ ppmu_dmc1: ppmu_dmc1@106b0000 {
status = "disabled";
};
- ppmu_cpu: ppmu_cpu@106c0000 {
+ ppmu_cpu: ppmu@106c0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106c0000 0x2000>;
clocks = <&clock CLK_PPMUCPU>;
@@ -806,7 +806,7 @@ ppmu_cpu: ppmu_cpu@106c0000 {
status = "disabled";
};
- ppmu_rightbus: ppmu_rightbus@112a0000 {
+ ppmu_rightbus: ppmu@112a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x112a0000 0x2000>;
clocks = <&clock CLK_PPMURIGHT>;
@@ -814,7 +814,7 @@ ppmu_rightbus: ppmu_rightbus@112a0000 {
status = "disabled";
};
- ppmu_leftbus: ppmu_leftbus0@116a0000 {
+ ppmu_leftbus: ppmu@116a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x116a0000 0x2000>;
clocks = <&clock CLK_PPMULEFT>;
@@ -822,7 +822,7 @@ ppmu_leftbus: ppmu_leftbus0@116a0000 {
status = "disabled";
};
- ppmu_camif: ppmu_camif@11ac0000 {
+ ppmu_camif: ppmu@11ac0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x11ac0000 0x2000>;
clocks = <&clock CLK_PPMUCAMIF>;
@@ -830,7 +830,7 @@ ppmu_camif: ppmu_camif@11ac0000 {
status = "disabled";
};
- ppmu_lcd0: ppmu_lcd0@11e40000 {
+ ppmu_lcd0: ppmu@11e40000 {
compatible = "samsung,exynos-ppmu";
reg = <0x11e40000 0x2000>;
clocks = <&clock CLK_PPMULCD0>;
@@ -838,13 +838,13 @@ ppmu_lcd0: ppmu_lcd0@11e40000 {
status = "disabled";
};
- ppmu_fsys: ppmu_g3d@12630000 {
+ ppmu_fsys: ppmu@12630000 {
compatible = "samsung,exynos-ppmu";
reg = <0x12630000 0x2000>;
status = "disabled";
};
- ppmu_image: ppmu_image@12aa0000 {
+ ppmu_image: ppmu@12aa0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x12aa0000 0x2000>;
clocks = <&clock CLK_PPMUIMAGE>;
@@ -852,7 +852,7 @@ ppmu_image: ppmu_image@12aa0000 {
status = "disabled";
};
- ppmu_tv: ppmu_tv@12e40000 {
+ ppmu_tv: ppmu@12e40000 {
compatible = "samsung,exynos-ppmu";
reg = <0x12e40000 0x2000>;
clocks = <&clock CLK_PPMUTV>;
@@ -860,7 +860,7 @@ ppmu_tv: ppmu_tv@12e40000 {
status = "disabled";
};
- ppmu_g3d: ppmu_g3d@13220000 {
+ ppmu_g3d: ppmu@13220000 {
compatible = "samsung,exynos-ppmu";
reg = <0x13220000 0x2000>;
clocks = <&clock CLK_PPMUG3D>;
@@ -868,7 +868,7 @@ ppmu_g3d: ppmu_g3d@13220000 {
status = "disabled";
};
- ppmu_mfc_left: ppmu_mfc_left@13660000 {
+ ppmu_mfc_left: ppmu@13660000 {
compatible = "samsung,exynos-ppmu";
reg = <0x13660000 0x2000>;
clocks = <&clock CLK_PPMUMFC_L>;
@@ -876,7 +876,7 @@ ppmu_mfc_left: ppmu_mfc_left@13660000 {
status = "disabled";
};
- ppmu_mfc_right: ppmu_mfc_right@13670000 {
+ ppmu_mfc_right: ppmu@13670000 {
compatible = "samsung,exynos-ppmu";
reg = <0x13670000 0x2000>;
clocks = <&clock CLK_PPMUMFC_R>;
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts b/arch/arm/boot/dts/exynos4210-i9100.dts
index 5370ee4..a0c3bab 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -329,7 +329,7 @@ &i2c_3 {
pinctrl-0 = <&i2c3_bus>;
pinctrl-names = "default";
- mxt224-touchscreen@4a {
+ touchscreen@4a {
compatible = "atmel,maxtouch";
reg = <0x4a>;
@@ -348,7 +348,7 @@ &i2c_5 {
pinctrl-0 = <&i2c5_bus>;
pinctrl-names = "default";
- max8997_pmic@66 {
+ pmic@66 {
compatible = "maxim,max8997-pmic";
reg = <0x66>;
@@ -597,7 +597,7 @@ &i2c_7 {
pinctrl-0 = <&i2c7_bus>;
pinctrl-names = "default";
- ak8975@c {
+ magnetometer@c {
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
index 7d2cfba..1c53941 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -43,7 +43,7 @@ mmc_reg: voltage-regulator {
enable-active-high;
};
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
up {
@@ -171,7 +171,7 @@ &i2c_0 {
pinctrl-0 = <&i2c0_bus>;
pinctrl-names = "default";
- max8997_pmic@66 {
+ pmic@66 {
compatible = "maxim,max8997-pmic";
reg = <0x66>;
interrupt-parent = <&gpx0>;
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index c5609af..d5797a6 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -90,61 +90,61 @@ &keypad {
pinctrl-0 = <&keypad_rows &keypad_cols>;
status = "okay";
- key_1 {
+ key-1 {
keypad,row = <0>;
keypad,column = <3>;
linux,code = <2>;
};
- key_2 {
+ key-2 {
keypad,row = <0>;
keypad,column = <4>;
linux,code = <3>;
};
- key_3 {
+ key-3 {
keypad,row = <0>;
keypad,column = <5>;
linux,code = <4>;
};
- key_4 {
+ key-4 {
keypad,row = <0>;
keypad,column = <6>;
linux,code = <5>;
};
- key_5 {
+ key-5 {
keypad,row = <0>;
keypad,column = <7>;
linux,code = <6>;
};
- key_a {
+ key-a {
keypad,row = <1>;
keypad,column = <3>;
linux,code = <30>;
};
- key_b {
+ key-b {
keypad,row = <1>;
keypad,column = <4>;
linux,code = <48>;
};
- key_c {
+ key-c {
keypad,row = <1>;
keypad,column = <5>;
linux,code = <46>;
};
- key_d {
+ key-d {
keypad,row = <1>;
keypad,column = <6>;
linux,code = <32>;
};
- key_e {
+ key-e {
keypad,row = <1>;
keypad,column = <7>;
linux,code = <18>;
@@ -200,7 +200,7 @@ &spi_2 {
cs-gpios = <&gpc1 2 GPIO_ACTIVE_HIGH>;
status = "okay";
- w25x80@0 {
+ flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "w25x80";
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index a226bec..d2406c9 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -263,7 +263,7 @@ &i2c_3 {
pinctrl-names = "default";
status = "okay";
- mms114-touchscreen@48 {
+ touchscreen@48 {
compatible = "melfas,mms114";
reg = <0x48>;
interrupt-parent = <&gpx0>;
@@ -283,7 +283,7 @@ &i2c_5 {
pinctrl-names = "default";
status = "okay";
- max8997_pmic@66 {
+ pmic@66 {
compatible = "maxim,max8997-pmic";
reg = <0x66>;
@@ -462,6 +462,26 @@ EN32KHZ_CP {
};
};
+&pinctrl_1 {
+ bt_shutdown: bt-shutdown {
+ samsung,pins = "gpl1-0";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_host_wakeup: bt-host-wakeup {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_device_wakeup: bt-device-wakeup {
+ samsung,pins = "gpx3-1";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&pmic_ap_clk>;
@@ -512,6 +532,17 @@ brcmf: wifi@1 {
&serial_0 {
status = "okay";
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ pinctrl-0 = <&bt_shutdown &bt_device_wakeup &bt_host_wakeup>;
+ pinctrl-names = "default";
+ shutdown-gpios = <&gpl1 0 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpx3 1 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ };
};
&serial_1 {
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 08284e8..dd44ad2 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -532,6 +532,24 @@ &ohci {
};
&pinctrl_1 {
+ bt_shutdown: bt-shutdown {
+ samsung,pins = "gpe1-4";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_host_wakeup: bt-host-wakeup {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_device_wakeup: bt-device-wakeup {
+ samsung,pins = "gpx3-1";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
lp3974_irq: lp3974-irq {
samsung,pins = "gpx0-7", "gpx2-7";
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
@@ -608,6 +626,17 @@ &serial_0 {
status = "okay";
/delete-property/dmas;
/delete-property/dma-names;
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ pinctrl-0 = <&bt_shutdown &bt_device_wakeup &bt_host_wakeup>;
+ pinctrl-names = "default";
+ shutdown-gpios = <&gpe1 4 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpx3 1 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ };
};
&serial_1 {
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index fddc661..70baad9 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -168,13 +168,13 @@ g2d: g2d@12800000 {
iommus = <&sysmmu_g2d>;
};
- ppmu_acp: ppmu_acp@10ae0000 {
+ ppmu_acp: ppmu@10ae0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x10ae0000 0x2000>;
status = "disabled";
};
- ppmu_lcd1: ppmu_lcd1@12240000 {
+ ppmu_lcd1: ppmu@12240000 {
compatible = "samsung,exynos-ppmu";
reg = <0x12240000 0x2000>;
clocks = <&clock CLK_PPMULCD1>;
@@ -204,7 +204,7 @@ sysmmu_fimd1: sysmmu@12220000 {
#iommu-cells = <0>;
};
- bus_dmc: bus_dmc {
+ bus_dmc: bus-dmc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_DMC>;
clock-names = "bus";
@@ -212,7 +212,7 @@ bus_dmc: bus_dmc {
status = "disabled";
};
- bus_acp: bus_acp {
+ bus_acp: bus-acp {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_ACP>;
clock-names = "bus";
@@ -220,7 +220,7 @@ bus_acp: bus_acp {
status = "disabled";
};
- bus_peri: bus_peri {
+ bus_peri: bus-peri {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK100>;
clock-names = "bus";
@@ -228,7 +228,7 @@ bus_peri: bus_peri {
status = "disabled";
};
- bus_fsys: bus_fsys {
+ bus_fsys: bus-fsys {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK133>;
clock-names = "bus";
@@ -236,7 +236,7 @@ bus_fsys: bus_fsys {
status = "disabled";
};
- bus_display: bus_display {
+ bus_display: bus-display {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK160>;
clock-names = "bus";
@@ -244,7 +244,7 @@ bus_display: bus_display {
status = "disabled";
};
- bus_lcd0: bus_lcd0 {
+ bus_lcd0: bus-lcd0 {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK200>;
clock-names = "bus";
@@ -252,7 +252,7 @@ bus_lcd0: bus_lcd0 {
status = "disabled";
};
- bus_leftbus: bus_leftbus {
+ bus_leftbus: bus-leftbus {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
@@ -260,7 +260,7 @@ bus_leftbus: bus_leftbus {
status = "disabled";
};
- bus_rightbus: bus_rightbus {
+ bus_rightbus: bus-rightbus {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_GDR>;
clock-names = "bus";
@@ -268,7 +268,7 @@ bus_rightbus: bus_rightbus {
status = "disabled";
};
- bus_mfc: bus_mfc {
+ bus_mfc: bus-mfc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_SCLK_MFC>;
clock-names = "bus";
@@ -276,7 +276,7 @@ bus_mfc: bus_mfc {
status = "disabled";
};
- bus_dmc_opp_table: opp_table1 {
+ bus_dmc_opp_table: opp-table1 {
compatible = "operating-points-v2";
opp-shared;
@@ -295,7 +295,7 @@ opp-400000000 {
};
};
- bus_acp_opp_table: opp_table2 {
+ bus_acp_opp_table: opp-table2 {
compatible = "operating-points-v2";
opp-shared;
@@ -310,7 +310,7 @@ opp-200000000 {
};
};
- bus_peri_opp_table: opp_table3 {
+ bus_peri_opp_table: opp-table3 {
compatible = "operating-points-v2";
opp-shared;
@@ -322,7 +322,7 @@ opp-100000000 {
};
};
- bus_fsys_opp_table: opp_table4 {
+ bus_fsys_opp_table: opp-table4 {
compatible = "operating-points-v2";
opp-shared;
@@ -334,7 +334,7 @@ opp-134000000 {
};
};
- bus_display_opp_table: opp_table5 {
+ bus_display_opp_table: opp-table5 {
compatible = "operating-points-v2";
opp-shared;
@@ -349,7 +349,7 @@ opp-160000000 {
};
};
- bus_leftbus_opp_table: opp_table6 {
+ bus_leftbus_opp_table: opp-table6 {
compatible = "operating-points-v2";
opp-shared;
@@ -463,7 +463,7 @@ &gpu {
"ppmmu3";
operating-points-v2 = <&gpu_opp_table>;
- gpu_opp_table: opp_table {
+ gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-160000000 {
diff --git a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
index 89ed81f..c14e37d 100644
--- a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
+++ b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
@@ -15,7 +15,7 @@ aliases {
i2c10 = &i2c_cm36651;
};
- aat1290 {
+ led-controller {
compatible = "skyworks,aat1290";
flen-gpios = <&gpj1 1 GPIO_ACTIVE_HIGH>;
enset-gpios = <&gpj1 2 GPIO_ACTIVE_HIGH>;
@@ -58,9 +58,8 @@ i2c_ak8975: i2c-gpio-0 {
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
- status = "okay";
- ak8975@c {
+ magnetometer@c {
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
@@ -75,7 +74,7 @@ i2c_cm36651: i2c-gpio-2 {
#address-cells = <1>;
#size-cells = <0>;
- cm36651@18 {
+ light-sensor@18 {
compatible = "capella,cm36651";
reg = <0x18>;
interrupt-parent = <&gpx0>;
@@ -133,7 +132,7 @@ timing-0 {
};
&i2c_3 {
- mms114-touchscreen@48 {
+ touchscreen@48 {
compatible = "melfas,mms114";
reg = <0x48>;
interrupt-parent = <&gpm2>;
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index f6d0a5f..4743130 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -175,7 +175,7 @@ &i2c_4 {
pinctrl-names = "default";
status = "okay";
- codec: wm8960@1a {
+ codec: audio-codec@1a {
compatible = "wlf,wm8960";
reg = <0x1a>;
clocks = <&pmu_system_controller 0>;
diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
index dfceb15..4583d34 100644
--- a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
+++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
@@ -134,7 +134,7 @@ &i2c_1 {
pinctrl-names = "default";
status = "okay";
- s5m8767: s5m8767-pmic@66 {
+ s5m8767: pmic@66 {
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
diff --git a/arch/arm/boot/dts/exynos4412-midas.dtsi b/arch/arm/boot/dts/exynos4412-midas.dtsi
index 7e7c243..111c32b 100644
--- a/arch/arm/boot/dts/exynos4412-midas.dtsi
+++ b/arch/arm/boot/dts/exynos4412-midas.dtsi
@@ -169,9 +169,8 @@ i2c_max77693: i2c-gpio-1 {
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
- status = "okay";
- max77693@66 {
+ pmic@66 {
compatible = "maxim,max77693";
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
@@ -193,7 +192,7 @@ charger_reg: CHARGER {
};
};
- max77693_haptic {
+ motor-driver {
compatible = "maxim,max77693-haptic";
haptic-supply = <&ldo26_reg>;
pwms = <&pwm 0 38022 0>;
@@ -218,9 +217,8 @@ i2c_max77693_fuel: i2c-gpio-3 {
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
- status = "okay";
- max77693-fuel-gauge@36 {
+ fuel-gauge@36 {
compatible = "maxim,max17047";
interrupt-parent = <&gpx2>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
@@ -262,7 +260,6 @@ i2c-mhl {
pinctrl-0 = <&i2c_mhl_bus>;
pinctrl-names = "default";
- status = "okay";
sii9234: hdmi-bridge@39 {
compatible = "sil,sii9234";
@@ -550,7 +547,7 @@ &i2c_0 {
pinctrl-names = "default";
status = "okay";
- s5c73m3: s5c73m3@3c {
+ s5c73m3: image-sensor@3c {
compatible = "samsung,s5c73m3";
reg = <0x3c>;
xshutdown-gpios = <&gpf1 3 GPIO_ACTIVE_LOW>; /* ISP_RESET */
@@ -577,7 +574,7 @@ &i2c1_isp {
pinctrl-0 = <&fimc_is_i2c1>;
pinctrl-names = "default";
- s5k6a3@10 {
+ image-sensor@10 {
compatible = "samsung,s5k6a3";
reg = <0x10>;
svdda-supply = <&cam_io_reg>;
@@ -616,7 +613,7 @@ &i2c_4 {
pinctrl-names = "default";
status = "okay";
- wm1811: wm1811@1a {
+ wm1811: audio-codec@1a {
compatible = "wlf,wm1811";
reg = <0x1a>;
clocks = <&pmu_system_controller 0>,
@@ -665,7 +662,7 @@ &i2c_7 {
pinctrl-names = "default";
status = "okay";
- max77686: max77686_pmic@9 {
+ max77686: pmic@9 {
compatible = "maxim,max77686";
interrupt-parent = <&gpx0>;
interrupts = <7 IRQ_TYPE_NONE>;
@@ -1109,6 +1106,21 @@ gpio_keys: gpio-keys {
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
};
+ bt_shutdown: bt-shutdown {
+ samsung,pins = "gpl0-6";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_host_wakeup: bt-host-wakeup {
+ samsung,pins = "gpx2-6";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_device_wakeup: bt-device-wakeup {
+ samsung,pins = "gpx3-1";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
max77686_irq: max77686-irq {
samsung,pins = "gpx0-7";
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
@@ -1386,7 +1398,20 @@ brcmf: wifi@1 {
};
&serial_0 {
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ pinctrl-0 = <&bt_shutdown &bt_device_wakeup &bt_host_wakeup>;
+ pinctrl-names = "default";
+ max-speed = <3000000>;
+ shutdown-gpios = <&gpl0 6 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpx3 1 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
+ };
};
&serial_1 {
@@ -1407,7 +1432,7 @@ &spi_1 {
cs-gpios = <&gpb 5 GPIO_ACTIVE_HIGH>;
status = "okay";
- s5c73m3_spi: s5c73m3@0 {
+ s5c73m3_spi: image-sensor@0 {
compatible = "samsung,s5c73m3";
spi-max-frequency = <50000000>;
reg = <0>;
diff --git a/arch/arm/boot/dts/exynos4412-n710x.dts b/arch/arm/boot/dts/exynos4412-n710x.dts
index a47b7f3..c49dbb7 100644
--- a/arch/arm/boot/dts/exynos4412-n710x.dts
+++ b/arch/arm/boot/dts/exynos4412-n710x.dts
@@ -45,7 +45,7 @@ &i2c_3 {
pinctrl-names = "default";
status = "okay";
- mms152-touchscreen@48 {
+ touchscreen@48 {
compatible = "melfas,mms152";
reg = <0x48>;
interrupt-parent = <&gpm2>;
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 2983e91..2b20d90 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -22,12 +22,12 @@ firmware@204f000 {
reg = <0x0204F000 0x1000>;
};
- gpio_keys {
+ gpio_keys: gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&gpio_power_key>;
- power_key {
+ power-key {
gpios = <&gpx1 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_POWER>;
label = "power key";
@@ -171,7 +171,7 @@ cooling_map1: map1 {
};
&pinctrl_1 {
- gpio_power_key: power_key {
+ gpio_power_key: power-key {
samsung,pins = "gpx1-3";
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
};
@@ -255,7 +255,6 @@ &hdmicec {
};
&hsotg {
- dr_mode = "peripheral";
status = "okay";
vusb_d-supply = <&ldo15_reg>;
vusb_a-supply = <&ldo12_reg>;
@@ -266,7 +265,7 @@ &i2c_0 {
samsung,i2c-max-bus-freq = <400000>;
status = "okay";
- usb3503: usb3503@8 {
+ usb3503: usb-hub@8 {
compatible = "smsc,usb3503";
reg = <0x08>;
@@ -492,7 +491,7 @@ buck8_reg: BUCK8 {
&i2c_1 {
status = "okay";
- max98090: max98090@10 {
+ max98090: audio-codec@10 {
compatible = "maxim,max98090";
reg = <0x10>;
interrupt-parent = <&gpx0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index b8549d8..efaf753 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -16,11 +16,24 @@ / {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
compatible = "hardkernel,odroid-u3", "samsung,exynos4412", "samsung,exynos4";
+ aliases {
+ ethernet = ðernet;
+ };
+
memory@40000000 {
device_type = "memory";
reg = <0x40000000 0x7FF00000>;
};
+ vbus_otg_reg: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "VBUS_VDD_5.0V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpl2 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
leds {
compatible = "gpio-leds";
led1 {
@@ -101,8 +114,21 @@ &usb3503 {
};
&ehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
phys = <&exynos_usbphy 2>, <&exynos_usbphy 3>;
phy-names = "hsic0", "hsic1";
+
+ ethernet: usbether@2 {
+ compatible = "usb0424,9730";
+ reg = <2>;
+ local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */
+ };
+};
+
+&hsotg {
+ dr_mode = "otg";
+ vbus-supply = <&vbus_otg_reg>;
};
&sound {
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 3ea2a01..0e9d626 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -15,6 +15,10 @@ / {
model = "Hardkernel ODROID-X board based on Exynos4412";
compatible = "hardkernel,odroid-x", "samsung,exynos4412", "samsung,exynos4";
+ aliases {
+ ethernet = ðernet;
+ };
+
memory@40000000 {
device_type = "memory";
reg = <0x40000000 0x3FF00000>;
@@ -36,19 +40,7 @@ led2 {
};
};
- gpio_keys {
- pinctrl-0 = <&gpio_power_key &gpio_home_key>;
-
- home_key {
- gpios = <&gpx2 2 GPIO_ACTIVE_HIGH>;
- linux,code = <KEY_HOME>;
- label = "home key";
- debounce-interval = <10>;
- wakeup-source;
- };
- };
-
- regulator_p3v3 {
+ regulator-1 {
compatible = "regulator-fixed";
regulator-name = "p3v3_en";
regulator-min-microvolt = <3300000>;
@@ -72,8 +64,46 @@ &buck8_reg {
};
&ehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
phys = <&exynos_usbphy 2>;
phy-names = "hsic0";
+
+ hub@2 {
+ compatible = "usb0424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb0424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <1>;
+ local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */
+ };
+ };
+ };
+};
+
+&gpio_keys {
+ pinctrl-0 = <&gpio_power_key &gpio_home_key>;
+
+ home-key {
+ gpios = <&gpx2 2 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_HOME>;
+ label = "home key";
+ debounce-interval = <10>;
+ wakeup-source;
+ };
+};
+
+&hsotg {
+ dr_mode = "peripheral";
};
&mshc_0 {
@@ -81,7 +111,7 @@ &mshc_0 {
};
&pinctrl_1 {
- gpio_home_key: home_key {
+ gpio_home_key: home-key {
samsung,pins = "gpx2-2";
samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts b/arch/arm/boot/dts/exynos4412-origen.dts
index c2e793b..e1f6de5 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -116,7 +116,7 @@ &i2c_0 {
pinctrl-names = "default";
status = "okay";
- s5m8767_pmic@66 {
+ pmic@66 {
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
@@ -453,37 +453,37 @@ &keypad {
pinctrl-names = "default";
status = "okay";
- key_home {
+ key-home {
keypad,row = <0>;
keypad,column = <0>;
linux,code = <KEY_HOME>;
};
- key_down {
+ key-down {
keypad,row = <0>;
keypad,column = <1>;
linux,code = <KEY_DOWN>;
};
- key_up {
+ key-up {
keypad,row = <1>;
keypad,column = <0>;
linux,code = <KEY_UP>;
};
- key_menu {
+ key-menu {
keypad,row = <1>;
keypad,column = <1>;
linux,code = <KEY_MENU>;
};
- key_back {
+ key-back {
keypad,row = <2>;
keypad,column = <0>;
linux,code = <KEY_BACK>;
};
- key_enter {
+ key-enter {
keypad,row = <2>;
keypad,column = <1>;
linux,code = <KEY_ENTER>;
diff --git a/arch/arm/boot/dts/exynos4412-p4note-n8010.dts b/arch/arm/boot/dts/exynos4412-p4note-n8010.dts
new file mode 100644
index 0000000..9f55942
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-p4note-n8010.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's Galaxy Note 10.1 - N801x (wifi only version)
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ */
+
+/dts-v1/;
+#include "exynos4412-p4note.dtsi"
+
+/ {
+ model = "Samsung Galaxy Note 10.1 (GT-N8010/N8013) based on Exynos4412";
+ compatible = "samsung,n8010", "samsung,p4note", "samsung,exynos4412", "samsung,exynos4";
+
+ /* this is the base variant without any kind of modem */
+};
diff --git a/arch/arm/boot/dts/exynos4412-p4note.dtsi b/arch/arm/boot/dts/exynos4412-p4note.dtsi
new file mode 100644
index 0000000..b2f9d54
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-p4note.dtsi
@@ -0,0 +1,1132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's Exynos4412 based p4note device family base DT.
+ * Based on exynos4412-midas.dtsi.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ */
+
+/dts-v1/;
+#include "exynos4412.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
+
+#include <dt-bindings/clock/maxim,max77686.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/samsung.h>
+
+/ {
+ compatible = "samsung,p4note", "samsung,exynos4412", "samsung,exynos4";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x80000000>;
+ };
+
+ chosen {
+ stdout-path = &serial_2;
+ };
+
+ firmware@204f000 {
+ compatible = "samsung,secure-firmware";
+ reg = <0x0204F000 0x1000>;
+ };
+
+ fixed-rate-clocks {
+ xxti {
+ compatible = "samsung,clock-xxti";
+ clock-frequency = <0>;
+ };
+
+ xusbxti {
+ compatible = "samsung,clock-xusbxti";
+ clock-frequency = <24000000>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys>;
+
+ key-down {
+ gpios = <&gpx2 2 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEDOWN>;
+ label = "volume down";
+ debounce-interval = <10>;
+ };
+
+ key-up {
+ gpios = <&gpx3 3 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ label = "volume up";
+ debounce-interval = <10>;
+ };
+
+ key-power {
+ gpios = <&gpx2 7 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ label = "power";
+ debounce-interval = <10>;
+ wakeup-source;
+ };
+ };
+
+ voltage-regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "TSP_LDO1";
+ pinctrl-names = "default";
+ pinctrl-0 = <&tsp_reg_gpio_1>;
+ gpios = <&gpm4 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ voltage-regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "TSP_LDO2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&tsp_reg_gpio_2>;
+ gpios = <&gpb 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ voltage-regulator-3 {
+ compatible = "regulator-fixed";
+ regulator-name = "TSP_LDO3";
+ pinctrl-names = "default";
+ pinctrl-0 = <&tsp_reg_gpio_3>;
+ gpios = <&gpb 7 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <20000>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ wlan_pwrseq: sdhci3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpm3 5 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&wifi_reset>;
+ pinctrl-names = "default";
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
+ clock-names = "ext_clock";
+ };
+
+ i2c-gpio-1 {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpy2 4 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpy2 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ pinctrl-0 = <&ak8975_irq>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpm4>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+
+ i2c-gpio-2 {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpy0 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpy0 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fuel-gauge@36 {
+ compatible = "maxim,max17042";
+ reg = <0x36>;
+ pinctrl-0 = <&fuel_alert_irq>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpx2>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ maxim,rsns-microohm = <10000>;
+ maxim,over-heat-temp = <600>;
+ maxim,over-volt = <4300>;
+ };
+ };
+
+ i2c-gpio-3 {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpm4 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpm4 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@41 {
+ compatible = "st,stmpe811";
+ reg = <0x41>;
+ pinctrl-0 = <&stmpe_adc_irq>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpx0>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ irq-trigger = <0x1>;
+ st,adc-freq = <3>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,sample-time = <3>;
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ #io-channel-cells = <1>;
+ st,norequest-mask = <0x2F>;
+ };
+ };
+ };
+};
+
+&adc {
+ vdd-supply = <&ldo3_reg>;
+ /* not verified */
+ status = "okay";
+};
+
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
+&bus_acp {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_c2c {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_display {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peri {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ /* Corresponds to 800MHz at freq_table */
+ cooling-device = <&cpu0 7 7>, <&cpu1 7 7>,
+ <&cpu2 7 7>, <&cpu3 7 7>;
+ };
+ map1 {
+ /* Corresponds to 200MHz at freq_table */
+ cooling-device = <&cpu0 13 13>, <&cpu1 13 13>,
+ <&cpu2 13 13>, <&cpu3 13 13>;
+ };
+ };
+};
+
+&exynos_usbphy {
+ status = "okay";
+};
+
+&fimd {
+ pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ display-timings {
+ timing0 {
+ clock-frequency = <66666666>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <18>;
+ hback-porch = <36>;
+ hsync-len = <16>;
+ vback-porch = <16>;
+ vfront-porch = <4>;
+ vsync-len = <3>;
+ hsync-active = <1>;
+ };
+ };
+};
+
+&gpu {
+ mali-supply = <&buck4_reg>;
+ status = "okay";
+};
+
+&hsotg {
+ vusb_a-supply = <&ldo12_reg>;
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&i2c_3 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-slave-addr = <0x10>;
+ samsung,i2c-max-bus-freq = <400000>;
+ pinctrl-0 = <&i2c3_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ pinctrl-0 = <&tsp_rst &tsp_irq>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpm2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpm0 4 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&i2c_7 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-slave-addr = <0x10>;
+ samsung,i2c-max-bus-freq = <400000>;
+ pinctrl-0 = <&i2c7_bus>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ max77686: pmic@9 {
+ compatible = "maxim,max77686";
+ interrupt-parent = <&gpx0>;
+ interrupts = <7 IRQ_TYPE_NONE>;
+ pinctrl-0 = <&max77686_irq>;
+ pinctrl-names = "default";
+ reg = <0x09>;
+ #clock-cells = <1>;
+
+ voltage-regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "ldo1";
+ regulator-always-on;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "ldo2";
+ regulator-always-on;
+ };
+
+ /* WM8994 audio */
+ ldo3_reg: LDO3 {
+ regulator-name = "VCC_1.8V_AP";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "ldo4";
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "VCC_1.8V_IO";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "ldo6";
+ regulator-always-on;
+ };
+
+ ldo7_reg: LDO7 {
+ regulator-name = "ldo7";
+ regulator-always-on;
+ };
+
+ /* CSI IP block */
+ ldo8_reg: LDO8 {
+ regulator-name = "VMIPI_1.0V";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ /* IR LED on/off */
+ ldo9_reg: LDO9 {
+ regulator-name = "VLED_IC_1.9V";
+ regulator-min-microvolt = <1950000>;
+ regulator-max-microvolt = <1950000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* CSI IP block */
+ ldo10_reg: LDO10 {
+ regulator-name = "VMIPI_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ ldo11_reg: LDO11 {
+ regulator-name = "VABB1_1.9V";
+ regulator-min-microvolt = <1950000>;
+ regulator-max-microvolt = <1950000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* USB OTG */
+ ldo12_reg: LDO12 {
+ regulator-name = "VUOTG_3.0V";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ /* not connected */
+ ldo13_reg: LDO13 {
+ regulator-name = "ldo13";
+ };
+
+ ldo14_reg: LDO14 {
+ regulator-name = "VABB2_1.9V";
+ regulator-min-microvolt = <1950000>;
+ regulator-max-microvolt = <1950000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ ldo15_reg: LDO15 {
+ regulator-name = "ldo15";
+ regulator-always-on;
+ };
+
+ ldo16_reg: LDO16 {
+ regulator-name = "ldo16";
+ regulator-always-on;
+ };
+
+ /* not connected */
+ ldo17_reg: LDO17 {
+ regulator-name = "ldo17";
+ };
+
+ /* Camera ISX012 */
+ ldo18_reg: LDO18 {
+ regulator-name = "CAM_IO_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* Camera S5K6A3 */
+ ldo19_reg: LDO19 {
+ regulator-name = "VT_CORE_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* not connected */
+ ldo20_reg: LDO20 {
+ regulator-name = "ldo20";
+ };
+
+ /* MMC2 */
+ ldo21_reg: LDO21 {
+ regulator-name = "VTF_2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ maxim,ena-gpios = <&gpy2 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* not connected */
+ ldo22_reg: LDO22 {
+ regulator-name = "ldo22";
+ };
+
+ /* ADC */
+ ldo23_reg: LDO23 {
+ regulator-name = "VDD_ADC_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* Camera S5K6A3 */
+ ldo24_reg: LDO24 {
+ regulator-name = "CAM_A2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ ldo25_reg: LDO25 {
+ regulator-name = "VLED_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ /* Camera ISX012 */
+ ldo26_reg: LDO26 {
+ regulator-name = "3MP_AF_2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = "VDD_MIF";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "VDD_ARM";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck3_reg: BUCK3 {
+ regulator-name = "VDD_INT";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck4_reg: BUCK4 {
+ regulator-name = "VDD_G3D";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1075000>;
+ regulator-boot-on;
+ };
+
+ buck5_reg: BUCK5 {
+ regulator-name = "buck5";
+ regulator-always-on;
+ };
+
+ buck6_reg: BUCK6 {
+ regulator-name = "buck6";
+ regulator-always-on;
+ };
+
+ buck7_reg: BUCK7 {
+ regulator-name = "buck7";
+ regulator-always-on;
+ };
+
+ /* not connected */
+ buck8_reg: BUCK8 {
+ regulator-name = "buck8";
+ };
+
+ buck9_reg: BUCK9 {
+ regulator-name = "3MP_CORE_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&mshc_0 {
+ broken-cd;
+ non-removable;
+ card-detect-delay = <200>;
+ clock-frequency = <400000000>;
+ samsung,dw-mshc-ciu-div = <0>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+ pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
+ pinctrl-names = "default";
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ status = "okay";
+};
+
+&pinctrl_0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sleep0>;
+
+ tsp_reg_gpio_2: tsp-reg-gpio-2 {
+ samsung,pins = "gpb-5";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ tsp_reg_gpio_3: tsp-reg-gpio-3 {
+ samsung,pins = "gpb-7";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ sleep0: sleep-states {
+ PIN_SLP(gpa0-0, INPUT, NONE);
+ PIN_SLP(gpa0-1, OUT0, NONE);
+ PIN_SLP(gpa0-2, INPUT, NONE);
+ PIN_SLP(gpa0-3, INPUT, UP);
+ PIN_SLP(gpa0-4, INPUT, NONE);
+ PIN_SLP(gpa0-5, INPUT, DOWN);
+ PIN_SLP(gpa0-6, INPUT, DOWN);
+ PIN_SLP(gpa0-7, INPUT, UP);
+
+ PIN_SLP(gpa1-0, INPUT, DOWN);
+ PIN_SLP(gpa1-1, INPUT, DOWN);
+ PIN_SLP(gpa1-2, INPUT, DOWN);
+ PIN_SLP(gpa1-3, INPUT, DOWN);
+ PIN_SLP(gpa1-4, INPUT, DOWN);
+ PIN_SLP(gpa1-5, INPUT, DOWN);
+
+ PIN_SLP(gpb-0, INPUT, NONE);
+ PIN_SLP(gpb-1, INPUT, NONE);
+ PIN_SLP(gpb-2, INPUT, NONE);
+ PIN_SLP(gpb-3, INPUT, NONE);
+ PIN_SLP(gpb-4, INPUT, DOWN);
+ PIN_SLP(gpb-5, INPUT, DOWN);
+ PIN_SLP(gpb-6, INPUT, DOWN);
+ PIN_SLP(gpb-7, INPUT, DOWN);
+
+ PIN_SLP(gpc0-0, INPUT, DOWN);
+ PIN_SLP(gpc0-1, INPUT, DOWN);
+ PIN_SLP(gpc0-2, INPUT, DOWN);
+ PIN_SLP(gpc0-3, INPUT, DOWN);
+ PIN_SLP(gpc0-4, INPUT, DOWN);
+
+ PIN_SLP(gpc1-0, INPUT, UP);
+ PIN_SLP(gpc1-1, PREV, NONE);
+ PIN_SLP(gpc1-2, INPUT, UP);
+ PIN_SLP(gpc1-3, INPUT, UP);
+ PIN_SLP(gpc1-4, INPUT, UP);
+
+ PIN_SLP(gpd0-0, INPUT, DOWN);
+ PIN_SLP(gpd0-1, OUT0, NONE);
+ PIN_SLP(gpd0-2, INPUT, NONE);
+ PIN_SLP(gpd0-3, INPUT, NONE);
+
+ PIN_SLP(gpd1-0, INPUT, DOWN);
+ PIN_SLP(gpd1-1, INPUT, DOWN);
+ PIN_SLP(gpd1-2, INPUT, NONE);
+ PIN_SLP(gpd1-3, INPUT, NONE);
+
+ PIN_SLP(gpf0-0, OUT0, NONE);
+ PIN_SLP(gpf0-1, OUT0, NONE);
+ PIN_SLP(gpf0-2, OUT0, NONE);
+ PIN_SLP(gpf0-3, OUT0, NONE);
+ PIN_SLP(gpf0-4, OUT0, NONE);
+ PIN_SLP(gpf0-5, OUT0, NONE);
+ PIN_SLP(gpf0-6, OUT0, NONE);
+ PIN_SLP(gpf0-7, OUT0, NONE);
+
+ PIN_SLP(gpf1-0, OUT0, NONE);
+ PIN_SLP(gpf1-1, OUT0, NONE);
+ PIN_SLP(gpf1-2, OUT0, NONE);
+ PIN_SLP(gpf1-3, OUT0, NONE);
+ PIN_SLP(gpf1-4, OUT0, NONE);
+ PIN_SLP(gpf1-5, OUT0, NONE);
+ PIN_SLP(gpf1-6, OUT0, NONE);
+ PIN_SLP(gpf1-7, OUT0, NONE);
+
+ PIN_SLP(gpf2-0, OUT0, NONE);
+ PIN_SLP(gpf2-1, OUT0, NONE);
+ PIN_SLP(gpf2-2, OUT0, NONE);
+ PIN_SLP(gpf2-3, OUT0, NONE);
+ PIN_SLP(gpf2-4, OUT0, NONE);
+ PIN_SLP(gpf2-5, OUT0, NONE);
+ PIN_SLP(gpf2-6, OUT0, NONE);
+ PIN_SLP(gpf2-7, OUT0, NONE);
+
+ PIN_SLP(gpf3-0, OUT0, NONE);
+ PIN_SLP(gpf3-1, OUT0, NONE);
+ PIN_SLP(gpf3-2, OUT0, NONE);
+ PIN_SLP(gpf3-3, OUT0, NONE);
+ PIN_SLP(gpf3-4, OUT0, NONE);
+ PIN_SLP(gpf3-5, OUT0, NONE);
+
+ PIN_SLP(gpj0-0, INPUT, DOWN);
+ PIN_SLP(gpj0-1, INPUT, DOWN);
+ PIN_SLP(gpj0-2, INPUT, DOWN);
+ PIN_SLP(gpj0-3, PREV, NONE);
+ PIN_SLP(gpj0-4, PREV, NONE);
+ PIN_SLP(gpj0-5, OUT0, NONE);
+ PIN_SLP(gpj0-6, OUT0, NONE);
+ PIN_SLP(gpj0-7, OUT0, NONE);
+
+ PIN_SLP(gpj1-0, OUT0, NONE);
+ PIN_SLP(gpj1-1, INPUT, DOWN);
+ PIN_SLP(gpj1-2, PREV, NONE);
+ PIN_SLP(gpj1-3, OUT0, NONE);
+ };
+};
+
+&pinctrl_1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sleep1>;
+
+ sd3_wifi: sd3-wifi {
+ samsung,pins = "gpk3-3", "gpk3-4", "gpk3-5", "gpk3-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_shutdown: bt-shutdown {
+ samsung,pins = "gpl0-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ uart_sel: uart-sel {
+ samsung,pins = "gpl2-7";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-val = <1>;
+ /* 0 = CP, 1 = AP (serial output) */
+ };
+
+ tsp_rst: tsp-rst {
+ samsung,pins = "gpm0-4";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ tsp_irq: tsp-irq {
+ samsung,pins = "gpm2-3";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_F>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ wifi_reset: wifi-reset {
+ samsung,pins = "gpm3-5";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ tsp_reg_gpio_1: tsp-reg-gpio-1 {
+ samsung,pins = "gpm4-5";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ ak8975_irq: ak8975-irq {
+ samsung,pins = "gpm4-7";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_F>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ };
+
+ stmpe_adc_irq: stmpe-adc-irq {
+ samsung,pins = "gpx0-1";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ max77686_irq: max77686-irq {
+ samsung,pins = "gpx0-7";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ gpio_keys: gpio-keys {
+ samsung,pins = "gpx2-2", "gpx2-7", "gpx3-3";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ fuel_alert_irq: fuel-alert-irq {
+ samsung,pins = "gpx2-3";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ wifi_host_wake: wifi-host-wake {
+ samsung,pins = "gpx2-5";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_F>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ };
+
+ bt_host_wakeup: bt-host-wakeup {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ bt_device_wakeup: bt-device-wakeup {
+ samsung,pins = "gpx3-1";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ sdhci2_cd: sdhci2-cd {
+ samsung,pins = "gpx3-4";
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+ };
+
+ sleep1: sleep-states {
+ PIN_SLP(gpk0-0, PREV, NONE);
+ PIN_SLP(gpk0-1, PREV, NONE);
+ PIN_SLP(gpk0-2, PREV, NONE);
+ PIN_SLP(gpk0-3, PREV, NONE);
+ PIN_SLP(gpk0-4, PREV, NONE);
+ PIN_SLP(gpk0-5, PREV, NONE);
+ PIN_SLP(gpk0-6, PREV, NONE);
+
+ PIN_SLP(gpk1-0, INPUT, DOWN);
+ PIN_SLP(gpk1-1, INPUT, DOWN);
+ PIN_SLP(gpk1-2, INPUT, DOWN);
+ PIN_SLP(gpk1-3, PREV, NONE);
+ PIN_SLP(gpk1-4, PREV, NONE);
+ PIN_SLP(gpk1-5, PREV, NONE);
+ PIN_SLP(gpk1-6, PREV, NONE);
+
+ PIN_SLP(gpk2-0, INPUT, DOWN);
+ PIN_SLP(gpk2-1, INPUT, DOWN);
+ PIN_SLP(gpk2-2, INPUT, DOWN);
+ PIN_SLP(gpk2-3, INPUT, DOWN);
+ PIN_SLP(gpk2-4, INPUT, DOWN);
+ PIN_SLP(gpk2-5, INPUT, DOWN);
+ PIN_SLP(gpk2-6, INPUT, DOWN);
+
+ PIN_SLP(gpk3-0, OUT0, NONE);
+ PIN_SLP(gpk3-1, INPUT, NONE);
+ PIN_SLP(gpk3-2, INPUT, DOWN);
+ PIN_SLP(gpk3-3, INPUT, NONE);
+ PIN_SLP(gpk3-4, INPUT, NONE);
+ PIN_SLP(gpk3-5, INPUT, NONE);
+ PIN_SLP(gpk3-6, INPUT, NONE);
+
+ PIN_SLP(gpl0-0, OUT0, NONE);
+ PIN_SLP(gpl0-1, INPUT, NONE);
+ PIN_SLP(gpl0-2, INPUT, NONE);
+ PIN_SLP(gpl0-3, INPUT, DOWN);
+ PIN_SLP(gpl0-4, PREV, NONE);
+ PIN_SLP(gpl0-6, PREV, NONE);
+
+ PIN_SLP(gpl1-0, OUT0, NONE);
+ PIN_SLP(gpl1-1, OUT0, NONE);
+
+ PIN_SLP(gpl2-0, INPUT, DOWN);
+ PIN_SLP(gpl2-1, INPUT, DOWN);
+ PIN_SLP(gpl2-2, INPUT, DOWN);
+ PIN_SLP(gpl2-3, INPUT, DOWN);
+ PIN_SLP(gpl2-4, OUT0, NONE);
+ PIN_SLP(gpl2-5, INPUT, DOWN);
+ PIN_SLP(gpl2-6, PREV, NONE);
+ PIN_SLP(gpl2-7, PREV, NONE);
+
+ PIN_SLP(gpm0-0, PREV, NONE);
+ PIN_SLP(gpm0-1, OUT0, NONE);
+ PIN_SLP(gpm0-2, INPUT, DOWN);
+ PIN_SLP(gpm0-3, INPUT, NONE);
+ PIN_SLP(gpm0-4, OUT0, NONE);
+ PIN_SLP(gpm0-5, OUT0, NONE);
+ PIN_SLP(gpm0-6, INPUT, DOWN);
+ PIN_SLP(gpm0-7, OUT0, NONE);
+
+ PIN_SLP(gpm1-0, INPUT, NONE);
+ PIN_SLP(gpm1-1, INPUT, NONE);
+ PIN_SLP(gpm1-2, INPUT, NONE);
+ PIN_SLP(gpm1-3, INPUT, NONE);
+ PIN_SLP(gpm1-4, INPUT, NONE);
+ PIN_SLP(gpm1-5, INPUT, NONE);
+ PIN_SLP(gpm1-6, INPUT, DOWN);
+
+ PIN_SLP(gpm2-0, INPUT, NONE);
+ PIN_SLP(gpm2-1, INPUT, NONE);
+ PIN_SLP(gpm2-2, OUT0, NONE);
+ PIN_SLP(gpm2-3, OUT0, DOWN);
+ PIN_SLP(gpm2-4, INPUT, DOWN);
+
+ PIN_SLP(gpm3-0, PREV, NONE);
+ PIN_SLP(gpm3-1, PREV, NONE);
+ PIN_SLP(gpm3-2, PREV, NONE);
+ PIN_SLP(gpm3-3, OUT1, NONE);
+ PIN_SLP(gpm3-4, OUT0, DOWN);
+ PIN_SLP(gpm3-5, PREV, NONE);
+ PIN_SLP(gpm3-6, PREV, NONE);
+ PIN_SLP(gpm3-7, OUT0, NONE);
+
+ PIN_SLP(gpm4-0, INPUT, NONE);
+ PIN_SLP(gpm4-1, INPUT, NONE);
+ PIN_SLP(gpm4-2, INPUT, DOWN);
+ PIN_SLP(gpm4-3, INPUT, DOWN);
+ PIN_SLP(gpm4-4, PREV, NONE);
+ PIN_SLP(gpm4-5, OUT0, NONE);
+ PIN_SLP(gpm4-6, OUT0, NONE);
+ PIN_SLP(gpm4-7, INPUT, DOWN);
+
+ PIN_SLP(gpy0-0, INPUT, DOWN);
+ PIN_SLP(gpy0-1, INPUT, DOWN);
+ PIN_SLP(gpy0-2, INPUT, NONE);
+ PIN_SLP(gpy0-3, INPUT, NONE);
+ PIN_SLP(gpy0-4, INPUT, NONE);
+ PIN_SLP(gpy0-5, INPUT, NONE);
+
+ PIN_SLP(gpy1-0, INPUT, DOWN);
+ PIN_SLP(gpy1-1, INPUT, DOWN);
+ PIN_SLP(gpy1-2, INPUT, DOWN);
+ PIN_SLP(gpy1-3, INPUT, DOWN);
+
+ PIN_SLP(gpy2-0, PREV, NONE);
+ PIN_SLP(gpy2-1, INPUT, DOWN);
+ PIN_SLP(gpy2-2, INPUT, NONE);
+ PIN_SLP(gpy2-3, INPUT, NONE);
+ PIN_SLP(gpy2-4, INPUT, NONE);
+ PIN_SLP(gpy2-5, INPUT, NONE);
+
+ PIN_SLP(gpy3-0, INPUT, DOWN);
+ PIN_SLP(gpy3-1, INPUT, DOWN);
+ PIN_SLP(gpy3-2, INPUT, DOWN);
+ PIN_SLP(gpy3-3, INPUT, DOWN);
+ PIN_SLP(gpy3-4, INPUT, DOWN);
+ PIN_SLP(gpy3-5, INPUT, DOWN);
+ PIN_SLP(gpy3-6, INPUT, DOWN);
+ PIN_SLP(gpy3-7, INPUT, DOWN);
+
+ PIN_SLP(gpy4-0, INPUT, DOWN);
+ PIN_SLP(gpy4-1, INPUT, DOWN);
+ PIN_SLP(gpy4-2, INPUT, DOWN);
+ PIN_SLP(gpy4-3, INPUT, DOWN);
+ PIN_SLP(gpy4-4, INPUT, DOWN);
+ PIN_SLP(gpy4-5, INPUT, DOWN);
+ PIN_SLP(gpy4-6, INPUT, DOWN);
+ PIN_SLP(gpy4-7, INPUT, DOWN);
+
+ PIN_SLP(gpy5-0, INPUT, DOWN);
+ PIN_SLP(gpy5-1, INPUT, DOWN);
+ PIN_SLP(gpy5-2, INPUT, DOWN);
+ PIN_SLP(gpy5-3, INPUT, DOWN);
+ PIN_SLP(gpy5-4, INPUT, DOWN);
+ PIN_SLP(gpy5-5, INPUT, DOWN);
+ PIN_SLP(gpy5-6, INPUT, DOWN);
+ PIN_SLP(gpy5-7, INPUT, DOWN);
+
+ PIN_SLP(gpy6-0, INPUT, DOWN);
+ PIN_SLP(gpy6-1, INPUT, DOWN);
+ PIN_SLP(gpy6-2, INPUT, DOWN);
+ PIN_SLP(gpy6-3, INPUT, DOWN);
+ PIN_SLP(gpy6-4, INPUT, DOWN);
+ PIN_SLP(gpy6-5, INPUT, DOWN);
+ PIN_SLP(gpy6-6, INPUT, DOWN);
+ PIN_SLP(gpy6-7, INPUT, DOWN);
+ };
+};
+
+&pinctrl_2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sleep2>;
+
+ sleep2: sleep-states {
+ PIN_SLP(gpz-0, INPUT, DOWN);
+ PIN_SLP(gpz-1, INPUT, DOWN);
+ PIN_SLP(gpz-2, INPUT, DOWN);
+ PIN_SLP(gpz-3, INPUT, DOWN);
+ PIN_SLP(gpz-4, INPUT, DOWN);
+ PIN_SLP(gpz-5, INPUT, DOWN);
+ PIN_SLP(gpz-6, INPUT, DOWN);
+ };
+};
+
+&pinctrl_3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sleep3>;
+
+ sleep3: sleep-states {
+ PIN_SLP(gpv0-0, INPUT, DOWN);
+ PIN_SLP(gpv0-1, INPUT, DOWN);
+ PIN_SLP(gpv0-2, INPUT, DOWN);
+ PIN_SLP(gpv0-3, INPUT, DOWN);
+ PIN_SLP(gpv0-4, INPUT, DOWN);
+ PIN_SLP(gpv0-5, INPUT, DOWN);
+ PIN_SLP(gpv0-6, INPUT, DOWN);
+ PIN_SLP(gpv0-7, INPUT, DOWN);
+
+ PIN_SLP(gpv1-0, INPUT, DOWN);
+ PIN_SLP(gpv1-1, INPUT, DOWN);
+ PIN_SLP(gpv1-2, INPUT, DOWN);
+ PIN_SLP(gpv1-3, INPUT, DOWN);
+ PIN_SLP(gpv1-4, INPUT, DOWN);
+ PIN_SLP(gpv1-5, INPUT, DOWN);
+ PIN_SLP(gpv1-6, INPUT, DOWN);
+ PIN_SLP(gpv1-7, INPUT, DOWN);
+
+ PIN_SLP(gpv2-0, INPUT, DOWN);
+ PIN_SLP(gpv2-1, INPUT, DOWN);
+ PIN_SLP(gpv2-2, INPUT, DOWN);
+ PIN_SLP(gpv2-3, INPUT, DOWN);
+ PIN_SLP(gpv2-4, INPUT, DOWN);
+ PIN_SLP(gpv2-5, INPUT, DOWN);
+ PIN_SLP(gpv2-6, INPUT, DOWN);
+ PIN_SLP(gpv2-7, INPUT, DOWN);
+
+ PIN_SLP(gpv3-0, INPUT, DOWN);
+ PIN_SLP(gpv3-1, INPUT, DOWN);
+ PIN_SLP(gpv3-2, INPUT, DOWN);
+ PIN_SLP(gpv3-3, INPUT, DOWN);
+ PIN_SLP(gpv3-4, INPUT, DOWN);
+ PIN_SLP(gpv3-5, INPUT, DOWN);
+ PIN_SLP(gpv3-6, INPUT, DOWN);
+ PIN_SLP(gpv3-7, INPUT, DOWN);
+
+ PIN_SLP(gpv4-0, INPUT, DOWN);
+ PIN_SLP(gpv4-1, INPUT, DOWN);
+ };
+};
+
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_XUSBXTI>;
+};
+
+&rtc {
+ clocks = <&clock CLK_RTC>, <&max77686 MAX77686_CLK_AP>;
+ clock-names = "rtc", "rtc_src";
+ status = "okay";
+};
+
+&sdhci_2 {
+ bus-width = <4>;
+ cd-gpios = <&gpx3 4 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sdhci2_cd>;
+ pinctrl-names = "default";
+ vmmc-supply = <&ldo21_reg>;
+ status = "okay";
+};
+
+&sdhci_3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ non-removable;
+ bus-width = <4>;
+ mmc-pwrseq = <&wlan_pwrseq>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd3_clk &sd3_cmd &sd3_wifi>;
+ status = "okay";
+
+ wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <0x1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake>;
+ interrupt-parent = <&gpx2>;
+ interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "host-wake";
+ };
+};
+
+&serial_0 {
+ pinctrl-0 = <&uart0_data &uart0_fctl>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ pinctrl-0 = <&bt_shutdown &bt_device_wakeup &bt_host_wakeup>;
+ pinctrl-names = "default";
+
+ max-speed = <2000000>;
+ shutdown-gpios = <&gpl0 6 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpx3 1 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ clocks = <&max77686 MAX77686_CLK_PMIC>;
+ clock-names = "lpo";
+ };
+};
+
+&serial_2 {
+ pinctrl-0 = <&uart_sel>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&tmu {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts b/arch/arm/boot/dts/exynos4412-smdk4412.dts
index 4997120..cc99b95 100644
--- a/arch/arm/boot/dts/exynos4412-smdk4412.dts
+++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
@@ -71,61 +71,61 @@ &keypad {
pinctrl-names = "default";
status = "okay";
- key_1 {
+ key-1 {
keypad,row = <1>;
keypad,column = <3>;
linux,code = <2>;
};
- key_2 {
+ key-2 {
keypad,row = <1>;
keypad,column = <4>;
linux,code = <3>;
};
- key_3 {
+ key-3 {
keypad,row = <1>;
keypad,column = <5>;
linux,code = <4>;
};
- key_4 {
+ key-4 {
keypad,row = <1>;
keypad,column = <6>;
linux,code = <5>;
};
- key_5 {
+ key-5 {
keypad,row = <1>;
keypad,column = <7>;
linux,code = <6>;
};
- key_A {
+ key-A {
keypad,row = <2>;
keypad,column = <6>;
linux,code = <30>;
};
- key_B {
+ key-B {
keypad,row = <2>;
keypad,column = <7>;
linux,code = <48>;
};
- key_C {
+ key-C {
keypad,row = <0>;
keypad,column = <5>;
linux,code = <46>;
};
- key_D {
+ key-D {
keypad,row = <2>;
keypad,column = <5>;
linux,code = <32>;
};
- key_E {
+ key-E {
keypad,row = <0>;
keypad,column = <7>;
linux,code = <18>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index e76881d..a142fe8 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -274,7 +274,6 @@ adc: adc@126c0000 {
clocks = <&clock CLK_TSADC>;
clock-names = "adc";
#io-channel-cells = <1>;
- io-channel-ranges;
samsung,syscon-phandle = <&pmu_system_controller>;
status = "disabled";
};
@@ -378,15 +377,17 @@ sysmmu_fimc_lite1: sysmmu@123c0000 {
#iommu-cells = <0>;
};
- bus_dmc: bus_dmc {
+ 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>;
status = "disabled";
};
- bus_acp: bus_acp {
+ bus_acp: bus-acp {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_ACP>;
clock-names = "bus";
@@ -394,7 +395,7 @@ bus_acp: bus_acp {
status = "disabled";
};
- bus_c2c: bus_c2c {
+ bus_c2c: bus-c2c {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_C2C>;
clock-names = "bus";
@@ -404,7 +405,6 @@ bus_c2c: bus_c2c {
bus_dmc_opp_table: opp-table1 {
compatible = "operating-points-v2";
- opp-shared;
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
@@ -431,7 +431,6 @@ opp-400000000 {
bus_acp_opp_table: opp-table2 {
compatible = "operating-points-v2";
- opp-shared;
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
@@ -447,15 +446,17 @@ opp-267000000 {
};
};
- bus_leftbus: bus_leftbus {
+ bus_leftbus: bus-leftbus {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
+ interconnects = <&bus_dmc>;
+ #interconnect-cells = <0>;
status = "disabled";
};
- bus_rightbus: bus_rightbus {
+ bus_rightbus: bus-rightbus {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_GDR>;
clock-names = "bus";
@@ -463,15 +464,17 @@ bus_rightbus: bus_rightbus {
status = "disabled";
};
- bus_display: bus_display {
+ bus_display: bus-display {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK160>;
clock-names = "bus";
operating-points-v2 = <&bus_display_opp_table>;
+ interconnects = <&bus_leftbus &bus_dmc>;
+ #interconnect-cells = <0>;
status = "disabled";
};
- bus_fsys: bus_fsys {
+ bus_fsys: bus-fsys {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK133>;
clock-names = "bus";
@@ -479,7 +482,7 @@ bus_fsys: bus_fsys {
status = "disabled";
};
- bus_peri: bus_peri {
+ bus_peri: bus-peri {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK100>;
clock-names = "bus";
@@ -487,7 +490,7 @@ bus_peri: bus_peri {
status = "disabled";
};
- bus_mfc: bus_mfc {
+ bus_mfc: bus-mfc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_SCLK_MFC>;
clock-names = "bus";
@@ -497,7 +500,6 @@ bus_mfc: bus_mfc {
bus_leftbus_opp_table: opp-table3 {
compatible = "operating-points-v2";
- opp-shared;
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
@@ -520,7 +522,6 @@ opp-200000000 {
bus_display_opp_table: opp-table4 {
compatible = "operating-points-v2";
- opp-shared;
opp-160000000 {
opp-hz = /bits/ 64 <160000000>;
@@ -532,7 +533,6 @@ opp-200000000 {
bus_fsys_opp_table: opp-table5 {
compatible = "operating-points-v2";
- opp-shared;
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
@@ -544,7 +544,6 @@ opp-134000000 {
bus_peri_opp_table: opp-table6 {
compatible = "operating-points-v2";
- opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
@@ -773,6 +772,7 @@ &mixer {
clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
<&clock CLK_SCLK_HDMI>, <&clock CLK_VP>;
+ interconnects = <&bus_display &bus_dmc>;
};
&pmu {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 79546f1..a161f623 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -27,7 +27,7 @@ chosen {
stdout-path = "serial2:115200n8";
};
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
menu {
@@ -211,7 +211,7 @@ &i2c_0 {
samsung,i2c-max-bus-freq = <20000>;
samsung,i2c-slave-addr = <0x66>;
- s5m8767_pmic@66 {
+ pmic@66 {
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
interrupt-parent = <&gpx3>;
@@ -511,7 +511,7 @@ buck9_reg: BUCK9 {
&i2c_3 {
status = "okay";
- wm1811: codec@1a {
+ wm1811: audio-codec@1a {
compatible = "wlf,wm1811";
reg = <0x1a>;
clocks = <&i2s0 CLK_I2S_CDCLK>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 186790f..8b5a79a 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -290,7 +290,7 @@ eeprom@51 {
reg = <0x51>;
};
- wm8994: wm8994@1a {
+ wm8994: audio-codec@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
@@ -385,7 +385,7 @@ &spi_1 {
status = "okay";
cs-gpios = <&gpa2 5 GPIO_ACTIVE_HIGH>;
- w25q80bw@0 {
+ flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "w25x80";
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index c952a61..6635f61 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -217,7 +217,7 @@ panel_in: endpoint {
};
};
- mmc3_pwrseq: mmc3_pwrseq {
+ mmc3_pwrseq: mmc3-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpx0 2 GPIO_ACTIVE_LOW>, /* WIFI_RSTn */
<&gpx0 1 GPIO_ACTIVE_LOW>; /* WIFI_EN */
@@ -289,7 +289,7 @@ &i2c_0 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
- max77686: max77686@9 {
+ max77686: pmic@9 {
compatible = "maxim,max77686";
interrupt-parent = <&gpx3>;
interrupts = <2 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-rev5.dts b/arch/arm/boot/dts/exynos5250-snow-rev5.dts
index 7cbfc6f..0822b77 100644
--- a/arch/arm/boot/dts/exynos5250-snow-rev5.dts
+++ b/arch/arm/boot/dts/exynos5250-snow-rev5.dts
@@ -32,7 +32,7 @@ codec {
};
&i2c_7 {
- max98090: codec@10 {
+ max98090: audio-codec@10 {
compatible = "maxim,max98090";
reg = <0x10>;
interrupts = <4 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 75fdc5e..9946dce 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -30,7 +30,7 @@ codec {
};
&i2c_7 {
- max98095: codec@11 {
+ max98095: audio-codec@11 {
compatible = "maxim,max98095";
reg = <0x11>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index a92ade3..9d2baea 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -105,7 +105,7 @@ &i2c_0 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
- s5m8767-pmic@66 {
+ pmic@66 {
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
interrupt-parent = <&gpx3>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index bd2d883..2ea2caa 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -70,7 +70,7 @@ cpu1: cpu@1 {
};
};
- cpu0_opp_table: opp_table0 {
+ cpu0_opp_table: opp-table0 {
compatible = "operating-points-v2";
opp-shared;
@@ -635,8 +635,8 @@ usb_dwc3 {
#size-cells = <1>;
ranges;
- usbdrd_dwc3: dwc3@12000000 {
- compatible = "synopsys,dwc3";
+ usbdrd_dwc3: usb@12000000 {
+ compatible = "snps,dwc3";
reg = <0x12000000 0x10000>;
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
@@ -844,7 +844,6 @@ adc: adc@12d10000 {
clocks = <&clock CLK_ADC>;
clock-names = "adc";
#io-channel-cells = <1>;
- io-channel-ranges;
samsung,syscon-phandle = <&pmu_system_controller>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index 75b4150..949c072 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -19,6 +19,10 @@ / {
model = "Hardkernel Odroid XU";
compatible = "hardkernel,odroid-xu", "samsung,exynos5410", "samsung,exynos5";
+ aliases {
+ ethernet = ðernet;
+ };
+
memory@40000000 {
device_type = "memory";
reg = <0x40000000 0x7ea00000>;
@@ -327,6 +331,8 @@ ldo7_reg: LDO7 {
regulator-name = "vddq_lcd";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+ /* Supplies also GPK and GPJ */
+ regulator-always-on;
};
ldo8_reg: LDO8 {
@@ -498,7 +504,7 @@ ldo35_reg: LDO35 {
&i2c_1 {
status = "okay";
- max98090: max98090@10 {
+ max98090: audio-codec@10 {
compatible = "maxim,max98090";
reg = <0x10>;
interrupt-parent = <&gpj3>;
@@ -636,12 +642,22 @@ &tmu_cpu3 {
vtmu-supply = <&ldo10_reg>;
};
+&usb3_0_oc {
+ /* External pull up */
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+};
+
+&usb3_1_oc {
+ /* External pull up */
+ samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
+};
+
&usbdrd_dwc3_0 {
- dr_mode = "host";
+ dr_mode = "peripheral";
};
&usbdrd_dwc3_1 {
- dr_mode = "peripheral";
+ dr_mode = "host";
};
&usbdrd3_0 {
@@ -653,3 +669,14 @@ &usbdrd3_1 {
vdd33-supply = <&ldo12_reg>;
vdd10-supply = <&ldo15_reg>;
};
+
+&usbhost2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@2 {
+ compatible = "usb0424,9730";
+ reg = <2>;
+ local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5410-pinctrl.dtsi b/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
index e5d0a2a..d0aa184 100644
--- a/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5410-pinctrl.dtsi
@@ -560,6 +560,34 @@ gpk3: gpk3 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+ usb3_1_oc: usb3-1-oc {
+ samsung,pins = "gpk2-4", "gpk2-5";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
+ };
+
+ usb3_1_vbusctrl: usb3-1-vbusctrl {
+ samsung,pins = "gpk2-6", "gpk2-7";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
+ };
+
+ usb3_0_oc: usb3-0-oc {
+ samsung,pins = "gpk3-0", "gpk3-1";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
+ samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
+ };
+
+ usb3_0_vbusctrl: usb3-0-vbusctrl {
+ samsung,pins = "gpk3-2", "gpk3-3";
+ samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
+ samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
+ samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
+ };
};
&pinctrl_2 {
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 60a8768..584ce62 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -390,6 +390,8 @@ &trng {
&usbdrd3_0 {
clocks = <&clock CLK_USBD300>;
clock-names = "usbdrd30";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb3_0_oc>, <&usb3_0_vbusctrl>;
};
&usbdrd_phy0 {
@@ -401,6 +403,8 @@ &usbdrd_phy0 {
&usbdrd3_1 {
clocks = <&clock CLK_USBD301>;
clock-names = "usbdrd30";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb3_1_oc>, <&usb3_1_vbusctrl>;
};
&usbdrd_dwc3_1 {
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index dd7f838..bf457d0 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -39,7 +39,7 @@ oscclk {
};
};
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
wakeup {
@@ -344,7 +344,7 @@ &hdmi {
&hsi2c_4 {
status = "okay";
- s2mps11_pmic@66 {
+ pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 2bcbdf8..315b3dc 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -138,7 +138,7 @@ panel_in: endpoint {
};
};
- mmc1_pwrseq: mmc1_pwrseq {
+ mmc1_pwrseq: mmc1-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpx0 0 GPIO_ACTIVE_LOW>; /* WIFI_EN */
clocks = <&max77802 MAX77802_CLK_32K_CP>;
@@ -205,7 +205,7 @@ &hsi2c_4 {
status = "okay";
clock-frequency = <400000>;
- max77802: max77802-pmic@9 {
+ max77802: pmic@9 {
compatible = "maxim,max77802";
interrupt-parent = <&gpx3>;
interrupts = <1 IRQ_TYPE_NONE>;
@@ -615,7 +615,7 @@ &hsi2c_7 {
status = "okay";
clock-frequency = <400000>;
- max98090: codec@10 {
+ max98090: audio-codec@10 {
compatible = "maxim,max98090";
reg = <0x10>;
interrupts = <2 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 4e49d8095b..d506da9 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -129,7 +129,7 @@ &hdmi {
&hsi2c_4 {
status = "okay";
- s2mps11_pmic@66 {
+ pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 83580f0..e23e8ff 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -42,7 +42,7 @@ aliases {
* by exynos5420-cpus.dtsi or exynos5422-cpus.dtsi.
*/
- cluster_a15_opp_table: opp_table0 {
+ cluster_a15_opp_table: opp-table0 {
compatible = "operating-points-v2";
opp-shared;
@@ -108,7 +108,7 @@ opp-700000000 {
};
};
- cluster_a7_opp_table: opp_table1 {
+ cluster_a7_opp_table: opp-table1 {
compatible = "operating-points-v2";
opp-shared;
@@ -240,9 +240,6 @@ mmc_2: mmc@12220000 {
dmc: memory-controller@10c20000 {
compatible = "samsung,exynos5422-dmc";
reg = <0x10c20000 0x10000>, <0x10c30000 0x10000>;
- interrupt-parent = <&combiner>;
- interrupts = <16 0>, <16 1>;
- interrupt-names = "drex_0", "drex_1";
clocks = <&clock CLK_FOUT_SPLL>,
<&clock CLK_MOUT_SCLK_SPLL>,
<&clock CLK_FF_DOUT_SPLL2>,
@@ -1080,112 +1077,112 @@ sysmmu_fimd1_1: sysmmu@14680000 {
#iommu-cells = <0>;
};
- bus_wcore: bus_wcore {
+ bus_wcore: bus-wcore {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK400_WCORE>;
clock-names = "bus";
status = "disabled";
};
- bus_noc: bus_noc {
+ bus_noc: bus-noc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK100_NOC>;
clock-names = "bus";
status = "disabled";
};
- bus_fsys_apb: bus_fsys_apb {
+ bus_fsys_apb: bus-fsys-apb {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_PCLK200_FSYS>;
clock-names = "bus";
status = "disabled";
};
- bus_fsys: bus_fsys {
+ bus_fsys: bus-fsys {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK200_FSYS>;
clock-names = "bus";
status = "disabled";
};
- bus_fsys2: bus_fsys2 {
+ bus_fsys2: bus-fsys2 {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK200_FSYS2>;
clock-names = "bus";
status = "disabled";
};
- bus_mfc: bus_mfc {
+ bus_mfc: bus-mfc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK333>;
clock-names = "bus";
status = "disabled";
};
- bus_gen: bus_gen {
+ bus_gen: bus-gen {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK266>;
clock-names = "bus";
status = "disabled";
};
- bus_peri: bus_peri {
+ bus_peri: bus-peri {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK66>;
clock-names = "bus";
status = "disabled";
};
- bus_g2d: bus_g2d {
+ bus_g2d: bus-g2d {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK333_G2D>;
clock-names = "bus";
status = "disabled";
};
- bus_g2d_acp: bus_g2d_acp {
+ bus_g2d_acp: bus-g2d-acp {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK266_G2D>;
clock-names = "bus";
status = "disabled";
};
- bus_jpeg: bus_jpeg {
+ bus_jpeg: bus-jpeg {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK300_JPEG>;
clock-names = "bus";
status = "disabled";
};
- bus_jpeg_apb: bus_jpeg_apb {
+ bus_jpeg_apb: bus-jpeg-apb {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK166>;
clock-names = "bus";
status = "disabled";
};
- bus_disp1_fimd: bus_disp1_fimd {
+ bus_disp1_fimd: bus-disp1-fimd {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK300_DISP1>;
clock-names = "bus";
status = "disabled";
};
- bus_disp1: bus_disp1 {
+ bus_disp1: bus-disp1 {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK400_DISP1>;
clock-names = "bus";
status = "disabled";
};
- bus_gscl_scaler: bus_gscl_scaler {
+ bus_gscl_scaler: bus-gscl-scaler {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK300_GSCL>;
clock-names = "bus";
status = "disabled";
};
- bus_mscl: bus_mscl {
+ bus_mscl: bus-mscl {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DOUT_ACLK400_MSCL>;
clock-names = "bus";
diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index b1cf941..d0df560 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -35,7 +35,7 @@ oscclk {
};
};
- bus_wcore_opp_table: opp_table2 {
+ bus_wcore_opp_table: opp-table2 {
compatible = "operating-points-v2";
/* derived from 532MHz MPLL */
@@ -61,7 +61,7 @@ opp04 {
};
};
- bus_noc_opp_table: opp_table3 {
+ bus_noc_opp_table: opp-table3 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -79,7 +79,7 @@ opp03 {
};
};
- bus_fsys_apb_opp_table: opp_table4 {
+ bus_fsys_apb_opp_table: opp-table4 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -91,7 +91,7 @@ opp01 {
};
};
- bus_fsys2_opp_table: opp_table5 {
+ bus_fsys2_opp_table: opp-table5 {
compatible = "operating-points-v2";
/* derived from 600MHz DPLL */
@@ -106,7 +106,7 @@ opp02 {
};
};
- bus_mfc_opp_table: opp_table6 {
+ bus_mfc_opp_table: opp-table6 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -127,7 +127,7 @@ opp04 {
};
};
- bus_gen_opp_table: opp_table7 {
+ bus_gen_opp_table: opp-table7 {
compatible = "operating-points-v2";
/* derived from 532MHz MPLL */
@@ -145,7 +145,7 @@ opp03 {
};
};
- bus_peri_opp_table: opp_table8 {
+ bus_peri_opp_table: opp-table8 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -154,7 +154,7 @@ opp00 {
};
};
- bus_g2d_opp_table: opp_table9 {
+ bus_g2d_opp_table: opp-table9 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -175,7 +175,7 @@ opp04 {
};
};
- bus_g2d_acp_opp_table: opp_table10 {
+ bus_g2d_acp_opp_table: opp-table10 {
compatible = "operating-points-v2";
/* derived from 532MHz MPLL */
@@ -193,7 +193,7 @@ opp03 {
};
};
- bus_jpeg_opp_table: opp_table11 {
+ bus_jpeg_opp_table: opp-table11 {
compatible = "operating-points-v2";
/* derived from 600MHz DPLL */
@@ -211,7 +211,7 @@ opp03 {
};
};
- bus_jpeg_apb_opp_table: opp_table12 {
+ bus_jpeg_apb_opp_table: opp-table12 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -229,7 +229,7 @@ opp03 {
};
};
- bus_disp1_fimd_opp_table: opp_table13 {
+ bus_disp1_fimd_opp_table: opp-table13 {
compatible = "operating-points-v2";
/* derived from 600MHz DPLL */
@@ -241,7 +241,7 @@ opp01 {
};
};
- bus_disp1_opp_table: opp_table14 {
+ bus_disp1_opp_table: opp-table14 {
compatible = "operating-points-v2";
/* derived from 600MHz DPLL */
@@ -256,7 +256,7 @@ opp02 {
};
};
- bus_gscl_opp_table: opp_table15 {
+ bus_gscl_opp_table: opp-table15 {
compatible = "operating-points-v2";
/* derived from 600MHz DPLL */
@@ -271,7 +271,7 @@ opp02 {
};
};
- bus_mscl_opp_table: opp_table16 {
+ bus_mscl_opp_table: opp-table16 {
compatible = "operating-points-v2";
/* derived from 666MHz CPLL */
@@ -292,7 +292,7 @@ opp04 {
};
};
- dmc_opp_table: opp_table17 {
+ dmc_opp_table: opp-table17 {
compatible = "operating-points-v2";
opp00 {
@@ -503,7 +503,7 @@ &dmc {
&hsi2c_4 {
status = "okay";
- s2mps11_pmic@66 {
+ pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
samsung,s2mps11-acokb-ground;
diff --git a/arch/arm/boot/dts/exynos5422-odroidhc1.dts b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
index 8126592..20c222b 100644
--- a/arch/arm/boot/dts/exynos5422-odroidhc1.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
@@ -15,10 +15,10 @@ / {
compatible = "hardkernel,odroid-hc1", "samsung,exynos5800", \
"samsung,exynos5";
- pwmleds {
+ led-controller {
compatible = "pwm-leds";
- blueled {
+ led-1 {
label = "blue:heartbeat";
pwms = <&pwm 2 2000000 0>;
pwm-names = "pwm2";
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
index b5ec4f4..86b96f97 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi
@@ -40,7 +40,7 @@ codec {
&hsi2c_5 {
status = "okay";
- max98090: max98090@10 {
+ max98090: audio-codec@10 {
compatible = "maxim,max98090";
reg = <0x10>;
interrupt-parent = <&gpx3>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 5da2d81..e35af40 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -13,12 +13,12 @@
#include "exynos5422-odroid-core.dtsi"
/ {
- gpio_keys {
+ gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&power_key>;
- power_key {
+ power-key {
/*
* The power button (SW2) is connected to the PWRON
* pin (active high) of the S2MPS11 PMIC, which acts
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
index 98feeca..62c5928 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
@@ -16,6 +16,10 @@
/ {
model = "Hardkernel Odroid XU3 Lite";
compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
+
+ aliases {
+ ethernet = ðernet;
+ };
};
&arm_a7_pmu {
@@ -103,3 +107,21 @@ &pwm {
&usbdrd_dwc3_1 {
dr_mode = "peripheral";
};
+
+&usbhost2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb0424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <1>;
+ local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index db0bc17..cecaeb6 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -15,34 +15,38 @@
/ {
model = "Hardkernel Odroid XU3";
compatible = "hardkernel,odroid-xu3", "samsung,exynos5800", "samsung,exynos5";
+
+ aliases {
+ ethernet = ðernet;
+ };
};
&i2c_0 {
status = "okay";
/* A15 cluster: VDD_ARM */
- ina231@40 {
+ power-sensor@40 {
compatible = "ti,ina231";
reg = <0x40>;
shunt-resistor = <10000>;
};
/* memory: VDD_MEM */
- ina231@41 {
+ power-sensor@41 {
compatible = "ti,ina231";
reg = <0x41>;
shunt-resistor = <10000>;
};
/* GPU: VDD_G3D */
- ina231@44 {
+ power-sensor@44 {
compatible = "ti,ina231";
reg = <0x44>;
shunt-resistor = <10000>;
};
/* A7 cluster: VDD_KFC */
- ina231@45 {
+ power-sensor@45 {
compatible = "ti,ina231";
reg = <0x45>;
shunt-resistor = <10000>;
@@ -70,3 +74,21 @@ &pwm {
&usbdrd_dwc3_1 {
dr_mode = "peripheral";
};
+
+&usbhost2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb0424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb0424,ec00";
+ reg = <1>;
+ local-mac-address = [00 00 00 00 00 00]; /* Filled in by a bootloader */
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index ddd55d3..ede7822 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -17,10 +17,10 @@ / {
compatible = "hardkernel,odroid-xu4", "samsung,exynos5800", \
"samsung,exynos5";
- pwmleds {
+ led-controller {
compatible = "pwm-leds";
- blueled {
+ led-1 {
label = "blue:heartbeat";
pwms = <&pwm 2 2000000 0>;
pwm-names = "pwm2";
diff --git a/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi b/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
index 56acd83..2fc3e86 100644
--- a/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
+++ b/arch/arm/boot/dts/exynos54xx-odroidxu-leds.dtsi
@@ -11,10 +11,10 @@
#include <dt-bindings/gpio/gpio.h>
/ {
- pwmleds {
+ led-controller-1 {
compatible = "pwm-leds";
- greenled {
+ led-1 {
label = "green:mmc0";
pwms = <&pwm 1 2000000 0>;
pwm-names = "pwm1";
@@ -26,7 +26,7 @@ greenled {
linux,default-trigger = "mmc0";
};
- blueled {
+ led-2 {
label = "blue:heartbeat";
pwms = <&pwm 2 2000000 0>;
pwm-names = "pwm2";
@@ -35,9 +35,10 @@ blueled {
};
};
- gpioleds {
+ led-controller-2 {
compatible = "gpio-leds";
- redled {
+
+ led-3 {
label = "red:microSD";
gpios = <&gpx2 3 GPIO_ACTIVE_HIGH>;
default-state = "off";
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index 8aa5117..fe9d34c 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -101,7 +101,6 @@ adc: adc@12d10000 {
reg = <0x12d10000 0x100>;
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
#io-channel-cells = <1>;
- io-channel-ranges;
status = "disabled";
};
@@ -148,7 +147,7 @@ usbdrd3_0: usb3-0 {
#size-cells = <1>;
ranges;
- usbdrd_dwc3_0: dwc3@12000000 {
+ usbdrd_dwc3_0: usb@12000000 {
compatible = "snps,dwc3";
reg = <0x12000000 0x10000>;
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
@@ -170,7 +169,7 @@ usbdrd3_1: usb3-1 {
#size-cells = <1>;
ranges;
- usbdrd_dwc3_1: dwc3@12400000 {
+ usbdrd_dwc3_1: usb@12400000 {
compatible = "snps,dwc3";
reg = <0x12400000 0x10000>;
phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 60ab0ef..0ce3443 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -138,7 +138,7 @@ panel_in: endpoint {
};
};
- mmc1_pwrseq: mmc1_pwrseq {
+ mmc1_pwrseq: mmc1-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpx0 0 GPIO_ACTIVE_LOW>; /* WIFI_EN */
clocks = <&max77802 MAX77802_CLK_32K_CP>;
@@ -214,7 +214,7 @@ &hsi2c_4 {
status = "okay";
clock-frequency = <400000>;
- max77802: max77802-pmic@9 {
+ max77802: pmic@9 {
compatible = "maxim,max77802";
interrupt-parent = <&gpx3>;
interrupts = <1 IRQ_TYPE_NONE>;
diff --git a/arch/arm/boot/dts/hi3519-demb.dts b/arch/arm/boot/dts/hi3519-demb.dts
index 64f8ed1..f473fa2 100644
--- a/arch/arm/boot/dts/hi3519-demb.dts
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -14,7 +14,7 @@ aliases {
serial0 = &uart0;
};
- memory {
+ memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
index 410409a..c524c85 100644
--- a/arch/arm/boot/dts/hi3519.dtsi
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -52,8 +52,8 @@ uart0: serial@12100000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12100000 0x1000>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_UART0_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_UART0_CLK>, <&crg HI3519_UART0_CLK>;
+ clock-names = "uartclk", "apb_pclk";
status = "disable";
};
@@ -61,8 +61,8 @@ uart1: serial@12101000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12101000 0x1000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_UART1_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_UART1_CLK>, <&crg HI3519_UART1_CLK>;
+ clock-names = "uartclk", "apb_pclk";
status = "disable";
};
@@ -70,8 +70,8 @@ uart2: serial@12102000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12102000 0x1000>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_UART2_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_UART2_CLK>, <&crg HI3519_UART2_CLK>;
+ clock-names = "uartclk", "apb_pclk";
status = "disable";
};
@@ -79,8 +79,8 @@ uart3: serial@12103000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12103000 0x1000>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_UART3_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_UART3_CLK>, <&crg HI3519_UART3_CLK>;
+ clock-names = "uartclk", "apb_pclk";
status = "disable";
};
@@ -88,8 +88,8 @@ uart4: serial@12104000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12104000 0x1000>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_UART4_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_UART4_CLK>, <&crg HI3519_UART4_CLK>;
+ clock-names = "uartclk", "apb_pclk";
status = "disable";
};
@@ -127,8 +127,8 @@ spi_bus0: spi@12120000 {
compatible = "arm,pl022", "arm,primecell";
reg = <0x12120000 0x1000>;
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_SPI0_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_SPI0_CLK>, <&crg HI3519_SPI0_CLK>;
+ clock-names = "sspclk", "apb_pclk";
num-cs = <1>;
#address-cells = <1>;
#size-cells = <0>;
@@ -139,8 +139,8 @@ spi_bus1: spi@12121000 {
compatible = "arm,pl022", "arm,primecell";
reg = <0x12121000 0x1000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_SPI1_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_SPI1_CLK>, <&crg HI3519_SPI1_CLK>;
+ clock-names = "sspclk", "apb_pclk";
num-cs = <1>;
#address-cells = <1>;
#size-cells = <0>;
@@ -151,8 +151,8 @@ spi_bus2: spi@12122000 {
compatible = "arm,pl022", "arm,primecell";
reg = <0x12122000 0x1000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HI3519_SPI2_CLK>;
- clock-names = "apb_pclk";
+ clocks = <&crg HI3519_SPI2_CLK>, <&crg HI3519_SPI2_CLK>;
+ clock-names = "sspclk", "apb_pclk";
num-cs = <1>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/hi3620-hi4511.dts b/arch/arm/boot/dts/hi3620-hi4511.dts
index 8c703c3..ce356c4 100644
--- a/arch/arm/boot/dts/hi3620-hi4511.dts
+++ b/arch/arm/boot/dts/hi3620-hi4511.dts
@@ -17,46 +17,46 @@ chosen {
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@40000000 {
device_type = "memory";
reg = <0x40000000 0x20000000>;
};
- amba {
+ amba-bus {
dual_timer0: dual_timer@800000 {
status = "ok";
};
- uart0: uart@b00000 { /* console */
- pinctrl-names = "default", "idle";
+ uart0: serial@b00000 { /* console */
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&uart0_pmx_func &uart0_cfg_func>;
pinctrl-1 = <&uart0_pmx_idle &uart0_cfg_idle>;
status = "ok";
};
- uart1: uart@b01000 { /* modem */
- pinctrl-names = "default", "idle";
+ uart1: serial@b01000 { /* modem */
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&uart1_pmx_func &uart1_cfg_func>;
pinctrl-1 = <&uart1_pmx_idle &uart1_cfg_idle>;
status = "ok";
};
- uart2: uart@b02000 { /* audience */
- pinctrl-names = "default", "idle";
+ uart2: serial@b02000 { /* audience */
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&uart2_pmx_func &uart2_cfg_func>;
pinctrl-1 = <&uart2_pmx_idle &uart2_cfg_idle>;
status = "ok";
};
- uart3: uart@b03000 {
- pinctrl-names = "default", "idle";
+ uart3: serial@b03000 {
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&uart3_pmx_func &uart3_cfg_func>;
pinctrl-1 = <&uart3_pmx_idle &uart3_cfg_idle>;
status = "ok";
};
- uart4: uart@b04000 {
- pinctrl-names = "default", "idle";
+ uart4: serial@b04000 {
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&uart4_pmx_func &uart4_cfg_func>;
pinctrl-1 = <&uart4_pmx_idle &uart4_cfg_func>;
status = "ok";
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
index f683440..905900b 100644
--- a/arch/arm/boot/dts/hi3620.dtsi
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -63,7 +63,7 @@ cpu@3 {
};
};
- amba {
+ amba-bus {
#address-cells = <1>;
#size-cells = <1>;
@@ -172,48 +172,48 @@ timer5: timer@600 {
interrupts = <1 13 0xf01>;
};
- uart0: uart@b00000 {
+ uart0: serial@b00000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xb00000 0x1000>;
interrupts = <0 20 4>;
- clocks = <&clock HI3620_UARTCLK0>;
- clock-names = "apb_pclk";
+ clocks = <&clock HI3620_UARTCLK0>, <&clock HI3620_UARTCLK0>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart1: uart@b01000 {
+ uart1: serial@b01000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xb01000 0x1000>;
interrupts = <0 21 4>;
- clocks = <&clock HI3620_UARTCLK1>;
- clock-names = "apb_pclk";
+ clocks = <&clock HI3620_UARTCLK1>, <&clock HI3620_UARTCLK1>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart2: uart@b02000 {
+ uart2: serial@b02000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xb02000 0x1000>;
interrupts = <0 22 4>;
- clocks = <&clock HI3620_UARTCLK2>;
- clock-names = "apb_pclk";
+ clocks = <&clock HI3620_UARTCLK2>, <&clock HI3620_UARTCLK2>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart3: uart@b03000 {
+ uart3: serial@b03000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xb03000 0x1000>;
interrupts = <0 23 4>;
- clocks = <&clock HI3620_UARTCLK3>;
- clock-names = "apb_pclk";
+ clocks = <&clock HI3620_UARTCLK3>, <&clock HI3620_UARTCLK3>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart4: uart@b04000 {
+ uart4: serial@b04000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xb04000 0x1000>;
interrupts = <0 24 4>;
- clocks = <&clock HI3620_UARTCLK4>;
- clock-names = "apb_pclk";
+ clocks = <&clock HI3620_UARTCLK4>, <&clock HI3620_UARTCLK4>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/hip01-ca9x2.dts b/arch/arm/boot/dts/hip01-ca9x2.dts
index f05e74e..0314763 100644
--- a/arch/arm/boot/dts/hip01-ca9x2.dts
+++ b/arch/arm/boot/dts/hip01-ca9x2.dts
@@ -37,7 +37,7 @@ cpu@1 {
};
};
- memory {
+ memory@80000000 {
device_type = "memory";
reg = <0x80000000 0x80000000>;
};
diff --git a/arch/arm/boot/dts/hip01.dtsi b/arch/arm/boot/dts/hip01.dtsi
index 975d398..2a79636 100644
--- a/arch/arm/boot/dts/hip01.dtsi
+++ b/arch/arm/boot/dts/hip01.dtsi
@@ -35,47 +35,47 @@ soc {
interrupt-parent = <&gic>;
ranges = <0 0x10000000 0x20000000>;
- amba {
+ amba-bus {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges;
- uart0: uart@10001000 {
+ uart0: serial@10001000 {
compatible = "snps,dw-apb-uart";
reg = <0x10001000 0x1000>;
- clocks = <&hisi_refclk144mhz>;
- clock-names = "apb_pclk";
+ clocks = <&hisi_refclk144mhz>, <&hisi_refclk144mhz>;
+ clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
interrupts = <0 32 4>;
status = "disabled";
};
- uart1: uart@10002000 {
+ uart1: serial@10002000 {
compatible = "snps,dw-apb-uart";
reg = <0x10002000 0x1000>;
- clocks = <&hisi_refclk144mhz>;
- clock-names = "apb_pclk";
+ clocks = <&hisi_refclk144mhz>, <&hisi_refclk144mhz>;
+ clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
interrupts = <0 33 4>;
status = "disabled";
};
- uart2: uart@10003000 {
+ uart2: serial@10003000 {
compatible = "snps,dw-apb-uart";
reg = <0x10003000 0x1000>;
- clocks = <&hisi_refclk144mhz>;
- clock-names = "apb_pclk";
+ clocks = <&hisi_refclk144mhz>, <&hisi_refclk144mhz>;
+ clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
interrupts = <0 34 4>;
status = "disabled";
};
- uart3: uart@10006000 {
+ uart3: serial@10006000 {
compatible = "snps,dw-apb-uart";
reg = <0x10006000 0x1000>;
- clocks = <&hisi_refclk144mhz>;
- clock-names = "apb_pclk";
+ clocks = <&hisi_refclk144mhz>, <&hisi_refclk144mhz>;
+ clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
interrupts = <0 4 4>;
status = "disabled";
diff --git a/arch/arm/boot/dts/hip04-d01.dts b/arch/arm/boot/dts/hip04-d01.dts
index 9019e0d..f5691db 100644
--- a/arch/arm/boot/dts/hip04-d01.dts
+++ b/arch/arm/boot/dts/hip04-d01.dts
@@ -22,7 +22,7 @@ memory@0,10000000 {
};
soc {
- uart0: uart@4007000 {
+ uart0: serial@4007000 {
status = "ok";
};
};
diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi
index 555bc6b..bccf5ba 100644
--- a/arch/arm/boot/dts/hip04.dtsi
+++ b/arch/arm/boot/dts/hip04.dtsi
@@ -250,12 +250,12 @@ arm-pmu {
<0 79 4>;
};
- uart0: uart@4007000 {
+ uart0: serial@4007000 {
compatible = "snps,dw-apb-uart";
reg = <0x4007000 0x1000>;
interrupts = <0 381 4>;
- clocks = <&clk_168m>;
- clock-names = "uartclk";
+ clocks = <&clk_168m>, <&clk_168m>;
+ clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
index d55e9cd..22b122d 100644
--- a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
+++ b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
@@ -35,7 +35,7 @@ cpu@1 {
};
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x00000000 0x80000000>;
};
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index e2dbf1d..9721138 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -30,7 +30,7 @@ soc {
interrupt-parent = <&gic>;
ranges = <0 0xf8000000 0x8000000>;
- amba {
+ amba-bus {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
@@ -86,48 +86,48 @@ timer4: timer@a81000 {
status = "disabled";
};
- uart0: uart@b00000 {
+ uart0: serial@b00000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x00b00000 0x1000>;
interrupts = <0 49 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
+ clocks = <&clock HIX5HD2_FIXED_83M>, <&clock HIX5HD2_FIXED_83M>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart1: uart@6000 {
+ uart1: serial@6000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x00006000 0x1000>;
interrupts = <0 50 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
+ clocks = <&clock HIX5HD2_FIXED_83M>, <&clock HIX5HD2_FIXED_83M>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart2: uart@b02000 {
+ uart2: serial@b02000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x00b02000 0x1000>;
interrupts = <0 51 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
+ clocks = <&clock HIX5HD2_FIXED_83M>, <&clock HIX5HD2_FIXED_83M>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart3: uart@b03000 {
+ uart3: serial@b03000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x00b03000 0x1000>;
interrupts = <0 52 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
+ clocks = <&clock HIX5HD2_FIXED_83M>, <&clock HIX5HD2_FIXED_83M>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
- uart4: uart@b04000 {
+ uart4: serial@b04000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xb04000 0x1000>;
interrupts = <0 53 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
+ clocks = <&clock HIX5HD2_FIXED_83M>, <&clock HIX5HD2_FIXED_83M>;
+ clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
@@ -423,7 +423,7 @@ mmc: mmc@1830000 {
interrupts = <0 35 4>;
clocks = <&clock HIX5HD2_MMC_CIU_RST>,
<&clock HIX5HD2_MMC_BIU_CLK>;
- clock-names = "ciu", "biu";
+ clock-names = "biu", "ciu";
};
sd: mmc@1820000 {
@@ -432,7 +432,7 @@ sd: mmc@1820000 {
interrupts = <0 34 4>;
clocks = <&clock HIX5HD2_SD_CIU_RST>,
<&clock HIX5HD2_SD_BIU_CLK>;
- clock-names = "ciu","biu";
+ clock-names = "biu", "ciu";
};
gmac0: ethernet@1840000 {
@@ -453,14 +453,14 @@ gmac1: ethernet@1841000 {
status = "disabled";
};
- usb0: ehci@1890000 {
+ usb0: usb@1890000 {
compatible = "generic-ehci";
reg = <0x1890000 0x1000>;
interrupts = <0 66 4>;
clocks = <&clock HIX5HD2_USB_CLK>;
};
- usb1: ohci@1880000 {
+ usb1: usb@1880000 {
compatible = "generic-ohci";
reg = <0x1880000 0x1000>;
interrupts = <0 67 4>;
@@ -468,7 +468,7 @@ usb1: ohci@1880000 {
};
peripheral_ctrl: syscon@a20000 {
- compatible = "syscon";
+ compatible = "hisilicon,peri-subctrl", "syscon";
reg = <0xa20000 0x1000>;
};
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 1ab19f1..fdcca82 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -525,7 +525,7 @@ sdma: sdma@53fd4000 {
fsl,sdma-ram-script-name = "imx/sdma/sdma-imx25.bin";
};
- wdog@53fdc000 {
+ watchdog@53fdc000 {
compatible = "fsl,imx25-wdt", "fsl,imx21-wdt";
reg = <0x53fdc000 0x4000>;
clocks = <&clks 126>;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 7bc1327..fd525c3 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -99,7 +99,7 @@ dma: dma@10001000 {
#dma-channels = <16>;
};
- wdog: wdog@10002000 {
+ wdog: watchdog@10002000 {
compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
reg = <0x10002000 0x1000>;
interrupts = <27>;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 94dfbf5..bbe5215 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1317,7 +1317,7 @@ mac1: ethernet@800f4000 {
status = "disabled";
};
- etn_switch: switch@800f8000 {
+ eth_switch: switch@800f8000 {
reg = <0x800f8000 0x8000>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 45333f7..948d2a5 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -315,10 +315,11 @@ rtc: rtc@53fd8000 {
clock-names = "ref", "ipg";
};
- wdog: wdog@53fdc000 {
+ wdog: watchdog@53fdc000 {
compatible = "fsl,imx31-wdt", "fsl,imx21-wdt";
reg = <0x53fdc000 0x4000>;
clocks = <&clks 41>;
+ interrupts = <55>;
};
pwm: pwm@53fe0000 {
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index aba1625..98ccc81 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -294,7 +294,7 @@ sdma: sdma@53fd4000 {
fsl,sdma-ram-script-name = "imx/sdma/sdma-imx35.bin";
};
- wdog: wdog@53fdc000 {
+ wdog: watchdog@53fdc000 {
compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
reg = <0x53fdc000 0x4000>;
clocks = <&clks 74>;
diff --git a/arch/arm/boot/dts/imx50-kobo-aura.dts b/arch/arm/boot/dts/imx50-kobo-aura.dts
index a0eaf86..97cfd97 100644
--- a/arch/arm/boot/dts/imx50-kobo-aura.dts
+++ b/arch/arm/boot/dts/imx50-kobo-aura.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "imx50.dtsi"
#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
/ {
model = "Kobo Aura (N514)";
@@ -119,7 +120,14 @@ &i2c1 {
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- /* TODO: ektf2132 touch controller at 0x15 */
+ touchscreen@15 {
+ reg = <0x15>;
+ compatible = "elan,ektf2132";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ts>;
+ power-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
+ interrupts-extended = <&gpio5 13 IRQ_TYPE_EDGE_FALLING>;
+ };
};
&i2c2 {
@@ -139,7 +147,7 @@ &i2c3 {
};
&iomuxc {
- pinctrl_gpiokeys: gpiokeys {
+ pinctrl_gpiokeys: gpiokeysgrp {
fsl,pins = <
MX50_PAD_CSPI_MISO__GPIO4_10 0x0
MX50_PAD_SD2_D7__GPIO5_15 0x0
@@ -147,34 +155,34 @@ MX50_PAD_KEY_ROW0__GPIO4_1 0x0
>;
};
- pinctrl_i2c1: i2c1 {
+ pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX50_PAD_I2C1_SCL__I2C1_SCL 0x400001fd
MX50_PAD_I2C1_SDA__I2C1_SDA 0x400001fd
>;
};
- pinctrl_i2c2: i2c2 {
+ pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX50_PAD_I2C2_SCL__I2C2_SCL 0x400001fd
MX50_PAD_I2C2_SDA__I2C2_SDA 0x400001fd
>;
};
- pinctrl_i2c3: i2c3 {
+ pinctrl_i2c3: i2c3grp {
fsl,pins = <
MX50_PAD_I2C3_SCL__I2C3_SCL 0x400001fd
MX50_PAD_I2C3_SDA__I2C3_SDA 0x400001fd
>;
};
- pinctrl_leds: leds {
+ pinctrl_leds: ledsgrp {
fsl,pins = <
MX50_PAD_PWM1__GPIO6_24 0x0
>;
};
- pinctrl_sd1: sd1 {
+ pinctrl_sd1: sd1grp {
fsl,pins = <
MX50_PAD_SD1_CMD__ESDHC1_CMD 0x1e4
MX50_PAD_SD1_CLK__ESDHC1_CLK 0xd4
@@ -187,7 +195,7 @@ MX50_PAD_SD2_CD__GPIO5_17 0x0
>;
};
- pinctrl_sd2: sd2 {
+ pinctrl_sd2: sd2grp {
fsl,pins = <
MX50_PAD_SD2_CMD__ESDHC2_CMD 0x1e4
MX50_PAD_SD2_CLK__ESDHC2_CLK 0xd4
@@ -198,19 +206,19 @@ MX50_PAD_SD2_D3__ESDHC2_DAT3 0x1d4
>;
};
- pinctrl_sd2_reset: sd2-reset {
+ pinctrl_sd2_reset: sd2-resetgrp {
fsl,pins = <
MX50_PAD_ECSPI2_MOSI__GPIO4_17 0x0
>;
};
- pinctrl_sd2_vmmc: sd2-vmmc {
+ pinctrl_sd2_vmmc: sd2-vmmcgrp {
fsl,pins = <
MX50_PAD_ECSPI1_SCLK__GPIO4_12 0x0
>;
};
- pinctrl_sd3: sd3 {
+ pinctrl_sd3: sd3grp {
fsl,pins = <
MX50_PAD_SD3_CMD__ESDHC3_CMD 0x1e4
MX50_PAD_SD3_CLK__ESDHC3_CLK 0xd4
@@ -225,14 +233,21 @@ MX50_PAD_SD3_D7__ESDHC3_DAT7 0x1d4
>;
};
- pinctrl_uart2: uart2 {
+ pinctrl_ts: tsgrp {
+ fsl,pins = <
+ MX50_PAD_CSPI_MOSI__GPIO4_9 0x0
+ MX50_PAD_SD2_D5__GPIO5_13 0x0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
fsl,pins = <
MX50_PAD_UART2_TXD__UART2_TXD_MUX 0x1e4
MX50_PAD_UART2_RXD__UART2_RXD_MUX 0x1e4
>;
};
- pinctrl_usbphy: usbphy {
+ pinctrl_usbphy: usbphygrp {
fsl,pins = <
MX50_PAD_ECSPI2_SS0__GPIO4_19 0x0
>;
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index b6b2e6a..a969f33 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -267,7 +267,7 @@ gpio4: gpio@53f90000 {
<&iomuxc 20 140 11>;
};
- wdog1: wdog@53f98000 {
+ wdog1: watchdog@53f98000 {
compatible = "fsl,imx50-wdt", "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index e559ab0..ec8ca3a 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -451,7 +451,7 @@ &gpio1 {
"", "", "", "",
"", "", "", "";
- unused-sd3-wp-gpio {
+ unused-sd3-wp-hog {
/*
* See pinctrl_esdhc1 below for more details on this
*/
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 985e1be..7ebb46c 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -370,14 +370,14 @@ kpp: kpp@73f94000 {
status = "disabled";
};
- wdog1: wdog@73f98000 {
+ wdog1: watchdog@73f98000 {
compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
reg = <0x73f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
- wdog2: wdog@73f9c000 {
+ wdog2: watchdog@73f9c000 {
compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
reg = <0x73f9c000 0x4000>;
interrupts = <59>;
diff --git a/arch/arm/boot/dts/imx53-ppd.dts b/arch/arm/boot/dts/imx53-ppd.dts
index f7dcdf9..be040b6 100644
--- a/arch/arm/boot/dts/imx53-ppd.dts
+++ b/arch/arm/boot/dts/imx53-ppd.dts
@@ -176,36 +176,37 @@ pwm_bl: backlight {
power-supply = <®_3v3_lcd>;
};
- leds-brightness {
+ led-controller-1 {
compatible = "pwm-leds";
- alarm-brightness {
+ led-1 {
+ label = "alarm-brightness";
pwms = <&pwm1 0 100000>;
max-brightness = <255>;
};
};
- leds {
+ led-controller-2 {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_alarmled_pins>;
- alarm1 {
+ led-2 {
label = "alarm:red";
gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
};
- alarm2 {
+ led-3 {
label = "alarm:yellow";
gpios = <&gpio7 7 GPIO_ACTIVE_HIGH>;
};
- alarm3 {
+ led-4 {
label = "alarm:blue";
gpios = <&gpio7 8 GPIO_ACTIVE_HIGH>;
};
- alarm4 {
+ led-5 {
label = "alarm:silenced";
gpios = <&gpio7 13 GPIO_ACTIVE_HIGH>;
};
@@ -589,7 +590,7 @@ &i2c2 {
touchscreen@4b {
compatible = "atmel,maxtouch";
- reset-gpio = <&gpio5 19 GPIO_ACTIVE_HIGH>;
+ reset-gpio = <&gpio5 19 GPIO_ACTIVE_LOW>;
reg = <0x4b>;
interrupt-parent = <&gpio5>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 500eeaa..000050a 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -427,14 +427,14 @@ kpp: kpp@53f94000 {
status = "disabled";
};
- wdog1: wdog@53f98000 {
+ wdog1: watchdog@53f98000 {
compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
- wdog2: wdog@53f9c000 {
+ wdog2: watchdog@53f9c000 {
compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
reg = <0x53f9c000 0x4000>;
interrupts = <59>;
diff --git a/arch/arm/boot/dts/imx6dl-alti6p.dts b/arch/arm/boot/dts/imx6dl-alti6p.dts
new file mode 100644
index 0000000..4329b37
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-alti6p.dts
@@ -0,0 +1,564 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel <kernel@pengutronix.de>, Pengutronix
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Altesco I6P Board";
+ compatible = "alt,alti6p", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ clock_ksz8081: clock-ksz8081 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <50000000>;
+ };
+
+ i2c2-mux {
+ compatible = "i2c-mux";
+ i2c-parent = <&i2c2>;
+ mux-controls = <&i2c_mux>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ i2c4-mux {
+ compatible = "i2c-mux";
+ i2c-parent = <&i2c4>;
+ mux-controls = <&i2c_mux>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-debug1 {
+ function = LED_FUNCTION_SD;
+ gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+ };
+
+ i2c_mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2cmux>;
+
+ mux-gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>,
+ <&gpio5 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "h1-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux-ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux-pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+ <&clks IMX6QDL_CLK_ENET>,
+ <&clock_ksz8081>;
+ clock-names = "ipg", "ahb", "ptp";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio4 30 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&gpio1 {
+ gpio-line-names =
+ "", "SD1_CD", "", "USB_H1_OC", "", "", "", "",
+ "DEBUG_0", "DEBUG_1", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "ECSPI1_SS1", "", "USB_EXT1_OC", "USB_EXT1_PWR", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&gpio4 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "ETH_RESET", "", "", "BUZZER", "ETH_INTRP", "";
+};
+
+&gpio5 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "", "", "I2C_EN13", "I2C_EN24", "", "", "", "",
+ "", "", "", "", "", "AUDIO_RESET", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ ddc-i2c-bus = <&i2c1>;
+ status = "okay";
+};
+
+/* DDC */
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ sgtl5000: audio-codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+
+ /* additional i2c devices are added automatically by the boot loader */
+};
+
+&i2c2 {
+ clock-frequency = <50000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ /* external interface, device are configured from user space */
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ temperature-sensor@70 {
+ compatible = "ti,tmp103";
+ reg = <0x70>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <50000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "ac97-slave";
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_h1_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ disable-wp;
+ cap-sd-highspeed;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ no-sd;
+ no-sdio;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_can1: can1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b000
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x3008
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x1b000
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x3008
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x3008
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x3008
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ /* MX6QDL_ENET_PINGRP4 */
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b0
+ /* Phy reset */
+ MX6QDL_PAD_DISP0_DAT5__GPIO4_IO26 0x1b0b0
+ /* nINTRP */
+ MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ /* NOTE: DDC is done via I2C2, so DON'T configure DDC
+ * pins for HDMI!
+ */
+ MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001f8b1
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS3__I2C4_SDA 0x4001f8b1
+ MX6QDL_PAD_NANDF_WP_B__I2C4_SCL 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2cmux: i2cmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT16__GPIO5_IO10 0x1b0b0
+ MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x1b0b0
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x8
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1B058
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1B058
+
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__USB_OTG_OC 0x1b0b0
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17099
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10099
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17099
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17099
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17099
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17099
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17099
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17099
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17099
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17099
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x1b0b1
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts b/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
index b16603f..dfa6f64 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
@@ -46,7 +46,7 @@
/ {
model = "aristainetos2 i.MX6 Dual Lite Board 4";
- compatible = "fsl,imx6dl";
+ compatible = "abb,aristainetos2-imx6dl-4", "fsl,imx6dl";
memory@10000000 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts b/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
index abb2a1b..5e15212 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
@@ -46,7 +46,7 @@
/ {
model = "aristainetos2 i.MX6 Dual Lite Board 7";
- compatible = "fsl,imx6dl";
+ compatible = "abb,aristainetos2-imx6dl-7", "fsl,imx6dl";
memory@10000000 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos_4.dts b/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
index 5c7e853..cc861a4 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
@@ -10,7 +10,7 @@
/ {
model = "aristainetos i.MX6 Dual Lite Board 4";
- compatible = "fsl,imx6dl";
+ compatible = "abb,aristainetos-imx6dl-4", "fsl,imx6dl";
backlight {
compatible = "pwm-backlight";
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos_7.dts b/arch/arm/boot/dts/imx6dl-aristainetos_7.dts
index 4d58cb4..b6cb788 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos_7.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos_7.dts
@@ -10,7 +10,7 @@
/ {
model = "aristainetos i.MX6 Dual Lite Board 7";
- compatible = "fsl,imx6dl";
+ compatible = "abb,aristainetos-imx6dl-7", "fsl,imx6dl";
memory@10000000 {
device_type = "memory";
diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
index 65359ae..7da74e6 100644
--- a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
@@ -143,7 +143,7 @@ touchscreen@4a {
reg = <0x4a>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* SODIMM 28 */
- reset-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30 */
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>; /* SODIMM 30 */
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6dl-lanmcu.dts b/arch/arm/boot/dts/imx6dl-lanmcu.dts
new file mode 100644
index 0000000..6b6e6fc
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-lanmcu.dts
@@ -0,0 +1,470 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2019 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel <kernel@pengutronix.de>, Pengutronix
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Van der Laan LANMCU";
+ compatible = "vdl,lanmcu", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ clock_ksz8081: clock-ksz8081 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <50000000>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 5000000 0>;
+ brightness-levels = <0 1000>;
+ num-interpolated-steps = <20>;
+ default-brightness-level = <19>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <&pinctrl_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-0 {
+ label = "debug0";
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0bdh6";
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+
+ reg_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usdhc2_wifi_pwrseq: usdhc2-wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ reset-gpios = <&gpio6 10 GPIO_ACTIVE_LOW>;
+ };
+
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+ <&clks IMX6QDL_CLK_ENET>,
+ <&clock_ksz8081>;
+ clock-names = "ipg", "ahb", "ptp";
+ phy-handle = <&rgmii_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio5 23 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&gpio1 {
+ gpio-line-names =
+ "", "SD1_CD", "", "", "", "", "", "",
+ "DEBUG_0", "BL_PWM", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "ENET_LED_GREEN",
+ "", "", "", "", "", "", "", "";
+};
+
+&gpio3 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "TS_INT", "USB_OTG1_OC", "USB_OTG1_PWR", "",
+ "", "", "", "", "UART2_CTS", "", "UART3_CTS", "";
+};
+
+&gpio5 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "ENET_RST", "ENET_INT",
+ "", "", "I2C1_SDA", "I2C1_SCL", "", "", "", "";
+};
+
+&gpio6 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "", "", "WLAN_REG_ON", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&gpio7 {
+ gpio-line-names =
+ "", "", "", "", "", "", "", "",
+ "EMMC_RST", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ /* additional i2c devices are added automatically by the boot loader */
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ touchscreen@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ts_edt>;
+ interrupts-extended = <&gpio3 20 IRQ_TYPE_EDGE_FALLING>;
+
+ touchscreen-size-x = <1792>;
+ touchscreen-size-y = <1024>;
+
+ touchscreen-fuzz-x = <0>;
+ touchscreen-fuzz-y = <0>;
+
+ /* Touch screen calibration */
+ threshold = <50>;
+ gain = <5>;
+ offset = <10>;
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&ipu1_di0_disp0 {
+ remote-endpoint = <&display_in>;
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ linux,rs485-enabled-at-boot-time;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ linux,rs485-enabled-at-boot-time;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ disable-wp;
+ cap-sd-highspeed;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ non-removable;
+ mmc-pwrseq = <&usdhc2_wifi_pwrseq>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ no-sd;
+ no-sdio;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can1: can1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b000
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x3008
+ >;
+ };
+
+ pinctrl_can2: can2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b000
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x3008
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ /* MX6QDL_ENET_PINGRP4 */
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b0
+ /* Phy reset */
+ MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22 0x1b0b0
+ /* nINTRP */
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 0x1b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001f8b1
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_ipu1_disp: ipudisp1grp {
+ fsl,pins = <
+ /* DSE 0x30 => 25 Ohm, 0x20 => 37 Ohm, 0x10 => 75 Ohm */
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x30
+ MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x30
+ MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x30
+ MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x30
+ MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x30
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x30
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x30
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x30
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x30
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x30
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x30
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x30
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x30
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x30
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x30
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x30
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x30
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x30
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x30
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x30
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x30
+ MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x30
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x8
+ >;
+ };
+
+ pinctrl_ts_edt: ts1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D28__UART2_CTS_B 0x130b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D30__UART3_CTS_B 0x130b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__USB_OTG_OC 0x1b0b0
+ /* power enable, high active */
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_GPIO_1__SD1_CD_B 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17099
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10099
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17099
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17099
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17099
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17099
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17099
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17099
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17099
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17099
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x1b0b1
+ >;
+ };
+
+ pinctrl_wifi_npd: wifigrp {
+ fsl,pins = <
+ /* WL_REG_ON */
+ MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x13069
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6dl-pico-dwarf.dts b/arch/arm/boot/dts/imx6dl-pico-dwarf.dts
index 659a8e8..d85b15a 100644
--- a/arch/arm/boot/dts/imx6dl-pico-dwarf.dts
+++ b/arch/arm/boot/dts/imx6dl-pico-dwarf.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 DualLite/Solo Board and Dwarf baseboard";
- compatible = "technexion,imx6dl-pico", "fsl,imx6dl";
+ compatible = "technexion,imx6dl-pico-dwarf", "fsl,imx6dl";
};
diff --git a/arch/arm/boot/dts/imx6dl-pico-hobbit.dts b/arch/arm/boot/dts/imx6dl-pico-hobbit.dts
index d7403c5..08fedcb 100644
--- a/arch/arm/boot/dts/imx6dl-pico-hobbit.dts
+++ b/arch/arm/boot/dts/imx6dl-pico-hobbit.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 DualLite/Solo Board and Hobbit baseboard";
- compatible = "technexion,imx6dl-pico", "fsl,imx6dl";
+ compatible = "technexion,imx6dl-pico-hobbit", "fsl,imx6dl";
};
diff --git a/arch/arm/boot/dts/imx6dl-pico-nymph.dts b/arch/arm/boot/dts/imx6dl-pico-nymph.dts
index b282dbf..32ccfc5 100644
--- a/arch/arm/boot/dts/imx6dl-pico-nymph.dts
+++ b/arch/arm/boot/dts/imx6dl-pico-nymph.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 DualLite/Solo Board and Nymph baseboard";
- compatible = "technexion,imx6dl-pico", "fsl,imx6dl";
+ compatible = "technexion,imx6dl-pico-nymph", "fsl,imx6dl";
};
diff --git a/arch/arm/boot/dts/imx6dl-pico-pi.dts b/arch/arm/boot/dts/imx6dl-pico-pi.dts
index b7b1c07..4590e8a 100644
--- a/arch/arm/boot/dts/imx6dl-pico-pi.dts
+++ b/arch/arm/boot/dts/imx6dl-pico-pi.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 DualLite/Solo Board and PI baseboard";
- compatible = "technexion,imx6dl-pico", "fsl,imx6dl";
+ compatible = "technexion,imx6dl-pico-pi", "fsl,imx6dl";
};
diff --git a/arch/arm/boot/dts/imx6q-apalis-eval.dts b/arch/arm/boot/dts/imx6q-apalis-eval.dts
index fab83ab..a0683b4 100644
--- a/arch/arm/boot/dts/imx6q-apalis-eval.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-eval.dts
@@ -140,7 +140,7 @@ touchscreen@4a {
reg = <0x4a>;
interrupt-parent = <&gpio6>;
interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* SODIMM 13 */
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_LOW>; /* SODIMM 13 */
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts b/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts
index 1614b1a..86e8478 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora-v1.1.dts
@@ -145,7 +145,7 @@ touchscreen@4a {
reg = <0x4a>;
interrupt-parent = <&gpio6>;
interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* SODIMM 13 */
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_LOW>; /* SODIMM 13 */
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index fa9f98d..62e7277 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -144,7 +144,7 @@ touchscreen@4a {
reg = <0x4a>;
interrupt-parent = <&gpio6>;
interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* SODIMM 13 */
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_LOW>; /* SODIMM 13 */
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap10.dts b/arch/arm/boot/dts/imx6q-icore-ofcap10.dts
index 81cc346..02aca1e 100644
--- a/arch/arm/boot/dts/imx6q-icore-ofcap10.dts
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap10.dts
@@ -12,6 +12,17 @@
/ {
model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 10.1 Kit";
compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "ampire,am-1280800n3tzqw-t00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
};
&ldb {
@@ -22,18 +33,11 @@ lvds-channel@0 {
fsl,data-width = <24>;
status = "okay";
- display-timings {
- native-mode = <&timing0>;
- timing0: timing0 {
- clock-frequency = <60000000>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <40>;
- hfront-porch = <40>;
- vback-porch = <10>;
- vfront-porch = <3>;
- hsync-len = <80>;
- vsync-len = <10>;
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6q-pico-dwarf.dts b/arch/arm/boot/dts/imx6q-pico-dwarf.dts
index 618d274..479a63e 100644
--- a/arch/arm/boot/dts/imx6q-pico-dwarf.dts
+++ b/arch/arm/boot/dts/imx6q-pico-dwarf.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 Quad Board and Dwarf baseboard";
- compatible = "technexion,imx6q-pico", "fsl,imx6q";
+ compatible = "technexion,imx6q-pico-dwarf", "fsl,imx6q";
};
diff --git a/arch/arm/boot/dts/imx6q-pico-hobbit.dts b/arch/arm/boot/dts/imx6q-pico-hobbit.dts
index 7a66650..b767131 100644
--- a/arch/arm/boot/dts/imx6q-pico-hobbit.dts
+++ b/arch/arm/boot/dts/imx6q-pico-hobbit.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 Quad Board and Hobbit baseboard";
- compatible = "technexion,imx6q-pico", "fsl,imx6q";
+ compatible = "technexion,imx6q-pico-hobbit", "fsl,imx6q";
};
diff --git a/arch/arm/boot/dts/imx6q-pico-nymph.dts b/arch/arm/boot/dts/imx6q-pico-nymph.dts
index fe5a7be..e8ad4c1 100644
--- a/arch/arm/boot/dts/imx6q-pico-nymph.dts
+++ b/arch/arm/boot/dts/imx6q-pico-nymph.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 Quad Board and Nymph baseboard";
- compatible = "technexion,imx6q-pico", "fsl,imx6q";
+ compatible = "technexion,imx6q-pico-nymph", "fsl,imx6q";
};
diff --git a/arch/arm/boot/dts/imx6q-pico-pi.dts b/arch/arm/boot/dts/imx6q-pico-pi.dts
index 9413f0a..cc2394d 100644
--- a/arch/arm/boot/dts/imx6q-pico-pi.dts
+++ b/arch/arm/boot/dts/imx6q-pico-pi.dts
@@ -13,5 +13,5 @@
/ {
model = "TechNexion PICO-IMX6 Quad Board and PI baseboard";
- compatible = "technexion,imx6q-pico", "fsl,imx6q";
+ compatible = "technexion,imx6q-pico-pi", "fsl,imx6q";
};
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index 6704279..1e530d8 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -55,12 +55,12 @@ ir_recv: ir-receiver {
pinctrl-0 = <&pinctrl_cubox_i_ir>;
};
- pwmleds {
+ led-controller {
compatible = "pwm-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cubox_i_pwm1>;
- front {
+ led-1 {
active-low;
label = "imx6:red:front";
max-brightness = <248>;
diff --git a/arch/arm/boot/dts/imx6qdl-kontron-samx6i.dtsi b/arch/arm/boot/dts/imx6qdl-kontron-samx6i.dtsi
index 24f793c..d6df598 100644
--- a/arch/arm/boot/dts/imx6qdl-kontron-samx6i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-kontron-samx6i.dtsi
@@ -390,21 +390,21 @@ vgen6 {
/* I2C_GP */
&i2c1 {
- clock-frequency = <100000>;
+ clock-frequency = <375000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
};
/* HDMI_CTRL */
&i2c2 {
- clock-frequency = <100000>;
+ clock-frequency = <375000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
};
/* I2C_PM */
&i2c3 {
- clock-frequency = <100000>;
+ clock-frequency = <375000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index e361df2..7a1e531 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -116,7 +116,8 @@ &i2c1 {
status = "okay";
som_eeprom: eeprom@50 {
- compatible = "atmel,24c32";
+ compatible = "catalyst,24c32", "atmel,24c32";
+ pagesize = <32>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
index 41ebe45..a80aa08 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
@@ -84,7 +84,8 @@ &i2c3 {
status = "okay";
eeprom@50 {
- compatible = "atmel,24c32";
+ compatible = "st,24c32", "atmel,24c32";
+ pagesize = <32>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 66b1574..c0a7620 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -330,28 +330,28 @@ &gpio3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpio3_hog>;
- usb-emulation {
+ usb-emulation-hog {
gpio-hog;
gpios = <19 GPIO_ACTIVE_HIGH>;
output-low;
line-name = "usb-emulation";
};
- usb-mode1 {
+ usb-mode1-hog {
gpio-hog;
gpios = <20 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "usb-mode1";
};
- usb-pwr {
+ usb-pwr-hog {
gpio-hog;
gpios = <22 GPIO_ACTIVE_LOW>;
output-high;
line-name = "usb-pwr-ctrl-en-n";
};
- usb-mode2 {
+ usb-mode2-hog {
gpio-hog;
gpios = <23 GPIO_ACTIVE_HIGH>;
output-high;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 7a8837c..6f59a99 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -45,6 +45,10 @@ aliases {
spi1 = &ecspi2;
spi2 = &ecspi3;
spi3 = &ecspi4;
+ usb0 = &usbotg;
+ usb1 = &usbh1;
+ usb2 = &usbh2;
+ usb3 = &usbh3;
usbphy0 = &usbphy1;
usbphy1 = &usbphy2;
};
@@ -542,25 +546,25 @@ pwm4: pwm@208c000 {
status = "disabled";
};
- can1: flexcan@2090000 {
+ can1: can@2090000 {
compatible = "fsl,imx6q-flexcan";
reg = <0x02090000 0x4000>;
interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_CAN1_IPG>,
<&clks IMX6QDL_CLK_CAN1_SERIAL>;
clock-names = "ipg", "per";
- fsl,stop-mode = <&gpr 0x34 28 0x10 17>;
+ fsl,stop-mode = <&gpr 0x34 28>;
status = "disabled";
};
- can2: flexcan@2094000 {
+ can2: can@2094000 {
compatible = "fsl,imx6q-flexcan";
reg = <0x02094000 0x4000>;
interrupts = <0 111 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_CAN2_IPG>,
<&clks IMX6QDL_CLK_CAN2_SERIAL>;
clock-names = "ipg", "per";
- fsl,stop-mode = <&gpr 0x34 29 0x10 18>;
+ fsl,stop-mode = <&gpr 0x34 29>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6qp-prtwd3.dts b/arch/arm/boot/dts/imx6qp-prtwd3.dts
new file mode 100644
index 0000000..c427239
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-prtwd3.dts
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2018 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel <kernel@pengutronix.de>, Pengutronix
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include "imx6qp.dtsi"
+
+/ {
+ model = "Protonic WD3 board";
+ compatible = "prt,prtwd3", "fsl,imx6qp";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ memory@10000000 {
+ device_type = "memory";
