Merge tag 'gfs2-v6.5-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
Pull gfs2 updates from Andreas Gruenbacher:
- Fix a glock state (non-)transition bug when a dlm request times out
and is canceled, and we have locking requests that can now be granted
immediately
- Various fixes and cleanups in how the logd and quotad daemons are
woken up and terminated
- Fix several bugs in the quota data reference counting and shrinking.
Free quota data objects synchronously in put_super() instead of
letting call_rcu() run wild
- Make sure not to deallocate quota data during a withdraw; rather,
defer quota data deallocation to put_super(). Withdraws can happen in
contexts in which callers on the stack are holding quota data
references
- Many minor quota fixes and cleanups by Bob
- Update the the mailing list address for gfs2 and dlm. (It's the same
list for both and we are moving it to gfs2@lists.linux.dev)
- Various other minor cleanups
* tag 'gfs2-v6.5-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: (51 commits)
MAINTAINERS: Update dlm mailing list
MAINTAINERS: Update gfs2 mailing list
gfs2: change qd_slot_count to qd_slot_ref
gfs2: check for no eligible quota changes
gfs2: Remove useless assignment
gfs2: simplify slot_get
gfs2: Simplify qd2offset
gfs2: introduce qd_bh_get_or_undo
gfs2: Remove quota allocation info from quota file
gfs2: use constant for array size
gfs2: Set qd_sync_gen in do_sync
gfs2: Remove useless err set
gfs2: Small gfs2_quota_lock cleanup
gfs2: move qdsb_put and reduce redundancy
gfs2: improvements to sysfs status
gfs2: Don't try to sync non-changes
gfs2: Simplify function need_sync
gfs2: remove unneeded pg_oflow variable
gfs2: remove unneeded variable done
gfs2: pass sdp to gfs2_write_buf_to_page
...
diff --git a/.gitignore b/.gitignore
index 9fd4c95..0bbae16 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,7 +74,7 @@
#
# RPM spec file (make rpm-pkg)
#
-/*.spec
+/kernel.spec
/rpmbuild/
#
diff --git a/.mailmap b/.mailmap
index 5dd3181..a0a6efe 100644
--- a/.mailmap
+++ b/.mailmap
@@ -139,6 +139,9 @@
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
David Brownell <david-b@pacbell.net>
David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
+David Rheinsberg <david@readahead.eu> <dh.herrmann@gmail.com>
+David Rheinsberg <david@readahead.eu> <dh.herrmann@googlemail.com>
+David Rheinsberg <david@readahead.eu> <david.rheinsberg@gmail.com>
David Woodhouse <dwmw2@shinybook.infradead.org>
Dedy Lansky <quic_dlansky@quicinc.com> <dlansky@codeaurora.org>
Deepak Kumar Singh <quic_deesin@quicinc.com> <deesin@codeaurora.org>
@@ -538,6 +541,8 @@
Sibi Sankar <quic_sibis@quicinc.com> <sibis@codeaurora.org>
Sid Manning <quic_sidneym@quicinc.com> <sidneym@codeaurora.org>
Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
+Simon Horman <horms@kernel.org> <simon.horman@corigine.com>
+Simon Horman <horms@kernel.org> <simon.horman@netronome.com>
Simon Kelley <simon@thekelleys.org.uk>
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
diff --git a/CREDITS b/CREDITS
index 8b48820..f33a33f 100644
--- a/CREDITS
+++ b/CREDITS
@@ -666,11 +666,6 @@
S: Taiwan 251
S: Republic of China
-N: Reinette Chatre
-E: reinette.chatre@intel.com
-D: WiMedia Link Protocol implementation
-D: UWB stack bits and pieces
-
N: Michael Elizabeth Chastain
E: mec@shout.net
D: Configure, Menuconfig, xconfig
@@ -3023,12 +3018,6 @@
S: Tula 300000
S: Russia
-N: Inaky Perez-Gonzalez
-E: inaky.perez-gonzalez@intel.com
-D: UWB stack, HWA-RC driver and HWA-HC drivers
-D: Wireless USB additions to the USB stack
-D: WiMedia Link Protocol bits and pieces
-
N: Gordon Peters
E: GordPeters@smarttech.com
D: Isochronous receive for IEEE 1394 driver (OHCI module).
diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block
index c57e5b7..1fe9a55 100644
--- a/Documentation/ABI/stable/sysfs-block
+++ b/Documentation/ABI/stable/sysfs-block
@@ -295,7 +295,7 @@
capable of executing requests targeting different sector ranges
in parallel. For instance, single LUN multi-actuator hard-disks
will have an independent_access_ranges directory if the device
- correctly advertizes the sector ranges of its actuators.
+ correctly advertises the sector ranges of its actuators.
The independent_access_ranges directory contains one directory
per access range, with each range described using the sector
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi
index 96ccc33..1a47f9e 100644
--- a/Documentation/ABI/stable/sysfs-bus-mhi
+++ b/Documentation/ABI/stable/sysfs-bus-mhi
@@ -1,7 +1,7 @@
What: /sys/bus/mhi/devices/.../serialnumber
Date: Sept 2020
KernelVersion: 5.10
-Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Contact: mhi@lists.linux.dev
Description: The file holds the serial number of the client device obtained
using a BHI (Boot Host Interface) register read after at least
one attempt to power up the device has been done. If read
@@ -12,7 +12,7 @@
What: /sys/bus/mhi/devices/.../oem_pk_hash
Date: Sept 2020
KernelVersion: 5.10
-Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Contact: mhi@lists.linux.dev
Description: The file holds the OEM PK Hash value of the endpoint device
obtained using a BHI (Boot Host Interface) register read after
at least one attempt to power up the device has been done. If
diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband
index ebf08c6..694f23a 100644
--- a/Documentation/ABI/stable/sysfs-class-infiniband
+++ b/Documentation/ABI/stable/sysfs-class-infiniband
@@ -356,7 +356,7 @@
pkeys/<n>: (RO) Displays the contents of the physical
key table n = 0..126
- mcgs/: (RO) Muticast group table
+ mcgs/: (RO) Multicast group table
<m>/gid_idx/0: (RO) Display the GID mapping m = 1..2
diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd
index 534b7a3..825e619 100644
--- a/Documentation/ABI/stable/sysfs-driver-dma-idxd
+++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd
@@ -84,7 +84,7 @@
Date: Oct 27, 2020
KernelVersion: 5.11.0
Contact: dmaengine@vger.kernel.org
-Description: To indicate if PASID (process address space identifier) is
+Description: To indicate if user PASID (process address space identifier) is
enabled or not for this device.
What: /sys/bus/dsa/devices/dsa<m>/state
diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
index 6095390..2cdfd09 100644
--- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io
+++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
@@ -662,3 +662,56 @@
Value 1 in file means this is reset cause, 0 - otherwise.
The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_pn
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version_min
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files show with which CPLD part numbers, version and minor
+ versions have been burned the 5-th CPLD device equipped on a
+ system.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_cap
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file indicates the available method of CPLD/FPGA devices
+ field update through the JTAG chain:
+
+ b00 - field update through LPC bus register memory space.
+ b01 - Reserved.
+ b10 - Reserved.
+ b11 - field update through CPU GPIOs bit-banging.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lid_open
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: 1 - indicates that system lid is opened, otherwise 0.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_long_pwr_pb
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file if set 1 indicates that system has been reset by
+ long press of power button.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_dc_dc_pwr_fail
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows 1 in case the system reset happened due to the
+ failure of any DC-DC power converter devices equipped on the
+ switch board.
+
+ The file is read only.
diff --git a/Documentation/ABI/stable/sysfs-platform-wmi-bmof b/Documentation/ABI/stable/sysfs-platform-wmi-bmof
index a786504..2881244e 100644
--- a/Documentation/ABI/stable/sysfs-platform-wmi-bmof
+++ b/Documentation/ABI/stable/sysfs-platform-wmi-bmof
@@ -2,6 +2,6 @@
Date: Jun 2017
KernelVersion: 4.13
Description:
- Binary MOF metadata used to decribe the details of available ACPI WMI interfaces.
+ Binary MOF metadata used to describe the details of available ACPI WMI interfaces.
See Documentation/wmi/devices/wmi-bmof.rst for details.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-midi2 b/Documentation/ABI/testing/configfs-usb-gadget-midi2
new file mode 100644
index 0000000..0eac3aa
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-midi2
@@ -0,0 +1,54 @@
+What: /config/usb-gadget/gadget/functions/midi2.name
+Date: Jul 2023
+KernelVersion: 6.6
+Description:
+ The attributes:
+
+ ============ ===============================================
+ process_ump Flag to process UMP Stream messages (0 or 1)
+ static_block Flag for static blocks (0 or 1)
+ iface_name MIDI interface name string
+ ============ ===============================================
+
+What: /config/usb-gadget/gadget/functions/midi2.name/ep.number
+Date: Jul 2023
+KernelVersion: 6.6
+Description:
+ This group contains a UMP Endpoint configuration.
+ A new Endpoint starts from 0, and can be up to 3.
+
+ The attributes:
+
+ ============= ===============================================
+ protocol_caps MIDI protocol capabilities (1, 2 or 3 for both)
+ protocol Default MIDI protocol (1 or 2)
+ ep_name UMP Endpoint name string
+ product_id Product ID string
+ manufacturer Manufacture ID (24 bit)
+ family Device family ID (16 bit)
+ model Device model ID (16 bit)
+ sw_revision Software Revision (32 bit)
+ ============= ===============================================
+
+What: /config/usb-gadget/gadget/functions/midi2.name/ep.number/block.number
+Date: Jul 2023
+KernelVersion: 6.6
+Description:
+ This group contains a UMP Function Block configuration.
+ A new block starts from 0, and can be up to 31.
+
+ The attributes:
+
+ ================= ==============================================
+ name Function Block name string
+ direction 1: input, 2: output, 3: bidirectional
+ first_group The first UMP Group number (0-15)
+ num_groups The number of groups in this FB (1-16)
+ midi1_first_group The first UMP Group number for MIDI 1.0 (0-15)
+ midi1_num_groups The number of groups for MIDI 1.0 (0-16)
+ ui_hint 0: unknown, 1: receiver, 2: sender, 3: both
+ midi_ci_verison Supported MIDI-CI version number (8 bit)
+ is_midi1 Legacy MIDI 1.0 device (0, 1 or 2)
+ sysex8_streams Max number of SysEx8 streams (8 bit)
+ active Active FB flag (0 or 1)
+ ================= ==============================================
diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs
index 85f6d04..df53578 100644
--- a/Documentation/ABI/testing/debugfs-driver-habanalabs
+++ b/Documentation/ABI/testing/debugfs-driver-habanalabs
@@ -95,7 +95,7 @@
Date: Oct 2022
KernelVersion: 6.2
Contact: ttayar@habana.ai
-Description: The watchdog timeout value in seconds for a device relese upon
+Description: The watchdog timeout value in seconds for a device release upon
certain error cases, after which the device is reset.
What: /sys/kernel/debug/habanalabs/hl<n>/dma_size
diff --git a/Documentation/ABI/testing/debugfs-driver-qat b/Documentation/ABI/testing/debugfs-driver-qat
new file mode 100644
index 0000000..6731ffa
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-driver-qat
@@ -0,0 +1,61 @@
+What: /sys/kernel/debug/qat_<device>_<BDF>/qat/fw_counters
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the number of requests sent to the FW and the number of responses
+ received from the FW for each Acceleration Engine
+ Reported firmware counters::
+
+ <N>: Number of requests sent from Acceleration Engine N to FW and responses
+ Acceleration Engine N received from FW
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/config
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RW) Read returns value of the Heartbeat update period.
+ Write to the file changes this period value.
+
+ This period should reflect planned polling interval of device
+ health status. High frequency Heartbeat monitoring wastes CPU cycles
+ but minimizes the customer’s system downtime. Also, if there are
+ large service requests that take some time to complete, high frequency
+ Heartbeat monitoring could result in false reports of unresponsiveness
+ and in those cases, period needs to be increased.
+
+ This parameter is effective only for c3xxx, c62x, dh895xcc devices.
+ 4xxx has this value internally fixed to 200ms.
+
+ Default value is set to 500. Minimal allowed value is 200.
+ All values are expressed in milliseconds.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_failed
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the number of times the device became unresponsive.
+
+ Attribute returns value of the counter which is incremented when
+ status query results negative.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_sent
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the number of times the control process checked
+ if the device is responsive.
+
+ Attribute returns value of the counter which is incremented on
+ every status query.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/status
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the device health status.
+
+ Returns 0 when device is healthy or -1 when is unresponsive
+ or the query failed to send.
+
+ The driver does not monitor for Heartbeat. It is left for a user
+ to poll the status periodically.
diff --git a/Documentation/ABI/testing/debugfs-tpmi b/Documentation/ABI/testing/debugfs-tpmi
new file mode 100644
index 0000000..597f0475
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-tpmi
@@ -0,0 +1,31 @@
+What: /sys/kernel/debug/tpmi-<n>/pfs_dump
+Date: November 2023
+KernelVersion: 6.6
+Contact: srinivas.pandruvada@linux.intel.com
+Description:
+The PFS (PM Feature Structure) table, shows details of each power
+management feature. This includes:
+tpmi_id, number of entries, entry size, offset, vsec offset, lock status
+and disabled status.
+Users: Debugging, any user space test suite
+
+What: /sys/kernel/debug/tpmi-<n>/tpmi-id-<n>/mem_dump
+Date: November 2023
+KernelVersion: 6.6
+Contact: srinivas.pandruvada@linux.intel.com
+Description:
+Shows the memory dump of the MMIO region for a TPMI ID.
+Users: Debugging, any user space test suite
+
+What: /sys/kernel/debug/tpmi-<n>/tpmi-id-<n>/mem_write
+Date: November 2023
+KernelVersion: 6.6
+Contact: srinivas.pandruvada@linux.intel.com
+Description:
+Allows to write at any offset. It doesn't check for Read/Write access
+as hardware will not allow to write at read-only memory. This write is
+at offset multiples of 4. The format is instance,offset,contents.
+Example:
+echo 0,0x20,0xff > mem_write
+echo 1,64,64 > mem_write
+Users: Debugging, any user space test suite
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 49db0ff..c2385183 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -57,9 +57,9 @@
stored in security.ima xattr. Requires
specifying "digest_type=verity" first.)
- appraise_flag:= [check_blacklist]
- Currently, blacklist check is only for files signed with appended
- signature.
+ appraise_flag:= [check_blacklist] (deprecated)
+ Setting the check_blacklist flag is no longer necessary.
+ All appraisal functions set it by default.
digest_type:= verity
Require fs-verity's file digest instead of the
regular IMA file hash.
diff --git a/Documentation/ABI/testing/procfs-diskstats b/Documentation/ABI/testing/procfs-diskstats
index e58d641..6a719cf 100644
--- a/Documentation/ABI/testing/procfs-diskstats
+++ b/Documentation/ABI/testing/procfs-diskstats
@@ -8,7 +8,7 @@
== ===================================
1 major number
- 2 minor mumber
+ 2 minor number
3 device name
4 reads completed successfully
5 reads merged
diff --git a/Documentation/ABI/testing/sysfs-bus-coreboot b/Documentation/ABI/testing/sysfs-bus-coreboot
index 9c5acce..8e8d6af2 100644
--- a/Documentation/ABI/testing/sysfs-bus-coreboot
+++ b/Documentation/ABI/testing/sysfs-bus-coreboot
@@ -21,7 +21,7 @@
Date: August 2022
Contact: Jack Rosenthal <jrosenth@chromium.org>
Description:
- This is the pyhsical memory address that the CBMEM entry's data
+ This is the physical memory address that the CBMEM entry's data
begins at, in hexadecimal (e.g., ``0x76ffe000``).
What: /sys/bus/coreboot/devices/cbmem-<id>/size
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
index 234c33f..3acf7fc 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
@@ -31,7 +31,7 @@
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the range of
- addresses to trigger on. Inclusion or exclusion is specificed
+ addresses to trigger on. Inclusion or exclusion is specified
in the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single
@@ -304,19 +304,19 @@
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RO) Print the content of the ETM Trace Start/Stop Conrol
+Description: (RO) Print the content of the ETM Trace Start/Stop Control
register (0x018). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RO) Print the content of the ETM Enable Conrol #1
+Description: (RO) Print the content of the ETM Enable Control #1
register (0x024). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RO) Print the content of the ETM Enable Conrol #2
+Description: (RO) Print the content of the ETM Enable Control #2
register (0x01c). The value is read directly from the HW.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
index 08b1964..a0425d7 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
@@ -446,7 +446,7 @@
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (Read) Returns the maximum size of the data value, data address,
- VMID, context ID and instuction address in the trace unit
+ VMID, context ID and instruction address in the trace unit
(0x1E8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3
diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
index dc3b3a5..73ac84c 100644
--- a/Documentation/ABI/testing/sysfs-bus-counter
+++ b/Documentation/ABI/testing/sysfs-bus-counter
@@ -22,11 +22,11 @@
phase clock.
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available
-KernelVersion: 6.4
-Contact: linux-iio@vger.kernel.org
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
Description:
- Discrete set of available values for the respective device
- configuration are listed in this file.
+ Discrete set of available values for the respective device
+ configuration are listed in this file.
What: /sys/bus/counter/devices/counterX/countY/count
KernelVersion: 5.2
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 505f080..77de58d 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -47,7 +47,7 @@
If a <term> is specified alone (without an assigned value), it
is implied that 0x1 is assigned to that <term>.
- Examples (each of these lines would be in a seperate file):
+ Examples (each of these lines would be in a separate file):
event=0x2abc
event=0x423,inv,cmask=0x3
@@ -83,7 +83,7 @@
A string representing a floating point value expressed in
scientific notation to be multiplied by the event count
- recieved from the kernel to match the unit specified in the
+ received from the kernel to match the unit specified in the
<event>.unit file.
Example:
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
index 12e2bf9..40f7cd2 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -80,3 +80,163 @@
Description: read only
This sysfs file exposes the cpumask which is designated to make
HCALLs to retrieve hv-gpci pmu event counter data.
+
+What: /sys/devices/hv_gpci/interface/processor_bus_topology
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ PROCESSOR_BUS_TOPOLOGY(0xD0).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/processor_config
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ PROCESSOR_CONFIG(0x90).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/affinity_domain_via_virtual_processor
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ AFFINITY_DOMAIN_INFORMATION_BY_VIRTUAL_PROCESSOR(0xA0).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/affinity_domain_via_domain
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ AFFINITY_DOMAIN_INFORMATION_BY_DOMAIN(0xB0).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/affinity_domain_via_partition
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ AFFINITY_DOMAIN_INFORMATION_BY_PARTITION(0xB1).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
diff --git a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo
index 531fe9d..c7393b4 100644
--- a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo
+++ b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo
@@ -5,6 +5,6 @@
Indicates whether or not this SBE device has experienced a
timeout; i.e. the SBE did not respond within the time allotted
by the driver. A value of 1 indicates that a timeout has
- ocurred and no transfers have completed since the timeout. A
- value of 0 indicates that no timeout has ocurred, or if one
- has, more recent transfers have completed successful.
+ occurred and no transfers have completed since the timeout. A
+ value of 0 indicates that no timeout has occurred, or if one
+ has, more recent transfers have completed successfully.
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480
index 42dfc93..288bc2f 100644
--- a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480
@@ -8,7 +8,7 @@
NONE no device
USB USB device is attached
UART UART is attached
- CHARGER Charger is attaced
+ CHARGER Charger is attached
JIG JIG is attached
======= ======================
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 7140e8e..a2854dc9 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -2163,3 +2163,19 @@
Description:
An example format is 16-bytes, 2-digits-per-byte, HEX-string
representing the sensor unique ID number.
+
+What: /sys/.../events/in_proximity_thresh_either_runningperiod
+KernelVersion: 6.6
+Contact: linux-iio@vger.kernel.org
+Description:
+ A running period of time (in seconds) for which
+ in_proximity_thresh_either_runningcount amount of conditions
+ must occur before an event is generated. If direction is not
+ specified then this period applies to both directions.
+
+What: /sys/.../events/in_proximity_thresh_either_runningcount
+KernelVersion: 6.6
+Contact: linux-iio@vger.kernel.org
+Description:
+ Number of conditions that must occur, during a running
+ period, before an event is generated.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
index f6c0357..31dbb39 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
+++ b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
@@ -7,6 +7,8 @@
- auto -> Adjust bandpass filter to track changes in input clock rate.
- manual -> disable/unregister the clock rate notifier / input clock tracking.
+ - bypass -> bypass low pass filter, high pass filter and disable/unregister
+ the clock rate notifier
What: /sys/bus/iio/devices/iio:deviceX/filter_mode
KernelVersion:
diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit
index e7282d1..ed483a1 100644
--- a/Documentation/ABI/testing/sysfs-bus-nfit
+++ b/Documentation/ABI/testing/sysfs-bus-nfit
@@ -121,7 +121,7 @@
Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI specification 6.2 section 5.2.25.9, defines an
- identifier for an NVDIMM, which refelects the id attribute.
+ identifier for an NVDIMM, which reflects the id attribute.
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm
index de8c5a5..64eb8f4 100644
--- a/Documentation/ABI/testing/sysfs-bus-nvdimm
+++ b/Documentation/ABI/testing/sysfs-bus-nvdimm
@@ -18,10 +18,12 @@
Each attribute under this group defines a bit range of the
perf_event_attr.config. Supported attribute is listed
below::
+
event = "config:0-4" - event ID
For example::
- ctl_res_cnt = "event=0x1"
+
+ ctl_res_cnt = "event=0x1"
What: /sys/bus/event_source/devices/nmemX/events
Date: February 2022
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 4ac0673..46cfe02 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -30,7 +30,7 @@
Indicating that contents of the
NVDIMM have been scrubbed.
* "locked"
- Indicating that NVDIMM contents cant
+ Indicating that NVDIMM contents can't
be modified until next power cycle.
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index 76ab3e1f..221b6c7 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -1,7 +1,7 @@
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
Date: Jun 2018
KernelVersion: 4.17
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Holds a comma separated list of device unique_ids that
are allowed to be connected automatically during system
startup (e.g boot devices). The list always contains
@@ -33,7 +33,7 @@
What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
Date: Mar 2019
KernelVersion: 4.21
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute tells whether the system uses IOMMU
for DMA protection. Value of 1 means IOMMU is used 0 means
it is not (DMA protection is solely based on Thunderbolt
@@ -42,7 +42,7 @@
What: /sys/bus/thunderbolt/devices/.../domainX/security
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute holds current Thunderbolt security level
set by the system BIOS. Possible values are:
@@ -64,7 +64,7 @@
What: /sys/bus/thunderbolt/devices/.../authorized
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute is used to authorize Thunderbolt devices
after they have been connected. If the device is not
authorized, no PCIe devices are available to the system.
@@ -98,7 +98,7 @@
What: /sys/bus/thunderbolt/devices/.../boot
Date: Jun 2018
KernelVersion: 4.17
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains 1 if Thunderbolt device was already
authorized on boot and 0 otherwise.
@@ -113,7 +113,7 @@
What: /sys/bus/thunderbolt/devices/.../key
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: When a devices supports Thunderbolt secure connect it will
have this attribute. Writing 32 byte hex string changes
authorization to use the secure connection method instead.
@@ -123,14 +123,14 @@
What: /sys/bus/thunderbolt/devices/.../device
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains id of this device extracted from
the device DROM.
What: /sys/bus/thunderbolt/devices/.../device_name
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains name of this device extracted from
the device DROM.
@@ -172,21 +172,21 @@
What: /sys/bus/thunderbolt/devices/.../vendor
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains vendor id of this device extracted
from the device DROM.
What: /sys/bus/thunderbolt/devices/.../vendor_name
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains vendor name of this device extracted
from the device DROM.
What: /sys/bus/thunderbolt/devices/.../unique_id
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains unique_id string of this device.
This is either read from hardware registers (UUID on
newer hardware) or based on UID from the device DROM.
@@ -195,7 +195,7 @@
What: /sys/bus/thunderbolt/devices/.../nvm_version
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: If the device has upgradeable firmware the version
number is available here. Format: %x.%x, major.minor.
If the device is in safe mode reading the file returns
@@ -204,7 +204,7 @@
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: When new NVM image is written to the non-active NVM
area (through non_activeX NVMem device), the
authentication procedure is started by writing to
@@ -246,7 +246,7 @@
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/key
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains name of the property directory the XDomain
service exposes. This entry describes the protocol in
question. Following directories are already reserved by
@@ -261,35 +261,35 @@
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/modalias
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Stores the same MODALIAS value emitted by uevent for
the XDomain service. Format: tbtsvc:kSpNvNrN
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcid
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain protocol identifier the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcvers
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain protocol version the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcrevs
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain software version the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcstns
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain service specific settings as
bitmask. Format: %x
diff --git a/Documentation/ABI/testing/sysfs-bus-umc b/Documentation/ABI/testing/sysfs-bus-umc
deleted file mode 100644
index 948fec4..0000000
--- a/Documentation/ABI/testing/sysfs-bus-umc
+++ /dev/null
@@ -1,28 +0,0 @@
-What: /sys/bus/umc/
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The Wireless Host Controller Interface (WHCI)
- specification describes a PCI-based device with
- multiple capabilities; the UWB Multi-interface
- Controller (UMC).
-
- The umc bus presents each of the individual
- capabilties as a device.
-
-What: /sys/bus/umc/devices/.../capability_id
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The ID of this capability, with 0 being the radio
- controller capability.
-
-What: /sys/bus/umc/devices/.../version
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The specification version this capability's hardware
- interface complies with.
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index be66325..a44bfe0 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -28,40 +28,6 @@
drivers, non-authorized one are not. By default, wired
USB devices are authorized.
- Certified Wireless USB devices are not authorized
- initially and should be (by writing 1) after the
- device has been authenticated.
-
-What: /sys/bus/usb/device/.../wusb_cdid
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- For Certified Wireless USB devices only.
-
- A devices's CDID, as 16 space-separated hex octets.
-
-What: /sys/bus/usb/device/.../wusb_ck
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- For Certified Wireless USB devices only.
-
- Write the device's connection key (CK) to start the
- authentication of the device. The CK is 16
- space-separated hex octets.
-
-What: /sys/bus/usb/device/.../wusb_disconnect
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- For Certified Wireless USB devices only.
-
- Write a 1 to force the device to disconnect
- (equivalent to unplugging a wired USB device).
-
What: /sys/bus/usb/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class
index 676530f..906735f 100644
--- a/Documentation/ABI/testing/sysfs-class
+++ b/Documentation/ABI/testing/sysfs-class
@@ -1,5 +1,5 @@
What: /sys/class/
-Date: Febuary 2006
+Date: February 2006
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
The /sys/class directory will consist of a group of
diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
index 594fda2..cfc48a8 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/testing/sysfs-class-cxl
@@ -42,7 +42,7 @@
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
- Decimal value of the size of the MMIO space that may be mmaped
+ Decimal value of the size of the MMIO space that may be mmapped
by userspace.
Users: https://github.com/ibm-capi/libcxl
@@ -155,7 +155,7 @@
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
- Decimal value of the size of the MMIO space that may be mmaped
+ Decimal value of the size of the MMIO space that may be mmapped
by userspace. This includes all slave contexts space also.
Users: https://github.com/ibm-capi/libcxl
diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
index 1b3ecae..f205d39 100644
--- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
+++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
@@ -22,6 +22,11 @@
- integer: a range of numerical values
- string
+ HP specific types
+ -----------------
+ - ordered-list - a set of ordered list valid values
+
+
All attribute types support the following values:
current_value:
@@ -126,6 +131,21 @@
value will not be effective through sysfs until this rule is
met.
+ HP specific class extensions
+ ------------------------------
+
+ On HP systems the following additional attributes are available:
+
+ "ordered-list"-type specific properties:
+
+ elements:
+ A file that can be read to obtain the possible
+ list of values of the <attr>. Values are separated using
+ semi-colon (``;``) and listed according to their priority.
+ An element listed first has the highest priority. Writing
+ the list in a different order to current_value alters
+ the priority order for the particular attribute.
+
What: /sys/class/firmware-attributes/*/authentication/
Date: February 2021
KernelVersion: 5.11
@@ -206,7 +226,7 @@
Drivers may emit a CHANGE uevent when a password is set or unset
userspace may check it again.
- On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes
+ On Dell, Lenovo and HP systems, if Admin password is set, then all BIOS attributes
require password validation.
On Lenovo systems if you change the Admin password the new password is not active until
the next boot.
@@ -296,6 +316,15 @@
echo "signature" > authentication/Admin/signature
echo "password" > authentication/Admin/certificate_to_password
+ HP specific class extensions
+ --------------------------------
+
+ On HP systems the following additional settings are available:
+
+ role: enhanced-bios-auth:
+ This role is specific to Secure Platform Management (SPM) attribute.
+ It requires configuring an endorsement (kek) and signing certificate (sk).
+
What: /sys/class/firmware-attributes/*/attributes/pending_reboot
Date: February 2021
@@ -311,7 +340,7 @@
== =========================================
0 All BIOS attributes setting are current
1 A reboot is necessary to get pending BIOS
- attribute changes applied
+ attribute changes applied
== =========================================
Note, userspace applications need to follow below steps for efficient
@@ -364,3 +393,71 @@
use it to enable extra debug attributes or BIOS features for testing purposes.
Note that any changes to this attribute requires a reboot for changes to take effect.
+
+
+ HP specific class extensions - Secure Platform Manager (SPM)
+ --------------------------------
+
+What: /sys/class/firmware-attributes/*/authentication/SPM/kek
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'kek' Key-Encryption-Key is a write-only file that can be used to configure the
+ RSA public key that will be used by the BIOS to verify
+ signatures when setting the signing key. When written,
+ the bytes should correspond to the KEK certificate
+ (x509 .DER format containing an OU). The size of the
+ certificate must be less than or equal to 4095 bytes.
+
+What: /sys/class/firmware-attributes/*/authentication/SPM/sk
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'sk' Signature Key is a write-only file that can be used to configure the RSA
+ public key that will be used by the BIOS to verify signatures
+ when configuring BIOS settings and security features. When
+ written, the bytes should correspond to the modulus of the
+ public key. The exponent is assumed to be 0x10001.
+
+What: /sys/class/firmware-attributes/*/authentication/SPM/status
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'status' is a read-only file that returns ASCII text in JSON format reporting
+ the status information.
+
+ "State": "not provisioned | provisioned | provisioning in progress",
+ "Version": "Major.Minor",
+ "Nonce": <16-bit unsigned number display in base 10>,
+ "FeaturesInUse": <16-bit unsigned number display in base 10>,
+ "EndorsementKeyMod": "<256 bytes in base64>",
+ "SigningKeyMod": "<256 bytes in base64>"
+
+What: /sys/class/firmware-attributes/*/attributes/Sure_Start/audit_log_entries
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'audit_log_entries' is a read-only file that returns the events in the log.
+
+ Audit log entry format
+
+ Byte 0-15: Requested Audit Log entry (Each Audit log is 16 bytes)
+ Byte 16-127: Unused
+
+What: /sys/class/firmware-attributes/*/attributes/Sure_Start/audit_log_entry_count
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'audit_log_entry_count' is a read-only file that returns the number of existing
+ audit log events available to be read. Values are separated using comma. (``,``)
+
+ [No of entries],[log entry size],[Max number of entries supported]
+
+ log entry size identifies audit log size for the current BIOS version.
+ The current size is 16 bytes but it can be up to 128 bytes long in future BIOS
+ versions.
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
index 2e24ac3..b2ff0012 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -59,6 +59,15 @@
brightness. Reading this file when no hw brightness change
event has happened will return an ENODATA error.
+What: /sys/class/leds/<led>/color
+Date: June 2023
+KernelVersion: 6.5
+Description:
+ Color of the LED.
+
+ This is a read-only file. Reading this file returns the color
+ of the LED as a string (e.g: "red", "green", "multicolor").
+
What: /sys/class/leds/<led>/trigger
Date: March 2006
KernelVersion: 2.6.17
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
index 78b62a2..f6d9d72 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
@@ -13,7 +13,7 @@
Specifies the duration of the LED blink in milliseconds.
Defaults to 50 ms.
- With hw_control ON, the interval value MUST be set to the
+ When offloaded is true, the interval value MUST be set to the
default value and cannot be changed.
Trying to set any value in this specific mode will return
an EINVAL error.
@@ -44,8 +44,8 @@
If set to 1, the LED will blink for the milliseconds specified
in interval to signal transmission.
- With hw_control ON, the blink interval is controlled by hardware
- and won't reflect the value set in interval.
+ When offloaded is true, the blink interval is controlled by
+ hardware and won't reflect the value set in interval.
What: /sys/class/leds/<led>/rx
Date: Dec 2017
@@ -59,21 +59,21 @@
If set to 1, the LED will blink for the milliseconds specified
in interval to signal reception.
- With hw_control ON, the blink interval is controlled by hardware
- and won't reflect the value set in interval.
+ When offloaded is true, the blink interval is controlled by
+ hardware and won't reflect the value set in interval.
-What: /sys/class/leds/<led>/hw_control
+What: /sys/class/leds/<led>/offloaded
Date: Jun 2023
KernelVersion: 6.5
Contact: linux-leds@vger.kernel.org
Description:
- Communicate whether the LED trigger modes are driven by hardware
- or software fallback is used.
+ Communicate whether the LED trigger modes are offloaded to
+ hardware or whether software fallback is used.
If 0, the LED is using software fallback to blink.
- If 1, the LED is using hardware control to blink and signal the
- requested modes.
+ If 1, the LED blinking in requested mode is offloaded to
+ hardware.
What: /sys/class/leds/<led>/link_10
Date: Jun 2023
diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
index 3bc7c0a..f77fa4f 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -39,7 +39,7 @@
Contact: linux-mtd@lists.infradead.org
Description:
Major and minor numbers of the character device corresponding
- to the read-only variant of thie MTD device (in
+ to the read-only variant of the MTD device (in
<major>:<minor> format). In this case <minor> will be odd.
What: /sys/class/mtd/mtdX/erasesize
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net
index 1419103..ebf21be 100644
--- a/Documentation/ABI/testing/sysfs-class-net
+++ b/Documentation/ABI/testing/sysfs-class-net
@@ -82,7 +82,7 @@
Contact: netdev@vger.kernel.org
Description:
Indicates the current physical link state of the interface.
- Posssible values are:
+ Possible values are:
== =====================
0 physical link is down
diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues
index 978b763..906ff3ca 100644
--- a/Documentation/ABI/testing/sysfs-class-net-queues
+++ b/Documentation/ABI/testing/sysfs-class-net-queues
@@ -39,7 +39,7 @@
Description:
Mask of the CPU(s) currently enabled to participate into the
Transmit Packet Steering packet processing flow for this
- network device transmit queue. Possible vaules depend on the
+ network device transmit queue. Possible values depend on the
number of available CPU(s) in the system.
What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco b/Documentation/ABI/testing/sysfs-class-power-wilco
index 82af180..083c464 100644
--- a/Documentation/ABI/testing/sysfs-class-power-wilco
+++ b/Documentation/ABI/testing/sysfs-class-power-wilco
@@ -22,7 +22,7 @@
Long Life:
Customized charge rate for last longer battery life.
On Wilco device this mode is pre-configured in the factory
- through EC's private PID. Swiching to a different mode will
+ through EC's private PID. Switching to a different mode will
be denied by Wilco EC when Long Life mode is enabled.
What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold
diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc b/Documentation/ABI/testing/sysfs-class-remoteproc
index 0c9ee55..b2b8e2d 100644
--- a/Documentation/ABI/testing/sysfs-class-remoteproc
+++ b/Documentation/ABI/testing/sysfs-class-remoteproc
@@ -81,7 +81,7 @@
collected userspace will directly read from the remote
processor's device memory. Extra buffer will not be used to
copy the dump. Also recovery process will not proceed until
- all data is read by usersapce.
+ all data is read by userspace.
What: /sys/class/remoteproc/.../recovery
Date: July 2020
diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal
index 8eee379..968d89e 100644
--- a/Documentation/ABI/testing/sysfs-class-thermal
+++ b/Documentation/ABI/testing/sysfs-class-thermal
@@ -4,7 +4,7 @@
This is given by thermal zone driver as part of registration.
E.g: "acpitz" indicates it's an ACPI thermal device.
In order to keep it consistent with hwmon sys attribute; this
- shouldbe a short, lowercase string, not containing spaces nor
+ should be a short, lowercase string, not containing spaces nor
dashes.
RO, Required
diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc b/Documentation/ABI/testing/sysfs-class-uwb_rc
deleted file mode 100644
index a7ea169..0000000
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc
+++ /dev/null
@@ -1,156 +0,0 @@
-What: /sys/class/uwb_rc
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Interfaces for WiMedia Ultra Wideband Common Radio
- Platform (UWB) radio controllers.
-
- Familiarity with the ECMA-368 'High Rate Ultra
- Wideband MAC and PHY Specification' is assumed.
-
-What: /sys/class/uwb_rc/beacon_timeout_ms
-Date: July 2008
-KernelVersion: 2.6.27
-Description:
- If no beacons are received from a device for at least
- this time, the device will be considered to have gone
- and it will be removed. The default is 3 superframes
- (~197 ms) as required by the specification.
-
-What: /sys/class/uwb_rc/uwb<N>/
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- An individual UWB radio controller.
-
-What: /sys/class/uwb_rc/uwb<N>/beacon
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Write:
-
- <channel>
-
- to force a specific channel to be used when beaconing,
- or, if <channel> is -1, to prohibit beaconing. If
- <channel> is 0, then the default channel selection
- algorithm will be used. Valid channels depends on the
- radio controller's supported band groups.
-
- Reading returns the currently active channel, or -1 if
- the radio controller is not beaconing.
-
-What: /sys/class/uwb_rc/uwb<N>/ASIE
-Date: August 2014
-KernelVersion: 3.18
-Contact: linux-usb@vger.kernel.org
-Description:
-
- The application-specific information element (ASIE)
- included in this device's beacon, in space separated
- hex octets.
-
- Reading returns the current ASIE. Writing replaces
- the current ASIE with the one written.
-
-What: /sys/class/uwb_rc/uwb<N>/scan
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Write:
-
- <channel> <type> [<bpst offset>]
-
- to start (or stop) scanning on a channel. <type> is one of:
-
- == =======================================
- 0 scan
- 1 scan outside BP
- 2 scan while inactive
- 3 scanning disabled
- 4 scan (with start time of <bpst offset>)
- == =======================================
-
-What: /sys/class/uwb_rc/uwb<N>/mac_address
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The EUI-48, in colon-separated hex octets, for this
- radio controller. A write will change the radio
- controller's EUI-48 but only do so while the device is
- not beaconing or scanning.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- A symlink to the device (if any) of the WUSB Host
- Controller PAL using this radio controller.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- A neighbour UWB device that has either been detected
- as part of a scan or is a member of the radio
- controllers beacon group.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/BPST
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The time (using the radio controllers internal 1 ms
- interval superframe timer) of the last beacon from
- this device was received.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/DevAddr
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The current DevAddr of this device in colon separated
- hex octets.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/EUI_48
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
-
- The EUI-48 of this device in colon separated hex
- octets.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/IEs
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The latest IEs included in this device's beacon, in
- space separated hex octets with one IE per line.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/LQE
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Link Quality Estimate - the Signal to Noise Ratio
- (SNR) of all packets received from this device in dB.
- This gives an estimate on a suitable PHY rate. Refer
- to [ECMA-368] section 13.3 for more details.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/RSSI
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Received Signal Strength Indication - the strength of
- the received signal in dB. LQE is a more useful
- measure of the radio link quality.
diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
deleted file mode 100644
index 55eb55c..0000000
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
+++ /dev/null
@@ -1,57 +0,0 @@
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_chid
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Write the CHID (16 space-separated hex octets) for this host controller.
- This starts the host controller, allowing it to accept connection from
- WUSB devices.
-
- Set an all zero CHID to stop the host controller.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_trust_timeout
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Devices that haven't sent a WUSB packet to the host
- within 'wusb_trust_timeout' ms are considered to have
- disconnected and are removed. The default value of
- 4000 ms is the value required by the WUSB
- specification.
-
- Since this relates to security (specifically, the
- lifetime of PTKs and GTKs) it should not be changed
- from the default.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_phy_rate
-Date: August 2009
-KernelVersion: 2.6.32
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The maximum PHY rate to use for all connected devices.
- This is only of limited use for testing and
- development as the hardware's automatic rate
- adaptation is better then this simple control.
-
- Refer to [ECMA-368] section 10.3.1.1 for the value to
- use.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_dnts
-Date: June 2013
-KernelVersion: 3.11
-Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
-Description:
- The device notification time slot (DNTS) count and inverval in
- milliseconds that the WUSB host should use. This controls how
- often the devices will have the opportunity to send
- notifications to the host.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_retry_count
-Date: June 2013
-KernelVersion: 3.11
-Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
-Description:
- The number of retries that the WUSB host should attempt
- before reporting an error for a bus transaction. The range of
- valid values is [0..15], where 0 indicates infinite retries.
diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory
index d8b0f80..a95e0f1 100644
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -110,3 +110,11 @@
link is created for memory section 9 on node0.
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
+
+What: /sys/devices/system/memory/crash_hotplug
+Date: Aug 2023
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ (RO) indicates whether or not the kernel directly supports
+ modifying the crash elfcorehdr for memory hot un/plug and/or
+ on/offline changes.
diff --git a/Documentation/ABI/testing/sysfs-devices-online b/Documentation/ABI/testing/sysfs-devices-online
index f990026..c3359fe 100644
--- a/Documentation/ABI/testing/sysfs-devices-online
+++ b/Documentation/ABI/testing/sysfs-devices-online
@@ -17,4 +17,4 @@
After a successful execution of the bus type's .offline()
callback the device cannot be used for any purpose until either
it is removed (i.e. device_del() is called for it), or its bus
- type's .online() is exeucted successfully.
+ type's .online() is executed successfully.
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs b/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
new file mode 100644
index 0000000..fdb4e36
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
@@ -0,0 +1,81 @@
+What: /sys/devices/platform/HISI04Bx:00/chipX/all_linked
+What: /sys/devices/platform/HISI04Bx:00/chipX/linked_full_lane
+What: /sys/devices/platform/HISI04Bx:00/chipX/crc_err_cnt
+Date: November 2023
+KernelVersion: 6.6
+Contact: Huisong Li <lihuisong@huawei.org>
+Description:
+ The /sys/devices/platform/HISI04Bx:00/chipX/ directory
+ contains read-only attributes exposing some summarization
+ information of all HCCS ports under a specified chip.
+ The X in 'chipX' indicates the Xth chip on platform.
+
+ There are following attributes in this directory:
+
+ ================= ==== =========================================
+ all_linked: (RO) if all enabled ports on this chip are
+ linked (bool).
+ linked_full_lane: (RO) if all linked ports on this chip are full
+ lane (bool).
+ crc_err_cnt: (RO) total CRC err count for all ports on this
+ chip.
+ ================= ==== =========================================
+
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/all_linked
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/linked_full_lane
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/crc_err_cnt
+Date: November 2023
+KernelVersion: 6.6
+Contact: Huisong Li <lihuisong@huawei.org>
+Description:
+ The /sys/devices/platform/HISI04Bx:00/chipX/dieY/ directory
+ contains read-only attributes exposing some summarization
+ information of all HCCS ports under a specified die.
+ The Y in 'dieY' indicates the hardware id of the die on chip who
+ has chip id X.
+
+ There are following attributes in this directory:
+
+ ================= ==== =========================================
+ all_linked: (RO) if all enabled ports on this die are
+ linked (bool).
+ linked_full_lane: (RO) if all linked ports on this die are full
+ lane (bool).
+ crc_err_cnt: (RO) total CRC err count for all ports on this
+ die.
+ ================= ==== =========================================
+
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/type
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/lane_mode
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/enable
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/cur_lane_num
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/link_fsm
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/lane_mask
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/crc_err_cnt
+Date: November 2023
+KernelVersion: 6.6
+Contact: Huisong Li <lihuisong@huawei.org>
+Description:
+ The /sys/devices/platform/HISI04Bx/chipX/dieX/hccsN/ directory
+ contains read-only attributes exposing information about
+ a HCCS port. The N value in 'hccsN' indicates this port id.
+ The X in 'chipX' indicates the ID of the chip to which the
+ HCCS port belongs. For example, X ranges from to 'n - 1' if the
+ chip number on platform is n.
+ The Y in 'dieY' indicates the hardware id of the die to which
+ the hccs port belongs.
+ Note: type, lane_mode and enable are fixed attributes on running
+ platform.
+
+ The HCCS port have the following attributes:
+
+ ============= ==== =============================================
+ type: (RO) port type (string), e.g. HCCS-v1 -> H32
+ lane_mode: (RO) the lane mode of this port (string), e.g. x8
+ enable: (RO) indicate if this port is enabled (bool).
+ cur_lane_num: (RO) current lane number of this port.
+ link_fsm: (RO) link finite state machine of this port.
+ lane_mask: (RO) current lane mask of this port, every bit
+ indicates a lane.
+ crc_err_cnt: (RO) CRC err count on this port.
+ ============= ==== =============================================
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 77942ee..7ecd5c8 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -556,6 +556,7 @@
================ =========================================
"on" SMT is enabled
"off" SMT is disabled
+ "<N>" SMT is enabled with N threads per core.
"forceoff" SMT is force disabled. Cannot be changed.
"notsupported" SMT is not supported by the CPU
"notimplemented" SMT runtime toggling is not
@@ -687,3 +688,11 @@
(RO) the list of CPUs that are isolated and don't
participate in load balancing. These CPUs are set by
boot parameter "isolcpus=".
+
+What: /sys/devices/system/cpu/crash_hotplug
+Date: Aug 2023
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ (RO) indicates whether or not the kernel directly supports
+ modifying the crash elfcorehdr for CPU hot un/plug and/or
+ on/offline changes.
diff --git a/Documentation/ABI/testing/sysfs-driver-ccp b/Documentation/ABI/testing/sysfs-driver-ccp
index 7aded9b..ee6b787 100644
--- a/Documentation/ABI/testing/sysfs-driver-ccp
+++ b/Documentation/ABI/testing/sysfs-driver-ccp
@@ -85,3 +85,21 @@
Possible values:
0: Not enforced
1: Enforced
+
+What: /sys/bus/pci/devices/<BDF>/bootloader_version
+Date: June 2023
+KernelVersion: 6.4
+Contact: mario.limonciello@amd.com
+Description:
+ The /sys/bus/pci/devices/<BDF>/bootloader_version
+ file reports the firmware version of the AMD AGESA
+ bootloader.
+
+What: /sys/bus/pci/devices/<BDF>/tee_version
+Date: June 2023
+KernelVersion: 6.4
+Contact: mario.limonciello@amd.com
+Description:
+ The /sys/bus/pci/devices/<BDF>/tee_version
+ file reports the firmware version of the AMD Trusted
+ Execution Environment (TEE).
diff --git a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi
index c308926..d46b1c85 100644
--- a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi
+++ b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi
@@ -1,4 +1,5 @@
What: /sys/bus/platform/devices/GGL0001:*/BINF.2
+ /sys/bus/platform/devices/GOOG0016:*/BINF.2
Date: May 2022
KernelVersion: 5.19
Description:
@@ -10,6 +11,7 @@
== ===============================
What: /sys/bus/platform/devices/GGL0001:*/BINF.3
+ /sys/bus/platform/devices/GOOG0016:*/BINF.3
Date: May 2022
KernelVersion: 5.19
Description:
@@ -23,6 +25,7 @@
== =====================================
What: /sys/bus/platform/devices/GGL0001:*/CHSW
+ /sys/bus/platform/devices/GOOG0016:*/CHSW
Date: May 2022
KernelVersion: 5.19
Description:
@@ -38,6 +41,7 @@
==== ===========================================
What: /sys/bus/platform/devices/GGL0001:*/FMAP
+ /sys/bus/platform/devices/GOOG0016:*/FMAP
Date: May 2022
KernelVersion: 5.19
Description:
@@ -45,6 +49,7 @@
processor firmware flashmap.
What: /sys/bus/platform/devices/GGL0001:*/FRID
+ /sys/bus/platform/devices/GOOG0016:*/FRID
Date: May 2022
KernelVersion: 5.19
Description:
@@ -52,6 +57,7 @@
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/FWID
+ /sys/bus/platform/devices/GOOG0016:*/FWID
Date: May 2022
KernelVersion: 5.19
Description:
@@ -59,6 +65,7 @@
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.0
Date: May 2022
KernelVersion: 5.19
Description:
@@ -73,6 +80,7 @@
=========== ==================================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.1
Date: May 2022
KernelVersion: 5.19
Description:
@@ -84,6 +92,7 @@
== =======================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.2
Date: May 2022
KernelVersion: 5.19
Description:
@@ -91,18 +100,21 @@
controller.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns name of the GPIO controller.
What: /sys/bus/platform/devices/GGL0001:*/HWID
+ /sys/bus/platform/devices/GOOG0016:*/HWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns hardware ID for the Chromebook.
What: /sys/bus/platform/devices/GGL0001:*/MECK
+ /sys/bus/platform/devices/GOOG0016:*/MECK
Date: May 2022
KernelVersion: 5.19
Description:
@@ -113,6 +125,7 @@
present, or if the firmware was unable to read the extended registers, this buffer size can be zero.
What: /sys/bus/platform/devices/GGL0001:*/VBNV.0
+ /sys/bus/platform/devices/GOOG0016:*/VBNV.0
Date: May 2022
KernelVersion: 5.19
Description:
@@ -122,6 +135,7 @@
clock data).
What: /sys/bus/platform/devices/GGL0001:*/VBNV.1
+ /sys/bus/platform/devices/GOOG0016:*/VBNV.1
Date: May 2022
KernelVersion: 5.19
Description:
@@ -129,9 +143,10 @@
storage block.
What: /sys/bus/platform/devices/GGL0001:*/VDAT
+ /sys/bus/platform/devices/GOOG0016:*/VDAT
Date: May 2022
KernelVersion: 5.19
Description:
Returns the verified boot data block shared between the
firmware verification step and the kernel verification step
- (binary).
+ (hex dump).
diff --git a/Documentation/ABI/testing/sysfs-driver-ge-achc b/Documentation/ABI/testing/sysfs-driver-ge-achc
index a9e7a07..c3e77de 100644
--- a/Documentation/ABI/testing/sysfs-driver-ge-achc
+++ b/Documentation/ABI/testing/sysfs-driver-ge-achc
@@ -5,7 +5,7 @@
firmware via the EzPort interface. For this the kernel
will load "achc.bin" via the firmware API (so usually
from /lib/firmware). The write will block until the FW
- has either been flashed successfully or an error occured.
+ has either been flashed successfully or an error occurred.
What: /sys/bus/spi/<dev>/reset
Date: Jul 2021
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
index 69f5af6..b8936fa 100644
--- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
@@ -3,7 +3,7 @@
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
- data programmed at the factory. The data is layed out in 32bit
+ data programmed at the factory. The data is laid out in 32bit
words in LSB first format. Each bit represents a single value
as decoded from the fuse registers. Bits order/assignment
exactly matches the HW registers, including any unused bits.
diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs
index e487f96..0c7efaf 100644
--- a/Documentation/ABI/testing/sysfs-driver-ufs
+++ b/Documentation/ABI/testing/sysfs-driver-ufs
@@ -1437,180 +1437,6 @@
If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to
be flushed, otherwise it is not necessary.
-What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
-What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the HPB specification version.
- The full information about the descriptor can be found in the UFS
- HPB (Host Performance Booster) Extension specifications.
- Example: version 1.2.3 = 0123h
-
- The file is read only.
-
-What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control
-What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_control
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows an indication of the HPB control mode.
- 00h: Host control mode
- 01h: Device control mode
-
- The file is read only.
-
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_region_size
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the bHPBRegionSize which can be calculated
- as in the following (in bytes):
- HPB Region size = 512B * 2^bHPBRegionSize
-
- The file is read only.
-
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_number_lu
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum number of HPB LU supported by
- the device.
- 00h: HPB is not supported by the device.
- 01h ~ 20h: Maximum number of HPB LU supported by the device
-
- The file is read only.
-
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_subregion_size
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the bHPBSubRegionSize, which can be
- calculated as in the following (in bytes) and shall be a multiple of
- logical block size:
- HPB Sub-Region size = 512B x 2^bHPBSubRegionSize
- bHPBSubRegionSize shall not exceed bHPBRegionSize.
-
- The file is read only.
-
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_max_active_regions
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum number of active HPB regions that
- is supported by the device.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum number of HPB regions assigned to
- the HPB logical unit.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the start offset of HPB pinned region.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of HPB pinned regions assigned to
- the HPB logical unit.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of reads that changed to HPB read.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of reads that cannot be changed to
- HPB read.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_noti_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of response UPIUs that has
- recommendations for activating sub-regions and/or inactivating region.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_active_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: For the HPB device control mode, this entry shows the number of
- active sub-regions recommended by response UPIUs. For the HPB host control
- mode, this entry shows the number of active sub-regions recommended by the
- HPB host control mode heuristic algorithm.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_inactive_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: For the HPB device control mode, this entry shows the number of
- inactive regions recommended by response UPIUs. For the HPB host control
- mode, this entry shows the number of inactive regions recommended by the
- HPB host control mode heuristic algorithm.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of read buffer commands for
- activating sub-regions recommended by response UPIUs.
-
- The file is read only.
-
-What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the requeue timeout threshold for write buffer
- command in ms. The value can be changed by writing an integer to
- this entry.
-
-What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd
-What: /sys/bus/platform/devices/*.ufs/attributes/max_data_size_hpb_single_cmd
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum HPB data size for using a single HPB
- command.
-
- === ========
- 00h 4KB
- 01h 8KB
- 02h 12KB
- ...
- FFh 1024KB
- === ========
-
- The file is read only.
-
-What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable
-What: /sys/bus/platform/devices/*.ufs/flags/hpb_enable
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the status of HPB.
-
- == ============================
- 0 HPB is not enabled.
- 1 HPB is enabled
- == ============================
-
- The file is read only.
-
Contact: Daniil Lunev <dlunev@chromium.org>
What: /sys/bus/platform/drivers/ufshcd/*/capabilities/
What: /sys/bus/platform/devices/*.ufs/capabilities/
@@ -1648,76 +1474,3 @@
The file is read only.
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In host control mode, reads are the major source of activation
- trials. Once this threshold hs met, the region is added to the
- "to-be-activated" list. Since we reset the read counter upon
- write, this include sending a rb command updating the region
- ppn as well.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In host control mode, we think of the regions as "buckets".
- Those buckets are being filled with reads, and emptied on write.
- We use entries_per_srgn - the amount of blocks in a subregion as
- our bucket size. This applies because HPB1.0 only handles
- single-block reads. Once the bucket size is crossed, we trigger
- a normalization work - not only to avoid overflow, but mainly
- because we want to keep those counters normalized, as we are
- using those reads as a comparative score, to make various decisions.
- The normalization is dividing (shift right) the read counter by
- the normalization_factor. If during consecutive normalizations
- an active region has exhausted its reads - inactivate it.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: Region deactivation is often due to the fact that eviction took
- place: A region becomes active at the expense of another. This is
- happening when the max-active-regions limit has been crossed.
- In host mode, eviction is considered an extreme measure. We
- want to verify that the entering region has enough reads, and
- the exiting region has much fewer reads. eviction_thld_enter is
- the min reads that a region must have in order to be considered
- a candidate for evicting another region.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: Same as above for the exiting region. A region is considered to
- be a candidate for eviction only if it has fewer reads than
- eviction_thld_exit.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In order not to hang on to "cold" regions, we inactivate
- a region that has no READ access for a predefined amount of
- time - read_timeout_ms. If read_timeout_ms has expired, and the
- region is dirty, it is less likely that we can make any use of
- HPB reading it so we inactivate it. Still, deactivation has
- its overhead, and we may still benefit from HPB reading this
- region if it is clean - see read_timeout_expiries.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: If the region read timeout has expired, but the region is clean,
- just re-wind its timer for another spin. Do that as long as it
- is clean and did not exhaust its read_timeout_expiries threshold.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: The frequency with which the delayed worker that checks the
- read_timeouts is awakened.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In host control mode the host is the originator of map requests.
- To avoid flooding the device with map requests, use a simple throttling
- mechanism that limits the number of inflight map requests.
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index 819939d..5249ad5 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -84,7 +84,7 @@
hotplug events associated with the given class of
devices and will allow those devices to be ejected with
the help of the _EJ0 control method. Unsetting it
- effectively disables hotplug for the correspoinding
+ effectively disables hotplug for the corresponding
class of devices.
======== =======================================================
diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
index 12ed843..7fe9244 100644
--- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
+++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
@@ -102,12 +102,12 @@
conn_port
The conn_hub entry contains a value representing the unique
- oridinal value of the hub on the other end of the fabric
+ ordinal 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
+ ordinal 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.
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 8140fc9..36c3cb5 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -54,9 +54,9 @@
0x00 DISABLE disable IPU(=default option in LFS mode)
0x01 FORCE all the time
0x02 SSR if SSR mode is activated
- 0x04 UTIL if FS utilization is over threashold
+ 0x04 UTIL if FS utilization is over threshold
0x08 SSR_UTIL if SSR mode is activated and FS utilization is over
- threashold
+ threshold
0x10 FSYNC activated in fsync path only for high performance
flash storages. IPU will be triggered only if the
# of dirty pages over min_fsync_blocks.
@@ -102,9 +102,9 @@
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description: Controls the issue rate of discard commands that consist of small
- blocks less than 2MB. The candidates to be discarded are cached until
- checkpoint is triggered, and issued during the checkpoint.
- By default, it is disabled with 0.
+ blocks less than 2MB. The candidates to be discarded are cached during
+ checkpoint, and issued by issue_discard thread after checkpoint.
+ It is enabled by default.
What: /sys/fs/f2fs/<disk>/max_ordered_discard
Date: October 2022
@@ -117,7 +117,7 @@
Contact: "Konstantin Vyshetsky" <vkon@google.com>
Description: Controls the number of discards a thread will issue at a time.
Higher number will allow the discard thread to finish its work
- faster, at the cost of higher latency for incomming I/O.
+ faster, at the cost of higher latency for incoming I/O.
What: /sys/fs/f2fs/<disk>/min_discard_issue_time
Date: December 2021
@@ -334,7 +334,7 @@
state. 2048 trials is set by default.
What: /sys/fs/f2fs/<disk>/extension_list
-Date: Feburary 2018
+Date: February 2018
Contact: "Chao Yu" <yuchao0@huawei.com>
Description: Used to control configure extension list:
- Query: cat /sys/fs/f2fs/<disk>/extension_list
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index 2744f21..420b30f 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -29,8 +29,10 @@
file updates contents of schemes stats files of the kdamond.
Writing 'update_schemes_tried_regions' to the file updates
contents of 'tried_regions' directory of every scheme directory
- of this kdamond. Writing 'clear_schemes_tried_regions' to the
- file removes contents of the 'tried_regions' directory.
+ of this kdamond. Writing 'update_schemes_tried_bytes' to the
+ file updates only '.../tried_regions/total_bytes' files of this
+ kdamond. Writing 'clear_schemes_tried_regions' to the file
+ removes contents of the 'tried_regions' directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid
Date: Mar 2022
@@ -152,7 +154,7 @@
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
-Description: Writing to and reading from this file sets and gets the mimimum
+Description: Writing to and reading from this file sets and gets the minimum
size of the scheme's target regions in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/max
@@ -269,8 +271,10 @@
Date: Dec 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the type of
- the memory of the interest. 'anon' for anonymous pages, or
- 'memcg' for specific memory cgroup can be written and read.
+ the memory of the interest. 'anon' for anonymous pages,
+ 'memcg' for specific memory cgroup, 'addr' for address range
+ (an open-ended interval), or 'target' for DAMON monitoring
+ target can be written and read.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/memcg_path
Date: Dec 2022
@@ -279,6 +283,27 @@
reading from this file sets and gets the path to the memory
cgroup of the interest.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_start
+Date: Jul 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'addr' is written to the 'type' file, writing to or reading
+ from this file sets or gets the start address of the address
+ range for the filter.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_end
+Date: Jul 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'addr' is written to the 'type' file, writing to or reading
+ from this file sets or gets the end address of the address
+ range for the filter.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/target_idx
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'target' is written to the 'type' file, writing to or
+ reading from this file sets or gets the index of the DAMON
+ monitoring target of the interest.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/matching
Date: Dec 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -317,6 +342,13 @@
Description: Reading this file returns the number of the exceed events of
the scheme's quotas.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/total_bytes
+Date: Jul 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the total amount of memory that
+ corresponding DAMON-based Operation Scheme's action has tried
+ to be applied.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/start
Date: Oct 2022
Contact: SeongJae Park <sj@kernel.org>
diff --git a/Documentation/ABI/testing/sysfs-memory-page-offline b/Documentation/ABI/testing/sysfs-memory-page-offline
index e14703f..00f4e35 100644
--- a/Documentation/ABI/testing/sysfs-memory-page-offline
+++ b/Documentation/ABI/testing/sysfs-memory-page-offline
@@ -10,7 +10,7 @@
dropping it if possible. The kernel will then be placed
on the bad page list and never be reused.
- The offlining is done in kernel specific granuality.
+ The offlining is done in kernel specific granularity.
Normally it's the base page size of the kernel, but
this might change.
@@ -35,7 +35,7 @@
to access this page assuming it's poisoned by the
hardware.
- The offlining is done in kernel specific granuality.
+ The offlining is done in kernel specific granularity.
Normally it's the base page size of the kernel, but
this might change.
diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Documentation/ABI/testing/sysfs-platform-asus-wmi
index a77a004..8a7e25b 100644
--- a/Documentation/ABI/testing/sysfs-platform-asus-wmi
+++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi
@@ -98,3 +98,91 @@
Enable an LCD response-time boost to reduce or remove ghosting:
* 0 - Disable,
* 1 - Enable
+
+What: /sys/devices/platform/<platform>/charge_mode
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Get the current charging mode being used:
+ * 1 - Barrel connected charger,
+ * 2 - USB-C charging
+ * 3 - Both connected, barrel used for charging
+
+What: /sys/devices/platform/<platform>/egpu_connected
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Show if the egpu (XG Mobile) is correctly connected:
+ * 0 - False,
+ * 1 - True
+
+What: /sys/devices/platform/<platform>/mini_led_mode
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Change the mini-LED mode:
+ * 0 - Single-zone,
+ * 1 - Multi-zone
+
+What: /sys/devices/platform/<platform>/ppt_pl1_spl
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the Package Power Target total of CPU: PL1 on Intel, SPL on AMD.
+ Shown on Intel+Nvidia or AMD+Nvidia based systems:
+
+ * min=5, max=250
+
+What: /sys/devices/platform/<platform>/ppt_pl2_sppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the Slow Package Power Tracking Limit of CPU: PL2 on Intel, SPPT,
+ on AMD. Shown on Intel+Nvidia or AMD+Nvidia based systems:
+
+ * min=5, max=250
+
+What: /sys/devices/platform/<platform>/ppt_fppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the Fast Package Power Tracking Limit of CPU. AMD+Nvidia only:
+ * min=5, max=250
+
+What: /sys/devices/platform/<platform>/ppt_apu_sppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the APU SPPT limit. Shown on full AMD systems only:
+ * min=5, max=130
+
+What: /sys/devices/platform/<platform>/ppt_platform_sppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the platform SPPT limit. Shown on full AMD systems only:
+ * min=5, max=130
+
+What: /sys/devices/platform/<platform>/nv_dynamic_boost
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the dynamic boost limit of the Nvidia dGPU:
+ * min=5, max=25
+
+What: /sys/devices/platform/<platform>/nv_temp_target
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ Set the target temperature limit of the Nvidia dGPU:
+ * min=75, max=87
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
index 82bcfe9..7015296 100644
--- a/Documentation/ABI/testing/sysfs-platform-dell-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
@@ -15,7 +15,7 @@
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali@kernel.org>
Description:
- This file allows to specifiy the on/off threshold value,
+ This file allows to specify the on/off threshold value,
as reported by the ambient light sensor.
What: /sys/class/leds/dell::kbd_backlight/start_triggers
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
index d6ab34e..2d5b78d 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
@@ -90,7 +90,7 @@
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to get errors detected on FME.
Write this file to clear errors logged in fme_errors. Write
- fials with -EINVAL if input parsing fails or input error code
+ fails with -EINVAL if input parsing fails or input error code
doesn't match.
What: /sys/bus/platform/devices/dfl-fme.0/errors/first_error
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma b/Documentation/ABI/testing/sysfs-platform-hidma
index fca40a5..a80aeda 100644
--- a/Documentation/ABI/testing/sysfs-platform-hidma
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -2,7 +2,7 @@
/sys/devices/platform/QCOM8061:*/chid
Date: Dec 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the ID of the channel within the HIDMA instance.
It is used to associate a given HIDMA channel with the
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
index 3b6c5c9..0373745 100644
--- a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -2,7 +2,7 @@
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains either 0 or 1 and indicates if the DMA channel is a
low priority (0) or high priority (1) channel.
@@ -11,7 +11,7 @@
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains 0..15 and indicates the weight of the channel among
equal priority channels during round robin scheduling.
@@ -20,7 +20,7 @@
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the platform specific cycle value to wait after a
reset command is issued. If the value is chosen too short,
@@ -32,7 +32,7 @@
/sys/devices/platform/QCOM8060:*/dma_channels
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the number of dma channels supported by one instance
of HIDMA hardware. The value may change from chip to chip.
@@ -41,7 +41,7 @@
/sys/devices/platform/QCOM8060:*/hw_version_major
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Version number major for the hardware.
@@ -49,7 +49,7 @@
/sys/devices/platform/QCOM8060:*/hw_version_minor
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Version number minor for the hardware.
@@ -57,7 +57,7 @@
/sys/devices/platform/QCOM8060:*/max_rd_xactions
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains a value between 0 and 31. Maximum number of
read transactions that can be issued back to back.
@@ -69,7 +69,7 @@
/sys/devices/platform/QCOM8060:*/max_read_request
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Size of each read request. The value needs to be a power
of two and can be between 128 and 1024.
@@ -78,7 +78,7 @@
/sys/devices/platform/QCOM8060:*/max_wr_xactions
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains a value between 0 and 31. Maximum number of
write transactions that can be issued back to back.
@@ -91,7 +91,7 @@
/sys/devices/platform/QCOM8060:*/max_write_request
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Size of each write request. The value needs to be a power
of two and can be between 128 and 1024.
diff --git a/Documentation/ABI/testing/sysfs-platform-kim b/Documentation/ABI/testing/sysfs-platform-kim
index 6a52d6d..0a38caa 100644
--- a/Documentation/ABI/testing/sysfs-platform-kim
+++ b/Documentation/ABI/testing/sysfs-platform-kim
@@ -9,7 +9,7 @@
The device name flows down to architecture specific board
initialization file from the ATAGS bootloader
firmware. The name exposed is read from the user-space
- dameon and opens the device when install is requested.
+ daemon and opens the device when install is requested.
What: /sys/devices/platform/kim/baud_rate
Date: January 2010
diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
index 4c5c02d..65ed386 100644
--- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
+++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
@@ -84,3 +84,69 @@
The file used to write BlueField boot log with the format
"[INFO|WARN|ERR|ASSERT ]<msg>". Log level 'INFO' is used by
default if not specified.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/oob_mac
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "oob_mac" sysfs attribute holds the MAC address for
+ the out-of-band 1Gbps Ethernet port. This MAC address is
+ provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/opn
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "opn" sysfs attribute holds the board's part number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/sku
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "sku" sysfs attribute holds the board's SKU number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/modl
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "modl" sysfs attribute holds the board's model number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/sn
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "sn" sysfs attribute holds the board's serial number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/uuid
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "uuid" sysfs attribute holds the board's UUID.
+ This value is provided by the manufacturing team.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/rev
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "rev" sysfs attribute holds the board's revision.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/mfg_lock
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "mfg_lock" sysfs attribute is write-only.
+ A successful write to this attribute will latch the
+ board-level attributes into EEPROM, making them read-only.
diff --git a/Documentation/ABI/testing/sysfs-platform-power-on-reason b/Documentation/ABI/testing/sysfs-platform-power-on-reason
new file mode 100644
index 0000000..c3b29db
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-power-on-reason
@@ -0,0 +1,12 @@
+What: /sys/devices/platform/.../power_on_reason
+Date: June 2023
+KernelVersion: 6.5
+Contact: Kamel Bouhara <kamel.bouhara@bootlin.com>
+Description: Shows system power on reason. The following strings/reasons can
+ be read (the list can be extended):
+ "regular power-up", "RTC wakeup", "watchdog timeout",
+ "software reset", "reset button action", "CPU clock failure",
+ "crystal oscillator failure", "brown-out reset",
+ "unknown reason".
+
+ The file is read only.
diff --git a/Documentation/ABI/testing/sysfs-platform-sst-atom b/Documentation/ABI/testing/sysfs-platform-sst-atom
index 0154b0f..4bb2e61 100644
--- a/Documentation/ABI/testing/sysfs-platform-sst-atom
+++ b/Documentation/ABI/testing/sysfs-platform-sst-atom
@@ -4,7 +4,7 @@
Contact: "Sebastien Guiriec" <sebastien.guiriec@intel.com>
Description:
LPE Firmware version for SST driver on all atom
- plaforms (BYT/CHT/Merrifield/BSW).
+ platforms (BYT/CHT/Merrifield/BSW).
If the FW has never been loaded it will display::
"FW not yet loaded"
diff --git a/Documentation/ABI/testing/sysfs-wusb_cbaf b/Documentation/ABI/testing/sysfs-wusb_cbaf
deleted file mode 100644
index 2969d36..0000000
--- a/Documentation/ABI/testing/sysfs-wusb_cbaf
+++ /dev/null
@@ -1,101 +0,0 @@
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_*
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Various files for managing Cable Based Association of
- (wireless) USB devices.
-
- The sequence of operations should be:
-
- 1. Device is plugged in.
-
- 2. The connection manager (CM) sees a device with CBA capability.
- (the wusb_chid etc. files in /sys/devices/blah/OURDEVICE).
-
- 3. The CM writes the host name, supported band groups,
- and the CHID (host ID) into the wusb_host_name,
- wusb_host_band_groups and wusb_chid files. These
- get sent to the device and the CDID (if any) for
- this host is requested.
-
- 4. The CM can verify that the device's supported band
- groups (wusb_device_band_groups) are compatible
- with the host.
-
- 5. The CM reads the wusb_cdid file.
-
- 6. The CM looks it up its database.
-
- - If it has a matching CHID,CDID entry, the device
- has been authorized before and nothing further
- needs to be done.
-
- - If the CDID is zero (or the CM doesn't find a
- matching CDID in its database), the device is
- assumed to be not known. The CM may associate
- the host with device by: writing a randomly
- generated CDID to wusb_cdid and then a random CK
- to wusb_ck (this uploads the new CC to the
- device).
-
- CMD may choose to prompt the user before
- associating with a new device.
-
- 7. Device is unplugged.
-
- References:
- [WUSB-AM]
- Association Models Supplement to the
- Certified Wireless Universal Serial Bus
- Specification, version 1.0.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_chid
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The CHID of the host formatted as 16 space-separated
- hex octets.
-
- Writes fetches device's supported band groups and the
- the CDID for any existing association with this host.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_name
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- A friendly name for the host as a UTF-8 encoded string.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_band_groups
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The band groups supported by the host, in the format
- defined in [WUSB-AM].
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_device_band_groups
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The band groups supported by the device, in the format
- defined in [WUSB-AM].
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_cdid
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The device's CDID formatted as 16 space-separated hex
- octets.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_ck
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Write 16 space-separated random, hex octets to
- associate with the device.
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 023fa65..2f35793 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -59,6 +59,12 @@
KERNELDOC = $(srctree)/scripts/kernel-doc
KERNELDOC_CONF = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC)
ALLSPHINXOPTS = $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) $(SPHINXOPTS)
+ifneq ($(wildcard $(srctree)/.config),)
+ifeq ($(CONFIG_RUST),y)
+ # Let Sphinx know we will include rustdoc
+ ALLSPHINXOPTS += -t rustdoc
+endif
+endif
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
@@ -95,6 +101,16 @@
@$(srctree)/scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var)))
+# If Rust support is available and .config exists, add rustdoc generated contents.
+# If there are any, the errors from this make rustdoc will be displayed but
+# won't stop the execution of htmldocs
+
+ifneq ($(wildcard $(srctree)/.config),)
+ifeq ($(CONFIG_RUST),y)
+ $(Q)$(MAKE) rustdoc || true
+endif
+endif
+
texinfodocs:
@$(srctree)/scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,texinfo,$(var),texinfo,$(var)))
diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
index c237596..0c7552a 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -17,7 +17,7 @@
and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
pSeries boxes. A typical action taken is to disconnect the affected device,
halting all I/O to it. The goal of a disconnection is to avoid system
-corruption; for example, to halt system memory corruption due to DMA's
+corruption; for example, to halt system memory corruption due to DMAs
to "wild" addresses. Typically, a reconnection mechanism is also
offered, so that the affected PCI device(s) are reset and put back
into working condition. The reset phase requires coordination
@@ -178,9 +178,9 @@
complex and not worth implementing.
The current powerpc implementation doesn't much care if the device
- attempts I/O at this point, or not. I/O's will fail, returning
+ attempts I/O at this point, or not. I/Os will fail, returning
a value of 0xff on read, and writes will be dropped. If more than
- EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH
+ EEH_MAX_FAILS I/Os are attempted to a frozen adapter, EEH
assumes that the device driver has gone into an infinite loop
and prints an error to syslog. A reboot is then required to
get the device working again.
@@ -204,7 +204,7 @@
.. note::
The following is proposed; no platform implements this yet:
- Proposal: All I/O's should be done _synchronously_ from within
+ Proposal: All I/Os should be done _synchronously_ from within
this callback, errors triggered by them will be returned via
the normal pci_check_whatever() API, no new error_detected()
callback will be issued due to an error happening here. However,
@@ -258,7 +258,7 @@
soft reset(default) and fundamental(optional) reset.
Powerpc soft reset consists of asserting the adapter #RST line and then
-restoring the PCI BAR's and PCI configuration header to a state
+restoring the PCI BARs and PCI configuration header to a state
that is equivalent to what it would be after a fresh system
power-on followed by power-on BIOS/system firmware initialization.
Soft reset is also known as hot-reset.
@@ -362,7 +362,7 @@
the operator will probably want to remove and replace the device.
Note, however, not all failures are truly "permanent". Some are
caused by over-heating, some by a poorly seated card. Many
-PCI error events are caused by software bugs, e.g. DMA's to
+PCI error events are caused by software bugs, e.g. DMAs to
wild addresses or bogus split transactions due to programming
errors. See the discussion in Documentation/powerpc/eeh-pci-error-recovery.rst
for additional detail on real-life experience of the causes of
diff --git a/Documentation/PCI/pciebus-howto.rst b/Documentation/PCI/pciebus-howto.rst
index f882ff6..a0027e8 100644
--- a/Documentation/PCI/pciebus-howto.rst
+++ b/Documentation/PCI/pciebus-howto.rst
@@ -213,8 +213,12 @@
--------------------
Each service driver runs its PCI config operations on its own
-capability structure except the PCI Express capability structure, in
-which Root Control register and Device Control register are shared
-between PME and AER. This patch assumes that all service drivers
-will be well behaved and not overwrite other service driver's
-configuration settings.
+capability structure except the PCI Express capability structure,
+that is shared between many drivers including the service drivers.
+RMW Capability accessors (pcie_capability_clear_and_set_word(),
+pcie_capability_set_word(), and pcie_capability_clear_word()) protect
+a selected set of PCI Express Capability Registers (Link Control
+Register and Root Control Register). Any change to those registers
+should be performed using RMW accessors to avoid problems due to
+concurrent updates. For the up-to-date list of protected registers,
+see pcie_capability_clear_and_set_word().
diff --git a/Documentation/RCU/lockdep-splat.rst b/Documentation/RCU/lockdep-splat.rst
index 2a5c79d..bcbc4b3 100644
--- a/Documentation/RCU/lockdep-splat.rst
+++ b/Documentation/RCU/lockdep-splat.rst
@@ -10,7 +10,7 @@
family to access an RCU-protected pointer without the proper protection.
When such misuse is detected, an lockdep-RCU splat is emitted.
-The usual cause of a lockdep-RCU slat is someone accessing an
+The usual cause of a lockdep-RCU splat is someone accessing an
RCU-protected data structure without either (1) being in the right kind of
RCU read-side critical section or (2) holding the right update-side lock.
This problem can therefore be serious: it might result in random memory
diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst
index 9a734bf..21e40fc 100644
--- a/Documentation/RCU/rculist_nulls.rst
+++ b/Documentation/RCU/rculist_nulls.rst
@@ -18,7 +18,16 @@
Without 'nulls', a typical RCU linked list managing objects which are
allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following
-algorithms:
+algorithms. Following examples assume 'obj' is a pointer to such
+objects, which is having below type.
+
+::
+
+ struct object {
+ struct hlist_node obj_node;
+ atomic_t refcnt;
+ unsigned int key;
+ };
1) Lookup algorithm
-------------------
@@ -26,11 +35,13 @@
::
begin:
- rcu_read_lock()
+ rcu_read_lock();
obj = lockless_lookup(key);
if (obj) {
- if (!try_get_ref(obj)) // might fail for free objects
+ if (!try_get_ref(obj)) { // might fail for free objects
+ rcu_read_unlock();
goto begin;
+ }
/*
* Because a writer could delete object, and a writer could
* reuse these object before the RCU grace period, we
@@ -54,7 +65,7 @@
struct hlist_node *node, *next;
for (pos = rcu_dereference((head)->first);
pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
- ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
+ ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
pos = rcu_dereference(next))
if (obj->key == key)
return obj;
@@ -66,10 +77,10 @@
struct hlist_node *node;
for (pos = rcu_dereference((head)->first);
pos && ({ prefetch(pos->next); 1; }) &&
- ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
+ ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
pos = rcu_dereference(pos->next))
- if (obj->key == key)
- return obj;
+ if (obj->key == key)
+ return obj;
return NULL;
Quoting Corey Minyard::
@@ -86,7 +97,7 @@
2) Insertion algorithm
----------------------
-We need to make sure a reader cannot read the new 'obj->obj_next' value
+We need to make sure a reader cannot read the new 'obj->obj_node.next' value
and previous value of 'obj->key'. Otherwise, an item could be deleted
from a chain, and inserted into another chain. If new chain was empty
before the move, 'next' pointer is NULL, and lockless reader can not
@@ -129,8 +140,7 @@
Avoiding extra smp_rmb()
========================
-With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
-and extra _release() in insert function.
+With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup().
For example, if we choose to store the slot number as the 'nulls'
end-of-list marker for each slot of the hash table, we can detect
@@ -142,6 +152,9 @@
then the reader doesn't care: It might occasionally
scan the list again without harm.
+Note that using hlist_nulls means the type of 'obj_node' field of
+'struct object' becomes 'struct hlist_nulls_node'.
+
1) lookup algorithm
-------------------
@@ -151,7 +164,7 @@
head = &table[slot];
begin:
rcu_read_lock();
- hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
+ hlist_nulls_for_each_entry_rcu(obj, node, head, obj_node) {
if (obj->key == key) {
if (!try_get_ref(obj)) { // might fail for free objects
rcu_read_unlock();
@@ -182,6 +195,9 @@
2) Insert algorithm
-------------------
+Same to the above one, but uses hlist_nulls_add_head_rcu() instead of
+hlist_add_head_rcu().
+
::
/*
diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst
index df6062e..d455db3 100644
--- a/Documentation/accounting/psi.rst
+++ b/Documentation/accounting/psi.rst
@@ -178,7 +178,7 @@
Cgroup2 interface
=================
-In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem
+In a system with a CONFIG_CGROUPS=y kernel and the cgroup2 filesystem
mounted, pressure stall information is also tracked for tasks grouped
into cgroups. Each subdirectory in the cgroupfs mountpoint contains
cpu.pressure, memory.pressure, and io.pressure files; the format is
diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index a402359..1f12845 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -62,7 +62,7 @@
At cancel(), simply usage -= PAGE_SIZE.
-Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
+Under below explanation, we assume CONFIG_SWAP=y.
4. Anonymous
============
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
index fabaad3..5f502bf 100644
--- a/Documentation/admin-guide/cgroup-v1/memory.rst
+++ b/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -92,8 +92,6 @@
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
- memory.kmem.limit_in_bytes This knob is deprecated and writing to
- it will return -ENOTSUPP.
memory.kmem.usage_in_bytes show current kernel memory allocation
memory.kmem.failcnt show the number of kernel memory usage
hits limits
@@ -197,11 +195,11 @@
RSS pages are accounted at page_fault unless they've already been accounted
for earlier. A file page will be accounted for as Page Cache when it's
-inserted into inode (radix-tree). While it's mapped into the page tables of
+inserted into inode (xarray). While it's mapped into the page tables of
processes, duplicate accounting is carefully avoided.
An RSS page is unaccounted when it's fully unmapped. A PageCache page is
-unaccounted when it's removed from radix-tree. Even if RSS pages are fully
+unaccounted when it's removed from xarray. Even if RSS pages are fully
unmapped (by kswapd), they may exist as SwapCache in the system until they
are really freed. Such SwapCaches are also accounted.
A swapped-in page is accounted after adding into swapcache.
@@ -909,7 +907,7 @@
notification, i.e. groups A and B will not receive it. This is done to avoid
excessive "broadcasting" of messages, which disturbs the system and which is
especially bad if we are low on memory or thrashing. Group B, will receive
-notification only if there are no event listers for group C.
+notification only if there are no event listeners for group C.
There are three optional modes that specify different propagation behavior:
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 4ef8901..b26b527 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1045,7 +1045,7 @@
- user_usec
- system_usec
- and the following three when the controller is enabled:
+ and the following five when the controller is enabled:
- nr_periods
- nr_throttled
diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt
index b1b57f6..8390549 100644
--- a/Documentation/admin-guide/devices.txt
+++ b/Documentation/admin-guide/devices.txt
@@ -2691,18 +2691,9 @@
45 = /dev/ttyMM1 Marvell MPSC - port 1 (obsolete unused)
46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
...
- 49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 3
- 50 = /dev/ttyIOC0 Altix serial card
- ...
- 81 = /dev/ttyIOC31 Altix serial card
+ 51 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
82 = /dev/ttyVR0 NEC VR4100 series SIU
83 = /dev/ttyVR1 NEC VR4100 series DSIU
- 84 = /dev/ttyIOC84 Altix ioc4 serial card
- ...
- 115 = /dev/ttyIOC115 Altix ioc4 serial card
- 116 = /dev/ttySIOC0 Altix ioc3 serial card
- ...
- 147 = /dev/ttySIOC31 Altix ioc3 serial card
148 = /dev/ttyPSC0 PPC PSC - port 0
...
153 = /dev/ttyPSC5 PPC PSC - port 5
@@ -2761,10 +2752,7 @@
43 = /dev/ttycusmx2 Callout device for ttySMX2
46 = /dev/cucpm0 Callout device for ttyCPM0
...
- 49 = /dev/cucpm5 Callout device for ttyCPM5
- 50 = /dev/cuioc40 Callout device for ttyIOC40
- ...
- 81 = /dev/cuioc431 Callout device for ttyIOC431
+ 51 = /dev/cucpm5 Callout device for ttyCPM5
82 = /dev/cuvr0 Callout device for ttyVR0
83 = /dev/cuvr1 Callout device for ttyVR1
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst
index 8dc668c..0b3d39c 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -216,13 +216,14 @@
t Include thread ID, or <intr>
m Include module name
f Include the function name
+ s Include the source file name
l Include line number
For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only
the ``p`` flag has meaning, other flags are ignored.
-Note the regexp ``^[-+=][flmpt_]+$`` matches a flags specification.
-To clear all flags at once, use ``=_`` or ``-flmpt``.
+Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification.
+To clear all flags at once, use ``=_`` or ``-fslmpt``.
Debug messages during Boot Process
diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst
index a7d37e1..de99caa 100644
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -13,11 +13,11 @@
l1tf
mds
tsx_async_abort
- multihit.rst
- special-register-buffer-data-sampling.rst
- core-scheduling.rst
- l1d_flush.rst
- processor_mmio_stale_data.rst
- cross-thread-rsb.rst
+ multihit
+ special-register-buffer-data-sampling
+ core-scheduling
+ l1d_flush
+ processor_mmio_stale_data
+ cross-thread-rsb
srso
- gather_data_sampling.rst
+ gather_data_sampling
diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst
index 32eb5e6..b6cfb51 100644
--- a/Documentation/admin-guide/hw-vuln/srso.rst
+++ b/Documentation/admin-guide/hw-vuln/srso.rst
@@ -42,42 +42,59 @@
The possible values in this file are:
- - 'Not affected' The processor is not vulnerable
+ * 'Not affected':
- - 'Vulnerable: no microcode' The processor is vulnerable, no
- microcode extending IBPB functionality
- to address the vulnerability has been
- applied.
+ The processor is not vulnerable
- - 'Mitigation: microcode' Extended IBPB functionality microcode
- patch has been applied. It does not
- address User->Kernel and Guest->Host
- transitions protection but it does
- address User->User and VM->VM attack
- vectors.
+ * 'Vulnerable: no microcode':
- (spec_rstack_overflow=microcode)
+ The processor is vulnerable, no microcode extending IBPB
+ functionality to address the vulnerability has been applied.
- - 'Mitigation: safe RET' Software-only mitigation. It complements
- the extended IBPB microcode patch
- functionality by addressing User->Kernel
- and Guest->Host transitions protection.
+ * 'Mitigation: microcode':
- Selected by default or by
- spec_rstack_overflow=safe-ret
+ Extended IBPB functionality microcode patch has been applied. It does
+ not address User->Kernel and Guest->Host transitions protection but it
+ does address User->User and VM->VM attack vectors.
- - 'Mitigation: IBPB' Similar protection as "safe RET" above
- but employs an IBPB barrier on privilege
- domain crossings (User->Kernel,
- Guest->Host).
+ Note that User->User mitigation is controlled by how the IBPB aspect in
+ the Spectre v2 mitigation is selected:
- (spec_rstack_overflow=ibpb)
+ * conditional IBPB:
- - 'Mitigation: IBPB on VMEXIT' Mitigation addressing the cloud provider
- scenario - the Guest->Host transitions
- only.
+ where each process can select whether it needs an IBPB issued
+ around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`
- (spec_rstack_overflow=ibpb-vmexit)
+ * strict:
+
+ i.e., always on - by supplying spectre_v2_user=on on the kernel
+ command line
+
+ (spec_rstack_overflow=microcode)
+
+ * 'Mitigation: safe RET':
+
+ Software-only mitigation. It complements the extended IBPB microcode
+ patch functionality by addressing User->Kernel and Guest->Host
+ transitions protection.
+
+ Selected by default or by spec_rstack_overflow=safe-ret
+
+ * 'Mitigation: IBPB':
+
+ Similar protection as "safe RET" above but employs an IBPB barrier on
+ privilege domain crossings (User->Kernel, Guest->Host).
+
+ (spec_rstack_overflow=ibpb)
+
+ * 'Mitigation: IBPB on VMEXIT':
+
+ Mitigation addressing the cloud provider scenario - the Guest->Host
+ transitions only.
+
+ (spec_rstack_overflow=ibpb-vmexit)
+
+
In order to exploit vulnerability, an attacker needs to:
@@ -124,8 +141,8 @@
To ensure the safety of this mitigation, the kernel must ensure that the
safe return sequence is itself free from attacker interference. In Zen3
and Zen4, this is accomplished by creating a BTB alias between the
-untraining function srso_untrain_ret_alias() and the safe return
-function srso_safe_ret_alias() which results in evicting a potentially
+untraining function srso_alias_untrain_ret() and the safe return
+function srso_alias_safe_ret() which results in evicting a potentially
poisoned BTB entry and using that safe one for all function returns.
In older Zen1 and Zen2, this is accomplished using a reinterpretation
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index f8ebb63..599e8d3 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -141,8 +141,8 @@
The size of a nodemask_t type. Used to compute the number of online
nodes.
-(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|compound_order|compound_head)
--------------------------------------------------------------------------------------------------
+(page, flags|_refcount|mapping|lru|_mapcount|private|compound_order|compound_head)
+----------------------------------------------------------------------------------
User-space tools compute their values based on the offset of these
variables. The variables are used when excluding unnecessary pages.
@@ -325,8 +325,8 @@
On linux-2.6.21 or later, the number of free pages is in
vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
-PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask
-------------------------------------------------------------------------------
+PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask|PG_hugetlb
+-----------------------------------------------------------------------------------------
Page attributes. These flags are used to filter various unnecessary for
dumping pages.
@@ -338,12 +338,6 @@
dumping pages.
-HUGETLB_PAGE_DTOR
------------------
-
-The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile
-excludes these pages.
-
x86_64
======
diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst
index 1ba8f2a..102937b 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -80,7 +80,7 @@
so that "nohz_full=all" is the equivalent of "nohz_full=0-N".
The semantics of "N" and "all" is supported on a level of bitmaps and holds for
-all users of bitmap_parse().
+all users of bitmap_parselist().
This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
@@ -89,10 +89,11 @@
parameters may be changed at runtime by the command
``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``.
-The parameters listed below are only valid if certain kernel build options were
-enabled and if respective hardware is present. The text in square brackets at
-the beginning of each description states the restrictions within which a
-parameter is applicable::
+The parameters listed below are only valid if certain kernel build options
+were enabled and if respective hardware is present. This list should be kept
+in alphabetical order. The text in square brackets at the beginning
+of each description states the restrictions within which a parameter
+is applicable::
ACPI ACPI support is enabled.
AGP AGP (Accelerated Graphics Port) is enabled.
@@ -127,9 +128,9 @@
KGDB Kernel debugger support is enabled.
KVM Kernel Virtual Machine support is enabled.
LIBATA Libata driver is enabled
- LP Printer support is enabled.
LOONGARCH LoongArch architecture is enabled.
LOOP Loopback device support is enabled.
+ LP Printer support is enabled.
M68k M68k architecture is enabled.
These options have more detailed description inside of
Documentation/arch/m68k/kernel-options.rst.
@@ -139,10 +140,9 @@
MSI Message Signaled Interrupts (PCI).
MTD MTD (Memory Technology Device) support is enabled.
NET Appropriate network support is enabled.
- NUMA NUMA support is enabled.
NFS Appropriate NFS support is enabled.
+ NUMA NUMA support is enabled.
OF Devicetree is enabled.
- PV_OPS A paravirtualized kernel is enabled.
PARISC The PA-RISC architecture is enabled.
PCI PCI bus support is enabled.
PCIE PCI Express support is enabled.
@@ -151,9 +151,10 @@
PPC PowerPC architecture is enabled.
PPT Parallel port support is enabled.
PS2 Appropriate PS/2 support is enabled.
+ PV_OPS A paravirtualized kernel is enabled.
RAM RAM disk support is enabled.
- RISCV RISCV architecture is enabled.
RDT Intel Resource Director Technology.
+ RISCV RISCV architecture is enabled.
S390 S390 architecture is enabled.
SCSI Appropriate SCSI support is enabled.
A lot of drivers have their options described inside
@@ -164,15 +165,15 @@
SH SuperH architecture is enabled.
SMP The kernel is an SMP kernel.
SPARC Sparc architecture is enabled.
- SWSUSP Software suspend (hibernation) is enabled.
SUSPEND System suspend states are enabled.
+ SWSUSP Software suspend (hibernation) is enabled.
TPM TPM drivers are enabled.
UMS USB Mass Storage support is enabled.
USB USB support is enabled.
USBHID USB Human Interface Device support is enabled.
V4L Video For Linux support is enabled.
- VMMIO Driver for memory mapped virtio devices is enabled.
VGA The VGA console has been enabled.
+ VMMIO Driver for memory mapped virtio devices is enabled.
VT Virtual terminal support is enabled.
WDT Watchdog support is enabled.
X86-32 X86-32, aka i386 architecture is enabled.
@@ -186,9 +187,9 @@
In addition, the following text indicates that the option::
+ BOOT Is a boot loader parameter.
BUGS= Relates to possible processor bugs on the said processor.
KNL Is a kernel start-up parameter.
- BOOT Is a boot loader parameter.
Parameters denoted with BOOT are actually interpreted by the boot
loader, and have no meaning to the kernel directly.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 722b6ec..0a1731a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -418,20 +418,20 @@
arm64.nobti [ARM64] Unconditionally disable Branch Target
Identification support
- arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication
- support
+ arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
+ Set instructions support
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
support
- arm64.nosve [ARM64] Unconditionally disable Scalable Vector
- Extension support
+ arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication
+ support
arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
Extension support
- arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
- Set instructions support
+ arm64.nosve [ARM64] Unconditionally disable Scalable Vector
+ Extension support
ataflop= [HW,M68k]
@@ -553,7 +553,7 @@
others).
ccw_timeout_log [S390]
- See Documentation/s390/common_io.rst for details.
+ See Documentation/arch/s390/common_io.rst for details.
cgroup_disable= [KNL] Disable a particular controller or optional feature
Format: {name of the controller(s) or feature(s) to disable}
@@ -598,7 +598,7 @@
Setting checkreqprot to 1 is deprecated.
cio_ignore= [S390]
- See Documentation/s390/common_io.rst for details.
+ See Documentation/arch/s390/common_io.rst for details.
clearcpuid=X[,X...] [X86]
Disable CPUID feature X for the kernel. See
@@ -696,7 +696,7 @@
kernel/dma/contiguous.c
cma_pernuma=nn[MG]
- [ARM64,KNL,CMA]
+ [KNL,CMA]
Sets the size of kernel per-numa memory area for
contiguous memory allocations. A value of 0 disables
per-numa CMA altogether. And If this option is not
@@ -706,6 +706,17 @@
which is located in node nid, if the allocation fails,
they will fallback to the global default memory area.
+ numa_cma=<node>:nn[MG][,<node>:nn[MG]]
+ [KNL,CMA]
+ Sets the size of kernel numa memory area for
+ contiguous memory allocations. It will reserve CMA
+ area for the specified node.
+
+ With numa CMA enabled, DMA users on node nid will
+ first try to allocate buffer from the numa area
+ which is located in node nid, if the allocation fails,
+ they will fallback to the global default memory area.
+
cmo_free_hint= [PPC] Format: { yes | no }
Specify whether pages are marked as being inactive
when they are freed. This is used in CMO environments
@@ -862,7 +873,7 @@
memory region [offset, offset + size] for that kernel
image. If '@offset' is omitted, then a suitable offset
is selected automatically.
- [KNL, X86-64, ARM64] Select a region under 4G first, and
+ [KNL, X86-64, ARM64, RISCV] Select a region under 4G first, and
fall back to reserve region above 4G when '@offset'
hasn't been specified.
See Documentation/admin-guide/kdump/kdump.rst for further details.
@@ -875,14 +886,14 @@
Documentation/admin-guide/kdump/kdump.rst for an example.
crashkernel=size[KMG],high
- [KNL, X86-64, ARM64] range could be above 4G. Allow kernel
- to allocate physical memory region from top, so could
- be above 4G if system have more than 4G ram installed.
- Otherwise memory region will be allocated below 4G, if
- available.
+ [KNL, X86-64, ARM64, RISCV] range could be above 4G.
+ Allow kernel to allocate physical memory region from top,
+ so could be above 4G if system have more than 4G ram
+ installed. Otherwise memory region will be allocated
+ below 4G, if available.
It will be ignored if crashkernel=X is specified.
crashkernel=size[KMG],low
- [KNL, X86-64, ARM64] range under 4G. When crashkernel=X,high
+ [KNL, X86-64, ARM64, RISCV] range under 4G. When crashkernel=X,high
is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
@@ -893,6 +904,7 @@
size is platform dependent.
--> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB)
--> arm64: 128MiB
+ --> riscv: 128MiB
This one lets the user specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
@@ -2644,7 +2656,7 @@
kvm-intel.flexpriority=
[KVM,Intel] Control KVM's use of FlexPriority feature
- (TPR shadow). Default is 1 (enabled). Disalbe by KVM if
+ (TPR shadow). Default is 1 (enabled). Disable by KVM if
hardware lacks support for it.
kvm-intel.nested=
@@ -2938,6 +2950,10 @@
locktorture.torture_type= [KNL]
Specify the locking implementation to test.
+ locktorture.writer_fifo= [KNL]
+ Run the write-side locktorture kthreads at
+ sched_set_fifo() real-time priority.
+
locktorture.verbose= [KNL]
Enable additional printk() statements.
@@ -3125,7 +3141,7 @@
[KNL,SH] Allow user to override the default size for
per-device physically contiguous DMA buffers.
- memhp_default_state=online/offline
+ memhp_default_state=online/offline/online_kernel/online_movable
[KNL] Set the initial state for the memory hotplug
onlining policy. If not specified, the default value is
set according to the
@@ -3738,7 +3754,7 @@
nohibernate [HIBERNATION] Disable hibernation and resume.
- nohlt [ARM,ARM64,MICROBLAZE,MIPS,SH] Forces the kernel to
+ nohlt [ARM,ARM64,MICROBLAZE,MIPS,PPC,SH] Forces the kernel to
busy wait in do_idle() and not use the arch_cpu_idle()
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
to be effective. This is useful on platforms where the
@@ -3874,10 +3890,10 @@
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC. legacy for "maxcpus=0".
- nosmt [KNL,MIPS,S390] Disable symmetric multithreading (SMT).
+ nosmt [KNL,MIPS,PPC,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
- [KNL,X86] Disable symmetric multithreading (SMT).
+ [KNL,X86,PPC] Disable symmetric multithreading (SMT).
nosmt=force: Force disable SMT, cannot be undone
via the sysfs control file.
@@ -4058,20 +4074,6 @@
timeout < 0: reboot immediately
Format: <timeout>
- panic_print= Bitmask for printing system info when panic happens.
- User can chose combination of the following bits:
- bit 0: print all tasks info
- bit 1: print system memory info
- bit 2: print timer info
- bit 3: print locks info if CONFIG_LOCKDEP is on
- bit 4: print ftrace buffer
- bit 5: print all printk messages in buffer
- bit 6: print all CPUs backtrace (if available in the arch)
- *Be aware* that this option may print a _lot_ of lines,
- so there are risks of losing older messages in the log.
- Use this option carefully, maybe worth to setup a
- bigger log buffer with "log_buf_len" along with this.
-
panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
Format: <hex>[,nousertaint]
Hexadecimal bitmask representing the set of TAINT flags
@@ -4088,6 +4090,20 @@
panic_on_warn=1 panic() instead of WARN(). Useful to cause kdump
on a WARN().
+ panic_print= Bitmask for printing system info when panic happens.
+ User can chose combination of the following bits:
+ bit 0: print all tasks info
+ bit 1: print system memory info
+ bit 2: print timer info
+ bit 3: print locks info if CONFIG_LOCKDEP is on
+ bit 4: print ftrace buffer
+ bit 5: print all printk messages in buffer
+ bit 6: print all CPUs backtrace (if available in the arch)
+ *Be aware* that this option may print a _lot_ of lines,
+ so there are risks of losing older messages in the log.
+ Use this option carefully, maybe worth to setup a
+ bigger log buffer with "log_buf_len" along with this.
+
parkbd.port= [HW] Parallel port number the keyboard adapter is
connected to, default is 0.
Format: <parport#>
@@ -4207,7 +4223,7 @@
mode 0, bit 1 is for mode 1, and so on. Mode 0 only
allowed by default.
- pause_on_oops=
+ pause_on_oops=<int>
Halt all CPUs after the first oops has been printed for
the specified number of seconds. This is to be used if
your oopses keep scrolling off the screen.
@@ -4949,6 +4965,15 @@
test until boot completes in order to avoid
interference.
+ rcuscale.kfree_by_call_rcu= [KNL]
+ In kernels built with CONFIG_RCU_LAZY=y, test
+ call_rcu() instead of kfree_rcu().
+
+ rcuscale.kfree_mult= [KNL]
+ Instead of allocating an object of size kfree_obj,
+ allocate one of kfree_mult * sizeof(kfree_obj).
+ Defaults to 1.
+
rcuscale.kfree_rcu_test= [KNL]
Set to measure performance of kfree_rcu() flooding.
@@ -4974,6 +4999,12 @@
Number of loops doing rcuscale.kfree_alloc_num number
of allocations and frees.
+ rcuscale.minruntime= [KNL]
+ Set the minimum test run time in seconds. This
+ does not affect the data-collection interval,
+ but instead allows better measurement of things
+ like CPU consumption.
+
rcuscale.nreaders= [KNL]
Set number of RCU readers. The value -1 selects
N, where N is the number of CPUs. A value
@@ -4988,7 +5019,7 @@
the same as for rcuscale.nreaders.
N, where N is the number of CPUs
- rcuscale.perf_type= [KNL]
+ rcuscale.scale_type= [KNL]
Specify the RCU implementation to test.
rcuscale.shutdown= [KNL]
@@ -5004,6 +5035,11 @@
in microseconds. The default of zero says
no holdoff.
+ rcuscale.writer_holdoff_jiffies= [KNL]
+ Additional write-side holdoff between grace
+ periods, but in jiffies. The default of zero
+ says no holdoff.
+
rcutorture.fqs_duration= [KNL]
Set duration of force_quiescent_state bursts
in microseconds.
@@ -5285,6 +5321,13 @@
number avoids disturbing real-time workloads,
but lengthens grace periods.
+ rcupdate.rcu_task_lazy_lim= [KNL]
+ Number of callbacks on a given CPU that will
+ cancel laziness on that CPU. Use -1 to disable
+ cancellation of laziness, but be advised that
+ doing so increases the danger of OOM due to
+ callback flooding.
+
rcupdate.rcu_task_stall_info= [KNL]
Set initial timeout in jiffies for RCU task stall
informational messages, which give some indication
@@ -5314,6 +5357,29 @@
A change in value does not take effect until
the beginning of the next grace period.
+ rcupdate.rcu_tasks_lazy_ms= [KNL]
+ Set timeout in milliseconds RCU Tasks asynchronous
+ callback batching for call_rcu_tasks().
+ A negative value will take the default. A value
+ of zero will disable batching. Batching is
+ always disabled for synchronize_rcu_tasks().
+
+ rcupdate.rcu_tasks_rude_lazy_ms= [KNL]
+ Set timeout in milliseconds RCU Tasks
+ Rude asynchronous callback batching for
+ call_rcu_tasks_rude(). A negative value
+ will take the default. A value of zero will
+ disable batching. Batching is always disabled
+ for synchronize_rcu_tasks_rude().
+
+ rcupdate.rcu_tasks_trace_lazy_ms= [KNL]
+ Set timeout in milliseconds RCU Tasks
+ Trace asynchronous callback batching for
+ call_rcu_tasks_trace(). A negative value
+ will take the default. A value of zero will
+ disable batching. Batching is always disabled
+ for synchronize_rcu_tasks_trace().
+
rcupdate.rcu_self_test= [KNL]
Run the RCU early boot self tests
@@ -5489,6 +5555,13 @@
[KNL] Disable ring 3 MONITOR/MWAIT feature on supported
CPUs.
+ riscv_isa_fallback [RISCV]
+ When CONFIG_RISCV_ISA_FALLBACK is not enabled, permit
+ falling back to detecting extension support by parsing
+ "riscv,isa" property on devicetree systems when the
+ replacement properties are not found. See the Kconfig
+ entry for RISCV_ISA_FALLBACK.
+
ro [KNL] Mount root device read-only on boot
rodata= [KNL]
@@ -5522,6 +5595,10 @@
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rootwait= [KNL] Maximum time (in seconds) to wait for root device
+ to show up before attempting to mount the root
+ filesystem.
+
rproc_mem=nn[KMG][@address]
[KNL,ARM,CMA] Remoteproc physical memory block.
Memory area to be used by remote processor image,
@@ -6275,10 +6352,6 @@
-1: disable all critical trip points in all thermal zones
<degrees C>: override all critical trip points
- thermal.nocrt= [HW,ACPI]
- Set to disable actions on ACPI thermal zone
- critical and hot trip points.
-
thermal.off= [HW,ACPI]
1: disable ACPI thermal control
@@ -6340,6 +6413,13 @@
This will guarantee that all the other pcrs
are saved.
+ tpm_tis.interrupts= [HW,TPM]
+ Enable interrupts for the MMIO based physical layer
+ for the FIFO interface. By default it is set to false
+ (0). For more information about TPM hardware interfaces
+ defined by Trusted Computing Group (TCG) see
+ https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
+
tp_printk [FTRACE]
Have the tracepoints sent to printk as well as the
tracing ring buffer. This is useful for early boot up
@@ -6639,7 +6719,7 @@
usbcore.authorized_default=
[USB] Default USB device authorization:
- (default -1 = authorized except for wireless USB,
+ (default -1 = authorized (same as 1),
0 = not authorized, 1 = authorized, 2 = authorized
if device connected to internal port)
@@ -6996,6 +7076,13 @@
disables both lockup detectors. Default is 10
seconds.
+ workqueue.unbound_cpus=
+ [KNL,SMP] Specify to constrain one or some CPUs
+ to use in unbound workqueues.
+ Format: <cpu-list>
+ By default, all online CPUs are available for
+ unbound workqueues.
+
workqueue.watchdog_thresh=
If CONFIG_WQ_WATCHDOG is configured, workqueue can
warn stall conditions and dump internal state to
@@ -7017,15 +7104,6 @@
threshold repeatedly. They are likely good
candidates for using WQ_UNBOUND workqueues instead.
- workqueue.disable_numa
- By default, all work items queued to unbound
- workqueues are affine to the NUMA nodes they're
- issued on, which results in better behavior in
- general. If NUMA affinity needs to be disabled for
- whatever reason, this option can be used. Note
- that this also can be controlled per-workqueue for
- workqueues visible under /sys/bus/workqueue/.
-
workqueue.power_efficient
Per-cpu workqueues are generally preferred because
they show better performance thanks to cache
@@ -7041,6 +7119,18 @@
The default value of this parameter is determined by
the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
+ workqueue.default_affinity_scope=
+ Select the default affinity scope to use for unbound
+ workqueues. Can be one of "cpu", "smt", "cache",
+ "numa" and "system". Default is "cache". For more
+ information, see the Affinity Scopes section in
+ Documentation/core-api/workqueue.rst.
+
+ This can be changed after boot by writing to the
+ matching /sys/module/workqueue/parameters file. All
+ workqueues with the "default" affinity scope will be
+ updated accordignly.
+
workqueue.debug_force_rr_cpu
Workqueue used to implicitly guarantee that work
items queued without explicit CPU specified are put
diff --git a/Documentation/admin-guide/media/qcom_camss.rst b/Documentation/admin-guide/media/qcom_camss.rst
index a72e17d..8a8f3ff 100644
--- a/Documentation/admin-guide/media/qcom_camss.rst
+++ b/Documentation/admin-guide/media/qcom_camss.rst
@@ -18,7 +18,7 @@
Camera sensor using V4L2 subdev interface in the kernel is supported.
The driver is implemented using as a reference the Qualcomm Camera Subsystem
-driver for Android as found in Code Aurora [#f1]_ [#f2]_.
+driver for Android as found in Code Linaro [#f1]_ [#f2]_.
Qualcomm Camera Subsystem hardware
@@ -181,5 +181,5 @@
References
----------
-.. [#f1] https://source.codeaurora.org/quic/la/kernel/msm-3.10/
-.. [#f2] https://source.codeaurora.org/quic/la/kernel/msm-3.18/
+.. [#f1] https://git.codelinaro.org/clo/la/kernel/msm-3.10/
+.. [#f2] https://git.codelinaro.org/clo/la/kernel/msm-3.18/
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 2d495fa..8da1b72 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -87,7 +87,7 @@
│ │ │ │ │ │ │ filters/nr_filters
│ │ │ │ │ │ │ │ 0/type,matching,memcg_id
│ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
- │ │ │ │ │ │ │ tried_regions/
+ │ │ │ │ │ │ │ tried_regions/total_bytes
│ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
@@ -99,7 +99,7 @@
The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it
has one directory named ``admin``. The directory contains the files for
-privileged user space programs' control of DAMON. User space tools or deamons
+privileged user space programs' control of DAMON. User space tools or daemons
having the root permission could use this directory.
kdamonds/
@@ -127,14 +127,18 @@
user inputs in the sysfs files except ``state`` file again. Writing
``update_schemes_stats`` to ``state`` file updates the contents of stats files
for each DAMON-based operation scheme of the kdamond. For details of the
-stats, please refer to :ref:`stats section <sysfs_schemes_stats>`. Writing
-``update_schemes_tried_regions`` to ``state`` file updates the DAMON-based
-operation scheme action tried regions directory for each DAMON-based operation
-scheme of the kdamond. Writing ``clear_schemes_tried_regions`` to ``state``
-file clears the DAMON-based operating scheme action tried regions directory for
-each DAMON-based operation scheme of the kdamond. For details of the
-DAMON-based operation scheme action tried regions directory, please refer to
-:ref:`tried_regions section <sysfs_schemes_tried_regions>`.
+stats, please refer to :ref:`stats section <sysfs_schemes_stats>`.
+
+Writing ``update_schemes_tried_regions`` to ``state`` file updates the
+DAMON-based operation scheme action tried regions directory for each
+DAMON-based operation scheme of the kdamond. Writing
+``update_schemes_tried_bytes`` to ``state`` file updates only
+``.../tried_regions/total_bytes`` files. Writing
+``clear_schemes_tried_regions`` to ``state`` file clears the DAMON-based
+operating scheme action tried regions directory for each DAMON-based operation
+scheme of the kdamond. For details of the DAMON-based operation scheme action
+tried regions directory, please refer to :ref:`tried_regions section
+<sysfs_schemes_tried_regions>`.
If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread.
@@ -359,15 +363,21 @@
to ``N-1``. Each directory represents each filter. The filters are evaluated
in the numeric order.
-Each filter directory contains three files, namely ``type``, ``matcing``, and
-``memcg_path``. You can write one of two special keywords, ``anon`` for
-anonymous pages, or ``memcg`` for specific memory cgroup filtering. In case of
-the memory cgroup filtering, you can specify the memory cgroup of the interest
-by writing the path of the memory cgroup from the cgroups mount point to
-``memcg_path`` file. You can write ``Y`` or ``N`` to ``matching`` file to
-filter out pages that does or does not match to the type, respectively. Then,
-the scheme's action will not be applied to the pages that specified to be
-filtered out.
+Each filter directory contains six files, namely ``type``, ``matcing``,
+``memcg_path``, ``addr_start``, ``addr_end``, and ``target_idx``. To ``type``
+file, you can write one of four special keywords: ``anon`` for anonymous pages,
+``memcg`` for specific memory cgroup, ``addr`` for specific address range (an
+open-ended interval), or ``target`` for specific DAMON monitoring target
+filtering. In case of the memory cgroup filtering, you can specify the memory
+cgroup of the interest by writing the path of the memory cgroup from the
+cgroups mount point to ``memcg_path`` file. In case of the address range
+filtering, you can specify the start and end address of the range to
+``addr_start`` and ``addr_end`` files, respectively. For the DAMON monitoring
+target filtering, you can specify the index of the target between the list of
+the DAMON context's monitoring targets list to ``target_idx`` file. You can
+write ``Y`` or ``N`` to ``matching`` file to filter out pages that does or does
+not match to the type, respectively. Then, the scheme's action will not be
+applied to the pages that specified to be filtered out.
For example, below restricts a DAMOS action to be applied to only non-anonymous
pages of all memory cgroups except ``/having_care_already``.::
@@ -381,8 +391,14 @@
echo /having_care_already > 1/memcg_path
echo N > 1/matching
-Note that filters are currently supported only when ``paddr``
-`implementation <sysfs_contexts>` is being used.
+Note that ``anon`` and ``memcg`` filters are currently supported only when
+``paddr`` `implementation <sysfs_contexts>` is being used.
+
+Also, memory regions that are filtered out by ``addr`` or ``target`` filters
+are not counted as the scheme has tried to those, while regions that filtered
+out by other type filters are counted as the scheme has tried to. The
+difference is applied to :ref:`stats <damos_stats>` and
+:ref:`tried regions <sysfs_schemes_tried_regions>`.
.. _sysfs_schemes_stats:
@@ -397,7 +413,7 @@
The statistics can be retrieved by reading the files under ``stats`` directory
(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and
``qt_exceeds``), respectively. The files are not updated in real time, so you
-should ask DAMON sysfs interface to updte the content of the files for the
+should ask DAMON sysfs interface to update the content of the files for the
stats by writing a special keyword, ``update_schemes_stats`` to the relevant
``kdamonds/<N>/state`` file.
@@ -406,13 +422,21 @@
schemes/<N>/tried_regions/
--------------------------
+This directory initially has one file, ``total_bytes``.
+
When a special keyword, ``update_schemes_tried_regions``, is written to the
-relevant ``kdamonds/<N>/state`` file, DAMON creates directories named integer
-starting from ``0`` under this directory. Each directory contains files
-exposing detailed information about each of the memory region that the
-corresponding scheme's ``action`` has tried to be applied under this directory,
-during next :ref:`aggregation interval <sysfs_monitoring_attrs>`. The
-information includes address range, ``nr_accesses``, and ``age`` of the region.
+relevant ``kdamonds/<N>/state`` file, DAMON updates the ``total_bytes`` file so
+that reading it returns the total size of the scheme tried regions, and creates
+directories named integer starting from ``0`` under this directory. Each
+directory contains files exposing detailed information about each of the memory
+region that the corresponding scheme's ``action`` has tried to be applied under
+this directory, during next :ref:`aggregation interval
+<sysfs_monitoring_attrs>`. The information includes address range,
+``nr_accesses``, and ``age`` of the region.
+
+Writing ``update_schemes_tried_bytes`` to the relevant ``kdamonds/<N>/state``
+file will only update the ``total_bytes`` file, and will not create the
+subdirectories.
The directories will be removed when another special keyword,
``clear_schemes_tried_regions``, is written to the relevant
diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index 7626392..776f244 100644
--- a/Documentation/admin-guide/mm/ksm.rst
+++ b/Documentation/admin-guide/mm/ksm.rst
@@ -159,6 +159,8 @@
general_profit
how effective is KSM. The calculation is explained below.
+pages_scanned
+ how many pages are being scanned for ksm
pages_shared
how many shared pages are being used
pages_sharing
@@ -173,6 +175,13 @@
the number of KSM pages that hit the ``max_page_sharing`` limit
stable_node_dups
number of duplicated KSM pages
+ksm_zero_pages
+ how many zero pages that are still mapped into processes were mapped by
+ KSM when deduplicating.
+
+When ``use_zero_pages`` is/was enabled, the sum of ``pages_sharing`` +
+``ksm_zero_pages`` represents the actual number of pages saved by KSM.
+if ``use_zero_pages`` has never been enabled, ``ksm_zero_pages`` is 0.
A high ratio of ``pages_sharing`` to ``pages_shared`` indicates good
sharing, but a high ratio of ``pages_unshared`` to ``pages_sharing``
@@ -196,21 +205,25 @@
1) How to determine whether KSM save memory or consume memory in system-wide
range? Here is a simple approximate calculation for reference::
- general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
+ general_profit =~ ksm_saved_pages * sizeof(page) - (all_rmap_items) *
sizeof(rmap_item);
- where all_rmap_items can be easily obtained by summing ``pages_sharing``,
- ``pages_shared``, ``pages_unshared`` and ``pages_volatile``.
+ where ksm_saved_pages equals to the sum of ``pages_sharing`` +
+ ``ksm_zero_pages`` of the system, and all_rmap_items can be easily
+ obtained by summing ``pages_sharing``, ``pages_shared``, ``pages_unshared``
+ and ``pages_volatile``.
2) The KSM profit inner a single process can be similarly obtained by the
following approximate calculation::
- process_profit =~ ksm_merging_pages * sizeof(page) -
+ process_profit =~ ksm_saved_pages * sizeof(page) -
ksm_rmap_items * sizeof(rmap_item).
- where ksm_merging_pages is shown under the directory ``/proc/<pid>/``,
- and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit
- is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
+ where ksm_saved_pages equals to the sum of ``ksm_merging_pages`` and
+ ``ksm_zero_pages``, both of which are shown under the directory
+ ``/proc/<pid>/ksm_stat``, and ksm_rmap_items is also shown in
+ ``/proc/<pid>/ksm_stat``. The process profit is also shown in
+ ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
From the perspective of application, a high ratio of ``ksm_rmap_items`` to
``ksm_merging_pages`` means a bad madvise-applied policy, so developers or
diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst
index 1b02fe5..cfe034c 100644
--- a/Documentation/admin-guide/mm/memory-hotplug.rst
+++ b/Documentation/admin-guide/mm/memory-hotplug.rst
@@ -291,6 +291,14 @@
Availability depends on the CONFIG_ARCH_MEMORY_PROBE
kernel configuration option.
``uevent`` read-write: generic udev file for device subsystems.
+``crash_hotplug`` read-only: when changes to the system memory map
+ occur due to hot un/plug of memory, this file contains
+ '1' if the kernel updates the kdump capture kernel memory
+ map itself (via elfcorehdr), or '0' if userspace must update
+ the kdump capture kernel memory map.
+
+ Availability depends on the CONFIG_MEMORY_HOTPLUG kernel
+ configuration option.
====================== =========================================================
.. note::
@@ -433,6 +441,18 @@
memory in a way that huge pages in bigger
granularity cannot be formed on hotplugged
memory.
+
+ With value "force" it could result in memory
+ wastage due to memmap size limitations. For
+ example, if the memmap for a memory block
+ requires 1 MiB, but the pageblock size is 2
+ MiB, 1 MiB of hotplugged memory will be wasted.
+ Note that there are still cases where the
+ feature cannot be enforced: for example, if the
+ memmap is smaller than a single page, or if the
+ architecture does not support the forced mode
+ in all configurations.
+
``online_policy`` read-write: Set the basic policy used for
automatic zone selection when onlining memory
blocks without specifying a target zone.
@@ -669,7 +689,7 @@
(-> BUG), memory offlining will keep retrying until it eventually succeeds.
When offlining is triggered from user space, the offlining context can be
-terminated by sending a fatal signal. A timeout based offlining can easily be
+terminated by sending a signal. A timeout based offlining can easily be
implemented via::
% timeout $TIMEOUT offline_block | failure_handling
diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst
index 46515ad..eca38fa 100644
--- a/Documentation/admin-guide/mm/numa_memory_policy.rst
+++ b/Documentation/admin-guide/mm/numa_memory_policy.rst
@@ -109,7 +109,7 @@
* A task may install a new VMA policy on a sub-range of a
previously mmap()ed region. When this happens, Linux splits
the existing virtual memory area into 2 or 3 VMAs, each with
- it's own policy.
+ its own policy.
* By default, VMA policy applies only to pages allocated after
the policy is installed. Any pages already faulted into the
diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
index 7c304e4..4349a8c 100644
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -244,6 +244,21 @@
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
respectively) to configure the mapping this way.
+Memory Poisioning Emulation
+---------------------------
+
+In response to a fault (either missing or minor), an action userspace can
+take to "resolve" it is to issue a ``UFFDIO_POISON``. This will cause any
+future faulters to either get a SIGBUS, or in KVM's case the guest will
+receive an MCE as if there were hardware memory poisoning.
+
+This is used to emulate hardware memory poisoning. Imagine a VM running on a
+machine which experiences a real hardware memory error. Later, we live migrate
+the VM to another physical machine. Since we want the migration to be
+transparent to the guest, we want that same address range to act as if it was
+still poisoned, even though it's on a new physical host which ostensibly
+doesn't have a memory error in the exact same spot.
+
QEMU/KVM
========
diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst
index c5c2c7d..45b9839 100644
--- a/Documentation/admin-guide/mm/zswap.rst
+++ b/Documentation/admin-guide/mm/zswap.rst
@@ -49,7 +49,7 @@
Design
======
-Zswap receives pages for compression through the Frontswap API and is able to
+Zswap receives pages for compression from the swap subsystem and is able to
evict pages from its own compressed pool on an LRU basis and write them back to
the backing swap device in the case that the compressed pool is full.
@@ -70,19 +70,19 @@
zbud pages). The zsmalloc type zpool has a more complex compressed page
storage method, and it can achieve greater storage densities.
-When a swap page is passed from frontswap to zswap, zswap maintains a mapping
+When a swap page is passed from swapout to zswap, zswap maintains a mapping
of the swap entry, a combination of the swap type and swap offset, to the zpool
handle that references that compressed swap page. This mapping is achieved
with a red-black tree per swap type. The swap offset is the search key for the
tree nodes.
-During a page fault on a PTE that is a swap entry, frontswap calls the zswap
-load function to decompress the page into the page allocated by the page fault
-handler.
+During a page fault on a PTE that is a swap entry, the swapin code calls the
+zswap load function to decompress the page into the page allocated by the page
+fault handler.
Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
-in the swap_map goes to 0) the swap code calls the zswap invalidate function,
-via frontswap, to free the compressed entry.
+in the swap_map goes to 0) the swap code calls the zswap invalidate function
+to free the compressed entry.
Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
controlled policy:
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index 7d7c7c8..2898b27 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -266,7 +266,7 @@
unsigned. Any module for which the kernel has a key, but which proves to have
a signature mismatch will not be permitted to load.
-Any module that has an unparseable signature will be rejected.
+Any module that has an unparsable signature will be rejected.
=========================================
diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst
index 8c8b94e..a3dfc2c 100644
--- a/Documentation/admin-guide/serial-console.rst
+++ b/Documentation/admin-guide/serial-console.rst
@@ -59,7 +59,7 @@
the hardware is not available.
The result might be surprising. For example, the following two command
-lines have the same result:
+lines have the same result::
console=ttyS1,9600 console=tty0 console=tty1
console=tty0 console=ttyS1,9600 console=tty1
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 3800fab..8019103 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -941,16 +941,35 @@
The default value is 8.
-perf_user_access (arm64 only)
-=================================
+perf_user_access (arm64 and riscv only)
+=======================================
-Controls user space access for reading perf event counters. When set to 1,
-user space can read performance monitor counter registers directly.
+Controls user space access for reading perf event counters.
+
+arm64
+=====
The default value is 0 (access disabled).
+When set to 1, user space can read performance monitor counter registers
+directly.
+
See Documentation/arch/arm64/perf.rst for more information.
+riscv
+=====
+
+When set to 0, user space access is disabled.
+
+The default value is 1, user space can read performance monitor counter
+registers through perf, any direct access without perf intervention will trigger
+an illegal instruction.
+
+When set to 2, which enables legacy mode (user space has direct access to cycle
+and insret CSRs only). Note that this legacy value is deprecated and will be
+removed once all user space applications are fixed.
+
+Note that the time CSR is always directly accessible to all modes.
pid_max
=======
diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst
index 3a9c041..b67772c 100644
--- a/Documentation/admin-guide/xfs.rst
+++ b/Documentation/admin-guide/xfs.rst
@@ -192,7 +192,7 @@
are any integer multiple of a valid ``sunit`` value.
Typically the only time these mount options are necessary if
- after an underlying RAID device has had it's geometry
+ after an underlying RAID device has had its geometry
modified, such as adding a new disk to a RAID5 lun and
reshaping it.
diff --git a/Documentation/arch/arm/arm.rst b/Documentation/arch/arm/arm.rst
index 99d660f..7b41b89 100644
--- a/Documentation/arch/arm/arm.rst
+++ b/Documentation/arch/arm/arm.rst
@@ -141,7 +141,7 @@
`*configure` harddrive set to 2). I've got an internal 20MB and a great
big external 5.25" FH 64MB drive (who could ever want more :-) ).
- I've just got 240K/s off it (a dd with bs=128k); thats about half of what
+ I've just got 240K/s off it (a dd with bs=128k); that's about half of what
RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
last week :-)
diff --git a/Documentation/arch/arm/ixp4xx.rst b/Documentation/arch/arm/ixp4xx.rst
index a572356..17aafc6 100644
--- a/Documentation/arch/arm/ixp4xx.rst
+++ b/Documentation/arch/arm/ixp4xx.rst
@@ -78,9 +78,9 @@
1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
To access PCI via this space, we simply ioremap() the BAR
into the kernel and we can use the standard read[bwl]/write[bwl]
- macros. This is the preffered method due to speed but it
+ macros. This is the preferred method due to speed but it
limits the system to just 64MB of PCI memory. This can be
- problamatic if using video cards and other memory-heavy devices.
+ problematic if using video cards and other memory-heavy devices.
2) If > 64MB of memory space is required, the IXP4xx can be
configured to use indirect registers to access PCI This allows
diff --git a/Documentation/arch/arm/sunxi/clocks.rst b/Documentation/arch/arm/sunxi/clocks.rst
index 23bd03f..dfe6d48 100644
--- a/Documentation/arch/arm/sunxi/clocks.rst
+++ b/Documentation/arch/arm/sunxi/clocks.rst
@@ -5,7 +5,7 @@
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
-Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
+Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
diff --git a/Documentation/arch/arm/swp_emulation.rst b/Documentation/arch/arm/swp_emulation.rst
index 6a608a9..bf205e3 100644
--- a/Documentation/arch/arm/swp_emulation.rst
+++ b/Documentation/arch/arm/swp_emulation.rst
@@ -1,7 +1,7 @@
Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE)
---------------------------------------------------------------------
-ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds
+ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends
moving to the load-locked/store-conditional instructions LDREX and STREX.
ARMv7 multiprocessing extensions introduce the ability to disable these
diff --git a/Documentation/arch/arm/tcm.rst b/Documentation/arch/arm/tcm.rst
index 1dc6c39..7ce17a2 100644
--- a/Documentation/arch/arm/tcm.rst
+++ b/Documentation/arch/arm/tcm.rst
@@ -71,7 +71,7 @@
- Have the remaining TCM RAM added to a special
allocation pool with gen_pool_create() and gen_pool_add()
- and provice tcm_alloc() and tcm_free() for this
+ and provide tcm_alloc() and tcm_free() for this
memory. Such a heap is great for things like saving
device state when shutting off device power domains.
diff --git a/Documentation/arch/arm/uefi.rst b/Documentation/arch/arm/uefi.rst
index baebe68..2b7ad9b 100644
--- a/Documentation/arch/arm/uefi.rst
+++ b/Documentation/arch/arm/uefi.rst
@@ -50,7 +50,7 @@
following parameters:
========================== ====== ===========================================
-Name Size Description
+Name Type Description
========================== ====== ===========================================
linux,uefi-system-table 64-bit Physical address of the UEFI System Table.
@@ -67,4 +67,6 @@
kaslr-seed 64-bit Entropy used to randomize the kernel image
base address location.
+
+bootargs String Kernel command line
========================== ====== ===========================================
diff --git a/Documentation/arch/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst
index a40a174..737aa86 100644
--- a/Documentation/arch/arm/vlocks.rst
+++ b/Documentation/arch/arm/vlocks.rst
@@ -155,7 +155,7 @@
optimisation.
If there are too many CPUs to read the currently_voting array in
- one transaction then multiple transations are still required. The
+ one transaction then multiple transactions are still required. The
implementation uses a simple loop of word-sized loads for this
case. The number of transactions is still fewer than would be
required if bytes were loaded individually.
diff --git a/Documentation/arch/arm64/acpi_object_usage.rst b/Documentation/arch/arm64/acpi_object_usage.rst
index 1da2220..06d8a87 100644
--- a/Documentation/arch/arm64/acpi_object_usage.rst
+++ b/Documentation/arch/arm64/acpi_object_usage.rst
@@ -45,7 +45,7 @@
**Arm Performance Monitoring Table**
- This table describes the properties of PMU support implmented by
+ This table describes the properties of PMU support implemented by
components in the system.
BERT Section 18.3 (signature == "BERT")
diff --git a/Documentation/arch/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst
index 94274a8..a46c34f 100644
--- a/Documentation/arch/arm64/arm-acpi.rst
+++ b/Documentation/arch/arm64/arm-acpi.rst
@@ -99,7 +99,7 @@
When a Linux driver or subsystem is first implemented using ACPI, it by
definition ends up requiring a specific version of the ACPI specification
--- it's baseline. ACPI firmware must continue to work, even though it may
+-- its baseline. ACPI firmware must continue to work, even though it may
not be optimal, with the earliest kernel version that first provides support
for that baseline version of ACPI. There may be a need for additional drivers,
but adding new functionality (e.g., CPU power management) should not break
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index bedd3a1..e96f057 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -63,6 +63,14 @@
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
+----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
++----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
@@ -109,14 +117,6 @@
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
-+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
@@ -198,6 +198,9 @@
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A |
+| | Hip09 SMMU PMCG | | |
++----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+----------------+-----------------+-----------------+-----------------------------+
diff --git a/Documentation/arch/arm64/sme.rst b/Documentation/arch/arm64/sme.rst
index ba529a1..3d0e53e 100644
--- a/Documentation/arch/arm64/sme.rst
+++ b/Documentation/arch/arm64/sme.rst
@@ -322,7 +322,7 @@
VL is supported.
* The size and layout of the payload depends on the header fields. The
- SME_PT_ZA_*() macros are provided to facilitate access to the data.
+ ZA_PT_ZA*() macros are provided to facilitate access to the data.
* In either case, for SETREGSET it is permissible to omit the payload, in which
case the vector length and flags are changed and PSTATE.ZA is set to 0
diff --git a/Documentation/arch/index.rst b/Documentation/arch/index.rst
index 8458b88..84b8025 100644
--- a/Documentation/arch/index.rst
+++ b/Documentation/arch/index.rst
@@ -13,15 +13,15 @@
arm/index
arm64/index
ia64/index
- ../loongarch/index
+ loongarch/index
m68k/index
- ../mips/index
+ mips/index
nios2/index
openrisc/index
parisc/index
../powerpc/index
../riscv/index
- ../s390/index
+ s390/index
sh/index
sparc/index
x86/index
diff --git a/Documentation/loongarch/booting.rst b/Documentation/arch/loongarch/booting.rst
similarity index 100%
rename from Documentation/loongarch/booting.rst
rename to Documentation/arch/loongarch/booting.rst
diff --git a/Documentation/loongarch/features.rst b/Documentation/arch/loongarch/features.rst
similarity index 100%
rename from Documentation/loongarch/features.rst
rename to Documentation/arch/loongarch/features.rst
diff --git a/Documentation/loongarch/index.rst b/Documentation/arch/loongarch/index.rst
similarity index 100%
rename from Documentation/loongarch/index.rst
rename to Documentation/arch/loongarch/index.rst
diff --git a/Documentation/loongarch/introduction.rst b/Documentation/arch/loongarch/introduction.rst
similarity index 100%
rename from Documentation/loongarch/introduction.rst
rename to Documentation/arch/loongarch/introduction.rst
diff --git a/Documentation/loongarch/irq-chip-model.rst b/Documentation/arch/loongarch/irq-chip-model.rst
similarity index 100%
rename from Documentation/loongarch/irq-chip-model.rst
rename to Documentation/arch/loongarch/irq-chip-model.rst
diff --git a/Documentation/mips/booting.rst b/Documentation/arch/mips/booting.rst
similarity index 100%
rename from Documentation/mips/booting.rst
rename to Documentation/arch/mips/booting.rst
diff --git a/Documentation/mips/features.rst b/Documentation/arch/mips/features.rst
similarity index 100%
rename from Documentation/mips/features.rst
rename to Documentation/arch/mips/features.rst
diff --git a/Documentation/mips/index.rst b/Documentation/arch/mips/index.rst
similarity index 100%
rename from Documentation/mips/index.rst
rename to Documentation/arch/mips/index.rst
diff --git a/Documentation/mips/ingenic-tcu.rst b/Documentation/arch/mips/ingenic-tcu.rst
similarity index 100%
rename from Documentation/mips/ingenic-tcu.rst
rename to Documentation/arch/mips/ingenic-tcu.rst
diff --git a/Documentation/arch/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst
index 657ac4a..1565b95 100644
--- a/Documentation/arch/openrisc/openrisc_port.rst
+++ b/Documentation/arch/openrisc/openrisc_port.rst
@@ -106,7 +106,7 @@
a much improved version with changes all around.
10-04-2004 Matjaz Breskvar (phoenix@bsemi.com)
- alot of bugfixes all over.
+ a lot of bugfixes all over.
ethernet support, functional http and telnet servers.
running many standard linux apps.
@@ -114,7 +114,7 @@
port to 2.6.x
30-11-2004 Matjaz Breskvar (phoenix@bsemi.com)
- lots of bugfixes and enhancments.
+ lots of bugfixes and enhancements.
added opencores framebuffer driver.
09-10-2010 Jonas Bonn (jonas@southpole.se)
diff --git a/Documentation/s390/3270.ChangeLog b/Documentation/arch/s390/3270.ChangeLog
similarity index 100%
rename from Documentation/s390/3270.ChangeLog
rename to Documentation/arch/s390/3270.ChangeLog
diff --git a/Documentation/arch/s390/3270.rst b/Documentation/arch/s390/3270.rst
new file mode 100644
index 0000000..467eace
--- /dev/null
+++ b/Documentation/arch/s390/3270.rst
@@ -0,0 +1,298 @@
+===============================
+IBM 3270 Display System support
+===============================
+
+This file describes the driver that supports local channel attachment
+of IBM 3270 devices. It consists of three sections:
+
+ * Introduction
+ * Installation
+ * Operation
+
+
+Introduction
+============
+
+This paper describes installing and operating 3270 devices under
+Linux/390. A 3270 device is a block-mode rows-and-columns terminal of
+which I'm sure hundreds of millions were sold by IBM and clonemakers
+twenty and thirty years ago.
+
+You may have 3270s in-house and not know it. If you're using the
+VM-ESA operating system, define a 3270 to your virtual machine by using
+the command "DEF GRAF <hex-address>" This paper presumes you will be
+defining four 3270s with the CP/CMS commands:
+
+ - DEF GRAF 620
+ - DEF GRAF 621
+ - DEF GRAF 622
+ - DEF GRAF 623
+
+Your network connection from VM-ESA allows you to use x3270, tn3270, or
+another 3270 emulator, started from an xterm window on your PC or
+workstation. With the DEF GRAF command, an application such as xterm,
+and this Linux-390 3270 driver, you have another way of talking to your
+Linux box.
+
+This paper covers installation of the driver and operation of a
+dialed-in x3270.
+
+
+Installation
+============
+
+You install the driver by installing a patch, doing a kernel build, and
+running the configuration script (config3270.sh, in this directory).
+
+WARNING: If you are using 3270 console support, you must rerun the
+configuration script every time you change the console's address (perhaps
+by using the condev= parameter in silo's /boot/parmfile). More precisely,
+you should rerun the configuration script every time your set of 3270s,
+including the console 3270, changes subchannel identifier relative to
+one another. ReIPL as soon as possible after running the configuration
+script and the resulting /tmp/mkdev3270.
+
+If you have chosen to make tub3270 a module, you add a line to a
+configuration file under /etc/modprobe.d/. If you are working on a VM
+virtual machine, you can use DEF GRAF to define virtual 3270 devices.
+
+You may generate both 3270 and 3215 console support, or one or the
+other, or neither. If you generate both, the console type under VM is
+not changed. Use #CP Q TERM to see what the current console type is.
+Use #CP TERM CONMODE 3270 to change it to 3270. If you generate only
+3270 console support, then the driver automatically converts your console
+at boot time to a 3270 if it is a 3215.
+
+In brief, these are the steps:
+
+ 1. Install the tub3270 patch
+ 2. (If a module) add a line to a file in `/etc/modprobe.d/*.conf`
+ 3. (If VM) define devices with DEF GRAF
+ 4. Reboot
+ 5. Configure
+
+To test that everything works, assuming VM and x3270,
+
+ 1. Bring up an x3270 window.
+ 2. Use the DIAL command in that window.
+ 3. You should immediately see a Linux login screen.
+
+Here are the installation steps in detail:
+
+ 1. The 3270 driver is a part of the official Linux kernel
+ source. Build a tree with the kernel source and any necessary
+ patches. Then do::
+
+ make oldconfig
+ (If you wish to disable 3215 console support, edit
+ .config; change CONFIG_TN3215's value to "n";
+ and rerun "make oldconfig".)
+ make image
+ make modules
+ make modules_install
+
+ 2. (Perform this step only if you have configured tub3270 as a
+ module.) Add a line to a file `/etc/modprobe.d/*.conf` to automatically
+ load the driver when it's needed. With this line added, you will see
+ login prompts appear on your 3270s as soon as boot is complete (or
+ with emulated 3270s, as soon as you dial into your vm guest using the
+ command "DIAL <vmguestname>"). Since the line-mode major number is
+ 227, the line to add should be::
+
+ alias char-major-227 tub3270
+
+ 3. Define graphic devices to your vm guest machine, if you
+ haven't already. Define them before you reboot (reipl):
+
+ - DEFINE GRAF 620
+ - DEFINE GRAF 621
+ - DEFINE GRAF 622
+ - DEFINE GRAF 623
+
+ 4. Reboot. The reboot process scans hardware devices, including
+ 3270s, and this enables the tub3270 driver once loaded to respond
+ correctly to the configuration requests of the next step. If
+ you have chosen 3270 console support, your console now behaves
+ as a 3270, not a 3215.
+
+ 5. Run the 3270 configuration script config3270. It is
+ distributed in this same directory, Documentation/arch/s390, as
+ config3270.sh. Inspect the output script it produces,
+ /tmp/mkdev3270, and then run that script. This will create the
+ necessary character special device files and make the necessary
+ changes to /etc/inittab.
+
+ Then notify /sbin/init that /etc/inittab has changed, by issuing
+ the telinit command with the q operand::
+
+ cd Documentation/arch/s390
+ sh config3270.sh
+ sh /tmp/mkdev3270
+ telinit q
+
+ This should be sufficient for your first time. If your 3270
+ configuration has changed and you're reusing config3270, you
+ should follow these steps::
+
+ Change 3270 configuration
+ Reboot
+ Run config3270 and /tmp/mkdev3270
+ Reboot
+
+Here are the testing steps in detail:
+
+ 1. Bring up an x3270 window, or use an actual hardware 3278 or
+ 3279, or use the 3270 emulator of your choice. You would be
+ running the emulator on your PC or workstation. You would use
+ the command, for example::
+
+ x3270 vm-esa-domain-name &
+
+ if you wanted a 3278 Model 4 with 43 rows of 80 columns, the
+ default model number. The driver does not take advantage of
+ extended attributes.
+
+ The screen you should now see contains a VM logo with input
+ lines near the bottom. Use TAB to move to the bottom line,
+ probably labeled "COMMAND ===>".
+
+ 2. Use the DIAL command instead of the LOGIN command to connect
+ to one of the virtual 3270s you defined with the DEF GRAF
+ commands::
+
+ dial my-vm-guest-name
+
+ 3. You should immediately see a login prompt from your
+ Linux-390 operating system. If that does not happen, you would
+ see instead the line "DIALED TO my-vm-guest-name 0620".
+
+ To troubleshoot: do these things.
+
+ A. Is the driver loaded? Use the lsmod command (no operands)
+ to find out. Probably it isn't. Try loading it manually, with
+ the command "insmod tub3270". Does that command give error
+ messages? Ha! There's your problem.
+
+ B. Is the /etc/inittab file modified as in installation step 3
+ above? Use the grep command to find out; for instance, issue
+ "grep 3270 /etc/inittab". Nothing found? There's your
+ problem!
+
+ C. Are the device special files created, as in installation
+ step 2 above? Use the ls -l command to find out; for instance,
+ issue "ls -l /dev/3270/tty620". The output should start with the
+ letter "c" meaning character device and should contain "227, 1"
+ just to the left of the device name. No such file? no "c"?
+ Wrong major number? Wrong minor number? There's your
+ problem!
+
+ D. Do you get the message::
+
+ "HCPDIA047E my-vm-guest-name 0620 does not exist"?
+
+ If so, you must issue the command "DEF GRAF 620" from your VM
+ 3215 console and then reboot the system.
+
+
+
+OPERATION.
+==========
+
+The driver defines three areas on the 3270 screen: the log area, the
+input area, and the status area.
+
+The log area takes up all but the bottom two lines of the screen. The
+driver writes terminal output to it, starting at the top line and going
+down. When it fills, the status area changes from "Linux Running" to
+"Linux More...". After a scrolling timeout of (default) 5 sec, the
+screen clears and more output is written, from the top down.
+
+The input area extends from the beginning of the second-to-last screen
+line to the start of the status area. You type commands in this area
+and hit ENTER to execute them.
+
+The status area initializes to "Linux Running" to give you a warm
+fuzzy feeling. When the log area fills up and output awaits, it
+changes to "Linux More...". At this time you can do several things or
+nothing. If you do nothing, the screen will clear in (default) 5 sec
+and more output will appear. You may hit ENTER with nothing typed in
+the input area to toggle between "Linux More..." and "Linux Holding",
+which indicates no scrolling will occur. (If you hit ENTER with "Linux
+Running" and nothing typed, the application receives a newline.)
+
+You may change the scrolling timeout value. For example, the following
+command line::
+
+ echo scrolltime=60 > /proc/tty/driver/tty3270
+
+changes the scrolling timeout value to 60 sec. Set scrolltime to 0 if
+you wish to prevent scrolling entirely.
+
+Other things you may do when the log area fills up are: hit PA2 to
+clear the log area and write more output to it, or hit CLEAR to clear
+the log area and the input area and write more output to the log area.
+
+Some of the Program Function (PF) and Program Attention (PA) keys are
+preassigned special functions. The ones that are not yield an alarm
+when pressed.
+
+PA1 causes a SIGINT to the currently running application. You may do
+the same thing from the input area, by typing "^C" and hitting ENTER.
+
+PA2 causes the log area to be cleared. If output awaits, it is then
+written to the log area.
+
+PF3 causes an EOF to be received as input by the application. You may
+cause an EOF also by typing "^D" and hitting ENTER.
+
+No PF key is preassigned to cause a job suspension, but you may cause a
+job suspension by typing "^Z" and hitting ENTER. You may wish to
+assign this function to a PF key. To make PF7 cause job suspension,
+execute the command::
+
+ echo pf7=^z > /proc/tty/driver/tty3270
+
+If the input you type does not end with the two characters "^n", the
+driver appends a newline character and sends it to the tty driver;
+otherwise the driver strips the "^n" and does not append a newline.
+The IBM 3215 driver behaves similarly.
+
+Pf10 causes the most recent command to be retrieved from the tube's
+command stack (default depth 20) and displayed in the input area. You
+may hit PF10 again for the next-most-recent command, and so on. A
+command is entered into the stack only when the input area is not made
+invisible (such as for password entry) and it is not identical to the
+current top entry. PF10 rotates backward through the command stack;
+PF11 rotates forward. You may assign the backward function to any PF
+key (or PA key, for that matter), say, PA3, with the command::
+
+ echo -e pa3=\\033k > /proc/tty/driver/tty3270
+
+This assigns the string ESC-k to PA3. Similarly, the string ESC-j
+performs the forward function. (Rationale: In bash with vi-mode line
+editing, ESC-k and ESC-j retrieve backward and forward history.
+Suggestions welcome.)
+
+Is a stack size of twenty commands not to your liking? Change it on
+the fly. To change to saving the last 100 commands, execute the
+command::
+
+ echo recallsize=100 > /proc/tty/driver/tty3270
+
+Have a command you issue frequently? Assign it to a PF or PA key! Use
+the command::
+
+ echo pf24="mkdir foobar; cd foobar" > /proc/tty/driver/tty3270
+
+to execute the commands mkdir foobar and cd foobar immediately when you
+hit PF24. Want to see the command line first, before you execute it?
+Use the -n option of the echo command::
+
+ echo -n pf24="mkdir foo; cd foo" > /proc/tty/driver/tty3270
+
+
+
+Happy testing! I welcome any and all comments about this document, the
+driver, etc etc.
+
+Dick Hitt <rbh00@utsglobal.com>
diff --git a/Documentation/arch/s390/cds.rst b/Documentation/arch/s390/cds.rst
new file mode 100644
index 0000000..bcad2a1
--- /dev/null
+++ b/Documentation/arch/s390/cds.rst
@@ -0,0 +1,530 @@
+===========================
+Linux for S/390 and zSeries
+===========================
+
+Common Device Support (CDS)
+Device Driver I/O Support Routines
+
+Authors:
+ - Ingo Adlung
+ - Cornelia Huck
+
+Copyright, IBM Corp. 1999-2002
+
+Introduction
+============
+
+This document describes the common device support routines for Linux/390.
+Different than other hardware architectures, ESA/390 has defined a unified
+I/O access method. This gives relief to the device drivers as they don't
+have to deal with different bus types, polling versus interrupt
+processing, shared versus non-shared interrupt processing, DMA versus port
+I/O (PIO), and other hardware features more. However, this implies that
+either every single device driver needs to implement the hardware I/O
+attachment functionality itself, or the operating system provides for a
+unified method to access the hardware, providing all the functionality that
+every single device driver would have to provide itself.
+
+The document does not intend to explain the ESA/390 hardware architecture in
+every detail.This information can be obtained from the ESA/390 Principles of
+Operation manual (IBM Form. No. SA22-7201).
+
+In order to build common device support for ESA/390 I/O interfaces, a
+functional layer was introduced that provides generic I/O access methods to
+the hardware.
+
+The common device support layer comprises the I/O support routines defined
+below. Some of them implement common Linux device driver interfaces, while
+some of them are ESA/390 platform specific.
+
+Note:
+ In order to write a driver for S/390, you also need to look into the interface
+ described in Documentation/arch/s390/driver-model.rst.
+
+Note for porting drivers from 2.4:
+
+The major changes are:
+
+* The functions use a ccw_device instead of an irq (subchannel).
+* All drivers must define a ccw_driver (see driver-model.txt) and the associated
+ functions.
+* request_irq() and free_irq() are no longer done by the driver.
+* The oper_handler is (kindof) replaced by the probe() and set_online() functions
+ of the ccw_driver.
+* The not_oper_handler is (kindof) replaced by the remove() and set_offline()
+ functions of the ccw_driver.
+* The channel device layer is gone.
+* The interrupt handlers must be adapted to use a ccw_device as argument.
+ Moreover, they don't return a devstat, but an irb.
+* Before initiating an io, the options must be set via ccw_device_set_options().
+* Instead of calling read_dev_chars()/read_conf_data(), the driver issues
+ the channel program and handles the interrupt itself.
+
+ccw_device_get_ciw()
+ get commands from extended sense data.
+
+ccw_device_start(), ccw_device_start_timeout(), ccw_device_start_key(), ccw_device_start_key_timeout()
+ initiate an I/O request.
+
+ccw_device_resume()
+ resume channel program execution.
+
+ccw_device_halt()
+ terminate the current I/O request processed on the device.
+
+do_IRQ()
+ generic interrupt routine. This function is called by the interrupt entry
+ routine whenever an I/O interrupt is presented to the system. The do_IRQ()
+ routine determines the interrupt status and calls the device specific
+ interrupt handler according to the rules (flags) defined during I/O request
+ initiation with do_IO().
+
+The next chapters describe the functions other than do_IRQ() in more details.
+The do_IRQ() interface is not described, as it is called from the Linux/390
+first level interrupt handler only and does not comprise a device driver
+callable interface. Instead, the functional description of do_IO() also
+describes the input to the device specific interrupt handler.
+
+Note:
+ All explanations apply also to the 64 bit architecture s390x.
+
+
+Common Device Support (CDS) for Linux/390 Device Drivers
+========================================================
+
+General Information
+-------------------
+
+The following chapters describe the I/O related interface routines the
+Linux/390 common device support (CDS) provides to allow for device specific
+driver implementations on the IBM ESA/390 hardware platform. Those interfaces
+intend to provide the functionality required by every device driver
+implementation to allow to drive a specific hardware device on the ESA/390
+platform. Some of the interface routines are specific to Linux/390 and some
+of them can be found on other Linux platforms implementations too.
+Miscellaneous function prototypes, data declarations, and macro definitions
+can be found in the architecture specific C header file
+linux/arch/s390/include/asm/irq.h.
+
+Overview of CDS interface concepts
+----------------------------------
+
+Different to other hardware platforms, the ESA/390 architecture doesn't define
+interrupt lines managed by a specific interrupt controller and bus systems
+that may or may not allow for shared interrupts, DMA processing, etc.. Instead,
+the ESA/390 architecture has implemented a so called channel subsystem, that
+provides a unified view of the devices physically attached to the systems.
+Though the ESA/390 hardware platform knows about a huge variety of different
+peripheral attachments like disk devices (aka. DASDs), tapes, communication
+controllers, etc. they can all be accessed by a well defined access method and
+they are presenting I/O completion a unified way : I/O interruptions. Every
+single device is uniquely identified to the system by a so called subchannel,
+where the ESA/390 architecture allows for 64k devices be attached.
+
+Linux, however, was first built on the Intel PC architecture, with its two
+cascaded 8259 programmable interrupt controllers (PICs), that allow for a
+maximum of 15 different interrupt lines. All devices attached to such a system
+share those 15 interrupt levels. Devices attached to the ISA bus system must
+not share interrupt levels (aka. IRQs), as the ISA bus bases on edge triggered
+interrupts. MCA, EISA, PCI and other bus systems base on level triggered
+interrupts, and therewith allow for shared IRQs. However, if multiple devices
+present their hardware status by the same (shared) IRQ, the operating system
+has to call every single device driver registered on this IRQ in order to
+determine the device driver owning the device that raised the interrupt.
+
+Up to kernel 2.4, Linux/390 used to provide interfaces via the IRQ (subchannel).
+For internal use of the common I/O layer, these are still there. However,
+device drivers should use the new calling interface via the ccw_device only.
+
+During its startup the Linux/390 system checks for peripheral devices. Each
+of those devices is uniquely defined by a so called subchannel by the ESA/390
+channel subsystem. While the subchannel numbers are system generated, each
+subchannel also takes a user defined attribute, the so called device number.
+Both subchannel number and device number cannot exceed 65535. During sysfs
+initialisation, the information about control unit type and device types that
+imply specific I/O commands (channel command words - CCWs) in order to operate
+the device are gathered. Device drivers can retrieve this set of hardware
+information during their initialization step to recognize the devices they
+support using the information saved in the struct ccw_device given to them.
+This methods implies that Linux/390 doesn't require to probe for free (not
+armed) interrupt request lines (IRQs) to drive its devices with. Where
+applicable, the device drivers can use issue the READ DEVICE CHARACTERISTICS
+ccw to retrieve device characteristics in its online routine.
+
+In order to allow for easy I/O initiation the CDS layer provides a
+ccw_device_start() interface that takes a device specific channel program (one
+or more CCWs) as input sets up the required architecture specific control blocks
+and initiates an I/O request on behalf of the device driver. The
+ccw_device_start() routine allows to specify whether it expects the CDS layer
+to notify the device driver for every interrupt it observes, or with final status
+only. See ccw_device_start() for more details. A device driver must never issue
+ESA/390 I/O commands itself, but must use the Linux/390 CDS interfaces instead.
+
+For long running I/O request to be canceled, the CDS layer provides the
+ccw_device_halt() function. Some devices require to initially issue a HALT
+SUBCHANNEL (HSCH) command without having pending I/O requests. This function is
+also covered by ccw_device_halt().
+
+
+get_ciw() - get command information word
+
+This call enables a device driver to get information about supported commands
+from the extended SenseID data.
+
+::
+
+ struct ciw *
+ ccw_device_get_ciw(struct ccw_device *cdev, __u32 cmd);
+
+==== ========================================================
+cdev The ccw_device for which the command is to be retrieved.
+cmd The command type to be retrieved.
+==== ========================================================
+
+ccw_device_get_ciw() returns:
+
+===== ================================================================
+ NULL No extended data available, invalid device or command not found.
+!NULL The command requested.
+===== ================================================================
+
+::
+
+ ccw_device_start() - Initiate I/O Request
+
+The ccw_device_start() routines is the I/O request front-end processor. All
+device driver I/O requests must be issued using this routine. A device driver
+must not issue ESA/390 I/O commands itself. Instead the ccw_device_start()
+routine provides all interfaces required to drive arbitrary devices.
+
+This description also covers the status information passed to the device
+driver's interrupt handler as this is related to the rules (flags) defined
+with the associated I/O request when calling ccw_device_start().
+
+::
+
+ int ccw_device_start(struct ccw_device *cdev,
+ struct ccw1 *cpa,
+ unsigned long intparm,
+ __u8 lpm,
+ unsigned long flags);
+ int ccw_device_start_timeout(struct ccw_device *cdev,
+ struct ccw1 *cpa,
+ unsigned long intparm,
+ __u8 lpm,
+ unsigned long flags,
+ int expires);
+ int ccw_device_start_key(struct ccw_device *cdev,
+ struct ccw1 *cpa,
+ unsigned long intparm,
+ __u8 lpm,
+ __u8 key,
+ unsigned long flags);
+ int ccw_device_start_key_timeout(struct ccw_device *cdev,
+ struct ccw1 *cpa,
+ unsigned long intparm,
+ __u8 lpm,
+ __u8 key,
+ unsigned long flags,
+ int expires);
+
+============= =============================================================
+cdev ccw_device the I/O is destined for
+cpa logical start address of channel program
+user_intparm user specific interrupt information; will be presented
+ back to the device driver's interrupt handler. Allows a
+ device driver to associate the interrupt with a
+ particular I/O request.
+lpm defines the channel path to be used for a specific I/O
+ request. A value of 0 will make cio use the opm.
+key the storage key to use for the I/O (useful for operating on a
+ storage with a storage key != default key)
+flag defines the action to be performed for I/O processing
+expires timeout value in jiffies. The common I/O layer will terminate
+ the running program after this and call the interrupt handler
+ with ERR_PTR(-ETIMEDOUT) as irb.
+============= =============================================================
+
+Possible flag values are:
+
+========================= =============================================
+DOIO_ALLOW_SUSPEND channel program may become suspended
+DOIO_DENY_PREFETCH don't allow for CCW prefetch; usually
+ this implies the channel program might
+ become modified
+DOIO_SUPPRESS_INTER don't call the handler on intermediate status
+========================= =============================================
+
+The cpa parameter points to the first format 1 CCW of a channel program::
+
+ struct ccw1 {
+ __u8 cmd_code;/* command code */
+ __u8 flags; /* flags, like IDA addressing, etc. */
+ __u16 count; /* byte count */
+ __u32 cda; /* data address */
+ } __attribute__ ((packed,aligned(8)));
+
+with the following CCW flags values defined:
+
+=================== =========================
+CCW_FLAG_DC data chaining
+CCW_FLAG_CC command chaining
+CCW_FLAG_SLI suppress incorrect length
+CCW_FLAG_SKIP skip
+CCW_FLAG_PCI PCI
+CCW_FLAG_IDA indirect addressing
+CCW_FLAG_SUSPEND suspend
+=================== =========================
+
+
+Via ccw_device_set_options(), the device driver may specify the following
+options for the device:
+
+========================= ======================================
+DOIO_EARLY_NOTIFICATION allow for early interrupt notification
+DOIO_REPORT_ALL report all interrupt conditions
+========================= ======================================
+
+
+The ccw_device_start() function returns:
+
+======== ======================================================================
+ 0 successful completion or request successfully initiated
+ -EBUSY The device is currently processing a previous I/O request, or there is
+ a status pending at the device.
+-ENODEV cdev is invalid, the device is not operational or the ccw_device is
+ not online.
+======== ======================================================================
+
+When the I/O request completes, the CDS first level interrupt handler will
+accumulate the status in a struct irb and then call the device interrupt handler.
+The intparm field will contain the value the device driver has associated with a
+particular I/O request. If a pending device status was recognized,
+intparm will be set to 0 (zero). This may happen during I/O initiation or delayed
+by an alert status notification. In any case this status is not related to the
+current (last) I/O request. In case of a delayed status notification no special
+interrupt will be presented to indicate I/O completion as the I/O request was
+never started, even though ccw_device_start() returned with successful completion.
+
+The irb may contain an error value, and the device driver should check for this
+first:
+
+========== =================================================================
+-ETIMEDOUT the common I/O layer terminated the request after the specified
+ timeout value
+-EIO the common I/O layer terminated the request due to an error state
+========== =================================================================
+
+If the concurrent sense flag in the extended status word (esw) in the irb is
+set, the field erw.scnt in the esw describes the number of device specific
+sense bytes available in the extended control word irb->scsw.ecw[]. No device
+sensing by the device driver itself is required.
+
+The device interrupt handler can use the following definitions to investigate
+the primary unit check source coded in sense byte 0 :
+
+======================= ====
+SNS0_CMD_REJECT 0x80
+SNS0_INTERVENTION_REQ 0x40
+SNS0_BUS_OUT_CHECK 0x20
+SNS0_EQUIPMENT_CHECK 0x10
+SNS0_DATA_CHECK 0x08
+SNS0_OVERRUN 0x04
+SNS0_INCOMPL_DOMAIN 0x01
+======================= ====
+
+Depending on the device status, multiple of those values may be set together.
+Please refer to the device specific documentation for details.
+
+The irb->scsw.cstat field provides the (accumulated) subchannel status :
+
+========================= ============================
+SCHN_STAT_PCI program controlled interrupt
+SCHN_STAT_INCORR_LEN incorrect length
+SCHN_STAT_PROG_CHECK program check
+SCHN_STAT_PROT_CHECK protection check
+SCHN_STAT_CHN_DATA_CHK channel data check
+SCHN_STAT_CHN_CTRL_CHK channel control check
+SCHN_STAT_INTF_CTRL_CHK interface control check
+SCHN_STAT_CHAIN_CHECK chaining check
+========================= ============================
+
+The irb->scsw.dstat field provides the (accumulated) device status :
+
+===================== =================
+DEV_STAT_ATTENTION attention
+DEV_STAT_STAT_MOD status modifier
+DEV_STAT_CU_END control unit end
+DEV_STAT_BUSY busy
+DEV_STAT_CHN_END channel end
+DEV_STAT_DEV_END device end
+DEV_STAT_UNIT_CHECK unit check
+DEV_STAT_UNIT_EXCEP unit exception
+===================== =================
+
+Please see the ESA/390 Principles of Operation manual for details on the
+individual flag meanings.
+
+Usage Notes:
+
+ccw_device_start() must be called disabled and with the ccw device lock held.
+
+The device driver is allowed to issue the next ccw_device_start() call from
+within its interrupt handler already. It is not required to schedule a
+bottom-half, unless a non deterministically long running error recovery procedure
+or similar needs to be scheduled. During I/O processing the Linux/390 generic
+I/O device driver support has already obtained the IRQ lock, i.e. the handler
+must not try to obtain it again when calling ccw_device_start() or we end in a
+deadlock situation!
+
+If a device driver relies on an I/O request to be completed prior to start the
+next it can reduce I/O processing overhead by chaining a NoOp I/O command
+CCW_CMD_NOOP to the end of the submitted CCW chain. This will force Channel-End
+and Device-End status to be presented together, with a single interrupt.
+However, this should be used with care as it implies the channel will remain
+busy, not being able to process I/O requests for other devices on the same
+channel. Therefore e.g. read commands should never use this technique, as the
+result will be presented by a single interrupt anyway.
+
+In order to minimize I/O overhead, a device driver should use the
+DOIO_REPORT_ALL only if the device can report intermediate interrupt
+information prior to device-end the device driver urgently relies on. In this
+case all I/O interruptions are presented to the device driver until final
+status is recognized.
+
+If a device is able to recover from asynchronously presented I/O errors, it can
+perform overlapping I/O using the DOIO_EARLY_NOTIFICATION flag. While some
+devices always report channel-end and device-end together, with a single
+interrupt, others present primary status (channel-end) when the channel is
+ready for the next I/O request and secondary status (device-end) when the data
+transmission has been completed at the device.
+
+Above flag allows to exploit this feature, e.g. for communication devices that
+can handle lost data on the network to allow for enhanced I/O processing.
+
+Unless the channel subsystem at any time presents a secondary status interrupt,
+exploiting this feature will cause only primary status interrupts to be
+presented to the device driver while overlapping I/O is performed. When a
+secondary status without error (alert status) is presented, this indicates
+successful completion for all overlapping ccw_device_start() requests that have
+been issued since the last secondary (final) status.
+
+Channel programs that intend to set the suspend flag on a channel command word
+(CCW) must start the I/O operation with the DOIO_ALLOW_SUSPEND option or the
+suspend flag will cause a channel program check. At the time the channel program
+becomes suspended an intermediate interrupt will be generated by the channel
+subsystem.
+
+ccw_device_resume() - Resume Channel Program Execution
+
+If a device driver chooses to suspend the current channel program execution by
+setting the CCW suspend flag on a particular CCW, the channel program execution
+is suspended. In order to resume channel program execution the CIO layer
+provides the ccw_device_resume() routine.
+
+::
+
+ int ccw_device_resume(struct ccw_device *cdev);
+
+==== ================================================
+cdev ccw_device the resume operation is requested for
+==== ================================================
+
+The ccw_device_resume() function returns:
+
+========= ==============================================
+ 0 suspended channel program is resumed
+ -EBUSY status pending
+ -ENODEV cdev invalid or not-operational subchannel
+ -EINVAL resume function not applicable
+-ENOTCONN there is no I/O request pending for completion
+========= ==============================================
+
+Usage Notes:
+
+Please have a look at the ccw_device_start() usage notes for more details on
+suspended channel programs.
+
+ccw_device_halt() - Halt I/O Request Processing
+
+Sometimes a device driver might need a possibility to stop the processing of
+a long-running channel program or the device might require to initially issue
+a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt()
+command is provided.
+
+ccw_device_halt() must be called disabled and with the ccw device lock held.
+
+::
+
+ int ccw_device_halt(struct ccw_device *cdev,
+ unsigned long intparm);
+
+======= =====================================================
+cdev ccw_device the halt operation is requested for
+intparm interruption parameter; value is only used if no I/O
+ is outstanding, otherwise the intparm associated with
+ the I/O request is returned
+======= =====================================================
+
+The ccw_device_halt() function returns:
+
+======= ==============================================================
+ 0 request successfully initiated
+-EBUSY the device is currently busy, or status pending.
+-ENODEV cdev invalid.
+-EINVAL The device is not operational or the ccw device is not online.
+======= ==============================================================
+
+Usage Notes:
+
+A device driver may write a never-ending channel program by writing a channel
+program that at its end loops back to its beginning by means of a transfer in
+channel (TIC) command (CCW_CMD_TIC). Usually this is performed by network
+device drivers by setting the PCI CCW flag (CCW_FLAG_PCI). Once this CCW is
+executed a program controlled interrupt (PCI) is generated. The device driver
+can then perform an appropriate action. Prior to interrupt of an outstanding
+read to a network device (with or without PCI flag) a ccw_device_halt()
+is required to end the pending operation.
+
+::
+
+ ccw_device_clear() - Terminage I/O Request Processing
+
+In order to terminate all I/O processing at the subchannel, the clear subchannel
+(CSCH) command is used. It can be issued via ccw_device_clear().
+
+ccw_device_clear() must be called disabled and with the ccw device lock held.
+
+::
+
+ int ccw_device_clear(struct ccw_device *cdev, unsigned long intparm);
+
+======= ===============================================
+cdev ccw_device the clear operation is requested for
+intparm interruption parameter (see ccw_device_halt())
+======= ===============================================
+
+The ccw_device_clear() function returns:
+
+======= ==============================================================
+ 0 request successfully initiated
+-ENODEV cdev invalid
+-EINVAL The device is not operational or the ccw device is not online.
+======= ==============================================================
+
+Miscellaneous Support Routines
+------------------------------
+
+This chapter describes various routines to be used in a Linux/390 device
+driver programming environment.
+
+get_ccwdev_lock()
+
+Get the address of the device specific lock. This is then used in
+spin_lock() / spin_unlock() calls.
+
+::
+
+ __u8 ccw_device_get_path_mask(struct ccw_device *cdev);
+
+Get the mask of the path currently available for cdev.
diff --git a/Documentation/arch/s390/common_io.rst b/Documentation/arch/s390/common_io.rst
new file mode 100644
index 0000000..6dcb40c
--- /dev/null
+++ b/Documentation/arch/s390/common_io.rst
@@ -0,0 +1,140 @@
+======================
+S/390 common I/O-Layer
+======================
+
+command line parameters, procfs and debugfs entries
+===================================================
+
+Command line parameters
+-----------------------
+
+* ccw_timeout_log
+
+ Enable logging of debug information in case of ccw device timeouts.
+
+* cio_ignore = device[,device[,..]]
+
+ device := {all | [!]ipldev | [!]condev | [!]<devno> | [!]<devno>-<devno>}
+
+ The given devices will be ignored by the common I/O-layer; no detection
+ and device sensing will be done on any of those devices. The subchannel to
+ which the device in question is attached will be treated as if no device was
+ attached.
+
+ An ignored device can be un-ignored later; see the "/proc entries"-section for
+ details.
+
+ The devices must be given either as bus ids (0.x.abcd) or as hexadecimal
+ device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
+ give a device number 0xabcd, it will be interpreted as 0.0.abcd.
+
+ You can use the 'all' keyword to ignore all devices. The 'ipldev' and 'condev'
+ keywords can be used to refer to the CCW based boot device and CCW console
+ device respectively (these are probably useful only when combined with the '!'
+ operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.
+ The command line
+ is parsed from left to right.
+
+ For example::
+
+ cio_ignore=0.0.0023-0.0.0042,0.0.4711
+
+ will ignore all devices ranging from 0.0.0023 to 0.0.0042 and the device
+ 0.0.4711, if detected.
+
+ As another example::
+
+ cio_ignore=all,!0.0.4711,!0.0.fd00-0.0.fd02
+
+ will ignore all devices but 0.0.4711, 0.0.fd00, 0.0.fd01, 0.0.fd02.
+
+ By default, no devices are ignored.
+
+
+/proc entries
+-------------
+
+* /proc/cio_ignore
+
+ Lists the ranges of devices (by bus id) which are ignored by common I/O.
+
+ You can un-ignore certain or all devices by piping to /proc/cio_ignore.
+ "free all" will un-ignore all ignored devices,
+ "free <device range>, <device range>, ..." will un-ignore the specified
+ devices.
+
+ For example, if devices 0.0.0023 to 0.0.0042 and 0.0.4711 are ignored,
+
+ - echo free 0.0.0030-0.0.0032 > /proc/cio_ignore
+ will un-ignore devices 0.0.0030 to 0.0.0032 and will leave devices 0.0.0023
+ to 0.0.002f, 0.0.0033 to 0.0.0042 and 0.0.4711 ignored;
+ - echo free 0.0.0041 > /proc/cio_ignore will furthermore un-ignore device
+ 0.0.0041;
+ - echo free all > /proc/cio_ignore will un-ignore all remaining ignored
+ devices.
+
+ When a device is un-ignored, device recognition and sensing is performed and
+ the device driver will be notified if possible, so the device will become
+ available to the system. Note that un-ignoring is performed asynchronously.
+
+ You can also add ranges of devices to be ignored by piping to
+ /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
+ specified devices.
+
+ Note: While already known devices can be added to the list of devices to be
+ ignored, there will be no effect on then. However, if such a device
+ disappears and then reappears, it will then be ignored. To make
+ known devices go away, you need the "purge" command (see below).
+
+ For example::
+
+ "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
+
+ will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
+ devices.
+
+ You can remove already known but now ignored devices via::
+
+ "echo purge > /proc/cio_ignore"
+
+ All devices ignored but still registered and not online (= not in use)
+ will be deregistered and thus removed from the system.
+
+ The devices can be specified either by bus id (0.x.abcd) or, for 2.4 backward
+ compatibility, by the device number in hexadecimal (0xabcd or abcd). Device
+ numbers given as 0xabcd will be interpreted as 0.0.abcd.
+
+* /proc/cio_settle
+
+ A write request to this file is blocked until all queued cio actions are
+ handled. This will allow userspace to wait for pending work affecting
+ device availability after changing cio_ignore or the hardware configuration.
+
+* For some of the information present in the /proc filesystem in 2.4 (namely,
+ /proc/subchannels and /proc/chpids), see driver-model.txt.
+ Information formerly in /proc/irq_count is now in /proc/interrupts.
+
+
+debugfs entries
+---------------
+
+* /sys/kernel/debug/s390dbf/cio_*/ (S/390 debug feature)
+
+ Some views generated by the debug feature to hold various debug outputs.
+
+ - /sys/kernel/debug/s390dbf/cio_crw/sprintf
+ Messages from the processing of pending channel report words (machine check
+ handling).
+
+ - /sys/kernel/debug/s390dbf/cio_msg/sprintf
+ Various debug messages from the common I/O-layer.
+
+ - /sys/kernel/debug/s390dbf/cio_trace/hex_ascii
+ Logs the calling of functions in the common I/O-layer and, if applicable,
+ which subchannel they were called for, as well as dumps of some data
+ structures (like irb in an error case).
+
+ The level of logging can be changed to be more or less verbose by piping to
+ /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
+ documentation on the S/390 debug feature (Documentation/arch/s390/s390dbf.rst)
+ for details.
diff --git a/Documentation/s390/config3270.sh b/Documentation/arch/s390/config3270.sh
similarity index 100%
rename from Documentation/s390/config3270.sh
rename to Documentation/arch/s390/config3270.sh
diff --git a/Documentation/s390/driver-model.rst b/Documentation/arch/s390/driver-model.rst
similarity index 100%
rename from Documentation/s390/driver-model.rst
rename to Documentation/arch/s390/driver-model.rst
diff --git a/Documentation/s390/features.rst b/Documentation/arch/s390/features.rst
similarity index 100%
rename from Documentation/s390/features.rst
rename to Documentation/arch/s390/features.rst
diff --git a/Documentation/s390/index.rst b/Documentation/arch/s390/index.rst
similarity index 100%
rename from Documentation/s390/index.rst
rename to Documentation/arch/s390/index.rst
diff --git a/Documentation/s390/monreader.rst b/Documentation/arch/s390/monreader.rst
similarity index 100%
rename from Documentation/s390/monreader.rst
rename to Documentation/arch/s390/monreader.rst
diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
new file mode 100644
index 0000000..d575548
--- /dev/null
+++ b/Documentation/arch/s390/pci.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========
+S/390 PCI
+=========
+
+Authors:
+ - Pierre Morel
+
+Copyright, IBM Corp. 2020
+
+
+Command line parameters and debugfs entries
+===========================================
+
+Command line parameters
+-----------------------
+
+* nomio
+
+ Do not use PCI Mapped I/O (MIO) instructions.
+
+* norid
+
+ Ignore the RID field and force use of one PCI domain per PCI function.
+
+debugfs entries
+---------------
+
+The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form:
+
+ * /sys/kernel/debug/s390dbf/pci_*/
+
+For example:
+
+ - /sys/kernel/debug/s390dbf/pci_msg/sprintf
+ Holds messages from the processing of PCI events, like machine check handling
+ and setting of global functionality, like UID checking.
+
+ Change the level of logging to be more or less verbose by piping
+ a number between 0 and 6 to /sys/kernel/debug/s390dbf/pci_*/level. For
+ details, see the documentation on the S/390 debug feature at
+ Documentation/arch/s390/s390dbf.rst.
+
+Sysfs entries
+=============
+
+Entries specific to zPCI functions and entries that hold zPCI information.
+
+* /sys/bus/pci/slots/XXXXXXXX
+
+ The slot entries are set up using the function identifier (FID) of the
+ PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
+ with 0 padding and lower case hexadecimal digits.
+
+ - /sys/bus/pci/slots/XXXXXXXX/power
+
+ A physical function that currently supports a virtual function cannot be
+ powered off until all virtual functions are removed with:
+ echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
+
+* /sys/bus/pci/devices/XXXX:XX:XX.X/
+
+ - function_id
+ A zPCI function identifier that uniquely identifies the function in the Z server.
+
+ - function_handle
+ Low-level identifier used for a configured PCI function.
+ It might be useful for debugging.
+
+ - pchid
+ Model-dependent location of the I/O adapter.
+
+ - pfgid
+ PCI function group ID, functions that share identical functionality
+ use a common identifier.
+ A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics.
+
+ - vfn
+ The virtual function number, from 1 to N for virtual functions,
+ 0 for physical functions.
+
+ - pft
+ The PCI function type
+
+ - port
+ The port corresponds to the physical port the function is attached to.
+ It also gives an indication of the physical function a virtual function
+ is attached to.
+
+ - uid
+ The user identifier (UID) may be defined as part of the machine
+ configuration or the z/VM or KVM guest configuration. If the accompanying
+ uid_is_unique attribute is 1 the platform guarantees that the UID is unique
+ within that instance and no devices with the same UID can be attached
+ during the lifetime of the system.
+
+ - uid_is_unique
+ Indicates whether the user identifier (UID) is guaranteed to be and remain
+ unique within this Linux instance.
+
+ - pfip/segmentX
+ The segments determine the isolation of a function.
+ They correspond to the physical path to the function.
+ The more the segments are different, the more the functions are isolated.
+
+Enumeration and hotplug
+=======================
+
+The PCI address consists of four parts: domain, bus, device and function,
+and is of this form: DDDD:BB:dd.f
+
+* When not using multi-functions (norid is set, or the firmware does not
+ support multi-functions):
+
+ - There is only one function per domain.
+
+ - The domain is set from the zPCI function's UID as defined during the
+ LPAR creation.
+
+* When using multi-functions (norid parameter is not set),
+ zPCI functions are addressed differently:
+
+ - There is still only one bus per domain.
+
+ - There can be up to 256 functions per bus.
+
+ - The domain part of the address of all functions for
+ a multi-Function device is set from the zPCI function's UID as defined
+ in the LPAR creation for the function zero.
+
+ - New functions will only be ready for use after the function zero
+ (the function with devfn 0) has been enumerated.
diff --git a/Documentation/s390/qeth.rst b/Documentation/arch/s390/qeth.rst
similarity index 100%
rename from Documentation/s390/qeth.rst
rename to Documentation/arch/s390/qeth.rst
diff --git a/Documentation/s390/s390dbf.rst b/Documentation/arch/s390/s390dbf.rst
similarity index 100%
rename from Documentation/s390/s390dbf.rst
rename to Documentation/arch/s390/s390dbf.rst
diff --git a/Documentation/s390/text_files.rst b/Documentation/arch/s390/text_files.rst
similarity index 100%
rename from Documentation/s390/text_files.rst
rename to Documentation/arch/s390/text_files.rst
diff --git a/Documentation/s390/vfio-ap-locking.rst b/Documentation/arch/s390/vfio-ap-locking.rst
similarity index 100%
rename from Documentation/s390/vfio-ap-locking.rst
rename to Documentation/arch/s390/vfio-ap-locking.rst
diff --git a/Documentation/arch/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst
new file mode 100644
index 0000000..929ee1c
--- /dev/null
+++ b/Documentation/arch/s390/vfio-ap.rst
@@ -0,0 +1,1069 @@
+===============================
+Adjunct Processor (AP) facility
+===============================
+
+
+Introduction
+============
+The Adjunct Processor (AP) facility is an IBM Z cryptographic facility comprised
+of three AP instructions and from 1 up to 256 PCIe cryptographic adapter cards.
+The AP devices provide cryptographic functions to all CPUs assigned to a
+linux system running in an IBM Z system LPAR.
+
+The AP adapter cards are exposed via the AP bus. The motivation for vfio-ap
+is to make AP cards available to KVM guests using the VFIO mediated device
+framework. This implementation relies considerably on the s390 virtualization
+facilities which do most of the hard work of providing direct access to AP
+devices.
+
+AP Architectural Overview
+=========================
+To facilitate the comprehension of the design, let's start with some
+definitions:
+
+* AP adapter
+
+ An AP adapter is an IBM Z adapter card that can perform cryptographic
+ functions. There can be from 0 to 256 adapters assigned to an LPAR. Adapters
+ assigned to the LPAR in which a linux host is running will be available to
+ the linux host. Each adapter is identified by a number from 0 to 255; however,
+ the maximum adapter number is determined by machine model and/or adapter type.
+ When installed, an AP adapter is accessed by AP instructions executed by any
+ CPU.
+
+ The AP adapter cards are assigned to a given LPAR via the system's Activation
+ Profile which can be edited via the HMC. When the linux host system is IPL'd
+ in the LPAR, the AP bus detects the AP adapter cards assigned to the LPAR and
+ creates a sysfs device for each assigned adapter. For example, if AP adapters
+ 4 and 10 (0x0a) are assigned to the LPAR, the AP bus will create the following
+ sysfs device entries::
+
+ /sys/devices/ap/card04
+ /sys/devices/ap/card0a
+
+ Symbolic links to these devices will also be created in the AP bus devices
+ sub-directory::
+
+ /sys/bus/ap/devices/[card04]
+ /sys/bus/ap/devices/[card04]
+
+* AP domain
+
+ An adapter is partitioned into domains. An adapter can hold up to 256 domains
+ depending upon the adapter type and hardware configuration. A domain is
+ identified by a number from 0 to 255; however, the maximum domain number is
+ determined by machine model and/or adapter type.. A domain can be thought of
+ as a set of hardware registers and memory used for processing AP commands. A
+ domain can be configured with a secure private key used for clear key
+ encryption. A domain is classified in one of two ways depending upon how it
+ may be accessed:
+
+ * Usage domains are domains that are targeted by an AP instruction to
+ process an AP command.
+
+ * Control domains are domains that are changed by an AP command sent to a
+ usage domain; for example, to set the secure private key for the control
+ domain.
+
+ The AP usage and control domains are assigned to a given LPAR via the system's
+ Activation Profile which can be edited via the HMC. When a linux host system
+ is IPL'd in the LPAR, the AP bus module detects the AP usage and control
+ domains assigned to the LPAR. The domain number of each usage domain and
+ adapter number of each AP adapter are combined to create AP queue devices
+ (see AP Queue section below). The domain number of each control domain will be
+ represented in a bitmask and stored in a sysfs file
+ /sys/bus/ap/ap_control_domain_mask. The bits in the mask, from most to least
+ significant bit, correspond to domains 0-255.
+
+* AP Queue
+
+ An AP queue is the means by which an AP command is sent to a usage domain
+ inside a specific adapter. An AP queue is identified by a tuple
+ comprised of an AP adapter ID (APID) and an AP queue index (APQI). The
+ APQI corresponds to a given usage domain number within the adapter. This tuple
+ forms an AP Queue Number (APQN) uniquely identifying an AP queue. AP
+ instructions include a field containing the APQN to identify the AP queue to
+ which the AP command is to be sent for processing.
+
+ The AP bus will create a sysfs device for each APQN that can be derived from
+ the cross product of the AP adapter and usage domain numbers detected when the
+ AP bus module is loaded. For example, if adapters 4 and 10 (0x0a) and usage
+ domains 6 and 71 (0x47) are assigned to the LPAR, the AP bus will create the
+ following sysfs entries::
+
+ /sys/devices/ap/card04/04.0006
+ /sys/devices/ap/card04/04.0047
+ /sys/devices/ap/card0a/0a.0006
+ /sys/devices/ap/card0a/0a.0047
+
+ The following symbolic links to these devices will be created in the AP bus
+ devices subdirectory::
+
+ /sys/bus/ap/devices/[04.0006]
+ /sys/bus/ap/devices/[04.0047]
+ /sys/bus/ap/devices/[0a.0006]
+ /sys/bus/ap/devices/[0a.0047]
+
+* AP Instructions:
+
+ There are three AP instructions:
+
+ * NQAP: to enqueue an AP command-request message to a queue
+ * DQAP: to dequeue an AP command-reply message from a queue
+ * PQAP: to administer the queues
+
+ AP instructions identify the domain that is targeted to process the AP
+ command; this must be one of the usage domains. An AP command may modify a
+ domain that is not one of the usage domains, but the modified domain
+ must be one of the control domains.
+
+AP and SIE
+==========
+Let's now take a look at how AP instructions executed on a guest are interpreted
+by the hardware.
+
+A satellite control block called the Crypto Control Block (CRYCB) is attached to
+our main hardware virtualization control block. The CRYCB contains an AP Control
+Block (APCB) that has three fields to identify the adapters, usage domains and
+control domains assigned to the KVM guest:
+
+* The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned
+ to the KVM guest. Each bit in the mask, from left to right, corresponds to
+ an APID from 0-255. If a bit is set, the corresponding adapter is valid for
+ use by the KVM guest.
+
+* The AP Queue Mask (AQM) field is a bit mask identifying the AP usage domains
+ assigned to the KVM guest. Each bit in the mask, from left to right,
+ corresponds to an AP queue index (APQI) from 0-255. If a bit is set, the
+ corresponding queue is valid for use by the KVM guest.
+
+* The AP Domain Mask field is a bit mask that identifies the AP control domains
+ assigned to the KVM guest. The ADM bit mask controls which domains can be
+ changed by an AP command-request message sent to a usage domain from the
+ guest. Each bit in the mask, from left to right, corresponds to a domain from
+ 0-255. If a bit is set, the corresponding domain can be modified by an AP
+ command-request message sent to a usage domain.
+
+If you recall from the description of an AP Queue, AP instructions include
+an APQN to identify the AP queue to which an AP command-request message is to be
+sent (NQAP and PQAP instructions), or from which a command-reply message is to
+be received (DQAP instruction). The validity of an APQN is defined by the matrix
+calculated from the APM and AQM; it is the Cartesian product of all assigned
+adapter numbers (APM) with all assigned queue indexes (AQM). For example, if
+adapters 1 and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs
+(1,5), (1,6), (2,5) and (2,6) will be valid for the guest.
+
+The APQNs can provide secure key functionality - i.e., a private key is stored
+on the adapter card for each of its domains - so each APQN must be assigned to
+at most one guest or to the linux host::
+
+ Example 1: Valid configuration:
+ ------------------------------
+ Guest1: adapters 1,2 domains 5,6
+ Guest2: adapter 1,2 domain 7
+
+ This is valid because both guests have a unique set of APQNs:
+ Guest1 has APQNs (1,5), (1,6), (2,5), (2,6);
+ Guest2 has APQNs (1,7), (2,7)
+
+ Example 2: Valid configuration:
+ ------------------------------
+ Guest1: adapters 1,2 domains 5,6
+ Guest2: adapters 3,4 domains 5,6
+
+ This is also valid because both guests have a unique set of APQNs:
+ Guest1 has APQNs (1,5), (1,6), (2,5), (2,6);
+ Guest2 has APQNs (3,5), (3,6), (4,5), (4,6)
+
+ Example 3: Invalid configuration:
+ --------------------------------
+ Guest1: adapters 1,2 domains 5,6
+ Guest2: adapter 1 domains 6,7
+
+ This is an invalid configuration because both guests have access to
+ APQN (1,6).
+
+The Design
+==========
+The design introduces three new objects:
+
+1. AP matrix device
+2. VFIO AP device driver (vfio_ap.ko)
+3. VFIO AP mediated pass-through device
+
+The VFIO AP device driver
+-------------------------
+The VFIO AP (vfio_ap) device driver serves the following purposes:
+
+1. Provides the interfaces to secure APQNs for exclusive use of KVM guests.
+
+2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated
+ device and creates the sysfs interfaces for assigning adapters, usage
+ domains, and control domains comprising the matrix for a KVM guest.
+
+3. Configures the APM, AQM and ADM in the APCB contained in the CRYCB referenced
+ by a KVM guest's SIE state description to grant the guest access to a matrix
+ of AP devices
+
+Reserve APQNs for exclusive use of KVM guests
+---------------------------------------------
+The following block diagram illustrates the mechanism by which APQNs are
+reserved::
+
+ +------------------+
+ 7 remove | |
+ +--------------------> cex4queue driver |
+ | | |
+ | +------------------+
+ |
+ |
+ | +------------------+ +----------------+
+ | 5 register driver | | 3 create | |
+ | +----------------> Device core +----------> matrix device |
+ | | | | | |
+ | | +--------^---------+ +----------------+
+ | | |
+ | | +-------------------+
+ | | +-----------------------------------+ |
+ | | | 4 register AP driver | | 2 register device
+ | | | | |
+ +--------+---+-v---+ +--------+-------+-+
+ | | | |
+ | ap_bus +--------------------- > vfio_ap driver |
+ | | 8 probe | |
+ +--------^---------+ +--^--^------------+
+ 6 edit | | |
+ apmask | +-----------------------------+ | 11 mdev create
+ aqmask | | 1 modprobe |
+ +--------+-----+---+ +----------------+-+ +----------------+
+ | | | |10 create| mediated |
+ | admin | | VFIO device core |---------> matrix |
+ | + | | | device |
+ +------+-+---------+ +--------^---------+ +--------^-------+
+ | | | |
+ | | 9 create vfio_ap-passthrough | |
+ | +------------------------------+ |
+ +-------------------------------------------------------------+
+ 12 assign adapter/domain/control domain
+
+The process for reserving an AP queue for use by a KVM guest is:
+
+1. The administrator loads the vfio_ap device driver
+2. The vfio-ap driver during its initialization will register a single 'matrix'
+ device with the device core. This will serve as the parent device for
+ all vfio_ap mediated devices used to configure an AP matrix for a guest.
+3. The /sys/devices/vfio_ap/matrix device is created by the device core
+4. The vfio_ap device driver will register with the AP bus for AP queue devices
+ of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap
+ driver's probe and remove callback interfaces. Devices older than CEX4 queues
+ are not supported to simplify the implementation by not needlessly
+ complicating the design by supporting older devices that will go out of
+ service in the relatively near future, and for which there are few older
+ systems around on which to test.
+5. The AP bus registers the vfio_ap device driver with the device core
+6. The administrator edits the AP adapter and queue masks to reserve AP queues
+ for use by the vfio_ap device driver.
+7. The AP bus removes the AP queues reserved for the vfio_ap driver from the
+ default zcrypt cex4queue driver.
+8. The AP bus probes the vfio_ap device driver to bind the queues reserved for
+ it.
+9. The administrator creates a passthrough type vfio_ap mediated device to be
+ used by a guest
+10. The administrator assigns the adapters, usage domains and control domains
+ to be exclusively used by a guest.
+
+Set up the VFIO mediated device interfaces
+------------------------------------------
+The VFIO AP device driver utilizes the common interfaces of the VFIO mediated
+device core driver to:
+
+* Register an AP mediated bus driver to add a vfio_ap mediated device to and
+ remove it from a VFIO group.
+* Create and destroy a vfio_ap mediated device
+* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver
+* Add a vfio_ap mediated device to and remove it from an IOMMU group
+
+The following high-level block diagram shows the main components and interfaces
+of the VFIO AP mediated device driver::
+
+ +-------------+
+ | |
+ | +---------+ | mdev_register_driver() +--------------+
+ | | Mdev | +<-----------------------+ |
+ | | bus | | | vfio_mdev.ko |
+ | | driver | +----------------------->+ |<-> VFIO user
+ | +---------+ | probe()/remove() +--------------+ APIs
+ | |
+ | MDEV CORE |
+ | MODULE |
+ | mdev.ko |
+ | +---------+ | mdev_register_parent() +--------------+
+ | |Physical | +<-----------------------+ |
+ | | device | | | vfio_ap.ko |<-> matrix
+ | |interface| +----------------------->+ | device
+ | +---------+ | callback +--------------+
+ +-------------+
+
+During initialization of the vfio_ap module, the matrix device is registered
+with an 'mdev_parent_ops' structure that provides the sysfs attribute
+structures, mdev functions and callback interfaces for managing the mediated
+matrix device.
+
+* sysfs attribute structures:
+
+ supported_type_groups
+ The VFIO mediated device framework supports creation of user-defined
+ mediated device types. These mediated device types are specified
+ via the 'supported_type_groups' structure when a device is registered
+ with the mediated device framework. The registration process creates the
+ sysfs structures for each mediated device type specified in the
+ 'mdev_supported_types' sub-directory of the device being registered. Along
+ with the device type, the sysfs attributes of the mediated device type are
+ provided.
+
+ The VFIO AP device driver will register one mediated device type for
+ passthrough devices:
+
+ /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough
+
+ Only the read-only attributes required by the VFIO mdev framework will
+ be provided::
+
+ ... name
+ ... device_api
+ ... available_instances
+ ... device_api
+
+ Where:
+
+ * name:
+ specifies the name of the mediated device type
+ * device_api:
+ the mediated device type's API
+ * available_instances:
+ the number of vfio_ap mediated passthrough devices
+ that can be created
+ * device_api:
+ specifies the VFIO API
+ mdev_attr_groups
+ This attribute group identifies the user-defined sysfs attributes of the
+ mediated device. When a device is registered with the VFIO mediated device
+ framework, the sysfs attribute files identified in the 'mdev_attr_groups'
+ structure will be created in the vfio_ap mediated device's directory. The
+ sysfs attributes for a vfio_ap mediated device are:
+
+ assign_adapter / unassign_adapter:
+ Write-only attributes for assigning/unassigning an AP adapter to/from the
+ vfio_ap mediated device. To assign/unassign an adapter, the APID of the
+ adapter is echoed into the respective attribute file.
+ assign_domain / unassign_domain:
+ Write-only attributes for assigning/unassigning an AP usage domain to/from
+ the vfio_ap mediated device. To assign/unassign a domain, the domain
+ number of the usage domain is echoed into the respective attribute
+ file.
+ matrix:
+ A read-only file for displaying the APQNs derived from the Cartesian
+ product of the adapter and domain numbers assigned to the vfio_ap mediated
+ device.
+ guest_matrix:
+ A read-only file for displaying the APQNs derived from the Cartesian
+ product of the adapter and domain numbers assigned to the APM and AQM
+ fields respectively of the KVM guest's CRYCB. This may differ from the
+ the APQNs assigned to the vfio_ap mediated device if any APQN does not
+ reference a queue device bound to the vfio_ap device driver (i.e., the
+ queue is not in the host's AP configuration).
+ assign_control_domain / unassign_control_domain:
+ Write-only attributes for assigning/unassigning an AP control domain
+ to/from the vfio_ap mediated device. To assign/unassign a control domain,
+ the ID of the domain to be assigned/unassigned is echoed into the
+ respective attribute file.
+ control_domains:
+ A read-only file for displaying the control domain numbers assigned to the
+ vfio_ap mediated device.
+
+* functions:
+
+ create:
+ allocates the ap_matrix_mdev structure used by the vfio_ap driver to:
+
+ * Store the reference to the KVM structure for the guest using the mdev
+ * Store the AP matrix configuration for the adapters, domains, and control
+ domains assigned via the corresponding sysfs attributes files
+ * Store the AP matrix configuration for the adapters, domains and control
+ domains available to a guest. A guest may not be provided access to APQNs
+ referencing queue devices that do not exist, or are not bound to the
+ vfio_ap device driver.
+
+ remove:
+ deallocates the vfio_ap mediated device's ap_matrix_mdev structure.
+ This will be allowed only if a running guest is not using the mdev.
+
+* callback interfaces
+
+ open_device:
+ The vfio_ap driver uses this callback to register a
+ VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the matrix mdev
+ devices. The open_device callback is invoked by userspace to connect the
+ VFIO iommu group for the matrix mdev device to the MDEV bus. Access to the
+ KVM structure used to configure the KVM guest is provided via this callback.
+ The KVM structure, is used to configure the guest's access to the AP matrix
+ defined via the vfio_ap mediated device's sysfs attribute files.
+
+ close_device:
+ unregisters the VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the
+ matrix mdev device and deconfigures the guest's AP matrix.
+
+ ioctl:
+ this callback handles the VFIO_DEVICE_GET_INFO and VFIO_DEVICE_RESET ioctls
+ defined by the vfio framework.
+
+Configure the guest's AP resources
+----------------------------------
+Configuring the AP resources for a KVM guest will be performed when the
+VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier
+function is called when userspace connects to KVM. The guest's AP resources are
+configured via its APCB by:
+
+* Setting the bits in the APM corresponding to the APIDs assigned to the
+ vfio_ap mediated device via its 'assign_adapter' interface.
+* Setting the bits in the AQM corresponding to the domains assigned to the
+ vfio_ap mediated device via its 'assign_domain' interface.
+* Setting the bits in the ADM corresponding to the domain dIDs assigned to the
+ vfio_ap mediated device via its 'assign_control_domains' interface.
+
+The linux device model precludes passing a device through to a KVM guest that
+is not bound to the device driver facilitating its pass-through. Consequently,
+an APQN that does not reference a queue device bound to the vfio_ap device
+driver will not be assigned to a KVM guest's matrix. The AP architecture,
+however, does not provide a means to filter individual APQNs from the guest's
+matrix, so the adapters, domains and control domains assigned to vfio_ap
+mediated device via its sysfs 'assign_adapter', 'assign_domain' and
+'assign_control_domain' interfaces will be filtered before providing the AP
+configuration to a guest:
+
+* The APIDs of the adapters, the APQIs of the domains and the domain numbers of
+ the control domains assigned to the matrix mdev that are not also assigned to
+ the host's AP configuration will be filtered.
+
+* Each APQN derived from the Cartesian product of the APIDs and APQIs assigned
+ to the vfio_ap mdev is examined and if any one of them does not reference a
+ queue device bound to the vfio_ap device driver, the adapter will not be
+ plugged into the guest (i.e., the bit corresponding to its APID will not be
+ set in the APM of the guest's APCB).
+
+The CPU model features for AP
+-----------------------------
+The AP stack relies on the presence of the AP instructions as well as three
+facilities: The AP Facilities Test (APFT) facility; the AP Query
+Configuration Information (QCI) facility; and the AP Queue Interruption Control
+facility. These features/facilities are made available to a KVM guest via the
+following CPU model features:
+
+1. ap: Indicates whether the AP instructions are installed on the guest. This
+ feature will be enabled by KVM only if the AP instructions are installed
+ on the host.
+
+2. apft: Indicates the APFT facility is available on the guest. This facility
+ can be made available to the guest only if it is available on the host (i.e.,
+ facility bit 15 is set).
+
+3. apqci: Indicates the AP QCI facility is available on the guest. This facility
+ can be made available to the guest only if it is available on the host (i.e.,
+ facility bit 12 is set).
+
+4. apqi: Indicates AP Queue Interruption Control faclity is available on the
+ guest. This facility can be made available to the guest only if it is
+ available on the host (i.e., facility bit 65 is set).
+
+Note: If the user chooses to specify a CPU model different than the 'host'
+model to QEMU, the CPU model features and facilities need to be turned on
+explicitly; for example::
+
+ /usr/bin/qemu-system-s390x ... -cpu z13,ap=on,apqci=on,apft=on,apqi=on
+
+A guest can be precluded from using AP features/facilities by turning them off
+explicitly; for example::
+
+ /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off,apqi=off
+
+Note: If the APFT facility is turned off (apft=off) for the guest, the guest
+will not see any AP devices. The zcrypt device drivers on the guest that
+register for type 10 and newer AP devices - i.e., the cex4card and cex4queue
+device drivers - need the APFT facility to ascertain the facilities installed on
+a given AP device. If the APFT facility is not installed on the guest, then no
+adapter or domain devices will get created by the AP bus running on the
+guest because only type 10 and newer devices can be configured for guest use.
+
+Example
+=======
+Let's now provide an example to illustrate how KVM guests may be given
+access to AP facilities. For this example, we will show how to configure
+three guests such that executing the lszcrypt command on the guests would
+look like this:
+
+Guest1
+------
+=========== ===== ============
+CARD.DOMAIN TYPE MODE
+=========== ===== ============
+05 CEX5C CCA-Coproc
+05.0004 CEX5C CCA-Coproc
+05.00ab CEX5C CCA-Coproc
+06 CEX5A Accelerator
+06.0004 CEX5A Accelerator
+06.00ab CEX5A Accelerator
+=========== ===== ============
+
+Guest2
+------
+=========== ===== ============
+CARD.DOMAIN TYPE MODE
+=========== ===== ============
+05 CEX5C CCA-Coproc
+05.0047 CEX5C CCA-Coproc
+05.00ff CEX5C CCA-Coproc
+=========== ===== ============
+
+Guest3
+------
+=========== ===== ============
+CARD.DOMAIN TYPE MODE
+=========== ===== ============
+06 CEX5A Accelerator
+06.0047 CEX5A Accelerator
+06.00ff CEX5A Accelerator
+=========== ===== ============
+
+These are the steps:
+
+1. Install the vfio_ap module on the linux host. The dependency chain for the
+ vfio_ap module is:
+ * iommu
+ * s390
+ * zcrypt
+ * vfio
+ * vfio_mdev
+ * vfio_mdev_device
+ * KVM
+
+ To build the vfio_ap module, the kernel build must be configured with the
+ following Kconfig elements selected:
+ * IOMMU_SUPPORT
+ * S390
+ * ZCRYPT
+ * VFIO
+ * KVM
+
+ If using make menuconfig select the following to build the vfio_ap module::
+
+ -> Device Drivers
+ -> IOMMU Hardware Support
+ select S390 AP IOMMU Support
+ -> VFIO Non-Privileged userspace driver framework
+ -> Mediated device driver frramework
+ -> VFIO driver for Mediated devices
+ -> I/O subsystem
+ -> VFIO support for AP devices
+
+2. Secure the AP queues to be used by the three guests so that the host can not
+ access them. To secure them, there are two sysfs files that specify
+ bitmasks marking a subset of the APQN range as usable only by the default AP
+ queue device drivers. All remaining APQNs are available for use by
+ any other device driver. The vfio_ap device driver is currently the only
+ non-default device driver. The location of the sysfs files containing the
+ masks are::
+
+ /sys/bus/ap/apmask
+ /sys/bus/ap/aqmask
+
+ The 'apmask' is a 256-bit mask that identifies a set of AP adapter IDs
+ (APID). Each bit in the mask, from left to right, corresponds to an APID from
+ 0-255. If a bit is set, the APID belongs to the subset of APQNs marked as
+ available only to the default AP queue device drivers.
+
+ The 'aqmask' is a 256-bit mask that identifies a set of AP queue indexes
+ (APQI). Each bit in the mask, from left to right, corresponds to an APQI from
+ 0-255. If a bit is set, the APQI belongs to the subset of APQNs marked as
+ available only to the default AP queue device drivers.
+
+ The Cartesian product of the APIDs corresponding to the bits set in the
+ apmask and the APQIs corresponding to the bits set in the aqmask comprise
+ the subset of APQNs that can be used only by the host default device drivers.
+ All other APQNs are available to the non-default device drivers such as the
+ vfio_ap driver.
+
+ Take, for example, the following masks::
+
+ apmask:
+ 0x7d00000000000000000000000000000000000000000000000000000000000000
+
+ aqmask:
+ 0x8000000000000000000000000000000000000000000000000000000000000000
+
+ The masks indicate:
+
+ * Adapters 1, 2, 3, 4, 5, and 7 are available for use by the host default
+ device drivers.
+
+ * Domain 0 is available for use by the host default device drivers
+
+ * The subset of APQNs available for use only by the default host device
+ drivers are:
+
+ (1,0), (2,0), (3,0), (4.0), (5,0) and (7,0)
+
+ * All other APQNs are available for use by the non-default device drivers.
+
+ The APQN of each AP queue device assigned to the linux host is checked by the
+ AP bus against the set of APQNs derived from the Cartesian product of APIDs
+ and APQIs marked as available to the default AP queue device drivers. If a
+ match is detected, only the default AP queue device drivers will be probed;
+ otherwise, the vfio_ap device driver will be probed.
+
+ By default, the two masks are set to reserve all APQNs for use by the default
+ AP queue device drivers. There are two ways the default masks can be changed:
+
+ 1. The sysfs mask files can be edited by echoing a string into the
+ respective sysfs mask file in one of two formats:
+
+ * An absolute hex string starting with 0x - like "0x12345678" - sets
+ the mask. If the given string is shorter than the mask, it is padded
+ with 0s on the right; for example, specifying a mask value of 0x41 is
+ the same as specifying::
+
+ 0x4100000000000000000000000000000000000000000000000000000000000000
+
+ Keep in mind that the mask reads from left to right, so the mask
+ above identifies device numbers 1 and 7 (01000001).
+
+ If the string is longer than the mask, the operation is terminated with
+ an error (EINVAL).
+
+ * Individual bits in the mask can be switched on and off by specifying
+ each bit number to be switched in a comma separated list. Each bit
+ number string must be prepended with a ('+') or minus ('-') to indicate
+ the corresponding bit is to be switched on ('+') or off ('-'). Some
+ valid values are:
+
+ - "+0" switches bit 0 on
+ - "-13" switches bit 13 off
+ - "+0x41" switches bit 65 on
+ - "-0xff" switches bit 255 off
+
+ The following example:
+
+ +0,-6,+0x47,-0xf0
+
+ Switches bits 0 and 71 (0x47) on
+
+ Switches bits 6 and 240 (0xf0) off
+
+ Note that the bits not specified in the list remain as they were before
+ the operation.
+
+ 2. The masks can also be changed at boot time via parameters on the kernel
+ command line like this:
+
+ ap.apmask=0xffff ap.aqmask=0x40
+
+ This would create the following masks::
+
+ apmask:
+ 0xffff000000000000000000000000000000000000000000000000000000000000
+
+ aqmask:
+ 0x4000000000000000000000000000000000000000000000000000000000000000
+
+ Resulting in these two pools::
+
+ default drivers pool: adapter 0-15, domain 1
+ alternate drivers pool: adapter 16-255, domains 0, 2-255
+
+ **Note:**
+ Changing a mask such that one or more APQNs will be taken from a vfio_ap
+ mediated device (see below) will fail with an error (EBUSY). A message
+ is logged to the kernel ring buffer which can be viewed with the 'dmesg'
+ command. The output identifies each APQN flagged as 'in use' and identifies
+ the vfio_ap mediated device to which it is assigned; for example:
+
+ Userspace may not re-assign queue 05.0054 already assigned to 62177883-f1bb-47f0-914d-32a22e3a8804
+ Userspace may not re-assign queue 04.0054 already assigned to cef03c3c-903d-4ecc-9a83-40694cb8aee4
+
+Securing the APQNs for our example
+----------------------------------
+ To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047,
+ 06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding
+ APQNs can be removed from the default masks using either of the following
+ commands::
+
+ echo -5,-6 > /sys/bus/ap/apmask
+
+ echo -4,-0x47,-0xab,-0xff > /sys/bus/ap/aqmask
+
+ Or the masks can be set as follows::
+
+ echo 0xf9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
+ > apmask
+
+ echo 0xf7fffffffffffffffeffffffffffffffffffffffffeffffffffffffffffffffe \
+ > aqmask
+
+ This will result in AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004,
+ 06.0047, 06.00ab, and 06.00ff getting bound to the vfio_ap device driver. The
+ sysfs directory for the vfio_ap device driver will now contain symbolic links
+ to the AP queue devices bound to it::
+
+ /sys/bus/ap
+ ... [drivers]
+ ...... [vfio_ap]
+ ......... [05.0004]
+ ......... [05.0047]
+ ......... [05.00ab]
+ ......... [05.00ff]
+ ......... [06.0004]
+ ......... [06.0047]
+ ......... [06.00ab]
+ ......... [06.00ff]
+
+ Keep in mind that only type 10 and newer adapters (i.e., CEX4 and later)
+ can be bound to the vfio_ap device driver. The reason for this is to
+ simplify the implementation by not needlessly complicating the design by
+ supporting older devices that will go out of service in the relatively near
+ future and for which there are few older systems on which to test.
+
+ The administrator, therefore, must take care to secure only AP queues that
+ can be bound to the vfio_ap device driver. The device type for a given AP
+ queue device can be read from the parent card's sysfs directory. For example,
+ to see the hardware type of the queue 05.0004:
+
+ cat /sys/bus/ap/devices/card05/hwtype
+
+ The hwtype must be 10 or higher (CEX4 or newer) in order to be bound to the
+ vfio_ap device driver.
+
+3. Create the mediated devices needed to configure the AP matrixes for the
+ three guests and to provide an interface to the vfio_ap driver for
+ use by the guests::
+
+ /sys/devices/vfio_ap/matrix/
+ --- [mdev_supported_types]
+ ------ [vfio_ap-passthrough] (passthrough vfio_ap mediated device type)
+ --------- create
+ --------- [devices]
+
+ To create the mediated devices for the three guests::
+
+ uuidgen > create
+ uuidgen > create
+ uuidgen > create
+
+ or
+
+ echo $uuid1 > create
+ echo $uuid2 > create
+ echo $uuid3 > create
+
+ This will create three mediated devices in the [devices] subdirectory named
+ after the UUID written to the create attribute file. We call them $uuid1,
+ $uuid2 and $uuid3 and this is the sysfs directory structure after creation::
+
+ /sys/devices/vfio_ap/matrix/
+ --- [mdev_supported_types]
+ ------ [vfio_ap-passthrough]
+ --------- [devices]
+ ------------ [$uuid1]
+ --------------- assign_adapter
+ --------------- assign_control_domain
+ --------------- assign_domain
+ --------------- matrix
+ --------------- unassign_adapter
+ --------------- unassign_control_domain
+ --------------- unassign_domain
+
+ ------------ [$uuid2]
+ --------------- assign_adapter
+ --------------- assign_control_domain
+ --------------- assign_domain
+ --------------- matrix
+ --------------- unassign_adapter
+ ----------------unassign_control_domain
+ ----------------unassign_domain
+
+ ------------ [$uuid3]
+ --------------- assign_adapter
+ --------------- assign_control_domain
+ --------------- assign_domain
+ --------------- matrix
+ --------------- unassign_adapter
+ ----------------unassign_control_domain
+ ----------------unassign_domain
+
+ Note *****: The vfio_ap mdevs do not persist across reboots unless the
+ mdevctl tool is used to create and persist them.
+
+4. The administrator now needs to configure the matrixes for the mediated
+ devices $uuid1 (for Guest1), $uuid2 (for Guest2) and $uuid3 (for Guest3).
+
+ This is how the matrix is configured for Guest1::
+
+ echo 5 > assign_adapter
+ echo 6 > assign_adapter
+ echo 4 > assign_domain
+ echo 0xab > assign_domain
+
+ Control domains can similarly be assigned using the assign_control_domain
+ sysfs file.
+
+ If a mistake is made configuring an adapter, domain or control domain,
+ you can use the unassign_xxx files to unassign the adapter, domain or
+ control domain.
+
+ To display the matrix configuration for Guest1::
+
+ cat matrix
+
+ To display the matrix that is or will be assigned to Guest1::
+
+ cat guest_matrix
+
+ This is how the matrix is configured for Guest2::
+
+ echo 5 > assign_adapter
+ echo 0x47 > assign_domain
+ echo 0xff > assign_domain
+
+ This is how the matrix is configured for Guest3::
+
+ echo 6 > assign_adapter
+ echo 0x47 > assign_domain
+ echo 0xff > assign_domain
+
+ In order to successfully assign an adapter:
+
+ * The adapter number specified must represent a value from 0 up to the
+ maximum adapter number configured for the system. If an adapter number
+ higher than the maximum is specified, the operation will terminate with
+ an error (ENODEV).
+
+ Note: The maximum adapter number can be obtained via the sysfs
+ /sys/bus/ap/ap_max_adapter_id attribute file.
+
+ * Each APQN derived from the Cartesian product of the APID of the adapter
+ being assigned and the APQIs of the domains previously assigned:
+
+ - Must only be available to the vfio_ap device driver as specified in the
+ sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even
+ one APQN is reserved for use by the host device driver, the operation
+ will terminate with an error (EADDRNOTAVAIL).
+
+ - Must NOT be assigned to another vfio_ap mediated device. If even one APQN
+ is assigned to another vfio_ap mediated device, the operation will
+ terminate with an error (EBUSY).
+
+ - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and
+ sys/bus/ap/aqmask attribute files are being edited or the operation may
+ terminate with an error (EBUSY).
+
+ In order to successfully assign a domain:
+
+ * The domain number specified must represent a value from 0 up to the
+ maximum domain number configured for the system. If a domain number
+ higher than the maximum is specified, the operation will terminate with
+ an error (ENODEV).
+
+ Note: The maximum domain number can be obtained via the sysfs
+ /sys/bus/ap/ap_max_domain_id attribute file.
+
+ * Each APQN derived from the Cartesian product of the APQI of the domain
+ being assigned and the APIDs of the adapters previously assigned:
+
+ - Must only be available to the vfio_ap device driver as specified in the
+ sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even
+ one APQN is reserved for use by the host device driver, the operation
+ will terminate with an error (EADDRNOTAVAIL).
+
+ - Must NOT be assigned to another vfio_ap mediated device. If even one APQN
+ is assigned to another vfio_ap mediated device, the operation will
+ terminate with an error (EBUSY).
+
+ - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and
+ sys/bus/ap/aqmask attribute files are being edited or the operation may
+ terminate with an error (EBUSY).
+
+ In order to successfully assign a control domain:
+
+ * The domain number specified must represent a value from 0 up to the maximum
+ domain number configured for the system. If a control domain number higher
+ than the maximum is specified, the operation will terminate with an
+ error (ENODEV).
+
+5. Start Guest1::
+
+ /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \
+ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ...
+
+7. Start Guest2::
+
+ /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \
+ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ...
+
+7. Start Guest3::
+
+ /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \
+ -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ...
+
+When the guest is shut down, the vfio_ap mediated devices may be removed.
+
+Using our example again, to remove the vfio_ap mediated device $uuid1::
+
+ /sys/devices/vfio_ap/matrix/
+ --- [mdev_supported_types]
+ ------ [vfio_ap-passthrough]
+ --------- [devices]
+ ------------ [$uuid1]
+ --------------- remove
+
+::
+
+ echo 1 > remove
+
+This will remove all of the matrix mdev device's sysfs structures including
+the mdev device itself. To recreate and reconfigure the matrix mdev device,
+all of the steps starting with step 3 will have to be performed again. Note
+that the remove will fail if a guest using the vfio_ap mdev is still running.
+
+It is not necessary to remove a vfio_ap mdev, but one may want to
+remove it if no guest will use it during the remaining lifetime of the linux
+host. If the vfio_ap mdev is removed, one may want to also reconfigure
+the pool of adapters and queues reserved for use by the default drivers.
+
+Hot plug/unplug support:
+========================
+An adapter, domain or control domain may be hot plugged into a running KVM
+guest by assigning it to the vfio_ap mediated device being used by the guest if
+the following conditions are met:
+
+* The adapter, domain or control domain must also be assigned to the host's
+ AP configuration.
+
+* Each APQN derived from the Cartesian product comprised of the APID of the
+ adapter being assigned and the APQIs of the domains assigned must reference a
+ queue device bound to the vfio_ap device driver.
+
+* To hot plug a domain, each APQN derived from the Cartesian product
+ comprised of the APQI of the domain being assigned and the APIDs of the
+ adapters assigned must reference a queue device bound to the vfio_ap device
+ driver.
+
+An adapter, domain or control domain may be hot unplugged from a running KVM
+guest by unassigning it from the vfio_ap mediated device being used by the
+guest.
+
+Over-provisioning of AP queues for a KVM guest:
+===============================================
+Over-provisioning is defined herein as the assignment of adapters or domains to
+a vfio_ap mediated device that do not reference AP devices in the host's AP
+configuration. The idea here is that when the adapter or domain becomes
+available, it will be automatically hot-plugged into the KVM guest using
+the vfio_ap mediated device to which it is assigned as long as each new APQN
+resulting from plugging it in references a queue device bound to the vfio_ap
+device driver.
+
+Limitations
+===========
+Live guest migration is not supported for guests using AP devices without
+intervention by a system administrator. Before a KVM guest can be migrated,
+the vfio_ap mediated device must be removed. Unfortunately, it can not be
+removed manually (i.e., echo 1 > /sys/devices/vfio_ap/matrix/$UUID/remove) while
+the mdev is in use by a KVM guest. If the guest is being emulated by QEMU,
+its mdev can be hot unplugged from the guest in one of two ways:
+
+1. If the KVM guest was started with libvirt, you can hot unplug the mdev via
+ the following commands:
+
+ virsh detach-device <guestname> <path-to-device-xml>
+
+ For example, to hot unplug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 from
+ the guest named 'my-guest':
+
+ virsh detach-device my-guest ~/config/my-guest-hostdev.xml
+
+ The contents of my-guest-hostdev.xml:
+
+.. code-block:: xml
+
+ <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'>
+ <source>
+ <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/>
+ </source>
+ </hostdev>
+
+
+ virsh qemu-monitor-command <guest-name> --hmp "device-del <device-id>"
+
+ For example, to hot unplug the vfio_ap mediated device identified on the
+ qemu command line with 'id=hostdev0' from the guest named 'my-guest':
+
+.. code-block:: sh
+
+ virsh qemu-monitor-command my-guest --hmp "device_del hostdev0"
+
+2. A vfio_ap mediated device can be hot unplugged by attaching the qemu monitor
+ to the guest and using the following qemu monitor command:
+
+ (QEMU) device-del id=<device-id>
+
+ For example, to hot unplug the vfio_ap mediated device that was specified
+ on the qemu command line with 'id=hostdev0' when the guest was started:
+
+ (QEMU) device-del id=hostdev0
+
+After live migration of the KVM guest completes, an AP configuration can be
+restored to the KVM guest by hot plugging a vfio_ap mediated device on the target
+system into the guest in one of two ways:
+
+1. If the KVM guest was started with libvirt, you can hot plug a matrix mediated
+ device into the guest via the following virsh commands:
+
+ virsh attach-device <guestname> <path-to-device-xml>
+
+ For example, to hot plug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 into
+ the guest named 'my-guest':
+
+ virsh attach-device my-guest ~/config/my-guest-hostdev.xml
+
+ The contents of my-guest-hostdev.xml:
+
+.. code-block:: xml
+
+ <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'>
+ <source>
+ <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/>
+ </source>
+ </hostdev>
+
+
+ virsh qemu-monitor-command <guest-name> --hmp \
+ "device_add vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>"
+
+ For example, to hot plug the vfio_ap mediated device
+ 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with
+ device-id hostdev0:
+
+ virsh qemu-monitor-command my-guest --hmp \
+ "device_add vfio-ap,\
+ sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\
+ id=hostdev0"
+
+2. A vfio_ap mediated device can be hot plugged by attaching the qemu monitor
+ to the guest and using the following qemu monitor command:
+
+ (qemu) device_add "vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>"
+
+ For example, to plug the vfio_ap mediated device
+ 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id
+ hostdev0:
+
+ (QEMU) device-add "vfio-ap,\
+ sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\
+ id=hostdev0"
diff --git a/Documentation/arch/s390/vfio-ccw.rst b/Documentation/arch/s390/vfio-ccw.rst
new file mode 100644
index 0000000..42960b7b
--- /dev/null
+++ b/Documentation/arch/s390/vfio-ccw.rst
@@ -0,0 +1,445 @@
+==================================
+vfio-ccw: the basic infrastructure
+==================================
+
+Introduction
+------------
+
+Here we describe the vfio support for I/O subchannel devices for
+Linux/s390. Motivation for vfio-ccw is to passthrough subchannels to a
+virtual machine, while vfio is the means.
+
+Different than other hardware architectures, s390 has defined a unified
+I/O access method, which is so called Channel I/O. It has its own access
+patterns:
+
+- Channel programs run asynchronously on a separate (co)processor.
+- The channel subsystem will access any memory designated by the caller
+ in the channel program directly, i.e. there is no iommu involved.
+
+Thus when we introduce vfio support for these devices, we realize it
+with a mediated device (mdev) implementation. The vfio mdev will be
+added to an iommu group, so as to make itself able to be managed by the
+vfio framework. And we add read/write callbacks for special vfio I/O
+regions to pass the channel programs from the mdev to its parent device
+(the real I/O subchannel device) to do further address translation and
+to perform I/O instructions.
+
+This document does not intend to explain the s390 I/O architecture in
+every detail. More information/reference could be found here:
+
+- A good start to know Channel I/O in general:
+ https://en.wikipedia.org/wiki/Channel_I/O
+- s390 architecture:
+ s390 Principles of Operation manual (IBM Form. No. SA22-7832)
+- The existing QEMU code which implements a simple emulated channel
+ subsystem could also be a good reference. It makes it easier to follow
+ the flow.
+ qemu/hw/s390x/css.c
+
+For vfio mediated device framework:
+- Documentation/driver-api/vfio-mediated-device.rst
+
+Motivation of vfio-ccw
+----------------------
+
+Typically, a guest virtualized via QEMU/KVM on s390 only sees
+paravirtualized virtio devices via the "Virtio Over Channel I/O
+(virtio-ccw)" transport. This makes virtio devices discoverable via
+standard operating system algorithms for handling channel devices.
+
+However this is not enough. On s390 for the majority of devices, which
+use the standard Channel I/O based mechanism, we also need to provide
+the functionality of passing through them to a QEMU virtual machine.
+This includes devices that don't have a virtio counterpart (e.g. tape
+drives) or that have specific characteristics which guests want to
+exploit.
+
+For passing a device to a guest, we want to use the same interface as
+everybody else, namely vfio. We implement this vfio support for channel
+devices via the vfio mediated device framework and the subchannel device
+driver "vfio_ccw".
+
+Access patterns of CCW devices
+------------------------------
+
+s390 architecture has implemented a so called channel subsystem, that
+provides a unified view of the devices physically attached to the
+systems. Though the s390 hardware platform knows about a huge variety of
+different peripheral attachments like disk devices (aka. DASDs), tapes,
+communication controllers, etc. They can all be accessed by a well
+defined access method and they are presenting I/O completion a unified
+way: I/O interruptions.
+
+All I/O requires the use of channel command words (CCWs). A CCW is an
+instruction to a specialized I/O channel processor. A channel program is
+a sequence of CCWs which are executed by the I/O channel subsystem. To
+issue a channel program to the channel subsystem, it is required to
+build an operation request block (ORB), which can be used to point out
+the format of the CCW and other control information to the system. The
+operating system signals the I/O channel subsystem to begin executing
+the channel program with a SSCH (start sub-channel) instruction. The
+central processor is then free to proceed with non-I/O instructions
+until interrupted. The I/O completion result is received by the
+interrupt handler in the form of interrupt response block (IRB).
+
+Back to vfio-ccw, in short:
+
+- ORBs and channel programs are built in guest kernel (with guest
+ physical addresses).
+- ORBs and channel programs are passed to the host kernel.
+- Host kernel translates the guest physical addresses to real addresses
+ and starts the I/O with issuing a privileged Channel I/O instruction
+ (e.g SSCH).
+- channel programs run asynchronously on a separate processor.
+- I/O completion will be signaled to the host with I/O interruptions.
+ And it will be copied as IRB to user space to pass it back to the
+ guest.
+
+Physical vfio ccw device and its child mdev
+-------------------------------------------
+
+As mentioned above, we realize vfio-ccw with a mdev implementation.
+
+Channel I/O does not have IOMMU hardware support, so the physical
+vfio-ccw device does not have an IOMMU level translation or isolation.
+
+Subchannel I/O instructions are all privileged instructions. When
+handling the I/O instruction interception, vfio-ccw has the software
+policing and translation how the channel program is programmed before
+it gets sent to hardware.
+
+Within this implementation, we have two drivers for two types of
+devices:
+
+- The vfio_ccw driver for the physical subchannel device.
+ This is an I/O subchannel driver for the real subchannel device. It
+ realizes a group of callbacks and registers to the mdev framework as a
+ parent (physical) device. As a consequence, mdev provides vfio_ccw a
+ generic interface (sysfs) to create mdev devices. A vfio mdev could be
+ created by vfio_ccw then and added to the mediated bus. It is the vfio
+ device that added to an IOMMU group and a vfio group.
+ vfio_ccw also provides an I/O region to accept channel program
+ request from user space and store I/O interrupt result for user
+ space to retrieve. To notify user space an I/O completion, it offers
+ an interface to setup an eventfd fd for asynchronous signaling.
+
+- The vfio_mdev driver for the mediated vfio ccw device.
+ This is provided by the mdev framework. It is a vfio device driver for
+ the mdev that created by vfio_ccw.
+ It realizes a group of vfio device driver callbacks, adds itself to a
+ vfio group, and registers itself to the mdev framework as a mdev
+ driver.
+ It uses a vfio iommu backend that uses the existing map and unmap
+ ioctls, but rather than programming them into an IOMMU for a device,
+ it simply stores the translations for use by later requests. This
+ means that a device programmed in a VM with guest physical addresses
+ can have the vfio kernel convert that address to process virtual
+ address, pin the page and program the hardware with the host physical
+ address in one step.
+ For a mdev, the vfio iommu backend will not pin the pages during the
+ VFIO_IOMMU_MAP_DMA ioctl. Mdev framework will only maintain a database
+ of the iova<->vaddr mappings in this operation. And they export a
+ vfio_pin_pages and a vfio_unpin_pages interfaces from the vfio iommu
+ backend for the physical devices to pin and unpin pages by demand.
+
+Below is a high Level block diagram::
+
+ +-------------+
+ | |
+ | +---------+ | mdev_register_driver() +--------------+
+ | | Mdev | +<-----------------------+ |
+ | | bus | | | vfio_mdev.ko |
+ | | driver | +----------------------->+ |<-> VFIO user
+ | +---------+ | probe()/remove() +--------------+ APIs
+ | |
+ | MDEV CORE |
+ | MODULE |
+ | mdev.ko |
+ | +---------+ | mdev_register_parent() +--------------+
+ | |Physical | +<-----------------------+ |
+ | | device | | | vfio_ccw.ko |<-> subchannel
+ | |interface| +----------------------->+ | device
+ | +---------+ | callback +--------------+
+ +-------------+
+
+The process of how these work together.
+
+1. vfio_ccw.ko drives the physical I/O subchannel, and registers the
+ physical device (with callbacks) to mdev framework.
+ When vfio_ccw probing the subchannel device, it registers device
+ pointer and callbacks to the mdev framework. Mdev related file nodes
+ under the device node in sysfs would be created for the subchannel
+ device, namely 'mdev_create', 'mdev_destroy' and
+ 'mdev_supported_types'.
+2. Create a mediated vfio ccw device.
+ Use the 'mdev_create' sysfs file, we need to manually create one (and
+ only one for our case) mediated device.
+3. vfio_mdev.ko drives the mediated ccw device.
+ vfio_mdev is also the vfio device driver. It will probe the mdev and
+ add it to an iommu_group and a vfio_group. Then we could pass through
+ the mdev to a guest.
+
+
+VFIO-CCW Regions
+----------------
+
+The vfio-ccw driver exposes MMIO regions to accept requests from and return
+results to userspace.
+
+vfio-ccw I/O region
+-------------------
+
+An I/O region is used to accept channel program request from user
+space and store I/O interrupt result for user space to retrieve. The
+definition of the region is::
+
+ struct ccw_io_region {
+ #define ORB_AREA_SIZE 12
+ __u8 orb_area[ORB_AREA_SIZE];
+ #define SCSW_AREA_SIZE 12
+ __u8 scsw_area[SCSW_AREA_SIZE];
+ #define IRB_AREA_SIZE 96
+ __u8 irb_area[IRB_AREA_SIZE];
+ __u32 ret_code;
+ } __packed;
+
+This region is always available.
+
+While starting an I/O request, orb_area should be filled with the
+guest ORB, and scsw_area should be filled with the SCSW of the Virtual
+Subchannel.
+
+irb_area stores the I/O result.
+
+ret_code stores a return code for each access of the region. The following
+values may occur:
+
+``0``
+ The operation was successful.
+
+``-EOPNOTSUPP``
+ The ORB specified transport mode or the
+ SCSW specified a function other than the start function.
+
+``-EIO``
+ A request was issued while the device was not in a state ready to accept
+ requests, or an internal error occurred.
+
+``-EBUSY``
+ The subchannel was status pending or busy, or a request is already active.
+
+``-EAGAIN``
+ A request was being processed, and the caller should retry.
+
+``-EACCES``
+ The channel path(s) used for the I/O were found to be not operational.
+
+``-ENODEV``
+ The device was found to be not operational.
+
+``-EINVAL``
+ The orb specified a chain longer than 255 ccws, or an internal error
+ occurred.
+
+
+vfio-ccw cmd region
+-------------------
+
+The vfio-ccw cmd region is used to accept asynchronous instructions
+from userspace::
+
+ #define VFIO_CCW_ASYNC_CMD_HSCH (1 << 0)
+ #define VFIO_CCW_ASYNC_CMD_CSCH (1 << 1)
+ struct ccw_cmd_region {
+ __u32 command;
+ __u32 ret_code;
+ } __packed;
+
+This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD.
+
+Currently, CLEAR SUBCHANNEL and HALT SUBCHANNEL use this region.
+
+command specifies the command to be issued; ret_code stores a return code
+for each access of the region. The following values may occur:
+
+``0``
+ The operation was successful.
+
+``-ENODEV``
+ The device was found to be not operational.
+
+``-EINVAL``
+ A command other than halt or clear was specified.
+
+``-EIO``
+ A request was issued while the device was not in a state ready to accept
+ requests.
+
+``-EAGAIN``
+ A request was being processed, and the caller should retry.
+
+``-EBUSY``
+ The subchannel was status pending or busy while processing a halt request.
+
+vfio-ccw schib region
+---------------------
+
+The vfio-ccw schib region is used to return Subchannel-Information
+Block (SCHIB) data to userspace::
+
+ struct ccw_schib_region {
+ #define SCHIB_AREA_SIZE 52
+ __u8 schib_area[SCHIB_AREA_SIZE];
+ } __packed;
+
+This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_SCHIB.
+
+Reading this region triggers a STORE SUBCHANNEL to be issued to the
+associated hardware.
+
+vfio-ccw crw region
+---------------------
+
+The vfio-ccw crw region is used to return Channel Report Word (CRW)
+data to userspace::
+
+ struct ccw_crw_region {
+ __u32 crw;
+ __u32 pad;
+ } __packed;
+
+This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_CRW.
+
+Reading this region returns a CRW if one that is relevant for this
+subchannel (e.g. one reporting changes in channel path state) is
+pending, or all zeroes if not. If multiple CRWs are pending (including
+possibly chained CRWs), reading this region again will return the next
+one, until no more CRWs are pending and zeroes are returned. This is
+similar to how STORE CHANNEL REPORT WORD works.
+
+vfio-ccw operation details
+--------------------------
+
+vfio-ccw follows what vfio-pci did on the s390 platform and uses
+vfio-iommu-type1 as the vfio iommu backend.
+
+* CCW translation APIs
+ A group of APIs (start with `cp_`) to do CCW translation. The CCWs
+ passed in by a user space program are organized with their guest
+ physical memory addresses. These APIs will copy the CCWs into kernel
+ space, and assemble a runnable kernel channel program by updating the
+ guest physical addresses with their corresponding host physical addresses.
+ Note that we have to use IDALs even for direct-access CCWs, as the
+ referenced memory can be located anywhere, including above 2G.
+
+* vfio_ccw device driver
+ This driver utilizes the CCW translation APIs and introduces
+ vfio_ccw, which is the driver for the I/O subchannel devices you want
+ to pass through.
+ vfio_ccw implements the following vfio ioctls::
+
+ VFIO_DEVICE_GET_INFO
+ VFIO_DEVICE_GET_IRQ_INFO
+ VFIO_DEVICE_GET_REGION_INFO
+ VFIO_DEVICE_RESET
+ VFIO_DEVICE_SET_IRQS
+
+ This provides an I/O region, so that the user space program can pass a
+ channel program to the kernel, to do further CCW translation before
+ issuing them to a real device.
+ This also provides the SET_IRQ ioctl to setup an event notifier to
+ notify the user space program the I/O completion in an asynchronous
+ way.
+
+The use of vfio-ccw is not limited to QEMU, while QEMU is definitely a
+good example to get understand how these patches work. Here is a little
+bit more detail how an I/O request triggered by the QEMU guest will be
+handled (without error handling).
+
+Explanation:
+
+- Q1-Q7: QEMU side process.
+- K1-K5: Kernel side process.
+
+Q1.
+ Get I/O region info during initialization.
+
+Q2.
+ Setup event notifier and handler to handle I/O completion.
+
+... ...
+
+Q3.
+ Intercept a ssch instruction.
+Q4.
+ Write the guest channel program and ORB to the I/O region.
+
+ K1.
+ Copy from guest to kernel.
+ K2.
+ Translate the guest channel program to a host kernel space
+ channel program, which becomes runnable for a real device.
+ K3.
+ With the necessary information contained in the orb passed in
+ by QEMU, issue the ccwchain to the device.
+ K4.
+ Return the ssch CC code.
+Q5.
+ Return the CC code to the guest.
+
+... ...
+
+ K5.
+ Interrupt handler gets the I/O result and write the result to
+ the I/O region.
+ K6.
+ Signal QEMU to retrieve the result.
+
+Q6.
+ Get the signal and event handler reads out the result from the I/O
+ region.
+Q7.
+ Update the irb for the guest.
+
+Limitations
+-----------
+
+The current vfio-ccw implementation focuses on supporting basic commands
+needed to implement block device functionality (read/write) of DASD/ECKD
+device only. Some commands may need special handling in the future, for
+example, anything related to path grouping.
+
+DASD is a kind of storage device. While ECKD is a data recording format.
+More information for DASD and ECKD could be found here:
+https://en.wikipedia.org/wiki/Direct-access_storage_device
+https://en.wikipedia.org/wiki/Count_key_data
+
+Together with the corresponding work in QEMU, we can bring the passed
+through DASD/ECKD device online in a guest now and use it as a block
+device.
+
+The current code allows the guest to start channel programs via
+START SUBCHANNEL, and to issue HALT SUBCHANNEL, CLEAR SUBCHANNEL,
+and STORE SUBCHANNEL.
+
+Currently all channel programs are prefetched, regardless of the
+p-bit setting in the ORB. As a result, self modifying channel
+programs are not supported. For this reason, IPL has to be handled as
+a special case by a userspace/guest program; this has been implemented
+in QEMU's s390-ccw bios as of QEMU 4.1.
+
+vfio-ccw supports classic (command mode) channel I/O only. Transport
+mode (HPF) is not supported.
+
+QDIO subchannels are currently not supported. Classic devices other than
+DASD/ECKD might work, but have not been tested.
+
+Reference
+---------
+1. ESA/s390 Principles of Operation manual (IBM Form. No. SA22-7832)
+2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204)
+3. https://en.wikipedia.org/wiki/Channel_I/O
+4. Documentation/arch/s390/cds.rst
+5. Documentation/driver-api/vfio.rst
+6. Documentation/driver-api/vfio-mediated-device.rst
diff --git a/Documentation/s390/zfcpdump.rst b/Documentation/arch/s390/zfcpdump.rst
similarity index 100%
rename from Documentation/s390/zfcpdump.rst
rename to Documentation/arch/s390/zfcpdump.rst
diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst
index 33520ec..f5d2f24 100644
--- a/Documentation/arch/x86/boot.rst
+++ b/Documentation/arch/x86/boot.rst
@@ -1105,7 +1105,7 @@
code, nor should it be located in high memory.
-Sample Boot Configuartion
+Sample Boot Configuration
=========================
As a sample configuration, assume the following layout of the real
@@ -1417,7 +1417,7 @@
The function prototype for the handover entry point looks like this::
- efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
+ efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp)
'handle' is the EFI image handle passed to the boot loader by the EFI
firmware, 'table' is the EFI system table - these are the first two
diff --git a/Documentation/arch/x86/buslock.rst b/Documentation/arch/x86/buslock.rst
index 31ec0ef..4c5a482 100644
--- a/Documentation/arch/x86/buslock.rst
+++ b/Documentation/arch/x86/buslock.rst
@@ -32,7 +32,7 @@
--------------------------------------
Beginning with the Tremont Atom CPU split lock operations may raise an
-Alignment Check (#AC) exception when a split lock operation is attemped.
+Alignment Check (#AC) exception when a split lock operation is attempted.
#DB exception for bus lock detection
------------------------------------
diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/index.rst
index c73d133..8ac64d7 100644
--- a/Documentation/arch/x86/index.rst
+++ b/Documentation/arch/x86/index.rst
@@ -22,6 +22,7 @@
mtrr
pat
intel-hfi
+ shstk
iommu
intel_txt
amd-memory-encryption
diff --git a/Documentation/arch/x86/mds.rst b/Documentation/arch/x86/mds.rst
index 5d4330b..e73fdff 100644
--- a/Documentation/arch/x86/mds.rst
+++ b/Documentation/arch/x86/mds.rst
@@ -60,7 +60,7 @@
data
The existence of such a construct in the kernel cannot be excluded with
-100% certainty, but the complexity involved makes it extremly unlikely.
+100% certainty, but the complexity involved makes it extremely unlikely.
There is one exception, which is untrusted BPF. The functionality of
untrusted BPF is limited, but it needs to be thoroughly investigated
diff --git a/Documentation/arch/x86/sgx.rst b/Documentation/arch/x86/sgx.rst
index 2bcbffa..d90796a 100644
--- a/Documentation/arch/x86/sgx.rst
+++ b/Documentation/arch/x86/sgx.rst
@@ -245,7 +245,7 @@
limited. However, while this may be fatal to SGX, the rest of the kernel
is unlikely to be impacted and should continue to work.
-As a result, when this happpens, user should stop running any new
+As a result, when this happens, user should stop running any new
SGX workloads, (or just any new workloads), and migrate all valuable
workloads. Although a machine reboot can recover all EPC memory, the bug
should be reported to Linux developers.
diff --git a/Documentation/arch/x86/shstk.rst b/Documentation/arch/x86/shstk.rst
new file mode 100644
index 0000000..60260e8
--- /dev/null
+++ b/Documentation/arch/x86/shstk.rst
@@ -0,0 +1,179 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================================
+Control-flow Enforcement Technology (CET) Shadow Stack
+======================================================
+
+CET Background
+==============
+
+Control-flow Enforcement Technology (CET) covers several related x86 processor
+features that provide protection against control flow hijacking attacks. CET
+can protect both applications and the kernel.
+
+CET introduces shadow stack and indirect branch tracking (IBT). A shadow stack
+is a secondary stack allocated from memory which cannot be directly modified by
+applications. When executing a CALL instruction, the processor pushes the
+return address to both the normal stack and the shadow stack. Upon
+function return, the processor pops the shadow stack copy and compares it
+to the normal stack copy. If the two differ, the processor raises a
+control-protection fault. IBT verifies indirect CALL/JMP targets are intended
+as marked by the compiler with 'ENDBR' opcodes. Not all CPU's have both Shadow
+Stack and Indirect Branch Tracking. Today in the 64-bit kernel, only userspace
+shadow stack and kernel IBT are supported.
+
+Requirements to use Shadow Stack
+================================
+
+To use userspace shadow stack you need HW that supports it, a kernel
+configured with it and userspace libraries compiled with it.
+
+The kernel Kconfig option is X86_USER_SHADOW_STACK. When compiled in, shadow
+stacks can be disabled at runtime with the kernel parameter: nousershstk.
+
+To build a user shadow stack enabled kernel, Binutils v2.29 or LLVM v6 or later
+are required.
+
+At run time, /proc/cpuinfo shows CET features if the processor supports
+CET. "user_shstk" means that userspace shadow stack is supported on the current
+kernel and HW.
+
+Application Enabling
+====================
+
+An application's CET capability is marked in its ELF note and can be verified
+from readelf/llvm-readelf output::
+
+ readelf -n <application> | grep -a SHSTK
+ properties: x86 feature: SHSTK
+
+The kernel does not process these applications markers directly. Applications
+or loaders must enable CET features using the interface described in section 4.
+Typically this would be done in dynamic loader or static runtime objects, as is
+the case in GLIBC.
+
+Enabling arch_prctl()'s
+=======================
+
+Elf features should be enabled by the loader using the below arch_prctl's. They
+are only supported in 64 bit user applications. These operate on the features
+on a per-thread basis. The enablement status is inherited on clone, so if the
+feature is enabled on the first thread, it will propagate to all the thread's
+in an app.
+
+arch_prctl(ARCH_SHSTK_ENABLE, unsigned long feature)
+ Enable a single feature specified in 'feature'. Can only operate on
+ one feature at a time.
+
+arch_prctl(ARCH_SHSTK_DISABLE, unsigned long feature)
+ Disable a single feature specified in 'feature'. Can only operate on
+ one feature at a time.
+
+arch_prctl(ARCH_SHSTK_LOCK, unsigned long features)
+ Lock in features at their current enabled or disabled status. 'features'
+ is a mask of all features to lock. All bits set are processed, unset bits
+ are ignored. The mask is ORed with the existing value. So any feature bits
+ set here cannot be enabled or disabled afterwards.
+
+arch_prctl(ARCH_SHSTK_UNLOCK, unsigned long features)
+ Unlock features. 'features' is a mask of all features to unlock. All
+ bits set are processed, unset bits are ignored. Only works via ptrace.
+
+arch_prctl(ARCH_SHSTK_STATUS, unsigned long addr)
+ Copy the currently enabled features to the address passed in addr. The
+ features are described using the bits passed into the others in
+ 'features'.
+
+The return values are as follows. On success, return 0. On error, errno can
+be::
+
+ -EPERM if any of the passed feature are locked.
+ -ENOTSUPP if the feature is not supported by the hardware or
+ kernel.
+ -EINVAL arguments (non existing feature, etc)
+ -EFAULT if could not copy information back to userspace
+
+The feature's bits supported are::
+
+ ARCH_SHSTK_SHSTK - Shadow stack
+ ARCH_SHSTK_WRSS - WRSS
+
+Currently shadow stack and WRSS are supported via this interface. WRSS
+can only be enabled with shadow stack, and is automatically disabled
+if shadow stack is disabled.
+
+Proc Status
+===========
+To check if an application is actually running with shadow stack, the
+user can read the /proc/$PID/status. It will report "wrss" or "shstk"
+depending on what is enabled. The lines look like this::
+
+ x86_Thread_features: shstk wrss
+ x86_Thread_features_locked: shstk wrss
+
+Implementation of the Shadow Stack
+==================================
+
+Shadow Stack Size
+-----------------
+
+A task's shadow stack is allocated from memory to a fixed size of
+MIN(RLIMIT_STACK, 4 GB). In other words, the shadow stack is allocated to
+the maximum size of the normal stack, but capped to 4 GB. In the case
+of the clone3 syscall, there is a stack size passed in and shadow stack
+uses this instead of the rlimit.
+
+Signal
+------
+
+The main program and its signal handlers use the same shadow stack. Because
+the shadow stack stores only return addresses, a large shadow stack covers
+the condition that both the program stack and the signal alternate stack run
+out.
+
+When a signal happens, the old pre-signal state is pushed on the stack. When
+shadow stack is enabled, the shadow stack specific state is pushed onto the
+shadow stack. Today this is only the old SSP (shadow stack pointer), pushed
+in a special format with bit 63 set. On sigreturn this old SSP token is
+verified and restored by the kernel. The kernel will also push the normal
+restorer address to the shadow stack to help userspace avoid a shadow stack
+violation on the sigreturn path that goes through the restorer.
+
+So the shadow stack signal frame format is as follows::
+
+ |1...old SSP| - Pointer to old pre-signal ssp in sigframe token format
+ (bit 63 set to 1)
+ | ...| - Other state may be added in the future
+
+
+32 bit ABI signals are not supported in shadow stack processes. Linux prevents
+32 bit execution while shadow stack is enabled by the allocating shadow stacks
+outside of the 32 bit address space. When execution enters 32 bit mode, either
+via far call or returning to userspace, a #GP is generated by the hardware
+which, will be delivered to the process as a segfault. When transitioning to
+userspace the register's state will be as if the userspace ip being returned to
+caused the segfault.
+
+Fork
+----
+
+The shadow stack's vma has VM_SHADOW_STACK flag set; its PTEs are required
+to be read-only and dirty. When a shadow stack PTE is not RO and dirty, a
+shadow access triggers a page fault with the shadow stack access bit set
+in the page fault error code.
+
+When a task forks a child, its shadow stack PTEs are copied and both the
+parent's and the child's shadow stack PTEs are cleared of the dirty bit.
+Upon the next shadow stack access, the resulting shadow stack page fault
+is handled by page copy/re-use.
+
+When a pthread child is created, the kernel allocates a new shadow stack
+for the new thread. New shadow stack creation behaves like mmap() with respect
+to ASLR behavior. Similarly, on thread exit the thread's shadow stack is
+disabled.
+
+Exec
+----
+
+On exec, shadow stack features are disabled by the kernel. At which point,
+userspace can choose to re-enable, or lock them.
diff --git a/Documentation/arch/xtensa/atomctl.rst b/Documentation/arch/xtensa/atomctl.rst
index 1ecbd0b..75d1741 100644
--- a/Documentation/arch/xtensa/atomctl.rst
+++ b/Documentation/arch/xtensa/atomctl.rst
@@ -23,7 +23,7 @@
operations.
For systems without an coherent cache controller, non-MX, we always
-use the memory controllers RCW, thought non-MX controlers likely
+use the memory controllers RCW, though non-MX controllers likely
support the Internal Operation.
CUSTOMER-WARNING:
diff --git a/Documentation/block/biovecs.rst b/Documentation/block/biovecs.rst
index ddb867e0..b9dc0c9 100644
--- a/Documentation/block/biovecs.rst
+++ b/Documentation/block/biovecs.rst
@@ -134,6 +134,7 @@
bio_for_each_bvec_all()
bio_first_bvec_all()
bio_first_page_all()
+ bio_first_folio_all()
bio_last_bvec_all()
* The following helpers iterate over single-page segment. The passed 'struct
diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst
index 07a97aa..6a760c0 100644
--- a/Documentation/block/data-integrity.rst
+++ b/Documentation/block/data-integrity.rst
@@ -209,7 +209,7 @@
sector must be set, and the bio should have all data pages
added. It is up to the caller to ensure that the bio does not
change while I/O is in progress.
- Complete bio with error if prepare failed for some reson.
+ Complete bio with error if prepare failed for some reason.
5.3 Passing Existing Integrity Metadata
diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst
index 1713b28..ff74b3e 100644
--- a/Documentation/block/ublk.rst
+++ b/Documentation/block/ublk.rst
@@ -238,7 +238,7 @@
request of ``/dev/ublkb*``.
UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
-the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for
+the driver. A fixed mmapped area (array) on ``/dev/ublkc*`` is provided for
exporting IO info to the server; such as IO offset, length, OP/flags and
buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id
and IO tag directly.
diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
index 38372a9..eb19c94 100644
--- a/Documentation/bpf/bpf_design_QA.rst
+++ b/Documentation/bpf/bpf_design_QA.rst
@@ -140,11 +140,6 @@
it more complicated to support on arm64 and other archs. Also it
needs div-by-zero runtime check.
-Q: Why there is no BPF_SDIV for signed divide operation?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A: Because it would be rarely used. llvm errors in such case and
-prints a suggestion to use unsigned divide instead.
-
Q: Why BPF has implicit prologue and epilogue?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A: Because architectures like sparc have register windows and in general
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
index 609b71f..de27e16 100644
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@ -635,12 +635,12 @@
Q: clang flag for target bpf?
-----------------------------
-Q: In some cases clang flag ``-target bpf`` is used but in other cases the
+Q: In some cases clang flag ``--target=bpf`` is used but in other cases the
default clang target, which matches the underlying architecture, is used.
What is the difference and when I should use which?
A: Although LLVM IR generation and optimization try to stay architecture
-independent, ``-target <arch>`` still has some impact on generated code:
+independent, ``--target=<arch>`` still has some impact on generated code:
- BPF program may recursively include header file(s) with file scope
inline assembly codes. The default target can handle this well,
@@ -658,7 +658,7 @@
The clang option ``-fno-jump-tables`` can be used to disable
switch table generation.
-- For clang ``-target bpf``, it is guaranteed that pointer or long /
+- For clang ``--target=bpf``, it is guaranteed that pointer or long /
unsigned long types will always have a width of 64 bit, no matter
whether underlying clang binary or default target (or kernel) is
32 bit. However, when native clang target is used, then it will
@@ -668,7 +668,7 @@
while the BPF LLVM back end still operates in 64 bit. The native
target is mostly needed in tracing for the case of walking ``pt_regs``
or other kernel structures where CPU's register width matters.
- Otherwise, ``clang -target bpf`` is generally recommended.
+ Otherwise, ``clang --target=bpf`` is generally recommended.
You should use default target when:
@@ -685,7 +685,7 @@
into these structures is verified by the BPF verifier and may result
in verification failures if the native architecture is not aligned with
the BPF architecture, e.g. 64-bit. An example of this is
- BPF_PROG_TYPE_SK_MSG require ``-target bpf``
+ BPF_PROG_TYPE_SK_MSG require ``--target=bpf``
.. Links
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index 7cd7c54..f32db1f 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -990,7 +990,7 @@
} g2;
int main() { return 0; }
int test() { return 0; }
- -bash-4.4$ clang -c -g -O2 -target bpf t2.c
+ -bash-4.4$ clang -c -g -O2 --target=bpf t2.c
-bash-4.4$ readelf -S t2.o
......
[ 8] .BTF PROGBITS 0000000000000000 00000247
@@ -1000,7 +1000,7 @@
[10] .rel.BTF.ext REL 0000000000000000 000007e0
0000000000000040 0000000000000010 16 9 8
......
- -bash-4.4$ clang -S -g -O2 -target bpf t2.c
+ -bash-4.4$ clang -S -g -O2 --target=bpf t2.c
-bash-4.4$ cat t2.s
......
.section .BTF,"",@progbits
diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst
index 3139c7c..a22b6ad 100644
--- a/Documentation/bpf/cpumasks.rst
+++ b/Documentation/bpf/cpumasks.rst
@@ -364,7 +364,7 @@
----
Some example usages of these querying kfuncs were shown above. We will not
-replicate those exmaples here. Note, however, that all of the aforementioned
+replicate those examples here. Note, however, that all of the aforementioned
kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so
please take a look there if you're looking for more examples of how they can be
used.
diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
index 6127462..06288cc 100644
--- a/Documentation/bpf/graph_ds_impl.rst
+++ b/Documentation/bpf/graph_ds_impl.rst
@@ -23,7 +23,7 @@
The BPF map API has historically been the main way to expose data structures
of various types for use within BPF programs. Some data structures fit naturally
-with the map API (HASH, ARRAY), others less so. Consequentially, programs
+with the map API (HASH, ARRAY), others less so. Consequently, programs
interacting with the latter group of data structures can be hard to parse
for kernel programmers without previous BPF experience.
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
index dbb39e8..1ff177b 100644
--- a/Documentation/bpf/index.rst
+++ b/Documentation/bpf/index.rst
@@ -12,9 +12,9 @@
.. toctree::
:maxdepth: 1
- instruction-set
verifier
libbpf/index
+ standardization/index
btf
faq
syscall_api
@@ -29,7 +29,6 @@
bpf_licensing
test_debug
clang-notes
- linux-notes
other
redirect
diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst
deleted file mode 100644
index 6644842..0000000
--- a/Documentation/bpf/instruction-set.rst
+++ /dev/null
@@ -1,478 +0,0 @@
-.. contents::
-.. sectnum::
-
-========================================
-eBPF Instruction Set Specification, v1.0
-========================================
-
-This document specifies version 1.0 of the eBPF instruction set.
-
-Documentation conventions
-=========================
-
-For brevity, this document uses the type notion "u64", "u32", etc.
-to mean an unsigned integer whose width is the specified number of bits,
-and "s32", etc. to mean a signed integer of the specified number of bits.
-
-Registers and calling convention
-================================
-
-eBPF has 10 general purpose registers and a read-only frame pointer register,
-all of which are 64-bits wide.
-
-The eBPF calling convention is defined as:
-
-* R0: return value from function calls, and exit value for eBPF programs
-* R1 - R5: arguments for function calls
-* R6 - R9: callee saved registers that function calls will preserve
-* R10: read-only frame pointer to access stack
-
-R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if
-necessary across calls.
-
-Instruction encoding
-====================
-
-eBPF has two instruction encodings:
-
-* the basic instruction encoding, which uses 64 bits to encode an instruction
-* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
- constant) value after the basic instruction for a total of 128 bits.
-
-The fields conforming an encoded basic instruction are stored in the
-following order::
-
- opcode:8 src_reg:4 dst_reg:4 offset:16 imm:32 // In little-endian BPF.
- opcode:8 dst_reg:4 src_reg:4 offset:16 imm:32 // In big-endian BPF.
-
-**imm**
- signed integer immediate value
-
-**offset**
- signed integer offset used with pointer arithmetic
-
-**src_reg**
- the source register number (0-10), except where otherwise specified
- (`64-bit immediate instructions`_ reuse this field for other purposes)
-
-**dst_reg**
- destination register number (0-10)
-
-**opcode**
- operation to perform
-
-Note that the contents of multi-byte fields ('imm' and 'offset') are
-stored using big-endian byte ordering in big-endian BPF and
-little-endian byte ordering in little-endian BPF.
-
-For example::
-
- opcode offset imm assembly
- src_reg dst_reg
- 07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little
- dst_reg src_reg
- 07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big
-
-Note that most instructions do not use all of the fields.
-Unused fields shall be cleared to zero.
-
-As discussed below in `64-bit immediate instructions`_, a 64-bit immediate
-instruction uses a 64-bit immediate value that is constructed as follows.
-The 64 bits following the basic instruction contain a pseudo instruction
-using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
-and imm containing the high 32 bits of the immediate value.
-
-This is depicted in the following figure::
-
- basic_instruction
- .-----------------------------.
- | |
- code:8 regs:8 offset:16 imm:32 unused:32 imm:32
- | |
- '--------------'
- pseudo instruction
-
-Thus the 64-bit immediate value is constructed as follows:
-
- imm64 = (next_imm << 32) | imm
-
-where 'next_imm' refers to the imm value of the pseudo instruction
-following the basic instruction. The unused bytes in the pseudo
-instruction are reserved and shall be cleared to zero.
-
-Instruction classes
--------------------
-
-The three LSB bits of the 'opcode' field store the instruction class:
-
-========= ===== =============================== ===================================
-class value description reference
-========= ===== =============================== ===================================
-BPF_LD 0x00 non-standard load operations `Load and store instructions`_
-BPF_LDX 0x01 load into register operations `Load and store instructions`_
-BPF_ST 0x02 store from immediate operations `Load and store instructions`_
-BPF_STX 0x03 store from register operations `Load and store instructions`_
-BPF_ALU 0x04 32-bit arithmetic operations `Arithmetic and jump instructions`_
-BPF_JMP 0x05 64-bit jump operations `Arithmetic and jump instructions`_
-BPF_JMP32 0x06 32-bit jump operations `Arithmetic and jump instructions`_
-BPF_ALU64 0x07 64-bit arithmetic operations `Arithmetic and jump instructions`_
-========= ===== =============================== ===================================
-
-Arithmetic and jump instructions
-================================
-
-For arithmetic and jump instructions (``BPF_ALU``, ``BPF_ALU64``, ``BPF_JMP`` and
-``BPF_JMP32``), the 8-bit 'opcode' field is divided into three parts:
-
-============== ====== =================
-4 bits (MSB) 1 bit 3 bits (LSB)
-============== ====== =================
-code source instruction class
-============== ====== =================
-
-**code**
- the operation code, whose meaning varies by instruction class
-
-**source**
- the source operand location, which unless otherwise specified is one of:
-
- ====== ===== ==============================================
- source value description
- ====== ===== ==============================================
- BPF_K 0x00 use 32-bit 'imm' value as source operand
- BPF_X 0x08 use 'src_reg' register value as source operand
- ====== ===== ==============================================
-
-**instruction class**
- the instruction class (see `Instruction classes`_)
-
-Arithmetic instructions
------------------------
-
-``BPF_ALU`` uses 32-bit wide operands while ``BPF_ALU64`` uses 64-bit wide operands for
-otherwise identical operations.
-The 'code' field encodes the operation as below, where 'src' and 'dst' refer
-to the values of the source and destination registers, respectively.
-
-======== ===== ==========================================================
-code value description
-======== ===== ==========================================================
-BPF_ADD 0x00 dst += src
-BPF_SUB 0x10 dst -= src
-BPF_MUL 0x20 dst \*= src
-BPF_DIV 0x30 dst = (src != 0) ? (dst / src) : 0
-BPF_OR 0x40 dst \|= src
-BPF_AND 0x50 dst &= src
-BPF_LSH 0x60 dst <<= (src & mask)
-BPF_RSH 0x70 dst >>= (src & mask)
-BPF_NEG 0x80 dst = ~src
-BPF_MOD 0x90 dst = (src != 0) ? (dst % src) : dst
-BPF_XOR 0xa0 dst ^= src
-BPF_MOV 0xb0 dst = src
-BPF_ARSH 0xc0 sign extending dst >>= (src & mask)
-BPF_END 0xd0 byte swap operations (see `Byte swap instructions`_ below)
-======== ===== ==========================================================
-
-Underflow and overflow are allowed during arithmetic operations, meaning
-the 64-bit or 32-bit value will wrap. If eBPF program execution would
-result in division by zero, the destination register is instead set to zero.
-If execution would result in modulo by zero, for ``BPF_ALU64`` the value of
-the destination register is unchanged whereas for ``BPF_ALU`` the upper
-32 bits of the destination register are zeroed.
-
-``BPF_ADD | BPF_X | BPF_ALU`` means::
-
- dst = (u32) ((u32) dst + (u32) src)
-
-where '(u32)' indicates that the upper 32 bits are zeroed.
-
-``BPF_ADD | BPF_X | BPF_ALU64`` means::
-
- dst = dst + src
-
-``BPF_XOR | BPF_K | BPF_ALU`` means::
-
- dst = (u32) dst ^ (u32) imm32
-
-``BPF_XOR | BPF_K | BPF_ALU64`` means::
-
- dst = dst ^ imm32
-
-Also note that the division and modulo operations are unsigned. Thus, for
-``BPF_ALU``, 'imm' is first interpreted as an unsigned 32-bit value, whereas
-for ``BPF_ALU64``, 'imm' is first sign extended to 64 bits and the result
-interpreted as an unsigned 64-bit value. There are no instructions for
-signed division or modulo.
-
-Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31)
-for 32-bit operations.
-
-Byte swap instructions
-~~~~~~~~~~~~~~~~~~~~~~
-
-The byte swap instructions use an instruction class of ``BPF_ALU`` and a 4-bit
-'code' field of ``BPF_END``.
-
-The byte swap instructions operate on the destination register
-only and do not use a separate source register or immediate value.
-
-The 1-bit source operand field in the opcode is used to select what byte
-order the operation convert from or to:
-
-========= ===== =================================================
-source value description
-========= ===== =================================================
-BPF_TO_LE 0x00 convert between host byte order and little endian
-BPF_TO_BE 0x08 convert between host byte order and big endian
-========= ===== =================================================
-
-The 'imm' field encodes the width of the swap operations. The following widths
-are supported: 16, 32 and 64.
-
-Examples:
-
-``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means::
-
- dst = htole16(dst)
-
-``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means::
-
- dst = htobe64(dst)
-
-Jump instructions
------------------
-
-``BPF_JMP32`` uses 32-bit wide operands while ``BPF_JMP`` uses 64-bit wide operands for
-otherwise identical operations.
-The 'code' field encodes the operation as below:
-
-======== ===== === =========================================== =========================================
-code value src description notes
-======== ===== === =========================================== =========================================
-BPF_JA 0x0 0x0 PC += offset BPF_JMP only
-BPF_JEQ 0x1 any PC += offset if dst == src
-BPF_JGT 0x2 any PC += offset if dst > src unsigned
-BPF_JGE 0x3 any PC += offset if dst >= src unsigned
-BPF_JSET 0x4 any PC += offset if dst & src
-BPF_JNE 0x5 any PC += offset if dst != src
-BPF_JSGT 0x6 any PC += offset if dst > src signed
-BPF_JSGE 0x7 any PC += offset if dst >= src signed
-BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_
-BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_
-BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_
-BPF_EXIT 0x9 0x0 return BPF_JMP only
-BPF_JLT 0xa any PC += offset if dst < src unsigned
-BPF_JLE 0xb any PC += offset if dst <= src unsigned
-BPF_JSLT 0xc any PC += offset if dst < src signed
-BPF_JSLE 0xd any PC += offset if dst <= src signed
-======== ===== === =========================================== =========================================
-
-The eBPF program needs to store the return value into register R0 before doing a
-``BPF_EXIT``.
-
-Example:
-
-``BPF_JSGE | BPF_X | BPF_JMP32`` (0x7e) means::
-
- if (s32)dst s>= (s32)src goto +offset
-
-where 's>=' indicates a signed '>=' comparison.
-
-Helper functions
-~~~~~~~~~~~~~~~~
-
-Helper functions are a concept whereby BPF programs can call into a
-set of function calls exposed by the underlying platform.
-
-Historically, each helper function was identified by an address
-encoded in the imm field. The available helper functions may differ
-for each program type, but address values are unique across all program types.
-
-Platforms that support the BPF Type Format (BTF) support identifying
-a helper function by a BTF ID encoded in the imm field, where the BTF ID
-identifies the helper name and type.
-
-Program-local functions
-~~~~~~~~~~~~~~~~~~~~~~~
-Program-local functions are functions exposed by the same BPF program as the
-caller, and are referenced by offset from the call instruction, similar to
-``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to
-the caller.
-
-Load and store instructions
-===========================
-
-For load and store instructions (``BPF_LD``, ``BPF_LDX``, ``BPF_ST``, and ``BPF_STX``), the
-8-bit 'opcode' field is divided as:
-
-============ ====== =================
-3 bits (MSB) 2 bits 3 bits (LSB)
-============ ====== =================
-mode size instruction class
-============ ====== =================
-
-The mode modifier is one of:
-
- ============= ===== ==================================== =============
- mode modifier value description reference
- ============= ===== ==================================== =============
- BPF_IMM 0x00 64-bit immediate instructions `64-bit immediate instructions`_
- BPF_ABS 0x20 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_
- BPF_IND 0x40 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_
- BPF_MEM 0x60 regular load and store operations `Regular load and store operations`_
- BPF_ATOMIC 0xc0 atomic operations `Atomic operations`_
- ============= ===== ==================================== =============
-
-The size modifier is one of:
-
- ============= ===== =====================
- size modifier value description
- ============= ===== =====================
- BPF_W 0x00 word (4 bytes)
- BPF_H 0x08 half word (2 bytes)
- BPF_B 0x10 byte
- BPF_DW 0x18 double word (8 bytes)
- ============= ===== =====================
-
-Regular load and store operations
----------------------------------
-
-The ``BPF_MEM`` mode modifier is used to encode regular load and store
-instructions that transfer data between a register and memory.
-
-``BPF_MEM | <size> | BPF_STX`` means::
-
- *(size *) (dst + offset) = src
-
-``BPF_MEM | <size> | BPF_ST`` means::
-
- *(size *) (dst + offset) = imm32
-
-``BPF_MEM | <size> | BPF_LDX`` means::
-
- dst = *(size *) (src + offset)
-
-Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``.
-
-Atomic operations
------------------
-
-Atomic operations are operations that operate on memory and can not be
-interrupted or corrupted by other access to the same memory region
-by other eBPF programs or means outside of this specification.
-
-All atomic operations supported by eBPF are encoded as store operations
-that use the ``BPF_ATOMIC`` mode modifier as follows:
-
-* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations
-* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations
-* 8-bit and 16-bit wide atomic operations are not supported.
-
-The 'imm' field is used to encode the actual atomic operation.
-Simple atomic operation use a subset of the values defined to encode
-arithmetic operations in the 'imm' field to encode the atomic operation:
-
-======== ===== ===========
-imm value description
-======== ===== ===========
-BPF_ADD 0x00 atomic add
-BPF_OR 0x40 atomic or
-BPF_AND 0x50 atomic and
-BPF_XOR 0xa0 atomic xor
-======== ===== ===========
-
-
-``BPF_ATOMIC | BPF_W | BPF_STX`` with 'imm' = BPF_ADD means::
-
- *(u32 *)(dst + offset) += src
-
-``BPF_ATOMIC | BPF_DW | BPF_STX`` with 'imm' = BPF ADD means::
-
- *(u64 *)(dst + offset) += src
-
-In addition to the simple atomic operations, there also is a modifier and
-two complex atomic operations:
-
-=========== ================ ===========================
-imm value description
-=========== ================ ===========================
-BPF_FETCH 0x01 modifier: return old value
-BPF_XCHG 0xe0 | BPF_FETCH atomic exchange
-BPF_CMPXCHG 0xf0 | BPF_FETCH atomic compare and exchange
-=========== ================ ===========================
-
-The ``BPF_FETCH`` modifier is optional for simple atomic operations, and
-always set for the complex atomic operations. If the ``BPF_FETCH`` flag
-is set, then the operation also overwrites ``src`` with the value that
-was in memory before it was modified.
-
-The ``BPF_XCHG`` operation atomically exchanges ``src`` with the value
-addressed by ``dst + offset``.
-
-The ``BPF_CMPXCHG`` operation atomically compares the value addressed by
-``dst + offset`` with ``R0``. If they match, the value addressed by
-``dst + offset`` is replaced with ``src``. In either case, the
-value that was at ``dst + offset`` before the operation is zero-extended
-and loaded back to ``R0``.
-
-64-bit immediate instructions
------------------------------
-
-Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
-encoding defined in `Instruction encoding`_, and use the 'src' field of the
-basic instruction to hold an opcode subtype.
-
-The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions
-with opcode subtypes in the 'src' field, using new terms such as "map"
-defined further below:
-
-========================= ====== === ========================================= =========== ==============
-opcode construction opcode src pseudocode imm type dst type
-========================= ====== === ========================================= =========== ==============
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
-========================= ====== === ========================================= =========== ==============
-
-where
-
-* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_)
-* map_by_idx(imm) means to convert a 32-bit index into an address of a map
-* map_val(map) gets the address of the first value in a given map
-* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id
-* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions
-* the 'imm type' can be used by disassemblers for display
-* the 'dst type' can be used for verification and JIT compilation purposes
-
-Maps
-~~~~
-
-Maps are shared memory regions accessible by eBPF programs on some platforms.
-A map can have various semantics as defined in a separate document, and may or
-may not have a single contiguous memory region, but the 'map_val(map)' is
-currently only defined for maps that do have a single contiguous memory region.
-
-Each map can have a file descriptor (fd) if supported by the platform, where
-'map_by_fd(imm)' means to get the map with the specified file descriptor. Each
-BPF program can also be defined to use a set of maps associated with the
-program at load time, and 'map_by_idx(imm)' means to get the map with the given
-index in the set associated with the BPF program containing the instruction.
-
-Platform Variables
-~~~~~~~~~~~~~~~~~~
-
-Platform variables are memory regions, identified by integer ids, exposed by
-the runtime and accessible by BPF programs on some platforms. The
-'var_addr(imm)' operation means to get the address of the memory region
-identified by the given id.
-
-Legacy BPF Packet access instructions
--------------------------------------
-
-eBPF previously introduced special instructions for access to packet data that were
-carried over from classic BPF. However, these instructions are
-deprecated and should no longer be used.
diff --git a/Documentation/bpf/linux-notes.rst b/Documentation/bpf/linux-notes.rst
deleted file mode 100644
index 508d009..0000000
--- a/Documentation/bpf/linux-notes.rst
+++ /dev/null
@@ -1,83 +0,0 @@
-.. contents::
-.. sectnum::
-
-==========================
-Linux implementation notes
-==========================
-
-This document provides more details specific to the Linux kernel implementation of the eBPF instruction set.
-
-Byte swap instructions
-======================
-
-``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
-
-Jump instructions
-=================
-
-``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function
-integer would be read from a specified register, is not currently supported
-by the verifier. Any programs with this instruction will fail to load
-until such support is added.
-
-Maps
-====
-
-Linux only supports the 'map_val(map)' operation on array maps with a single element.
-
-Linux uses an fd_array to store maps associated with a BPF program. Thus,
-map_by_idx(imm) uses the fd at that index in the array.
-
-Variables
-=========
-
-The following 64-bit immediate instruction specifies that a variable address,
-which corresponds to some integer stored in the 'imm' field, should be loaded:
-
-========================= ====== === ========================================= =========== ==============
-opcode construction opcode src pseudocode imm type dst type
-========================= ====== === ========================================= =========== ==============
-BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
-========================= ====== === ========================================= =========== ==============
-
-On Linux, this integer is a BTF ID.
-
-Legacy BPF Packet access instructions
-=====================================
-
-As mentioned in the `ISA standard documentation <instruction-set.rst#legacy-bpf-packet-access-instructions>`_,
-Linux has special eBPF instructions for access to packet data that have been
-carried over from classic BPF to retain the performance of legacy socket
-filters running in the eBPF interpreter.
-
-The instructions come in two forms: ``BPF_ABS | <size> | BPF_LD`` and
-``BPF_IND | <size> | BPF_LD``.
-
-These instructions are used to access packet data and can only be used when
-the program context is a pointer to a networking packet. ``BPF_ABS``
-accesses packet data at an absolute offset specified by the immediate data
-and ``BPF_IND`` access packet data at an offset that includes the value of
-a register in addition to the immediate data.
-
-These instructions have seven implicit operands:
-
-* Register R6 is an implicit input that must contain a pointer to a
- struct sk_buff.
-* Register R0 is an implicit output which contains the data fetched from
- the packet.
-* Registers R1-R5 are scratch registers that are clobbered by the
- instruction.
-
-These instructions have an implicit program exit condition as well. If an
-eBPF program attempts access data beyond the packet boundary, the
-program execution will be aborted.
-
-``BPF_ABS | BPF_W | BPF_LD`` (0x20) means::
-
- R0 = ntohl(*(u32 *) ((struct sk_buff *) R6->data + imm))
-
-where ``ntohl()`` converts a 32-bit value from network byte order to host byte order.
-
-``BPF_IND | BPF_W | BPF_LD`` (0x40) means::
-
- R0 = ntohl(*(u32 *) ((struct sk_buff *) R6->data + src + imm))
diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst
index e4a777a..450e640 100644
--- a/Documentation/bpf/llvm_reloc.rst
+++ b/Documentation/bpf/llvm_reloc.rst
@@ -28,7 +28,7 @@
return g1 + g2 + l1 + l2;
}
-Compiled with ``clang -target bpf -O2 -c test.c``, the following is
+Compiled with ``clang --target=bpf -O2 -c test.c``, the following is
the code with ``llvm-objdump -dr test.o``::
0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
@@ -157,7 +157,7 @@
return gfunc(a, b) + lfunc(a, b) + global;
}
-Compiled with ``clang -target bpf -O2 -c test.c``, we will have
+Compiled with ``clang --target=bpf -O2 -c test.c``, we will have
following code with `llvm-objdump -dr test.o``::
Disassembly of section .text:
@@ -203,7 +203,7 @@
int global() { return 0; }
struct t { void *g; } gbl = { global };
-Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a
+Compiled with ``clang --target=bpf -O2 -g -c test.c``, we will see a
relocation below in ``.data`` section with command
``llvm-readelf -r test.o``::
diff --git a/Documentation/bpf/standardization/index.rst b/Documentation/bpf/standardization/index.rst
new file mode 100644
index 0000000..09c6ba0
--- /dev/null
+++ b/Documentation/bpf/standardization/index.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
+
+===================
+BPF Standardization
+===================
+
+This directory contains documents that are being iterated on as part of the BPF
+standardization effort with the IETF. See the `IETF BPF Working Group`_ page
+for the working group charter, documents, and more.
+
+.. toctree::
+ :maxdepth: 1
+
+ instruction-set
+ linux-notes
+
+.. Links:
+.. _IETF BPF Working Group: https://datatracker.ietf.org/wg/bpf/about/
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
new file mode 100644
index 0000000..4f73e9d
--- /dev/null
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -0,0 +1,621 @@
+.. contents::
+.. sectnum::
+
+========================================
+eBPF Instruction Set Specification, v1.0
+========================================
+
+This document specifies version 1.0 of the eBPF instruction set.
+
+Documentation conventions
+=========================
+
+For brevity and consistency, this document refers to families
+of types using a shorthand syntax and refers to several expository,
+mnemonic functions when describing the semantics of instructions.
+The range of valid values for those types and the semantics of those
+functions are defined in the following subsections.
+
+Types
+-----
+This document refers to integer types with the notation `SN` to specify
+a type's signedness (`S`) and bit width (`N`), respectively.
+
+.. table:: Meaning of signedness notation.
+
+ ==== =========
+ `S` Meaning
+ ==== =========
+ `u` unsigned
+ `s` signed
+ ==== =========
+
+.. table:: Meaning of bit-width notation.
+
+ ===== =========
+ `N` Bit width
+ ===== =========
+ `8` 8 bits
+ `16` 16 bits
+ `32` 32 bits
+ `64` 64 bits
+ `128` 128 bits
+ ===== =========
+
+For example, `u32` is a type whose valid values are all the 32-bit unsigned
+numbers and `s16` is a types whose valid values are all the 16-bit signed
+numbers.
+
+Functions
+---------
+* `htobe16`: Takes an unsigned 16-bit number in host-endian format and
+ returns the equivalent number as an unsigned 16-bit number in big-endian
+ format.
+* `htobe32`: Takes an unsigned 32-bit number in host-endian format and
+ returns the equivalent number as an unsigned 32-bit number in big-endian
+ format.
+* `htobe64`: Takes an unsigned 64-bit number in host-endian format and
+ returns the equivalent number as an unsigned 64-bit number in big-endian
+ format.
+* `htole16`: Takes an unsigned 16-bit number in host-endian format and
+ returns the equivalent number as an unsigned 16-bit number in little-endian
+ format.
+* `htole32`: Takes an unsigned 32-bit number in host-endian format and
+ returns the equivalent number as an unsigned 32-bit number in little-endian
+ format.
+* `htole64`: Takes an unsigned 64-bit number in host-endian format and
+ returns the equivalent number as an unsigned 64-bit number in little-endian
+ format.
+* `bswap16`: Takes an unsigned 16-bit number in either big- or little-endian
+ format and returns the equivalent number with the same bit width but
+ opposite endianness.
+* `bswap32`: Takes an unsigned 32-bit number in either big- or little-endian
+ format and returns the equivalent number with the same bit width but
+ opposite endianness.
+* `bswap64`: Takes an unsigned 64-bit number in either big- or little-endian
+ format and returns the equivalent number with the same bit width but
+ opposite endianness.
+
+
+Definitions
+-----------
+
+.. glossary::
+
+ Sign Extend
+ To `sign extend an` ``X`` `-bit number, A, to a` ``Y`` `-bit number, B ,` means to
+
+ #. Copy all ``X`` bits from `A` to the lower ``X`` bits of `B`.
+ #. Set the value of the remaining ``Y`` - ``X`` bits of `B` to the value of
+ the most-significant bit of `A`.
+
+.. admonition:: Example
+
+ Sign extend an 8-bit number ``A`` to a 16-bit number ``B`` on a big-endian platform:
+ ::
+
+ A: 10000110
+ B: 11111111 10000110
+
+Registers and calling convention
+================================
+
+eBPF has 10 general purpose registers and a read-only frame pointer register,
+all of which are 64-bits wide.
+
+The eBPF calling convention is defined as:
+
+* R0: return value from function calls, and exit value for eBPF programs
+* R1 - R5: arguments for function calls
+* R6 - R9: callee saved registers that function calls will preserve
+* R10: read-only frame pointer to access stack
+
+R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if
+necessary across calls.
+
+Instruction encoding
+====================
+
+eBPF has two instruction encodings:
+
+* the basic instruction encoding, which uses 64 bits to encode an instruction
+* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
+ constant) value after the basic instruction for a total of 128 bits.
+
+The fields conforming an encoded basic instruction are stored in the
+following order::
+
+ opcode:8 src_reg:4 dst_reg:4 offset:16 imm:32 // In little-endian BPF.
+ opcode:8 dst_reg:4 src_reg:4 offset:16 imm:32 // In big-endian BPF.
+
+**imm**
+ signed integer immediate value
+
+**offset**
+ signed integer offset used with pointer arithmetic
+
+**src_reg**
+ the source register number (0-10), except where otherwise specified
+ (`64-bit immediate instructions`_ reuse this field for other purposes)
+
+**dst_reg**
+ destination register number (0-10)
+
+**opcode**
+ operation to perform
+
+Note that the contents of multi-byte fields ('imm' and 'offset') are
+stored using big-endian byte ordering in big-endian BPF and
+little-endian byte ordering in little-endian BPF.
+
+For example::
+
+ opcode offset imm assembly
+ src_reg dst_reg
+ 07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little
+ dst_reg src_reg
+ 07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big
+
+Note that most instructions do not use all of the fields.
+Unused fields shall be cleared to zero.
+
+As discussed below in `64-bit immediate instructions`_, a 64-bit immediate
+instruction uses a 64-bit immediate value that is constructed as follows.
+The 64 bits following the basic instruction contain a pseudo instruction
+using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
+and imm containing the high 32 bits of the immediate value.
+
+This is depicted in the following figure::
+
+ basic_instruction
+ .-----------------------------.
+ | |
+ code:8 regs:8 offset:16 imm:32 unused:32 imm:32
+ | |
+ '--------------'
+ pseudo instruction
+
+Thus the 64-bit immediate value is constructed as follows:
+
+ imm64 = (next_imm << 32) | imm
+
+where 'next_imm' refers to the imm value of the pseudo instruction
+following the basic instruction. The unused bytes in the pseudo
+instruction are reserved and shall be cleared to zero.
+
+Instruction classes
+-------------------
+
+The three LSB bits of the 'opcode' field store the instruction class:
+
+========= ===== =============================== ===================================
+class value description reference
+========= ===== =============================== ===================================
+BPF_LD 0x00 non-standard load operations `Load and store instructions`_
+BPF_LDX 0x01 load into register operations `Load and store instructions`_
+BPF_ST 0x02 store from immediate operations `Load and store instructions`_
+BPF_STX 0x03 store from register operations `Load and store instructions`_
+BPF_ALU 0x04 32-bit arithmetic operations `Arithmetic and jump instructions`_
+BPF_JMP 0x05 64-bit jump operations `Arithmetic and jump instructions`_
+BPF_JMP32 0x06 32-bit jump operations `Arithmetic and jump instructions`_
+BPF_ALU64 0x07 64-bit arithmetic operations `Arithmetic and jump instructions`_
+========= ===== =============================== ===================================
+
+Arithmetic and jump instructions
+================================
+
+For arithmetic and jump instructions (``BPF_ALU``, ``BPF_ALU64``, ``BPF_JMP`` and
+``BPF_JMP32``), the 8-bit 'opcode' field is divided into three parts:
+
+============== ====== =================
+4 bits (MSB) 1 bit 3 bits (LSB)
+============== ====== =================
+code source instruction class
+============== ====== =================
+
+**code**
+ the operation code, whose meaning varies by instruction class
+
+**source**
+ the source operand location, which unless otherwise specified is one of:
+
+ ====== ===== ==============================================
+ source value description
+ ====== ===== ==============================================
+ BPF_K 0x00 use 32-bit 'imm' value as source operand
+ BPF_X 0x08 use 'src_reg' register value as source operand
+ ====== ===== ==============================================
+
+**instruction class**
+ the instruction class (see `Instruction classes`_)
+
+Arithmetic instructions
+-----------------------
+
+``BPF_ALU`` uses 32-bit wide operands while ``BPF_ALU64`` uses 64-bit wide operands for
+otherwise identical operations.
+The 'code' field encodes the operation as below, where 'src' and 'dst' refer
+to the values of the source and destination registers, respectively.
+
+========= ===== ======= ==========================================================
+code value offset description
+========= ===== ======= ==========================================================
+BPF_ADD 0x00 0 dst += src
+BPF_SUB 0x10 0 dst -= src
+BPF_MUL 0x20 0 dst \*= src
+BPF_DIV 0x30 0 dst = (src != 0) ? (dst / src) : 0
+BPF_SDIV 0x30 1 dst = (src != 0) ? (dst s/ src) : 0
+BPF_OR 0x40 0 dst \|= src
+BPF_AND 0x50 0 dst &= src
+BPF_LSH 0x60 0 dst <<= (src & mask)
+BPF_RSH 0x70 0 dst >>= (src & mask)
+BPF_NEG 0x80 0 dst = -dst
+BPF_MOD 0x90 0 dst = (src != 0) ? (dst % src) : dst
+BPF_SMOD 0x90 1 dst = (src != 0) ? (dst s% src) : dst
+BPF_XOR 0xa0 0 dst ^= src
+BPF_MOV 0xb0 0 dst = src
+BPF_MOVSX 0xb0 8/16/32 dst = (s8,s16,s32)src
+BPF_ARSH 0xc0 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask)
+BPF_END 0xd0 0 byte swap operations (see `Byte swap instructions`_ below)
+========= ===== ======= ==========================================================
+
+Underflow and overflow are allowed during arithmetic operations, meaning
+the 64-bit or 32-bit value will wrap. If eBPF program execution would
+result in division by zero, the destination register is instead set to zero.
+If execution would result in modulo by zero, for ``BPF_ALU64`` the value of
+the destination register is unchanged whereas for ``BPF_ALU`` the upper
+32 bits of the destination register are zeroed.
+
+``BPF_ADD | BPF_X | BPF_ALU`` means::
+
+ dst = (u32) ((u32) dst + (u32) src)
+
+where '(u32)' indicates that the upper 32 bits are zeroed.
+
+``BPF_ADD | BPF_X | BPF_ALU64`` means::
+
+ dst = dst + src
+
+``BPF_XOR | BPF_K | BPF_ALU`` means::
+
+ dst = (u32) dst ^ (u32) imm32
+
+``BPF_XOR | BPF_K | BPF_ALU64`` means::
+
+ dst = dst ^ imm32
+
+Note that most instructions have instruction offset of 0. Only three instructions
+(``BPF_SDIV``, ``BPF_SMOD``, ``BPF_MOVSX``) have a non-zero offset.
+
+The division and modulo operations support both unsigned and signed flavors.
+
+For unsigned operations (``BPF_DIV`` and ``BPF_MOD``), for ``BPF_ALU``,
+'imm' is interpreted as a 32-bit unsigned value. For ``BPF_ALU64``,
+'imm' is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then
+interpreted as a 64-bit unsigned value.
+
+For signed operations (``BPF_SDIV`` and ``BPF_SMOD``), for ``BPF_ALU``,
+'imm' is interpreted as a 32-bit signed value. For ``BPF_ALU64``, 'imm'
+is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then
+interpreted as a 64-bit signed value.
+
+The ``BPF_MOVSX`` instruction does a move operation with sign extension.
+``BPF_ALU | BPF_MOVSX`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
+bit operands, and zeroes the remaining upper 32 bits.
+``BPF_ALU64 | BPF_MOVSX`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
+operands into 64 bit operands.
+
+Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31)
+for 32-bit operations.
+
+Byte swap instructions
+----------------------
+
+The byte swap instructions use instruction classes of ``BPF_ALU`` and ``BPF_ALU64``
+and a 4-bit 'code' field of ``BPF_END``.
+
+The byte swap instructions operate on the destination register
+only and do not use a separate source register or immediate value.
+
+For ``BPF_ALU``, the 1-bit source operand field in the opcode is used to
+select what byte order the operation converts from or to. For
+``BPF_ALU64``, the 1-bit source operand field in the opcode is reserved
+and must be set to 0.
+
+========= ========= ===== =================================================
+class source value description
+========= ========= ===== =================================================
+BPF_ALU BPF_TO_LE 0x00 convert between host byte order and little endian
+BPF_ALU BPF_TO_BE 0x08 convert between host byte order and big endian
+BPF_ALU64 Reserved 0x00 do byte swap unconditionally
+========= ========= ===== =================================================
+
+The 'imm' field encodes the width of the swap operations. The following widths
+are supported: 16, 32 and 64.
+
+Examples:
+
+``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16/32/64 means::
+
+ dst = htole16(dst)
+ dst = htole32(dst)
+ dst = htole64(dst)
+
+``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 16/32/64 means::
+
+ dst = htobe16(dst)
+ dst = htobe32(dst)
+ dst = htobe64(dst)
+
+``BPF_ALU64 | BPF_TO_LE | BPF_END`` with imm = 16/32/64 means::
+
+ dst = bswap16(dst)
+ dst = bswap32(dst)
+ dst = bswap64(dst)
+
+Jump instructions
+-----------------
+
+``BPF_JMP32`` uses 32-bit wide operands while ``BPF_JMP`` uses 64-bit wide operands for
+otherwise identical operations.
+The 'code' field encodes the operation as below:
+
+======== ===== === =========================================== =========================================
+code value src description notes
+======== ===== === =========================================== =========================================
+BPF_JA 0x0 0x0 PC += offset BPF_JMP class
+BPF_JA 0x0 0x0 PC += imm BPF_JMP32 class
+BPF_JEQ 0x1 any PC += offset if dst == src
+BPF_JGT 0x2 any PC += offset if dst > src unsigned
+BPF_JGE 0x3 any PC += offset if dst >= src unsigned
+BPF_JSET 0x4 any PC += offset if dst & src
+BPF_JNE 0x5 any PC += offset if dst != src
+BPF_JSGT 0x6 any PC += offset if dst > src signed
+BPF_JSGE 0x7 any PC += offset if dst >= src signed
+BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_
+BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_
+BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_
+BPF_EXIT 0x9 0x0 return BPF_JMP only
+BPF_JLT 0xa any PC += offset if dst < src unsigned
+BPF_JLE 0xb any PC += offset if dst <= src unsigned
+BPF_JSLT 0xc any PC += offset if dst < src signed
+BPF_JSLE 0xd any PC += offset if dst <= src signed
+======== ===== === =========================================== =========================================
+
+The eBPF program needs to store the return value into register R0 before doing a
+``BPF_EXIT``.
+
+Example:
+
+``BPF_JSGE | BPF_X | BPF_JMP32`` (0x7e) means::
+
+ if (s32)dst s>= (s32)src goto +offset
+
+where 's>=' indicates a signed '>=' comparison.
+
+``BPF_JA | BPF_K | BPF_JMP32`` (0x06) means::
+
+ gotol +imm
+
+where 'imm' means the branch offset comes from insn 'imm' field.
+
+Note that there are two flavors of ``BPF_JA`` instructions. The
+``BPF_JMP`` class permits a 16-bit jump offset specified by the 'offset'
+field, whereas the ``BPF_JMP32`` class permits a 32-bit jump offset
+specified by the 'imm' field. A > 16-bit conditional jump may be
+converted to a < 16-bit conditional jump plus a 32-bit unconditional
+jump.
+
+Helper functions
+~~~~~~~~~~~~~~~~
+
+Helper functions are a concept whereby BPF programs can call into a
+set of function calls exposed by the underlying platform.
+
+Historically, each helper function was identified by an address
+encoded in the imm field. The available helper functions may differ
+for each program type, but address values are unique across all program types.
+
+Platforms that support the BPF Type Format (BTF) support identifying
+a helper function by a BTF ID encoded in the imm field, where the BTF ID
+identifies the helper name and type.
+
+Program-local functions
+~~~~~~~~~~~~~~~~~~~~~~~
+Program-local functions are functions exposed by the same BPF program as the
+caller, and are referenced by offset from the call instruction, similar to
+``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to
+the caller.
+
+Load and store instructions
+===========================
+
+For load and store instructions (``BPF_LD``, ``BPF_LDX``, ``BPF_ST``, and ``BPF_STX``), the
+8-bit 'opcode' field is divided as:
+
+============ ====== =================
+3 bits (MSB) 2 bits 3 bits (LSB)
+============ ====== =================
+mode size instruction class
+============ ====== =================
+
+The mode modifier is one of:
+
+ ============= ===== ==================================== =============
+ mode modifier value description reference
+ ============= ===== ==================================== =============
+ BPF_IMM 0x00 64-bit immediate instructions `64-bit immediate instructions`_
+ BPF_ABS 0x20 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_
+ BPF_IND 0x40 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_
+ BPF_MEM 0x60 regular load and store operations `Regular load and store operations`_
+ BPF_MEMSX 0x80 sign-extension load operations `Sign-extension load operations`_
+ BPF_ATOMIC 0xc0 atomic operations `Atomic operations`_
+ ============= ===== ==================================== =============
+
+The size modifier is one of:
+
+ ============= ===== =====================
+ size modifier value description
+ ============= ===== =====================
+ BPF_W 0x00 word (4 bytes)
+ BPF_H 0x08 half word (2 bytes)
+ BPF_B 0x10 byte
+ BPF_DW 0x18 double word (8 bytes)
+ ============= ===== =====================
+
+Regular load and store operations
+---------------------------------
+
+The ``BPF_MEM`` mode modifier is used to encode regular load and store
+instructions that transfer data between a register and memory.
+
+``BPF_MEM | <size> | BPF_STX`` means::
+
+ *(size *) (dst + offset) = src
+
+``BPF_MEM | <size> | BPF_ST`` means::
+
+ *(size *) (dst + offset) = imm32
+
+``BPF_MEM | <size> | BPF_LDX`` means::
+
+ dst = *(unsigned size *) (src + offset)
+
+Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW`` and
+'unsigned size' is one of u8, u16, u32 or u64.
+
+Sign-extension load operations
+------------------------------
+
+The ``BPF_MEMSX`` mode modifier is used to encode :term:`sign-extension<Sign Extend>` load
+instructions that transfer data between a register and memory.
+
+``BPF_MEMSX | <size> | BPF_LDX`` means::
+
+ dst = *(signed size *) (src + offset)
+
+Where size is one of: ``BPF_B``, ``BPF_H`` or ``BPF_W``, and
+'signed size' is one of s8, s16 or s32.
+
+Atomic operations
+-----------------
+
+Atomic operations are operations that operate on memory and can not be
+interrupted or corrupted by other access to the same memory region
+by other eBPF programs or means outside of this specification.
+
+All atomic operations supported by eBPF are encoded as store operations
+that use the ``BPF_ATOMIC`` mode modifier as follows:
+
+* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations
+* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations
+* 8-bit and 16-bit wide atomic operations are not supported.
+
+The 'imm' field is used to encode the actual atomic operation.
+Simple atomic operation use a subset of the values defined to encode
+arithmetic operations in the 'imm' field to encode the atomic operation:
+
+======== ===== ===========
+imm value description
+======== ===== ===========
+BPF_ADD 0x00 atomic add
+BPF_OR 0x40 atomic or
+BPF_AND 0x50 atomic and
+BPF_XOR 0xa0 atomic xor
+======== ===== ===========
+
+
+``BPF_ATOMIC | BPF_W | BPF_STX`` with 'imm' = BPF_ADD means::
+
+ *(u32 *)(dst + offset) += src
+
+``BPF_ATOMIC | BPF_DW | BPF_STX`` with 'imm' = BPF ADD means::
+
+ *(u64 *)(dst + offset) += src
+
+In addition to the simple atomic operations, there also is a modifier and
+two complex atomic operations:
+
+=========== ================ ===========================
+imm value description
+=========== ================ ===========================
+BPF_FETCH 0x01 modifier: return old value
+BPF_XCHG 0xe0 | BPF_FETCH atomic exchange
+BPF_CMPXCHG 0xf0 | BPF_FETCH atomic compare and exchange
+=========== ================ ===========================
+
+The ``BPF_FETCH`` modifier is optional for simple atomic operations, and
+always set for the complex atomic operations. If the ``BPF_FETCH`` flag
+is set, then the operation also overwrites ``src`` with the value that
+was in memory before it was modified.
+
+The ``BPF_XCHG`` operation atomically exchanges ``src`` with the value
+addressed by ``dst + offset``.
+
+The ``BPF_CMPXCHG`` operation atomically compares the value addressed by
+``dst + offset`` with ``R0``. If they match, the value addressed by
+``dst + offset`` is replaced with ``src``. In either case, the
+value that was at ``dst + offset`` before the operation is zero-extended
+and loaded back to ``R0``.
+
+64-bit immediate instructions
+-----------------------------
+
+Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
+encoding defined in `Instruction encoding`_, and use the 'src' field of the
+basic instruction to hold an opcode subtype.
+
+The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions
+with opcode subtypes in the 'src' field, using new terms such as "map"
+defined further below:
+
+========================= ====== === ========================================= =========== ==============
+opcode construction opcode src pseudocode imm type dst type
+========================= ====== === ========================================= =========== ==============
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
+========================= ====== === ========================================= =========== ==============
+
+where
+
+* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_)
+* map_by_idx(imm) means to convert a 32-bit index into an address of a map
+* map_val(map) gets the address of the first value in a given map
+* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id
+* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions
+* the 'imm type' can be used by disassemblers for display
+* the 'dst type' can be used for verification and JIT compilation purposes
+
+Maps
+~~~~
+
+Maps are shared memory regions accessible by eBPF programs on some platforms.
+A map can have various semantics as defined in a separate document, and may or
+may not have a single contiguous memory region, but the 'map_val(map)' is
+currently only defined for maps that do have a single contiguous memory region.
+
+Each map can have a file descriptor (fd) if supported by the platform, where
+'map_by_fd(imm)' means to get the map with the specified file descriptor. Each
+BPF program can also be defined to use a set of maps associated with the
+program at load time, and 'map_by_idx(imm)' means to get the map with the given
+index in the set associated with the BPF program containing the instruction.
+
+Platform Variables
+~~~~~~~~~~~~~~~~~~
+
+Platform variables are memory regions, identified by integer ids, exposed by
+the runtime and accessible by BPF programs on some platforms. The
+'var_addr(imm)' operation means to get the address of the memory region
+identified by the given id.
+
+Legacy BPF Packet access instructions
+-------------------------------------
+
+eBPF previously introduced special instructions for access to packet data that were
+carried over from classic BPF. However, these instructions are
+deprecated and should no longer be used.
diff --git a/Documentation/bpf/standardization/linux-notes.rst b/Documentation/bpf/standardization/linux-notes.rst
new file mode 100644
index 0000000..00d2693
--- /dev/null
+++ b/Documentation/bpf/standardization/linux-notes.rst
@@ -0,0 +1,84 @@
+.. contents::
+.. sectnum::
+
+==========================
+Linux implementation notes
+==========================
+
+This document provides more details specific to the Linux kernel implementation of the eBPF instruction set.
+
+Byte swap instructions
+======================
+
+``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
+
+Jump instructions
+=================
+
+``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function
+integer would be read from a specified register, is not currently supported
+by the verifier. Any programs with this instruction will fail to load
+until such support is added.
+
+Maps
+====
+
+Linux only supports the 'map_val(map)' operation on array maps with a single element.
+
+Linux uses an fd_array to store maps associated with a BPF program. Thus,
+map_by_idx(imm) uses the fd at that index in the array.
+
+Variables
+=========
+
+The following 64-bit immediate instruction specifies that a variable address,
+which corresponds to some integer stored in the 'imm' field, should be loaded:
+
+========================= ====== === ========================================= =========== ==============
+opcode construction opcode src pseudocode imm type dst type
+========================= ====== === ========================================= =========== ==============
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
+========================= ====== === ========================================= =========== ==============
+
+On Linux, this integer is a BTF ID.
+
+Legacy BPF Packet access instructions
+=====================================
+
+As mentioned in the `ISA standard documentation
+<instruction-set.html#legacy-bpf-packet-access-instructions>`_,
+Linux has special eBPF instructions for access to packet data that have been
+carried over from classic BPF to retain the performance of legacy socket
+filters running in the eBPF interpreter.
+
+The instructions come in two forms: ``BPF_ABS | <size> | BPF_LD`` and
+``BPF_IND | <size> | BPF_LD``.
+
+These instructions are used to access packet data and can only be used when
+the program context is a pointer to a networking packet. ``BPF_ABS``
+accesses packet data at an absolute offset specified by the immediate data
+and ``BPF_IND`` access packet data at an offset that includes the value of
+a register in addition to the immediate data.
+
+These instructions have seven implicit operands:
+
+* Register R6 is an implicit input that must contain a pointer to a
+ struct sk_buff.
+* Register R0 is an implicit output which contains the data fetched from
+ the packet.
+* Registers R1-R5 are scratch registers that are clobbered by the
+ instruction.
+
+These instructions have an implicit program exit condition as well. If an
+eBPF program attempts access data beyond the packet boundary, the
+program execution will be aborted.
+
+``BPF_ABS | BPF_W | BPF_LD`` (0x20) means::
+
+ R0 = ntohl(*(u32 *) ((struct sk_buff *) R6->data + imm))
+
+where ``ntohl()`` converts a 32-bit value from network byte order to host byte order.
+
+``BPF_IND | BPF_W | BPF_LD`` (0x40) means::
+
+ R0 = ntohl(*(u32 *) ((struct sk_buff *) R6->data + src + imm))
diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst
index 5c0552e..889fc84 100644
--- a/Documentation/core-api/cachetlb.rst
+++ b/Documentation/core-api/cachetlb.rst
@@ -88,13 +88,17 @@
This is used primarily during fault processing.
-5) ``void update_mmu_cache(struct vm_area_struct *vma,
- unsigned long address, pte_t *ptep)``
+5) ``void update_mmu_cache_range(struct vm_fault *vmf,
+ struct vm_area_struct *vma, unsigned long address, pte_t *ptep,
+ unsigned int nr)``
- At the end of every page fault, this routine is invoked to
- tell the architecture specific code that a translation
- now exists at virtual address "address" for address space
- "vma->vm_mm", in the software page tables.
+ At the end of every page fault, this routine is invoked to tell
+ the architecture specific code that translations now exists
+ in the software page tables for address space "vma->vm_mm"
+ at virtual address "address" for "nr" consecutive pages.
+
+ This routine is also invoked in various other places which pass
+ a NULL "vmf".
A port may use this information in any way it so chooses.
For example, it could use this event to pre-load TLB
@@ -269,7 +273,7 @@
If D-cache aliasing is not an issue, these two routines may
simply call memcpy/memset directly and do nothing more.
- ``void flush_dcache_page(struct page *page)``
+ ``void flush_dcache_folio(struct folio *folio)``
This routines must be called when:
@@ -277,7 +281,7 @@
and / or in high memory
b) the kernel is about to read from a page cache page and user space
shared/writable mappings of this page potentially exist. Note
- that {get,pin}_user_pages{_fast} already call flush_dcache_page
+ that {get,pin}_user_pages{_fast} already call flush_dcache_folio
on any page found in the user address space and thus driver
code rarely needs to take this into account.
@@ -291,7 +295,7 @@
The phrase "kernel writes to a page cache page" means, specifically,
that the kernel executes store instructions that dirty data in that
- page at the page->virtual mapping of that page. It is important to
+ page at the kernel virtual mapping of that page. It is important to
flush here to handle D-cache aliasing, to make sure these kernel stores
are visible to user space mappings of that page.
@@ -302,21 +306,22 @@
If D-cache aliasing is not an issue, this routine may simply be defined
as a nop on that architecture.
- There is a bit set aside in page->flags (PG_arch_1) as "architecture
+ There is a bit set aside in folio->flags (PG_arch_1) as "architecture
private". The kernel guarantees that, for pagecache pages, it will
clear this bit when such a page first enters the pagecache.
- This allows these interfaces to be implemented much more efficiently.
- It allows one to "defer" (perhaps indefinitely) the actual flush if
- there are currently no user processes mapping this page. See sparc64's
- flush_dcache_page and update_mmu_cache implementations for an example
- of how to go about doing this.
+ This allows these interfaces to be implemented much more
+ efficiently. It allows one to "defer" (perhaps indefinitely) the
+ actual flush if there are currently no user processes mapping this
+ page. See sparc64's flush_dcache_folio and update_mmu_cache_range
+ implementations for an example of how to go about doing this.
- The idea is, first at flush_dcache_page() time, if page_file_mapping()
- returns a mapping, and mapping_mapped on that mapping returns %false,
- just mark the architecture private page flag bit. Later, in
- update_mmu_cache(), a check is made of this flag bit, and if set the
- flush is done and the flag bit is cleared.
+ The idea is, first at flush_dcache_folio() time, if
+ folio_flush_mapping() returns a mapping, and mapping_mapped() on that
+ mapping returns %false, just mark the architecture private page
+ flag bit. Later, in update_mmu_cache_range(), a check is made
+ of this flag bit, and if set the flush is done and the flag bit
+ is cleared.
.. important::
@@ -326,12 +331,6 @@
dirty. Again, see sparc64 for examples of how
to deal with this.
- ``void flush_dcache_folio(struct folio *folio)``
- This function is called under the same circumstances as
- flush_dcache_page(). It allows the architecture to
- optimise for flushing the entire folio of pages instead
- of flushing one page at a time.
-
``void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long user_vaddr, void *dst, void *src, int len)``
``void copy_from_user_page(struct vm_area_struct *vma, struct page *page,
@@ -352,7 +351,7 @@
When the kernel needs to access the contents of an anonymous
page, it calls this function (currently only
- get_user_pages()). Note: flush_dcache_page() deliberately
+ get_user_pages()). Note: flush_dcache_folio() deliberately
doesn't work for an anonymous page. The default
implementation is a nop (and should remain so for all coherent
architectures). For incoherent architectures, it should flush
@@ -369,7 +368,7 @@
``void flush_icache_page(struct vm_area_struct *vma, struct page *page)``
All the functionality of flush_icache_page can be implemented in
- flush_dcache_page and update_mmu_cache. In the future, the hope
+ flush_dcache_folio and update_mmu_cache_range. In the future, the hope
is to remove this interface completely.
The final category of APIs is for I/O to deliberately aliased address
diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
index e6f5bc3..9511e40 100644
--- a/Documentation/core-api/cpu_hotplug.rst
+++ b/Documentation/core-api/cpu_hotplug.rst
@@ -395,8 +395,8 @@
* cpuhp_setup_state_multi(state, name, startup, teardown)
The @state argument is either a statically allocated state or one of the
-constants for dynamically allocated states - CPUHP_PREPARE_DYN,
-CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
+constants for dynamically allocated states - CPUHP_BP_PREPARE_DYN,
+CPUHP_AP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
which a dynamic state should be allocated.
The @name argument is used for sysfs output and for instrumentation. The
@@ -588,7 +588,7 @@
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on offline operations::
- state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
+ state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
if (state < 0)
return state;
....
@@ -597,7 +597,7 @@
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on online operations without invoking the callbacks::
- state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
+ state = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
if (state < 0)
return state;
....
@@ -606,7 +606,7 @@
Setup, use and teardown a dynamically allocated multi-instance state in the
ONLINE section for notifications on online and offline operation::
- state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
+ state = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
if (state < 0)
return state;
....
@@ -741,6 +741,24 @@
can process the event further.
+When changes to the CPUs in the system occur, the sysfs file
+/sys/devices/system/cpu/crash_hotplug contains '1' if the kernel
+updates the kdump capture kernel list of CPUs itself (via elfcorehdr),
+or '0' if userspace must update the kdump capture kernel list of CPUs.
+
+The availability depends on the CONFIG_HOTPLUG_CPU kernel configuration
+option.
+
+To skip userspace processing of CPU hot un/plug events for kdump
+(i.e. the unload-then-reload to obtain a current list of CPUs), this sysfs
+file can be used in a udev rule as follows:
+
+ SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
+
+For a CPU hot un/plug event, if the architecture supports kernel updates
+of the elfcorehdr (which contains the list of CPUs), then the rule skips
+the unload-then-reload of the kdump capture kernel.
+
Kernel Inline Documentations Reference
======================================
diff --git a/Documentation/core-api/genericirq.rst b/Documentation/core-api/genericirq.rst
index f959c9b..4a46063 100644
--- a/Documentation/core-api/genericirq.rst
+++ b/Documentation/core-api/genericirq.rst
@@ -264,7 +264,7 @@
desc->irq_data.chip->irq_unmask();
desc->status &= ~pending;
handle_irq_event(desc->action);
- } while (status & pending);
+ } while (desc->status & pending);
desc->status &= ~running;
diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst
index f2bcc5a..ae92a25 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -162,8 +162,10 @@
.. kernel-doc:: include/linux/log2.h
:internal:
-Integer power Functions
------------------------
+Integer log and power Functions
+-------------------------------
+
+.. kernel-doc:: include/linux/int_log.h
.. kernel-doc:: lib/math/int_pow.c
:export:
diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst
index f5dde5b..2d091c8 100644
--- a/Documentation/core-api/mm-api.rst
+++ b/Documentation/core-api/mm-api.rst
@@ -115,3 +115,28 @@
.. kernel-doc:: include/linux/mmzone.h
.. kernel-doc:: mm/util.c
:functions: folio_mapping
+
+.. kernel-doc:: mm/rmap.c
+.. kernel-doc:: mm/migrate.c
+.. kernel-doc:: mm/mmap.c
+.. kernel-doc:: mm/kmemleak.c
+.. #kernel-doc:: mm/hmm.c (build warnings)
+.. kernel-doc:: mm/memremap.c
+.. kernel-doc:: mm/hugetlb.c
+.. kernel-doc:: mm/swap.c
+.. kernel-doc:: mm/zpool.c
+.. kernel-doc:: mm/memcontrol.c
+.. #kernel-doc:: mm/memory-tiers.c (build warnings)
+.. kernel-doc:: mm/shmem.c
+.. kernel-doc:: mm/migrate_device.c
+.. #kernel-doc:: mm/nommu.c (duplicates kernel-doc from other files)
+.. kernel-doc:: mm/mapping_dirty_helpers.c
+.. #kernel-doc:: mm/memory-failure.c (build warnings)
+.. kernel-doc:: mm/percpu.c
+.. kernel-doc:: mm/maccess.c
+.. kernel-doc:: mm/vmscan.c
+.. kernel-doc:: mm/memory_hotplug.c
+.. kernel-doc:: mm/mmu_notifier.c
+.. kernel-doc:: mm/balloon_compaction.c
+.. kernel-doc:: mm/huge_memory.c
+.. kernel-doc:: mm/io-mapping.c
diff --git a/Documentation/core-api/netlink.rst b/Documentation/core-api/netlink.rst
index e4a938a..9f692b0 100644
--- a/Documentation/core-api/netlink.rst
+++ b/Documentation/core-api/netlink.rst
@@ -67,10 +67,11 @@
kernel-policy
~~~~~~~~~~~~~
-Defines if the kernel validation policy is per operation (``per-op``)
-or for the entire family (``global``). New families should use ``per-op``
-(default) to be able to narrow down the attributes accepted by a specific
-command.
+Defines whether the kernel validation policy is ``global`` i.e. the same for all
+operations of the family, defined for each operation individually - ``per-op``,
+or separately for each operation and operation type (do vs dump) - ``split``.
+New families should use ``per-op`` (default) to be able to narrow down the
+attributes accepted by a specific command.
checks
------
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index dfe7e75a..4451ef5 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -15,9 +15,10 @@
If variable is of Type, use printk format specifier:
------------------------------------------------------------
- char %d or %x
+ signed char %d or %hhx
unsigned char %u or %x
- short int %d or %x
+ char %u or %x
+ short int %d or %hx
unsigned short int %u or %x
int %d or %x
unsigned int %u or %x
@@ -27,9 +28,9 @@
unsigned long long %llu or %llx
size_t %zu or %zx
ssize_t %zd or %zx
- s8 %d or %x
+ s8 %d or %hhx
u8 %u or %x
- s16 %d or %x
+ s16 %d or %hx
u16 %u or %x
s32 %d or %x
u32 %u or %x
diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst
index a4c9b9d..5d7b01a 100644
--- a/Documentation/core-api/workqueue.rst
+++ b/Documentation/core-api/workqueue.rst
@@ -1,6 +1,6 @@
-====================================
-Concurrency Managed Workqueue (cmwq)
-====================================
+=========
+Workqueue
+=========
:Date: September, 2010
:Author: Tejun Heo <tj@kernel.org>
@@ -25,8 +25,8 @@
When a new work item gets queued, the worker begins executing again.
-Why cmwq?
-=========
+Why Concurrency Managed Workqueue?
+==================================
In the original wq implementation, a multi threaded (MT) wq had one
worker thread per CPU and a single threaded (ST) wq had one worker
@@ -220,17 +220,16 @@
``max_active``
--------------
-``@max_active`` determines the maximum number of execution contexts
-per CPU which can be assigned to the work items of a wq. For example,
-with ``@max_active`` of 16, at most 16 work items of the wq can be
-executing at the same time per CPU.
+``@max_active`` determines the maximum number of execution contexts per
+CPU which can be assigned to the work items of a wq. For example, with
+``@max_active`` of 16, at most 16 work items of the wq can be executing
+at the same time per CPU. This is always a per-CPU attribute, even for
+unbound workqueues.
-Currently, for a bound wq, the maximum limit for ``@max_active`` is
-512 and the default value used when 0 is specified is 256. For an
-unbound wq, the limit is higher of 512 and 4 *
-``num_possible_cpus()``. These values are chosen sufficiently high
-such that they are not the limiting factor while providing protection
-in runaway cases.
+The maximum limit for ``@max_active`` is 512 and the default value used
+when 0 is specified is 256. These values are chosen sufficiently high
+such that they are not the limiting factor while providing protection in
+runaway cases.
The number of active work items of a wq is usually regulated by the
users of the wq, more specifically, by how many work items the users
@@ -348,27 +347,346 @@
level of locality in wq operations and work item execution.
+Affinity Scopes
+===============
+
+An unbound workqueue groups CPUs according to its affinity scope to improve
+cache locality. For example, if a workqueue is using the default affinity
+scope of "cache", it will group CPUs according to last level cache
+boundaries. A work item queued on the workqueue will be assigned to a worker
+on one of the CPUs which share the last level cache with the issuing CPU.
+Once started, the worker may or may not be allowed to move outside the scope
+depending on the ``affinity_strict`` setting of the scope.
+
+Workqueue currently supports the following affinity scopes.
+
+``default``
+ Use the scope in module parameter ``workqueue.default_affinity_scope``
+ which is always set to one of the scopes below.
+
+``cpu``
+ CPUs are not grouped. A work item issued on one CPU is processed by a
+ worker on the same CPU. This makes unbound workqueues behave as per-cpu
+ workqueues without concurrency management.
+
+``smt``
+ CPUs are grouped according to SMT boundaries. This usually means that the
+ logical threads of each physical CPU core are grouped together.
+
+``cache``
+ CPUs are grouped according to cache boundaries. Which specific cache
+ boundary is used is determined by the arch code. L3 is used in a lot of
+ cases. This is the default affinity scope.
+
+``numa``
+ CPUs are grouped according to NUMA bounaries.
+
+``system``
+ All CPUs are put in the same group. Workqueue makes no effort to process a
+ work item on a CPU close to the issuing CPU.
+
+The default affinity scope can be changed with the module parameter
+``workqueue.default_affinity_scope`` and a specific workqueue's affinity
+scope can be changed using ``apply_workqueue_attrs()``.
+
+If ``WQ_SYSFS`` is set, the workqueue will have the following affinity scope
+related interface files under its ``/sys/devices/virtual/WQ_NAME/``
+directory.
+
+``affinity_scope``
+ Read to see the current affinity scope. Write to change.
+
+ When default is the current scope, reading this file will also show the
+ current effective scope in parentheses, for example, ``default (cache)``.
+
+``affinity_strict``
+ 0 by default indicating that affinity scopes are not strict. When a work
+ item starts execution, workqueue makes a best-effort attempt to ensure
+ that the worker is inside its affinity scope, which is called
+ repatriation. Once started, the scheduler is free to move the worker
+ anywhere in the system as it sees fit. This enables benefiting from scope
+ locality while still being able to utilize other CPUs if necessary and
+ available.
+
+ If set to 1, all workers of the scope are guaranteed always to be in the
+ scope. This may be useful when crossing affinity scopes has other
+ implications, for example, in terms of power consumption or workload
+ isolation. Strict NUMA scope can also be used to match the workqueue
+ behavior of older kernels.
+
+
+Affinity Scopes and Performance
+===============================
+
+It'd be ideal if an unbound workqueue's behavior is optimal for vast
+majority of use cases without further tuning. Unfortunately, in the current
+kernel, there exists a pronounced trade-off between locality and utilization
+necessitating explicit configurations when workqueues are heavily used.
+
+Higher locality leads to higher efficiency where more work is performed for
+the same number of consumed CPU cycles. However, higher locality may also
+cause lower overall system utilization if the work items are not spread
+enough across the affinity scopes by the issuers. The following performance
+testing with dm-crypt clearly illustrates this trade-off.
+
+The tests are run on a CPU with 12-cores/24-threads split across four L3
+caches (AMD Ryzen 9 3900x). CPU clock boost is turned off for consistency.
+``/dev/dm-0`` is a dm-crypt device created on NVME SSD (Samsung 990 PRO) and
+opened with ``cryptsetup`` with default settings.
+
+
+Scenario 1: Enough issuers and work spread across the machine
+-------------------------------------------------------------
+
+The command used: ::
+
+ $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k --ioengine=libaio \
+ --iodepth=64 --runtime=60 --numjobs=24 --time_based --group_reporting \
+ --name=iops-test-job --verify=sha512
+
+There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512``
+makes ``fio`` generate and read back the content each time which makes
+execution locality matter between the issuer and ``kcryptd``. The followings
+are the read bandwidths and CPU utilizations depending on different affinity
+scope settings on ``kcryptd`` measured over five runs. Bandwidths are in
+MiBps, and CPU util in percents.
+
+.. list-table::
+ :widths: 16 20 20
+ :header-rows: 1
+
+ * - Affinity
+ - Bandwidth (MiBps)
+ - CPU util (%)
+
+ * - system
+ - 1159.40 ±1.34
+ - 99.31 ±0.02
+
+ * - cache
+ - 1166.40 ±0.89
+ - 99.34 ±0.01
+
+ * - cache (strict)
+ - 1166.00 ±0.71
+ - 99.35 ±0.01
+
+With enough issuers spread across the system, there is no downside to
+"cache", strict or otherwise. All three configurations saturate the whole
+machine but the cache-affine ones outperform by 0.6% thanks to improved
+locality.
+
+
+Scenario 2: Fewer issuers, enough work for saturation
+-----------------------------------------------------
+
+The command used: ::
+
+ $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
+ --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=8 \
+ --time_based --group_reporting --name=iops-test-job --verify=sha512
+
+The only difference from the previous scenario is ``--numjobs=8``. There are
+a third of the issuers but is still enough total work to saturate the
+system.
+
+.. list-table::
+ :widths: 16 20 20
+ :header-rows: 1
+
+ * - Affinity
+ - Bandwidth (MiBps)
+ - CPU util (%)
+
+ * - system
+ - 1155.40 ±0.89
+ - 97.41 ±0.05
+
+ * - cache
+ - 1154.40 ±1.14
+ - 96.15 ±0.09
+
+ * - cache (strict)
+ - 1112.00 ±4.64
+ - 93.26 ±0.35
+
+This is more than enough work to saturate the system. Both "system" and
+"cache" are nearly saturating the machine but not fully. "cache" is using
+less CPU but the better efficiency puts it at the same bandwidth as
+"system".
+
+Eight issuers moving around over four L3 cache scope still allow "cache
+(strict)" to mostly saturate the machine but the loss of work conservation
+is now starting to hurt with 3.7% bandwidth loss.
+
+
+Scenario 3: Even fewer issuers, not enough work to saturate
+-----------------------------------------------------------
+
+The command used: ::
+
+ $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
+ --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=4 \
+ --time_based --group_reporting --name=iops-test-job --verify=sha512
+
+Again, the only difference is ``--numjobs=4``. With the number of issuers
+reduced to four, there now isn't enough work to saturate the whole system
+and the bandwidth becomes dependent on completion latencies.
+
+.. list-table::
+ :widths: 16 20 20
+ :header-rows: 1
+
+ * - Affinity
+ - Bandwidth (MiBps)
+ - CPU util (%)
+
+ * - system
+ - 993.60 ±1.82
+ - 75.49 ±0.06
+
+ * - cache
+ - 973.40 ±1.52
+ - 74.90 ±0.07
+
+ * - cache (strict)
+ - 828.20 ±4.49
+ - 66.84 ±0.29
+
+Now, the tradeoff between locality and utilization is clearer. "cache" shows
+2% bandwidth loss compared to "system" and "cache (struct)" whopping 20%.
+
+
+Conclusion and Recommendations
+------------------------------
+
+In the above experiments, the efficiency advantage of the "cache" affinity
+scope over "system" is, while consistent and noticeable, small. However, the
+impact is dependent on the distances between the scopes and may be more
+pronounced in processors with more complex topologies.
+
+While the loss of work-conservation in certain scenarios hurts, it is a lot
+better than "cache (strict)" and maximizing workqueue utilization is
+unlikely to be the common case anyway. As such, "cache" is the default
+affinity scope for unbound pools.
+
+* As there is no one option which is great for most cases, workqueue usages
+ that may consume a significant amount of CPU are recommended to configure
+ the workqueues using ``apply_workqueue_attrs()`` and/or enable
+ ``WQ_SYSFS``.
+
+* An unbound workqueue with strict "cpu" affinity scope behaves the same as
+ ``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the
+ latter and an unbound workqueue provides a lot more flexibility.
+
+* Affinity scopes are introduced in Linux v6.5. To emulate the previous
+ behavior, use strict "numa" affinity scope.
+
+* The loss of work-conservation in non-strict affinity scopes is likely
+ originating from the scheduler. There is no theoretical reason why the
+ kernel wouldn't be able to do the right thing and maintain
+ work-conservation in most cases. As such, it is possible that future
+ scheduler improvements may make most of these tunables unnecessary.
+
+
+Examining Configuration
+=======================
+
+Use tools/workqueue/wq_dump.py to examine unbound CPU affinity
+configuration, worker pools and how workqueues map to the pools: ::
+
+ $ tools/workqueue/wq_dump.py
+ Affinity Scopes
+ ===============
+ wq_unbound_cpumask=0000000f
+
+ CPU
+ nr_pods 4
+ pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
+ pod_node [0]=0 [1]=0 [2]=1 [3]=1
+ cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
+
+ SMT
+ nr_pods 4
+ pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
+ pod_node [0]=0 [1]=0 [2]=1 [3]=1
+ cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
+
+ CACHE (default)
+ nr_pods 2
+ pod_cpus [0]=00000003 [1]=0000000c
+ pod_node [0]=0 [1]=1
+ cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
+
+ NUMA
+ nr_pods 2
+ pod_cpus [0]=00000003 [1]=0000000c
+ pod_node [0]=0 [1]=1
+ cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
+
+ SYSTEM
+ nr_pods 1
+ pod_cpus [0]=0000000f
+ pod_node [0]=-1
+ cpu_pod [0]=0 [1]=0 [2]=0 [3]=0
+
+ Worker Pools
+ ============
+ pool[00] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 0
+ pool[01] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 0
+ pool[02] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 1
+ pool[03] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 1
+ pool[04] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 2
+ pool[05] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 2
+ pool[06] ref= 1 nice= 0 idle/workers= 3/ 3 cpu= 3
+ pool[07] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 3
+ pool[08] ref=42 nice= 0 idle/workers= 6/ 6 cpus=0000000f
+ pool[09] ref=28 nice= 0 idle/workers= 3/ 3 cpus=00000003
+ pool[10] ref=28 nice= 0 idle/workers= 17/ 17 cpus=0000000c
+ pool[11] ref= 1 nice=-20 idle/workers= 1/ 1 cpus=0000000f
+ pool[12] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=00000003
+ pool[13] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=0000000c
+
+ Workqueue CPU -> pool
+ =====================
+ [ workqueue \ CPU 0 1 2 3 dfl]
+ events percpu 0 2 4 6
+ events_highpri percpu 1 3 5 7
+ events_long percpu 0 2 4 6
+ events_unbound unbound 9 9 10 10 8
+ events_freezable percpu 0 2 4 6
+ events_power_efficient percpu 0 2 4 6
+ events_freezable_power_ percpu 0 2 4 6
+ rcu_gp percpu 0 2 4 6
+ rcu_par_gp percpu 0 2 4 6
+ slub_flushwq percpu 0 2 4 6
+ netns ordered 8 8 8 8 8
+ ...
+
+See the command's help message for more info.
+
+
Monitoring
==========
Use tools/workqueue/wq_monitor.py to monitor workqueue operations: ::
$ tools/workqueue/wq_monitor.py events
- total infl CPUtime CPUhog CMwake mayday rescued
+ total infl CPUtime CPUhog CMW/RPR mayday rescued
events 18545 0 6.1 0 5 - -
events_highpri 8 0 0.0 0 0 - -
events_long 3 0 0.0 0 0 - -
- events_unbound 38306 0 0.1 - - - -
+ events_unbound 38306 0 0.1 - 7 - -
events_freezable 0 0 0.0 0 0 - -
events_power_efficient 29598 0 0.2 0 0 - -
events_freezable_power_ 10 0 0.0 0 0 - -
sock_diag_events 0 0 0.0 0 0 - -
- total infl CPUtime CPUhog CMwake mayday rescued
+ total infl CPUtime CPUhog CMW/RPR mayday rescued
events 18548 0 6.1 0 5 - -
events_highpri 8 0 0.0 0 0 - -
events_long 3 0 0.0 0 0 - -
- events_unbound 38322 0 0.1 - - - -
+ events_unbound 38322 0 0.1 - 7 - -
events_freezable 0 0 0.0 0 0 - -
events_power_efficient 29603 0 0.2 0 0 - -
events_freezable_power_ 10 0 0.0 0 0 - -
diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst
index dafe8eb..19ddf5e 100644
--- a/Documentation/dev-tools/kunit/run_wrapper.rst
+++ b/Documentation/dev-tools/kunit/run_wrapper.rst
@@ -321,3 +321,15 @@
- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or
saves to a file if a filename is specified.
+
+- ``--filter``: Specifies filters on test attributes, for example, ``speed!=slow``.
+ Multiple filters can be used by wrapping input in quotes and separating filters
+ by commas. Example: ``--filter "speed>slow, module=example"``.
+
+- ``--filter_action``: If set to ``skip``, filtered tests will be shown as skipped
+ in the output rather than showing no output.
+
+- ``--list_tests``: If set, lists all tests that will be run.
+
+- ``--list_tests_attr``: If set, lists all tests that will be run and all of their
+ attributes.
diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst
index 8e8c493..766f9cd 100644
--- a/Documentation/dev-tools/kunit/running_tips.rst
+++ b/Documentation/dev-tools/kunit/running_tips.rst
@@ -262,3 +262,169 @@
# Reset coverage counters before running the test.
$ echo 0 > /sys/kernel/debug/gcov/reset
$ modprobe kunit-example-test
+
+
+Test Attributes and Filtering
+=============================
+
+Test suites and cases can be marked with test attributes, such as speed of
+test. These attributes will later be printed in test output and can be used to
+filter test execution.
+
+Marking Test Attributes
+-----------------------
+
+Tests are marked with an attribute by including a ``kunit_attributes`` object
+in the test definition.
+
+Test cases can be marked using the ``KUNIT_CASE_ATTR(test_name, attributes)``
+macro to define the test case instead of ``KUNIT_CASE(test_name)``.
+
+.. code-block:: c
+
+ static const struct kunit_attributes example_attr = {
+ .speed = KUNIT_VERY_SLOW,
+ };
+
+ static struct kunit_case example_test_cases[] = {
+ KUNIT_CASE_ATTR(example_test, example_attr),
+ };
+
+.. note::
+ To mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``.
+ This is a helpful macro as the slow attribute is the most commonly used.
+
+Test suites can be marked with an attribute by setting the "attr" field in the
+suite definition.
+
+.. code-block:: c
+
+ static const struct kunit_attributes example_attr = {
+ .speed = KUNIT_VERY_SLOW,
+ };
+
+ static struct kunit_suite example_test_suite = {
+ ...,
+ .attr = example_attr,
+ };
+
+.. note::
+ Not all attributes need to be set in a ``kunit_attributes`` object. Unset
+ attributes will remain uninitialized and act as though the attribute is set
+ to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset.
+ These unset attributes will not be reported and may act as a default value
+ for filtering purposes.
+
+Reporting Attributes
+--------------------
+
+When a user runs tests, attributes will be present in the raw kernel output (in
+KTAP format). Note that attributes will be hidden by default in kunit.py output
+for all passing tests but the raw kernel output can be accessed using the
+``--raw_output`` flag. This is an example of how test attributes for test cases
+will be formatted in kernel output:
+
+.. code-block:: none
+
+ # example_test.speed: slow
+ ok 1 example_test
+
+This is an example of how test attributes for test suites will be formatted in
+kernel output:
+
+.. code-block:: none
+
+ KTAP version 2
+ # Subtest: example_suite
+ # module: kunit_example_test
+ 1..3
+ ...
+ ok 1 example_suite
+
+Additionally, users can output a full attribute report of tests with their
+attributes, using the command line flag ``--list_tests_attr``:
+
+.. code-block:: bash
+
+ kunit.py run "example" --list_tests_attr
+
+.. note::
+ This report can be accessed when running KUnit manually by passing in the
+ module_param ``kunit.action=list_attr``.
+
+Filtering
+---------
+
+Users can filter tests using the ``--filter`` command line flag when running
+tests. As an example:
+
+.. code-block:: bash
+
+ kunit.py run --filter speed=slow
+
+
+You can also use the following operations on filters: "<", ">", "<=", ">=",
+"!=", and "=". Example:
+
+.. code-block:: bash
+
+ kunit.py run --filter "speed>slow"
+
+This example will run all tests with speeds faster than slow. Note that the
+characters < and > are often interpreted by the shell, so they may need to be
+quoted or escaped, as above.
+
+Additionally, you can use multiple filters at once. Simply separate filters
+using commas. Example:
+
+.. code-block:: bash
+
+ kunit.py run --filter "speed>slow, module=kunit_example_test"
+
+.. note::
+ You can use this filtering feature when running KUnit manually by passing
+ the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``.
+
+Filtered tests will not run or show up in the test output. You can use the
+``--filter_action=skip`` flag to skip filtered tests instead. These tests will be
+shown in the test output in the test but will not run. To use this feature when
+running KUnit manually, use the module param ``kunit.filter_action=skip``.
+
+Rules of Filtering Procedure
+----------------------------
+
+Since both suites and test cases can have attributes, there may be conflicts
+between attributes during filtering. The process of filtering follows these
+rules:
+
+- Filtering always operates at a per-test level.
+
+- If a test has an attribute set, then the test's value is filtered on.
+
+- Otherwise, the value falls back to the suite's value.
+
+- If neither are set, the attribute has a global "default" value, which is used.
+
+List of Current Attributes
+--------------------------
+
+``speed``
+
+This attribute indicates the speed of a test's execution (how slow or fast the
+test is).
+
+This attribute is saved as an enum with the following categories: "normal",
+"slow", or "very_slow". The assumed default speed for tests is "normal". This
+indicates that the test takes a relatively trivial amount of time (less than
+1 second), regardless of the machine it is running on. Any test slower than
+this could be marked as "slow" or "very_slow".
+
+The macro ``KUNIT_CASE_SLOW(test_name)`` can be easily used to set the speed
+of a test case to "slow".
+
+``module``
+
+This attribute indicates the name of the module associated with the test.
+
+This attribute is automatically saved as a string and is printed for each suite.
+Tests can also be filtered using this attribute.
diff --git a/Documentation/devicetree/bindings/.yamllint b/Documentation/devicetree/bindings/.yamllint
index 4abe9f0..fea5231 100644
--- a/Documentation/devicetree/bindings/.yamllint
+++ b/Documentation/devicetree/bindings/.yamllint
@@ -1,6 +1,11 @@
extends: relaxed
rules:
+ quoted-strings:
+ required: only-when-needed
+ extra-allowed:
+ - '[$^,[]'
+ - '^/$'
line-length:
# 80 chars should be enough, but don't fail if a line is longer
max: 110
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 08d5984..1c1094c 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -218,6 +218,14 @@
- amlogic,aq222
- const: amlogic,s4
+ - description: Boards with the Amlogic T7 A311D2 SoC
+ items:
+ - enum:
+ - amlogic,an400
+ - khadas,vim4
+ - const: amlogic,a311d2
+ - const: amlogic,t7
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
index d6c84b6..6216cfb 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
index cb78cfa..c960c8e 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-sink.yaml#
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
index 5fedaed..6745b4c 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-source.yaml#
diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml
index 1084606..f725e69 100644
--- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml
@@ -1,9 +1,9 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Embedded Trace Extensions
diff --git a/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml
index b1322658..87128e7 100644
--- a/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml
@@ -1,9 +1,9 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Trace Buffer Extensions
@@ -19,7 +19,8 @@
properties:
$nodename:
- const: "trbe"
+ const: trbe
+
compatible:
items:
- const: arm,trace-buffer-extension
diff --git a/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml
index 491eef1..3b060c3 100644
--- a/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,versatile-sysreg.yaml#
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
index cdd6588..8dd6b64 100644
--- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
@@ -143,7 +143,7 @@
"simple-bus". If the compatible is placed in the "motherboard-bus" node,
it is stricter and always has two compatibles.
type: object
- $ref: '/schemas/simple-bus.yaml'
+ $ref: /schemas/simple-bus.yaml
unevaluatedProperties: false
properties:
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml
index c72aab7..b8c5cac 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml
@@ -2,8 +2,8 @@
# Copyright 2021 Joel Stanley, IBM Corp.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ASPEED Secure Boot Controller
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index e0eff4c..68f7176 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/aspeed/aspeed.yaml#
@@ -79,9 +79,11 @@
- facebook,elbert-bmc
- facebook,fuji-bmc
- facebook,greatlakes-bmc
+ - facebook,yosemite4-bmc
- ibm,everest-bmc
- ibm,rainier-bmc
- ibm,tacoma-bmc
+ - inventec,starscream-bmc
- inventec,transformer-bmc
- jabil,rbp-bmc
- qcom,dc-scm-v1-bmc
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
index 5c3ac97e..4cc4e67 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
@@ -66,6 +66,7 @@
- description: BCM47094 based boards
items:
- enum:
+ - asus,rt-ac3100
- asus,rt-ac88u
- dlink,dir-885l
- dlink,dir-890l
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml
new file mode 100644
index 0000000..81b9a4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm53573.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM53573 SoCs family
+
+description:
+ Broadcom BCM53573 / BCM47189 Wi-Fi SoCs derived from Northstar.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: BCM53573 based boards
+ items:
+ - enum:
+ - tenda,ac6-v1
+ - tenda,w15e-v1
+ - const: brcm,bcm53573
+
+ - description: BCM47189 based boards
+ items:
+ - enum:
+ - brcm,bcm947189acdbmr
+ - luxul,xap-810-v1
+ - luxul,xap-1440-v1
+ - tenda,ac9
+ - const: brcm,bcm47189
+ - const: brcm,bcm53573
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 9e6a45e..0d17cba 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -143,8 +143,10 @@
- arm,cortex-a78ae
- arm,cortex-a78c
- arm,cortex-a510
+ - arm,cortex-a520
- arm,cortex-a710
- arm,cortex-a715
+ - arm,cortex-a720
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
@@ -158,6 +160,7 @@
- arm,cortex-x1c
- arm,cortex-x2
- arm,cortex-x3
+ - arm,cortex-x4
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
index 9d1857c..e3980b65 100644
--- a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
+++ b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Trusted Foundations
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 2510eaa..9450b2c 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -909,6 +909,7 @@
- fsl,imx8mm-evk # i.MX8MM EVK Board
- fsl,imx8mm-evkb # i.MX8MM EVKB Board
- gateworks,imx8mm-gw7904
+ - gateworks,imx8mm-gw7905-0x # i.MX8MM Gateworks Board
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
- gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit
- gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit
@@ -1031,10 +1032,11 @@
- beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
- fsl,imx8mp-evk # i.MX8MP EVK Board
+ - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
+ - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
+ - gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
- gateworks,imx8mp-gw7905-2x # i.MX8MP Gateworks Board
- - polyhex,imx8mp-debix # Polyhex Debix boards
- - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board
- toradex,verdin-imx8mp # Verdin iMX8M Plus Modules
- toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Modules without Wi-Fi / BT
- toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
@@ -1068,6 +1070,20 @@
- const: phytec,imx8mp-phycore-som # phyCORE-i.MX8MP SoM
- const: fsl,imx8mp
+ - description: Polyhex DEBIX i.MX8MP based SBCs
+ items:
+ - enum:
+ - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board
+ - const: polyhex,imx8mp-debix # Polyhex i.MX8MP Debix SBCs
+ - const: fsl,imx8mp
+
+ - description: Polyhex DEBIX i.MX8MP SOM A based boards
+ items:
+ - enum:
+ - polyhex,imx8mp-debix-som-a-bmb-08 # Polyhex Debix SOM A on SOM A I/O board
+ - const: polyhex,imx8mp-debix-som-a # Polyhex Debix SOM A
+ - const: fsl,imx8mp
+
- description: Toradex Boards with Verdin iMX8M Plus Modules
items:
- enum:
@@ -1220,11 +1236,30 @@
- const: fsl,imxrt1170
- description:
+ TQMa93xxLA and TQMa93xxCA are two series of feature compatible SOM
+ using NXP i.MX93 SOC in 11x11 mm package.
+ TQMa93xxLA is designed to be soldered on different carrier boards.
+ TQMa93xxCA is a compatible variant using board to board connectors.
+ All SOM and CPU variants use the same device tree hence only one
+ compatible is needed. Bootloader disables all features not present
+ in the assembled SOC.
+ MBa93xxCA mainboard can be used as starterkit for the SOM
+ soldered on an adapter board or for the connector variant
+ MBa93xxLA mainboard is a single board computer using the solderable
+ SOM variant
+ items:
+ - enum:
+ - tq,imx93-tqma9352-mba93xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa93xxCA
+ - tq,imx93-tqma9352-mba93xxla # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA SBC
+ - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
+ - const: fsl,imx93
+
+ - description:
Freescale Vybrid Platform Device Tree Bindings
- For the Vybrid SoC familiy all variants with DDR controller are supported,
+ For the Vybrid SoC family all variants with DDR controller are supported,
which is the VF5xx and VF6xx series. Out of historical reasons, in most
- places the kernel uses vf610 to refer to the whole familiy.
+ places the kernel uses vf610 to refer to the whole family.
The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4
core support.
items:
@@ -1289,6 +1324,16 @@
- fsl,ls1021a-twr
- const: fsl,ls1021a
+ - description:
+ TQ-Systems TQMLS102xA is a series of socketable SOM featuring
+ LS102x system-on-chip variants. MBLS102xA mainboard can be used as
+ starterkit.
+ items:
+ - enum:
+ - tq,ls1021a-tqmls1021a-mbls102xa
+ - const: tq,ls1021a-tqmls1021a
+ - const: fsl,ls1021a
+
- description: LS1028A based Boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml b/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml
index 528dad4..4fc208d 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml
+++ b/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml
@@ -29,6 +29,26 @@
ranges: true
+patternProperties:
+ "^clock@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: hisilicon,hix5hd2-clock
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ required:
+ - compatible
+ - reg
+ - "#clock-cells"
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml
index 4b4dcf5..2ee0c74 100644
--- a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml
+++ b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml
@@ -21,6 +21,11 @@
- intel,socfpga-agilex-n6000
- intel,socfpga-agilex-socdk
- const: intel,socfpga-agilex
+ - description: Agilex5 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex5-socdk
+ - const: intel,socfpga-agilex5
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml
index ff378d5..4a323e8 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml#
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
index 86b59de..c24ad09 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
index d84105c..9d5d70c 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
@@ -21,13 +21,13 @@
number of clocks:
- a set of core clocks
- - a set of gatable clocks
+ - a set of gateable clocks
Those clocks can be referenced by other Device Tree nodes using two
cells:
- The first cell must be 0 or 1. 0 for the core clocks and 1 for the
- gatable clocks.
- - The second cell identifies the particular core clock or gatable
+ gateable clocks.
+ - The second cell identifies the particular core clock or gateable
clocks.
The following clocks are available:
@@ -38,7 +38,7 @@
- 0 3 Core
- 0 4 NAND core
- 0 5 SDIO core
- - Gatable clocks
+ - Gateable clocks
- 1 0 Audio
- 1 1 Comm Unit
- 1 2 NAND
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
index 8be5978..1c67194 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
@@ -16,7 +16,7 @@
The mipi0a controller also uses the common power domain from
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
-The available power doamins are defined in dt-bindings/power/mt*-power.h.
+The available power domains are defined in dt-bindings/power/mt*-power.h.
Example:
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
index c877bcc..f090147 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
@@ -15,7 +15,7 @@
The vcodecsys controller also uses the common power domain from
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
-The available power doamins are defined in dt-bindings/power/mt*-power.h.
+The available power domains are defined in dt-bindings/power/mt*-power.h.
Example:
diff --git a/Documentation/devicetree/bindings/arm/msm/ssbi.txt b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
deleted file mode 100644
index 54fd5ce..0000000
--- a/Documentation/devicetree/bindings/arm/msm/ssbi.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Qualcomm SSBI
-
-Some Qualcomm MSM devices contain a point-to-point serial bus used to
-communicate with a limited range of devices (mostly power management
-chips).
-
-These require the following properties:
-
-- compatible: "qcom,ssbi"
-
-- qcom,controller-type
- indicates the SSBI bus variant the controller should use to talk
- with the slave device. This should be one of "ssbi", "ssbi2", or
- "pmic-arbiter". The type chosen is determined by the attached
- slave.
-
-The slave device should be the single child node of the ssbi device
-with a compatible field.
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml
index 6816bd6..a8ac4a2 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 thingy.jp.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MStar/SigmaStar Armv7 SoC l3bridge
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
index 599c659..5739848 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
@@ -2,8 +2,8 @@
# 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#"
+$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
diff --git a/Documentation/devicetree/bindings/arm/omap/ctrl.txt b/Documentation/devicetree/bindings/arm/omap/ctrl.txt
index f35b779..0ce6665 100644
--- a/Documentation/devicetree/bindings/arm/omap/ctrl.txt
+++ b/Documentation/devicetree/bindings/arm/omap/ctrl.txt
@@ -8,7 +8,7 @@
See [2] for documentation about clock/clockdomain nodes.
-[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
[2] Documentation/devicetree/bindings/clock/ti/*
Required properties:
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index fa8b316..c863ec0 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -41,14 +41,6 @@
SoC Families:
-- OMAP2 generic - defaults to OMAP2420
- compatible = "ti,omap2"
-- OMAP3 generic
- compatible = "ti,omap3"
-- OMAP4 generic - defaults to OMAP4430
- compatible = "ti,omap4"
-- OMAP5 generic - defaults to OMAP5430
- compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
- AM33x generic
@@ -58,32 +50,6 @@
SoCs:
-- OMAP2420
- compatible = "ti,omap2420", "ti,omap2"
-- OMAP2430
- compatible = "ti,omap2430", "ti,omap2"
-
-- OMAP3430
- compatible = "ti,omap3430", "ti,omap3"
- legacy: "ti,omap34xx" - please do not use any more
-- AM3517
- compatible = "ti,am3517", "ti,omap3"
-- OMAP3630
- compatible = "ti,omap3630", "ti,omap3"
- legacy: "ti,omap36xx" - please do not use any more
-- AM335x
- compatible = "ti,am33xx"
-
-- OMAP4430
- compatible = "ti,omap4430", "ti,omap4"
-- OMAP4460
- compatible = "ti,omap4460", "ti,omap4"
-
-- OMAP5430
- compatible = "ti,omap5430", "ti,omap5"
-- OMAP5432
- compatible = "ti,omap5432", "ti,omap5"
-
- DRA762
compatible = "ti,dra762", "ti,dra7"
@@ -116,65 +82,6 @@
Boards (incomplete list of examples):
-- OMAP3 BeagleBoard : Low cost community board
- compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
-
-- OMAP3 BeagleBoard A to B4 : Early BeagleBoard revisions A to B4 with a timer quirk
- compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
-
-- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
- compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
-
-- OMAP4 SDP : Software Development Board
- compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4"
-
-- OMAP4 PandaBoard : Low cost community board
- compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4"
-
-- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
- compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
-
-- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN
- compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
-
-- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard, VAR-SOM-OM44 w/WLAN and LCD touchscreen
- compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
-
-- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
- compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3"
-
-- AM335X EVM : Software Development Board for AM335x
- compatible = "ti,am335x-evm", "ti,am33xx"
-
-- AM335X Bone : Low cost community board
- compatible = "ti,am335x-bone", "ti,am33xx"
-
-- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM.
- compatible = "ti,am3359-icev2", "ti,am33xx"
-
-- AM335X OrionLXm : Substation Automation Platform
- compatible = "novatech,am335x-lxm", "ti,am33xx"
-
-- AM335X phyBOARD-WEGA: Single Board Computer dev kit
- compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
-
-- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
- compatible = "compulab,cm-t335", "ti,am33xx"
-
-- AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4
- compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx"
-
-- AM335X phyCORE-AM335x: Development kit
- compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx"
-
-- AM335x phyBOARD-REGOR: Single Board Computer
- compatible = "phytec,am335x-regor", "phytec,am335x-phycore-som", "ti,am33xx"
-
-- AM335X UC-8100-ME-T: Communication-centric industrial computing platform
- compatible = "moxa,uc-8100-me-t", "ti,am33xx";
-
-- OMAP5 EVM : Evaluation Module
- compatible = "ti,omap5-evm", "ti,omap5"
- AM437x CM-T43
compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
@@ -217,9 +124,3 @@
- DRA718 EVM: Software Development Board for DRA718
compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
-
-- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3"
-
-- DM3730 Logic PD SOM-LV: Commercial System on Module with WiFi and Bluetooth
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3"
diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml
index e14358b..99b5e95 100644
--- a/Documentation/devicetree/bindings/arm/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/pmu.yaml
@@ -49,9 +49,14 @@
- arm,cortex-a77-pmu
- arm,cortex-a78-pmu
- arm,cortex-a510-pmu
+ - arm,cortex-a520-pmu
- arm,cortex-a710-pmu
+ - arm,cortex-a715-pmu
+ - arm,cortex-a720-pmu
- arm,cortex-x1-pmu
- arm,cortex-x2-pmu
+ - arm,cortex-x3-pmu
+ - arm,cortex-x4-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- arm,neoverse-n2-pmu
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
index 2ec9b5b..ea3c5db 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
%YAML 1.2
---
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
index 5c08342..3bad47b 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
%YAML 1.2
---
diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
index e333ec4..97621c9 100644
--- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
@@ -31,7 +31,7 @@
compatible:
oneOf:
# Preferred naming style for compatibles of SoC components:
- - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+-.*$"
+ - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|sa|sc|sdm|sdx|sm)[0-9]+(pro)?-.*$"
- pattern: "^qcom,(sa|sc)8[0-9]+[a-z][a-z]?-.*$"
# Legacy namings - variations of existing patterns/compatibles are OK,
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 450f616..adbfaea 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -30,6 +30,7 @@
apq8084
apq8096
ipq4018
+ ipq5018
ipq5332
ipq6018
ipq8074
@@ -72,6 +73,7 @@
sdx65
sdx75
sm4250
+ sm4450
sm6115
sm6115p
sm6125
@@ -104,6 +106,7 @@
hk10-c2
idp
liquid
+ rdp432-c2
mtp
qrd
rb2
@@ -186,6 +189,7 @@
- items:
- enum:
+ - samsung,a7
- sony,kanuti-tulip
- square,apq8039-t2
- const: qcom,msm8939
@@ -341,6 +345,11 @@
- items:
- enum:
+ - qcom,ipq5018-rdp432-c2
+ - const: qcom,ipq5018
+
+ - items:
+ - enum:
- qcom,ipq5332-ap-mi01.2
- qcom,ipq5332-ap-mi01.3
- qcom,ipq5332-ap-mi01.6
@@ -904,6 +913,11 @@
- items:
- enum:
+ - qcom,sm4450-qrd
+ - const: qcom,sm4450
+
+ - items:
+ - enum:
- fxtec,pro1x
- const: qcom,sm6115
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ecdb72a..ca53898 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -196,6 +196,11 @@
- const: firefly,rk3566-roc-pc
- const: rockchip,rk3566
+ - description: Firefly Station P2
+ items:
+ - const: firefly,rk3568-roc-pc
+ - const: rockchip,rk3568
+
- description: FriendlyElec NanoPi R2 series boards
items:
- enum:
@@ -222,6 +227,11 @@
- friendlyarm,nanopi-r5s
- const: rockchip,rk3568
+ - description: FriendlyElec NanoPC T6
+ items:
+ - const: friendlyarm,nanopc-t6
+ - const: rockchip,rk3588
+
- description: GeekBuying GeekBox
items:
- const: geekbuying,geekbox
@@ -694,6 +704,11 @@
- const: radxa,rock-4c-plus
- const: rockchip,rk3399
+ - description: Radxa ROCK 4SE
+ items:
+ - const: radxa,rock-4se
+ - const: rockchip,rk3399
+
- description: Radxa ROCK Pi E
items:
- const: radxa,rockpi-e
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
index 2297ad3..d2dce23 100644
--- a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 ML-AHB interconnect
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
index b63ff59..d083d8a 100644
--- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 Platforms System Controller
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index 4466b45..4bf28e7 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -143,7 +143,9 @@
- description: Octavo OSD32MP15x System-in-Package based boards
items:
- enum:
- - lxa,stm32mp157c-mc1 # Linux Automation MC-1
+ - lxa,stm32mp157c-mc1 # Linux Automation MC-1
+ - lxa,stm32mp157c-tac-gen1 # Linux Automation TAC (Generation 1)
+ - lxa,stm32mp157c-tac-gen2 # Linux Automation TAC (Generation 2)
- const: oct,stm32mp15xx-osd32
- enum:
- st,stm32mp157
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ee8fdd2..e4dd678 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -541,13 +541,13 @@
- const: msi,primo81
- const: allwinner,sun6i-a31s
- - description: Emlid Neutis N5 Developper Board
+ - description: Emlid Neutis N5 Developer Board
items:
- const: emlid,neutis-n5-devboard
- const: emlid,neutis-n5
- const: allwinner,sun50i-h5
- - description: Emlid Neutis N5H3 Developper Board
+ - description: Emlid Neutis N5H3 Developer Board
items:
- const: emlid,neutis-n5h3-devboard
- const: emlid,neutis-n5h3
@@ -997,4 +997,9 @@
- const: xunlong,orangepi-zero2
- const: allwinner,sun50i-h616
+ - description: Xunlong OrangePi Zero 3
+ items:
+ - const: xunlong,orangepi-zero3
+ - const: allwinner,sun50i-h618
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt
deleted file mode 100644
index 5ae601e..0000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-NVIDIA compliant embedded controller
-
-Required properties:
-- compatible : should be "nvidia,nvec".
-- reg : the iomem of the i2c slave controller
-- interrupts : the interrupt line of the i2c slave controller
-- clock-frequency : the frequency of the i2c bus
-- gpios : the gpio used for ec request
-- slave-addr: the i2c address of the slave controller
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- Tegra20/Tegra30:
- - div-clk
- - fast-clk
- Tegra114:
- - div-clk
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - i2c
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
deleted file mode 100644
index 9a4295b..0000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-NVIDIA Tegra AHB
-
-Required properties:
-- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For
- Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain
- '"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124,
- tegra132, or tegra210.
-- reg : Should contain 1 register ranges(address and length). For
- Tegra20, Tegra30, and Tegra114 chips, the value must be <0x6000c004
- 0x10c>. For Tegra124, Tegra132 and Tegra210 chips, the value should
- be be <0x6000c000 0x150>.
-
-Example (for a Tegra20 chip):
- ahb: ahb@6000c004 {
- compatible = "nvidia,tegra20-ahb";
- reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
- };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt
deleted file mode 100644
index a855c1b..0000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-NVIDIA Tegra Flow Controller
-
-Required properties:
-- compatible: Should contain one of the following:
- - "nvidia,tegra20-flowctrl": for Tegra20
- - "nvidia,tegra30-flowctrl": for Tegra30
- - "nvidia,tegra114-flowctrl": for Tegra114
- - "nvidia,tegra124-flowctrl": for Tegra124
- - "nvidia,tegra132-flowctrl", "nvidia,tegra124-flowctrl": for Tegra132
- - "nvidia,tegra210-flowctrl": for Tegra210
-- reg: Should contain one register range (address and length)
-
-Example:
-
- flow-controller@60007000 {
- compatible = "nvidia,tegra20-flowctrl";
- reg = <0x60007000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 577eee9..03d2a0d 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -25,6 +25,12 @@
- ti,am62a7-sk
- const: ti,am62a7
+ - description: K3 AM62P5 SoC and Boards
+ items:
+ - enum:
+ - ti,am62p5-sk
+ - const: ti,am62p5
+
- description: K3 AM625 SoC PHYTEC phyBOARD-Lyra
items:
- const: phytec,am625-phyboard-lyra-rdk
@@ -72,6 +78,13 @@
- const: phytec,am64-phycore-som
- const: ti,am642
+ - description: K3 AM642 SoC on TQ-Systems TQMaX4XxL SoM
+ items:
+ - enum:
+ - tq,am642-tqma6442l-mbax4xxl # MBaX4XxL base board
+ - const: tq,am642-tqma6442l
+ - const: ti,am642
+
- description: K3 AM654 SoC
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/ti/omap.yaml b/Documentation/devicetree/bindings/arm/ti/omap.yaml
new file mode 100644
index 0000000..b18fc04
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/omap.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/ti/omap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OMAP SoC architecture
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description: Platforms based on Texas Instruments OMAP SoC architecture.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: TI OMAP2420 SoC based platforms
+ items:
+ - enum:
+ - nokia,n800
+ - nokia,n810
+ - nokia,n810-wimax
+ - ti,omap2420-h4
+ - const: ti,omap2420
+ - const: ti,omap2
+
+ - description: TI OMAP2430 SoC based platforms
+ items:
+ - enum:
+ - ti,omap2430-sdp # TI OMAP2430 SDP
+ - const: ti,omap2430
+ - const: ti,omap2
+
+ - description: TI OMAP3430 SoC based platforms
+ items:
+ - enum:
+ - compulab,omap3-cm-t3530
+ - logicpd,dm3730-som-lv-devkit # LogicPD Zoom OMAP35xx SOM-LV Development Kit
+ - logicpd,dm3730-torpedo-devkit # LogicPD Zoom OMAP35xx Torpedo Development Kit
+ - nokia,omap3-n900
+ - openpandora,omap3-pandora-600mhz
+ - ti,omap3430-sdp
+ - ti,omap3-beagle
+ - ti,omap3-evm # TI OMAP35XX EVM (TMDSEVM3530)
+ - ti,omap3-ldp # TI OMAP3430 LDP (Zoom1 Labrador)
+ - timll,omap3-devkit8000
+ - const: ti,omap3430
+ - const: ti,omap3
+
+ - description: Early BeagleBoard revisions A to B4 with a timer quirk
+ items:
+ - const: ti,omap3-beagle-ab4
+ - const: ti,omap3-beagle
+ - const: ti,omap3430
+ - const: ti,omap3
+
+ - description: Gumstix Overo TI OMAP 3430/3630 boards + expansion boards
+ items:
+ - enum:
+ - gumstix,omap3-overo-alto35
+ - gumstix,omap3-overo-chestnut43
+ - gumstix,omap3-overo-gallop43
+ - gumstix,omap3-overo-palo35
+ - gumstix,omap3-overo-palo43
+ - gumstix,omap3-overo-summit
+ - gumstix,omap3-overo-tobi
+ - gumstix,omap3-overo-tobiduo
+ - const: gumstix,omap3-overo
+ - enum:
+ - ti,omap3430
+ - ti,omap3630
+
+ - description: TI OMAP3630 SoC based platforms
+ items:
+ - enum:
+ - amazon,omap3-echo # Amazon Echo (first generation)
+ - compulab,omap3-cm-t3730
+ - goldelico,gta04
+ - lg,omap3-sniper # LG Optimus Black
+ - logicpd,dm3730-som-lv-devkit # LogicPD Zoom DM3730 SOM-LV Development Kit
+ - logicpd,dm3730-torpedo-devkit # LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
+ - nokia,omap3-n9
+ - nokia,omap3-n950
+ - openpandora,omap3-pandora-1ghz
+ - ti,omap3-beagle-xm
+ - ti,omap3-evm-37xx # TI OMAP37XX EVM (TMDSEVM3730)
+ - ti,omap3-zoom3
+ - const: ti,omap3630
+ - const: ti,omap3
+
+ - description: TI AM35 SoC based platforms
+ items:
+ - enum:
+ - compulab,omap3-sbc-t3517 # CompuLab SBC-T3517 with CM-T3517
+ - teejet,mt_ventoux
+ - ti,am3517-craneboard # TI AM3517 CraneBoard (TMDSEVM3517)
+ - ti,am3517-evm # TI AM3517 EVM (AM3517/05 TMDSEVM3517)
+ - const: ti,am3517
+ - const: ti,omap3
+
+ - description: TI AM33 based platform
+ items:
+ - enum:
+ - compulab,cm-t335
+ - moxa,uc-8100-me-t
+ - novatech,am335x-lxm
+ - ti,am335x-bone
+ - ti,am335x-evm
+ - ti,am3359-icev2
+ - const: ti,am33xx
+
+ - description: Compulab board variants based on TI AM33
+ items:
+ - enum:
+ - compulab,sbc-t335
+ - const: compulab,cm-t335
+ - const: ti,am33xx
+
+ - description: Phytec boards based on TI AM33
+ items:
+ - enum:
+ - phytec,am335x-wega
+ - phytec,am335x-pcm-953
+ - phytec,am335x-regor
+ - const: phytec,am335x-phycore-som
+ - const: ti,am33xx
+
+ - description: TI OMAP4430 SoC based platforms
+ items:
+ - enum:
+ - amazon,omap4-kc1 # Amazon Kindle Fire (first generation)
+ - motorola,droid4 # Motorola Droid 4 XT894
+ - motorola,droid-bionic # Motorola Droid Bionic XT875
+ - ti,omap4-panda
+ - ti,omap4-sdp
+ - const: ti,omap4430
+ - const: ti,omap4
+
+ - description: OMAP4 DuoVero with Parlor expansion board/daughter board
+ items:
+ - const: gumstix,omap4-duovero-parlor
+ - const: gumstix,omap4-duovero
+ - const: ti,omap4430
+ - const: ti,omap4
+
+ - description: TI OMAP4460 SoC based platforms
+ items:
+ - enum:
+ - epson,embt2ws # Epson Moverio BT-200
+ - ti,omap4-panda-es
+ - const: ti,omap4460
+ - const: ti,omap4
+
+ - description: VAR-OM44 boards
+ items:
+ - enum:
+ - variscite,var-dvk-om44
+ - variscite,var-stk-om44
+ - const: variscite,var-som-om44
+ - const: ti,omap4460
+ - const: ti,omap4
+
+ - description: TI OMAP5 SoC based platforms
+ items:
+ - enum:
+ - compulab,omap5-cm-t54
+ - isee,omap5-igep0050
+ - ti,omap5-uevm
+ - const: ti,omap5
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/ata/pata-common.yaml b/Documentation/devicetree/bindings/ata/pata-common.yaml
index 2412894..337ddf1 100644
--- a/Documentation/devicetree/bindings/ata/pata-common.yaml
+++ b/Documentation/devicetree/bindings/ata/pata-common.yaml
@@ -12,7 +12,7 @@
description: |
This document defines device tree properties common to most Parallel
ATA (PATA, also known as IDE) AT attachment storage devices.
- It doesn't constitue a device tree binding specification by itself but is
+ It doesn't constitute a device tree binding specification by itself but is
meant to be referenced by device tree bindings.
The PATA (IDE) controller-specific device tree bindings are responsible for
diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml
index b23c300..3aaefdb 100644
--- a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml
+++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml
@@ -43,7 +43,7 @@
brcm,gisb-arb-master-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: >
- String list of the litteral name of the GISB masters. Should match the
+ String list of the literal name of the GISB masters. Should match the
number of bits set in brcm,gisb-master-mask and the order in which they
appear from MSB to LSB.
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
index 4157e88..26362c9 100644
--- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
@@ -7,10 +7,10 @@
title: NVIDIA Tegra ACONNECT Bus
description: |
- The Tegra ACONNECT bus is an AXI switch which is used to connnect various
+ The Tegra ACONNECT bus is an AXI switch which is used to connect 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.
+ devices accessed via the ACONNECT are described by child-nodes.
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
diff --git a/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml b/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml
new file mode 100644
index 0000000..693cfa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/qcom,ssbi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Single-wire Serial Bus Interface (SSBI)
+
+description:
+ Some Qualcomm MSM devices contain a point-to-point serial bus used to
+ communicate with a limited range of devices (mostly power management
+ chips).
+
+maintainers:
+ - Andy Gross <agross@kernel.org>
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ const: qcom,ssbi
+
+ reg:
+ maxItems: 1
+
+ qcom,controller-type:
+ description:
+ Indicates the SSBI bus variant the controller should use to talk
+ with the slave device. The type chosen is determined by the attached
+ slave.
+ enum:
+ - ssbi
+ - ssbi2
+ - pmic-arbiter
+
+ pmic:
+ $ref: /schemas/mfd/qcom-pm8xxx.yaml#
+
+required:
+ - compatible
+ - reg
+ - qcom,controller-type
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ ssbi@c00000 {
+ compatible = "qcom,ssbi";
+ reg = <0x00c00000 0x1000>;
+ qcom,controller-type = "pmic-arbiter";
+
+ pmic {
+ compatible = "qcom,pm8821";
+ interrupt-parent = <&msmgpio>;
+ interrupts = <76 IRQ_TYPE_LEVEL_LOW>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
index 3b0548c..9f9816f 100644
--- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
+++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
@@ -29,10 +29,8 @@
patternProperties:
'^connector@[0-9a-f]+$':
$ref: /schemas/connector/usb-connector.yaml#
- unevaluatedProperties: false
- properties:
- reg:
- maxItems: 1
+ required:
+ - reg
required:
- compatible
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml
index 52a7b6e..0052bf1 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-osc-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Gatable Oscillator Clock
+title: Allwinner A10 Gateable Oscillator Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/alphascale,acc.txt b/Documentation/devicetree/bindings/clock/alphascale,acc.txt
index b3205b2..c9fb932 100644
--- a/Documentation/devicetree/bindings/clock/alphascale,acc.txt
+++ b/Documentation/devicetree/bindings/clock/alphascale,acc.txt
@@ -1,7 +1,7 @@
Alphascale Clock Controller
-The ACC (Alphascale Clock Controller) is responsible of choising proper
-clock source, setting deviders and clock gates.
+The ACC (Alphascale Clock Controller) is responsible for choosing proper
+clock source, setting dividers and clock gates.
Required properties for the ACC node:
- compatible: must be "alphascale,asm9260-clock-controller"
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt
deleted file mode 100644
index c41f0be..0000000
--- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-* Amlogic GXBB AO Clock and Reset Unit
-
-The Amlogic GXBB AO clock controller generates and supplies clock to various
-controllers within the Always-On part of the SoC.
-
-Required Properties:
-
-- compatible: value should be different for each SoC family as :
- - GXBB (S905) : "amlogic,meson-gxbb-aoclkc"
- - GXL (S905X, S905D) : "amlogic,meson-gxl-aoclkc"
- - GXM (S912) : "amlogic,meson-gxm-aoclkc"
- - AXG (A113D, A113X) : "amlogic,meson-axg-aoclkc"
- - G12A (S905X2, S905D2, S905Y2) : "amlogic,meson-g12a-aoclkc"
- followed by the common "amlogic,meson-gx-aoclkc"
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "xtal" : the platform xtal
- * "mpeg-clk" : the main clock controller mother clock (aka clk81)
- * "ext-32k-0" : external 32kHz reference #0 if any (optional)
- * "ext-32k-1" : external 32kHz reference #1 if any (optional - gx only)
- * "ext-32k-2" : external 32kHz reference #2 if any (optional - gx only)
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/gxbb-aoclkc.h header and can be
-used in device tree sources.
-
-- #reset-cells: should be 1.
-
-Each reset is assigned an identifier and client nodes can use this identifier
-to specify the reset which they consume. All available resets are defined as
-preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be
-used in device tree sources.
-
-Parent node should have the following properties :
-- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"
-- reg: base address and size of the AO system control register space.
-
-Example: AO Clock controller node:
-
-ao_sysctrl: sys-ctrl@0 {
- compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd";
- reg = <0x0 0x0 0x0 0x100>;
-
- clkc_AO: clock-controller {
- compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
- #clock-cells = <1>;
- #reset-cells = <1>;
- clocks = <&xtal>, <&clkc CLKID_CLK81>;
- clock-names = "xtal", "mpeg-clk";
- };
-
-Example: UART controller node that consumes the clock and reset generated
- by the clock controller:
-
- uart_AO: serial@4c0 {
- compatible = "amlogic,meson-uart";
- reg = <0x4c0 0x14>;
- interrupts = <0 90 1>;
- clocks = <&clkc_AO CLKID_AO_UART1>;
- resets = <&clkc_AO RESET_AO_UART1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml
new file mode 100644
index 0000000..628e5dd3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,gxbb-aoclkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Always-On Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-aoclkc
+ - amlogic,meson-gxl-aoclkc
+ - amlogic,meson-gxm-aoclkc
+ - amlogic,meson-axg-aoclkc
+ - const: amlogic,meson-gx-aoclkc
+ - enum:
+ - amlogic,meson-axg-aoclkc
+ - amlogic,meson-g12a-aoclkc
+
+ clocks:
+ minItems: 2
+ maxItems: 5
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: xtal
+ - const: mpeg-clk
+ - const: ext-32k-0
+ - const: ext-32k-1
+ - const: ext-32k-2
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-aoclkc
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxl-aoclkc
+ - amlogic,meson-gxm-aoclkc
+ - amlogic,meson-axg-aoclkc
+
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ maxItems: 2
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
deleted file mode 100644
index 7ccecd5..0000000
--- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Amlogic GXBB Clock and Reset Unit
-
-The Amlogic GXBB clock controller generates and supplies clock to various
-controllers within the SoC.
-
-Required Properties:
-
-- compatible: should be:
- "amlogic,gxbb-clkc" for GXBB SoC,
- "amlogic,gxl-clkc" for GXL and GXM SoC,
- "amlogic,axg-clkc" for AXG SoC.
- "amlogic,g12a-clkc" for G12A SoC.
- "amlogic,g12b-clkc" for G12B SoC.
- "amlogic,sm1-clkc" for SM1 SoC.
-- clocks : list of clock phandle, one for each entry clock-names.
-- clock-names : should contain the following:
- * "xtal": the platform xtal
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/gxbb-clkc.h header and can be
-used in device tree sources.
-
-Parent node should have the following properties :
-- compatible: "syscon", "simple-mfd, and "amlogic,meson-gx-hhi-sysctrl" or
- "amlogic,meson-axg-hhi-sysctrl"
-- reg: base address and size of the HHI system control register space.
-
-Example: Clock controller node:
-
-sysctrl: system-controller@0 {
- compatible = "amlogic,meson-gx-hhi-sysctrl", "syscon", "simple-mfd";
- reg = <0 0 0 0x400>;
-
- clkc: clock-controller {
- #clock-cells = <1>;
- compatible = "amlogic,gxbb-clkc";
- clocks = <&xtal>;
- clock-names = "xtal";
- };
-};
-
-Example: UART controller node that consumes the clock generated by the clock
- controller:
-
- uart_AO: serial@c81004c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc81004c0 0x14>;
- interrupts = <0 90 1>;
- clocks = <&clkc CLKID_CLK81>;
- };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml
new file mode 100644
index 0000000..63246f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,gxbb-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,gxbb-clkc
+ - amlogic,gxl-clkc
+ - amlogic,axg-clkc
+ - amlogic,g12a-clkc
+ - amlogic,g12b-clkc
+ - amlogic,sm1-clkc
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xtal
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml b/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml
new file mode 100644
index 0000000..07b9d21
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml
@@ -0,0 +1,282 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,imx8-acm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8 Audio Clock Mux
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+description: |
+ NXP i.MX8 Audio Clock Mux is dedicated clock muxing IP
+ used to control Audio related clock on the SoC.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8dxl-acm
+ - fsl,imx8qm-acm
+ - fsl,imx8qxp-acm
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ minItems: 13
+ maxItems: 21
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8-clock.h
+ for the full list of i.MX8 ACM clock IDs.
+
+ clocks:
+ minItems: 13
+ maxItems: 27
+
+ clock-names:
+ minItems: 13
+ maxItems: 27
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-acm
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: power domain of IMX_SC_R_AUDIO_CLK_0
+ - description: power domain of IMX_SC_R_AUDIO_CLK_1
+ - description: power domain of IMX_SC_R_MCLK_OUT_0
+ - description: power domain of IMX_SC_R_MCLK_OUT_1
+ - description: power domain of IMX_SC_R_AUDIO_PLL_0
+ - description: power domain of IMX_SC_R_AUDIO_PLL_1
+ - description: power domain of IMX_SC_R_ASRC_0
+ - description: power domain of IMX_SC_R_ASRC_1
+ - description: power domain of IMX_SC_R_ESAI_0
+ - description: power domain of IMX_SC_R_SAI_0
+ - description: power domain of IMX_SC_R_SAI_1
+ - description: power domain of IMX_SC_R_SAI_2
+ - description: power domain of IMX_SC_R_SAI_3
+ - description: power domain of IMX_SC_R_SAI_4
+ - description: power domain of IMX_SC_R_SAI_5
+ - description: power domain of IMX_SC_R_SPDIF_0
+ - description: power domain of IMX_SC_R_MQS_0
+
+ clocks:
+ minItems: 18
+ maxItems: 18
+
+ clock-names:
+ items:
+ - const: aud_rec_clk0_lpcg_clk
+ - const: aud_rec_clk1_lpcg_clk
+ - const: aud_pll_div_clk0_lpcg_clk
+ - const: aud_pll_div_clk1_lpcg_clk
+ - const: ext_aud_mclk0
+ - const: ext_aud_mclk1
+ - const: esai0_rx_clk
+ - const: esai0_rx_hf_clk
+ - const: esai0_tx_clk
+ - const: esai0_tx_hf_clk
+ - const: spdif0_rx
+ - const: sai0_rx_bclk
+ - const: sai0_tx_bclk
+ - const: sai1_rx_bclk
+ - const: sai1_tx_bclk
+ - const: sai2_rx_bclk
+ - const: sai3_rx_bclk
+ - const: sai4_rx_bclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-acm
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: power domain of IMX_SC_R_AUDIO_CLK_0
+ - description: power domain of IMX_SC_R_AUDIO_CLK_1
+ - description: power domain of IMX_SC_R_MCLK_OUT_0
+ - description: power domain of IMX_SC_R_MCLK_OUT_1
+ - description: power domain of IMX_SC_R_AUDIO_PLL_0
+ - description: power domain of IMX_SC_R_AUDIO_PLL_1
+ - description: power domain of IMX_SC_R_ASRC_0
+ - description: power domain of IMX_SC_R_ASRC_1
+ - description: power domain of IMX_SC_R_ESAI_0
+ - description: power domain of IMX_SC_R_ESAI_1
+ - description: power domain of IMX_SC_R_SAI_0
+ - description: power domain of IMX_SC_R_SAI_1
+ - description: power domain of IMX_SC_R_SAI_2
+ - description: power domain of IMX_SC_R_SAI_3
+ - description: power domain of IMX_SC_R_SAI_4
+ - description: power domain of IMX_SC_R_SAI_5
+ - description: power domain of IMX_SC_R_SAI_6
+ - description: power domain of IMX_SC_R_SAI_7
+ - description: power domain of IMX_SC_R_SPDIF_0
+ - description: power domain of IMX_SC_R_SPDIF_1
+ - description: power domain of IMX_SC_R_MQS_0
+
+ clocks:
+ minItems: 27
+ maxItems: 27
+
+ clock-names:
+ items:
+ - const: aud_rec_clk0_lpcg_clk
+ - const: aud_rec_clk1_lpcg_clk
+ - const: aud_pll_div_clk0_lpcg_clk
+ - const: aud_pll_div_clk1_lpcg_clk
+ - const: mlb_clk
+ - const: hdmi_rx_mclk
+ - const: ext_aud_mclk0
+ - const: ext_aud_mclk1
+ - const: esai0_rx_clk
+ - const: esai0_rx_hf_clk
+ - const: esai0_tx_clk
+ - const: esai0_tx_hf_clk
+ - const: esai1_rx_clk
+ - const: esai1_rx_hf_clk
+ - const: esai1_tx_clk
+ - const: esai1_tx_hf_clk
+ - const: spdif0_rx
+ - const: spdif1_rx
+ - const: sai0_rx_bclk
+ - const: sai0_tx_bclk
+ - const: sai1_rx_bclk
+ - const: sai1_tx_bclk
+ - const: sai2_rx_bclk
+ - const: sai3_rx_bclk
+ - const: sai4_rx_bclk
+ - const: sai5_tx_bclk
+ - const: sai6_rx_bclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8dxl-acm
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: power domain of IMX_SC_R_AUDIO_CLK_0
+ - description: power domain of IMX_SC_R_AUDIO_CLK_1
+ - description: power domain of IMX_SC_R_MCLK_OUT_0
+ - description: power domain of IMX_SC_R_MCLK_OUT_1
+ - description: power domain of IMX_SC_R_AUDIO_PLL_0
+ - description: power domain of IMX_SC_R_AUDIO_PLL_1
+ - description: power domain of IMX_SC_R_ASRC_0
+ - description: power domain of IMX_SC_R_SAI_0
+ - description: power domain of IMX_SC_R_SAI_1
+ - description: power domain of IMX_SC_R_SAI_2
+ - description: power domain of IMX_SC_R_SAI_3
+ - description: power domain of IMX_SC_R_SPDIF_0
+ - description: power domain of IMX_SC_R_MQS_0
+
+ clocks:
+ minItems: 13
+ maxItems: 13
+
+ clock-names:
+ items:
+ - const: aud_rec_clk0_lpcg_clk
+ - const: aud_rec_clk1_lpcg_clk
+ - const: aud_pll_div_clk0_lpcg_clk
+ - const: aud_pll_div_clk1_lpcg_clk
+ - const: ext_aud_mclk0
+ - const: ext_aud_mclk1
+ - const: spdif0_rx
+ - const: sai0_rx_bclk
+ - const: sai0_tx_bclk
+ - const: sai1_rx_bclk
+ - const: sai1_tx_bclk
+ - const: sai2_rx_bclk
+ - const: sai3_rx_bclk
+
+additionalProperties: false
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ clock-controller@59e00000 {
+ compatible = "fsl,imx8qxp-acm";
+ reg = <0x59e00000 0x1d0000>;
+ #clock-cells = <1>;
+ power-domains = <&pd IMX_SC_R_AUDIO_CLK_0>,
+ <&pd IMX_SC_R_AUDIO_CLK_1>,
+ <&pd IMX_SC_R_MCLK_OUT_0>,
+ <&pd IMX_SC_R_MCLK_OUT_1>,
+ <&pd IMX_SC_R_AUDIO_PLL_0>,
+ <&pd IMX_SC_R_AUDIO_PLL_1>,
+ <&pd IMX_SC_R_ASRC_0>,
+ <&pd IMX_SC_R_ASRC_1>,
+ <&pd IMX_SC_R_ESAI_0>,
+ <&pd IMX_SC_R_SAI_0>,
+ <&pd IMX_SC_R_SAI_1>,
+ <&pd IMX_SC_R_SAI_2>,
+ <&pd IMX_SC_R_SAI_3>,
+ <&pd IMX_SC_R_SAI_4>,
+ <&pd IMX_SC_R_SAI_5>,
+ <&pd IMX_SC_R_SPDIF_0>,
+ <&pd IMX_SC_R_MQS_0>;
+ clocks = <&aud_rec0_lpcg IMX_LPCG_CLK_0>,
+ <&aud_rec1_lpcg IMX_LPCG_CLK_0>,
+ <&aud_pll_div0_lpcg IMX_LPCG_CLK_0>,
+ <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>,
+ <&clk_ext_aud_mclk0>,
+ <&clk_ext_aud_mclk1>,
+ <&clk_esai0_rx_clk>,
+ <&clk_esai0_rx_hf_clk>,
+ <&clk_esai0_tx_clk>,
+ <&clk_esai0_tx_hf_clk>,
+ <&clk_spdif0_rx>,
+ <&clk_sai0_rx_bclk>,
+ <&clk_sai0_tx_bclk>,
+ <&clk_sai1_rx_bclk>,
+ <&clk_sai1_tx_bclk>,
+ <&clk_sai2_rx_bclk>,
+ <&clk_sai3_rx_bclk>,
+ <&clk_sai4_rx_bclk>;
+ clock-names = "aud_rec_clk0_lpcg_clk",
+ "aud_rec_clk1_lpcg_clk",
+ "aud_pll_div_clk0_lpcg_clk",
+ "aud_pll_div_clk1_lpcg_clk",
+ "ext_aud_mclk0",
+ "ext_aud_mclk1",
+ "esai0_rx_clk",
+ "esai0_rx_hf_clk",
+ "esai0_tx_clk",
+ "esai0_tx_hf_clk",
+ "spdif0_rx",
+ "sai0_rx_bclk",
+ "sai0_tx_bclk",
+ "sai1_rx_bclk",
+ "sai1_tx_bclk",
+ "sai2_rx_bclk",
+ "sai3_rx_bclk",
+ "sai4_rx_bclk";
+ };
diff --git a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt
deleted file mode 100644
index 4733e58..0000000
--- a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Hisilicon Hix5hd2 Clock Controller
-
-The hix5hd2 clock controller generates and supplies clock to various
-controllers within the hix5hd2 SoC.
-
-Required Properties:
-
-- compatible: should be "hisilicon,hix5hd2-clock"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-Each clock is assigned an identifier and client nodes use this identifier
-to specify the clock which they consume.
-
-All these identifier could be found in <dt-bindings/clock/hix5hd2-clock.h>.
-
-Examples:
- clock: clock@f8a22000 {
- compatible = "hisilicon,hix5hd2-clock";
- reg = <0xf8a22000 0x1000>;
- #clock-cells = <1>;
- };
-
- uart0: uart@f8b00000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0xf8b00000 0x1000>;
- interrupts = <0 49 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
- };
diff --git a/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml b/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml
new file mode 100644
index 0000000..d120b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/intel,agilex5-clkmgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel SoCFPGA Agilex5 clock manager
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+
+description:
+ The Intel Agilex5 Clock Manager is an integrated clock controller, which
+ generates and supplies clock to all the modules.
+
+properties:
+ compatible:
+ const: intel,agilex5-clkmgr
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clkmgr: clock-controller@10d10000 {
+ compatible = "intel,agilex5-clkmgr";
+ reg = <0x10d10000 0x1000>;
+ #clock-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 47570d2..9a3fbc6 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -14,7 +14,7 @@
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
- clocks : parent clock phandle
-- reg - pll control0 and pll multipler registers
+- reg - pll control0 and pll multiplier registers
- reg-names : control, multiplier and post-divider. The multiplier and
post-divider registers are applicable only for main pll clock
- fixed-postdiv : fixed post divider value. If absent, use clkod register bits
diff --git a/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt b/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt
index fa97c12..8cf8f0e 100644
--- a/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt
@@ -68,7 +68,7 @@
"base_ssp0_clk", "base_sdio_clk";
};
- /* A user of CCU brach clocks */
+ /* A user of CCU branch clocks */
uart1: serial@40082000 {
...
clocks = <&ccu2 CLK_APB0_UART1>, <&ccu1 CLK_CPU_UART1>;
diff --git a/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt b/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
index 6f1c7b4..b6b2547 100644
--- a/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
+++ b/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
@@ -5,8 +5,8 @@
32 kHz oscillator driver with power up/down and clock gating. Next
is a fixed divider that creates a 1 kHz clock from the 32 kHz osc.
-These clocks are used by the RTC and the Event Router peripherials.
-The 32 kHz can also be routed to other peripherials to enable low
+These clocks are used by the RTC and the Event Router peripherals.
+The 32 kHz can also be routed to other peripherals to enable low
power modes.
This binding uses the common clock binding:
diff --git a/Documentation/devicetree/bindings/clock/maxim,max9485.txt b/Documentation/devicetree/bindings/clock/maxim,max9485.txt
index 61bec11..b8f5c3b 100644
--- a/Documentation/devicetree/bindings/clock/maxim,max9485.txt
+++ b/Documentation/devicetree/bindings/clock/maxim,max9485.txt
@@ -12,7 +12,7 @@
Required properties:
- compatible: "maxim,max9485"
-- clocks: Input clock, must provice 27.000 MHz
+- clocks: Input clock, must provide 27.000 MHz
- clock-names: Must be set to "xclk"
- #clock-cells: From common clock binding; shall be set to 1
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml
index 1b2181f..a9ba211 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml
@@ -27,7 +27,9 @@
properties:
compatible:
- const: nvidia,tegra124-car
+ enum:
+ - nvidia,tegra124-car
+ - nvidia,tegra132-car
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
deleted file mode 100644
index b652f3f..0000000
--- a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Oxford Semiconductor OXNAS SoC Family Standard Clocks
-================================================
-
-Please also refer to clock-bindings.txt in this directory for common clock
-bindings usage.
-
-Required properties:
-- compatible: For OX810SE, should be "oxsemi,ox810se-stdclk"
- For OX820, should be "oxsemi,ox820-stdclk"
-- #clock-cells: 1, see below
-
-Parent node should have the following properties :
-- compatible: For OX810SE, should be
- "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
- For OX820, should be
- "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-
-example:
-
-sys: sys-ctrl@000000 {
- compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
- reg = <0x000000 0x100000>;
-
- stdclk: stdclk {
- compatible = "oxsemi,ox810se-stdclk";
- #clock-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
index 8a210c4..0a3ef7f 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
@@ -29,6 +29,7 @@
- description: Link clock from DP PHY
- description: VCO DIV clock from DP PHY
- description: AHB config clock from GCC
+ - description: GPLL0 div source from GCC
clock-names:
items:
@@ -39,6 +40,7 @@
- const: dp_phy_pll_link_clk
- const: dp_phy_pll_vco_div_clk
- const: cfg_ahb_clk
+ - const: gcc_disp_gpll0_div_clk_src
'#clock-cells':
const: 1
@@ -46,6 +48,16 @@
'#power-domain-cells':
const: 1
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the CX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing the power domain's performance point.
+ maxItems: 1
+
reg:
maxItems: 1
@@ -63,23 +75,31 @@
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/clock/qcom,gcc-sm6125.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
clock-controller@5f00000 {
compatible = "qcom,sm6125-dispcc";
reg = <0x5f00000 0x20000>;
+
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&dsi0_phy 0>,
<&dsi0_phy 1>,
<&dsi1_phy 1>,
<&dp_phy 0>,
<&dp_phy 1>,
- <&gcc GCC_DISP_AHB_CLK>;
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
clock-names = "bi_tcxo",
"dsi0_phy_pll_out_byteclk",
"dsi0_phy_pll_out_dsiclk",
"dsi1_phy_pll_out_dsiclk",
"dp_phy_pll_link_clk",
"dp_phy_pll_vco_div_clk",
- "cfg_ahb_clk";
+ "cfg_ahb_clk",
+ "gcc_disp_gpll0_div_clk_src";
+
+ required-opps = <&rpmhpd_opp_ret>;
+ power-domains = <&rpmpd SM6125_VDDCX>;
+
#clock-cells = <1>;
#power-domain-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
index d6774db..59cc88a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
@@ -82,7 +82,7 @@
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@af00000 {
compatible = "qcom,sm8250-dispcc";
reg = <0x0af00000 0x10000>;
@@ -103,7 +103,7 @@
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
index 09cd7a7..1921117 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml
index 6ebaef2..fb3957d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
- Robert Marko <robert.markoo@sartura.hr>
description: |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
index deef398..52e7831 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml
index d2186e25..62d6f1f 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
index f77036a..97523cc 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module which provides the clocks, resets and
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
index 3c97290..58f7fb2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
index ba969e7..559fc21 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
@@ -19,8 +19,6 @@
include/dt-bindings/reset/qcom,gcc-ipq6018.h
include/dt-bindings/clock/qcom,gcc-msm8953.h
include/dt-bindings/clock/qcom,gcc-mdm9607.h
- include/dt-bindings/clock/qcom,gcc-mdm9615.h
- include/dt-bindings/reset/qcom,gcc-mdm9615.h
allOf:
- $ref: qcom,gcc.yaml#
@@ -30,7 +28,6 @@
enum:
- qcom,gcc-ipq6018
- qcom,gcc-mdm9607
- - qcom,gcc-mdm9615
required:
- compatible
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
index b2256f8..7bc6c57 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
index 8bf9b6f4..7aae21a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
index ff0b18bb..c4ca08d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Global Clock & Reset Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
index 68e1b7822..0595da0 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
index 3ea0ff3..58ccb7d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
index ead6665..5d77c09 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
index 9a31981..75259f4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
@@ -25,7 +25,7 @@
- description: Sleep clock source
- description: PCIE 0 Pipe clock source (Optional clock)
- description: PCIE 1 Pipe clock source (Optional clock)
- - description: PCIE 1 Phy Auxillary clock source (Optional clock)
+ - description: PCIE 1 Phy Auxiliary clock source (Optional clock)
- description: UFS Phy Rx symbol 0 clock source (Optional clock)
- description: UFS Phy Rx symbol 1 clock source (Optional clock)
- description: UFS Phy Tx symbol 0 clock source (Optional clock)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
index 7129fbc..7888251 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
@@ -8,7 +8,7 @@
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Common bindings for Qualcomm global clock control module providing the
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index a00216b..f369fa3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Graphics Clock & Reset Controller
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm graphics clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
new file mode 100644
index 0000000..ef84a0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq5018-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on IPQ5018
+
+maintainers:
+ - Sricharan Ramabadhran <quic_srichara@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ5018
+
+ See also::
+ include/dt-bindings/clock/qcom,ipq5018-gcc.h
+ include/dt-bindings/reset/qcom,ipq5018-gcc.h
+
+properties:
+ compatible:
+ const: qcom,gcc-ipq5018
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE20 PHY0 pipe clock source
+ - description: PCIE20 PHY1 pipe clock source
+ - description: USB3 PHY pipe clock source
+ - description: GEPHY RX clock source
+ - description: GEPHY TX clock source
+ - description: UNIPHY RX clock source
+ - description: UNIPHY TX clk source
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@1800000 {
+ compatible = "qcom,gcc-ipq5018";
+ reg = <0x01800000 0x80000>;
+ clocks = <&xo_board_clk>,
+ <&sleep_clk>,
+ <&pcie20_phy0_pipe_clk>,
+ <&pcie20_phy1_pipe_clk>,
+ <&usb3_phy0_pipe_clk>,
+ <&gephy_rx_clk>,
+ <&gephy_tx_clk>,
+ <&uniphy_rx_clk>,
+ <&uniphy_tx_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml
index a466e4e..5763275 100644
--- a/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml
@@ -14,7 +14,7 @@
There is one ACC register region per CPU within the KPSS remapped region as
well as an alias register region that remaps accesses to the ACC associated
with the CPU accessing the region. ACC v1 is currently used as a
- clock-controller for enabling the cpu and hanling the aux clocks.
+ clock-controller for enabling the cpu and handling the aux clocks.
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/qcom,lcc.yaml b/Documentation/devicetree/bindings/clock/qcom,lcc.yaml
index 8c78382..55985e5 100644
--- a/Documentation/devicetree/bindings/clock/qcom,lcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,lcc.yaml
@@ -76,6 +76,40 @@
- clocks
- clock-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,lcc-mdm9615
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board CXO source
+ - description: PLL 4 Vote clock
+ - description: MI2S codec clock
+ - description: Mic I2S codec clock
+ - description: Mic I2S spare clock
+ - description: Speaker I2S codec clock
+ - description: Speaker I2S spare clock
+ - description: PCM codec clock
+
+ clock-names:
+ items:
+ - const: cxo
+ - const: pll4_vote
+ - const: mi2s_codec_clk
+ - const: codec_i2s_mic_codec_clk
+ - const: spare_i2s_mic_codec_clk
+ - const: codec_i2s_spkr_codec_clk
+ - const: spare_i2s_spkr_codec_clk
+ - const: pcm_codec_clk
+
+ required:
+ - clocks
+ - clock-names
+
examples:
- |
clock-controller@28000000 {
diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
index 422f577..aa35a40 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
@@ -8,7 +8,7 @@
maintainers:
- Jeffrey Hugo <quic_jhugo@quicinc.com>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm multimedia clock control module provides the clocks, resets and
@@ -297,6 +297,7 @@
- description: HDMI phy PLL clock
- description: DisplayPort phy PLL link clock
- description: DisplayPort phy PLL vco clock
+ - description: Global PLL 0 DIV clock
clock-names:
items:
@@ -309,6 +310,7 @@
- const: hdmipll
- const: dplink
- const: dpvco
+ - const: gpll0_div
- if:
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
index 3ffe69d..0dfbd8c4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
@@ -15,7 +15,9 @@
properties:
compatible:
- const: qcom,msm8996-cbf
+ enum:
+ - qcom,msm8996-cbf
+ - qcom,msm8996pro-cbf
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml
index 2d88979..7b271ae 100644
--- a/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Graphics Clock & Reset Controller on MSM8998
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm graphics clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
index 767a9d0..d712b1a8 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
@@ -7,7 +7,8 @@
title: Qualcomm Global Clock & Reset Controller for QDU1000 and QRU1000
maintainers:
- - Melody Olvera <quic_molvera@quicinc.com>
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Imran Shaik <quic_imrashai@quicinc.com>
description: |
Qualcomm global clock control module which supports the clocks, resets and
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
index 267cf8c..fd14d18 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Technologies, Inc. RPMh Clocks
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Resource Power Manager Hardened (RPMh) manages shared resources on
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
index 098c8ac..2dfc2a4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Camera Clock & Reset Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm camera clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
index 95ad16d..1c9ce300 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Display Clock & Reset Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm display clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
index f297694..fdfb389 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm LPASS Core Clock Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm LPASS core clock control module provides the clocks and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
index 1e856a8..873a2f9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Modem Clock Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm modem clock control module provides the clocks on SC7180.
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
index b60adba..01feef1 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Camera Clock & Reset Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm camera clock control module provides the clocks, resets and
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml
index cfe6594..c42b0ef 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Display Clock & Reset Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm display clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml
index 97c6bd9..f44c5c1 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm LPASS Core Clock Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm LPASS core clock control module provides the clocks and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
index 447cdc4..deee542 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm LPASS Core & Audio Clock Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm LPASS core and audio clock control module provides the clocks and
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
index 76b53ce..719844d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Display Clock & Reset Controller on SDM845
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm display clock control module provides the clocks, resets and power
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
index 23505c8..46d1d91 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -19,7 +19,9 @@
properties:
compatible:
- const: qcom,sm8350-videocc
+ enum:
+ - qcom,sc8280xp-videocc
+ - qcom,sm8350-videocc
clocks:
items:
@@ -51,7 +53,7 @@
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@abf0000 {
compatible = "qcom,sm8350-videocc";
@@ -59,7 +61,7 @@
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- power-domains = <&rpmhpd SM8350_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
index 87ae741..8178c35 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
@@ -64,7 +64,7 @@
- |
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@ade0000 {
compatible = "qcom,sm8450-camcc";
reg = <0xade0000 0x20000>;
@@ -72,7 +72,7 @@
<&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml
index 1dd1f69..2f22310 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml
@@ -76,7 +76,7 @@
- |
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@af00000 {
compatible = "qcom,sm8450-dispcc";
reg = <0x0af00000 0x10000>;
@@ -91,7 +91,7 @@
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
index f1c6dd5..bad8f01 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
@@ -64,13 +64,13 @@
- |
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
videocc: clock-controller@aaf0000 {
compatible = "qcom,sm8450-videocc";
reg = <0x0aaf0000 0x10000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_VIDEO_AHB_CLK>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
index ab25f7c..c129f8c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
@@ -76,7 +76,7 @@
- |
#include <dt-bindings/clock/qcom,sm8550-gcc.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@af00000 {
compatible = "qcom,sm8550-dispcc";
reg = <0x0af00000 0x10000>;
@@ -99,7 +99,7 @@
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
- power-domains = <&rpmhpd SM8550_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index 2b07146..6999e36 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Video Clock & Reset Controller
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm video clock control module provides the clocks, resets and power
@@ -124,7 +124,7 @@
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@ab00000 {
compatible = "qcom,sdm845-videocc";
reg = <0x0ab00000 0x10000>;
@@ -133,7 +133,7 @@
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml
new file mode 100644
index 0000000..839648e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,5p35023.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas 5p35023 VersaClock 3 programmable I2C clock generator
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The 5P35023 is a VersaClock programmable clock generator and
+ is designed for low-power, consumer, and high-performance PCI
+ express applications. The 5P35023 device is a three PLL
+ architecture design, and each PLL is individually programmable
+ and allowing for up to 6 unique frequency outputs.
+
+ An internal OTP memory allows the user to store the configuration
+ in the device. After power up, the user can change the device register
+ settings through the I2C interface when I2C mode is selected.
+
+ The driver can read a full register map from the DT, and will use that
+ register map to initialize the attached part (via I2C) when the system
+ boots. Any configuration not supported by the common clock framework
+ must be done via the full register map, including optimized settings.
+
+ Link to datasheet:
+ https://www.renesas.com/us/en/products/clocks-timing/clock-generation/programmable-clocks/5p35023-versaclock-3s-programmable-clock-generator
+
+properties:
+ compatible:
+ enum:
+ - renesas,5p35023
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ renesas,settings:
+ description: Optional, complete register map of the device.
+ Optimized settings for the device must be provided in full
+ and are written during initialization.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ maxItems: 37
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ versa3: clock-generator@68 {
+ compatible = "renesas,5p35023";
+ reg = <0x68>;
+ #clock-cells = <1>;
+
+ clocks = <&x1_x2>;
+
+ renesas,settings = [
+ 80 00 11 19 4c 02 23 7f 83 19 08 a9 5f 25 24 bf
+ 00 14 7a e1 00 00 00 00 01 55 59 bb 3f 30 90 b6
+ 80 b0 45 c4 95
+ ];
+
+ assigned-clocks = <&versa3 0>, <&versa3 1>,
+ <&versa3 2>, <&versa3 3>,
+ <&versa3 4>, <&versa3 5>;
+ assigned-clock-rates = <12288000>, <25000000>,
+ <12000000>, <11289600>,
+ <11289600>, <24000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
index 1703e30..a065805 100644
--- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
@@ -66,7 +66,7 @@
else:
description: |
Other SC9863a clock nodes should be the child of a syscon node in
- which compatible string shoule be:
+ which compatible string should be:
"sprd,sc9863a-glbregs", "syscon", "simple-mfd"
The 'reg' property for the clock node is also required if there is a sub
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml
new file mode 100644
index 0000000..3b8b85b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-ispcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Image-Signal-Process Clock and Reset Generator
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-ispcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ISP Top core
+ - description: ISP Top Axi
+ - description: NOC ISP Bus
+ - description: external DVP
+
+ clock-names:
+ items:
+ - const: isp_top_core
+ - const: isp_top_axi
+ - const: noc_bus_isp_axi
+ - const: dvp_clk
+
+ resets:
+ items:
+ - description: ISP Top core
+ - description: ISP Top Axi
+ - description: NOC ISP Bus
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+ power-domains:
+ maxItems: 1
+ description:
+ ISP domain power
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - '#clock-cells'
+ - '#reset-cells'
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+ #include <dt-bindings/power/starfive,jh7110-pmu.h>
+ #include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+ ispcrg: clock-controller@19810000 {
+ compatible = "starfive,jh7110-ispcrg";
+ reg = <0x19810000 0x10000>;
+ clocks = <&syscrg JH7110_SYSCLK_ISP_TOP_CORE>,
+ <&syscrg JH7110_SYSCLK_ISP_TOP_AXI>,
+ <&syscrg JH7110_SYSCLK_NOC_BUS_ISP_AXI>,
+ <&dvp_clk>;
+ clock-names = "isp_top_core", "isp_top_axi",
+ "noc_bus_isp_axi", "dvp_clk";
+ resets = <&syscrg JH7110_SYSRST_ISP_TOP>,
+ <&syscrg JH7110_SYSRST_ISP_TOP_AXI>,
+ <&syscrg JH7110_SYSRST_NOC_BUS_ISP_AXI>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ power-domains = <&pwrc JH7110_PD_ISP>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml
new file mode 100644
index 0000000..be8300c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 PLL Clock Generator
+
+description:
+ These PLLs are high speed, low jitter frequency synthesizers in the JH7110.
+ Each PLL works in integer mode or fraction mode, with configuration
+ registers in the sys syscon. So the PLLs node should be a child of
+ SYS-SYSCON node.
+ The formula for calculating frequency is
+ Fvco = Fref * (NI + NF) / M / Q1
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-pll
+
+ clocks:
+ maxItems: 1
+ description: Main Oscillator (24 MHz)
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+required:
+ - compatible
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller {
+ compatible = "starfive,jh7110-pll";
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml
new file mode 100644
index 0000000..b64ccd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-stgcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 System-Top-Group Clock and Reset Generator
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-stgcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Main Oscillator (24 MHz)
+ - description: HIFI4 core
+ - description: STG AXI/AHB
+ - description: USB (125 MHz)
+ - description: CPU Bus
+ - description: HIFI4 Axi
+ - description: NOC STG Bus
+ - description: APB Bus
+
+ clock-names:
+ items:
+ - const: osc
+ - const: hifi4_core
+ - const: stg_axiahb
+ - const: usb_125m
+ - const: cpu_bus
+ - const: hifi4_axi
+ - const: nocstg_bus
+ - const: apb_bus
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+
+ stgcrg: clock-controller@10230000 {
+ compatible = "starfive,jh7110-stgcrg";
+ reg = <0x10230000 0x10000>;
+ clocks = <&osc>,
+ <&syscrg JH7110_SYSCLK_HIFI4_CORE>,
+ <&syscrg JH7110_SYSCLK_STG_AXIAHB>,
+ <&syscrg JH7110_SYSCLK_USB_125M>,
+ <&syscrg JH7110_SYSCLK_CPU_BUS>,
+ <&syscrg JH7110_SYSCLK_HIFI4_AXI>,
+ <&syscrg JH7110_SYSCLK_NOCSTG_BUS>,
+ <&syscrg JH7110_SYSCLK_APB_BUS>;
+ clock-names = "osc", "hifi4_core",
+ "stg_axiahb", "usb_125m",
+ "cpu_bus", "hifi4_axi",
+ "nocstg_bus", "apb_bus";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml
index 84373ae..5ba0a88 100644
--- a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml
@@ -27,6 +27,9 @@
- description: External I2S RX left/right channel clock
- description: External TDM clock
- description: External audio master clock
+ - description: PLL0
+ - description: PLL1
+ - description: PLL2
- items:
- description: Main Oscillator (24 MHz)
@@ -38,6 +41,9 @@
- description: External I2S RX left/right channel clock
- description: External TDM clock
- description: External audio master clock
+ - description: PLL0
+ - description: PLL1
+ - description: PLL2
clock-names:
oneOf:
@@ -52,6 +58,9 @@
- const: i2srx_lrck_ext
- const: tdm_ext
- const: mclk_ext
+ - const: pll0_out
+ - const: pll1_out
+ - const: pll2_out
- items:
- const: osc
@@ -63,6 +72,9 @@
- const: i2srx_lrck_ext
- const: tdm_ext
- const: mclk_ext
+ - const: pll0_out
+ - const: pll1_out
+ - const: pll2_out
'#clock-cells':
const: 1
@@ -93,12 +105,14 @@
<&gmac1_rgmii_rxin>,
<&i2stx_bclk_ext>, <&i2stx_lrck_ext>,
<&i2srx_bclk_ext>, <&i2srx_lrck_ext>,
- <&tdm_ext>, <&mclk_ext>;
+ <&tdm_ext>, <&mclk_ext>,
+ <&pllclk 0>, <&pllclk 1>, <&pllclk 2>;
clock-names = "osc", "gmac1_rmii_refin",
"gmac1_rgmii_rxin",
"i2stx_bclk_ext", "i2stx_lrck_ext",
"i2srx_bclk_ext", "i2srx_lrck_ext",
- "tdm_ext", "mclk_ext";
+ "tdm_ext", "mclk_ext",
+ "pll0_out", "pll1_out", "pll2_out";
#clock-cells = <1>;
#reset-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml
new file mode 100644
index 0000000..af77bd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-voutcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Video-Output Clock and Reset Generator
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-voutcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Vout Top core
+ - description: Vout Top Ahb
+ - description: Vout Top Axi
+ - description: Vout Top HDMI MCLK
+ - description: I2STX0 BCLK
+ - description: external HDMI pixel
+
+ clock-names:
+ items:
+ - const: vout_src
+ - const: vout_top_ahb
+ - const: vout_top_axi
+ - const: vout_top_hdmitx0_mclk
+ - const: i2stx0_bclk
+ - const: hdmitx0_pixelclk
+
+ resets:
+ maxItems: 1
+ description: Vout Top core
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+ power-domains:
+ maxItems: 1
+ description:
+ Vout domain power
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - '#clock-cells'
+ - '#reset-cells'
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+ #include <dt-bindings/power/starfive,jh7110-pmu.h>
+ #include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+ voutcrg: clock-controller@295C0000 {
+ compatible = "starfive,jh7110-voutcrg";
+ reg = <0x295C0000 0x10000>;
+ clocks = <&syscrg JH7110_SYSCLK_VOUT_SRC>,
+ <&syscrg JH7110_SYSCLK_VOUT_TOP_AHB>,
+ <&syscrg JH7110_SYSCLK_VOUT_TOP_AXI>,
+ <&syscrg JH7110_SYSCLK_VOUT_TOP_HDMITX0_MCLK>,
+ <&syscrg JH7110_SYSCLK_I2STX0_BCLK>,
+ <&hdmitx0_pixelclk>;
+ clock-names = "vout_src", "vout_top_ahb",
+ "vout_top_axi", "vout_top_hdmitx0_mclk",
+ "i2stx0_bclk", "hdmitx0_pixelclk";
+ resets = <&syscrg JH7110_SYSRST_VOUT_TOP_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ power-domains = <&pwrc JH7110_PD_VOUT>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.yaml b/Documentation/devicetree/bindings/clock/ti,cdce925.yaml
index a4ec8dd..95c1c6f 100644
--- a/Documentation/devicetree/bindings/clock/ti,cdce925.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,cdce925.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/ti,cdce925.yaml#
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
index 63d9763..0a9d6a4 100644
--- a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt
index e17425a..b33f641 100644
--- a/Documentation/devicetree/bindings/clock/ti/mux.txt
+++ b/Documentation/devicetree/bindings/clock/ti/mux.txt
@@ -8,7 +8,7 @@
gate or adjust the parent rate via a divider or multiplier.
By default the "clocks" property lists the parents in the same order
-as they are programmed into the regster. E.g:
+as they are programmed into the register. E.g:
clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt
index 63f9f1a..109ffa3 100644
--- a/Documentation/devicetree/bindings/clock/vf610-clock.txt
+++ b/Documentation/devicetree/bindings/clock/vf610-clock.txt
@@ -9,7 +9,7 @@
- clocks: list of clock identifiers which are external input clocks to the
given clock controller. Please refer the next section to find
the input clocks for a given controller.
-- clock-names: list of names of clocks which are exteral input clocks to the
+- clock-names: list of names of clocks which are external input clocks to the
given clock controller.
Input clocks for top clock controller:
diff --git a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
index 5cbb34d..1ba687d 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
@@ -14,11 +14,16 @@
reads required input clock frequencies from the devicetree and acts as clock
provider for all clock consumers of PS clocks.
-select: false
-
properties:
compatible:
- const: xlnx,versal-clk
+ oneOf:
+ - enum:
+ - xlnx,versal-clk
+ - xlnx,zynqmp-clk
+ - items:
+ - enum:
+ - xlnx,versal-net-clk
+ - const: xlnx,versal-clk
"#clock-cells":
const: 1
@@ -26,16 +31,12 @@
clocks:
description: List of clock specifiers which are external input
clocks to the given clock controller.
- items:
- - description: reference clock
- - description: alternate reference clock
- - description: alternate reference clock for programmable logic
+ minItems: 3
+ maxItems: 8
clock-names:
- items:
- - const: ref
- - const: alt_ref
- - const: pl_alt_ref
+ minItems: 3
+ maxItems: 8
required:
- compatible
@@ -45,6 +46,61 @@
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,versal-clk
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: reference clock
+ - description: alternate reference clock
+ - description: alternate reference clock for programmable logic
+
+ clock-names:
+ items:
+ - const: ref
+ - const: alt_ref
+ - const: pl_alt_ref
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-clk
+
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ items:
+ - description: PS reference clock
+ - description: reference clock for video system
+ - description: alternative PS reference clock
+ - description: auxiliary reference clock
+ - description: transceiver reference clock
+ - description: (E)MIO clock source (Optional clock)
+ - description: GEM emio clock (Optional clock)
+ - description: Watchdog external clock (Optional clock)
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: pss_ref_clk
+ - const: video_clk
+ - const: pss_alt_ref_clk
+ - const: aux_ref_clk
+ - const: gt_crx_ref_clk
+ - pattern: "^mio_clk[00-77]+.*$"
+ - pattern: "gem[0-3]+_emio_clk.*$"
+ - pattern: "swdt[0-1]+_ext_clk.*$"
+
examples:
- |
firmware {
@@ -59,4 +115,13 @@
};
};
};
+
+ clock-controller {
+ #clock-cells = <1>;
+ compatible = "xlnx,zynqmp-clk";
+ clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>,
+ <&aux_ref_clk>, <>_crx_ref_clk>;
+ clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk",
+ "aux_ref_clk", "gt_crx_ref_clk";
+ };
...
diff --git a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
deleted file mode 100644
index 391ee1a6..0000000
--- a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
+++ /dev/null
@@ -1,63 +0,0 @@
---------------------------------------------------------------------------
-Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
-Zynq MPSoC firmware interface
---------------------------------------------------------------------------
-The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
-tree. It reads required input clock frequencies from the devicetree and acts
-as clock provider for all clock consumers of PS clocks.
-
-See clock_bindings.txt for more information on the generic clock bindings.
-
-Required properties:
- - #clock-cells: Must be 1
- - compatible: Must contain: "xlnx,zynqmp-clk"
- - clocks: List of clock specifiers which are external input
- clocks to the given clock controller. Please refer
- the next section to find the input clocks for a
- given controller.
- - clock-names: List of clock names which are exteral input clocks
- to the given clock controller. Please refer to the
- clock bindings for more details.
-
-Input clocks for zynqmp Ultrascale+ clock controller:
-
-The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
-inputs. These required clock inputs are:
- - pss_ref_clk (PS reference clock)
- - video_clk (reference clock for video system )
- - pss_alt_ref_clk (alternative PS reference clock)
- - aux_ref_clk
- - gt_crx_ref_clk (transceiver reference clock)
-
-The following strings are optional parameters to the 'clock-names' property in
-order to provide an optional (E)MIO clock source:
- - swdt0_ext_clk
- - swdt1_ext_clk
- - gem0_emio_clk
- - gem1_emio_clk
- - gem2_emio_clk
- - gem3_emio_clk
- - mio_clk_XX # with XX = 00..77
- - mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51
-
-
-Output clocks are registered based on clock information received
-from firmware. Output clocks indexes are mentioned in
-include/dt-bindings/clock/xlnx-zynqmp-clk.h.
-
--------
-Example
--------
-
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- compatible = "xlnx,zynqmp-firmware";
- method = "smc";
- zynqmp_clk: clock-controller {
- #clock-cells = <1>;
- compatible = "xlnx,zynqmp-clk";
- clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>;
- clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 1c4d3eb..7c8a3e8 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -30,6 +30,9 @@
- const: samsung,usb-connector-11pin
- const: usb-b-connector
+ reg:
+ maxItems: 1
+
label:
description: Symbolic name for the connector.
@@ -224,13 +227,13 @@
state as defined in 7.4.2 Sink Electrical Parameters of USB Power Delivery Specification
Revision 3.0, Version 1.2. When the property is set, the port requests pSnkStby(2.5W -
5V@500mA) upon entering SNK_DISCOVERY(instead of 3A or the 1.5A, Rp current advertised, during
- SNK_DISCOVERY) and the actual currrent limit after reception of PS_Ready for PD link or during
+ SNK_DISCOVERY) and the actual current limit after reception of PS_Ready for PD link or during
SNK_READY for non-pd link.
type: boolean
dependencies:
- sink-vdos-v1: [ 'sink-vdos' ]
- sink-vdos: [ 'sink-vdos-v1' ]
+ sink-vdos-v1: [ sink-vdos ]
+ sink-vdos: [ sink-vdos-v1 ]
required:
- compatible
@@ -264,7 +267,7 @@
- typec-power-opmode
- new-source-frs-typec-current
-additionalProperties: true
+additionalProperties: false
examples:
# Micro-USB connector with HS lines routed via controller (MUIC).
diff --git a/Documentation/devicetree/bindings/cpu/nvidia,tegra186-ccplex-cluster.yaml b/Documentation/devicetree/bindings/cpu/nvidia,tegra186-ccplex-cluster.yaml
new file mode 100644
index 0000000..16a44897
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpu/nvidia,tegra186-ccplex-cluster.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpu/nvidia,tegra186-ccplex-cluster.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra186 CCPLEX Cluster
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra186-ccplex-cluster
+
+ reg:
+ maxItems: 1
+
+ nvidia,bpmp:
+ description: phandle to the BPMP used to query CPU frequency tables
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - nvidia,bpmp
+
+examples:
+ - |
+ ccplex@e000000 {
+ compatible = "nvidia,tegra186-ccplex-cluster";
+ reg = <0x0e000000 0x400000>;
+ nvidia,bpmp = <&bpmp>;
+ };
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
index a6b3bb8..c1d225f 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
@@ -49,6 +49,7 @@
- description: Frequency domain 0 register region
- description: Frequency domain 1 register region
- description: Frequency domain 2 register region
+ - description: Frequency domain 3 register region
reg-names:
minItems: 1
@@ -56,6 +57,7 @@
- const: freq-domain0
- const: freq-domain1
- const: freq-domain2
+ - const: freq-domain3
clocks:
items:
@@ -69,7 +71,7 @@
interrupts:
minItems: 1
- maxItems: 3
+ maxItems: 4
interrupt-names:
minItems: 1
@@ -77,6 +79,7 @@
- const: dcvsh-irq-0
- const: dcvsh-irq-1
- const: dcvsh-irq-2
+ - const: dcvsh-irq-3
'#freq-domain-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
deleted file mode 100644
index 1758051..0000000
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-TI CPUFreq and OPP bindings
-================================
-
-Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
-families support different OPPs depending on the silicon variant in use.
-The ti-cpufreq driver can use revision and an efuse value from the SoC to
-provide the OPP framework with supported hardware information. This is
-used to determine which OPPs from the operating-points-v2 table get enabled
-when it is parsed by the OPP framework.
-
-Required properties:
---------------------
-In 'cpus' nodes:
-- operating-points-v2: Phandle to the operating-points-v2 table to use.
-
-In 'operating-points-v2' table:
-- compatible: Should be
- - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx,
- omap34xx, omap36xx and am3517 SoCs
-- syscon: A phandle pointing to a syscon node representing the control module
- register space of the SoC.
-
-Optional properties:
---------------------
-- "vdd-supply", "vbb-supply": to define two regulators for dra7xx
-- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx
-
-For each opp entry in 'operating-points-v2' table:
-- opp-supported-hw: Two bitfields indicating:
- 1. Which revision of the SoC the OPP is supported by
- 2. Which eFuse bits indicate this OPP is available
-
- A bitwise AND is performed against these values and if any bit
- matches, the OPP gets enabled.
-
-Example:
---------
-
-/* From arch/arm/boot/dts/am33xx.dtsi */
-cpus {
- #address-cells = <1>;
- #size-cells = <0>;
- cpu@0 {
- compatible = "arm,cortex-a8";
- device_type = "cpu";
- reg = <0>;
-
- operating-points-v2 = <&cpu0_opp_table>;
-
- clocks = <&dpll_mpu_ck>;
- clock-names = "cpu";
-
- clock-latency = <300000>; /* From omap-cpufreq driver */
- };
-};
-
-/*
- * cpu0 has different OPPs depending on SoC revision and some on revisions
- * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
- */
-cpu0_opp_table: opp-table {
- compatible = "operating-points-v2-ti-cpu";
- syscon = <&scm_conf>;
-
- /*
- * The three following nodes are marked with opp-suspend
- * because they can not be enabled simultaneously on a
- * single SoC.
- */
- opp50-300000000 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <950000 931000 969000>;
- opp-supported-hw = <0x06 0x0010>;
- opp-suspend;
- };
-
- opp100-275000000 {
- opp-hz = /bits/ 64 <275000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x01 0x00FF>;
- opp-suspend;
- };
-
- opp100-300000000 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x06 0x0020>;
- opp-suspend;
- };
-
- opp100-500000000 {
- opp-hz = /bits/ 64 <500000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- opp100-600000000 {
- opp-hz = /bits/ 64 <600000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x06 0x0040>;
- };
-
- opp120-600000000 {
- opp-hz = /bits/ 64 <600000000>;
- opp-microvolt = <1200000 1176000 1224000>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- opp120-720000000 {
- opp-hz = /bits/ 64 <720000000>;
- opp-microvolt = <1200000 1176000 1224000>;
- opp-supported-hw = <0x06 0x0080>;
- };
-
- oppturbo-720000000 {
- opp-hz = /bits/ 64 <720000000>;
- opp-microvolt = <1260000 1234800 1285200>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- oppturbo-800000000 {
- opp-hz = /bits/ 64 <800000000>;
- opp-microvolt = <1260000 1234800 1285200>;
- opp-supported-hw = <0x06 0x0100>;
- };
-
- oppnitro-1000000000 {
- opp-hz = /bits/ 64 <1000000000>;
- opp-microvolt = <1325000 1298500 1351500>;
- opp-supported-hw = <0x04 0x0200>;
- };
-};
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index 92e1d76..7da9aa8 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -13,6 +13,7 @@
compatible:
items:
- enum:
+ - qcom,sm8450-inline-crypto-engine
- qcom,sm8550-inline-crypto-engine
- const: qcom,inline-crypto-engine
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index bb82806..8e665d9 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -34,6 +34,7 @@
- enum:
- qcom,ipq6018-qce
- qcom,ipq8074-qce
+ - qcom,ipq9574-qce
- qcom,msm8996-qce
- qcom,qcm2290-qce
- qcom,sdm845-qce
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
index b767ec7..ac48076 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -20,6 +20,7 @@
- stericsson,ux500-hash
- st,stm32f456-hash
- st,stm32f756-hash
+ - st,stm32mp13-hash
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
index 77ec8bc..ff10a08 100644
--- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
+++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/ti,sa2ul.yaml#
@@ -66,10 +66,22 @@
required:
- compatible
- reg
- - power-domains
- dmas
- dma-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am62-sa3ul
+ then:
+ properties:
+ power-domains: false
+ else:
+ required:
+ - power-domains
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml
index e300df4b..d27dcb2 100644
--- a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml
+++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml
@@ -18,7 +18,7 @@
each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC). The
Exynos PPMU driver uses the devfreq-event class to provide event data to
various devfreq devices. The devfreq devices would use the event data when
- derterming the current state of each IP.
+ determining the current state of each IP.
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
index 0398aec..923aea2 100644
--- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
@@ -12,7 +12,7 @@
Required children nodes:
Children nodes are encoding available output ports and their connections
- to external devices using the OF graph reprensentation (see ../graph.txt).
+ to external devices using the OF graph representation (see ../graph.txt).
At least one port node is required.
Optional properties in grandchild nodes:
diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
index 0b51c64..8747b95 100644
--- a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
@@ -11,7 +11,7 @@
description: |
This document defines device tree properties for the Synopsys DesignWare MIPI
- DSI host controller. It doesn't constitue a device tree binding specification
+ DSI host controller. It doesn't constitute a device tree binding specification
by itself but is meant to be referenced by platform-specific device tree
bindings.
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index 0521261..ae894d9 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -49,6 +49,9 @@
description: |
OF device-tree gpio specification for RSTX pin(active low system reset)
+ interrupts:
+ maxItems: 1
+
toshiba,hpd-pin:
$ref: /schemas/types.yaml#/definitions/uint32
enum:
diff --git a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
index 0ab5f06..84c75f8 100644
--- a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
+++ b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
@@ -1,4 +1,4 @@
-* Currus Logic CLPS711X Framebuffer
+* Cirrus Logic CLPS711X Framebuffer
Required properties:
- compatible: Shall contain "cirrus,ep7209-fb".
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 7a7cf3f..f125589 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -28,6 +28,7 @@
- qcom,sm8350-dp
- items:
- enum:
+ - qcom,sm8250-dp
- qcom,sm8450-dp
- qcom,sm8550-dp
- const: qcom,sm8350-dp
@@ -79,7 +80,8 @@
operating-points-v2: true
- opp-table: true
+ opp-table:
+ type: object
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 01848bd..c6dbab6 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml#
@@ -27,6 +27,7 @@
- qcom,sdm660-dsi-ctrl
- qcom,sdm845-dsi-ctrl
- qcom,sm6115-dsi-ctrl
+ - qcom,sm6125-dsi-ctrl
- qcom,sm6350-dsi-ctrl
- qcom,sm6375-dsi-ctrl
- qcom,sm8150-dsi-ctrl
@@ -166,6 +167,10 @@
description:
Phandle to vdd regulator device node
+ refgen-supply:
+ description:
+ Phandle to REFGEN regulator device node
+
vcca-supply:
description:
Phandle to vdd regulator device node
@@ -301,6 +306,7 @@
contains:
enum:
- qcom,msm8998-dsi-ctrl
+ - qcom,sm6125-dsi-ctrl
- qcom,sm6350-dsi-ctrl
then:
properties:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
index e6b00d73..69d1386 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
index a43e11d..52bbe13 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml#
@@ -19,6 +19,7 @@
- qcom,dsi-phy-14nm-2290
- qcom,dsi-phy-14nm-660
- qcom,dsi-phy-14nm-8953
+ - qcom,sm6125-dsi-phy-14nm
reg:
items:
@@ -35,6 +36,16 @@
vcca-supply:
description: Phandle to vcca regulator device node.
+ power-domains:
+ description:
+ A phandle and PM domain specifier for an optional power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing the power domain's performance point.
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
index 9c1f914..7e6687c 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
index 62fb3e4..288d8ba 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
index 8e9031b..dd66195 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-7nm.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
index 0f6f088..6b57ce4 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index 58ca891..56b9b24 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -15,6 +15,12 @@
oneOf:
- description: |
The driver is parsing the compat string for Adreno to
+ figure out the chip-id.
+ items:
+ - pattern: '^qcom,adreno-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]$'
+ - const: qcom,adreno
+ - description: |
+ The driver is parsing the compat string for Adreno to
figure out the gpu-id and patch level.
items:
- pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$'
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
index ccd7d64..f69196e 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/mdss-common.yaml#
@@ -77,6 +77,12 @@
items:
- description: MDSS_CORE reset
+ memory-region:
+ maxItems: 1
+ description:
+ Phandle to a node describing a reserved framebuffer memory region.
+ For example, the splash memory region set up by the bootloader.
+
required:
- reg
- reg-names
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
index 2fe032d..91c774f 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,mdp5.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
index db9f07c..0999ea0 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,mdss.yaml#
@@ -11,7 +11,7 @@
- Rob Clark <robdclark@gmail.com>
description:
- This is the bindings documentation for the Mobile Display Subsytem(MDSS) that
+ This is the bindings documentation for the Mobile Display Subsystem(MDSS) that
encapsulates sub-blocks like MDP5, DSI, HDMI, eDP, etc.
properties:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
index 8d3cd46..d5a64c8 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,msm8998-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
index 3c2b6ed..e320ab1 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,msm8998-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
index 414f4e7..be6cd8a 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index 2995b84..4184b84 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
index 630b114..8137618 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-dpu.yaml#
@@ -15,6 +15,7 @@
compatible:
enum:
- qcom,sc7180-dpu
+ - qcom,sm6125-dpu
- qcom,sm6350-dpu
- qcom,sm6375-dpu
@@ -63,7 +64,9 @@
- if:
properties:
compatible:
- const: qcom,sm6375-dpu
+ enum:
+ - qcom,sm6375-dpu
+ - qcom,sm6125-dpu
then:
properties:
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
index 42ef06e..3b9c103 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
index 26dc073..b0fbe86 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sc7280-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
index 078e1d1..43500da 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sc7280-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml
index f2c8e16..d19e3be 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
index c239544..db680fb 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
index 0f7765d..b917064 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sdm845-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
index 6ecb009..d6d7ac1 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sdm845-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
index bf62c2f..510eb6c 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm6115-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
index b9f8308..17221b6 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm6115-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
new file mode 100644
index 0000000..57f0e36
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6125-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6125 Display MDSS
+
+maintainers:
+ - Marijn Suijten <marijn.suijten@somainline.org>
+
+description:
+ SM6125 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6125-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm6125-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6125-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm6125-dsi-phy-14nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm6125.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6125.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@5e00000 {
+ compatible = "qcom,sm6125-mdss";
+ reg = <0x05e00000 0x1000>;
+ reg-names = "mdss";
+
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ iommus = <&apps_smmu 0x400 0x0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@5e01000 {
+ compatible = "qcom,sm6125-dpu";
+ reg = <0x05e01000 0x83208>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&gcc GCC_DISP_THROTTLE_CORE_CLK>;
+ clock-names = "bus",
+ "iface",
+ "rot",
+ "lut",
+ "core",
+ "vsync",
+ "throttle";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd SM6125_VDDCX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi@5e94000 {
+ compatible = "qcom,sm6125-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x05e94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd SM6125_VDDCX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ phy@5e94400 {
+ compatible = "qcom,sm6125-dsi-phy-14nm";
+ reg = <0x05e94400 0x100>,
+ <0x05e94500 0x300>,
+ <0x05e94800 0x188>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface",
+ "ref";
+
+ required-opps = <&rpmpd_opp_nom>;
+ power-domains = <&rpmpd SM6125_VDDMX>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
index ed0ad19..db255b1 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml#
@@ -131,13 +131,6 @@
remote-endpoint = <&dsi0_in>;
};
};
-
- port@1 {
- reg = <1>;
- dpu_intf2_out: endpoint {
- remote-endpoint = <&dsi1_in>;
- };
- };
};
};
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
index 76369a4..30d36ff 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm6375-mdss.yaml#
@@ -132,13 +132,6 @@
remote-endpoint = <&dsi0_in>;
};
};
-
- port@1 {
- reg = <1>;
- dpu_intf2_out: endpoint {
- remote-endpoint = <&dsi1_in>;
- };
- };
};
};
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
index 2b3f3fe..13146b3 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8150-dpu.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
index 5182e95..54cdaa8 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8150-mdss.yaml#
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml
index 687c8c1..ffa5047 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8250-dpu.yaml#
@@ -54,7 +54,7 @@
#include <dt-bindings/clock/qcom,gcc-sm8250.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8250.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-controller@ae01000 {
compatible = "qcom,sm8250-dpu";
@@ -72,7 +72,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
index 368d3db..e887f03 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8250-mdss.yaml#
@@ -76,7 +76,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8250.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-subsystem@ae00000 {
compatible = "qcom,sm8250-mdss";
@@ -121,7 +121,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
@@ -196,7 +196,7 @@
assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&dsi0_phy>;
phy-names = "dsi";
@@ -286,7 +286,7 @@
assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&dsi1_phy>;
phy-names = "dsi";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml
index 1205003..96ef2d9 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8350-dpu.yaml#
@@ -51,7 +51,7 @@
#include <dt-bindings/clock/qcom,gcc-sm8350.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8350.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-controller@ae01000 {
compatible = "qcom,sm8350-dpu";
@@ -76,7 +76,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8350_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
index 79a226e..60d4aae 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8350-mdss.yaml#
@@ -52,6 +52,12 @@
compatible:
const: qcom,sm8350-dpu
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ const: qcom,sm8350-dp
+
"^dsi@[0-9a-f]+$":
type: object
properties:
@@ -75,7 +81,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8350.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-subsystem@ae00000 {
compatible = "qcom,sm8350-mdss";
@@ -128,7 +134,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8350_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
@@ -197,7 +203,7 @@
<&mdss_dsi0_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8350_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&mdss_dsi0_phy>;
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml
index 0d17ece..2a5d3da 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8450-dpu.yaml#
@@ -58,7 +58,7 @@
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8450.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-controller@ae01000 {
compatible = "qcom,sm8450-dpu";
@@ -83,7 +83,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
index f26eb56..bb22940 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8450-mdss.yaml#
@@ -42,6 +42,14 @@
compatible:
const: qcom,sm8450-dpu
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8450-dp
+ - const: qcom,sm8350-dp
+
"^dsi@[0-9a-f]+$":
type: object
properties:
@@ -68,7 +76,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8450.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-subsystem@ae00000 {
compatible = "qcom,sm8450-mdss";
@@ -122,7 +130,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
@@ -202,7 +210,7 @@
assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&dsi0_phy>;
phy-names = "dsi";
@@ -297,7 +305,7 @@
assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8450_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&dsi1_phy>;
phy-names = "dsi";
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml
index ff58a74..16a541f 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-dpu.yaml#
@@ -57,7 +57,7 @@
#include <dt-bindings/clock/qcom,sm8550-dispcc.h>
#include <dt-bindings/clock/qcom,sm8550-gcc.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-controller@ae01000 {
compatible = "qcom,sm8550-dpu";
@@ -82,7 +82,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8550_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml
index 887be33..48aea80 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-mdss.yaml#
@@ -42,6 +42,14 @@
compatible:
const: qcom,sm8550-dpu
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8550-dp
+ - const: qcom,sm8350-dp
+
"^dsi@[0-9a-f]+$":
type: object
properties:
@@ -68,7 +76,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
display-subsystem@ae00000 {
compatible = "qcom,sm8550-mdss";
@@ -122,7 +130,7 @@
assigned-clock-rates = <19200000>;
operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmhpd SM8550_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
interrupt-parent = <&mdss>;
interrupts = <0>;
@@ -197,7 +205,7 @@
assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8550_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&dsi0_phy>;
phy-names = "dsi";
@@ -286,7 +294,7 @@
assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
operating-points-v2 = <&dsi_opp_table>;
- power-domains = <&rpmhpd SM8550_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
phys = <&dsi1_phy>;
phy-names = "dsi";
diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
index 67682fe..2e8dbdb 100644
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -19,6 +19,9 @@
second port, therefore the ports must be marked accordingly (with either
dual-lvds-odd-pixels or dual-lvds-even-pixels).
+allOf:
+ - $ref: panel-common.yaml#
+
properties:
compatible:
items:
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
index 1b2a1ba..ffb3528 100644
--- a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/himax,hx8394.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
index c5d1df6..e7ab622 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
@@ -18,6 +18,7 @@
- enum:
- bananapi,lhr050h41
- feixin,k101-im2byl02
+ - tdo,tl050hdv35
- wanchanglong,w552946aba
- const: ilitek,ili9881c
diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
index a4b8569..74ff7729 100644
--- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
index 9f97598..7246379 100644
--- a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
+++ b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
@@ -20,7 +20,7 @@
The panel itself contains:
- AT24C16C EEPROM holding panel identification and timing requirements
- AR1021 resistive touch screen controller (optional)
- - FT5x6 capacitive touch screnn controller (optional)
+ - FT5x6 capacitive touch screen controller (optional)
- GT911/GT928 capacitive touch screen controller (optional)
The above chips share same I2C bus. The EEPROM is factory preprogrammed with
diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
index ad7d357..1e4f140 100644
--- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
+++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/orisetech,otm8009a.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index 5b38dc8..0a57a31 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -12,7 +12,7 @@
description: |
This document defines device tree properties common to several classes of
- display panels. It doesn't constitue a device tree binding specification by
+ display panels. It doesn't constitute a device tree binding specification by
itself but is meant to be referenced by device tree bindings.
When referenced from panel device tree bindings the properties defined in this
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
index 4a36aa6..f8dc992 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index 929fe04..9f10165 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -40,6 +40,12 @@
items:
- enum:
- auo,b101ew05
+ # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel
+ - chunghwa,claa070wp03xg
+ # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel
+ - hannstar,hsd101pww2
+ # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel
+ - hydis,hv070wx2-1e0
- tbs,a711-panel
- const: panel-lvds
diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
index 2f0238b..e808215 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
@@ -66,6 +66,7 @@
compatible:
items:
- enum:
+ - saef,sftc154b
- sainsmart18
- shineworld,lh133k
- const: panel-mipi-dbi-spi
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index 90c04cf..73674ba 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-simple-dsi.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 1d4936f..25b4589d 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -103,8 +103,6 @@
- cdtech,s070wv95-ct16
# Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel
- chefree,ch101olhlwh-002
- # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
- - chunghwa,claa070wp03xg
# Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
- chunghwa,claa101wa01a
# Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
@@ -168,8 +166,6 @@
- hannstar,hsd070pww1
# HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
- hannstar,hsd100pxn1
- # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel
- - hannstar,hsd101pww2
# Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
- hit,tx23d38vm0caa
# InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
@@ -196,6 +192,8 @@
- innolux,n116bge
# InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
- innolux,n125hce-gn1
+ # InnoLux 15.6" FHD (1920x1080) TFT LCD panel
+ - innolux,g156hce-l01
# InnoLux 15.6" WXGA TFT LCD panel
- innolux,n156bge-l21
# Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
index e8ce231..46fe101 100644
--- a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/raydium,rm68200.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
index 150e810..5ea7442 100644
--- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
index fa65563..ef162b5 100644
--- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
@@ -15,17 +15,26 @@
properties:
compatible:
- const: sitronix,st7789v
+ enum:
+ - edt,et028013dma
+ - inanbo,t28cp45tn89-v17
+ - jasonic,jt240mhqs-hwt-ek-e3
+ - sitronix,st7789v
reg: true
reset-gpios: true
power-supply: true
backlight: true
port: true
+ rotation: true
spi-cpha: true
spi-cpol: true
+ spi-rx-bus-width:
+ minimum: 0
+ maximum: 1
+
dc-gpios:
maxItems: 1
description: DCX pin, Display data/command selection pin in parallel interface
@@ -33,7 +42,6 @@
required:
- compatible
- reg
- - reset-gpios
- power-supply
unevaluatedProperties: false
@@ -52,6 +60,7 @@
reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>;
backlight = <&pwm_bl>;
power-supply = <&power>;
+ rotation = <180>;
spi-max-frequency = <100000>;
spi-cpol;
spi-cpha;
diff --git a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
new file mode 100644
index 0000000..d817f99
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/startek,kd070fhfid015.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Startek Electronic Technology Co. kd070fhfid015 7 inch TFT LCD panel
+
+maintainers:
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: startek,kd070fhfid015
+
+ enable-gpios: true
+
+ iovcc-supply:
+ description: Reference to the regulator powering the panel IO pins.
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ reset-gpios: true
+
+ port: true
+
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - enable-gpios
+ - iovcc-supply
+ - reg
+ - reset-gpios
+ - port
+ - power-supply
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "startek,kd070fhfid015";
+ reg = <0>;
+ enable-gpios = <&pio 67 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 20 GPIO_ACTIVE_HIGH>;
+ iovcc-supply = <&mt6357_vsim1_reg>;
+ power-supply = <&vsys_lcm_reg>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml
new file mode 100644
index 0000000..6ba3236
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,r66451.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox R66451 AMOLED DSI Panel
+
+maintainers:
+ - Jessica Zhang <quic_jesszhan@quicinc.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: visionox,r66451
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vddio-supply: true
+ vdd-supply: true
+ port: true
+ reset-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - vdd-supply
+ - reset-gpios
+ - port
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "visionox,r66451";
+ reg = <0>;
+ vddio-supply = <&vreg_l12c_1p8>;
+ vdd-supply = <&vreg_l13c_3p0>;
+
+ reset-gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
index 444ac2a..fa745a6 100644
--- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
+++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
index 84562a5..d5a8295 100644
--- a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
+++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/visionox,vtdr6130.yaml#
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
index fba4509..b60b904 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index 94bb5ef..20e2bd1 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -49,15 +49,15 @@
solomon,height:
$ref: /schemas/types.yaml#/definitions/uint32
- default: 16
description:
- Height in pixel of the screen driven by the controller
+ Height in pixel of the screen driven by the controller.
+ The default value is controller-dependent.
solomon,width:
$ref: /schemas/types.yaml#/definitions/uint32
- default: 96
description:
- Width in pixel of the screen driven by the controller
+ Width in pixel of the screen driven by the controller.
+ The default value is controller-dependent.
solomon,page-offset:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -157,6 +157,10 @@
const: sinowealth,sh1106
then:
properties:
+ width:
+ default: 132
+ height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -171,6 +175,10 @@
- solomon,ssd1305
then:
properties:
+ width:
+ default: 132
+ height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -185,6 +193,10 @@
- solomon,ssd1306
then:
properties:
+ width:
+ default: 128
+ height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -199,6 +211,10 @@
- solomon,ssd1307
then:
properties:
+ width:
+ default: 128
+ height:
+ default: 39
solomon,dclk-div:
default: 2
solomon,dclk-frq:
@@ -215,6 +231,10 @@
- solomon,ssd1309
then:
properties:
+ width:
+ default: 128
+ height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
index 70f0e45..6f2e224 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
@@ -97,7 +97,7 @@
# optional when driving an eDP output
nvidia,dpaux:
- description: phandle to a DispayPort AUX interface
+ description: phandle to a DisplayPort AUX interface
$ref: /schemas/types.yaml#/definitions/phandle
allOf:
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index b6b402f..ae09cd3 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -12,14 +12,18 @@
- Tomi Valkeinen <tomi.valkeinen@ti.com>
description: |
- The AM65x TI Keystone Display SubSystem with two output ports and
- two video planes. The first video port supports OLDI and the second
- supports DPI format. The fist plane is full video plane with all
- features and the second is a "lite plane" without scaling support.
+ The AM625 and AM65x TI Keystone Display SubSystem with two output
+ ports and two video planes. In AM65x DSS, the first video port
+ supports 1 OLDI TX and in AM625 DSS, the first video port output is
+ internally routed to 2 OLDI TXes. The second video port supports DPI
+ format. The first plane is full video plane with all features and the
+ second is a "lite plane" without scaling support.
properties:
compatible:
- const: ti,am65x-dss
+ enum:
+ - ti,am625-dss
+ - ti,am65x-dss
reg:
description:
@@ -80,7 +84,9 @@
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
- The DSS OLDI output port node form video port 1
+ For AM65x DSS, the OLDI output port node from video port 1.
+ For AM625 DSS, the internal DPI output port node from video
+ port 1.
port@1:
$ref: /schemas/graph.yaml#/properties/port
diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
index 510b7f2..76d649b 100644
--- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
@@ -3,7 +3,8 @@
* XDMA Controller
Required properties:
- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or
- "microchip,sama7g5-dma".
+ "microchip,sama7g5-dma" or
+ "microchip,sam9x7-dma", "atmel,sama5d4-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/brcm,bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
deleted file mode 100644
index b6a8cc0..0000000
--- a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-* BCM2835 DMA controller
-
-The BCM2835 DMA controller has 16 channels in total.
-Only the lower 13 channels have an associated IRQ.
-Some arbitrary channels are used by the firmware
-(1,3,6,7 in the current firmware version).
-The channels 0,2 and 3 have special functionality
-and should not be used by the driver.
-
-Required properties:
-- compatible: Should be "brcm,bcm2835-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain the DMA interrupts associated
- to the DMA channels in ascending order.
-- interrupt-names: Should contain the names of the interrupt
- in the form "dmaXX".
- Use "dma-shared-all" for the common interrupt line
- that is shared by all dma channels.
-- #dma-cells: Must be <1>, the cell in the dmas property of the
- client device represents the DREQ number.
-- brcm,dma-channel-mask: Bit mask representing the channels
- not used by the firmware in ascending order,
- i.e. first channel corresponds to LSB.
-
-Example:
-
-dma: dma@7e007000 {
- compatible = "brcm,bcm2835-dma";
- reg = <0x7e007000 0xf00>;
- interrupts = <1 16>,
- <1 17>,
- <1 18>,
- <1 19>,
- <1 20>,
- <1 21>,
- <1 22>,
- <1 23>,
- <1 24>,
- <1 25>,
- <1 26>,
- /* dma channel 11-14 share one irq */
- <1 27>,
- <1 27>,
- <1 27>,
- <1 27>,
- /* unused shared irq for all channels */
- <1 28>;
- interrupt-names = "dma0",
- "dma1",
- "dma2",
- "dma3",
- "dma4",
- "dma5",
- "dma6",
- "dma7",
- "dma8",
- "dma9",
- "dma10",
- "dma11",
- "dma12",
- "dma13",
- "dma14",
- "dma-shared-all";
-
- #dma-cells = <1>;
- brcm,dma-channel-mask = <0x7f35>;
-};
-
-
-DMA clients connected to the BCM2835 DMA controller must use the format
-described in the dma.txt file, using a two-cell specifier for each channel.
-
-Example:
-
-bcm2835_i2s: i2s@7e203000 {
- compatible = "brcm,bcm2835-i2s";
- reg = < 0x7e203000 0x24>;
- clocks = <&clocks BCM2835_CLOCK_PCM>;
-
- dmas = <&dma 2>,
- <&dma 3>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml
new file mode 100644
index 0000000..c9b9a54
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/brcm,bcm2835-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 DMA controller
+
+maintainers:
+ - Nicolas Saenz Julienne <nsaenz@kernel.org>
+
+description:
+ The BCM2835 DMA controller has 16 channels in total. Only the lower
+ 13 channels have an associated IRQ. Some arbitrary channels are used by the
+ VideoCore firmware (1,3,6,7 in the current firmware version). The channels
+ 0, 2 and 3 have special functionality and should not be used by the driver.
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm2835-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Should contain the DMA interrupts associated to the DMA channels in
+ ascending order.
+ minItems: 1
+ maxItems: 16
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 16
+
+ '#dma-cells':
+ description: The single cell represents the DREQ number.
+ const: 1
+
+ brcm,dma-channel-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bitmask of available DMA channels in ascending order that are
+ not reserved by firmware and are available to the
+ kernel. i.e. first channel corresponds to LSB.
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - brcm,dma-channel-mask
+
+examples:
+ - |
+ dma-controller@7e007000 {
+ compatible = "brcm,bcm2835-dma";
+ reg = <0x7e007000 0xf00>;
+ interrupts = <1 16>,
+ <1 17>,
+ <1 18>,
+ <1 19>,
+ <1 20>,
+ <1 21>,
+ <1 22>,
+ <1 23>,
+ <1 24>,
+ <1 25>,
+ <1 26>,
+ /* dma channel 11-14 share one irq */
+ <1 27>,
+ <1 27>,
+ <1 27>,
+ <1 27>,
+ /* unused shared irq for all channels */
+ <1 28>;
+ interrupt-names = "dma0",
+ "dma1",
+ "dma2",
+ "dma3",
+ "dma4",
+ "dma5",
+ "dma6",
+ "dma7",
+ "dma8",
+ "dma9",
+ "dma10",
+ "dma11",
+ "dma12",
+ "dma13",
+ "dma14",
+ "dma-shared-all";
+ #dma-cells = <1>;
+ brcm,dma-channel-mask = <0x7f35>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
index 5fd8fc6..437db0c 100644
--- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
+++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
@@ -21,32 +21,41 @@
- enum:
- fsl,vf610-edma
- fsl,imx7ulp-edma
+ - fsl,imx8qm-adma
+ - fsl,imx8qm-edma
+ - fsl,imx93-edma3
+ - fsl,imx93-edma4
- items:
- const: fsl,ls1028a-edma
- const: fsl,vf610-edma
reg:
- minItems: 2
+ minItems: 1
maxItems: 3
interrupts:
- minItems: 2
- maxItems: 17
+ minItems: 1
+ maxItems: 64
interrupt-names:
- minItems: 2
- maxItems: 17
+ minItems: 1
+ maxItems: 64
"#dma-cells":
- const: 2
+ enum:
+ - 2
+ - 3
dma-channels:
- const: 32
+ minItems: 1
+ maxItems: 64
clocks:
+ minItems: 1
maxItems: 2
clock-names:
+ minItems: 1
maxItems: 2
big-endian:
@@ -69,21 +78,52 @@
properties:
compatible:
contains:
+ enum:
+ - fsl,imx8qm-adma
+ - fsl,imx8qm-edma
+ - fsl,imx93-edma3
+ - fsl,imx93-edma4
+ then:
+ properties:
+ "#dma-cells":
+ const: 3
+ # It is not necessary to write the interrupt name for each channel.
+ # instead, you can simply maintain the sequential IRQ numbers as
+ # defined for the DMA channels.
+ interrupt-names: false
+ clock-names:
+ items:
+ - const: dma
+ clocks:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: fsl,vf610-edma
then:
properties:
+ clocks:
+ minItems: 2
clock-names:
items:
- const: dmamux0
- const: dmamux1
interrupts:
+ minItems: 2
maxItems: 2
interrupt-names:
items:
- const: edma-tx
- const: edma-err
reg:
+ minItems: 2
maxItems: 3
+ "#dma-cells":
+ const: 2
+ dma-channels:
+ const: 32
- if:
properties:
@@ -92,14 +132,22 @@
const: fsl,imx7ulp-edma
then:
properties:
+ clock:
+ minItems: 2
clock-names:
items:
- const: dma
- const: dmamux0
interrupts:
+ minItems: 2
maxItems: 17
reg:
+ minItems: 2
maxItems: 2
+ "#dma-cells":
+ const: 2
+ dma-channels:
+ const: 32
unevaluatedProperties: false
@@ -153,3 +201,47 @@
clock-names = "dma", "dmamux0";
clocks = <&pcc2 IMX7ULP_CLK_DMA1>, <&pcc2 IMX7ULP_CLK_DMA_MUX1>;
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx93-clock.h>
+
+ dma-controller@44000000 {
+ compatible = "fsl,imx93-edma3";
+ reg = <0x44000000 0x200000>;
+ #dma-cells = <3>;
+ dma-channels = <31>;
+ 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>,
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_EDMA1_GATE>;
+ clock-names = "dma";
+ };
diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
index 3740049..d9cca30 100644
--- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
+++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
@@ -68,7 +68,7 @@
$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
+ channel. These channels will only be assigned when explicitly
requested by a client. The primary use for this is channels 0 and
1, which can be configured to have special behaviour for NAND/BCH
when using programmable firmware.
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt
index c6908e7..447fb44 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt
@@ -2,7 +2,7 @@
Required properties:
- compatible: Should be "nvidia,<chip>-apbdma"
-- reg: Should contain DMA registers location and length. This shuld include
+- reg: Should contain DMA registers location and length. This should include
all of the per-channel registers.
- interrupts: Should contain all of the per-channel DMA interrupts.
- clocks: Must contain one entry, for the module clock.
diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
index f1ddcf6..3ad0d9b 100644
--- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
@@ -15,13 +15,19 @@
properties:
compatible:
- enum:
- # APQ8064, IPQ8064 and MSM8960
- - qcom,bam-v1.3.0
- # MSM8974, APQ8074 and APQ8084
- - qcom,bam-v1.4.0
- # MSM8916 and SDM845
- - qcom,bam-v1.7.0
+ oneOf:
+ - enum:
+ # APQ8064, IPQ8064 and MSM8960
+ - qcom,bam-v1.3.0
+ # MSM8974, APQ8074 and APQ8084
+ - qcom,bam-v1.4.0
+ # MSM8916, SDM630
+ - qcom,bam-v1.7.0
+ - items:
+ - enum:
+ # SDM845, SM6115, SM8150, SM8250 and QCM2290
+ - qcom,bam-v1.7.4
+ - const: qcom,bam-v1.7.0
clocks:
maxItems: 1
@@ -38,7 +44,7 @@
iommus:
minItems: 1
- maxItems: 4
+ maxItems: 6
num-channels:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -48,7 +54,7 @@
qcom,controlled-remotely:
type: boolean
description:
- Indicates that the bam is controlled by remote proccessor i.e. execution
+ Indicates that the bam is controlled by remote processor i.e. execution
environment.
qcom,ee:
@@ -81,6 +87,15 @@
- qcom,ee
- reg
+anyOf:
+ - required:
+ - qcom,powered-remotely
+ - required:
+ - qcom,controlled-remotely
+ - required:
+ - clocks
+ - clock-names
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
index 1e5752b..7b94d24 100644
--- a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
+++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
@@ -148,7 +148,7 @@
memcpy-channels:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: Array of u32 elements indicating which channels on the DMA
- engine are elegible for memcpy transfers
+ engine are eligible for memcpy transfers
required:
- "#dma-cells"
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index d1700a5..590d194 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -49,6 +49,12 @@
register as configured in h/w. Takes values {8...26}. If the property
is missing or invalid then the default value 23 is used. This is the
maximum value that is supported by all IP versions.
+
+Optional properties for AXI DMA:
+- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP.
+- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from
+ 0-255. Setting this value to zero disables the delay timer interrupt.
+ 1 timeout interval = 125 * clock period of SG clock.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml
index 84af0d5..9813948 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/eeprom/at24.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/eeprom/at24.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I2C EEPROMs compatible with Atmel's AT24
@@ -102,6 +102,9 @@
# These are special cases that don't conform to the above pattern.
# Each requires a standard at24 model as fallback.
- items:
+ - const: belling,bl24c16a
+ - const: atmel,24c16
+ - items:
- enum:
- rohm,br24g01
- rohm,br24t01
diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml
index 0e31bb3..1715b0c 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/eeprom/at25.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/eeprom/at25.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SPI EEPROMs or FRAMs compatible with Atmel's AT25
diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml
index 12896054..55800fb 100644
--- a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml
+++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml
@@ -23,6 +23,7 @@
connector:
$ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
ports:
$ref: /schemas/graph.yaml#/properties/ports
diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
index 2c8cf6a..6b80518c 100644
--- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
+++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Technologies, Inc. PM8941 USB ID Extcon device
maintainers:
- - Guru Das Srinagesh <gurus@codeaurora.org>
+ - Guru Das Srinagesh <quic_gurus@quicinc.com>
description: |
Some Qualcomm PMICs have a "misc" module that can be used to detect when
diff --git a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
index 7a224b2f..7ef2d9b 100644
--- a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
+++ b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
@@ -27,6 +27,10 @@
description: I2C slave address of the device. Usually 0x25 for SM5502
and SM5703, 0x14 for SM5504.
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
index 9a785bb..e6bed7d 100644
--- a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
+++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx Network Processing Engine
diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
index 833c07f..c43d17f 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
@@ -57,8 +57,11 @@
"#address-cells" or "#size-cells" property.
The shared memory area for the IPC TX and RX between CPU and BPMP are
- predefined and work on top of sysram, which is an SRAM inside the
- chip. See ".../sram/sram.yaml" for the bindings.
+ predefined and work on top of either sysram, which is an SRAM inside the
+ chip, or in normal SDRAM.
+ See ".../sram/sram.yaml" for the bindings for the SRAM case.
+ See "../reserved-memory/nvidia,tegra264-bpmp-shmem.yaml" for bindings for
+ the SDRAM case.
properties:
compatible:
@@ -81,6 +84,11 @@
minItems: 2
maxItems: 2
+ memory-region:
+ description: phandle to reserved memory region used for IPC between
+ CPU-NS and BPMP.
+ maxItems: 1
+
"#clock-cells":
const: 1
@@ -115,10 +123,15 @@
additionalProperties: false
+oneOf:
+ - required:
+ - memory-region
+ - required:
+ - shmem
+
required:
- compatible
- mboxes
- - shmem
- "#clock-cells"
- "#power-domain-cells"
- "#reset-cells"
@@ -165,8 +178,7 @@
<&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
interconnect-names = "read", "write", "dma-mem", "dma-write";
iommus = <&smmu TEGRA186_SID_BPMP>;
- mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB
- TEGRA_HSP_DB_MASTER_BPMP>;
+ mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
shmem = <&cpu_bpmp_tx>, <&cpu_bpmp_rx>;
#clock-cells = <1>;
#power-domain-cells = <1>;
@@ -184,3 +196,20 @@
#thermal-sensor-cells = <1>;
};
};
+
+ - |
+ #include <dt-bindings/mailbox/tegra186-hsp.h>
+
+ bpmp {
+ compatible = "nvidia,tegra186-bpmp";
+ interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
+ interconnect-names = "read", "write", "dma-mem", "dma-write";
+ mboxes = <&hsp_top1 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
+ memory-region = <&dram_cpu_bpmp_mail>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index bdbee58..4233ea8 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -176,6 +176,7 @@
contains:
enum:
- qcom,scm-qdu1000
+ - qcom,scm-sc8280xp
- qcom,scm-sm8450
- qcom,scm-sm8550
then:
diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index 910bebe..8228644 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -38,6 +38,9 @@
- smc
- hvc
+ "#power-domain-cells":
+ const: 1
+
versal_fpga:
$ref: /schemas/fpga/xlnx,versal-fpga.yaml#
description: Compatible of the FPGA device.
@@ -66,6 +69,17 @@
examples:
- |
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+ firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ #power-domain-cells = <1>;
+ };
+ };
+
+ sata {
+ power-domains = <&zynqmp_firmware PD_SATA>;
+ };
+
versal-firmware {
compatible = "xlnx,versal-firmware";
method = "smc";
diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index 6694ef2..528df8a 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -63,7 +63,7 @@
will be disabled.
* During Partial Reconfiguration of a specific region, that region's bridge
will be used to gate the busses. Traffic to other regions is not affected.
- * In some implementations, the FPGA Manager transparantly handles gating the
+ * In some implementations, the FPGA Manager transparently handles gating the
buses, eliminating the need to show the hardware FPGA bridges in the
device tree.
* An FPGA image may create a set of reprogrammable regions, each having its
@@ -466,7 +466,7 @@
constraints required to make partial reconfiguration work[1] [2] [3], but a few
deserve quick mention.
-A persona must have boundary connections that line up with those of the partion
+A persona must have boundary connections that line up with those of the partition
or region it is designed to go into.
During programming, transactions through those connections must be stopped and
diff --git a/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml b/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml
new file mode 100644
index 0000000..442cecd
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/ibm,i2cr-fsi-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM I2C Responder virtual FSI master
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description: |
+ The I2C Responder (I2CR) is a an I2C device that's connected to an FSI CFAM
+ (see fsi.txt). The I2CR translates I2C bus operations to FSI CFAM reads and
+ writes or SCOM operations, thereby acting as an FSI master.
+
+properties:
+ compatible:
+ enum:
+ - ibm,i2cr-fsi-master
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml b/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml
new file mode 100644
index 0000000..25b3198
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/adi,ds4520-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DS4520 I2C GPIO expander
+
+maintainers:
+ - Okan Sahin <okan.sahin@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - adi,ds4520-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ ngpios:
+ minimum: 1
+ maximum: 9
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - ngpios
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@50 {
+ compatible = "adi,ds4520-gpio";
+ reg = <0x50>;
+ ngpios = <9>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt
deleted file mode 100644
index 4a63bc9..0000000
--- a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Broadcom Kona Family GPIO
-=========================
-
-This GPIO driver is used in the following Broadcom SoCs:
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
-
-The Broadcom GPIO Controller IP can be configured prior to synthesis to
-support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
-GPIO controller only supports edge, not level, triggering of interrupts.
-
-Required properties
--------------------
-
-- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio"
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The interrupt outputs from the controller. There is one GPIO
- interrupt per GPIO bank. The number of interrupts listed depends on the
- number of GPIO banks on the SoC. The interrupts must be ordered by bank,
- starting with bank 0. There is always a 1:1 mapping between banks and
- IRQs.
-- #gpio-cells: Should be <2>. The first cell is the pin number, the second
- cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted)
- See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
-- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The
- second cell is used to specify flags. The following subset of flags is
- supported:
- - trigger type (bits[1:0]):
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 3 = low-to-high or high-to-low edge triggered
- Valid values are 1, 2, 3
- See also .../devicetree/bindings/interrupt-controller/interrupts.txt.
-- gpio-controller: Marks the device node as a GPIO controller.
-- interrupt-controller: Marks the device node as an interrupt controller.
-
-Example:
- gpio: gpio@35003000 {
- compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
- reg = <0x35003000 0x800>;
- interrupts =
- <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
- #gpio-cells = <2>;
- #interrupt-cells = <2>;
- gpio-controller;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml
new file mode 100644
index 0000000..296fdd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/brcm,kona-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family GPIO controller
+
+description:
+ The Broadcom GPIO Controller IP can be configured prior to synthesis to
+ support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
+ GPIO controller only supports edge, not level, triggering of interrupts.
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm11351-gpio
+ - brcm,bcm21664-gpio
+ - brcm,bcm23550-gpio
+ - const: brcm,kona-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 4
+ maxItems: 6
+ description:
+ The interrupt outputs from the controller. There is one GPIO interrupt
+ per GPIO bank. The number of interrupts listed depends on the number of
+ GPIO banks on the SoC. The interrupts must be ordered by bank, starting
+ with bank 0. There is always a 1:1 mapping between banks and IRQs.
+
+ '#gpio-cells':
+ const: 2
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#gpio-cells'
+ - '#interrupt-cells'
+ - gpio-controller
+ - interrupt-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm11351-gpio
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm21664-gpio
+ - brcm,bcm23550-gpio
+ then:
+ properties:
+ interrupts:
+ maxItems: 4
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio@35003000 {
+ compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
+ reg = <0x35003000 0x800>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
index ae18603..d0ca2af 100644
--- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
@@ -32,10 +32,12 @@
- fsl,imx6sx-gpio
- fsl,imx6ul-gpio
- fsl,imx7d-gpio
+ - fsl,imx8dxl-gpio
- fsl,imx8mm-gpio
- fsl,imx8mn-gpio
- fsl,imx8mp-gpio
- fsl,imx8mq-gpio
+ - fsl,imx8qm-gpio
- fsl,imx8qxp-gpio
- fsl,imxrt1050-gpio
- fsl,imxrt1170-gpio
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
index fa11614..99febb8 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
@@ -66,6 +66,7 @@
- ti,tca6408
- ti,tca6416
- ti,tca6424
+ - ti,tca9538
- ti,tca9539
- ti,tca9554
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
index e90fb98..7ddf292 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
@@ -27,7 +27,7 @@
- gpio-controller: Marks the device node as a GPIO controller.
- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
- interrupt-cells: Should be two.
- - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
+ - first cell is 0-N corresponding for EXT_INT_0 to EXT_INT_N.
- second cell is used to specify flags.
- interrupt-controller: Marks the device node as an interrupt controller.
- apm,nr-gpios: Optional, specify number of gpios pin.
diff --git a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
deleted file mode 100644
index 9665147..0000000
--- a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Oxford Semiconductor OXNAS SoC GPIO Controller
-
-Please refer to gpio.txt for generic information regarding GPIO bindings.
-
-Required properties:
- - compatible: "oxsemi,ox810se-gpio" or "oxsemi,ox820-gpio"
- - reg: Base address and length for the device.
- - interrupts: The port interrupt shared by all pins.
- - gpio-controller: Marks the port as GPIO controller.
- - #gpio-cells: Two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity as defined in
- defined in <dt-bindings/gpio/gpio.h>:
- 0 = GPIO_ACTIVE_HIGH
- 1 = GPIO_ACTIVE_LOW
- - interrupt-controller: Marks the device node as an interrupt controller.
- - #interrupt-cells: Two. The first cell is the GPIO number and second cell
- is used to specify the trigger type as defined in
- <dt-bindings/interrupt-controller/irq.h>:
- IRQ_TYPE_EDGE_RISING
- IRQ_TYPE_EDGE_FALLING
- IRQ_TYPE_EDGE_BOTH
- - gpio-ranges: Interaction with the PINCTRL subsystem, it also specifies the
- gpio base and count, should be in the format of numeric-gpio-range as
- specified in the gpio.txt file.
-
-Example:
-
-gpio0: gpio@0 {
- compatible = "oxsemi,ox810se-gpio";
- reg = <0x000000 0x100000>;
- interrupts = <21>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&pinctrl 0 0 32>;
-};
-
-keys {
- ...
-
- button-esc {
- label = "ESC";
- linux,code = <1>;
- gpios = <&gpio0 12 0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
index b391cc1..eefe7b3 100644
--- a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
@@ -9,7 +9,7 @@
description: |
Synopsys DesignWare GPIO controllers have a configurable number of ports,
each of which are intended to be represented as child nodes with the generic
- GPIO-controller properties as desribed in this bindings file.
+ GPIO-controller properties as described in this bindings file.
maintainers:
- Hoan Tran <hoan@os.amperecomputing.com>
@@ -61,6 +61,10 @@
'#gpio-cells':
const: 2
+ gpio-line-names:
+ minItems: 1
+ maxItems: 32
+
ngpios:
default: 32
minimum: 1
diff --git a/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
index 22c0cae7..4555f164 100644
--- a/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
@@ -28,6 +28,10 @@
gpio-controller: true
+ gpio-line-names:
+ minItems: 1
+ maxItems: 24
+
interrupt-controller: true
st,norequest-mask:
diff --git a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml
index bd721c8..7b75d2f 100644
--- a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml
@@ -58,14 +58,14 @@
deprecated: true
description:
Name of the hwmod associated with the GPIO. Needed on some legacy OMAP
- SoCs which have not been converted to the ti,sysc interconnect hierarachy.
+ SoCs which have not been converted to the ti,sysc interconnect hierarchy.
ti,no-reset-on-init:
$ref: /schemas/types.yaml#/definitions/flag
deprecated: true
description:
Do not reset on init. Used with ti,hwmods on some legacy OMAP SoCs which
- have not been converted to the ti,sysc interconnect hierarachy.
+ have not been converted to the ti,sysc interconnect hierarchy.
patternProperties:
"^(.+-hog(-[0-9]+)?)$":
diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
index 1638cfe..5eeb29b 100644
--- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: X-Powers AXP209 GPIO
diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
index 18e61af..56143f1 100644
--- a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
+++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ZynqMP Mode Pin GPIO controller
diff --git a/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml b/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml
index a36aec2..59c79a6 100644
--- a/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Bootlin
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpio/xylon,logicvc-gpio.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpio/xylon,logicvc-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xylon LogiCVC GPIO controller
diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
index 38478da..584cce32 100644
--- a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-a31-hwspinlock.yaml#
diff --git a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
index 0a955c7..5ba60d5 100644
--- a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwlock/ti,omap-hwspinlock.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
index ca2b473..2e45364 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
@@ -27,7 +27,7 @@
shunt-resistor-micro-ohms:
description:
- The value of curent sense resistor in microohms. If not provided,
+ The value of current sense resistor in microohms. If not provided,
the current reading and overcurrent alert is disabled.
adi,shutdown-threshold-microamp:
diff --git a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
index 0cf3ed6..6751f9b 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
@@ -11,7 +11,7 @@
- Nuno Sá <nuno.sa@analog.com>
description: |+
- Bindings for the Analog Devices AXI FAN Control driver. Spefications of the
+ Bindings for the Analog Devices AXI FAN Control driver. Specifications of the
core can be found in:
https://wiki.analog.com/resources/fpga/docs/axi_fan_control
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
index b39c632..0ad12d2 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
@@ -46,7 +46,7 @@
shunt-resistor-micro-ohms:
description:
- The value of curent sense resistor in microohms.
+ The value of current sense resistor in microohms.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
index 3ac0298..8645cd3 100644
--- a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -45,7 +45,7 @@
- aspeed,fan-tach-ch : should specify the Fan tach input channel.
integer value in the range 0 through 15, with 0 indicating
Fan tach channel 0 and 15 indicating Fan tach channel 15.
- Atleast one Fan tach input channel is required.
+ At least one Fan tach input channel is required.
Examples:
diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
index c54b598..e5b2478 100644
--- a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
+++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADC-attached Hardware Sensor
diff --git a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml
index 0e49b39..bf33321 100644
--- a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml
+++ b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/jedec,jc42.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml
index b1a4c23..e62aff6 100644
--- a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/lltc,ltc4151.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index 8226e3b..0b69897 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/lm75.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt
index e1b7990..758ff39 100644
--- a/Documentation/devicetree/bindings/hwmon/lm87.txt
+++ b/Documentation/devicetree/bindings/hwmon/lm87.txt
@@ -18,7 +18,7 @@
in7. Otherwise the pin is set as FAN2 input.
- vcc-supply: a Phandle for the regulator supplying power, can be
- cofigured to measure 5.0V power supply. Default is 3.3V.
+ configured to measure 5.0V power supply. Default is 3.3V.
Example:
diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
index 33fd00a..473b34c 100644
--- a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
+++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
@@ -1,4 +1,4 @@
-Lantiq cpu temperatur sensor
+Lantiq cpu temperature sensor
Requires node properties:
- compatible value :
diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml
index 028d6e5..f5e104c 100644
--- a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml
+++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/microchip,mcp3021.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
index bd67cfe..56db229 100644
--- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
+++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
@@ -42,7 +42,7 @@
reg:
items:
- description: PVT common registers
- - description: PVT temprature sensor registers
+ - description: PVT temperature sensor registers
- description: PVT process detector registers
- description: PVT voltage monitor registers
diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
index 7b9d48d..6e59c8f 100644
--- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
+++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/national,lm90.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
index 28f43e9..8523777 100644
--- a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
@@ -23,7 +23,7 @@
fan subnode format:
===================
Under fan subnode can be upto 8 child nodes, each child node representing a fan.
-Each fan subnode must have one PWM channel and atleast one Fan tach channel.
+Each fan subnode must have one PWM channel and at least one Fan tach channel.
For PWM channel can be configured cooling-levels to create cooling device.
Cooling device could be bound to a thermal zone for the thermal control.
diff --git a/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
index 306f673..48d654e 100644
--- a/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
+++ b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/nxp,mc34vr500.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml
index 80df718..14ac783 100644
--- a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/sensirion,sht15.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
index 159238e..3d14d5f 100644
--- a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -13,7 +13,7 @@
The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensors
designed especially for battery-driven high-volume consumer electronics
applications.
- For further information refere to Documentation/hwmon/shtc1.rst
+ For further information refer to Documentation/hwmon/shtc1.rst
This binding document describes the binding for the hardware monitor
portion of the driver.
diff --git a/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml
index f5b3452..733cba7 100644
--- a/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml
+++ b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml
@@ -27,8 +27,8 @@
clock-names:
items:
- - const: "sense"
- - const: "bus"
+ - const: sense
+ - const: bus
'#thermal-sensor-cells':
const: 0
@@ -39,8 +39,8 @@
reset-names:
items:
- - const: "sense"
- - const: "bus"
+ - const: sense
+ - const: bus
required:
- compatible
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
index c5a889e..7e5b62a 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/ti,tmp102.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml
index dcbc6fb..8b5307c 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/ti,tmp108.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
index fde5225..cdd1489 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
@@ -33,7 +33,7 @@
shunt-resistor-micro-ohms:
description: |
- If 0, the calibration process will be skiped and the current and power
+ If 0, the calibration process will be skipped and the current and power
measurement engine will not work. Temperature and voltage measurement
will continue to work. The shunt value also need to respect:
rshunt <= pga-gain * 40 * 1000 * 1000.
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
index bce68a3..ebc8d46 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
@@ -26,7 +26,7 @@
maxItems: 1
shunt-resistor-micro-ohms:
- description: The value of curent sense resistor in microohms.
+ description: The value of current sense resistor in microohms.
default: 255000
minimum: 250000
maximum: 255000
diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
index ff57c54..9f1d35c 100644
--- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
+++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
@@ -48,6 +48,9 @@
default: 16
enum: [2, 4, 8, 16, 32, 64, 128, 256]
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
deleted file mode 100644
index 548a73c..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
-=================================================================
-This uses GPIO lines and a challenge & response mechanism to arbitrate who is
-the master of an I2C bus in a multimaster situation.
-
-In many cases using GPIOs to arbitrate is not needed and a design can use
-the standard I2C multi-master rules. Using GPIOs is generally useful in
-the case where there is a device on the bus that has errata and/or bugs
-that makes standard multimaster mode not feasible.
-
-Note that this scheme works well enough but has some downsides:
-* It is nonstandard (not using standard I2C multimaster)
-* Having two masters on a bus in general makes it relatively hard to debug
- problems (hard to tell if i2c issues were caused by one master, another, or
- some device on the bus).
-
-
-Algorithm:
-
-All masters on the bus have a 'bus claim' line which is an output that the
-others can see. These are all active low with pull-ups enabled. We'll
-describe these lines as:
-
-- OUR_CLAIM: output from us signaling to other hosts that we want the bus
-- THEIR_CLAIMS: output from others signaling that they want the bus
-
-The basic algorithm is to assert your line when you want the bus, then make
-sure that the other side doesn't want it also. A detailed explanation is best
-done with an example.
-
-Let's say we want to claim the bus. We:
-1. Assert OUR_CLAIM.
-2. Waits a little bit for the other sides to notice (slew time, say 10
- microseconds).
-3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are
- done.
-4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
-5. If not, back off, release the claim and wait for a few more milliseconds.
-6. Go back to 1 (until retry time has expired).
-
-
-Required properties:
-- compatible: i2c-arb-gpio-challenge
-- our-claim-gpio: The GPIO that we use to claim the bus.
-- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
- Note that some implementations may only support a single other master.
-- I2C arbitration bus node. See i2c-arb.txt in this directory.
-
-Optional properties:
-- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
-- wait-retry-us: we'll attempt another claim after this many microseconds.
- Default is 3000 us.
-- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
-
-
-Example:
- i2c@12ca0000 {
- compatible = "acme,some-i2c-device";
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
- i2c-arbitrator {
- compatible = "i2c-arb-gpio-challenge";
-
- i2c-parent = <&{/i2c@12CA0000}>;
-
- our-claim-gpio = <&gpf0 3 1>;
- their-claim-gpios = <&gpe0 4 1>;
- slew-delay-us = <10>;
- wait-retry-us = <3000>;
- wait-free-us = <50000>;
-
- i2c-arb {
- #address-cells = <1>;
- #size-cells = <0>;
-
- i2c@52 {
- // Normal I2C device
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml
new file mode 100644
index 0000000..b618b5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-arb-gpio-challenge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+
+maintainers:
+ - Doug Anderson <dianders@chromium.org>
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ This uses GPIO lines and a challenge & response mechanism to arbitrate who is
+ the master of an I2C bus in a multimaster situation.
+
+ In many cases using GPIOs to arbitrate is not needed and a design can use the
+ standard I2C multi-master rules. Using GPIOs is generally useful in the case
+ where there is a device on the bus that has errata and/or bugs that makes
+ standard multimaster mode not feasible.
+
+ Note that this scheme works well enough but has some downsides:
+ * It is nonstandard (not using standard I2C multimaster)
+ * Having two masters on a bus in general makes it relatively hard to debug
+ problems (hard to tell if i2c issues were caused by one master, another,
+ or some device on the bus).
+
+ Algorithm:
+ All masters on the bus have a 'bus claim' line which is an output that the
+ others can see. These are all active low with pull-ups enabled. We'll
+ describe these lines as:
+ * OUR_CLAIM: output from us signaling to other hosts that we want the bus
+ * THEIR_CLAIMS: output from others signaling that they want the bus
+
+ The basic algorithm is to assert your line when you want the bus, then make
+ sure that the other side doesn't want it also. A detailed explanation is
+ best done with an example.
+
+ Let's say we want to claim the bus. We:
+ 1. Assert OUR_CLAIM.
+ 2. Waits a little bit for the other sides to notice (slew time, say 10
+ microseconds).
+ 3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we
+ are done.
+ 4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+ 5. If not, back off, release the claim and wait for a few more milliseconds.
+ 6. Go back to 1 (until retry time has expired).
+
+properties:
+ compatible:
+ const: i2c-arb-gpio-challenge
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The I2C bus that this multiplexer's master-side port is connected to.
+
+ our-claim-gpios:
+ maxItems: 1
+ description:
+ The GPIO that we use to claim the bus.
+
+ slew-delay-us:
+ default: 10
+ description:
+ Time to wait for a GPIO to go high.
+
+ their-claim-gpios:
+ minItems: 1
+ maxItems: 8
+ description:
+ The GPIOs that the other sides use to claim the bus. Note that some
+ implementations may only support a single other master.
+
+ wait-free-us:
+ default: 50000
+ description:
+ We'll give up after this many microseconds.
+
+ wait-retry-us:
+ default: 3000
+ description:
+ We'll attempt another claim after this many microseconds.
+
+ i2c-arb:
+ type: object
+ $ref: /schemas/i2c/i2c-controller.yaml
+ unevaluatedProperties: false
+ description:
+ I2C arbitration bus node.
+
+required:
+ - compatible
+ - i2c-arb
+ - our-claim-gpios
+ - their-claim-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c-arbitrator {
+ compatible = "i2c-arb-gpio-challenge";
+ i2c-parent = <&i2c_4>;
+
+ our-claim-gpios = <&gpf0 3 GPIO_ACTIVE_LOW>;
+ their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>;
+ slew-delay-us = <10>;
+ wait-retry-us = <3000>;
+ wait-free-us = <50000>;
+
+ i2c-arb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sbs-battery@b {
+ compatible = "sbs,sbs-battery";
+ reg = <0xb>;
+ sbs,poll-retry-count = <1>;
+ };
+
+ embedded-controller@1e {
+ compatible = "google,cros-ec-i2c";
+ reg = <0x1e>;
+ interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gpx1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ec_irq>;
+ wakeup-source;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb.txt b/Documentation/devicetree/bindings/i2c/i2c-arb.txt
deleted file mode 100644
index 59abf92..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-arb.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Common i2c arbitration bus properties.
-
-- i2c-arb child node
-
-Required properties for the i2c-arb child node:
-- #address-cells = <1>;
-- #size-cells = <0>;
-
-Optional properties for i2c-arb child node:
-- Child nodes conforming to i2c bus binding
-
-
-Example :
-
- /*
- An NXP pca9541 I2C bus master selector at address 0x74
- with a NXP pca8574 GPIO expander attached.
- */
-
- arb@74 {
- compatible = "nxp,pca9541";
- reg = <0x74>;
-
- i2c-arb {
- #address-cells = <1>;
- #size-cells = <0>;
-
- gpio@38 {
- compatible = "nxp,pca8574";
- reg = <0x38>;
- #gpio-cells = <2>;
- gpio-controller;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-atr.yaml b/Documentation/devicetree/bindings/i2c/i2c-atr.yaml
new file mode 100644
index 0000000..1939ab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-atr.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-atr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common i2c address translator properties
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ An I2C Address Translator (ATR) is a device with an I2C slave parent
+ ("upstream") port and N I2C master child ("downstream") ports, and
+ forwards transactions from upstream to the appropriate downstream port
+ with a modified slave address. The address used on the parent bus is
+ called the "alias" and is (potentially) different from the physical
+ slave address of the child bus. Address translation is done by the
+ hardware.
+
+properties:
+ i2c-alias-pool:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ I2C alias pool is a pool of I2C addresses on the main I2C bus that can be
+ used to access the remote peripherals on the serializer's I2C bus. The
+ addresses must be available, not used by any other peripheral. Each
+ remote peripheral is assigned an alias from the pool, and transactions to
+ that address will be forwarded to the remote peripheral, with the address
+ translated to the remote peripheral's real address. This property is not
+ needed if there are no I2C addressable remote peripherals.
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
index 9f1726d..2d7bb99 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
@@ -4,21 +4,29 @@
$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP PCA954x I2C bus switch
+title: NXP PCA954x I2C and compatible bus switches
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description:
- The binding supports NXP PCA954x and PCA984x I2C mux/switch devices.
-
-allOf:
- - $ref: /schemas/i2c/i2c-mux.yaml#
+ The NXP PCA954x and compatible devices are I2C bus
+ multiplexer/switches that share the same functionality
+ and register layout.
+ The devices usually have 4 or 8 child buses, which are
+ attached to the parent bus by using the SMBus "Send Byte"
+ command.
properties:
compatible:
oneOf:
- enum:
+ - maxim,max7356
+ - maxim,max7357
+ - maxim,max7358
+ - maxim,max7367
+ - maxim,max7368
+ - maxim,max7369
- nxp,pca9540
- nxp,pca9542
- nxp,pca9543
@@ -59,10 +67,34 @@
description: if present, overrides i2c-mux-idle-disconnect
$ref: /schemas/mux/mux-controller.yaml#/properties/idle-state
+ vdd-supply:
+ description: A voltage regulator supplying power to the chip. On PCA9846
+ the regulator supplies power to VDD2 (core logic) and optionally to VDD1.
+
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/i2c/i2c-mux.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max7367
+ - maxim,max7369
+ - nxp,pca9542
+ - nxp,pca9543
+ - nxp,pca9544
+ - nxp,pca9545
+ then:
+ properties:
+ interrupts: false
+ "#interrupt-cells": false
+ interrupt-controller: false
+
unevaluatedProperties: false
examples:
@@ -74,11 +106,13 @@
#size-cells = <0>;
i2c-mux@74 {
- compatible = "nxp,pca9548";
+ compatible = "nxp,pca9545";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
+ vdd-supply = <&p3v3>;
+
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
index 60b7cda..7b6b3b8 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
@@ -10,7 +10,7 @@
"source" for I2C source (parent) clock,
"enable" for I2C module enable clock.
- clocks: Should contain a clock specifier for each entry in clock-names.
-- clock-frequency: Constains desired I2C bus clock frequency in Hz.
+- clock-frequency: Contains desired I2C bus clock frequency in Hz.
- #address-cells: Should be 1 to describe address cells for I2C device address.
- #size-cells: Should be 0 means no size cell for I2C device address.
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
deleted file mode 100644
index 42bfc09..0000000
--- a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* NXP PCA9541 I2C bus master selector
-
-Required Properties:
-
- - compatible: Must be "nxp,pca9541"
-
- - reg: The I2C address of the device.
-
- The following required properties are defined externally:
-
- - I2C arbitration bus node. See i2c-arb.txt in this directory.
-
-
-Example:
-
- i2c-arbitrator@74 {
- compatible = "nxp,pca9541";
- reg = <0x74>;
-
- i2c-arb {
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@54 {
- compatible = "atmel,24c08";
- reg = <0x54>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml b/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml
new file mode 100644
index 0000000..b65c25c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nxp,pca9541.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA9541 I2C bus master selector
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+properties:
+ compatible:
+ const: nxp,pca9541
+
+ reg:
+ maxItems: 1
+
+ i2c-arb:
+ type: object
+ $ref: /schemas/i2c/i2c-controller.yaml
+ unevaluatedProperties: false
+ description:
+ I2C arbitration bus node.
+
+required:
+ - compatible
+ - reg
+ - i2c-arb
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-arbitrator@74 {
+ compatible = "nxp,pca9541";
+ reg = <0x74>;
+
+ i2c-arb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@54 {
+ compatible = "atmel,24c08";
+ reg = <0x54>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
index c002afd..5dda8cb 100644
--- a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
+++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
@@ -1,8 +1,8 @@
# 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#"
+$id: http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MIPI I3C HCI
diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml
index c8659c5..cb31e75 100644
--- a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml
@@ -36,8 +36,8 @@
maxItems: 2
items:
enum:
- - "INT1"
- - "INT2"
+ - INT1
+ - INT2
required:
- compatible
diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
new file mode 100644
index 0000000..7ef46c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/allwinner,sun20i-d1-gpadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1 General Purpose ADC
+
+maintainers:
+ - Maksim Kiselev <bigunclemax@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun20i-d1-gpadc
+
+ "#io-channel-cells":
+ const: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ "^channel@[0-9a-f]+$":
+ $ref: adc.yaml
+ type: object
+ description:
+ Represents the internal channels of the ADC.
+
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 15
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+required:
+ - "#io-channel-cells"
+ - clocks
+ - compatible
+ - interrupts
+ - reg
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sun20i-d1-ccu.h>
+ #include <dt-bindings/reset/sun20i-d1-ccu.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpadc: adc@2009000 {
+ compatible = "allwinner,sun20i-d1-gpadc";
+ reg = <0x2009000 0x400>;
+ clocks = <&ccu CLK_BUS_GPADC>;
+ resets = <&ccu RST_BUS_GPADC>;
+ interrupts = <73 IRQ_TYPE_LEVEL_HIGH>;
+ #io-channel-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
index e6a1f91..1f30a85 100644
--- a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
@@ -56,8 +56,8 @@
String corresponding to an identifier from atmel,adc-res-names property.
If not specified, the highest resolution will be used.
enum:
- - "lowres"
- - "highres"
+ - lowres
+ - highres
atmel,adc-sleep-mode:
$ref: /schemas/types.yaml#/definitions/flag
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
index 2127d63..e004659 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
@@ -78,9 +78,9 @@
ti,datarate:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
- maximum: 6
+ maximum: 7
description: |
- Data acquisition rate in samples per second
+ Data acquisition rate in samples per second for ADS1015, TLA2024
0: 128
1: 250
2: 490
@@ -88,6 +88,17 @@
4: 1600 (default)
5: 2400
6: 3300
+ 7: 3300
+
+ Data acquisition rate in samples per second for ADS1115
+ 0: 8
+ 1: 16
+ 2: 32
+ 3: 64
+ 4: 128 (default)
+ 5: 250
+ 6: 475
+ 7: 860
required:
- reg
diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml
index be93c10..8cbad7e 100644
--- a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml
@@ -57,7 +57,7 @@
|27 |FPD Internal voltage measurement, VCC_PSINTFP (supply5). |Voltage
|28 |PS Auxiliary voltage measurement (supply6). |Voltage
|29 |PL VCCADC voltage measurement (vccams). |Voltage
- |30 |Differential analog input signal voltage measurment. |Voltage
+ |30 |Differential analog input signal voltage measurement. |Voltage
|31 |VUser0 voltage measurement (supply7). |Voltage
|32 |VUser1 voltage measurement (supply8). |Voltage
|33 |VUser2 voltage measurement (supply9). |Voltage
diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
index 72d2e91..2594fa1 100644
--- a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
+++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
@@ -216,7 +216,6 @@
description: Whether to enable burnout current for EXT1.
adi,ext1-burnout-current-nanoamp:
- $ref: /schemas/types.yaml#/definitions/uint32
description:
Burnout current in nanoamps to be applied to EXT1.
enum: [0, 50, 500, 1000, 10000]
@@ -233,7 +232,6 @@
description: Whether to enable burnout current for EXT2.
adi,ext2-burnout-current-nanoamp:
- $ref: /schemas/types.yaml#/definitions/uint32
description: Burnout current in nanoamps to be applied to EXT2.
enum: [0, 50, 500, 1000, 10000]
default: 0
@@ -249,7 +247,6 @@
description: Whether to enable burnout current for VIOUT.
adi,viout-burnout-current-nanoamp:
- $ref: /schemas/types.yaml#/definitions/uint32
description: Burnout current in nanoamps to be applied to VIOUT.
enum: [0, 1000, 10000]
default: 0
diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml b/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml
index 2155d3f..3d7074f 100644
--- a/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml
+++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/cdc/adi,ad7150.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog device AD7150 and similar capacitance to digital convertors.
+title: Analog device AD7150 and similar capacitance to digital converters.
maintainers:
- Jonathan Cameron <jic23@kernel.org>
diff --git a/Documentation/devicetree/bindings/iio/common.yaml b/Documentation/devicetree/bindings/iio/common.yaml
index f845b41d..b3a10af 100644
--- a/Documentation/devicetree/bindings/iio/common.yaml
+++ b/Documentation/devicetree/bindings/iio/common.yaml
@@ -12,7 +12,7 @@
description: |
This document defines device tree properties common to several iio
- sensors. It doesn't constitue a device tree binding specification by itself but
+ sensors. It doesn't constitute a device tree binding specification by itself but
is meant to be referenced by device tree bindings.
When referenced from sensor tree bindings the properties defined in this
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml
new file mode 100644
index 0000000..99831d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.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/microchip,mcp4728.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP4728 DAC
+
+maintainers:
+ - Andrea Collamati <andrea.collamati@gmail.com>
+
+description: |
+ MCP4728 is a quad channel, 12-bit voltage output
+ Digital-to-Analog Converter with non-volatile
+ memory and I2C compatible Serial Interface.
+ https://www.microchip.com/en-us/product/mcp4728
+
+properties:
+ compatible:
+ const: microchip,mcp4728
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: |
+ Provides both power and acts as the reference supply on the MCP4728
+ when Internal Vref is not selected.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@60 {
+ compatible = "microchip,mcp4728";
+ reg = <0x60>;
+ vdd-supply = <&vdac_vdd>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
index fc813bc..f2eb228 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
@@ -39,6 +39,46 @@
description:
Analog voltage regulator.
+ vcc-drv-supply:
+ description:
+ RF Driver voltage regulator.
+
+ vcc2-drv-supply:
+ description:
+ RF predriver voltage regulator.
+
+ vcc-vva-supply:
+ description:
+ VVA Control Circuit voltage regulator.
+
+ vcc-amp1-supply:
+ description:
+ RF Amplifier 1 voltage regulator.
+
+ vcc-amp2-supply:
+ description:
+ RF Amplifier 2 voltage regulator.
+
+ vcc-env-supply:
+ description:
+ Envelope Detector voltage regulator.
+
+ vcc-bg-supply:
+ description:
+ Mixer Chip Band Gap Circuit voltage regulator.
+
+ vcc-bg2-supply:
+ description:
+ VGA Chip Band Gap Circuit voltage regulator.
+
+ vcc-mixer-supply:
+ description:
+ Mixer voltage regulator.
+
+ vcc-quad-supply:
+ description:
+ Quadruppler voltage regulator.
+
adi,detector-enable:
description:
Enable the Envelope Detector available at output pins VENV_P and
@@ -69,6 +109,16 @@
- clocks
- clock-names
- vcm-supply
+ - vcc-drv-supply
+ - vcc2-drv-supply
+ - vcc-vva-supply
+ - vcc-amp1-supply
+ - vcc-amp2-supply
+ - vcc-env-supply
+ - vcc-bg-supply
+ - vcc-bg2-supply
+ - vcc-mixer-supply
+ - vcc-quad-supply
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
@@ -87,6 +137,16 @@
clocks = <&admv1013_lo>;
clock-names = "lo_in";
vcm-supply = <&vcm>;
+ vcc-drv-supply = <&vcc_drv>;
+ vcc2-drv-supply = <&vcc2_drv>;
+ vcc-vva-supply = <&vcc_vva>;
+ vcc-amp1-supply = <&vcc_amp1>;
+ vcc-amp2-supply = <&vcc_amp2>;
+ vcc-env-supply = <&vcc_env>;
+ vcc-bg-supply = <&vcc_bg>;
+ vcc-bg2-supply = <&vcc_bg2>;
+ vcc-mixer-supply = <&vcc_mixer>;
+ vcc-quad-supply = <&vcc_quad>;
adi,quad-se-mode = "diff";
adi,detector-enable;
};
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
index ab86daa..39cc63a 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
@@ -33,7 +33,7 @@
items:
- const: lo_in
description:
- External clock that provides the Local Oscilator input.
+ External clock that provides the Local Oscillator input.
vcm-supply:
description:
@@ -103,6 +103,14 @@
- clocks
- clock-names
- vcm-supply
+ - vcc-if-bb-supply
+ - vcc-vga-supply
+ - vcc-vva-supply
+ - vcc-lna-3p3-supply
+ - vcc-lna-1p5-supply
+ - vcc-bg-supply
+ - vcc-quad-supply
+ - vcc-mixer-supply
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
index a2bc1fa..79e75a8 100644
--- a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
+++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
@@ -10,7 +10,7 @@
- Eugene Zaikonnikov <ez@norophonic.com>
description: |
- Relative humidity and tempereature sensors on I2C bus
+ Relative humidity and temperature sensors on I2C bus
Datasheets are available at:
http://www.ti.com/product/HDC2010/datasheet
diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml
new file mode 100644
index 0000000..8376d64
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27010.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/rohm,bu27010.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BU27010 color sensor
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ The ROHM BU27010 is a sensor with 6 photodiodes (red, green, blue, clear,
+ IR and flickering detection) with five configurable channels. Red, green
+ and flickering detection being always available and two out of the rest
+ three (blue, clear, IR) can be selected to be simultaneously measured.
+ Typical application is adjusting LCD/OLED backlight of TVs, mobile phones
+ and tablet PCs.
+
+properties:
+ compatible:
+ const: rohm,bu27010
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@38 {
+ compatible = "rohm,bu27010";
+ reg = <0x38>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
index c0a923f..b31f812 100644
--- a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
@@ -47,7 +47,7 @@
reset-gpios:
description:
Optional GPIO for resetting the device.
- If not present the device is not resetted during the probe.
+ If not present the device is not reset during the probe.
maxItems: 1
honeywell,pmin-pascal:
diff --git a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
index c999994..9567993 100644
--- a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
@@ -10,7 +10,7 @@
- Matt Ranostay <matt.ranostay@konsulko.com>
description:
- This lightening distance sensor uses an I2C or SPI interface. The
+ This lightning distance sensor uses an I2C or SPI interface. The
binding currently only covers the SPI option.
properties:
diff --git a/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml b/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml
new file mode 100644
index 0000000..67f5389
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/murata,irsd200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Murata IRS-D200 PIR sensor
+
+maintainers:
+ - Waqar Hameed <waqar.hameed@axis.com>
+
+description:
+ PIR sensor for human detection.
+
+properties:
+ compatible:
+ const: murata,irsd200
+
+ reg:
+ items:
+ - enum:
+ - 0x48
+ - 0x49
+ description: |
+ When the AD pin is connected to GND, the slave address is 0x48.
+ When the AD pin is connected to VDD, the slave address is 0x49.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Type should be IRQ_TYPE_EDGE_RISING.
+
+ vdd-supply:
+ description:
+ 3.3 V supply voltage.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ proximity@48 {
+ compatible = "murata,irsd200";
+ reg = <0x48>;
+ interrupts = <24 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <®ulator_3v3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
index 5de0bb2..775555d 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
@@ -15,6 +15,9 @@
Specifications about the devices can be found at:
https://www.semtech.com/products/smart-sensing/sar-sensors/sx9310
+allOf:
+ - $ref: /schemas/iio/iio.yaml#
+
properties:
compatible:
enum:
@@ -102,7 +105,7 @@
- reg
- "#io-channel-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
index b3aa2eb..48f2214 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
@@ -13,6 +13,9 @@
description: |
Semtech's SX9324 proximity sensor.
+allOf:
+ - $ref: /schemas/iio/iio.yaml#
+
properties:
compatible:
const: semtech,sx9324
@@ -167,7 +170,7 @@
- reg
- "#io-channel-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
index e450821..fff7e3d 100644
--- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -97,7 +97,7 @@
interrupts:
description: interrupt line(s) connected to the DRDY line(s) and/or the
- Intertial interrupt lines INT1 and INT2 if these exist. This means up to
+ Inertial interrupt lines INT1 and INT2 if these exist. This means up to
three interrupts, and the DRDY must be the first one if it exists on
the package. The trigger edge of the interrupts is sometimes software
configurable in the hardware so the operating system should parse this
diff --git a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml
index 2a9bb6ac..24dc2d6 100644
--- a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml
+++ b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/elan,ekth3000.yaml#
diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
index 05e6f2df..3e2d216 100644
--- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
+++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
@@ -13,6 +13,9 @@
Supports the Elan eKTH6915 touchscreen controller.
This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
properties:
compatible:
items:
@@ -24,6 +27,8 @@
interrupts:
maxItems: 1
+ panel: true
+
reset-gpios:
description: Reset GPIO; not all touchscreens using eKTH6915 hook this up.
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
index 1edad1d..358cb827 100644
--- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
+++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
@@ -14,6 +14,9 @@
This touchscreen uses the i2c-hid protocol but has some non-standard
power sequencing required.
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
properties:
compatible:
oneOf:
@@ -30,6 +33,8 @@
interrupts:
maxItems: 1
+ panel: true
+
reset-gpios:
true
diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
index 7156b08..138caad 100644
--- a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
+++ b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
@@ -44,6 +44,8 @@
description: HID descriptor address
$ref: /schemas/types.yaml#/definitions/uint32
+ panel: true
+
post-power-on-delay-ms:
description: Time required by the device after enabling its regulators
or powering it on, before it is ready for communication.
diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
new file mode 100644
index 0000000..c5d9e0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ilitek,ili9882t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ili9882t touchscreen controller
+
+maintainers:
+ - Cong Yang <yangcong5@huaqin.corp-partner.google.com>
+
+description:
+ Supports the Ilitek ili9882t touchscreen controller.
+ This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+properties:
+ compatible:
+ const: ilitek,ili9882t
+
+ reg:
+ const: 0x41
+
+ interrupts:
+ maxItems: 1
+
+ panel: true
+
+ reset-gpios:
+ maxItems: 1
+ description: Reset GPIO.
+
+ vccio-supply:
+ description: The 1.8V supply to the touchscreen.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - panel
+ - vccio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen: touchscreen@41 {
+ compatible = "ilitek,ili9882t";
+ reg = <0x41>;
+
+ interrupt-parent = <&pio>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+
+ panel = <&panel>;
+ reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
+ vccio-supply = <&mt6366_vio18_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
deleted file mode 100644
index 9afffbd..0000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Synaptics RMI4 2D Sensor Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices which contain 2D sensors using Function 11 or
-Function 12. Complete documentation for transports and other functions
-can be found in:
-Documentation/devicetree/bindings/input/rmi4.
-
-RMI4 Function 11 and Function 12 are for 2D touch position sensing.
-Additional documentation for F11 can be found at:
-http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
-
-Optional Touch Properties:
-Description in Documentation/devicetree/bindings/input/touchscreen
-- touchscreen-inverted-x
-- touchscreen-inverted-y
-- touchscreen-swapped-x-y
-- touchscreen-x-mm
-- touchscreen-y-mm
-
-Optional Properties:
-- syna,clip-x-low: Sets a minimum value for X.
-- syna,clip-y-low: Sets a minimum value for Y.
-- syna,clip-x-high: Sets a maximum value for X.
-- syna,clip-y-high: Sets a maximum value for Y.
-- syna,offset-x: Add an offset to X.
-- syna,offset-y: Add an offset to Y.
-- syna,delta-x-threshold: Set the minimum distance on the X axis required
- to generate an interrupt in reduced reporting
- mode.
-- syna,delta-y-threshold: Set the minimum distance on the Y axis required
- to generate an interrupt in reduced reporting
- mode.
-- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad.
-- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to
- disable reporing absolute position data.
-- syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero
- command.
-
-
-Example of a RMI4 I2C device with F11:
-Example:
- &i2c1 {
- rmi4-i2c-dev@2c {
- compatible = "syna,rmi4-i2c";
-
- ...
-
- rmi4-f11@11 {
- reg = <0x11>;
- touchscreen-inverted-y;
- syna,sensor-type = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
deleted file mode 100644
index 079cad2..0000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Synaptics RMI4 F01 Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices which contain Function 1. Complete documentation
-for transports and other functions can be found in:
-Documentation/devicetree/bindings/input/rmi4.
-
-Additional documentation for F01 can be found at:
-http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
-
-Optional Properties:
-- syna,nosleep-mode: If set the device will run at full power without sleeping.
- nosleep has 3 modes, 0 will not change the default
- setting, 1 will disable nosleep (allow sleeping),
- and 2 will enable nosleep (disabling sleep).
-- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
- background capacitance that will cause the
- device to wake from dozing.
-- syna,doze-holdoff-ms: The delay to wait after the last finger lift and the
- first doze cycle.
-- syna,doze-interval-ms: The time period that the device sleeps between finger
- activity.
-
-
-Example of a RMI4 I2C device with F01:
- Example:
- &i2c1 {
- rmi4-i2c-dev@2c {
- compatible = "syna,rmi4-i2c";
-
- ...
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
deleted file mode 100644
index dcb012f..0000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Synaptics RMI4 I2C Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices using the I2C transport driver. Complete documentation
-for other transports and functions can be found in
-Documentation/devicetree/bindings/input/rmi4.
-
-Required Properties:
-- compatible: syna,rmi4-i2c
-- reg: I2C address
-- #address-cells: Set to 1 to indicate that the function child nodes
- consist of only on uint32 value.
-- #size-cells: Set to 0 to indicate that the function child nodes do not
- have a size property.
-
-Optional Properties:
-- interrupts: interrupt which the rmi device is connected to.
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
-- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
- device.
-
-- syna,startup-delay-ms: The number of milliseconds to wait after powering on
- the device.
-
-- vdd-supply: VDD power supply.
-See ../regulator/regulator.txt
-
-- vio-supply: VIO power supply
-See ../regulator/regulator.txt
-
-Function Parameters:
-Parameters specific to RMI functions are contained in child nodes of the rmi device
- node. Documentation for the parameters of each function can be found in:
-Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
-
-
-
-Example:
- &i2c1 {
- rmi4-i2c-dev@2c {
- compatible = "syna,rmi4-i2c";
- reg = <0x2c>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <&gpio>;
- interrupts = <4 2>;
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
-
- rmi4-f11@11 {
- reg = <0x11>;
- touchscreen-inverted-y;
- syna,sensor-type = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
deleted file mode 100644
index 632f473..0000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Synaptics RMI4 SPI Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices using the SPI transport driver. Complete documentation
-for other transports and functions can be found in
-Documentation/devicetree/bindings/input/rmi4.
-
-Required Properties:
-- compatible: syna,rmi4-spi
-- reg: Chip select address for the device
-- #address-cells: Set to 1 to indicate that the function child nodes
- consist of only on uint32 value.
-- #size-cells: Set to 0 to indicate that the function child nodes do not
- have a size property.
-
-Optional Properties:
-- interrupts: interrupt which the rmi device is connected to.
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
-- spi-rx-delay-us: microsecond delay after a read transfer.
-- spi-tx-delay-us: microsecond delay after a write transfer.
-
-Function Parameters:
-Parameters specific to RMI functions are contained in child nodes of the rmi device
- node. Documentation for the parameters of each function can be found in:
-Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
-
-
-
-Example:
- spi@7000d800 {
- rmi4-spi-dev@0 {
- compatible = "syna,rmi4-spi";
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
- spi-max-frequency = <4000000>;
- spi-cpha;
- spi-cpol;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(K, 2) 0x2>;
- spi-rx-delay-us = <30>;
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
-
- rmi4-f11@11 {
- reg = <0x11>;
- touchscreen-inverted-y;
- syna,sensor-type = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
deleted file mode 100644
index 12bb771..0000000
--- a/Documentation/devicetree/bindings/input/stmpe-keypad.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* STMPE Keypad
-
-Required properties:
- - compatible : "st,stmpe-keypad"
- - linux,keymap : See ./matrix-keymap.txt
-
-Optional properties:
- - debounce-interval : Debouncing interval time in milliseconds
- - st,scan-count : Scanning cycles elapsed before key data is updated
- - st,no-autorepeat : If specified device will not autorepeat
- - keypad,num-rows : See ./matrix-keymap.txt
- - keypad,num-columns : See ./matrix-keymap.txt
-
-Example:
-
- stmpe_keypad {
- compatible = "st,stmpe-keypad";
-
- debounce-interval = <64>;
- st,scan-count = <8>;
- st,no-autorepeat;
-
- linux,keymap = <0x205006b
- 0x4010074
- 0x3050072
- 0x1030004
- 0x502006a
- 0x500000a
- 0x5008b
- 0x706001c
- 0x405000b
- 0x6070003
- 0x3040067
- 0x303006c
- 0x60400e7
- 0x602009e
- 0x4020073
- 0x5050002
- 0x4030069
- 0x3020008>;
- };
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
new file mode 100644
index 0000000..4d4e1a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -0,0 +1,271 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/syna,rmi4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics RMI4 compliant devices
+
+maintainers:
+ - Jason A. Donenfeld <Jason@zx2c4.com>
+ - Matthias Schiffer <matthias.schiffer@ew.tq-group.com
+ - Vincent Huang <vincent.huang@tw.synaptics.com>
+
+description: |
+ The Synaptics RMI4 (Register Mapped Interface 4) core is able to support RMI4
+ devices using different transports (I2C, SPI) and different functions (e.g.
+ Function 1, 2D sensors using Function 11 or 12).
+
+properties:
+ compatible:
+ enum:
+ - syna,rmi4-i2c
+ - syna,rmi4-spi
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description: Active low signal
+
+ spi-cpha: true
+ spi-cpol: true
+
+ syna,reset-delay-ms:
+ description:
+ Delay to wait after resetting the device.
+
+ syna,startup-delay-ms:
+ description:
+ Delay to wait after powering on the device.
+
+ vdd-supply: true
+ vio-supply: true
+
+ rmi4-f01@1:
+ type: object
+ additionalProperties: false
+ description:
+ Function 1
+
+ properties:
+ reg:
+ maxItems: 1
+
+ syna,nosleep-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ description:
+ If set the device will run at full power without sleeping. nosleep
+ has 3 modes, 0 will not change the default setting, 1 will disable
+ nosleep (allow sleeping), and 2 will enable nosleep (disabling
+ sleep).
+
+ syna,wakeup-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the amplitude of the disturbance to the background
+ capacitance that will cause the device to wake from dozing.
+
+ syna,doze-holdoff-ms:
+ description:
+ The delay to wait after the last finger lift and the first doze
+ cycle.
+
+ syna,doze-interval-ms:
+ description:
+ The time period that the device sleeps between finger activity.
+
+ required:
+ - reg
+
+patternProperties:
+ "^rmi4-f1[12]@1[12]$":
+ type: object
+ unevaluatedProperties: false
+ $ref: /schemas/input/touchscreen/touchscreen.yaml#
+ description:
+ RMI4 Function 11 and Function 12 are for 2D touch position sensing.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ syna,clip-x-low:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum value for X.
+
+ syna,clip-y-low:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum value for Y.
+
+ syna,clip-x-high:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum value for X.
+
+ syna,clip-y-high:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum value for Y.
+
+ syna,offset-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Add an offset to X.
+
+ syna,offset-y:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Add an offset to Y.
+
+ syna,delta-x-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum distance on the X axis required to generate an interrupt in
+ reduced reporting mode.
+
+ syna,delta-y-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum distance on the Y axis required to generate an interrupt in
+ reduced reporting mode.
+
+ syna,sensor-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: |
+ Sensor type: 1 for touchscreen 2 for touchpad.
+
+ syna,disable-report-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Mask for disabling posiiton reporting. Used to disable reporing
+ absolute position data.
+
+ syna,rezero-wait-ms:
+ description:
+ Time to wait after issuing a rezero command.
+
+ required:
+ - reg
+
+ "^rmi4-f[0-9a-f]+@[0-9a-f]+$":
+ type: object
+ description:
+ Other functions, not documented yet.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: syna,rmi4-i2c
+ then:
+ properties:
+ spi-rx-delay-us: false
+ spi-tx-delay-us: false
+ else:
+ properties:
+ syna,reset-delay-ms: false
+ syna,startup-delay-ms: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@20 {
+ compatible = "syna,rmi4-i2c";
+ reg = <0x20>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+
+ syna,startup-delay-ms = <100>;
+ vdd-supply = <&tsp_vdd>;
+ vio-supply = <&ldo32_reg>;
+
+ pinctrl-0 = <&touch_irq>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f12@12 {
+ reg = <0x12>;
+ syna,sensor-type = <1>;
+ };
+
+ rmi4-f1a@1a {
+ reg = <0x1a>;
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@0 {
+ compatible = "syna,rmi4-spi";
+ reg = <0x0>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+
+ spi-max-frequency = <4000000>;
+ spi-rx-delay-us = <30>;
+ spi-cpha;
+ spi-cpol;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f11@11 {
+ reg = <0x11>;
+ touchscreen-inverted-y;
+ syna,sensor-type = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
deleted file mode 100644
index 238b515..0000000
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-STMPE Touchscreen
-----------------
-
-Required properties:
- - compatible: "st,stmpe-ts"
-
-Optional properties:
-- st,ave-ctrl : Sample average control
- 0 -> 1 sample
- 1 -> 2 samples
- 2 -> 4 samples
- 3 -> 8 samples
-- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
- 0 -> 10 us
- 1 -> 50 us
- 2 -> 100 us
- 3 -> 500 us
- 4 -> 1 ms
- 5 -> 5 ms
- 6 -> 10 ms
- 7 -> 50 ms
-- st,settling : Panel driver settling time (recommended is 2)
- 0 -> 10 us
- 1 -> 100 us
- 2 -> 500 us
- 3 -> 1 ms
- 4 -> 5 ms
- 5 -> 10 ms
- 6 -> 50 ms
- 7 -> 100 ms
-- st,fraction-z : Length of the fractional part in z (recommended is 7)
- (fraction-z ([0..7]) = Count of the fractional part)
-- st,i-drive : current limit value of the touchscreen drivers
- 0 -> 20 mA (typical 35mA max)
- 1 -> 50 mA (typical 80 mA max)
-
-Optional properties common with MFD (deprecated):
- - st,sample-time : ADC conversion time in number of clock.
- 0 -> 36 clocks
- 1 -> 44 clocks
- 2 -> 56 clocks
- 3 -> 64 clocks
- 4 -> 80 clocks (recommended)
- 5 -> 96 clocks
- 6 -> 124 clocks
- - st,mod-12b : ADC Bit mode
- 0 -> 10bit ADC
- 1 -> 12bit ADC
- - st,ref-sel : ADC reference source
- 0 -> internal
- 1 -> external
- - st,adc-freq : ADC Clock speed
- 0 -> 1.625 MHz
- 1 -> 3.25 MHz
- 2 || 3 -> 6.5 MHz
-
-Node should be child node of stmpe node to which it belongs.
-
-Note that common ADC settings of stmpe_touchscreen (child) will take precedence
-over the settings done in MFD.
-
-Example:
-
-stmpe811@41 {
- compatible = "st,stmpe811";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_touch_int>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x41>;
- interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
- interrupt-parent = <&gpio4>;
- interrupt-controller;
- id = <0>;
- blocks = <0x5>;
- irq-trigger = <0x1>;
- /* Common ADC settings */
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
-
- stmpe_touchscreen {
- compatible = "st,stmpe-ts";
- reg = <0>;
- /* 8 sample average control */
- st,ave-ctrl = <3>;
- /* 5 ms touch detect interrupt delay */
- st,touch-det-delay = <5>;
- /* 1 ms panel driver settling time */
- st,settling = <3>;
- /* 7 length fractional part in z */
- st,fraction-z = <7>;
- /*
- * 50 mA typical 80 mA max touchscreen drivers
- * current limit value
- */
- st,i-drive = <1>;
- };
- stmpe_adc {
- compatible = "st,stmpe-adc";
- st,norequest-mask = <0x0F>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
index 895592d..431c133 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
@@ -10,6 +10,13 @@
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
properties:
+ panel:
+ description: If this touchscreen is integrally connected to a panel, this
+ is a reference to that panel. The presence of this reference indicates
+ that the touchscreen should be power sequenced together with the panel
+ and that they may share power and/or reset signals.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
touchscreen-min-x:
description: minimum x coordinate reported
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ed00f61..210486a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,7 +6,7 @@
- ti,x-plate-ohms: X-plate resistance in ohms.
Optional properties:
-- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
+- gpios: the interrupt gpio the chip is connected to (through the penirq pin).
The penirq pin goes to low when the panel is touched.
(see GPIO binding[1] for more details).
- interrupts: (gpio) interrupt to which the chip is connected
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
index 5d17bdc..73f809c 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
@@ -25,14 +25,20 @@
- const: qcom,msm8998-bwmon # BWMON v4
- items:
- enum:
+ - qcom,sc7180-cpu-bwmon
- qcom,sc7280-cpu-bwmon
- qcom,sc8280xp-cpu-bwmon
- qcom,sdm845-cpu-bwmon
+ - qcom,sm6350-llcc-bwmon
+ - qcom,sm8250-cpu-bwmon
- qcom,sm8550-cpu-bwmon
- const: qcom,sdm845-bwmon # BWMON v4, unified register space
- items:
- enum:
+ - qcom,sc7180-llcc-bwmon
- qcom,sc8280xp-llcc-bwmon
+ - qcom,sm6350-cpu-bwmon
+ - qcom,sm8250-llcc-bwmon
- qcom,sm8550-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon # BWMON v5
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
index 9d0a98d..21dae0b 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
@@ -21,6 +21,7 @@
- enum:
- qcom,sc7180-osm-l3
- qcom,sc8180x-osm-l3
+ - qcom,sdm670-osm-l3
- qcom,sdm845-osm-l3
- qcom,sm6350-osm-l3
- qcom,sm8150-osm-l3
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
index 4d93ad41..a46497a 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
@@ -18,9 +18,6 @@
least one RPMh device child node pertaining to their RSC and each provider
can map to multiple RPMh resources.
-allOf:
- - $ref: qcom,rpmh-common.yaml#
-
properties:
reg:
maxItems: 1
@@ -91,6 +88,7 @@
- qcom,sm8250-mc-virt
- qcom,sm8250-mmss-noc
- qcom,sm8250-npu-noc
+ - qcom,sm8250-qup-virt
- qcom,sm8250-system-noc
- qcom,sm8350-aggre1-noc
- qcom,sm8350-aggre2-noc
@@ -107,7 +105,19 @@
required:
- compatible
- - reg
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8250-qup-virt
+ then:
+ required:
+ - reg
+
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
index e84e4f3..3d06db9 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
@@ -35,6 +35,7 @@
- amlogic,meson-sm1-gpio-intc
- amlogic,meson-a1-gpio-intc
- amlogic,meson-s4-gpio-intc
+ - amlogic,c3-gpio-intc
- const: amlogic,meson-gpio-intc
reg:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
index 39e64c7..2bc3847 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -49,7 +49,7 @@
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
- range [0-15]. Extented SPI interrupts are in the range [0-1023].
+ range [0-15]. Extended SPI interrupts are in the range [0-1023].
Extended PPI interrupts are in the range [0-127].
The 3rd cell is the flags, encoded as follows:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
index 2a1d16b..ea939f5 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
@@ -6,7 +6,7 @@
instance can handle up to 32 interrupts.
Required properties:
-- compatible: "arm,versatile-fpga-irq" or "oxsemi,ox810se-rps-irq"
+- compatible: "arm,versatile-fpga-irq"
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: The number of cells to define the interrupts. Must be 1
as the FPGA IRQ controller has no configuration options for interrupt
@@ -19,6 +19,8 @@
the system till not make it possible for devices to request these
interrupts.
+The "oxsemi,ox810se-rps-irq" compatible is deprecated.
+
Example:
pic: pic@14000000 {
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
index 0f1af5a..bdd1730 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
@@ -70,7 +70,7 @@
25: DMA9
26: DMA10
27: DMA11-14 - shared interrupt for DMA 11 to 14
-28: DMAALL - triggers on all dma interrupts (including chanel 15)
+28: DMAALL - triggers on all dma interrupts (including channel 15)
29: AUX
30: ARM
31: VPUDMA
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
index c680de1c..786f242 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
@@ -59,7 +59,7 @@
..
31 ........................ X
- The BCM3380 Level 1 / Level 2 interrrupt controller shows up in various forms
+ The BCM3380 Level 1 / Level 2 interrupt controller shows up in various forms
on many BCM338x/BCM63xx chipsets. It has the following properties:
- outputs a single interrupt signal to its interrupt controller parent
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
index a106ba6..4847b04 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
@@ -31,6 +31,7 @@
- qcom,sc7180-pdc
- qcom,sc7280-pdc
- qcom,sc8280xp-pdc
+ - qcom,sdm670-pdc
- qcom,sdm845-pdc
- qcom,sdx55-pdc
- qcom,sdx65-pdc
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
index 65523d9..3cd5a18 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/ti,pruss-intc.yaml#
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 3a31a97..cf29ab1 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -270,6 +270,47 @@
contains:
enum:
- qcom,msm8998-smmu-v2
+ then:
+ anyOf:
+ - properties:
+ clock-names:
+ items:
+ - const: bus
+ clocks:
+ items:
+ - description: bus clock required for downstream bus access and for
+ the smmu ptw
+ - properties:
+ clock-names:
+ items:
+ - const: iface
+ - const: mem
+ - const: mem_iface
+ clocks:
+ items:
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+ - description: bus clock required for memory access
+ - description: bus clock required for GPU memory access
+ - properties:
+ clock-names:
+ items:
+ - const: iface-mm
+ - const: iface-smmu
+ - const: bus-smmu
+ clocks:
+ items:
+ - description: interface clock required to access mnoc's registers
+ through the TCU's programming interface.
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+ - description: bus clock required for the smmu ptw
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,sdm630-smmu-v2
- qcom,sm6375-smmu-v2
then:
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index 5b6395b..ea6b0f5 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -78,6 +78,9 @@
- mediatek,mt8173-m4u # generation two
- mediatek,mt8183-m4u # generation two
- mediatek,mt8186-iommu-mm # generation two
+ - mediatek,mt8188-iommu-vdo # generation two
+ - mediatek,mt8188-iommu-vpp # generation two
+ - mediatek,mt8188-iommu-infra # generation two
- mediatek,mt8192-m4u # generation two
- mediatek,mt8195-iommu-vdo # generation two
- mediatek,mt8195-iommu-vpp # generation two
@@ -123,6 +126,7 @@
description: |
This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as
defined in
+ dt-binding/memory/mediatek,mt8188-memory-port.h for mt8188,
dt-binding/memory/mt2701-larb-port.h for mt2701 and mt7623,
dt-binding/memory/mt2712-larb-port.h for mt2712,
dt-binding/memory/mt6779-larb-port.h for mt6779,
@@ -155,6 +159,8 @@
- mediatek,mt6795-m4u
- mediatek,mt8173-m4u
- mediatek,mt8186-iommu-mm
+ - mediatek,mt8188-iommu-vdo
+ - mediatek,mt8188-iommu-vpp
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@@ -168,6 +174,8 @@
compatible:
enum:
- mediatek,mt8186-iommu-mm
+ - mediatek,mt8188-iommu-vdo
+ - mediatek,mt8188-iommu-vpp
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@@ -194,7 +202,9 @@
properties:
compatible:
contains:
- const: mediatek,mt8195-iommu-infra
+ enum:
+ - mediatek,mt8188-iommu-infra
+ - mediatek,mt8195-iommu-infra
then:
required:
diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml
index d9fabdf..a74eb89 100644
--- a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml
@@ -17,11 +17,16 @@
properties:
compatible:
- items:
- - enum:
- - qcom,msm8916-iommu
- - qcom,msm8953-iommu
- - const: qcom,msm-iommu-v1
+ oneOf:
+ - items:
+ - enum:
+ - qcom,msm8916-iommu
+ - qcom,msm8953-iommu
+ - const: qcom,msm-iommu-v1
+ - items:
+ - enum:
+ - qcom,msm8976-iommu
+ - const: qcom,msm-iommu-v2
clocks:
items:
@@ -64,6 +69,8 @@
enum:
- qcom,msm-iommu-v1-ns
- qcom,msm-iommu-v1-sec
+ - qcom,msm-iommu-v2-ns
+ - qcom,msm-iommu-v2-sec
interrupts:
maxItems: 1
@@ -71,6 +78,11 @@
reg:
maxItems: 1
+ qcom,ctx-asid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The ASID number associated to the context bank.
+
required:
- compatible
- interrupts
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
index be1539d..3528b81 100644
--- a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
+++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml#
diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
index 4ff6fab..129e32c 100644
--- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
@@ -41,7 +41,7 @@
- description: STR register
aspeed,lpc-io-reg:
- $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 2
description: |
@@ -50,7 +50,7 @@
status address may be optionally provided.
aspeed,lpc-interrupts:
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
description: |
@@ -63,12 +63,12 @@
kcs_chan:
deprecated: true
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: The LPC channel number in the controller
kcs_addr:
deprecated: true
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: The host CPU IO map address
required:
diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml
index 3f25cdb..52647bf 100644
--- a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml
+++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml
@@ -18,7 +18,7 @@
device_type:
items:
- - const: "ipmi"
+ - const: ipmi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
index c1b4bf9..4bffa3d 100644
--- a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
+++ b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
@@ -20,7 +20,7 @@
device_type:
items:
- - const: "ipmi"
+ - const: ipmi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
index 5533b65..16fc98e 100644
--- a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
@@ -66,7 +66,7 @@
mediatek,bled-ocp-shutdown:
description: |
- Enable the backlight shutdown when OCP level triggerred.
+ Enable the backlight shutdown when OCP level triggered.
type: boolean
mediatek,bled-ocp-microamp:
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 58b492d..5fb7007 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -83,8 +83,7 @@
- enum:
# LED will act as a back-light, controlled by the framebuffer system
- backlight
- # LED will turn on (but for leds-gpio see "default-state" property in
- # Documentation/devicetree/bindings/leds/leds-gpio.yaml)
+ # LED will turn on (see also "default-state" property)
- default-on
# LED "double" flashes at a load average based rate
- heartbeat
@@ -158,6 +157,18 @@
For flash LED controllers with configurable current this property is
mandatory for the LEDs in the non-flash modes (e.g. torch or indicator).
+ max-brightness:
+ description:
+ Normally, the maximum brightness is determined by the hardware, and this
+ property is not required. This property is used to set a software limit.
+ It could happen that an LED is made so bright that it gets damaged or
+ causes damage due to restrictions in a specific system, such as mounting
+ conditions.
+ Note that this flag is mainly used for PWM-LEDs, where it is not possible
+ to map brightness to current. Drivers for other controllers should use
+ led-max-microamp.
+ $ref: /schemas/types.yaml#definitions/uint32
+
panic-indicator:
description:
This property specifies that the LED should be used, if at all possible,
diff --git a/Documentation/devicetree/bindings/leds/leds-an30259a.txt b/Documentation/devicetree/bindings/leds/leds-an30259a.txt
deleted file mode 100644
index cbd8339..0000000
--- a/Documentation/devicetree/bindings/leds/leds-an30259a.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-* Panasonic AN30259A 3-channel LED driver
-
-The AN30259A is a LED controller capable of driving three LEDs independently. It supports
-constant current output and sloping current output modes. The chip is connected over I2C.
-
-Required properties:
- - compatible: Must be "panasonic,an30259a".
- - reg: I2C slave address.
- - #address-cells: Must be 1.
- - #size-cells: Must be 0.
-
-Each LED is represented as a sub-node of the panasonic,an30259a node.
-
-Required sub-node properties:
- - reg: Pin that the LED is connected to. Must be 1, 2, or 3.
-
-Optional sub-node properties:
- - function :
- see Documentation/devicetree/bindings/leds/common.txt
- - color :
- see Documentation/devicetree/bindings/leds/common.txt
- - label :
- see Documentation/devicetree/bindings/leds/common.txt (deprecated)
- - linux,default-trigger :
- see Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
-#include <dt-bindings/leds/common.h>
-
-led-controller@30 {
- compatible = "panasonic,an30259a";
- reg = <0x30>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- led@1 {
- reg = <1>;
- linux,default-trigger = "heartbeat";
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_RED>;
- };
-
- led@2 {
- reg = <2>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_GREEN>;
- };
-
- led@3 {
- reg = <3>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_BLUE>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
index 08f3e1c..2623844 100644
--- a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
@@ -20,9 +20,20 @@
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+ description: Open-drain, low active interrupt pin "INTN".
+ Used to report completion of operations (power up, LED breath effects).
+
vcc-supply:
description: Regulator providing power to the "VCC" pin.
+ vio-supply:
+ description: Regulator providing power for pull-up of the I/O lines.
+ "VIO1" in the typical application circuit example of the datasheet.
+ Note that this regulator does not directly connect to AW2013, but is
+ needed for the correct operation of the interrupt and I2C lines.
+
"#address-cells":
const: 1
@@ -52,6 +63,7 @@
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
i2c {
@@ -61,6 +73,7 @@
led-controller@45 {
compatible = "awinic,aw2013";
reg = <0x45>;
+ interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
new file mode 100644
index 0000000..8ed059a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-group-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Multi-color LED built with monochromatic LEDs
+
+maintainers:
+ - Jean-Jacques Hiblot <jjhiblot@traphandler.com>
+
+description: |
+ This driver combines several monochromatic LEDs into one multi-color
+ LED using the multicolor LED class.
+
+properties:
+ compatible:
+ const: leds-group-multicolor
+
+ leds:
+ description:
+ An aray of monochromatic leds
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+required:
+ - leds
+
+allOf:
+ - $ref: leds-class-multicolor.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ monochromatic-leds {
+ compatible = "gpio-leds";
+
+ led0: led-0 {
+ gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led1: led-1 {
+ gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led2: led-2 {
+ gpios = <&mcu_pio 2 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
+ multi-led {
+ compatible = "leds-group-multicolor";
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ leds = <&led0>, <&led1>, <&led2>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
index 058be1f..e9d4514 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
@@ -106,7 +106,7 @@
max-cur:
$ref: /schemas/types.yaml#/definitions/uint8
- description: Maximun current at each LED channel.
+ description: Maximum current at each LED channel.
reg:
maximum: 8
@@ -129,7 +129,7 @@
max-cur:
$ref: /schemas/types.yaml#/definitions/uint8
- description: Maximun current at each LED channel.
+ description: Maximum current at each LED channel.
reg:
description: |
diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
index e6f1999..ea84ad4 100644
--- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
@@ -56,7 +56,7 @@
description: >
A list of integer pairs, where each pair represent the dtest line the
particular channel should be connected to and the flags denoting how the
- value should be outputed, as defined in the datasheet. The number of
+ value should be outputted, as defined in the datasheet. The number of
pairs should be the same as the number of channels.
items:
items:
diff --git a/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml
index edf6f55..9610bca 100644
--- a/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml
+++ b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml
@@ -29,6 +29,10 @@
gpio-controller: true
+ gpio-line-names:
+ minItems: 1
+ maxItems: 16
+
'#gpio-cells':
const: 2
diff --git a/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml
new file mode 100644
index 0000000..654915c
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/nxp,pca995x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA995x LED controllers
+
+maintainers:
+ - Isai Gaspar <isaiezequiel.gaspar@nxp.com>
+ - Marek Vasut <marex@denx.de>
+
+description:
+ The NXP PCA9952/PCA9955B are programmable LED controllers connected via I2C
+ that can drive 16 separate lines. Each of them can be individually switched
+ on and off, and brightness can be controlled via individual PWM.
+
+ Datasheets are available at
+ https://www.nxp.com/docs/en/data-sheet/PCA9952_PCA9955.pdf
+ https://www.nxp.com/docs/en/data-sheet/PCA9955B.pdf
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9952
+ - nxp,pca9955b
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-9a-f]+$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 15
+
+ required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1 {
+ compatible = "nxp,pca9955b";
+ reg = <0x01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_POWER;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_STATUS;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml b/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml
new file mode 100644
index 0000000..e918dce
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/panasonic,an30259a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Panasonic AN30259A 3-channel LED controller
+
+maintainers:
+ - Iskren Chernev <me@iskren.info>
+
+description:
+ The AN30259A is a LED controller capable of driving three LEDs independently.
+ It supports constant current output and sloping current output modes. The chip
+ is connected over I2C.
+
+properties:
+ compatible:
+ const: panasonic,an30259a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[1-3]$":
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [ 1, 2, 3 ]
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@30 {
+ compatible = "panasonic,an30259a";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ linux,default-trigger = "heartbeat";
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml
index 14700a2..44dd91a 100644
--- a/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml
+++ b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml
@@ -35,7 +35,7 @@
description: GPIO pin to enable/disable the device.
patternProperties:
- "^led@[0-6]$":
+ "^led@[0-5]$":
type: object
$ref: common.yaml#
unevaluatedProperties: false
@@ -43,7 +43,7 @@
properties:
reg:
minimum: 0
- maximum: 6
+ maximum: 5
required:
- reg
diff --git a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
index 58f0d94..b7a3ef7 100644
--- a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
+++ b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
@@ -18,8 +18,6 @@
The device has two LED outputs referred as GRNLED and AMBLED in data-sheet.
-select: false
-
properties:
compatible:
const: rohm,bd71828-leds
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
index 752ae6b..c80065a 100644
--- a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
@@ -29,7 +29,7 @@
where N is the value specified by 2nd cell above. If FlexRM
does not get required number of completion messages in time
specified by this cell then it will inject one MSI interrupt
- to CPU provided atleast one completion message is available.
+ to CPU provided at least one completion message is available.
Optional properties:
--------------------
diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
index d433e49..1a2001e 100644
--- a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml#
@@ -159,7 +159,7 @@
a corresponding sysc interconnect node.
This property is only needed on some legacy OMAP SoCs which have not
- yet been converted to the ti,sysc interconnect hierarachy, but is
+ yet been converted to the ti,sysc interconnect hierarchy, but is
otherwise considered obsolete.
patternProperties:
diff --git a/Documentation/devicetree/bindings/media/amphion,vpu.yaml b/Documentation/devicetree/bindings/media/amphion,vpu.yaml
index a9d80ea..c0d83d7 100644
--- a/Documentation/devicetree/bindings/media/amphion,vpu.yaml
+++ b/Documentation/devicetree/bindings/media/amphion,vpu.yaml
@@ -47,7 +47,7 @@
$ref: ../mailbox/fsl,mu.yaml#
- "^vpu_core@[0-9a-f]+$":
+ "^vpu-core@[0-9a-f]+$":
description:
Each core correspond a decoder or encoder, need to configure them
separately. NXP i.MX8QM SoC has one decoder and two encoder, i.MX8QXP SoC
@@ -143,7 +143,7 @@
power-domains = <&pd IMX_SC_R_VPU_MU_2>;
};
- vpu_core0: vpu_core@2d080000 {
+ vpu_core0: vpu-core@2d080000 {
compatible = "nxp,imx8q-vpu-decoder";
reg = <0x2d080000 0x10000>;
power-domains = <&pd IMX_SC_R_VPU_DEC_0>;
@@ -154,7 +154,7 @@
memory-region = <&decoder_boot>, <&decoder_rpc>;
};
- vpu_core1: vpu_core@2d090000 {
+ vpu_core1: vpu-core@2d090000 {
compatible = "nxp,imx8q-vpu-encoder";
reg = <0x2d090000 0x10000>;
power-domains = <&pd IMX_SC_R_VPU_ENC_0>;
@@ -165,7 +165,7 @@
memory-region = <&encoder1_boot>, <&encoder1_rpc>;
};
- vpu_core2: vpu_core@2d0a0000 {
+ vpu_core2: vpu-core@2d0a0000 {
reg = <0x2d0a0000 0x10000>;
compatible = "nxp,imx8q-vpu-encoder";
power-domains = <&pd IMX_SC_R_VPU_ENC_1>;
diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
deleted file mode 100644
index 6b02a06..0000000
--- a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Cadence MIPI-CSI2 RX controller
-===============================
-
-The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
-lanes in input, and 4 different pixel streams in output.
-
-Required properties:
- - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
- - reg: base address and size of the memory mapped region
- - clocks: phandles to the clocks driving the controller
- - clock-names: must contain:
- * sys_clk: main clock
- * p_clk: register bank clock
- * pixel_if[0-3]_clk: pixel stream output clock, one for each stream
- implemented in hardware, between 0 and 3
-
-Optional properties:
- - phys: phandle to the external D-PHY, phy-names must be provided
- - phy-names: must contain "dphy", if the implementation uses an
- external D-PHY
-
-Required subnodes:
- - ports: A ports node with 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 Description
- -----------------------------
- 0 CSI-2 input
- 1 Stream 0 output
- 2 Stream 1 output
- 3 Stream 2 output
- 4 Stream 3 output
-
- The stream output port nodes are optional if they are not
- connected to anything at the hardware level or implemented
- in the design.Since there is only one endpoint per port,
- the endpoints are not numbered.
-
-
-Example:
-
-csi2rx: csi-bridge@0d060000 {
- compatible = "cdns,csi2rx";
- reg = <0x0d060000 0x1000>;
- clocks = <&byteclock>, <&byteclock>
- <&coreclock>, <&coreclock>,
- <&coreclock>, <&coreclock>;
- clock-names = "sys_clk", "p_clk",
- "pixel_if0_clk", "pixel_if1_clk",
- "pixel_if2_clk", "pixel_if3_clk";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- csi2rx_in_sensor: endpoint {
- remote-endpoint = <&sensor_out_csi2rx>;
- clock-lanes = <0>;
- data-lanes = <1 2>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- csi2rx_out_grabber0: endpoint {
- remote-endpoint = <&grabber0_in_csi2rx>;
- };
- };
-
- port@2 {
- reg = <2>;
-
- csi2rx_out_grabber1: endpoint {
- remote-endpoint = <&grabber1_in_csi2rx>;
- };
- };
-
- port@3 {
- reg = <3>;
-
- csi2rx_out_grabber2: endpoint {
- remote-endpoint = <&grabber2_in_csi2rx>;
- };
- };
-
- port@4 {
- reg = <4>;
-
- csi2rx_out_grabber3: endpoint {
- remote-endpoint = <&grabber3_in_csi2rx>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
new file mode 100644
index 0000000..30a335b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
@@ -0,0 +1,201 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cdns,csi2rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MIPI-CSI2 RX controller
+
+maintainers:
+ - Maxime Ripard <mripard@kernel.org>
+
+description:
+ The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+ lanes in input, and 4 different pixel streams in output.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - starfive,jh7110-csi2rx
+ - const: cdns,csi2rx
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: CSI2Rx system clock
+ - description: Gated Register bank clock for APB interface
+ - description: pixel Clock for Stream interface 0
+ - description: pixel Clock for Stream interface 1
+ - description: pixel Clock for Stream interface 2
+ - description: pixel Clock for Stream interface 3
+
+ clock-names:
+ items:
+ - const: sys_clk
+ - const: p_clk
+ - const: pixel_if0_clk
+ - const: pixel_if1_clk
+ - const: pixel_if2_clk
+ - const: pixel_if3_clk
+
+ resets:
+ items:
+ - description: CSI2Rx system reset
+ - description: Gated Register bank reset for APB interface
+ - description: pixel reset for Stream interface 0
+ - description: pixel reset for Stream interface 1
+ - description: pixel reset for Stream interface 2
+ - description: pixel reset for Stream interface 3
+
+ reset-names:
+ items:
+ - const: sys
+ - const: reg_bank
+ - const: pixel_if0
+ - const: pixel_if1
+ - const: pixel_if2
+ - const: pixel_if3
+
+ phys:
+ maxItems: 1
+ description: MIPI D-PHY
+
+ phy-names:
+ items:
+ - const: dphy
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ const: 4
+
+ clock-lanes:
+ const: 0
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 4
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 0 Output port node
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 1 Output port node
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 2 Output port node
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 3 Output port node
+
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ csi@d060000 {
+ compatible = "starfive,jh7110-csi2rx", "cdns,csi2rx";
+ reg = <0x0d060000 0x1000>;
+ clocks = <&byteclock 7>, <&byteclock 6>,
+ <&coreclock 8>, <&coreclock 9>,
+ <&coreclock 10>, <&coreclock 11>;
+ clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+ resets = <&bytereset 9>, <&bytereset 4>,
+ <&corereset 5>, <&corereset 6>,
+ <&corereset 7>, <&corereset 8>;
+ reset-names = "sys", "reg_bank",
+ "pixel_if0", "pixel_if1",
+ "pixel_if2", "pixel_if3";
+ phys = <&csi_phy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csi2rx_in_sensor: endpoint {
+ remote-endpoint = <&sensor_out_csi2rx>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csi2rx_out_grabber0: endpoint {
+ remote-endpoint = <&grabber0_in_csi2rx>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ csi2rx_out_grabber1: endpoint {
+ remote-endpoint = <&grabber1_in_csi2rx>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ csi2rx_out_grabber2: endpoint {
+ remote-endpoint = <&grabber2_in_csi2rx>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ csi2rx_out_grabber3: endpoint {
+ remote-endpoint = <&grabber3_in_csi2rx>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
index 369c48f..a6b7349 100644
--- a/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
+++ b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
@@ -53,6 +53,5 @@
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA124_CLK_CEC>;
clock-names = "cec";
- status = "disabled";
hdmi-phandle = <&hdmi>;
};
diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
index 19a39d7..b681412 100644
--- a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
@@ -143,7 +143,6 @@
mipid02: csi2rx@14 {
compatible = "st,st-mipid02";
reg = <0x14>;
- status = "okay";
clocks = <&clk_ext_camera_12>;
clock-names = "xclk";
VDDE-supply = <&vdd>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml
new file mode 100644
index 0000000..f6612bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub913.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DS90UB913 FPD-Link III Serializer
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ The TI DS90UB913 is an FPD-Link III video serializer for parallel video.
+
+properties:
+ compatible:
+ enum:
+ - ti,ds90ub913a-q1
+
+ '#gpio-cells':
+ const: 2
+ description:
+ First cell is the GPO pin number, second cell is the flags. The GPO pin
+ number must be in range of [0, 3]. Note that GPOs 2 and 3 are not
+ available in external oscillator mode.
+
+ gpio-controller: true
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference clock connected to the CLKIN pin.
+
+ clock-names:
+ items:
+ - const: clkin
+
+ '#clock-cells':
+ const: 0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Parallel input port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - pclk-sample
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ description: FPD-Link III output port
+
+ required:
+ - port@0
+ - port@1
+
+ i2c:
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - '#gpio-cells'
+ - gpio-controller
+ - '#clock-cells'
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ serializer {
+ compatible = "ti,ds90ub913a-q1";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ clocks = <&clk_cam_48M>;
+ clock-names = "clkin";
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub913_in: endpoint {
+ remote-endpoint = <&sensor_out>;
+ pclk-sample = <1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&deser_fpd_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+
+ clocks = <&fixed_clock>;
+
+ port {
+ sensor_out: endpoint {
+ remote-endpoint = <&ub913_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml
new file mode 100644
index 0000000..2030366
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.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/ti,ds90ub953.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DS90UB953 FPD-Link III Serializer
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ The TI DS90UB953 is an FPD-Link III video serializer for MIPI CSI-2.
+
+properties:
+ compatible:
+ enum:
+ - ti,ds90ub953-q1
+ - ti,ds90ub971-q1
+
+ '#gpio-cells':
+ const: 2
+ description:
+ First cell is the GPIO pin number, second cell is the flags. The GPIO pin
+ number must be in range of [0, 3].
+
+ gpio-controller: true
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference clock connected to the CLKIN pin.
+
+ clock-names:
+ items:
+ - const: clkin
+
+ '#clock-cells':
+ const: 0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 input port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ description: FPD-Link III output port
+
+ required:
+ - port@0
+ - port@1
+
+ i2c:
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - '#gpio-cells'
+ - gpio-controller
+ - '#clock-cells'
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ serializer {
+ compatible = "ti,ds90ub953-q1";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub953_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&sensor_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&deser_fpd_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@1a {
+ compatible = "sony,imx274";
+ reg = <0x1a>;
+
+ reset-gpios = <&serializer 0 GPIO_ACTIVE_LOW>;
+
+ clocks = <&serializer>;
+ clock-names = "inck";
+
+ port {
+ sensor_out: endpoint {
+ remote-endpoint = <&ub953_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml
new file mode 100644
index 0000000..2897377
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml
@@ -0,0 +1,427 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DS90UB9XX Family FPD-Link Deserializer Hubs
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ The TI DS90UB9XX devices are FPD-Link video deserializers with I2C and GPIO
+ forwarding.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-atr.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,ds90ub960-q1
+ - ti,ds90ub9702-q1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference clock connected to the REFCLK pin.
+
+ clock-names:
+ items:
+ - const: refclk
+
+ powerdown-gpios:
+ maxItems: 1
+ description:
+ Specifier for the GPIO connected to the PDB pin.
+
+ i2c-alias-pool:
+ minItems: 1
+ maxItems: 32
+
+ links:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ ti,manual-strobe:
+ type: boolean
+ description:
+ Enable manual strobe position and EQ level
+
+ patternProperties:
+ '^link@[0-3]$':
+ type: object
+ additionalProperties: false
+ properties:
+ reg:
+ description: The link number
+ maxItems: 1
+
+ i2c-alias:
+ description:
+ The I2C address used for the serializer. Transactions to this
+ address on the I2C bus where the deserializer resides are
+ forwarded to the serializer.
+
+ ti,rx-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # RAW10
+ - 1 # RAW12 HF
+ - 2 # RAW12 LF
+ - 3 # CSI2 SYNC
+ - 4 # CSI2 NON-SYNC
+ description:
+ FPD-Link Input Mode. This should reflect the hardware and the
+ default mode of the connected device.
+
+ ti,cdr-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # FPD-Link III
+ - 1 # FPD-Link IV
+ description:
+ FPD-Link CDR Mode. This should reflect the hardware and the
+ default mode of the connected device.
+
+ ti,strobe-pos:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -13
+ maximum: 13
+ description: Manual strobe position
+
+ ti,eq-level:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 14
+ description: Manual EQ level
+
+ serializer:
+ type: object
+ description: FPD-Link Serializer node
+
+ required:
+ - reg
+ - i2c-alias
+ - ti,rx-mode
+ - serializer
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 0
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 1
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 2
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 3
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output 0
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ link-frequencies:
+ maxItems: 1
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ port@5:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output 1
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ link-frequencies:
+ maxItems: 1
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - port@0
+ - port@1
+ - port@2
+ - port@3
+ - port@4
+ - port@5
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+
+ clock-names = "refclk";
+ clocks = <&fixed_clock>;
+
+ powerdown-gpios = <&pca9555 7 GPIO_ACTIVE_LOW>;
+
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Port 0, Camera 0 */
+ port@0 {
+ reg = <0>;
+
+ ub960_fpd3_1_in: endpoint {
+ remote-endpoint = <&ub953_1_out>;
+ };
+ };
+
+ /* Port 1, Camera 1 */
+ port@1 {
+ reg = <1>;
+
+ ub960_fpd3_2_in: endpoint {
+ remote-endpoint = <&ub913_2_out>;
+ hsync-active = <0>;
+ vsync-active = <1>;
+ };
+ };
+
+ /* Port 2, unconnected */
+ port@2 {
+ reg = <2>;
+ };
+
+ /* Port 3, unconnected */
+ port@3 {
+ reg = <3>;
+ };
+
+ /* Port 4, CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ /* Port 5, unconnected */
+ port@5 {
+ reg = <5>;
+ };
+ };
+
+ links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Link 0 has DS90UB953 serializer and IMX274 sensor */
+
+ link@0 {
+ reg = <0>;
+ i2c-alias = <0x44>;
+
+ ti,rx-mode = <3>;
+
+ serializer1: serializer {
+ compatible = "ti,ds90ub953-q1";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub953_1_in: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&sensor_1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ub953_1_out: endpoint {
+ remote-endpoint = <&ub960_fpd3_1_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@1a {
+ compatible = "sony,imx274";
+ reg = <0x1a>;
+
+ reset-gpios = <&serializer1 0 GPIO_ACTIVE_LOW>;
+
+ port {
+ sensor_1_out: endpoint {
+ remote-endpoint = <&ub953_1_in>;
+ };
+ };
+ };
+ };
+ };
+ }; /* End of link@0 */
+
+ /* Link 1 has DS90UB913 serializer and MT9V111 sensor */
+
+ link@1 {
+ reg = <1>;
+ i2c-alias = <0x45>;
+
+ ti,rx-mode = <0>;
+
+ serializer2: serializer {
+ compatible = "ti,ds90ub913a-q1";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ clocks = <&clk_cam_48M>;
+ clock-names = "clkin";
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub913_2_in: endpoint {
+ remote-endpoint = <&sensor_2_out>;
+ pclk-sample = <1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ub913_2_out: endpoint {
+ remote-endpoint = <&ub960_fpd3_2_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+
+ clocks = <&serializer2>;
+
+ port {
+ sensor_2_out: endpoint {
+ remote-endpoint = <&ub913_2_in>;
+ };
+ };
+ };
+ };
+ };
+ }; /* End of link@1 */
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
index b8ba85a..c5cab54 100644
--- a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
@@ -12,7 +12,7 @@
description: |-
The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2
stream. The direction can be either parallel-in -> csi-out or csi-in ->
- parallel-out The chip is programmable trough I2C and SPI but the SPI
+ parallel-out The chip is programmable through I2C and SPI but the SPI
interface is only supported in parallel-in -> csi-out mode.
Note that the current device tree bindings only support the
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
index 719b299..94b908a 100644
--- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
+++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
@@ -53,7 +53,7 @@
==============================
- sdtv-standards: Set the possible signals to which the hardware tries to lock
- instead of using the autodetection mechnism. Please look at
+ instead of using the autodetection mechanism. Please look at
[1] for more information.
[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml.
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
index fad59b4..b401c67 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
@@ -21,24 +21,33 @@
- mediatek,mt8183-vcodec-dec
reg:
- maxItems: 12
+ minItems: 11
+ maxItems: 11
+
+ reg-names:
+ items:
+ - const: misc
+ - const: ld
+ - const: top
+ - const: cm
+ - const: ad
+ - const: av
+ - const: pp
+ - const: hwd
+ - const: hwq
+ - const: hwb
+ - const: hwg
interrupts:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 8
clock-names:
- items:
- - const: vcodecpll
- - const: univpll_d2
- - const: clk_cci400_sel
- - const: vdec_sel
- - const: vdecpll
- - const: vencpll
- - const: venc_lt_sel
- - const: vdec_bus_clk_src
+ minItems: 1
+ maxItems: 8
assigned-clocks: true
@@ -66,6 +75,10 @@
description:
Describes point to scp.
+ mediatek,vdecsys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the vdecsys syscon node.
+
required:
- compatible
- reg
@@ -73,8 +86,7 @@
- clocks
- clock-names
- iommus
- - assigned-clocks
- - assigned-clock-parents
+ - mediatek,vdecsys
allOf:
- if:
@@ -88,6 +100,15 @@
required:
- mediatek,scp
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: vdec
+
- if:
properties:
compatible:
@@ -99,6 +120,22 @@
required:
- mediatek,vpu
+ properties:
+ clocks:
+ minItems: 8
+ maxItems: 8
+
+ clock-names:
+ items:
+ - const: vcodecpll
+ - const: univpll_d2
+ - const: clk_cci400_sel
+ - const: vdec_sel
+ - const: vdecpll
+ - const: vencpll
+ - const: venc_lt_sel
+ - const: vdec_bus_clk_src
+
additionalProperties: false
examples:
@@ -109,10 +146,9 @@
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/mt8173-power.h>
- vcodec_dec: vcodec@16000000 {
+ vcodec_dec: vcodec@16020000 {
compatible = "mediatek,mt8173-vcodec-dec";
- reg = <0x16000000 0x100>, /*VDEC_SYS*/
- <0x16020000 0x1000>, /*VDEC_MISC*/
+ reg = <0x16020000 0x1000>, /*VDEC_MISC*/
<0x16021000 0x800>, /*VDEC_LD*/
<0x16021800 0x800>, /*VDEC_TOP*/
<0x16022000 0x1000>, /*VDEC_CM*/
@@ -133,6 +169,7 @@
<&iommu M4U_PORT_HW_VDEC_VLD_EXT>,
<&iommu M4U_PORT_HW_VDEC_VLD2_EXT>;
mediatek,vpu = <&vpu>;
+ mediatek,vdecsys = <&vdecsys>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>,
<&topckgen CLK_TOP_UNIVPLL_D2>,
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
index dca9b0c..a500a58 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
@@ -36,7 +36,7 @@
controls the information of each hardware independent which include clk/power/irq.
There are two workqueues in parent device: lat workqueue and core workqueue. They are used
- to lat and core hardware deocder. Lat workqueue need to get input bitstream and lat buffer,
+ to lat and core hardware decoder. Lat workqueue need to get input bitstream and lat buffer,
then enable lat to decode, writing the result to lat buffer, dislabe hardware when lat decode
done. Core workqueue need to get lat buffer and output buffer, then enable core to decode,
writing the result to output buffer, disable hardware when core decode done. These two
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
index 6038b9b..e466546 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
@@ -21,6 +21,7 @@
enum:
- fsl,imx8mn-isi
- fsl,imx8mp-isi
+ - fsl,imx93-isi
reg:
maxItems: 1
@@ -72,7 +73,9 @@
properties:
compatible:
contains:
- const: fsl,imx8mn-isi
+ enum:
+ - fsl,imx8mn-isi
+ - fsl,imx93-isi
then:
properties:
interrupts:
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
index 2350bf4..9410f13 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
@@ -40,7 +40,7 @@
properties:
compatible:
- const: "venus-decoder"
+ const: venus-decoder
required:
- compatible
@@ -52,7 +52,7 @@
properties:
compatible:
- const: "venus-encoder"
+ const: venus-encoder
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml
index 7915dcd..f66033a 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml
@@ -106,7 +106,7 @@
#include <dt-bindings/clock/qcom,videocc-sm8250.h>
#include <dt-bindings/interconnect/qcom,sm8250.h>
#include <dt-bindings/clock/qcom,gcc-sm8250.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
venus: video-codec@aa00000 {
compatible = "qcom,sm8250-venus";
@@ -114,7 +114,7 @@
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&videocc MVS0C_GDSC>,
<&videocc MVS0_GDSC>,
- <&rpmhpd SM8250_MX>;
+ <&rpmhpd RPMHPD_MX>;
power-domain-names = "venus", "vcodec0", "mx";
clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
index a027242..b40cec0 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
@@ -39,6 +39,7 @@
patternProperties:
".*@[0-9]+$":
type: object
+ $ref: mc-peripheral-props.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
index 5acfcad1..8d9dae1 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
@@ -34,6 +34,8 @@
# The controller specific properties go here.
allOf:
- $ref: st,stm32-fmc2-ebi-props.yaml#
+ - $ref: ingenic,nemc-peripherals.yaml#
- $ref: intel,ixp4xx-expansion-peripheral-props.yaml#
+ - $ref: ti,gpmc-child.yaml#
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index aee7f6c..2381660 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -67,7 +67,7 @@
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.
+ hardware id is not consecutive from its M4U point of view.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml
index fb49203..4e4af3c 100644
--- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml
@@ -152,7 +152,7 @@
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the phy side CA line
- (incluing command line, address line and clock line) drive strength.
+ (including command line, address line and clock line) drive strength.
default: 40
rockchip,phy_ddr3_dq_drv:
@@ -305,7 +305,7 @@
description:
Defines the self-refresh power down idle period in which memories are
placed into self-refresh power down mode if bus is idle for
- srpd_lite_idle nanoseonds. This parameter is for LPDDR4 only.
+ srpd_lite_idle nanoseconds. This parameter is for LPDDR4 only.
rockchip,standby-idle-ns:
description:
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
index 75143db..b74ad9a 100644
--- a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
@@ -12,7 +12,7 @@
description:
The Zynq DDR ECC controller has an optional ECC support in half-bus width
- (16-bit) configuration. It is cappable of correcting single bit ECC errors
+ (16-bit) configuration. It is capable of correcting single bit ECC errors
and detecting double bit ECC errors.
properties:
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
index cf94176..8789e36 100644
--- a/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
+++ b/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
@@ -34,6 +34,9 @@
- allwinner,sun6i-a31-clock-reset
- fixed-factor-clock
+ required:
+ - compatible
+
allOf:
- if:
properties:
@@ -55,25 +58,17 @@
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 2
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -85,25 +80,17 @@
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -119,9 +106,6 @@
offset of the bit controlling this particular gate in
the register.
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
@@ -129,16 +113,11 @@
minItems: 1
maxItems: 32
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -150,9 +129,6 @@
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 4
description: >
@@ -162,16 +138,11 @@
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -183,16 +154,8 @@
"#reset-cells":
const: 1
- # Already checked in the main schema
- compatible: true
-
- phandle: true
-
required:
- "#reset-cells"
- - compatible
-
- additionalProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
index 16c80a7..e51f855 100644
--- a/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
+++ b/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
@@ -57,25 +57,17 @@
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -91,9 +83,6 @@
offset of the bit controlling this particular gate in
the register.
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
@@ -101,16 +90,11 @@
minItems: 1
maxItems: 32
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -122,34 +106,8 @@
"#reset-cells":
const: 1
- # Already checked in the main schema
- compatible: true
-
- phandle: true
-
required:
- "#reset-cells"
- - compatible
-
- additionalProperties: false
-
- - if:
- properties:
- compatible:
- contains:
- const: allwinner,sun8i-a23-codec-analog
-
- then:
- properties:
- # Already checked in the main schema
- compatible: true
-
- phandle: true
-
- required:
- - compatible
-
- additionalProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml
index 750996d..5dfe77a 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml
@@ -27,7 +27,7 @@
as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
management and bus snoop configuration.
- * A set of SuperIO[3] scratch registers enableing implementation of e.g. custom
+ * A set of SuperIO[3] scratch registers enabling implementation of e.g. custom
hardware management protocols for handover between the host and baseboard
management controller.
diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
index 9d83753..af692e8 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
@@ -6,6 +6,7 @@
Required properties:
- compatible: Should be "atmel,sama5d2-flexcom"
+ or "microchip,sam9x7-flexcom", "atmel,sama5d2-flexcom"
- reg: Should be the offset/length value for Flexcom dedicated
I/O registers (without USART, TWI or SPI registers).
- clocks: Should be the Flexcom peripheral clock from PMC.
diff --git a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt b/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt
index e8c5255..3c989d1 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt
@@ -6,6 +6,7 @@
- compatible: Should be one of the following:
"atmel,at91sam9260-gpbr", "syscon"
"microchip,sam9x60-gpbr", "syscon"
+ "microchip,sam9x7-gpbr", "microchip,sam9x60-gpbr", "syscon"
- reg: contains offset/length value of the GPBR memory
region.
diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
index 5f8880c..7de696e 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
@@ -8,6 +8,7 @@
"atmel,sama5d3-hlcdc"
"atmel,sama5d4-hlcdc"
"microchip,sam9x60-hlcdc"
+ "microchip,sam9x75-xlcdc"
- reg: base address and size of the HLCDC device registers.
- clock-names: the name of the 3 clocks requested by the HLCDC device.
Should contain "periph_clk", "sys_clk" and "slow_clk".
diff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
index 89d05c6..6e5f836 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
@@ -14,6 +14,7 @@
"atmel,at91sam9x5-matrix", "syscon"
"atmel,sama5d3-matrix", "syscon"
"microchip,sam9x60-matrix", "syscon"
+ "microchip,sam9x7-matrix", "atmel,at91sam9x5-matrix", "syscon"
- reg: Contains offset/length value of the Bus Matrix
memory region.
diff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
index 5696d9f..fd62add 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-smc.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
@@ -10,6 +10,7 @@
"atmel,sama5d3-smc", "syscon"
"atmel,sama5d2-smc", "syscon"
"microchip,sam9x60-smc", "syscon"
+ "microchip,sam9x7-smc", "atmel,at91sam9260-smc", "syscon"
- reg: Contains offset/length value of the SMC memory
region.
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
index 9f9a14a..cb48016 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
@@ -35,7 +35,7 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@@ -44,7 +44,7 @@
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6318-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6318-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
index 803277d..c14def1 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
@@ -35,7 +35,7 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@@ -44,7 +44,7 @@
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm63268-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm63268-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
index b9a6856..5f48209 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
@@ -35,7 +35,7 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@@ -44,7 +44,7 @@
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6328-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6328-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
index 4651fe4d..f1f4629 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
@@ -35,7 +35,7 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@@ -44,7 +44,7 @@
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6358-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6358-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
index 0330b62..4d59473 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
@@ -35,7 +35,7 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@@ -44,7 +44,7 @@
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6362-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6362-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
index 82d3e44..aae83d4 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
@@ -35,7 +35,7 @@
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm63xx-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@@ -44,7 +44,7 @@
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6368-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6368-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
index 1b06a77..9804d13 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
@@ -31,12 +31,17 @@
charger:
$ref: /schemas/power/supply/maxim,max77693.yaml
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
led:
$ref: /schemas/leds/maxim,max77693.yaml
max77693-muic:
type: object
additionalProperties: false
+ deprecated: true
properties:
compatible:
@@ -45,6 +50,21 @@
required:
- compatible
+ muic:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: maxim,max77693-muic
+
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - compatible
+
motor-driver:
type: object
additionalProperties: false
@@ -107,6 +127,38 @@
};
};
+ muic {
+ compatible = "maxim,max77693-muic";
+
+ connector {
+ compatible = "samsung,usb-connector-11pin",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ muic_to_usb: endpoint {
+ remote-endpoint = <&usb_to_muic>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ muic_to_mhl: endpoint {
+ remote-endpoint = <&mhl_to_muic>;
+ };
+ };
+ };
+ };
+ };
+
motor-driver {
compatible = "maxim,max77693-haptic";
haptic-supply = <&ldo26_reg>;
diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
index e6a2387..9e4eed3 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
@@ -7,7 +7,7 @@
title: Qualcomm Technologies, Inc. PM8008 PMIC
maintainers:
- - Guru Das Srinagesh <gurus@codeaurora.org>
+ - Guru Das Srinagesh <quic_gurus@quicinc.com>
description: |
Qualcomm Technologies, Inc. PM8008 is a dedicated camera PMIC that integrates
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
index 8b9a200..9f03436 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -41,6 +41,7 @@
- qcom,pm660
- qcom,pm660l
- qcom,pm7250b
+ - qcom,pm7550ba
- qcom,pm7325
- qcom,pm8004
- qcom,pm8005
@@ -70,6 +71,8 @@
- qcom,pm8994
- qcom,pm8998
- qcom,pma8084
+ - qcom,pmc8180
+ - qcom,pmc8180c
- qcom,pmd9635
- qcom,pmi632
- qcom,pmi8950
@@ -88,6 +91,7 @@
- qcom,pms405
- qcom,pmx55
- qcom,pmx65
+ - qcom,pmx75
- qcom,smb2351
- const: qcom,spmi-pmic
@@ -127,7 +131,7 @@
"^audio-codec@[0-9a-f]+$":
type: object
- additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet
+ $ref: /schemas/sound/qcom,pm8916-wcd-analog-codec.yaml#
"^charger@[0-9a-f]+$":
type: object
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
index 7ab7b2c..d783cc4 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
@@ -130,7 +130,6 @@
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/leds/common.h>
i2c {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
index 10f207a..b7b323b 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
@@ -34,7 +34,7 @@
BD9576 and BD9573 VOUT1 regulator enable state can be individually
controlled by a GPIO. This is dictated by state of vout1-en pin during
the PMIC startup. If vout1-en is LOW during PMIC startup then the VOUT1
- enable sate is controlled via this pin. Set this property if vout1-en
+ enable state is controlled via this pin. Set this property if vout1-en
is wired to be down at PMIC start-up.
type: boolean
@@ -61,7 +61,7 @@
rohm,hw-timeout-ms:
maxItems: 2
description:
- Watchog timeout in milliseconds. If single value is given it is
+ Watchdog timeout in milliseconds. If single value is given it is
the maximum timeout. Eg. if pinging watchdog is not done within this time
limit the watchdog will be triggered. If two values are given watchdog
is configured in "window mode". Then first value is limit for short-ping
diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
new file mode 100644
index 0000000..b77cc3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
@@ -0,0 +1,297 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/st,stmpe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectonics Port Expander (STMPE)
+
+description: STMicroelectronics Port Expander (STMPE) is a series of slow
+ bus controllers for various expanded peripherals such as GPIO, keypad,
+ touchscreen, ADC, PWM or rotator. It can contain one or several different
+ peripherals connected to SPI or I2C.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,stmpe601
+ - st,stmpe801
+ - st,stmpe811
+ - st,stmpe1600
+ - st,stmpe1601
+ - st,stmpe2401
+ - st,stmpe2403
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vcc-supply: true
+
+ vio-supply: true
+
+ reset-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
+ st,autosleep-timeout:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 4, 16, 32, 64, 128, 256, 512, 1024 ]
+ description: Time idle before going to automatic sleep to save power
+
+ st,sample-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6 ]
+ description: |
+ Sample time per iteration
+ 0 = 36 clock ticks
+ 1 = 44 clock ticks
+ 2 = 56 clock ticks
+ 3 = 64 clock ticks
+ 4 = 80 clock ticks - recommended
+ 5 = 96 clock ticks
+ 6 = 124 clock ticks
+
+ st,mod-12b:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: ADC bit mode 0 = 10bit ADC, 1 = 12bit ADC
+
+ st,ref-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: ADC reference source 0 = internal, 1 = external
+
+ st,adc-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ ADC clock speed
+ 0 = 1.625 MHz
+ 1 = 3.25 MHz
+ 2, 3 = 6.5 MHz
+
+ adc:
+ type: object
+ $ref: /schemas/iio/adc/st,stmpe-adc.yaml#
+
+ gpio:
+ type: object
+ $ref: /schemas/gpio/st,stmpe-gpio.yaml#
+
+ keyboard-controller:
+ type: object
+ $ref: /schemas/input/matrix-keymap.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-keypad
+
+ debounce-interval:
+ description: Debouncing interval in milliseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st,no-autorepeat:
+ description: If present, the keys will not autorepeat when pressed
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,scan-count:
+ description: Scanning cycles elapsed before key data is updated
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - compatible
+ - linux,keymap
+
+ pwm:
+ type: object
+ $ref: /schemas/pwm/pwm.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-pwm
+
+ "#pwm-cells":
+ const: 2
+
+ touchscreen:
+ type: object
+ $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-ts
+
+ st,ave-ctrl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ Sample average control
+ 0 = 1 sample
+ 1 = 2 samples
+ 2 = 4 samples
+ 3 = 8 samples
+
+ st,touch-det-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: |
+ Touch detection delay
+ 0 = 10 us
+ 1 = 50 us
+ 2 = 100 us
+ 3 = 500 us - recommended
+ 4 = 1 ms
+ 5 = 5 ms
+ 6 = 10 ms
+ 7 = 50 ms
+
+ st,settling:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: |
+ Panel driver settling time
+ 0 = 10 us
+ 1 = 100 us
+ 2 = 500 us - recommended
+ 3 = 1 ms
+ 4 = 5 ms
+ 5 = 10 ms
+ 6 = 50 ms
+ 7 = 100 ms
+
+ st,fraction-z:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: Length of the fractional part in z, recommended is 7
+ (fraction-z ([0..7]) = Count of the fractional part)
+
+ st,i-drive:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: |
+ current limit value of the touchscreen drivers
+ 0 = 20 mA (typical 35 mA max)
+ 1 = 50 mA (typical 80 mA max)
+
+ required:
+ - compatible
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/input.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port-expander@43 {
+ compatible = "st,stmpe2401";
+ reg = <0x43>;
+ reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ vcc-supply = <&db8500_vsmps2_reg>;
+ vio-supply = <&db8500_vsmps2_reg>;
+ wakeup-source;
+ st,autosleep-timeout = <1024>;
+
+ gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ st,norequest-mask = <0xf0f002>;
+ };
+
+ keyboard-controller {
+ compatible = "st,stmpe-keypad";
+ debounce-interval = <64>;
+ st,scan-count = <8>;
+ st,no-autorepeat;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <8>;
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x00, KEY_1)
+ MATRIX_KEY(0x00, 0x01, KEY_2)
+ MATRIX_KEY(0x00, 0x02, KEY_3)
+ MATRIX_KEY(0x00, 0x03, KEY_4)
+ MATRIX_KEY(0x00, 0x04, KEY_5)
+ MATRIX_KEY(0x00, 0x05, KEY_6)
+ MATRIX_KEY(0x00, 0x06, KEY_7)
+ MATRIX_KEY(0x00, 0x07, KEY_8)
+ MATRIX_KEY(0x00, 0x08, KEY_9)
+ MATRIX_KEY(0x00, 0x09, KEY_0)
+ >;
+ };
+
+ pwm {
+ compatible = "st,stmpe-pwm";
+ #pwm-cells = <2>;
+ };
+ };
+
+ port-expander@41 {
+ compatible = "st,stmpe811";
+ reg = <0x41>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ st,adc-freq = <1>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,sample-time = <4>;
+
+ adc {
+ compatible = "st,stmpe-adc";
+ st,norequest-mask = <0x0f>;
+ #io-channel-cells = <1>;
+ };
+
+ gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pwm {
+ compatible = "st,stmpe-pwm";
+ #pwm-cells = <2>;
+ };
+
+ touchscreen {
+ compatible = "st,stmpe-ts";
+ st,ave-ctrl = <3>;
+ st,touch-det-delay = <5>;
+ st,settling = <3>;
+ st,fraction-z = <7>;
+ st,i-drive = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
index 97c6109..b17ebeb0 100644
--- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
@@ -106,6 +106,7 @@
const: st,stpmic1-regulators
ldo3:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -128,6 +129,7 @@
additionalProperties: false
ldo4:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -142,11 +144,14 @@
regulator-name: true
regulator-boot-on: true
regulator-always-on: true
+ regulator-min-microvolt: true
+ regulator-max-microvolt: true
regulator-over-current-protection: true
additionalProperties: false
vref_ddr:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -165,6 +170,7 @@
additionalProperties: false
boost:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -187,10 +193,8 @@
"^(buck[1-4]|ldo[1-6]|vref_ddr|boost|pwr_sw[1-2])-supply$":
description: STPMIC1 voltage regulators supplies
- "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
- $ref: ../regulator/regulator.yaml
-
"^ldo[1-2,5-6]$":
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -213,6 +217,7 @@
additionalProperties: false
"^buck[1-4]$":
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -237,6 +242,7 @@
additionalProperties: false
"^pwr_sw[1-2]$":
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
diff --git a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml
index 6c8d42f..94f9767 100644
--- a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml
+++ b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml
@@ -313,7 +313,7 @@
- const: audioclk
stericsson,earpeice-cmv:
- description: Earpeice voltage
+ description: Earpiece voltage
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 950, 1100, 1270, 1580 ]
@@ -337,39 +337,39 @@
with power.
ab8500_ldo_aux1:
- description: The voltage for the auxilary LDO regulator 1
+ description: The voltage for the auxiliary LDO regulator 1
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux2:
- description: The voltage for the auxilary LDO regulator 2
+ description: The voltage for the auxiliary LDO regulator 2
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux3:
- description: The voltage for the auxilary LDO regulator 3
+ description: The voltage for the auxiliary LDO regulator 3
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux4:
- description: The voltage for the auxilary LDO regulator 4
+ description: The voltage for the auxiliary LDO regulator 4
only present on AB8505
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux5:
- description: The voltage for the auxilary LDO regulator 5
+ description: The voltage for the auxiliary LDO regulator 5
only present on AB8505
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux6:
- description: The voltage for the auxilary LDO regulator 6
+ description: The voltage for the auxiliary LDO regulator 6
only present on AB8505
type: object
$ref: ../regulator/regulator.yaml#
@@ -378,7 +378,7 @@
# There is never any AUX7 regulator which is confusing
ab8500_ldo_aux8:
- description: The voltage for the auxilary LDO regulator 8
+ description: The voltage for the auxiliary LDO regulator 8
only present on AB8505
type: object
$ref: ../regulator/regulator.yaml#
diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
index 1d4d88f..5e0002f 100644
--- a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
+++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
@@ -72,44 +72,52 @@
main voltage domain for the chip.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_varm:
description: The voltage for the ARM Cortex A-9 CPU.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vmodem:
description: The voltage for the modem subsystem.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vpll:
description: The voltage for the phase locked loop clocks.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vsmps1:
description: Also known as VIO12, is a step-down voltage regulator
for 1.2V I/O. SMPS means System Management Power Source.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vsmps2:
description: Also known as VIO18, is a step-down voltage regulator
for 1.8V I/O. SMPS means System Management Power Source.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vsmps3:
description: This is a step-down voltage regulator
for 0.87 thru 1.875V I/O. SMPS means System Management Power Source.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vrf1:
- description: RF transciever voltage regulator.
+ description: RF transceiver voltage regulator.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sva_mmdsp:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
@@ -117,18 +125,21 @@
for video encoding and decoding.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sva_mmdsp_ret:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator for retention mode.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sva_pipe:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator for the data pipe.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sia_mmdsp:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
@@ -136,18 +147,21 @@
for image encoding and decoding.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sia_mmdsp_ret:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator for retention mode.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sia_pipe:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator for the data pipe.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sga:
description: Smart Graphics Accelerator (SGA) voltage regulator.
@@ -155,6 +169,7 @@
accelerator block.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_b2r2_mcde:
description: Blit Blend Rotate and Rescale (B2R2), and Multi-Channel
@@ -162,28 +177,33 @@
blocks.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram12:
description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram12_ret:
description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator for
retention mode.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram34:
description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram34_ret:
description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator for
retention mode.
type: object
$ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
deleted file mode 100644
index d4408a4..0000000
--- a/Documentation/devicetree/bindings/mfd/stmpe.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* ST Microelectronics STMPE Multi-Functional Device
-
-STMPE is an MFD device which may expose the following inbuilt devices: gpio,
-keypad, touchscreen, adc, pwm, rotator.
-
-Required properties:
- - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
- - reg : I2C/SPI address of the device
-
-Optional properties:
- - interrupts : The interrupt outputs from the controller
- - interrupt-controller : Marks the device node as an interrupt controller
- - wakeup-source : Marks the input device as wakable
- - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
- - irq-gpio : If present, which GPIO to use for event IRQ
-
-Optional properties for devices with touch and ADC (STMPE811|STMPE610):
- - st,sample-time : ADC conversion time in number of clock.
- 0 -> 36 clocks 4 -> 80 clocks (recommended)
- 1 -> 44 clocks 5 -> 96 clocks
- 2 -> 56 clocks 6 -> 124 clocks
- 3 -> 64 clocks
- - st,mod-12b : ADC Bit mode
- 0 -> 10bit ADC 1 -> 12bit ADC
- - st,ref-sel : ADC reference source
- 0 -> internal 1 -> external
- - st,adc-freq : ADC Clock speed
- 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
- 1 -> 3.25 MHz
-
-Example:
-
- stmpe1601: stmpe1601@40 {
- compatible = "st,stmpe1601";
- reg = <0x40>;
- interrupts = <26 0x4>;
- interrupt-parent = <&gpio6>;
- interrupt-controller;
-
- wakeup-source;
- st,autosleep-timeout = <1024>;
- };
diff --git a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml
index 20b5836..358ac8c 100644
--- a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml
+++ b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson 2K1000 PM Controller
diff --git a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
index 7c0f902..3e3a370 100644
--- a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
+++ b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson RS780E PCH ACPI Controller
diff --git a/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml b/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml
index 38ab049..36a9dbd 100644
--- a/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml
+++ b/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx AHB Queue Manager
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
index a6c19a6..3e99801 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
@@ -160,6 +160,12 @@
description:
The MIO bank number in which the command and data lines are configured.
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
dependencies:
'#clock-cells': [ clock-output-names ]
diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
index 3ee7588..3a8e748 100644
--- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
@@ -71,8 +71,8 @@
marvell,xenon-phy-type:
$ref: /schemas/types.yaml#/definitions/string
enum:
- - "emmc 5.1 phy"
- - "emmc 5.0 phy"
+ - emmc 5.1 phy
+ - emmc 5.0 phy
description: |
Xenon support multiple types of PHYs. To select eMMC 5.1 PHY, set:
marvell,xenon-phy-type = "emmc 5.1 phy" eMMC 5.1 PHY is the default
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
index 86c73fd..58ae298 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -269,7 +269,7 @@
post-power-on-delay-ms:
description:
It was invented for MMC pwrseq-simple which could be referred to
- mmc-pwrseq-simple.txt. But now it\'s reused as a tunable delay
+ mmc-pwrseq-simple.yaml. But now it\'s reused as a tunable delay
waiting for I/O signalling and card power supply to be stable,
regardless of whether pwrseq-simple is used. Default to 10ms if
no available.
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
index 46eefdd..3fffa46 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
@@ -91,16 +91,6 @@
should switch dat1 pin to GPIO mode.
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:
diff --git a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
index 5f5c2be..66a78ea 100644
--- a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
@@ -9,7 +9,7 @@
Optional properties:
- marvell,detect-delay-ms: sets the detection delay timeout in ms.
-In addition to the properties described in this docuent, the details
+In addition to the properties described in this document, the details
described in mmc.txt are supported.
Examples:
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
index 69edfd4..a9fb0a9 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
@@ -5,11 +5,13 @@
sdhci-of-at91 driver.
Required properties:
-- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci".
+- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci"
+ or "microchip,sam9x7-sdhci", "microchip,sam9x60-sdhci".
- clocks: Phandlers to the clocks.
- clock-names: Must be "hclock", "multclk", "baseclk" for
"atmel,sama5d2-sdhci".
Must be "hclock", "multclk" for "microchip,sam9x60-sdhci".
+ Must be "hclock", "multclk" for "microchip,sam9x7-sdhci".
Optional properties:
- assigned-clocks: The same with "multclk".
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
index 6da28e6..80141eb 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
@@ -215,7 +215,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-sm8250.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
sdhc_2: mmc@8804000 {
compatible = "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5";
@@ -232,7 +232,7 @@
iommus = <&apps_smmu 0x4a0 0x0>;
qcom,dll-config = <0x0007642c>;
qcom,ddr-config = <0x80040868>;
- power-domains = <&rpmhpd SM8250_CX>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
operating-points-v2 = <&sdhc2_opp_table>;
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 57d077c..7a0e9dc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -95,7 +95,7 @@
| card | -- CIRQ --> | hsmmc | -- IRQ --> | CPU |
------ ------- -----
-In suspend the fclk is off and the module is disfunctional. Even register reads
+In suspend the fclk is off and the module is dysfunctional. Even register reads
will fail. A small logic in the host will request fclk restore, when an
external event is detected. Once the clock is restored, the host detects the
event normally. Since am33xx doesn't have this line it never wakes from
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
index 787ef48..57b6957 100644
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
@@ -50,7 +50,7 @@
const: hw
nand-ecc-step-size:
- const: 1024
+ enum: [512, 1024]
nand-ecc-strength:
enum: [8, 16, 24, 30, 40, 50, 60]
@@ -66,6 +66,10 @@
unevaluatedProperties: false
+ dependencies:
+ nand-ecc-strength: [nand-ecc-step-size]
+ nand-ecc-step-size: [nand-ecc-strength]
+
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 89959e5..58f0cea 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -43,8 +43,10 @@
- const: jedec,spi-nor
- const: jedec,spi-nor
description:
- Must also include "jedec,spi-nor" for any SPI NOR flash that can be
- identified by the JEDEC READ ID opcode (0x9F).
+ SPI NOR flashes compatible with the JEDEC SFDP standard or which may be
+ identified with the READ ID opcode (0x9F) do not deserve a specific
+ compatible. They should instead only be matched against the generic
+ "jedec,spi-nor" compatible.
reg:
minItems: 1
@@ -70,6 +72,21 @@
be used on such systems, to denote the absence of a reliable reset
mechanism.
+ no-wp:
+ type: boolean
+ description:
+ The status register write disable (SRWD) bit in status register, combined
+ with the WP# signal, provides hardware data protection for the device. When
+ the SRWD bit is set to 1, and the WP# signal is either driven LOW or hard
+ strapped to LOW, the status register nonvolatile bits become read-only and
+ the WRITE STATUS REGISTER operation will not execute. The only way to exit
+ this hardware-protected mode is to drive WP# HIGH. If the WP# signal of the
+ flash device is not connected or is wrongly tied to GND (that includes internal
+ pull-downs) then status register permanently becomes read-only as the SRWD bit
+ cannot be reset. This boolean flag can be used on such systems to avoid setting
+ the SRWD bit while writing the status register. WP# signal hard strapped to GND
+ can be a valid use case.
+
reset-gpios:
description:
A GPIO line connected to the RESET (active low) signal of the device.
diff --git a/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
index a10729b..1ecea84 100644
--- a/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
@@ -16,6 +16,7 @@
- const: marvell,armada-8k-nand-controller
- const: marvell,armada370-nand-controller
- enum:
+ - marvell,ac5-nand-controller
- marvell,armada370-nand-controller
- marvell,pxa3xx-nand-controller
- description: legacy bindings
diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml
index 0088289..0ff32bd 100644
--- a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip 48l640 (and similar) serial EERAM
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 83a4fe4..28167c0 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mtd/nand-controller.yaml#
diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
deleted file mode 100644
index 2ba07fc..0000000
--- a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Oxford Semiconductor OXNAS NAND Controller
-
-Please refer to nand-controller.yaml for generic information regarding MTD NAND bindings.
-
-Required properties:
- - compatible: "oxsemi,ox820-nand"
- - reg: Base address and length for NAND mapped memory.
-
-Optional Properties:
- - clocks: phandle to the NAND gate clock if needed.
- - resets: phandle to the NAND reset control if needed.
-
-Example:
-
-nandc: nand-controller@41000000 {
- compatible = "oxsemi,ox820-nand";
- reg = <0x41000000 0x100000>;
- clocks = <&stdclk CLK_820_NAND>;
- resets = <&reset RESET_NAND>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- nand@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
- nand-ecc-mode = "soft";
- nand-ecc-algo = "hamming";
-
- partition@0 {
- label = "boot";
- reg = <0x00000000 0x00e00000>;
- read-only;
- };
-
- partition@e00000 {
- label = "ubi";
- reg = <0x00e00000 0x07200000>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/seama.yaml b/Documentation/devicetree/bindings/mtd/partitions/seama.yaml
new file mode 100644
index 0000000..4c1cbf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/seama.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/seama.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Seattle Image Partitions
+
+description: The SEAttle iMAge (SEAMA) partition is a type of partition
+ used for NAND flash devices. This type of flash image is found in some
+ D-Link routers such as DIR-645, DIR-842, DIR-859, DIR-860L, DIR-885L,
+ DIR890L and DCH-M225, as well as in WD and NEC routers on the ath79
+ (MIPS), Broadcom BCM53xx, and RAMIPS platforms. This partition type
+ does not have children defined in the device tree, they need to be
+ detected by software.
+
+allOf:
+ - $ref: partition.yaml#
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ const: seama
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ compatible = "seama";
+ reg = <0x0 0x800000>;
+ label = "firmware";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
index 56cbb42b..eba2f30 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
@@ -19,12 +19,14 @@
- qcom,qca2066-bt
- qcom,qca6174-bt
- qcom,qca9377-bt
+ - qcom,wcn3988-bt
- qcom,wcn3990-bt
- qcom,wcn3991-bt
- qcom,wcn3998-bt
- qcom,qca6390-bt
- qcom,wcn6750-bt
- qcom,wcn6855-bt
+ - qcom,wcn7850-bt
enable-gpios:
maxItems: 1
@@ -57,6 +59,9 @@
vddaon-supply:
description: VDD_AON supply regulator handle
+ vdddig-supply:
+ description: VDD_DIG supply regulator handle
+
vddbtcxmx-supply:
description: VDD_BT_CXMX supply regulator handle
@@ -72,6 +77,9 @@
vddrfa1p2-supply:
description: VDD_RFA_1P2 supply regulator handle
+ vddrfa1p9-supply:
+ description: VDD_RFA_1P9 supply regulator handle
+
vddrfa2p2-supply:
description: VDD_RFA_2P2 supply regulator handle
@@ -111,6 +119,7 @@
compatible:
contains:
enum:
+ - qcom,wcn3988-bt
- qcom,wcn3990-bt
- qcom,wcn3991-bt
- qcom,wcn3998-bt
@@ -155,6 +164,22 @@
- vddrfa0p8-supply
- vddrfa1p2-supply
- vddrfa1p7-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,wcn7850-bt
+ then:
+ required:
+ - enable-gpios
+ - swctrl-gpios
+ - vddio-supply
+ - vddaon-supply
+ - vdddig-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p9-supply
examples:
- |
diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
new file mode 100644
index 0000000..aa3162c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom ASP 2.0 Ethernet controller
+
+maintainers:
+ - Justin Chen <justin.chen@broadcom.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+description: Broadcom Ethernet controller first introduced with 72165
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - brcm,bcm74165-asp
+ - const: brcm,asp-v2.1
+ - items:
+ - enum:
+ - brcm,bcm72165-asp
+ - const: brcm,asp-v2.0
+
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: RX/TX interrupt
+ - description: Port 0 Wake-on-LAN
+ - description: Port 1 Wake-on-LAN
+
+ clocks:
+ maxItems: 1
+
+ ethernet-ports:
+ type: object
+ properties:
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^port@[0-9]+$":
+ type: object
+
+ $ref: ethernet-controller.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+ description: Port number
+
+ brcm,channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ ASP Channel Number
+
+ The depacketizer channel that consumes packets from
+ the unimac/port.
+
+ required:
+ - reg
+ - brcm,channel
+
+ additionalProperties: false
+
+patternProperties:
+ "^mdio@[0-9a-f]+$":
+ type: object
+ $ref: brcm,unimac-mdio.yaml
+
+ description:
+ ASP internal UniMAC MDIO bus
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@9c00000 {
+ compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0";
+ reg = <0x9c00000 0x1fff14>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ ranges = <0x0 0x9c00000 0x1fff14>;
+ clocks = <&scmi 14>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mdio@c614 {
+ compatible = "brcm,asp-v2.0-mdio";
+ reg = <0xc614 0x8>;
+ reg-names = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+
+ mdio@ce14 {
+ compatible = "brcm,asp-v2.0-mdio";
+ reg = <0xce14 0x8>;
+ reg-names = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ brcm,channel = <8>;
+ phy-mode = "rgmii";
+ phy-handle = <&phy0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ brcm,channel = <9>;
+ phy-mode = "rgmii";
+ phy-handle = <&phy1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt b/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt
index d0935d2..284cddb 100644
--- a/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt
+++ b/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt
@@ -1,4 +1,4 @@
-* Broadcom Starfighter 2 integrated swich
+* Broadcom Starfighter 2 integrated switch
See dsa/brcm,bcm7445-switch-v4.0.yaml for the documentation.
diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
index 0be426e..6684810 100644
--- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
@@ -22,6 +22,8 @@
- brcm,genet-mdio-v3
- brcm,genet-mdio-v4
- brcm,genet-mdio-v5
+ - brcm,asp-v2.0-mdio
+ - brcm,asp-v2.1-mdio
- brcm,unimac-mdio
reg:
diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
index 9c49495..e42ea28 100644
--- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
+++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
@@ -21,6 +21,7 @@
- const: allwinner,sun4i-a10-can
- const: allwinner,sun4i-a10-can
- const: allwinner,sun8i-r40-can
+ - const: allwinner,sun20i-d1-can
reg:
maxItems: 1
@@ -37,8 +38,9 @@
if:
properties:
compatible:
- contains:
- const: allwinner,sun8i-r40-can
+ enum:
+ - allwinner,sun8i-r40-can
+ - allwinner,sun20i-d1-can
then:
required:
diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
index 67879aa..f9ffb96 100644
--- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
+++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@@ -122,16 +122,15 @@
- compatible
- reg
- reg-names
- - interrupts
- - interrupt-names
- clocks
- clock-names
- bosch,mram-cfg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ // Example with interrupts
#include <dt-bindings/clock/imx6sx-clock.h>
can@20e8000 {
compatible = "bosch,m_can";
@@ -149,4 +148,21 @@
};
};
+ - |
+ // Example with timer polling
+ #include <dt-bindings/clock/imx6sx-clock.h>
+ can@20e8000 {
+ compatible = "bosch,m_can";
+ reg = <0x020e8000 0x4000>, <0x02298000 0x4000>;
+ reg-names = "m_can", "message_ram";
+ clocks = <&clks IMX6SX_CLK_CANFD>,
+ <&clks IMX6SX_CLK_CANFD>;
+ clock-names = "hclk", "cclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>;
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+ };
+
...
diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt
index 77027bf..042200c 100644
--- a/Documentation/devicetree/bindings/net/can/cc770.txt
+++ b/Documentation/devicetree/bindings/net/can/cc770.txt
@@ -26,7 +26,7 @@
will be disabled.
- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
- a resonable value will be calculated.
+ a reasonable value will be calculated.
- bosch,disconnect-rx0-input : see data sheet.
diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
index e3501bf..170e23f 100644
--- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
+++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
@@ -4,7 +4,10 @@
This file provides device node information for the TCAN4x5x interface contains.
Required properties:
- - compatible: "ti,tcan4x5x"
+ - compatible:
+ "ti,tcan4552", "ti,tcan4x5x"
+ "ti,tcan4553", "ti,tcan4x5x" or
+ "ti,tcan4x5x"
- reg: 0
- #address-cells: 1
- #size-cells: 0
@@ -21,8 +24,10 @@
- reset-gpios: Hardwired output GPIO. If not defined then software
reset.
- device-state-gpios: Input GPIO that indicates if the device is in
- a sleep state or if the device is active.
- - device-wake-gpios: Wake up GPIO to wake up the TCAN device.
+ a sleep state or if the device is active. Not
+ available with tcan4552/4553.
+ - device-wake-gpios: Wake up GPIO to wake up the TCAN device. Not
+ available with tcan4552/4553.
Example:
tcan4x5x: tcan4x5x@0 {
diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
index 897d2cb..64d57c3 100644
--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
@@ -46,6 +46,9 @@
$ref: /schemas/types.yaml#/definitions/uint32
description: CAN Tx mailbox buffer count (CAN FD)
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/net/davicom,dm9000.yaml b/Documentation/devicetree/bindings/net/davicom,dm9000.yaml
new file mode 100644
index 0000000..66a7c6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom,dm9000.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/davicom,dm9000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Davicom DM9000 Fast Ethernet Controller
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: davicom,dm9000
+
+ reg:
+ items:
+ - description: Address registers
+ - description: Data registers
+
+ interrupts:
+ maxItems: 1
+
+ davicom,no-eeprom:
+ type: boolean
+ description: Configuration EEPROM is not available
+
+ davicom,ext-phy:
+ type: boolean
+ description: Use external PHY
+
+ reset-gpios:
+ maxItems: 1
+
+ vcc-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ethernet@a8000000 {
+ compatible = "davicom,dm9000";
+ reg = <0xa8000000 0x2>, <0xa8000002 0x2>;
+ interrupt-parent = <&gph1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+ local-mac-address = [00 00 de ad be ef];
+ davicom,no-eeprom;
+ };
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
deleted file mode 100644
index 64c159e..0000000
--- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Davicom DM9000 Fast Ethernet controller
-
-Required properties:
-- compatible = "davicom,dm9000";
-- reg : physical addresses and sizes of registers, must contain 2 entries:
- first entry : address register,
- second entry : data register.
-- interrupts : interrupt specifier specific to interrupt controller
-
-Optional properties:
-- davicom,no-eeprom : Configuration EEPROM is not available
-- davicom,ext-phy : Use external PHY
-- reset-gpios : phandle of gpio that will be used to reset chip during probe
-- vcc-supply : phandle of regulator that will be used to enable power to chip
-
-Example:
-
- ethernet@18000000 {
- compatible = "davicom,dm9000";
- reg = <0x18000000 0x2 0x18000004 0x2>;
- interrupt-parent = <&gpn>;
- interrupts = <7 4>;
- local-mac-address = [00 00 de ad be ef];
- davicom,no-eeprom;
- reset-gpios = <&gpf 12 GPIO_ACTIVE_LOW>;
- vcc-supply = <ð0_power>;
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
index c745407..b06c416 100644
--- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/dsa/brcm,sf2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Starfighter 2 integrated swich
+title: Broadcom Starfighter 2 integrated switch
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
index 8d97181..ec74a66 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
@@ -36,7 +36,7 @@
$defs:
ethernet-ports:
description: A DSA switch without any extra port properties
- $ref: '#/'
+ $ref: '#'
patternProperties:
"^(ethernet-)?ports$":
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
index 3372613..6ec0c18 100644
--- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
+++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt
@@ -20,7 +20,7 @@
6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321,
6341, 6350, 6351, 6352
- "marvell,mv88e6190" : Switch has base address 0x00. Use with models:
- 6163, 6190, 6190X, 6191, 6290, 6390, 6390X
+ 6190, 6190X, 6191, 6290, 6361, 6390, 6390X
- "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model:
6220, 6250
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
index e51be1a..03b5567 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -49,6 +49,9 @@
Set if the output SYNCLKO clock should be disabled. Do not mix with
microchip,synclko-125.
+ interrupts:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index 6b0d359..9f6a5cc 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -66,6 +66,7 @@
- mii
- gmii
- sgmii
+ - psgmii
- qsgmii
- qusgmii
- tbi
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index c1241c8..8fb2a6e 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -110,7 +110,7 @@
$ref: /schemas/types.yaml#/definitions/flag
description:
If set, indicates that PHY will disable swap of the
- TX/RX lanes. This property allows the PHY to work correcly after
+ TX/RX lanes. This property allows the PHY to work correctly after
e.g. wrong bootstrap configuration caused by issues in PCB
layout design.
diff --git a/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml
new file mode 100644
index 0000000..9bcbacb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/faraday,ftgmac100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday Technology FTGMAC100 gigabit ethernet controller
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+maintainers:
+ - Po-Yu Chuang <ratbert@faraday-tech.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: faraday,ftgmac100
+ - items:
+ - enum:
+ - aspeed,ast2400-mac
+ - aspeed,ast2500-mac
+ - aspeed,ast2600-mac
+ - const: faraday,ftgmac100
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: MAC IP clock
+ - description: RMII RCLK gate for AST2500/2600
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: MACCLK
+ - const: RCLK
+
+ phy-mode:
+ enum:
+ - rgmii
+ - rmii
+
+ phy-handle: true
+
+ use-ncsi:
+ description:
+ Use the NC-SI stack instead of an MDIO PHY. Currently assumes
+ rmii (100bT) but kept as a separate property in case NC-SI grows support
+ for a gigabit link.
+ type: boolean
+
+ no-hw-checksum:
+ description:
+ Used to disable HW checksum support. Here for backward
+ compatibility as the driver now should have correct defaults based on
+ the SoC.
+ type: boolean
+ deprecated: true
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@1e660000 {
+ compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
+ reg = <0x1e660000 0x180>;
+ interrupts = <2>;
+ use-ncsi;
+ };
+
+ 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/ftgmac100.txt b/Documentation/devicetree/bindings/net/ftgmac100.txt
deleted file mode 100644
index 2923402..0000000
--- a/Documentation/devicetree/bindings/net/ftgmac100.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Faraday Technology FTGMAC100 gigabit ethernet controller
-
-Required properties:
-- compatible: "faraday,ftgmac100"
-
- Must also contain one of these if used as part of an Aspeed AST2400
- or 2500 family SoC as they have some subtle tweaks to the
- implementation:
-
- - "aspeed,ast2400-mac"
- - "aspeed,ast2500-mac"
- - "aspeed,ast2600-mac"
-
-- reg: Address and length of the register set for the device
-- 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.
-- use-ncsi: Use the NC-SI stack instead of an MDIO PHY. Currently assumes
- rmii (100bT) but kept as a separate property in case NC-SI grows support
- for a gigabit link.
-- no-hw-checksum: Used to disable HW checksum support. Here for backward
- compatibility as the driver now should have correct defaults based on
- the SoC.
-- clocks: In accordance with the generic clock bindings. Must describe the MAC
- IP clock, and optionally an RMII RCLK gate for the AST2500/AST2600. The
- required MAC clock must be the first cell.
-- clock-names:
-
- - "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 {
- compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
- reg = <0x1e660000 0x180>;
- 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/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index 31cc0c4..e74502a 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -19,10 +19,12 @@
enum:
- mediatek,mt2701-eth
- mediatek,mt7623-eth
+ - mediatek,mt7621-eth
- mediatek,mt7622-eth
- mediatek,mt7629-eth
- mediatek,mt7981-eth
- mediatek,mt7986-eth
+ - mediatek,mt7988-eth
- ralink,rt5350-eth
reg:
@@ -32,7 +34,7 @@
clock-names: true
interrupts:
- minItems: 3
+ minItems: 1
maxItems: 4
power-domains:
@@ -60,6 +62,12 @@
Phandle to the mediatek hifsys controller used to provide various clocks
and reset to the system.
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon node that handles the path from GMAC to
+ PHY variants.
+
mediatek,sgmiisys:
$ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
@@ -121,6 +129,8 @@
- const: gp1
- const: gp2
+ mediatek,infracfg: false
+
mediatek,pctl:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -135,6 +145,32 @@
properties:
compatible:
contains:
+ enum:
+ - mediatek,mt7621-eth
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ethif
+ - const: fe
+
+ mediatek,infracfg: false
+
+ mediatek,wed: false
+
+ mediatek,wed-pcie: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: mediatek,mt7622-eth
then:
properties:
@@ -159,6 +195,8 @@
- const: sgmii_ck
- const: eth2pll
+ mediatek,infracfg: false
+
mediatek,sgmiisys:
minItems: 1
maxItems: 1
@@ -204,12 +242,6 @@
- const: sgmii_ck
- const: eth2pll
- mediatek,infracfg:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the syscon node that handles the path from GMAC to
- PHY variants.
-
mediatek,sgmiisys:
minItems: 2
maxItems: 2
@@ -250,6 +282,8 @@
- const: netsys0
- const: netsys1
+ mediatek,infracfg: false
+
mediatek,sgmiisys:
minItems: 2
maxItems: 2
@@ -286,6 +320,67 @@
- const: netsys0
- const: netsys1
+ mediatek,infracfg: false
+
+ mediatek,sgmiisys:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7988-eth
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+
+ clocks:
+ minItems: 34
+ maxItems: 34
+
+ clock-names:
+ items:
+ - const: crypto
+ - const: fe
+ - const: gp2
+ - const: gp1
+ - const: gp3
+ - const: ethwarp_wocpu2
+ - const: ethwarp_wocpu1
+ - const: ethwarp_wocpu0
+ - const: esw
+ - const: netsys0
+ - const: netsys1
+ - const: sgmii_tx250m
+ - const: sgmii_rx250m
+ - const: sgmii2_tx250m
+ - const: sgmii2_rx250m
+ - const: top_usxgmii0_sel
+ - const: top_usxgmii1_sel
+ - const: top_sgm0_sel
+ - const: top_sgm1_sel
+ - const: top_xfi_phy0_xtal_sel
+ - const: top_xfi_phy1_xtal_sel
+ - const: top_eth_gmii_sel
+ - const: top_eth_refck_50m_sel
+ - const: top_eth_sys_200m_sel
+ - const: top_eth_sys_sel
+ - const: top_eth_xgmii_sel
+ - const: top_eth_mii_sel
+ - const: top_netsys_sel
+ - const: top_netsys_500m_sel
+ - const: top_netsys_pao_2x_sel
+ - const: top_netsys_sync_250m_sel
+ - const: top_netsys_ppefb_250m_sel
+ - const: top_netsys_warp_sel
+ - const: wocpu1
+ - const: wocpu0
+ - const: xgp1
+ - const: xgp2
+ - const: xgp3
+
mediatek,sgmiisys:
minItems: 2
maxItems: 2
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
index 5aa320c..ed9d845 100644
--- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
@@ -129,7 +129,7 @@
type: boolean
description:
If present, indicates that MAC supports WOL(Wake-On-LAN), and MAC WOL will be enabled.
- Otherwise, PHY WOL is perferred.
+ Otherwise, PHY WOL is preferred.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
index 0b97e14d..77c9bbf 100644
--- a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
@@ -33,7 +33,7 @@
- usb424,9906 # SMSC9505A USB Ethernet Device (HAL)
- usb424,9907 # SMSC9500 USB Ethernet Device (Alternate ID)
- usb424,9908 # SMSC9500A USB Ethernet Device (Alternate ID)
- - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Devic. ID)
+ - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Device ID)
- usb424,9e00 # SMSC9500A USB Ethernet Device
- usb424,9e01 # SMSC9505A USB Ethernet Device
- usb424,9e08 # SMSC LAN89530 USB Ethernet Device
diff --git a/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
index 157e3bb..26688e2 100644
--- a/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
+++ b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
@@ -52,6 +52,40 @@
for a timer.
type: boolean
+ motorcomm,rx-clk-drv-microamp:
+ description: |
+ drive strength of rx_clk rgmii pad.
+ The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can
+ be configured with hardware pull-up resistors to match the SOC voltage
+ (usually 1.8V).
+ The software can read the registers to obtain the LDO voltage and configure
+ the legal drive strength(curren).
+ =====================================================
+ | voltage | current Available (uA) |
+ | 1.8v | 1200 2100 2700 2910 3110 3600 3970 4350 |
+ | 3.3v | 3070 4080 4370 4680 5020 5450 5740 6140 |
+ =====================================================
+ enum: [ 1200, 2100, 2700, 2910, 3070, 3110, 3600, 3970,
+ 4080, 4350, 4370, 4680, 5020, 5450, 5740, 6140 ]
+ default: 2910
+
+ motorcomm,rx-data-drv-microamp:
+ description: |
+ drive strength of rx_data/rx_ctl rgmii pad.
+ The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can
+ be configured with hardware pull-up resistors to match the SOC voltage
+ (usually 1.8V).
+ The software can read the registers to obtain the LDO voltage and configure
+ the legal drive strength(curren).
+ =====================================================
+ | voltage | current Available (uA) |
+ | 1.8v | 1200 2100 2700 2910 3110 3600 3970 4350 |
+ | 3.3v | 3070 4080 4370 4680 5020 5450 5740 6140 |
+ =====================================================
+ enum: [ 1200, 2100, 2700, 2910, 3070, 3110, 3600, 3970,
+ 4080, 4350, 4370, 4680, 5020, 5450, 5740, 6140 ]
+ default: 2910
+
motorcomm,tx-clk-adj-enabled:
description: |
This configuration is mainly to adapt to VF2 with JH7110 SoC.
diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml
index 8e9a95f..89663fd 100644
--- a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml
@@ -37,13 +37,13 @@
type: boolean
description: |
For I2C type of connection. Specifies that the chip read event shall be
- trigged on falling edge.
+ triggered on falling edge.
i2c-int-rising:
type: boolean
description: |
For I2C type of connection. Specifies that the chip read event shall be
- trigged on rising edge.
+ triggered on rising edge.
break-control:
type: boolean
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
deleted file mode 100644
index 27db496..0000000
--- a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Oxford Semiconductor OXNAS DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: For the OX820 SoC, it should be :
- - "oxsemi,ox820-dwmac" to select glue
- - "snps,dwmac-3.512" to select IP version.
- For the OX810SE SoC, it should be :
- - "oxsemi,ox810se-dwmac" to select glue
- - "snps,dwmac-3.512" to select IP version.
-
-- clocks: Should contain phandles to the following clocks
-- clock-names: Should contain the following:
- - "stmmaceth" for the host clock - see stmmac.txt
- - "gmac" for the peripheral gate clock
-
-- oxsemi,sys-ctrl: a phandle to the system controller syscon node
-
-Example :
-
-etha: ethernet@40400000 {
- compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
- reg = <0x40400000 0x2000>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "macirq", "eth_wake_irq";
- mac-address = [000000000000]; /* Filled in by U-Boot */
- phy-mode = "rgmii";
-
- clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
- clock-names = "gmac", "stmmaceth";
- resets = <&reset RESET_MAC>;
-
- /* Regmap for sys registers */
- oxsemi,sys-ctrl = <&sys>;
-
-};
diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
index 161d289..3acd09f 100644
--- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml
+++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
@@ -75,6 +75,7 @@
description:
Initial data for the VDDIO regulator. Set this to 1.5V or 1.8V.
$ref: /schemas/regulator/regulator.yaml
+ unevaluatedProperties: false
vddh-regulator:
type: object
@@ -82,6 +83,7 @@
Dummy subnode to model the external connection of the PHY VDDH
regulator to VDDIO.
$ref: /schemas/regulator/regulator.yaml
+ unevaluatedProperties: false
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 7f324c6..70bbc42 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -80,6 +80,7 @@
"output" means GMAC provides the reference clock.
$ref: /schemas/types.yaml#/definitions/string
enum: [input, output]
+ default: input
rockchip,grf:
description: The phandle of the syscon node for the general register file.
diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
index 2cff6d8..b9381b7 100644
--- a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
+++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
@@ -5,10 +5,10 @@
- reg: Address and length of the register set for the device
- interrupts: Should contain the SXGBE interrupts
These interrupts are ordered by fixed and follows variable
- trasmit DMA interrupts, receive DMA interrupts and lpi interrupt.
+ transmit DMA interrupts, receive DMA interrupts and lpi interrupt.
index 0 - this is fixed common interrupt of SXGBE and it is always
available.
- index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts
+ index 1 to 25 - 8 variable transmit interrupts, variable 16 receive interrupts
and 1 optional lpi interrupt.
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "sgmii", "xgmii".
diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
index ad3c6e1..bb0224a 100644
--- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
+++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
@@ -110,7 +110,7 @@
It depends on the SoC configuration.
- snps,read-requests: Number of read requests that the AXI port can issue.
It depends on the SoC configuration.
-- snps,burst-map: Bitmap of allowed AXI burst lengts, with the LSB
+- snps,burst-map: Bitmap of allowed AXI burst lengths, with the LSB
representing 4, then 8 etc.
- snps,txpbl: DMA Programmable burst length for the TX DMA
- snps,rxpbl: DMA Programmable burst length for the RX DMA
diff --git a/Documentation/devicetree/bindings/net/sti-dwmac.txt b/Documentation/devicetree/bindings/net/sti-dwmac.txt
index 42cd075..e16287c 100644
--- a/Documentation/devicetree/bindings/net/sti-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/sti-dwmac.txt
@@ -21,7 +21,7 @@
MAC can generate it.
- st,tx-retime-src: This specifies which clk is wired up to the mac for
retimeing tx lines. This is totally board dependent and can take one of the
- posssible values from "txclk", "clk_125" or "clkgen".
+ possible values from "txclk", "clk_125" or "clkgen".
If not passed, the internal clock will be used by default.
- sti-ethclk: this is the phy clock.
- sti-clkconf: this is an extra sysconfig register, available in new SoCs,
diff --git a/Documentation/devicetree/bindings/net/ti,icss-iep.yaml b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml
new file mode 100644
index 0000000..f5c22d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,icss-iep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ICSS Industrial Ethernet Peripheral (IEP) module
+
+maintainers:
+ - Md Danish Anwar <danishanwar@ti.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,am642-icss-iep
+ - ti,j721e-icss-iep
+ - const: ti,am654-icss-iep
+
+ - const: ti,am654-icss-iep
+
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: phandle to the IEP source clock
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ /* AM65x */
+ icssg0_iep0: iep@2e000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2e000 0x1000>;
+ clocks = <&icssg0_iepclk_mux>;
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
new file mode 100644
index 0000000..311c570
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ICSSG PRUSS Ethernet
+
+maintainers:
+ - Md Danish Anwar <danishanwar@ti.com>
+
+description:
+ Ethernet based on the Programmable Real-Time Unit and Industrial
+ Communication Subsystem.
+
+allOf:
+ - $ref: /schemas/remoteproc/ti,pru-consumer.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,am654-icssg-prueth # for AM65x SoC family
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to MSMC SRAM node
+
+ dmas:
+ maxItems: 10
+
+ dma-names:
+ items:
+ - const: tx0-0
+ - const: tx0-1
+ - const: tx0-2
+ - const: tx0-3
+ - const: tx1-0
+ - const: tx1-1
+ - const: tx1-2
+ - const: tx1-3
+ - const: rx0
+ - const: rx1
+
+ ti,mii-g-rt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to MII_G_RT module's syscon regmap.
+
+ ti,mii-rt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to MII_RT module's syscon regmap
+
+ ti,iep:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 2
+ items:
+ maxItems: 1
+ description:
+ phandle to IEP (Industrial Ethernet Peripheral) for ICSSG
+
+ interrupts:
+ maxItems: 2
+ description:
+ Interrupt specifiers to TX timestamp IRQ.
+
+ interrupt-names:
+ items:
+ - const: tx_ts0
+ - const: tx_ts1
+
+ ethernet-ports:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ ^port@[0-1]$:
+ type: object
+ description: ICSSG PRUETH external ports
+ $ref: ethernet-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ items:
+ - enum: [0, 1]
+ description: ICSSG PRUETH port number
+
+ interrupts:
+ maxItems: 1
+
+ ti,syscon-rgmii-delay:
+ items:
+ - items:
+ - description: phandle to system controller node
+ - description: The offset to ICSSG control register
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ phandle to system controller node and register offset
+ to ICSSG control register for RGMII transmit delay
+
+ required:
+ - reg
+ anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+
+required:
+ - compatible
+ - sram
+ - dmas
+ - dma-names
+ - ethernet-ports
+ - ti,mii-g-rt
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* Example k3-am654 base board SR2.0, dual-emac */
+ pruss2_eth: ethernet {
+ compatible = "ti,am654-icssg-prueth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&icssg2_rgmii_pins_default>;
+ sram = <&msmc_ram>;
+
+ ti,prus = <&pru2_0>, <&rtu2_0>, <&tx_pru2_0>,
+ <&pru2_1>, <&rtu2_1>, <&tx_pru2_1>;
+ firmware-name = "ti-pruss/am65x-pru0-prueth-fw.elf",
+ "ti-pruss/am65x-rtu0-prueth-fw.elf",
+ "ti-pruss/am65x-txpru0-prueth-fw.elf",
+ "ti-pruss/am65x-pru1-prueth-fw.elf",
+ "ti-pruss/am65x-rtu1-prueth-fw.elf",
+ "ti-pruss/am65x-txpru1-prueth-fw.elf";
+ ti,pruss-gp-mux-sel = <2>, /* MII mode */
+ <2>,
+ <2>,
+ <2>, /* MII mode */
+ <2>,
+ <2>;
+ dmas = <&main_udmap 0xc300>, /* egress slice 0 */
+ <&main_udmap 0xc301>, /* egress slice 0 */
+ <&main_udmap 0xc302>, /* egress slice 0 */
+ <&main_udmap 0xc303>, /* egress slice 0 */
+ <&main_udmap 0xc304>, /* egress slice 1 */
+ <&main_udmap 0xc305>, /* egress slice 1 */
+ <&main_udmap 0xc306>, /* egress slice 1 */
+ <&main_udmap 0xc307>, /* egress slice 1 */
+ <&main_udmap 0x4300>, /* ingress slice 0 */
+ <&main_udmap 0x4301>; /* ingress slice 1 */
+ dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+ "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+ "rx0", "rx1";
+ ti,mii-g-rt = <&icssg2_mii_g_rt>;
+ ti,iep = <&icssg2_iep0>, <&icssg2_iep1>;
+ interrupt-parent = <&icssg2_intc>;
+ interrupts = <24 0 2>, <25 1 3>;
+ interrupt-names = "tx_ts0", "tx_ts1";
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss2_emac0: port@0 {
+ reg = <0>;
+ phy-handle = <&pruss2_eth0_phy>;
+ phy-mode = "rgmii-id";
+ interrupts-extended = <&icssg2_intc 24>;
+ ti,syscon-rgmii-delay = <&scm_conf 0x4120>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss2_emac1: port@1 {
+ reg = <1>;
+ phy-handle = <&pruss2_eth1_phy>;
+ phy-mode = "rgmii-id";
+ interrupts-extended = <&icssg2_intc 25>;
+ ti,syscon-rgmii-delay = <&scm_conf 0x4124>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
index 67b63f1..252207a 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
@@ -28,6 +28,7 @@
- mediatek,mt76
- mediatek,mt7628-wmac
- mediatek,mt7622-wmac
+ - mediatek,mt7981-wmac
- mediatek,mt7986-wmac
reg:
@@ -71,6 +72,14 @@
ieee80211-freq-limit: true
+ nvmem-cells:
+ items:
+ - description: NVMEM cell with EEPROM
+
+ nvmem-cell-names:
+ items:
+ - const: eeprom
+
mediatek,eeprom-data:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
@@ -84,6 +93,7 @@
- description: offset containing EEPROM data
description:
Phandle to a MTD partition + offset containing EEPROM data
+ deprecated: true
big-endian:
$ref: /schemas/types.yaml#/definitions/flag
@@ -258,7 +268,8 @@
interrupt-parent = <&cpuintc>;
interrupts = <6>;
- mediatek,mtd-eeprom = <&factory 0x0>;
+ nvmem-cells = <&eeprom>;
+ nvmem-cell-names = "eeprom";
};
- |
diff --git a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
deleted file mode 100644
index 038dda4..0000000
--- a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-XILINX GMIITORGMII Converter Driver Device Tree Bindings
---------------------------------------------------------
-
-The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
-Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
-Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
-This core can be used in all three modes of operation(10/100/1000 Mb/s).
-The Management Data Input/Output (MDIO) interface is used to configure the
-Speed of operation. This core can switch dynamically between the three
-Different speed modes by configuring the conveter register through mdio write.
-
-This converter sits between the ethernet MAC and the external phy.
-MAC <==> GMII2RGMII <==> RGMII_PHY
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible : Should be "xlnx,gmii-to-rgmii-1.0"
-- reg : The ID number for the phy, usually a small integer
-- phy-handle : Should point to the external phy device.
- See ethernet.txt file in the same directory.
-
-Example:
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- phy: ethernet-phy@0 {
- ......
- };
- gmiitorgmii: gmiitorgmii@8 {
- compatible = "xlnx,gmii-to-rgmii-1.0";
- reg = <8>;
- phy-handle = <&phy>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml
new file mode 100644
index 0000000..0f781da
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/xlnx,gmii-to-rgmii.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx GMII to RGMII Converter
+
+maintainers:
+ - Harini Katakam <harini.katakam@amd.com>
+
+description:
+ The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
+ Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
+ ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
+ This core can be used in all three modes of operation(10/100/1000 Mb/s).
+ The Management Data Input/Output (MDIO) interface is used to configure the
+ speed of operation. This core can switch dynamically between the three
+ different speed modes by configuring the converter register through mdio write.
+ The core cannot function without an external phy connected to it.
+
+properties:
+ compatible:
+ const: xlnx,gmii-to-rgmii-1.0
+
+ reg:
+ minimum: 0
+ maximum: 31
+ description: The ID number for the phy.
+
+ phy-handle:
+ $ref: ethernet-controller.yaml#/properties/phy-handle
+
+required:
+ - compatible
+ - reg
+ - phy-handle
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+ gmiitorgmii@8 {
+ compatible = "xlnx,gmii-to-rgmii-1.0";
+ reg = <8>;
+ phy-handle = <&phy>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nios2/nios2.txt b/Documentation/devicetree/bindings/nios2/nios2.txt
index b95e831..3e9cabe 100644
--- a/Documentation/devicetree/bindings/nios2/nios2.txt
+++ b/Documentation/devicetree/bindings/nios2/nios2.txt
@@ -23,7 +23,7 @@
- altr,tlb-num-ways: Specifies the number of set-associativity ways in the TLB.
- altr,tlb-num-entries: Specifies the number of entries in the TLB.
- altr,tlb-ptr-sz: Specifies size of TLB pointer.
-- altr,has-mul: Specifies CPU hardware multipy support, should be 1.
+- altr,has-mul: Specifies CPU hardware multiply support, should be 1.
- altr,has-mmu: Specifies CPU support MMU support, should be 1.
- altr,has-initda: Specifies CPU support initda instruction, should be 1.
- altr,reset-addr: Specifies CPU reset address
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
new file mode 100644
index 0000000..df826b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP QorIQ eFuse support
+
+maintainers:
+ - Richard Alpe <richard@bit42.se>
+
+description:
+ Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ const: fsl,t1023-sfp
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ efuse@e8000 {
+ compatible = "fsl,t1023-sfp";
+ reg = <0xe8000 0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
index e698098..ac2381e 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
@@ -11,6 +11,15 @@
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
properties:
+ compatible:
+ oneOf:
+ - const: mac-base
+ description: >
+ Cell with base MAC address to be used for calculating extra relative
+ addresses.
+ It can be stored in a plain binary format (cell length 6) or as an
+ ASCII text like "00:11:22:33:44:55" (cell length 17).
+
reg:
maxItems: 1
@@ -25,6 +34,23 @@
description:
Size in bit within the address range specified by reg.
+allOf:
+ - if:
+ required: [ compatible ]
+ then:
+ if:
+ properties:
+ compatible:
+ contains:
+ const: mac-base
+ then:
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ required:
+ - "#nvmem-cell-cells"
+
required:
- reg
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
index c271537..9bd34bd 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
@@ -44,6 +44,18 @@
#address-cells = <1>;
#size-cells = <1>;
+ mac@100 {
+ compatible = "mac-base";
+ reg = <0x100 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ mac@110 {
+ compatible = "mac-base";
+ reg = <0x110 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
+
calibration@4000 {
reg = <0x4000 0x100>;
};
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
index 714a653..ee8ac32 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
@@ -14,7 +14,7 @@
infrastructure shall provide a non-volatile memory with a table whose the
content is well specified and gives many information about the manufacturer
(name, country of manufacture, etc) as well as device caracteristics (serial
- number, hardware version, mac addresses, etc). The underlaying device type
+ number, hardware version, mac addresses, etc). The underlying device type
(flash, EEPROM,...) is not specified. The exact location of each value is also
dynamic and should be discovered at run time because it depends on the
parameters the manufacturer decided to embed.
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 9802441..9f921d9 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -49,7 +49,10 @@
patternProperties:
"@[0-9a-f]+(,[0-7])?$":
type: object
- $ref: layouts/fixed-cell.yaml
+ allOf:
+ - $ref: layouts/fixed-cell.yaml
+ - properties:
+ compatible: false
deprecated: true
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 6cd4682..8740938 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -23,11 +23,13 @@
- qcom,ipq8064-qfprom
- qcom,ipq8074-qfprom
- qcom,ipq9574-qfprom
+ - qcom,msm8226-qfprom
- qcom,msm8916-qfprom
- qcom,msm8974-qfprom
- qcom,msm8976-qfprom
- qcom,msm8996-qfprom
- qcom,msm8998-qfprom
+ - qcom,qcm2290-qfprom
- qcom,qcs404-qfprom
- qcom,sc7180-qfprom
- qcom,sc7280-qfprom
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml
new file mode 100644
index 0000000..9b133f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/qcom,sec-qfprom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies Inc, Secure QFPROM Efuse
+
+maintainers:
+ - Komal Bajaj <quic_kbajaj@quicinc.com>
+
+description:
+ For some of the Qualcomm SoC's, it is possible that the qfprom region is
+ protected from non-secure access. In such situations, the OS have to use
+ secure calls to read the region.
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,qdu1000-sec-qfprom
+ - const: qcom,sec-qfprom
+
+ reg:
+ items:
+ - description: The secure qfprom corrected region.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ efuse@221c8000 {
+ compatible = "qcom,qdu1000-sec-qfprom", "qcom,sec-qfprom";
+ reg = <0 0x221c8000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ multi_chan_ddr: multi-chan-ddr@12b {
+ reg = <0x12b 0x1>;
+ bits = <0 2>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
new file mode 100644
index 0000000..02d1d2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/opp/operating-points-v2-ti-cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI CPU OPP (Operating Performance Points)
+
+description:
+ TI SoCs, like those in the AM335x, AM437x, AM57xx, AM62x, and DRA7xx
+ families, the CPU frequencies subset and the voltage value of each
+ OPP vary based on the silicon variant used. The data sheet sections
+ corresponding to "Operating Performance Points" describe the frequency
+ and voltage values based on device type and speed bin information
+ blown in corresponding eFuse bits as referred to by the Technical
+ Reference Manual.
+
+ This document extends the operating-points-v2 binding by providing
+ the hardware description for the scheme mentioned above.
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+
+allOf:
+ - $ref: opp-v2-base.yaml#
+
+properties:
+ compatible:
+ const: operating-points-v2-ti-cpu
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ points to syscon node representing the control module
+ register space of the SoC.
+
+ opp-shared: true
+
+patternProperties:
+ '^opp(-?[0-9]+)*$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ clock-latency-ns: true
+ opp-hz: true
+ opp-microvolt: true
+ opp-supported-hw: true
+ opp-suspend: true
+ turbo-mode: true
+
+ required:
+ - opp-hz
+ - opp-supported-hw
+
+required:
+ - compatible
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0020>;
+ opp-suspend;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0040>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1325000 1298500 1351500>;
+ opp-supported-hw = <0x04 0x0200>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
index 47e6f36..e2f8f7a 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
@@ -56,7 +56,7 @@
need to be configured and that is left for the implementation
specific binding.
minItems: 1
- maxItems: 16
+ maxItems: 32
items:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml b/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml
new file mode 100644
index 0000000..693f225
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/opp/ti,omap-opp-supply.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OMAP compatible OPP supply
+
+description:
+ OMAP5, DRA7, and AM57 families of SoCs have Class 0 AVS eFuse
+ registers, which contain OPP-specific voltage information tailored
+ for the specific device. This binding provides the information
+ needed to describe such a hardware values and relate them to program
+ the primary regulator during an OPP transition.
+
+ Also, some supplies may have an associated vbb-supply, an Adaptive
+ Body Bias regulator, which must transition in a specific sequence
+ w.r.t the vdd-supply and clk when making an OPP transition. By
+ supplying two regulators to the device that will undergo OPP
+ transitions, we can use the multi-regulator support implemented by
+ the OPP core to describe both regulators the platform needs. The
+ OPP core binding Documentation/devicetree/bindings/opp/opp-v2.yaml
+ provides further information (refer to Example 4 Handling multiple
+ regulators).
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+
+properties:
+ $nodename:
+ pattern: '^opp-supply(@[0-9a-f]+)?$'
+
+ compatible:
+ oneOf:
+ - description: Basic OPP supply controlling VDD and VBB
+ const: ti,omap-opp-supply
+ - description: OMAP5+ optimized voltages in efuse(Class 0) VDD along with
+ VBB.
+ const: ti,omap5-opp-supply
+ - description: OMAP5+ optimized voltages in efuse(class0) VDD but no VBB
+ const: ti,omap5-core-opp-supply
+
+ reg:
+ maxItems: 1
+
+ ti,absolute-max-voltage-uv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Absolute maximum voltage for the OPP supply in micro-volts.
+ minimum: 750000
+ maximum: 1500000
+
+ ti,efuse-settings:
+ description: An array of u32 tuple items providing information about
+ optimized efuse configuration.
+ minItems: 1
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: Reference voltage in micro-volts (OPP Voltage)
+ minimum: 750000
+ maximum: 1500000
+ multipleOf: 10000
+ - description: efuse offset where the optimized voltage is located
+ multipleOf: 4
+ maximum: 256
+
+required:
+ - compatible
+ - ti,absolute-max-voltage-uv
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: ti,omap-opp-supply
+ then:
+ required:
+ - reg
+ - ti,efuse-settings
+
+additionalProperties: false
+
+examples:
+ - |
+ opp-supply {
+ compatible = "ti,omap-opp-supply";
+ ti,absolute-max-voltage-uv = <1375000>;
+ };
+ - |
+ opp-supply@4a003b20 {
+ compatible = "ti,omap5-opp-supply";
+ reg = <0x4a003b20 0x8>;
+ ti,efuse-settings =
+ /* uV offset */
+ <1060000 0x0>,
+ <1160000 0x4>,
+ <1210000 0x8>;
+ ti,absolute-max-voltage-uv = <1500000>;
+ };
diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
deleted file mode 100644
index b70d326..0000000
--- a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Texas Instruments OMAP compatible OPP supply description
-
-OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
-contain data that can be used to adjust voltages programmed for some of their
-supplies for more efficient operation. This binding provides the information
-needed to read these values and use them to program the main regulator during
-an OPP transitions.
-
-Also, some supplies may have an associated vbb-supply which is an Adaptive Body
-Bias regulator which much be transitioned in a specific sequence with regards
-to the vdd-supply and clk when making an OPP transition. By supplying two
-regulators to the device that will undergo OPP transitions we can make use
-of the multi regulator binding that is part of the OPP core described here [1]
-to describe both regulators needed by the platform.
-
-[1] Documentation/devicetree/bindings/opp/opp-v2.yaml
-
-Required Properties for Device Node:
-- vdd-supply: phandle to regulator controlling VDD supply
-- vbb-supply: phandle to regulator controlling Body Bias supply
- (Usually Adaptive Body Bias regulator)
-
-Required Properties for opp-supply node:
-- compatible: Should be one of:
- "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
- "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
- along with VBB
- "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
- but no VBB.
-- reg: Address and length of the efuse register set for the device (mandatory
- only for "ti,omap5-opp-supply")
-- ti,efuse-settings: An array of u32 tuple items providing information about
- optimized efuse configuration. Each item consists of the following:
- volt: voltage in uV - reference voltage (OPP voltage)
- efuse_offseet: efuse offset from reg where the optimized voltage is stored.
-- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
-
-Example:
-
-/* Device Node (CPU) */
-cpus {
- cpu0: cpu@0 {
- device_type = "cpu";
-
- ...
-
- vdd-supply = <&vcc>;
- vbb-supply = <&abb_mpu>;
- };
-};
-
-/* OMAP OPP Supply with Class0 registers */
-opp_supply_mpu: opp_supply@4a003b20 {
- compatible = "ti,omap5-opp-supply";
- reg = <0x4a003b20 0x8>;
- ti,efuse-settings = <
- /* uV offset */
- 1060000 0x0
- 1160000 0x4
- 1210000 0x8
- >;
- ti,absolute-max-voltage-uv = <1500000>;
-};
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
index 8111122..a223ce0 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
@@ -11,10 +11,13 @@
properties:
compatible:
- enum:
- - qcom,sdx55-pcie-ep
- - qcom,sdx65-pcie-ep
- - qcom,sm8450-pcie-ep
+ oneOf:
+ - enum:
+ - qcom,sdx55-pcie-ep
+ - qcom,sm8450-pcie-ep
+ - items:
+ - const: qcom,sdx65-pcie-ep
+ - const: qcom,sdx55-pcie-ep
reg:
items:
@@ -71,6 +74,14 @@
description: GPIO used as WAKE# output signal
maxItems: 1
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: pcie-mem
+ - const: cpu-pcie
+
resets:
maxItems: 1
@@ -98,6 +109,8 @@
- interrupts
- interrupt-names
- reset-gpios
+ - interconnects
+ - interconnect-names
- resets
- reset-names
- power-domains
@@ -110,7 +123,6 @@
contains:
enum:
- qcom,sdx55-pcie-ep
- - qcom,sdx65-pcie-ep
then:
properties:
clocks:
@@ -167,7 +179,9 @@
- |
#include <dt-bindings/clock/qcom,gcc-sdx55.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sdx55.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+
pcie_ep: pcie-ep@1c00000 {
compatible = "qcom,sdx55-pcie-ep";
reg = <0x01c00000 0x3000>,
@@ -194,6 +208,9 @@
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "global", "doorbell";
+ interconnects = <&system_noc MASTER_PCIE &mc_virt SLAVE_EBI_CH0>,
+ <&mem_noc MASTER_AMPSS_M0 &system_noc SLAVE_PCIE_0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
reset-gpios = <&tlmm 57 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>;
resets = <&gcc GCC_PCIE_BCR>;
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index 81971be4..eadba38 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -29,6 +29,7 @@
- qcom,pcie-msm8996
- qcom,pcie-qcs404
- qcom,pcie-sa8540p
+ - qcom,pcie-sa8775p
- qcom,pcie-sc7280
- qcom,pcie-sc8180x
- qcom,pcie-sc8280xp
@@ -211,6 +212,7 @@
compatible:
contains:
enum:
+ - qcom,pcie-sa8775p
- qcom,pcie-sc7280
- qcom,pcie-sc8180x
- qcom,pcie-sc8280xp
@@ -748,7 +750,32 @@
compatible:
contains:
enum:
+ - qcom,pcie-sa8775p
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ resets:
+ maxItems: 1
+ reset-names:
+ items:
+ - const: pci # PCIe core reset
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pcie-sa8540p
+ - qcom,pcie-sa8775p
- qcom,pcie-sc8280xp
then:
required:
@@ -790,6 +817,7 @@
contains:
enum:
- qcom,pcie-msm8996
+ - qcom,pcie-sa8775p
- qcom,pcie-sc7280
- qcom,pcie-sc8180x
- qcom,pcie-sdm845
diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
index a4f61ce..1ae8dcf 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
@@ -60,6 +60,61 @@
- const: aux
- const: pipe
+ interrupts:
+ items:
+ - description:
+ Combined system interrupt, which is used to signal the following
+ interrupts - phy_link_up, dll_link_up, link_req_rst_not, hp_pme,
+ hp, hp_msi, link_auto_bw, link_auto_bw_msi, bw_mgt, bw_mgt_msi,
+ edma_wr, edma_rd, dpa_sub_upd, rbar_update, link_eq_req, ep_elbi_app
+ - description:
+ Combined PM interrupt, which is used to signal the following
+ interrupts - linkst_in_l1sub, linkst_in_l1, linkst_in_l2,
+ linkst_in_l0s, linkst_out_l1sub, linkst_out_l1, linkst_out_l2,
+ linkst_out_l0s, pm_dstate_update
+ - description:
+ Combined message interrupt, which is used to signal the following
+ interrupts - ven_msg, unlock_msg, ltr_msg, cfg_pme, cfg_pme_msi,
+ pm_pme, pm_to_ack, pm_turnoff, obff_idle, obff_obff, obff_cpu_active
+ - description:
+ Combined legacy interrupt, which is used to signal the following
+ interrupts - inta, intb, intc, intd
+ - description:
+ Combined error interrupt, which is used to signal the following
+ interrupts - aer_rc_err, aer_rc_err_msi, rx_cpl_timeout,
+ tx_cpl_timeout, cor_err_sent, nf_err_sent, f_err_sent, cor_err_rx,
+ nf_err_rx, f_err_rx, radm_qoverflow
+
+ interrupt-names:
+ items:
+ - const: sys
+ - const: pmc
+ - const: msg
+ - const: legacy
+ - const: err
+
+ legacy-interrupt-controller:
+ description: Interrupt controller node for handling legacy PCI interrupts.
+ type: object
+ additionalProperties: false
+ properties:
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ items:
+ - description: combined legacy interrupt
+ required:
+ - "#address-cells"
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupts
+
msi-map: true
num-lanes: true
@@ -108,6 +163,7 @@
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
bus {
#address-cells = <2>;
@@ -127,6 +183,12 @@
"aclk_dbi", "pclk",
"aux";
device_type = "pci";
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "sys", "pmc", "msg", "legacy", "err";
linux,pci-domain = <2>;
max-link-speed = <2>;
msi-map = <0x2000 &its 0x2000 0x1000>;
@@ -140,6 +202,14 @@
reset-names = "pipe";
#address-cells = <3>;
#size-cells = <2>;
+
+ legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
index 1a83f0f..8bbdeb8 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
@@ -25,6 +25,15 @@
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
- $ref: /schemas/pci/snps,dw-pcie-common.yaml#
+ - if:
+ not:
+ required:
+ - msi-map
+ then:
+ properties:
+ interrupt-names:
+ contains:
+ const: msi
properties:
reg:
@@ -188,14 +197,15 @@
Link Control register).
const: bw_mg
- description:
+ Combined Legacy A/B/C/D interrupt signal. See "^int(a|b|c|d)$" for
+ details.
+ const: legacy
+ - description:
Vendor-specific IRQ names. Consider using the generic names above
for new bindings.
oneOf:
- description: See native "app" IRQ for details
- enum: [ intr ]
- allOf:
- - contains:
- const: msi
+ enum: [ intr, sys, pmc, msg, err ]
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml b/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml
new file mode 100644
index 0000000..087e02a
--- /dev/null
+++ b/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/peci/nuvoton,npcm-peci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton PECI Bus
+
+maintainers:
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+allOf:
+ - $ref: peci-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-peci
+ - nuvoton,npcm845-peci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description:
+ Clock source for PECI controller. Should reference the APB clock.
+ maxItems: 1
+
+ cmd-timeout-ms:
+ minimum: 1
+ maximum: 1000
+ default: 1000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ peci-controller@f0100000 {
+ compatible = "nuvoton,npcm750-peci";
+ reg = <0xf0100000 0x200>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM7XX_CLK_APB3>;
+ cmd-timeout-ms = <1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
index b35c4d2..99eac88 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# 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#
diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index 230a17f..2bb9154 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -64,7 +64,7 @@
properties:
$nodename:
- pattern: "^t-phy@[0-9a-f]+$"
+ pattern: "^t-phy(@[0-9a-f]+)?$"
compatible:
oneOf:
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
index d16bd6e..e9237c5 100644
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/nvidia,tegra210-xusb-padctl.yaml#
diff --git a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
index 0d70c83..104953e 100644
--- a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
@@ -14,7 +14,7 @@
- #size-cells: Must be 0.
The INNO USB2 PHY device should be a child node of peripheral controller that
-contains the PHY configuration register, and each device suppports up to 2 PHY
+contains the PHY configuration register, and each device supports up to 2 PHY
ports which are represented as child nodes of INNO USB2 PHY device.
Required properties for PHY port node:
diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
index afbc7e2..c7970c0 100644
--- a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
@@ -8,7 +8,7 @@
- clocks: Must contain an entry for each entry in clock-names.
See ../clock/clock-bindings.txt for details.
- clock-names: Must include "usb_phy".
- - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
+ - img,cr-top: Must contain a phandle to the CR_TOP syscon node.
- img,refclk: Indicates the reference clock source for the USB PHY.
See <dt-bindings/phy/phy-pistachio-usb.h> for a list of valid values.
diff --git a/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt b/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt
index 660a13c..da94426 100644
--- a/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt
@@ -4,7 +4,7 @@
- compatible: "marvell,pxa1928-usb-phy" or "marvell,pxa1928-hsic-phy"
- reg: base address and length of the registers
- clocks - A single clock. From common clock binding.
-- #phys-cells: should be 0. From commmon phy binding.
+- #phys-cells: should be 0. From common phy binding.
- resets: reference to the reset controller
Example:
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml
new file mode 100644
index 0000000..2671a04
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq5332-usb-hsphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: M31 USB PHY
+
+maintainers:
+ - Sricharan Ramabadhran <quic_srichara@quicinc.com>
+ - Varadarajan Narayanan <quic_varada@quicinc.com>
+
+description:
+ USB M31 PHY (https://www.m31tech.com) found in Qualcomm
+ IPQ5018, IPQ5332 SoCs.
+
+properties:
+ compatible:
+ items:
+ - const: qcom,ipq5332-usb-hsphy
+
+ "#phy-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cfg_ahb
+
+ resets:
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Phandle to 5V regulator supply to PHY digital circuit.
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
+ usb-phy@7b000 {
+ compatible = "qcom,ipq5332-usb-hsphy";
+ reg = <0x0007b000 0x12c>;
+
+ clocks = <&gcc GCC_USB0_PHY_CFG_AHB_CLK>;
+ clock-names = "cfg_ahb";
+
+ #phy-cells = <0>;
+
+ resets = <&gcc GCC_QUSB2_0_PHY_BCR>;
+
+ vdd-supply = <®ulator_fixed_5p0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index 3d42ee3..5073007 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -13,287 +13,79 @@
QMP PHY controller supports physical layer functionality for a number of
controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
- Note that these bindings are for SoCs up to SC8180X. For newer SoCs, see
- qcom,sc8280xp-qmp-pcie-phy.yaml.
-
properties:
compatible:
enum:
- qcom,ipq6018-qmp-pcie-phy
- qcom,ipq8074-qmp-gen3-pcie-phy
- qcom,ipq8074-qmp-pcie-phy
- - qcom,msm8998-qmp-pcie-phy
- - qcom,sc8180x-qmp-pcie-phy
- - qcom,sdm845-qhp-pcie-phy
- - qcom,sdm845-qmp-pcie-phy
- - qcom,sdx55-qmp-pcie-phy
- - qcom,sm8250-qmp-gen3x1-pcie-phy
- - qcom,sm8250-qmp-gen3x2-pcie-phy
- - qcom,sm8250-qmp-modem-pcie-phy
- - qcom,sm8450-qmp-gen3x1-pcie-phy
- - qcom,sm8450-qmp-gen4x2-pcie-phy
reg:
items:
- description: serdes
- "#address-cells":
- enum: [ 1, 2 ]
-
- "#size-cells":
- enum: [ 1, 2 ]
-
- ranges: true
-
clocks:
- minItems: 2
- maxItems: 4
+ maxItems: 3
clock-names:
- minItems: 2
- maxItems: 4
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: pipe
resets:
- minItems: 1
maxItems: 2
reset-names:
- minItems: 1
- maxItems: 2
+ items:
+ - const: phy
+ - const: common
- vdda-phy-supply: true
+ "#clock-cells":
+ const: 0
- vdda-pll-supply: true
+ clock-output-names:
+ maxItems: 1
- vddp-ref-clk-supply: true
-
-patternProperties:
- "^phy@[0-9a-f]+$":
- type: object
- description: single PHY-provider child node
- properties:
- reg:
- minItems: 3
- maxItems: 6
-
- clocks:
- items:
- - description: PIPE clock
-
- clock-names:
- deprecated: true
- items:
- - const: pipe0
-
- "#clock-cells":
- const: 0
-
- clock-output-names:
- maxItems: 1
-
- "#phy-cells":
- const: 0
-
- required:
- - reg
- - clocks
- - "#clock-cells"
- - clock-output-names
- - "#phy-cells"
-
- additionalProperties: false
+ "#phy-cells":
+ const: 0
required:
- compatible
- reg
- - "#address-cells"
- - "#size-cells"
- - ranges
- clocks
- clock-names
- resets
- reset-names
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
additionalProperties: false
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8998-qmp-pcie-phy
- then:
- properties:
- clocks:
- maxItems: 3
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- resets:
- maxItems: 2
- reset-names:
- items:
- - const: phy
- - const: common
- required:
- - vdda-phy-supply
- - vdda-pll-supply
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,ipq6018-qmp-pcie-phy
- - qcom,ipq8074-qmp-gen3-pcie-phy
- - qcom,ipq8074-qmp-pcie-phy
- then:
- properties:
- clocks:
- maxItems: 2
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- resets:
- maxItems: 2
- reset-names:
- items:
- - const: phy
- - const: common
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8180x-qmp-pcie-phy
- - qcom,sdm845-qhp-pcie-phy
- - qcom,sdm845-qmp-pcie-phy
- - qcom,sdx55-qmp-pcie-phy
- - qcom,sm8250-qmp-gen3x1-pcie-phy
- - qcom,sm8250-qmp-gen3x2-pcie-phy
- - qcom,sm8250-qmp-modem-pcie-phy
- - qcom,sm8450-qmp-gen3x1-pcie-phy
- - qcom,sm8450-qmp-gen4x2-pcie-phy
- then:
- properties:
- clocks:
- maxItems: 4
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: refgen
- resets:
- maxItems: 1
- reset-names:
- items:
- - const: phy
- required:
- - vdda-phy-supply
- - vdda-pll-supply
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8180x-qmp-pcie-phy
- - qcom,sm8250-qmp-gen3x2-pcie-phy
- - qcom,sm8250-qmp-modem-pcie-phy
- - qcom,sm8450-qmp-gen4x2-pcie-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX lane 1
- - description: RX lane 1
- - description: PCS
- - description: TX lane 2
- - description: RX lane 2
- - description: PCS_MISC
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sdm845-qmp-pcie-phy
- - qcom,sdx55-qmp-pcie-phy
- - qcom,sm8250-qmp-gen3x1-pcie-phy
- - qcom,sm8450-qmp-gen3x1-pcie-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX
- - description: RX
- - description: PCS
- - description: PCS_MISC
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,ipq6018-qmp-pcie-phy
- - qcom,ipq8074-qmp-pcie-phy
- - qcom,msm8998-qmp-pcie-phy
- - qcom,sdm845-qhp-pcie-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX
- - description: RX
- - description: PCS
-
examples:
- |
- #include <dt-bindings/clock/qcom,gcc-sm8250.h>
- phy-wrapper@1c0e000 {
- compatible = "qcom,sm8250-qmp-gen3x2-pcie-phy";
- reg = <0x01c0e000 0x1c0>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x01c0e000 0x1000>;
+ #include <dt-bindings/clock/qcom,gcc-ipq6018.h>
+ #include <dt-bindings/reset/qcom,gcc-ipq6018.h>
- clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
- <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
- <&gcc GCC_PCIE_WIGIG_CLKREF_EN>,
- <&gcc GCC_PCIE1_PHY_REFGEN_CLK>;
- clock-names = "aux", "cfg_ahb", "ref", "refgen";
+ phy@84000 {
+ compatible = "qcom,ipq6018-qmp-pcie-phy";
+ reg = <0x0 0x00084000 0x0 0x1000>;
- resets = <&gcc GCC_PCIE_1_PHY_BCR>;
- reset-names = "phy";
+ clocks = <&gcc GCC_PCIE0_AUX_CLK>,
+ <&gcc GCC_PCIE0_AHB_CLK>,
+ <&gcc GCC_PCIE0_PIPE_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "pipe";
- vdda-phy-supply = <&vreg_l10c_0p88>;
- vdda-pll-supply = <&vreg_l6b_1p2>;
+ clock-output-names = "gcc_pcie0_pipe_clk_src";
+ #clock-cells = <0>;
- phy@200 {
- reg = <0x200 0x170>,
- <0x400 0x200>,
- <0xa00 0x1f0>,
- <0x600 0x170>,
- <0x800 0x200>,
- <0xe00 0xf4>;
+ #phy-cells = <0>;
- clocks = <&gcc GCC_PCIE_1_PIPE_CLK>;
-
- #clock-cells = <0>;
- clock-output-names = "pcie_1_pipe_clk";
-
- #phy-cells = <0>;
- };
+ resets = <&gcc GCC_PCIE0_PHY_BCR>,
+ <&gcc GCC_PCIE0PHY_PHY_BCR>;
+ reset-names = "phy",
+ "common";
};
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
deleted file mode 100644
index 881ba54..0000000
--- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-ufs-phy.yaml
+++ /dev/null
@@ -1,228 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/phy/qcom,msm8996-qmp-ufs-phy.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm QMP PHY controller (UFS, MSM8996)
-
-maintainers:
- - Vinod Koul <vkoul@kernel.org>
-
-description:
- QMP PHY controller supports physical layer functionality for a number of
- controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
-
- Note that these bindings are for SoCs up to SC8180X. For newer SoCs, see
- qcom,sc8280xp-qmp-ufs-phy.yaml.
-
-properties:
- compatible:
- enum:
- - qcom,msm8996-qmp-ufs-phy
- - qcom,msm8998-qmp-ufs-phy
- - qcom,sc8180x-qmp-ufs-phy
- - qcom,sdm845-qmp-ufs-phy
- - qcom,sm6115-qmp-ufs-phy
- - qcom,sm6350-qmp-ufs-phy
- - qcom,sm8150-qmp-ufs-phy
- - qcom,sm8250-qmp-ufs-phy
- - qcom,sm8350-qmp-ufs-phy
- - qcom,sm8450-qmp-ufs-phy
-
- reg:
- items:
- - description: serdes
-
- "#address-cells":
- enum: [ 1, 2 ]
-
- "#size-cells":
- enum: [ 1, 2 ]
-
- ranges: true
-
- clocks:
- minItems: 1
- maxItems: 3
-
- clock-names:
- minItems: 1
- maxItems: 3
-
- power-domains:
- maxItems: 1
-
- resets:
- maxItems: 1
-
- reset-names:
- items:
- - const: ufsphy
-
- vdda-phy-supply: true
-
- vdda-pll-supply: true
-
- vddp-ref-clk-supply: true
-
-patternProperties:
- "^phy@[0-9a-f]+$":
- type: object
- description: single PHY-provider child node
- properties:
- reg:
- minItems: 3
- maxItems: 6
-
- "#clock-cells":
- const: 1
-
- "#phy-cells":
- const: 0
-
- required:
- - reg
- - "#phy-cells"
-
- additionalProperties: false
-
-required:
- - compatible
- - reg
- - "#address-cells"
- - "#size-cells"
- - ranges
- - clocks
- - clock-names
- - resets
- - reset-names
- - vdda-phy-supply
- - vdda-pll-supply
-
-additionalProperties: false
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8996-qmp-ufs-phy
- then:
- properties:
- clocks:
- maxItems: 1
- clock-names:
- items:
- - const: ref
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8998-qmp-ufs-phy
- - qcom,sc8180x-qmp-ufs-phy
- - qcom,sdm845-qmp-ufs-phy
- - qcom,sm6115-qmp-ufs-phy
- - qcom,sm6350-qmp-ufs-phy
- - qcom,sm8150-qmp-ufs-phy
- - qcom,sm8250-qmp-ufs-phy
- then:
- properties:
- clocks:
- maxItems: 2
- clock-names:
- items:
- - const: ref
- - const: ref_aux
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm8450-qmp-ufs-phy
- then:
- properties:
- clocks:
- maxItems: 3
- clock-names:
- items:
- - const: ref
- - const: ref_aux
- - const: qref
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8998-qmp-ufs-phy
- - qcom,sc8180x-qmp-ufs-phy
- - qcom,sdm845-qmp-ufs-phy
- - qcom,sm6350-qmp-ufs-phy
- - qcom,sm8150-qmp-ufs-phy
- - qcom,sm8250-qmp-ufs-phy
- - qcom,sm8350-qmp-ufs-phy
- - qcom,sm8450-qmp-ufs-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX lane 1
- - description: RX lane 1
- - description: PCS
- - description: TX lane 2
- - description: RX lane 2
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8996-qmp-ufs-phy
- - qcom,sm6115-qmp-ufs-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX
- - description: RX
- - description: PCS
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sm8250.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
-
- phy-wrapper@1d87000 {
- compatible = "qcom,sm8250-qmp-ufs-phy";
- reg = <0x01d87000 0x1c0>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x01d87000 0x1000>;
-
- clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
- clock-names = "ref", "ref_aux";
-
- resets = <&ufs_mem_hc 0>;
- reset-names = "ufsphy";
-
- vdda-phy-supply = <&vreg_l6b>;
- vdda-pll-supply = <&vreg_l3b>;
-
- phy@400 {
- reg = <0x400 0x108>,
- <0x600 0x1e0>,
- <0xc00 0x1dc>,
- <0x800 0x108>,
- <0xa00 0x1e0>;
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
index 4c96dab..827109d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-usb3-phy.yaml
@@ -23,25 +23,16 @@
- qcom,ipq8074-qmp-usb3-phy
- qcom,msm8996-qmp-usb3-phy
- qcom,msm8998-qmp-usb3-phy
- - qcom,sc7180-qmp-usb3-phy
- - qcom,sc8180x-qmp-usb3-phy
- - qcom,sdm845-qmp-usb3-phy
- qcom,sdm845-qmp-usb3-uni-phy
- qcom,sdx55-qmp-usb3-uni-phy
- qcom,sdx65-qmp-usb3-uni-phy
- - qcom,sm8150-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- - qcom,sm8250-qmp-usb3-phy
- qcom,sm8250-qmp-usb3-uni-phy
- - qcom,sm8350-qmp-usb3-phy
- qcom,sm8350-qmp-usb3-uni-phy
- - qcom,sm8450-qmp-usb3-phy
reg:
- minItems: 1
items:
- description: serdes
- - description: DP_COM
"#address-cells":
enum: [ 1, 2 ]
@@ -131,28 +122,6 @@
compatible:
contains:
enum:
- - qcom,sc7180-qmp-usb3-phy
- then:
- properties:
- clocks:
- maxItems: 4
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: com_aux
- resets:
- maxItems: 1
- reset-names:
- items:
- - const: phy
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,sdm845-qmp-usb3-uni-phy
then:
properties:
@@ -202,7 +171,6 @@
compatible:
contains:
enum:
- - qcom,sm8150-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-usb3-uni-phy
- qcom,sm8350-qmp-usb3-uni-phy
@@ -228,51 +196,6 @@
compatible:
contains:
enum:
- - qcom,sm8250-qmp-usb3-phy
- - qcom,sm8350-qmp-usb3-phy
- then:
- properties:
- clocks:
- maxItems: 3
- clock-names:
- items:
- - const: aux
- - const: ref_clk_src
- - const: com_aux
- resets:
- maxItems: 2
- reset-names:
- items:
- - const: phy
- - const: common
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sdm845-qmp-usb3-phy
- - qcom,sm8150-qmp-usb3-phy
- - qcom,sm8350-qmp-usb3-phy
- - qcom,sm8450-qmp-usb3-phy
- then:
- patternProperties:
- "^phy@[0-9a-f]+$":
- properties:
- reg:
- items:
- - description: TX lane 1
- - description: RX lane 1
- - description: PCS
- - description: TX lane 2
- - description: RX lane 2
- - description: PCS_MISC
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8998-qmp-usb3-phy
then:
patternProperties:
@@ -293,12 +216,9 @@
enum:
- qcom,ipq6018-qmp-usb3-phy
- qcom,ipq8074-qmp-usb3-phy
- - qcom,sc7180-qmp-usb3-phy
- - qcom,sc8180x-qmp-usb3-phy
- qcom,sdx55-qmp-usb3-uni-phy
- qcom,sdx65-qmp-usb3-uni-phy
- qcom,sm8150-qmp-usb3-uni-phy
- - qcom,sm8250-qmp-usb3-phy
then:
patternProperties:
"^phy@[0-9a-f]+$":
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml
new file mode 100644
index 0000000..d05eef0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,msm8998-qmp-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (PCIe, MSM8998)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ const: qcom,msm8998-qmp-pcie-phy
+
+ reg:
+ items:
+ - description: serdes
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+ - const: pipe
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: common
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8998.h>
+
+ phy@1c18000 {
+ compatible = "qcom,msm8998-qmp-pcie-phy";
+ reg = <0x01c06000 0x1000>;
+
+ clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_CLKREF_CLK>,
+ <&gcc GCC_PCIE_0_PIPE_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "pipe";
+
+ clock-output-names = "pcie_0_pipe_clk_src";
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ resets = <&gcc GCC_PCIE_0_PHY_BCR>, <&gcc GCC_PCIE_PHY_BCR>;
+ reset-names = "phy", "common";
+
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l2a_1p2>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
deleted file mode 100644
index d307343..0000000
--- a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml
+++ /dev/null
@@ -1,282 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm QMP USB3 DP PHY controller (SC7180)
-
-description:
- The QMP PHY controller supports physical layer functionality for a number of
- controllers on Qualcomm chipsets, such as, PCIe, UFS and USB.
-
- Note that these bindings are for SoCs up to SC8180X. For newer SoCs, see
- qcom,sc8280xp-qmp-usb43dp-phy.yaml.
-
-maintainers:
- - Wesley Cheng <quic_wcheng@quicinc.com>
-
-properties:
- compatible:
- oneOf:
- - enum:
- - qcom,sc7180-qmp-usb3-dp-phy
- - qcom,sc8180x-qmp-usb3-dp-phy
- - qcom,sdm845-qmp-usb3-dp-phy
- - qcom,sm8250-qmp-usb3-dp-phy
- - items:
- - enum:
- - qcom,sc7280-qmp-usb3-dp-phy
- - const: qcom,sm8250-qmp-usb3-dp-phy
-
- reg:
- items:
- - description: Address and length of PHY's USB serdes block.
- - description: Address and length of the DP_COM control block.
- - description: Address and length of PHY's DP serdes block.
-
- reg-names:
- items:
- - const: usb
- - const: dp_com
- - const: dp
-
- "#address-cells":
- enum: [ 1, 2 ]
-
- "#size-cells":
- enum: [ 1, 2 ]
-
- ranges: true
-
- clocks:
- minItems: 3
- maxItems: 4
-
- clock-names:
- minItems: 3
- maxItems: 4
-
- power-domains:
- maxItems: 1
-
- orientation-switch:
- description: Flag the port as possible handler of orientation switching
- type: boolean
-
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
-
- reset-names:
- items:
- - const: phy
- - const: common
-
- vdda-phy-supply:
- description:
- Phandle to a regulator supply to PHY core block.
-
- vdda-pll-supply:
- description:
- Phandle to 1.8V regulator supply to PHY refclk pll block.
-
- vddp-ref-clk-supply:
- description:
- Phandle to a regulator supply to any specific refclk pll block.
-
-# Required nodes:
-patternProperties:
- "^usb3-phy@[0-9a-f]+$":
- type: object
- additionalProperties: false
- description:
- The USB3 PHY.
-
- properties:
- reg:
- items:
- - description: Address and length of TX.
- - description: Address and length of RX.
- - description: Address and length of PCS.
- - description: Address and length of TX2.
- - description: Address and length of RX2.
- - description: Address and length of pcs_misc.
-
- clocks:
- items:
- - description: pipe clock
-
- clock-names:
- deprecated: true
- items:
- - const: pipe0
-
- clock-output-names:
- items:
- - const: usb3_phy_pipe_clk_src
-
- '#clock-cells':
- const: 0
-
- '#phy-cells':
- const: 0
-
- required:
- - reg
- - clocks
- - '#clock-cells'
- - '#phy-cells'
-
- "^dp-phy@[0-9a-f]+$":
- type: object
- additionalProperties: false
- description:
- The DP PHY.
-
- properties:
- reg:
- items:
- - description: Address and length of TX.
- - description: Address and length of RX.
- - description: Address and length of PCS.
- - description: Address and length of TX2.
- - description: Address and length of RX2.
-
- '#clock-cells':
- const: 1
-
- '#phy-cells':
- const: 0
-
- required:
- - reg
- - '#clock-cells'
- - '#phy-cells'
-
-required:
- - compatible
- - reg
- - "#address-cells"
- - "#size-cells"
- - ranges
- - clocks
- - clock-names
- - resets
- - reset-names
- - vdda-phy-supply
- - vdda-pll-supply
-
-allOf:
- - if:
- properties:
- compatible:
- enum:
- - qcom,sc7180-qmp-usb3-dp-phy
- - qcom,sdm845-qmp-usb3-dp-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock
- - description: Phy config clock
- - description: 19.2 MHz ref clk
- - description: Phy common block aux clock
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: com_aux
-
- - if:
- properties:
- compatible:
- enum:
- - qcom,sc8180x-qmp-usb3-dp-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock
- - description: 19.2 MHz ref clk
- - description: Phy common block aux clock
- clock-names:
- items:
- - const: aux
- - const: ref
- - const: com_aux
-
- - if:
- properties:
- compatible:
- enum:
- - qcom,sm8250-qmp-usb3-dp-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock
- - description: Board XO source
- - description: Phy common block aux clock
- clock-names:
- items:
- - const: aux
- - const: ref_clk_src
- - const: com_aux
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sdm845.h>
- usb_1_qmpphy: phy-wrapper@88e9000 {
- compatible = "qcom,sdm845-qmp-usb3-dp-phy";
- reg = <0x088e9000 0x18c>,
- <0x088e8000 0x10>,
- <0x088ea000 0x40>;
- reg-names = "usb", "dp_com", "dp";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x088e9000 0x2000>;
-
- clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
- <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
- <&gcc GCC_USB3_PRIM_CLKREF_CLK>,
- <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
- clock-names = "aux", "cfg_ahb", "ref", "com_aux";
-
- resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
- <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
- reset-names = "phy", "common";
-
- vdda-phy-supply = <&vdda_usb2_ss_1p2>;
- vdda-pll-supply = <&vdda_usb2_ss_core>;
-
- orientation-switch;
-
- usb3-phy@200 {
- reg = <0x200 0x128>,
- <0x400 0x200>,
- <0xc00 0x218>,
- <0x600 0x128>,
- <0x800 0x200>,
- <0xa00 0x100>;
- #clock-cells = <0>;
- #phy-cells = <0>;
- clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
- clock-output-names = "usb3_phy_pipe_clk_src";
- };
-
- dp-phy@88ea200 {
- reg = <0xa200 0x200>,
- <0xa400 0x200>,
- <0xaa00 0x200>,
- <0xa600 0x200>,
- <0xa800 0x200>;
- #clock-cells = <1>;
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index a0407fc..2c3d655 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -16,11 +16,24 @@
properties:
compatible:
enum:
+ - qcom,sa8775p-qmp-gen4x2-pcie-phy
+ - qcom,sa8775p-qmp-gen4x4-pcie-phy
+ - qcom,sc8180x-qmp-pcie-phy
- qcom,sc8280xp-qmp-gen3x1-pcie-phy
- qcom,sc8280xp-qmp-gen3x2-pcie-phy
- qcom,sc8280xp-qmp-gen3x4-pcie-phy
+ - qcom,sdm845-qhp-pcie-phy
+ - qcom,sdm845-qmp-pcie-phy
+ - qcom,sdx55-qmp-pcie-phy
- qcom,sdx65-qmp-gen4x2-pcie-phy
+ - qcom,sm8150-qmp-gen3x1-pcie-phy
+ - qcom,sm8150-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-gen3x1-pcie-phy
+ - qcom,sm8250-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-modem-pcie-phy
- qcom,sm8350-qmp-gen3x1-pcie-phy
+ - qcom,sm8450-qmp-gen3x1-pcie-phy
+ - qcom,sm8450-qmp-gen4x2-pcie-phy
- qcom,sm8550-qmp-gen3x2-pcie-phy
- qcom,sm8550-qmp-gen4x2-pcie-phy
@@ -30,7 +43,7 @@
clocks:
minItems: 5
- maxItems: 6
+ maxItems: 7
clock-names:
minItems: 5
@@ -38,9 +51,10 @@
- const: aux
- const: cfg_ahb
- const: ref
- - const: rchng
+ - enum: [rchng, refgen]
- const: pipe
- const: pipediv2
+ - const: phy_aux
power-domains:
maxItems: 1
@@ -84,7 +98,6 @@
- reg
- clocks
- clock-names
- - power-domains
- resets
- reset-names
- vdda-phy-supply
@@ -120,7 +133,18 @@
compatible:
contains:
enum:
+ - qcom,sc8180x-qmp-pcie-phy
+ - qcom,sdm845-qhp-pcie-phy
+ - qcom,sdm845-qmp-pcie-phy
+ - qcom,sdx55-qmp-pcie-phy
+ - qcom,sm8150-qmp-gen3x1-pcie-phy
+ - qcom,sm8150-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-gen3x1-pcie-phy
+ - qcom,sm8250-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-modem-pcie-phy
- qcom,sm8350-qmp-gen3x1-pcie-phy
+ - qcom,sm8450-qmp-gen3x1-pcie-phy
+ - qcom,sm8450-qmp-gen3x2-pcie-phy
- qcom,sm8550-qmp-gen3x2-pcie-phy
- qcom,sm8550-qmp-gen4x2-pcie-phy
then:
@@ -129,7 +153,16 @@
maxItems: 5
clock-names:
maxItems: 5
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-qmp-gen3x1-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x2-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+ then:
properties:
clocks:
minItems: 6
@@ -141,6 +174,20 @@
compatible:
contains:
enum:
+ - qcom,sa8775p-qmp-gen4x2-pcie-phy
+ - qcom,sa8775p-qmp-gen4x4-pcie-phy
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ clock-names:
+ minItems: 7
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,sm8550-qmp-gen4x2-pcie-phy
then:
properties:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index a1897a7..d981d77 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -16,21 +16,31 @@
properties:
compatible:
enum:
+ - qcom,msm8996-qmp-ufs-phy
+ - qcom,msm8998-qmp-ufs-phy
- qcom,sa8775p-qmp-ufs-phy
+ - qcom,sc8180x-qmp-ufs-phy
- qcom,sc8280xp-qmp-ufs-phy
+ - qcom,sdm845-qmp-ufs-phy
+ - qcom,sm6115-qmp-ufs-phy
- qcom,sm6125-qmp-ufs-phy
+ - qcom,sm6350-qmp-ufs-phy
- qcom,sm7150-qmp-ufs-phy
+ - qcom,sm8150-qmp-ufs-phy
+ - qcom,sm8250-qmp-ufs-phy
+ - qcom,sm8350-qmp-ufs-phy
+ - qcom,sm8450-qmp-ufs-phy
- qcom,sm8550-qmp-ufs-phy
reg:
maxItems: 1
clocks:
- minItems: 2
+ minItems: 1
maxItems: 3
clock-names:
- minItems: 2
+ minItems: 1
items:
- const: ref
- const: ref_aux
@@ -75,19 +85,51 @@
contains:
enum:
- qcom,sa8775p-qmp-ufs-phy
+ - qcom,sm8450-qmp-ufs-phy
then:
properties:
clocks:
minItems: 3
clock-names:
minItems: 3
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-qmp-ufs-phy
+ - qcom,sc8180x-qmp-ufs-phy
+ - qcom,sc8280xp-qmp-ufs-phy
+ - qcom,sdm845-qmp-ufs-phy
+ - qcom,sm6115-qmp-ufs-phy
+ - qcom,sm6125-qmp-ufs-phy
+ - qcom,sm6350-qmp-ufs-phy
+ - qcom,sm7150-qmp-ufs-phy
+ - qcom,sm8150-qmp-ufs-phy
+ - qcom,sm8250-qmp-ufs-phy
+ - qcom,sm8350-qmp-ufs-phy
+ - qcom,sm8550-qmp-ufs-phy
+ then:
properties:
clocks:
maxItems: 2
clock-names:
maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-qmp-ufs-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index ef1c02d..9af203d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -16,8 +16,14 @@
properties:
compatible:
enum:
+ - qcom,sc7180-qmp-usb3-dp-phy
+ - qcom,sc7280-qmp-usb3-dp-phy
+ - qcom,sc8180x-qmp-usb3-dp-phy
- qcom,sc8280xp-qmp-usb43dp-phy
+ - qcom,sdm845-qmp-usb3-dp-phy
- qcom,sm6350-qmp-usb3-dp-phy
+ - qcom,sm8150-qmp-usb3-dp-phy
+ - qcom,sm8250-qmp-usb3-dp-phy
- qcom,sm8350-qmp-usb3-dp-phy
- qcom,sm8450-qmp-usb3-dp-phy
- qcom,sm8550-qmp-usb3-dp-phy
@@ -26,14 +32,17 @@
maxItems: 1
clocks:
- maxItems: 4
+ minItems: 4
+ maxItems: 5
clock-names:
+ minItems: 4
items:
- const: aux
- const: ref
- const: com_aux
- const: usb3_pipe
+ - const: cfg_ahb
power-domains:
maxItems: 1
@@ -85,7 +94,6 @@
- reg
- clocks
- clock-names
- - power-domains
- resets
- reset-names
- vdda-phy-supply
@@ -93,6 +101,40 @@
- "#clock-cells"
- "#phy-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-qmp-usb3-dp-phy
+ - qcom,sdm845-qmp-usb3-dp-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ maxItems: 5
+ else:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ maxItems: 4
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-qmp-usb43dp-phy
+ - qcom,sm6350-qmp-usb3-dp-phy
+ - qcom,sm8550-qmp-usb3-dp-phy
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
index 083fda5..029569d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
@@ -15,7 +15,12 @@
properties:
compatible:
- const: qcom,pm8550b-eusb2-repeater
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm7550ba-eusb2-repeater
+ - const: qcom,pm8550b-eusb2-repeater
+ - const: qcom,pm8550b-eusb2-repeater
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml b/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml
new file mode 100644
index 0000000..9911ada
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/realtek,usb2phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC SoCs USB 2.0 PHY
+
+maintainers:
+ - Stanley Chang <stanley_chang@realtek.com>
+
+description: |
+ Realtek USB 2.0 PHY support the digital home center (DHC) RTD series SoCs.
+ The USB 2.0 PHY driver is designed to support the XHCI controller. The SoCs
+ support multiple XHCI controllers. One PHY device node maps to one XHCI
+ controller.
+
+ RTD1295/RTD1619 SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some
+ controllers.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1395 SoCs USB
+ The USB architecture includes two XHCI controllers.
+ The controller#0 has one USB 2.0 PHY. The controller#1 includes two USB 2.0
+ PHY.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ |- phy#1
+
+ RTD1319/RTD1619b SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1319d SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+
+ RTD1312c/RTD1315e SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1295-usb2phy
+ - realtek,rtd1312c-usb2phy
+ - realtek,rtd1315e-usb2phy
+ - realtek,rtd1319-usb2phy
+ - realtek,rtd1319d-usb2phy
+ - realtek,rtd1395-usb2phy
+ - realtek,rtd1395-usb2phy-2port
+ - realtek,rtd1619-usb2phy
+ - realtek,rtd1619b-usb2phy
+
+ reg:
+ items:
+ - description: PHY data registers
+ - description: PHY control registers
+
+ "#phy-cells":
+ const: 0
+
+ nvmem-cells:
+ maxItems: 2
+ description:
+ Phandles to nvmem cell that contains the trimming data.
+ If unspecified, default value is used.
+
+ nvmem-cell-names:
+ items:
+ - const: usb-dc-cal
+ - const: usb-dc-dis
+ description:
+ The following names, which correspond to each nvmem-cells.
+ usb-dc-cal is the driving level for each phy specified via efuse.
+ usb-dc-dis is the disconnection level for each phy specified via efuse.
+
+ realtek,inverse-hstx-sync-clock:
+ description:
+ For one of the phys of RTD1619b SoC, the synchronous clock of the
+ high-speed tx must be inverted.
+ type: boolean
+
+ realtek,driving-level:
+ description:
+ Control the magnitude of High speed Dp/Dm output swing (mV).
+ For a different board or port, the original magnitude maybe not meet
+ the specification. In this situation we can adjust the value to meet
+ the specification.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 8
+ minimum: 0
+ maximum: 31
+
+ realtek,driving-level-compensate:
+ description:
+ For RTD1315e SoC, the driving level can be adjusted by reading the
+ efuse table. This property provides drive compensation.
+ If the magnitude of High speed Dp/Dm output swing still not meet the
+ specification, then we can set this value to meet the specification.
+ $ref: /schemas/types.yaml#/definitions/int32
+ default: 0
+ minimum: -8
+ maximum: 8
+
+ realtek,disconnection-compensate:
+ description:
+ This adjusts the disconnection level compensation for the different
+ boards with different disconnection level.
+ $ref: /schemas/types.yaml#/definitions/int32
+ default: 0
+ minimum: -8
+ maximum: 8
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - realtek,rtd1619b-usb2phy
+ then:
+ properties:
+ realtek,inverse-hstx-sync-clock: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - realtek,rtd1315e-usb2phy
+ then:
+ properties:
+ realtek,driving-level-compensate: false
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@13214 {
+ compatible = "realtek,rtd1619b-usb2phy";
+ reg = <0x13214 0x4>, <0x28280 0x4>;
+ #phy-cells = <0>;
+ nvmem-cells = <&otp_usb_port0_dc_cal>, <&otp_usb_port0_dc_dis>;
+ nvmem-cell-names = "usb-dc-cal", "usb-dc-dis";
+
+ realtek,inverse-hstx-sync-clock;
+ realtek,driving-level = <0xa>;
+ realtek,disconnection-compensate = <(-1)>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml b/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml
new file mode 100644
index 0000000..dfe2bb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/realtek,usb3phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC SoCs USB 3.0 PHY
+
+maintainers:
+ - Stanley Chang <stanley_chang@realtek.com>
+
+description: |
+ Realtek USB 3.0 PHY support the digital home center (DHC) RTD series SoCs.
+ The USB 3.0 PHY driver is designed to support the XHCI controller. The SoCs
+ support multiple XHCI controllers. One PHY device node maps to one XHCI
+ controller.
+
+ RTD1295/RTD1619 SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some
+ controllers.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1319/RTD1619b SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1319d SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1295-usb3phy
+ - realtek,rtd1319-usb3phy
+ - realtek,rtd1319d-usb3phy
+ - realtek,rtd1619-usb3phy
+ - realtek,rtd1619b-usb3phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ nvmem-cells:
+ maxItems: 1
+ description: A phandle to the tx lfps swing trim data provided by
+ a nvmem device, if unspecified, default values shall be used.
+
+ nvmem-cell-names:
+ items:
+ - const: usb_u3_tx_lfps_swing_trim
+
+ realtek,amplitude-control-coarse-tuning:
+ description:
+ This adjusts the signal amplitude for normal operation and beacon LFPS.
+ This value is a parameter for coarse tuning.
+ For different boards, if the default value is inappropriate, this
+ property can be assigned to adjust.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 255
+ minimum: 0
+ maximum: 255
+
+ realtek,amplitude-control-fine-tuning:
+ description:
+ This adjusts the signal amplitude for normal operation and beacon LFPS.
+ This value is used for fine-tuning parameters.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 65535
+ minimum: 0
+ maximum: 65535
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@13e10 {
+ compatible = "realtek,rtd1319d-usb3phy";
+ reg = <0x13e10 0x4>;
+ #phy-cells = <0>;
+
+ nvmem-cells = <&otp_usb_u3_tx_lfps_swing_trim>;
+ nvmem-cell-names = "usb_u3_tx_lfps_swing_trim";
+
+ realtek,amplitude-control-coarse-tuning = <0x77>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
index 0d6b8c2..5254413 100644
--- a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
@@ -20,6 +20,7 @@
- rockchip,rk3366-usb2phy
- rockchip,rk3399-usb2phy
- rockchip,rk3568-usb2phy
+ - rockchip,rk3588-usb2phy
- rockchip,rv1108-usb2phy
reg:
@@ -56,6 +57,14 @@
description: Muxed interrupt for both ports
maxItems: 1
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: apb
+
rockchip,usbgrf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -120,15 +129,21 @@
- reg
- clock-output-names
- "#clock-cells"
- - host-port
- - otg-port
+
+anyOf:
+ - required:
+ - otg-port
+ - required:
+ - host-port
allOf:
- if:
properties:
compatible:
contains:
- const: rockchip,rk3568-usb2phy
+ enum:
+ - rockchip,rk3568-usb2phy
+ - rockchip,rk3588-usb2phy
then:
properties:
diff --git a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
index 9f2d8d2..c4fbffc 100644
--- a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
@@ -13,19 +13,18 @@
compatible:
enum:
- rockchip,rk3568-pcie3-phy
+ - rockchip,rk3588-pcie3-phy
reg:
maxItems: 1
clocks:
- minItems: 3
+ minItems: 1
maxItems: 3
clock-names:
- items:
- - const: refclk_m
- - const: refclk_n
- - const: pclk
+ minItems: 1
+ maxItems: 3
data-lanes:
description: which lanes (by position) should be mapped to which
@@ -61,6 +60,30 @@
- rockchip,phy-grf
- "#phy-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - rockchip,rk3588-pcie3-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: pclk
+ else:
+ properties:
+ clocks:
+ minItems: 3
+
+ clock-names:
+ items:
+ - const: refclk_m
+ - const: refclk_n
+ - const: pclk
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
index 5c35e5c..46e64fa 100644
--- a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
@@ -19,6 +19,7 @@
- rockchip,rk3128-dsi-dphy
- rockchip,rk3368-dsi-dphy
- rockchip,rk3568-dsi-dphy
+ - rockchip,rv1126-dsi-dphy
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index 0e6505e..5ac994b 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -10,7 +10,7 @@
- Heiko Stuebner <heiko@sntech.de>
description: |
- The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP wich
+ The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP which
connects to the ISP1 (Image Signal Processing unit v1.0) for CSI cameras.
properties:
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
index 5ba55f9..452e584 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
@@ -29,6 +29,7 @@
- samsung,exynos5420-usbdrd-phy
- samsung,exynos5433-usbdrd-phy
- samsung,exynos7-usbdrd-phy
+ - samsung,exynos850-usbdrd-phy
clocks:
minItems: 2
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml
new file mode 100644
index 0000000..7224cde
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/starfive,jh7110-dphy-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive SoC JH7110 MIPI D-PHY Rx Controller
+
+maintainers:
+ - Jack Zhu <jack.zhu@starfivetech.com>
+ - Changhuang Liang <changhuang.liang@starfivetech.com>
+
+description:
+ StarFive SoCs contain a MIPI CSI D-PHY based on M31 IP, used to
+ transfer CSI camera data.
+
+properties:
+ compatible:
+ const: starfive,jh7110-dphy-rx
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: config clock
+ - description: reference clock
+ - description: escape mode transmit clock
+
+ clock-names:
+ items:
+ - const: cfg
+ - const: ref
+ - const: tx
+
+ resets:
+ items:
+ - description: DPHY_HW reset
+ - description: DPHY_B09_ALWAYS_ON reset
+
+ power-domains:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@19820000 {
+ compatible = "starfive,jh7110-dphy-rx";
+ reg = <0x19820000 0x10000>;
+ clocks = <&ispcrg 3>,
+ <&ispcrg 4>,
+ <&ispcrg 5>;
+ clock-names = "cfg", "ref", "tx";
+ resets = <&ispcrg 2>,
+ <&ispcrg 3>;
+ power-domains = <&aon_syscon 1>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml
new file mode 100644
index 0000000..2e83a61
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.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/starfive,jh7110-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 PCIe 2.0 PHY
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ starfive,sys-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller sys_syscon node.
+ - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY.
+ description:
+ The phandle to System Register Controller syscon node and the PHY connect offset
+ of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB3 controller.
+
+ starfive,stg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller stg_syscon node.
+ - description: PHY mode offset of STG_SYSCONSAIF__SYSCFG register.
+ - description: PHY enable for USB offset of STG_SYSCONSAIF__SYSCFG register.
+ description:
+ The phandle to System Register Controller syscon node and the offset
+ of STG_SYSCONSAIF__SYSCFG register for PCIe PHY. Total 2 regsisters offset.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@10210000 {
+ compatible = "starfive,jh7110-pcie-phy";
+ reg = <0x10210000 0x10000>;
+ #phy-cells = <0>;
+ starfive,sys-syscon = <&sys_syscon 0x18>;
+ starfive,stg-syscon = <&stg_syscon 0x148 0x1f4>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
new file mode 100644
index 0000000..269e9f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/starfive,jh7110-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 USB 2.0 PHY
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-usb-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: PHY 125m
+ - description: app 125m
+
+ clock-names:
+ items:
+ - const: 125m
+ - const: app_125m
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@10200000 {
+ compatible = "starfive,jh7110-usb-phy";
+ reg = <0x10200000 0x10000>;
+ clocks = <&syscrg 95>,
+ <&stgcrg 6>;
+ clock-names = "125m", "app_125m";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 9ea30ea..3f16ff1 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -59,7 +59,7 @@
description:
GPIO to signal Type-C cable orientation for lane swap.
If GPIO is active, lane 0 and lane 1 of SERDES will be swapped to
- achieve the funtionality of an external type-C plug flip mux.
+ achieve the functionality of an external type-C plug flip mux.
typec-dir-debounce-ms:
minimum: 100
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 60c9d0a..7c7936b 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -62,7 +62,7 @@
- ctrl-module : phandle of the control module used by PHY driver to power on
the PHY.
-Recommended properies:
+Recommended properties:
- syscon-phy-power : phandle/offset pair. Phandle to the system control
module and the register offset to power on/off the PHY.
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
index 467016c..4502405 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
@@ -97,7 +97,7 @@
# It's pretty scary, but the basic idea is that:
# - One node name can start with either s- or r- for PRCM nodes,
# - Then, the name itself can be any repetition of <string>- (to
- # accomodate with nodes like uart4-rts-cts-pins), where each
+ # accommodate with nodes like uart4-rts-cts-pins), where each
# string can be either starting with 'p' but in a string longer
# than 3, or something that doesn't start with 'p',
# - Then, the bank name is optional and will be between pa and pg,
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml
index 99080c9..4e7a456 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml
@@ -15,6 +15,7 @@
properties:
compatible:
enum:
+ - amlogic,c3-periphs-pinctrl
- amlogic,meson-a1-periphs-pinctrl
- amlogic,meson-s4-periphs-pinctrl
@@ -36,6 +37,10 @@
- const: mux
- const: gpio
+ gpio-line-names:
+ minItems: 62 # A1
+ maxItems: 82 # S4
+
unevaluatedProperties:
type: object
$ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml
index a7b29ef..e707c22 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml
@@ -41,6 +41,13 @@
gpio-ranges:
maxItems: 1
+ patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
required:
- reg
- reg-names
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml
index 7c9c94ec..0942ea6 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml
@@ -36,6 +36,9 @@
- const: ds
- const: gpio
+ gpio-line-names:
+ maxItems: 15
+
unevaluatedProperties:
type: object
$ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml
index 4bcb8b6..e3c8bde 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml
@@ -38,6 +38,9 @@
- const: mux
- const: ds
+ gpio-line-names:
+ maxItems: 85
+
unevaluatedProperties:
type: object
$ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml
index 32d99c9..c1b0314 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml
@@ -44,6 +44,10 @@
- const: pull
- const: gpio
+ gpio-line-names:
+ minItems: 11 # GXL
+ maxItems: 16 # Meson8
+
unevaluatedProperties:
type: object
$ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml
index d044105..4ec85b8 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml
@@ -45,6 +45,10 @@
- const: pull-enable
- const: gpio
+ gpio-line-names:
+ minItems: 86 # AXG
+ maxItems: 120 # Meson8
+
unevaluatedProperties:
type: object
$ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
index bef85c2..37c0a74 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -25,30 +25,32 @@
reg:
maxItems: 2
-patternProperties:
- '^.*$':
- if:
- type: object
- then:
- patternProperties:
- "^function|groups$":
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
- ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT,
- EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0,
- GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4,
- I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, LPCPME, LPCRST, LPCSMI, MAC1LINK,
- MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2,
- NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4,
- NDTS4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0,
- PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1,
- RMII2, ROM16, ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3,
- RXD4, SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD,
- SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO,
- SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, SPI1PASSTHRU,
- SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2,
- TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM,
- VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2]
+additionalProperties:
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins: true
+ bias-disable: true
+
+ patternProperties:
+ "^function|groups$":
+ enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
+ ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT,
+ EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0,
+ GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4,
+ I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, LPCPME, LPCRST, LPCSMI, MAC1LINK,
+ MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2,
+ NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4,
+ NDTS4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0,
+ PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1,
+ RMII2, ROM16, ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3,
+ RXD4, SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD,
+ SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO,
+ SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, SPI1PASSTHRU,
+ SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2,
+ TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM,
+ VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2]
allOf:
- $ref: pinctrl.yaml#
@@ -56,8 +58,6 @@
required:
- compatible
-additionalProperties: false
-
examples:
- |
syscon: scu@1e6e2000 {
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
index 14c391f..863da5d 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
@@ -37,32 +37,34 @@
0: compatible with "aspeed,ast2500-gfx", "syscon"
1: compatible with "aspeed,ast2500-lhc", "syscon"
-patternProperties:
- '^.*$':
- if:
- type: object
- then:
- patternProperties:
- "^function|groups$":
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
- ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT,
- ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2,
- GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, I2C5,
- I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, LAD2, LAD3, LCLK, LFRAME, LPCHC,
- LPCPD, LPCPLUS, LPCPME, LPCRST, LPCSMI, LSIRQ, MAC1LINK, MAC2LINK,
- MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4,
- NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2,
- NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0,
- PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1,
- RMII2, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13,
- SALT14, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1,
- SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO,
- SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, SPI1DEBUG,
- SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, SPI2MOSI, TIMER3,
- TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, TXD3, TXD4, UART6,
- USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS,
- VGAVS, VPI24, VPO, WDTRST1, WDTRST2]
+additionalProperties:
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins: true
+ bias-disable: true
+
+ patternProperties:
+ "^function|groups$":
+ enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
+ ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT,
+ ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2,
+ GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, I2C5,
+ I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, LAD2, LAD3, LCLK, LFRAME, LPCHC,
+ LPCPD, LPCPLUS, LPCPME, LPCRST, LPCSMI, LSIRQ, MAC1LINK, MAC2LINK,
+ MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4,
+ NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2,
+ NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0,
+ PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1,
+ RMII2, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13,
+ SALT14, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1,
+ SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO,
+ SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, SPI1DEBUG,
+ SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, SPI2MOSI, TIMER3,
+ TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, TXD3, TXD4, UART6,
+ USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS,
+ VGAVS, VPI24, VPO, WDTRST1, WDTRST2]
allOf:
- $ref: pinctrl.yaml#
@@ -71,8 +73,6 @@
- compatible
- aspeed,external-nodes
-additionalProperties: false
-
examples:
- |
#include <dt-bindings/clock/aspeed-clock.h>
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
index 859a188..612464a 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
@@ -23,65 +23,65 @@
compatible:
const: aspeed,ast2600-pinctrl
-patternProperties:
- '^.*$':
- if:
- type: object
- then:
- properties:
- function:
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2,
- ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT,
- FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3,
- GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5,
- GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16,
- I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5,
- I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ,
- MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4,
- NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2,
- NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4,
- NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11,
- PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8,
- PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4,
- RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14,
- SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8,
- SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO,
- SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2,
- SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14,
- TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0,
- THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12,
- UART13, UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP,
- USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4 ]
+additionalProperties:
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
- groups:
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2,
- ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4,
- EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP,
- GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1,
- GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10,
- I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5,
- I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ,
- LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3,
- MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4,
- NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2,
- NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4,
- OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0,
- PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2,
- PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1,
- QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4,
- RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1,
- SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0,
- SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6,
- SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2,
- SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1,
- SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11,
- TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6,
- TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3,
- TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6,
- UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2,
- WDTRST3, WDTRST4]
+ properties:
+ function:
+ enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2,
+ ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT,
+ FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3,
+ GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5,
+ GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16,
+ I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5,
+ I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ,
+ MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4,
+ NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2,
+ NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4,
+ NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11,
+ PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8,
+ PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4,
+ RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14,
+ SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8,
+ SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO,
+ SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2,
+ SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14,
+ TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0,
+ THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12,
+ UART13, UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP,
+ USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4 ]
+
+ groups:
+ enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2,
+ ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4,
+ EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP,
+ GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1,
+ GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10,
+ I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5,
+ I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ,
+ LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3,
+ MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4,
+ NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2,
+ NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4,
+ OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0,
+ PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2,
+ PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1,
+ QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4,
+ RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1,
+ SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0,
+ SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6,
+ SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2,
+ SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1,
+ SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11,
+ TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6,
+ TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3,
+ TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6,
+ UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2,
+ WDTRST3, WDTRST4]
+
+ pins: true
+ bias-disable: true
allOf:
- $ref: pinctrl.yaml#
@@ -89,8 +89,6 @@
required:
- compatible
-additionalProperties: false
-
examples:
- |
syscon: scu@1e6e2000 {
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
deleted file mode 100644
index e047a19..0000000
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
+++ /dev/null
@@ -1,461 +0,0 @@
-Broadcom BCM281xx Pin Controller
-
-This is a pin controller for the Broadcom BCM281xx SoC family, which includes
-BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs.
-
-=== Pin Controller Node ===
-
-Required Properties:
-
-- compatible: Must be "brcm,bcm11351-pinctrl"
-- reg: Base address of the PAD Controller register block and the size
- of the block.
-
-For example, the following is the bare minimum node:
-
- pinctrl@35004800 {
- compatible = "brcm,bcm11351-pinctrl";
- reg = <0x35004800 0x430>;
- };
-
-As a pin controller device, in addition to the required properties, this node
-should also contain the pin configuration nodes that client devices reference,
-if any.
-
-=== Pin Configuration Node ===
-
-Each pin configuration node is a sub-node of the pin controller node and is a
-container of an arbitrary number of subnodes, called pin group nodes in this
-document.
-
-Please refer to the pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the definition of a
-"pin configuration node".
-
-=== Pin Group Node ===
-
-A pin group node specifies the desired pin mux and/or pin configuration for an
-arbitrary number of pins. The name of the pin group node is optional and not
-used.
-
-A pin group node only affects the properties specified in the node, and has no
-effect on any properties that are omitted.
-
-The pin group node accepts a subset of the generic pin config properties. For
-details generic pin config properties, please refer to pinctrl-bindings.txt
-and <include/linux/pinctrl/pinconfig-generic.h>.
-
-Each pin controlled by this pin controller belong to one of three types:
-Standard, I2C, and HDMI. Each type accepts a different set of pin config
-properties. A list of pins and their types is provided below.
-
-Required Properties (applicable to all pins):
-
-- pins: Multiple strings. Specifies the name(s) of one or more pins to
- be configured by this node.
-
-Optional Properties (for standard pins):
-
-- function: String. Specifies the pin mux selection. Values
- must be one of: "alt1", "alt2", "alt3", "alt4"
-- input-schmitt-enable: No arguments. Enable schmitt-trigger mode.
-- input-schmitt-disable: No arguments. Disable schmitt-trigger mode.
-- bias-pull-up: No arguments. Pull up on pin.
-- bias-pull-down: No arguments. Pull down on pin.
-- bias-disable: No arguments. Disable pin bias.
-- slew-rate: Integer. Meaning depends on configured pin mux:
- *_SCL or *_SDA:
- 0: Standard(100kbps)& Fast(400kbps) mode
- 1: Highspeed (3.4Mbps) mode
- IC_DM or IC_DP:
- 0: normal slew rate
- 1: fast slew rate
- Otherwise:
- 0: fast slew rate
- 1: normal slew rate
-- input-enable: No arguments. Enable input (does not affect
- output.)
-- input-disable: No arguments. Disable input (does not affect
- output.)
-- drive-strength: Integer. Drive strength in mA. Valid values are
- 2, 4, 6, 8, 10, 12, 14, 16 mA.
-
-Optional Properties (for I2C pins):
-
-- function: String. Specifies the pin mux selection. Values
- must be one of: "alt1", "alt2", "alt3", "alt4"
-- bias-pull-up: Integer. Pull up strength in Ohm. There are 3
- pull-up resistors (1.2k, 1.8k, 2.7k) available
- in parallel for I2C pins, so the valid values
- are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm.
-- bias-disable: No arguments. Disable pin bias.
-- slew-rate: Integer. Meaning depends on configured pin mux:
- *_SCL or *_SDA:
- 0: Standard(100kbps)& Fast(400kbps) mode
- 1: Highspeed (3.4Mbps) mode
- IC_DM or IC_DP:
- 0: normal slew rate
- 1: fast slew rate
- Otherwise:
- 0: fast slew rate
- 1: normal slew rate
-- input-enable: No arguments. Enable input (does not affect
- output.)
-- input-disable: No arguments. Disable input (does not affect
- output.)
-
-Optional Properties (for HDMI pins):
-
-- function: String. Specifies the pin mux selection. Values
- must be one of: "alt1", "alt2", "alt3", "alt4"
-- slew-rate: Integer. Controls slew rate.
- 0: Standard(100kbps)& Fast(400kbps) mode
- 1: Highspeed (3.4Mbps) mode
-- input-enable: No arguments. Enable input (does not affect
- output.)
-- input-disable: No arguments. Disable input (does not affect
- output.)
-
-Example:
-// pin controller node
-pinctrl@35004800 {
- compatible = "brcm,bcm11351-pinctrl";
- reg = <0x35004800 0x430>;
-
- // pin configuration node
- dev_a_default: dev_a_active {
- //group node defining 1 standard pin
- grp_1 {
- pins = "std_pin1";
- function = "alt1";
- input-schmitt-enable;
- bias-disable;
- slew-rate = <1>;
- drive-strength = <4>;
- };
-
- // group node defining 2 I2C pins
- grp_2 {
- pins = "i2c_pin1", "i2c_pin2";
- function = "alt2";
- bias-pull-up = <720>;
- input-enable;
- };
-
- // group node defining 2 HDMI pins
- grp_3 {
- pins = "hdmi_pin1", "hdmi_pin2";
- function = "alt3";
- slew-rate = <1>;
- };
-
- // other pin group nodes
- ...
- };
-
- // other pin configuration nodes
- ...
-};
-
-In the example above, "dev_a_active" is a pin configuration node with a number
-of sub-nodes. In the pin group node "grp_1", one pin, "std_pin1", is defined in
-the "pins" property. Thus, the remaining properties in the "grp_1" node applies
-only to this pin, including the following settings:
- - setting pinmux to "alt1"
- - enabling schmitt-trigger (hystersis) mode
- - disabling pin bias
- - setting the slew-rate to 1
- - setting the drive strength to 4 mA
-Note that neither "input-enable" nor "input-disable" was specified - the pinctrl
-subsystem will therefore leave this property unchanged from whatever state it
-was in before applying these changes.
-
-The "pins" property in the pin group node "grp_2" specifies two pins -
-"i2c_pin1" and "i2c_pin2"; the remaining properties in this pin group node,
-therefore, applies to both of these pins. The properties include:
- - setting pinmux to "alt2"
- - setting pull-up resistance to 720 Ohm (ie. enabling 1.2k and 1.8k resistors
- in parallel)
- - enabling both pins' input
-"slew-rate" is not specified in this pin group node, so the slew-rate for these
-pins are left as-is.
-
-Finally, "grp_3" defines two HDMI pins. The following properties are applied to
-both pins:
- - setting pinmux to "alt3"
- - setting slew-rate to 1; for HDMI pins, this corresponds to the 3.4 Mbps
- Highspeed mode
-The input is neither enabled or disabled, and is left untouched.
-
-=== Pin Names and Type ===
-
-The following are valid pin names and their pin types:
-
- "adcsync", Standard
- "bat_rm", Standard
- "bsc1_scl", I2C
- "bsc1_sda", I2C
- "bsc2_scl", I2C
- "bsc2_sda", I2C
- "classgpwr", Standard
- "clk_cx8", Standard
- "clkout_0", Standard
- "clkout_1", Standard
- "clkout_2", Standard
- "clkout_3", Standard
- "clkreq_in_0", Standard
- "clkreq_in_1", Standard
- "cws_sys_req1", Standard
- "cws_sys_req2", Standard
- "cws_sys_req3", Standard
- "digmic1_clk", Standard
- "digmic1_dq", Standard
- "digmic2_clk", Standard
- "digmic2_dq", Standard
- "gpen13", Standard
- "gpen14", Standard
- "gpen15", Standard
- "gpio00", Standard
- "gpio01", Standard
- "gpio02", Standard
- "gpio03", Standard
- "gpio04", Standard
- "gpio05", Standard
- "gpio06", Standard
- "gpio07", Standard
- "gpio08", Standard
- "gpio09", Standard
- "gpio10", Standard
- "gpio11", Standard
- "gpio12", Standard
- "gpio13", Standard
- "gpio14", Standard
- "gps_pablank", Standard
- "gps_tmark", Standard
- "hdmi_scl", HDMI
- "hdmi_sda", HDMI
- "ic_dm", Standard
- "ic_dp", Standard
- "kp_col_ip_0", Standard
- "kp_col_ip_1", Standard
- "kp_col_ip_2", Standard
- "kp_col_ip_3", Standard
- "kp_row_op_0", Standard
- "kp_row_op_1", Standard
- "kp_row_op_2", Standard
- "kp_row_op_3", Standard
- "lcd_b_0", Standard
- "lcd_b_1", Standard
- "lcd_b_2", Standard
- "lcd_b_3", Standard
- "lcd_b_4", Standard
- "lcd_b_5", Standard
- "lcd_b_6", Standard
- "lcd_b_7", Standard
- "lcd_g_0", Standard
- "lcd_g_1", Standard
- "lcd_g_2", Standard
- "lcd_g_3", Standard
- "lcd_g_4", Standard
- "lcd_g_5", Standard
- "lcd_g_6", Standard
- "lcd_g_7", Standard
- "lcd_hsync", Standard
- "lcd_oe", Standard
- "lcd_pclk", Standard
- "lcd_r_0", Standard
- "lcd_r_1", Standard
- "lcd_r_2", Standard
- "lcd_r_3", Standard
- "lcd_r_4", Standard
- "lcd_r_5", Standard
- "lcd_r_6", Standard
- "lcd_r_7", Standard
- "lcd_vsync", Standard
- "mdmgpio0", Standard
- "mdmgpio1", Standard
- "mdmgpio2", Standard
- "mdmgpio3", Standard
- "mdmgpio4", Standard
- "mdmgpio5", Standard
- "mdmgpio6", Standard
- "mdmgpio7", Standard
- "mdmgpio8", Standard
- "mphi_data_0", Standard
- "mphi_data_1", Standard
- "mphi_data_2", Standard
- "mphi_data_3", Standard
- "mphi_data_4", Standard
- "mphi_data_5", Standard
- "mphi_data_6", Standard
- "mphi_data_7", Standard
- "mphi_data_8", Standard
- "mphi_data_9", Standard
- "mphi_data_10", Standard
- "mphi_data_11", Standard
- "mphi_data_12", Standard
- "mphi_data_13", Standard
- "mphi_data_14", Standard
- "mphi_data_15", Standard
- "mphi_ha0", Standard
- "mphi_hat0", Standard
- "mphi_hat1", Standard
- "mphi_hce0_n", Standard
- "mphi_hce1_n", Standard
- "mphi_hrd_n", Standard
- "mphi_hwr_n", Standard
- "mphi_run0", Standard
- "mphi_run1", Standard
- "mtx_scan_clk", Standard
- "mtx_scan_data", Standard
- "nand_ad_0", Standard
- "nand_ad_1", Standard
- "nand_ad_2", Standard
- "nand_ad_3", Standard
- "nand_ad_4", Standard
- "nand_ad_5", Standard
- "nand_ad_6", Standard
- "nand_ad_7", Standard
- "nand_ale", Standard
- "nand_cen_0", Standard
- "nand_cen_1", Standard
- "nand_cle", Standard
- "nand_oen", Standard
- "nand_rdy_0", Standard
- "nand_rdy_1", Standard
- "nand_wen", Standard
- "nand_wp", Standard
- "pc1", Standard
- "pc2", Standard
- "pmu_int", Standard
- "pmu_scl", I2C
- "pmu_sda", I2C
- "rfst2g_mtsloten3g", Standard
- "rgmii_0_rx_ctl", Standard
- "rgmii_0_rxc", Standard
- "rgmii_0_rxd_0", Standard
- "rgmii_0_rxd_1", Standard
- "rgmii_0_rxd_2", Standard
- "rgmii_0_rxd_3", Standard
- "rgmii_0_tx_ctl", Standard
- "rgmii_0_txc", Standard
- "rgmii_0_txd_0", Standard
- "rgmii_0_txd_1", Standard
- "rgmii_0_txd_2", Standard
- "rgmii_0_txd_3", Standard
- "rgmii_1_rx_ctl", Standard
- "rgmii_1_rxc", Standard
- "rgmii_1_rxd_0", Standard
- "rgmii_1_rxd_1", Standard
- "rgmii_1_rxd_2", Standard
- "rgmii_1_rxd_3", Standard
- "rgmii_1_tx_ctl", Standard
- "rgmii_1_txc", Standard
- "rgmii_1_txd_0", Standard
- "rgmii_1_txd_1", Standard
- "rgmii_1_txd_2", Standard
- "rgmii_1_txd_3", Standard
- "rgmii_gpio_0", Standard
- "rgmii_gpio_1", Standard
- "rgmii_gpio_2", Standard
- "rgmii_gpio_3", Standard
- "rtxdata2g_txdata3g1", Standard
- "rtxen2g_txdata3g2", Standard
- "rxdata3g0", Standard
- "rxdata3g1", Standard
- "rxdata3g2", Standard
- "sdio1_clk", Standard
- "sdio1_cmd", Standard
- "sdio1_data_0", Standard
- "sdio1_data_1", Standard
- "sdio1_data_2", Standard
- "sdio1_data_3", Standard
- "sdio4_clk", Standard
- "sdio4_cmd", Standard
- "sdio4_data_0", Standard
- "sdio4_data_1", Standard
- "sdio4_data_2", Standard
- "sdio4_data_3", Standard
- "sim_clk", Standard
- "sim_data", Standard
- "sim_det", Standard
- "sim_resetn", Standard
- "sim2_clk", Standard
- "sim2_data", Standard
- "sim2_det", Standard
- "sim2_resetn", Standard
- "sri_c", Standard
- "sri_d", Standard
- "sri_e", Standard
- "ssp_extclk", Standard
- "ssp0_clk", Standard
- "ssp0_fs", Standard
- "ssp0_rxd", Standard
- "ssp0_txd", Standard
- "ssp2_clk", Standard
- "ssp2_fs_0", Standard
- "ssp2_fs_1", Standard
- "ssp2_fs_2", Standard
- "ssp2_fs_3", Standard
- "ssp2_rxd_0", Standard
- "ssp2_rxd_1", Standard
- "ssp2_txd_0", Standard
- "ssp2_txd_1", Standard
- "ssp3_clk", Standard
- "ssp3_fs", Standard
- "ssp3_rxd", Standard
- "ssp3_txd", Standard
- "ssp4_clk", Standard
- "ssp4_fs", Standard
- "ssp4_rxd", Standard
- "ssp4_txd", Standard
- "ssp5_clk", Standard
- "ssp5_fs", Standard
- "ssp5_rxd", Standard
- "ssp5_txd", Standard
- "ssp6_clk", Standard
- "ssp6_fs", Standard
- "ssp6_rxd", Standard
- "ssp6_txd", Standard
- "stat_1", Standard
- "stat_2", Standard
- "sysclken", Standard
- "traceclk", Standard
- "tracedt00", Standard
- "tracedt01", Standard
- "tracedt02", Standard
- "tracedt03", Standard
- "tracedt04", Standard
- "tracedt05", Standard
- "tracedt06", Standard
- "tracedt07", Standard
- "tracedt08", Standard
- "tracedt09", Standard
- "tracedt10", Standard
- "tracedt11", Standard
- "tracedt12", Standard
- "tracedt13", Standard
- "tracedt14", Standard
- "tracedt15", Standard
- "txdata3g0", Standard
- "txpwrind", Standard
- "uartb1_ucts", Standard
- "uartb1_urts", Standard
- "uartb1_urxd", Standard
- "uartb1_utxd", Standard
- "uartb2_urxd", Standard
- "uartb2_utxd", Standard
- "uartb3_ucts", Standard
- "uartb3_urts", Standard
- "uartb3_urxd", Standard
- "uartb3_utxd", Standard
- "uartb4_ucts", Standard
- "uartb4_urts", Standard
- "uartb4_urxd", Standard
- "uartb4_utxd", Standard
- "vc_cam1_scl", I2C
- "vc_cam1_sda", I2C
- "vc_cam2_scl", I2C
- "vc_cam2_sda", I2C
- "vc_cam3_scl", I2C
- "vc_cam3_sda", I2C
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml
new file mode 100644
index 0000000..90c2752
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml
@@ -0,0 +1,259 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,bcm11351-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM281xx pin controller
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm11351-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '-grp[0-9]$':
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ Specifies the name(s) of one or more pins to be configured by
+ this node.
+ items:
+ enum: [ adcsync, bat_rm, bsc1_scl, bsc1_sda, bsc2_scl, bsc2_sda,
+ classgpwr, clk_cx8, clkout_0, clkout_1, clkout_2,
+ clkout_3, clkreq_in_0, clkreq_in_1, cws_sys_req1,
+ cws_sys_req2, cws_sys_req3, digmic1_clk, digmic1_dq,
+ digmic2_clk, digmic2_dq, gpen13, gpen14, gpen15, gpio00,
+ gpio01, gpio02, gpio03, gpio04, gpio05, gpio06, gpio07,
+ gpio08, gpio09, gpio10, gpio11, gpio12, gpio13, gpio14,
+ gps_pablank, gps_tmark, hdmi_scl, hdmi_sda, ic_dm, ic_dp,
+ kp_col_ip_0, kp_col_ip_1, kp_col_ip_2, kp_col_ip_3,
+ kp_row_op_0, kp_row_op_1, kp_row_op_2, kp_row_op_3,
+ lcd_b_0, lcd_b_1, lcd_b_2, lcd_b_3, lcd_b_4, lcd_b_5,
+ lcd_b_6, lcd_b_7, lcd_g_0, lcd_g_1, lcd_g_2, lcd_g_3,
+ lcd_g_4, lcd_g_5, lcd_g_6, lcd_g_7, lcd_hsync, lcd_oe,
+ lcd_pclk, lcd_r_0, lcd_r_1, lcd_r_2, lcd_r_3, lcd_r_4,
+ lcd_r_5, lcd_r_6, lcd_r_7, lcd_vsync, mdmgpio0, mdmgpio1,
+ mdmgpio2, mdmgpio3, mdmgpio4, mdmgpio5, mdmgpio6,
+ mdmgpio7, mdmgpio8, mphi_data_0, mphi_data_1, mphi_data_2,
+ mphi_data_3, mphi_data_4, mphi_data_5, mphi_data_6,
+ mphi_data_7, mphi_data_8, mphi_data_9, mphi_data_10,
+ mphi_data_11, mphi_data_12, mphi_data_13, mphi_data_14,
+ mphi_data_15, mphi_ha0, mphi_hat0, mphi_hat1, mphi_hce0_n,
+ mphi_hce1_n, mphi_hrd_n, mphi_hwr_n, mphi_run0, mphi_run1,
+ mtx_scan_clk, mtx_scan_data, nand_ad_0, nand_ad_1,
+ nand_ad_2, nand_ad_3, nand_ad_4, nand_ad_5, nand_ad_6,
+ nand_ad_7, nand_ale, nand_cen_0, nand_cen_1, nand_cle,
+ nand_oen, nand_rdy_0, nand_rdy_1, nand_wen, nand_wp, pc1,
+ pc2, pmu_int, pmu_scl, pmu_sda, rfst2g_mtsloten3g,
+ rgmii_0_rx_ctl, rgmii_0_rxc, rgmii_0_rxd_0, rgmii_0_rxd_1,
+ rgmii_0_rxd_2, rgmii_0_rxd_3, rgmii_0_tx_ctl, rgmii_0_txc,
+ rgmii_0_txd_0, rgmii_0_txd_1, rgmii_0_txd_2,
+ rgmii_0_txd_3, rgmii_1_rx_ctl, rgmii_1_rxc, rgmii_1_rxd_0,
+ rgmii_1_rxd_1, rgmii_1_rxd_2, rgmii_1_rxd_3,
+ rgmii_1_tx_ctl, rgmii_1_txc, rgmii_1_txd_0, rgmii_1_txd_1,
+ rgmii_1_txd_2, rgmii_1_txd_3, rgmii_gpio_0, rgmii_gpio_1,
+ rgmii_gpio_2, rgmii_gpio_3, rtxdata2g_txdata3g1,
+ rtxen2g_txdata3g2, rxdata3g0, rxdata3g1, rxdata3g2,
+ sdio1_clk, sdio1_cmd, sdio1_data_0, sdio1_data_1,
+ sdio1_data_2, sdio1_data_3, sdio4_clk, sdio4_cmd,
+ sdio4_data_0, sdio4_data_1, sdio4_data_2, sdio4_data_3,
+ sim_clk, sim_data, sim_det, sim_resetn, sim2_clk,
+ sim2_data, sim2_det, sim2_resetn, sri_c, sri_d, sri_e,
+ ssp_extclk, ssp0_clk, ssp0_fs, ssp0_rxd, ssp0_txd,
+ ssp2_clk, ssp2_fs_0, ssp2_fs_1, ssp2_fs_2, ssp2_fs_3,
+ ssp2_rxd_0, ssp2_rxd_1, ssp2_txd_0, ssp2_txd_1, ssp3_clk,
+ ssp3_fs, ssp3_rxd, ssp3_txd, ssp4_clk, ssp4_fs, ssp4_rxd,
+ ssp4_txd, ssp5_clk, ssp5_fs, ssp5_rxd, ssp5_txd, ssp6_clk,
+ ssp6_fs, ssp6_rxd, ssp6_txd, stat_1, stat_2, sysclken,
+ traceclk, tracedt00, tracedt01, tracedt02, tracedt03,
+ tracedt04, tracedt05, tracedt06, tracedt07, tracedt08
+ tracedt09, tracedt10, tracedt11, tracedt12, tracedt13
+ tracedt14, tracedt15, txdata3g0, txpwrind, uartb1_ucts,
+ uartb1_urts, uartb1_urxd, uartb1_utxd, uartb2_urxd,
+ uartb2_utxd, uartb3_ucts, uartb3_urts, uartb3_urxd,
+ uartb3_utxd, uartb4_ucts, uartb4_urts, uartb4_urxd,
+ uartb4_utxd, vc_cam1_scl, vc_cam1_sda, vc_cam2_scl,
+ vc_cam2_sda, vc_cam3_scl, vc_cam3_sda ]
+
+ function:
+ description:
+ Specifies the pin mux selection.
+ enum: [ alt1, alt2, alt3, alt4 ]
+
+ slew-rate:
+ description: |
+ Meaning depends on configured pin mux:
+ *_scl or *_sda:
+ 0: Standard (100 kbps) & Fast (400 kbps) mode
+ 1: Highspeed (3.4 Mbps) mode
+ ic_dm or ic_dp:
+ 0: normal slew rate
+ 1: fast slew rate
+ Otherwise:
+ 0: fast slew rate
+ 1: normal slew rate
+
+ bias-disable: true
+ input-disable: true
+ input-enable: true
+
+ required:
+ - pins
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+
+ # Optional properties for standard pins
+ - if:
+ properties:
+ pins:
+ contains:
+ enum: [ adcsync, bat_rm, classgpwr, clk_cx8, clkout_0,
+ clkout_1, clkout_2, clkout_3, clkreq_in_0,
+ clkreq_in_1, cws_sys_req1, cws_sys_req2,
+ cws_sys_req3, digmic1_clk, digmic1_dq, digmic2_clk,
+ digmic2_dq, gpen13, gpen14, gpen15, gpio00, gpio01,
+ gpio02, gpio03, gpio04, gpio05, gpio06, gpio07,
+ gpio08, gpio09, gpio10, gpio11, gpio12, gpio13,
+ gpio14, gps_pablank, gps_tmark, ic_dm, ic_dp,
+ kp_col_ip_0, kp_col_ip_1, kp_col_ip_2, kp_col_ip_3,
+ kp_row_op_0, kp_row_op_1, kp_row_op_2, kp_row_op_3,
+ lcd_b_0, lcd_b_1, lcd_b_2, lcd_b_3, lcd_b_4, lcd_b_5,
+ lcd_b_6, lcd_b_7, lcd_g_0, lcd_g_1, lcd_g_2, lcd_g_3,
+ lcd_g_4, lcd_g_5, lcd_g_6, lcd_g_7, lcd_hsync,
+ lcd_oe, lcd_pclk, lcd_r_0, lcd_r_1, lcd_r_2,
+ lcd_r_3, lcd_r_4, lcd_r_5, lcd_r_6, lcd_r_7,
+ lcd_vsync, mdmgpio0, mdmgpio1, mdmgpio2, mdmgpio3,
+ mdmgpio4, mdmgpio5, mdmgpio6, mdmgpio7, mdmgpio8,
+ mphi_data_0, mphi_data_1, mphi_data_2, mphi_data_3,
+ mphi_data_4, mphi_data_5, mphi_data_6, mphi_data_7,
+ mphi_data_8, mphi_data_9, mphi_data_10,
+ mphi_data_11, mphi_data_12, mphi_data_13,
+ mphi_data_14, mphi_data_15, mphi_ha0, mphi_hat0,
+ mphi_hat1, mphi_hce0_n, mphi_hce1_n, mphi_hrd_n,
+ mphi_hwr_n, mphi_run0, mphi_run1, mtx_scan_clk,
+ mtx_scan_data, nand_ad_0, nand_ad_1, nand_ad_2,
+ nand_ad_3, nand_ad_4, nand_ad_5, nand_ad_6,
+ nand_ad_7, nand_ale, nand_cen_0, nand_cen_1,
+ nand_cle, nand_oen, nand_rdy_0, nand_rdy_1,
+ nand_wen, nand_wp, pc1, pc2, pmu_int,
+ rfst2g_mtsloten3g, rgmii_0_rx_ctl, rgmii_0_rxc,
+ rgmii_0_rxd_0, rgmii_0_rxd_1, rgmii_0_rxd_2,
+ rgmii_0_rxd_3, rgmii_0_tx_ctl, rgmii_0_txc,
+ rgmii_0_txd_0, rgmii_0_txd_1, rgmii_0_txd_2,
+ rgmii_0_txd_3, rgmii_1_rx_ctl, rgmii_1_rxc,
+ rgmii_1_rxd_0, rgmii_1_rxd_1, rgmii_1_rxd_2,
+ rgmii_1_rxd_3, rgmii_1_tx_ctl, rgmii_1_txc,
+ rgmii_1_txd_0, rgmii_1_txd_1, rgmii_1_txd_2,
+ rgmii_1_txd_3, rgmii_gpio_0, rgmii_gpio_1,
+ rgmii_gpio_2, rgmii_gpio_3, rtxdata2g_txdata3g1,
+ rtxen2g_txdata3g2, rxdata3g0, rxdata3g1, rxdata3g2,
+ sdio1_clk, sdio1_cmd, sdio1_data_0, sdio1_data_1,
+ sdio1_data_2, sdio1_data_3, sdio4_clk, sdio4_cmd,
+ sdio4_data_0, sdio4_data_1, sdio4_data_2,
+ sdio4_data_3, sim_clk, sim_data, sim_det,
+ sim_resetn, sim2_clk, sim2_data, sim2_det,
+ sim2_resetn, sri_c, sri_d, sri_e, ssp_extclk,
+ ssp0_clk, ssp0_fs, ssp0_rxd, ssp0_txd, ssp2_clk,
+ ssp2_fs_0, ssp2_fs_1, ssp2_fs_2, ssp2_fs_3,
+ ssp2_rxd_0, ssp2_rxd_1, ssp2_txd_0, ssp2_txd_1,
+ ssp3_clk, ssp3_fs, ssp3_rxd, ssp3_txd, ssp4_clk,
+ ssp4_fs, ssp4_rxd, ssp4_txd, ssp5_clk, ssp5_fs,
+ ssp5_rxd, ssp5_txd, ssp6_clk, ssp6_fs, ssp6_rxd,
+ ssp6_txd, stat_1, stat_2, sysclken, traceclk,
+ tracedt00, tracedt01, tracedt02, tracedt03,
+ tracedt04, tracedt05, tracedt06, tracedt07,
+ tracedt08, tracedt09, tracedt10, tracedt11,
+ tracedt12, tracedt13, tracedt14, tracedt15,
+ txdata3g0, txpwrind, uartb1_ucts, uartb1_urts,
+ uartb1_urxd, uartb1_utxd, uartb2_urxd, uartb2_utxd,
+ uartb3_ucts, uartb3_urts, uartb3_urxd, uartb3_utxd,
+ uartb4_ucts, uartb4_urts, uartb4_urxd, uartb4_utxd ]
+ then:
+ properties:
+ drive-strength:
+ enum: [ 2, 4, 6, 8, 10, 12, 14, 16 ]
+
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+
+ # Optional properties for I2C pins
+ - if:
+ properties:
+ pins:
+ contains:
+ enum: [ bsc1_scl, bsc1_sda, bsc2_scl, bsc2_sda, pmu_scl,
+ pmu_sda, vc_cam1_scl, vc_cam1_sda, vc_cam2_scl,
+ vc_cam2_sda, vc_cam3_scl, vc_cam3_sda ]
+ then:
+ properties:
+ bias-pull-up:
+ description:
+ There are 3 pull-up resistors (1.2k, 1.8k, 2.7k) available
+ in parallel for I2C pins.
+ enum: [ 568, 720, 831, 1080, 1200, 1800, 2700 ]
+
+ bias-disable: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pinctrl@35004800 {
+ compatible = "brcm,bcm11351-pinctrl";
+ reg = <0x35004800 0x430>;
+
+ dev-a-active-pins {
+ /* group node defining 1 standard pin */
+ std-grp0 {
+ pins = "gpio00";
+ function = "alt1";
+ input-schmitt-enable;
+ bias-disable;
+ slew-rate = <1>;
+ drive-strength = <4>;
+ };
+
+ /* group node defining 2 I2C pins */
+ i2c-grp0 {
+ pins = "bsc1_scl", "bsc1_sda";
+ function = "alt2";
+ bias-pull-up = <720>;
+ input-enable;
+ };
+
+ /* group node defining 2 HDMI pins */
+ hdmi-grp0 {
+ pins = "hdmi_scl", "hdmi_sda";
+ function = "alt3";
+ slew-rate = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
index 739a08f..beb769e 100644
--- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
@@ -11,7 +11,7 @@
description:
The Canaan Kendryte K210 SoC Fully Programmable IO Array (FPIOA)
- controller allows assiging any of 256 possible functions to any of
+ controller allows assigning any of 256 possible functions to any of
48 IO pins of the SoC. Pin function configuration is performed on
a per-pin basis.
diff --git a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml
index 222d575..7f30ec2 100644
--- a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml
@@ -51,6 +51,10 @@
description:
Optional power supply.
+ reset-gpios:
+ description: GPIO connected to the XRES pin
+ maxItems: 1
+
patternProperties:
'-pins$':
type: object
diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
index 3572396..8909618 100644
--- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
@@ -135,7 +135,6 @@
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -147,8 +146,6 @@
additionalProperties: false
- type: object
- properties:
- phandle: true
additionalProperties:
type: object
allOf:
@@ -156,7 +153,6 @@
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
index 7f0e2d6..3bbc00d 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
@@ -159,7 +159,7 @@
mediatek,pull-up-adv:
description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
+ Pull up settings for 2 pull resistors, R0 and R1. User can
configure those special pins. Valid arguments are described as
below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
index 601d86a..68e91c0 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
@@ -130,7 +130,7 @@
mediatek,pull-up-adv:
description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
+ Pull up settings for 2 pull resistors, R0 and R1. User can
configure those special pins. Valid arguments are described as
below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
index 10717ce..74d52a7 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
@@ -386,7 +386,7 @@
mediatek,pull-up-adv:
description: |
Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
- Pull up setings for 2 pull resistors, R0 and R1. Valid arguments
+ Pull up settings for 2 pull resistors, R0 and R1. Valid arguments
are described as below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
@@ -398,7 +398,7 @@
mediatek,pull-down-adv:
description: |
Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
- Pull down setings for 2 pull resistors, R0 and R1. Valid arguments
+ Pull down settings for 2 pull resistors, R0 and R1. Valid arguments
are described as below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml
index 0f615ad..5ad6513 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml
@@ -332,7 +332,7 @@
mediatek,pull-up-adv:
description: |
Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
- Pull up setings for 2 pull resistors, R0 and R1. Valid arguments
+ Pull up settings for 2 pull resistors, R0 and R1. Valid arguments
are described as below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
@@ -344,7 +344,7 @@
mediatek,pull-down-adv:
description: |
Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
- Pull down setings for 2 pull resistors, R0 and R1. Valid arguments
+ Pull down settings for 2 pull resistors, R0 and R1. Valid arguments
are described as below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
index ff24cf2..8507bd1 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
@@ -143,7 +143,7 @@
mediatek,pull-up-adv:
description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
+ Pull up settings for 2 pull resistors, R0 and R1. User can
configure those special pins. Valid arguments are described as
below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
index 61b33b5..7b43e78 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
@@ -149,7 +149,7 @@
deprecated: true
description: |
DEPRECATED: Please use bias-pull-up instead.
- Pull up setings for 2 pull resistors, R0 and R1. User can
+ Pull up settings for 2 pull resistors, R0 and R1. User can
configure those special pins. Valid arguments are described as
below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml
index 065dedb..1690c0e 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml
@@ -22,8 +22,6 @@
patternProperties:
"^pinmux(-[a-z0-9-_]+)?$":
type: object
- properties:
- phandle: true
# pin groups
additionalProperties:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml
index f924652..9b7368b 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml
@@ -32,8 +32,6 @@
patternProperties:
"^pinmux(-[a-z0-9-_]+)?$":
type: object
- properties:
- phandle: true
# pin groups
additionalProperties:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml
index 60a4bdf..87b6f4f 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml
@@ -23,8 +23,6 @@
patternProperties:
"^pinmux(-[a-z0-9-_]+)?$":
type: object
- properties:
- phandle: true
# pin groups
additionalProperties:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml
index 432ea40..63cd743 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml
@@ -24,8 +24,6 @@
patternProperties:
"^pinmux(-[a-z0-9-_]+)?$":
type: object
- properties:
- phandle: true
# pin groups
additionalProperties:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
index 28ae2e6..e99387a 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
@@ -22,8 +22,6 @@
patternProperties:
"^pinmux(-[a-z0-9-_]+)?$":
type: object
- properties:
- phandle: true
# pin groups
additionalProperties:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml
index c0eda78..36c8f33 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml
@@ -22,8 +22,6 @@
patternProperties:
"^pinmux(-[a-z0-9-_]+)?$":
type: object
- properties:
- phandle: true
# pin groups
additionalProperties:
diff --git a/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt
deleted file mode 100644
index b115943..0000000
--- a/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Oxford Semiconductor OXNAS SoC Family Pin Controller
-
-Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
-../interrupt-controller/interrupts.txt for generic information regarding
-pin controller, GPIO, and interrupt bindings.
-
-OXNAS 'pin configuration node' is a node of a group of pins which can be
-used for a specific device or function. This node represents configurations of
-pins, optional function, and optional mux related configuration.
-
-Required properties for pin controller node:
- - compatible: "oxsemi,ox810se-pinctrl" or "oxsemi,ox820-pinctrl"
- - oxsemi,sys-ctrl: a phandle to the system controller syscon node
-
-Required properties for pin configuration sub-nodes:
- - pins: List of pins to which the configuration applies.
-
-Optional properties for pin configuration sub-nodes:
-----------------------------------------------------
- - function: Mux function for the specified pins.
- - bias-pull-up: Enable weak pull-up.
-
-Example:
-
-pinctrl: pinctrl {
- compatible = "oxsemi,ox810se-pinctrl";
-
- /* Regmap for sys registers */
- oxsemi,sys-ctrl = <&sys>;
-
- pinctrl_uart2: pinctrl_uart2 {
- uart2a {
- pins = "gpio31";
- function = "fct3";
- };
- uart2b {
- pins = "gpio32";
- function = "fct3";
- };
- };
-};
-
-uart2: serial@900000 {
- compatible = "ns16550a";
- reg = <0x900000 0x100000>;
- clocks = <&sysclk>;
- interrupts = <29>;
- reg-shift = <0>;
- fifo-size = <16>;
- reg-io-width = <1>;
- current-speed = <115200>;
- no-loopback-test;
- resets = <&reset 22>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
index 511fc23..28fbca1 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
@@ -38,7 +38,7 @@
gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
reference-out
-Theres is also customised properties for the GPIO1, GPIO2 and GPIO3. These
+There are also customised properties for the GPIO1, GPIO2 and GPIO3. These
customised properties are required to configure FPS configuration parameters
of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
detail of Flexible Power Sequence (FPS).
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
index 939cb5b..6ad49e5 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
@@ -40,7 +40,7 @@
Valid values for function properties are: gpio.
-Theres is also not customised properties for any GPIO.
+There are also not customised properties for any GPIO.
Example:
--------
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
deleted file mode 100644
index bfd222b..0000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ /dev/null
@@ -1,262 +0,0 @@
-One-register-per-pin type device tree based pinctrl driver
-
-Required properties:
-- compatible : "pinctrl-single" or "pinconf-single".
- "pinctrl-single" means that pinconf isn't supported.
- "pinconf-single" means that generic pinconf is supported.
-
-- reg : offset and length of the register set for the mux registers
-
-- #pinctrl-cells : number of cells in addition to the index, set to 1
- or 2 for pinctrl-single,pins and set to 2 for pinctrl-single,bits
-
-- pinctrl-single,register-width : pinmux register access width in bits
-
-- pinctrl-single,function-mask : mask of allowed pinmux function bits
- in the pinmux register
-
-Optional properties:
-- pinctrl-single,function-off : function off mode for disabled state if
- available and same for all registers; if not specified, disabling of
- pin functions is ignored
-
-- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
- more than one pin, for which "pinctrl-single,function-mask" property specifies
- position mask of pin.
-
-- pinctrl-single,drive-strength : array of value that are used to configure
- drive strength in the pinmux register. They're value of drive strength
- current and drive strength mask.
-
- /* drive strength current, mask */
- pinctrl-single,power-source = <0x30 0xf0>;
-
-- pinctrl-single,bias-pullup : array of value that are used to configure the
- input bias pullup in the pinmux register.
-
- /* input, enabled pullup bits, disabled pullup bits, mask */
- pinctrl-single,bias-pullup = <0 1 0 1>;
-
-- pinctrl-single,bias-pulldown : array of value that are used to configure the
- input bias pulldown in the pinmux register.
-
- /* input, enabled pulldown bits, disabled pulldown bits, mask */
- pinctrl-single,bias-pulldown = <2 2 0 2>;
-
- * Two bits to control input bias pullup and pulldown: User should use
- pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
- pullup, and the other one bit means pulldown.
- * Three bits to control input bias enable, pullup and pulldown. User should
- use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
- enable bit should be included in pullup or pulldown bits.
- * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
- pinctrl-single,bias-disable. Because pinctrl single driver could implement
- it by calling pulldown, pullup disabled.
-
-- pinctrl-single,input-schmitt : array of value that are used to configure
- input schmitt in the pinmux register. In some silicons, there're two input
- schmitt value (rising-edge & falling-edge) in the pinmux register.
-
- /* input schmitt value, mask */
- pinctrl-single,input-schmitt = <0x30 0x70>;
-
-- pinctrl-single,input-schmitt-enable : array of value that are used to
- configure input schmitt enable or disable in the pinmux register.
-
- /* input, enable bits, disable bits, mask */
- pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
-
-- pinctrl-single,low-power-mode : array of value that are used to configure
- low power mode of this pin. For some silicons, the low power mode will
- control the output of the pin when the pad including the pin enter low
- power mode.
- /* low power mode value, mask */
- pinctrl-single,low-power-mode = <0x288 0x388>;
-
-- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
- range. They're value of subnode phandle, pin base in pinctrl device, pin
- number in this range, GPIO function value of this GPIO range.
- The number of parameters is depend on #pinctrl-single,gpio-range-cells
- property.
-
- /* pin base, nr pins & gpio function */
- pinctrl-single,gpio-range = <&range 0 3 0>, <&range 3 9 1>;
-
-- interrupt-controller : standard interrupt controller binding if using
- interrupts for wake-up events for example. In this case pinctrl-single
- is set up as a chained interrupt controller and the wake-up interrupts
- can be requested by the drivers using request_irq().
-
-- #interrupt-cells : standard interrupt binding if using interrupts
-
-This driver assumes that there is only one register for each pin (unless the
-pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
-specified in the pinctrl-bindings.txt document in this directory.
-
-The pin configuration nodes for pinctrl-single are specified as pinctrl
-register offset and values using pinctrl-single,pins. Only the bits specified
-in pinctrl-single,function-mask are updated.
-
-When #pinctrl-cells = 1, then setting a pin for a device could be done with:
-
- pinctrl-single,pins = <0xdc 0x118>;
-
-Where 0xdc is the offset from the pinctrl register base address for the device
-pinctrl register, and 0x118 contains the desired value of the pinctrl register.
-
-When #pinctrl-cells = 2, then setting a pin for a device could be done with:
-
- pinctrl-single,pins = <0xdc 0x30 0x07>;
-
-Where 0x30 is the pin configuration value and 0x07 is the pin mux mode value.
-These two values are OR'd together to produce the value stored at offset 0xdc.
-See the device example and static board pins example below for more information.
-
-In case when one register changes more than one pin's mux the
-pinctrl-single,bits need to be used which takes three parameters:
-
- pinctrl-single,bits = <0xdc 0x18 0xff>;
-
-Where 0xdc is the offset from the pinctrl register base address for the
-device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
-be used when applying this change to the register.
-
-
-Optional sub-node: In case some pins could be configured as GPIO in the pinmux
-register, those pins could be defined as a GPIO range. This sub-node is required
-by pinctrl-single,gpio-range property.
-
-Required properties in sub-node:
-- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
- pinctrl-single,gpio-range property.
-
- range: gpio-range {
- #pinctrl-single,gpio-range-cells = <3>;
- };
-
-
-Example:
-
-/* SoC common file */
-
-/* first controller instance for pins in core domain */
-pmx_core: pinmux@4a100040 {
- compatible = "pinctrl-single";
- reg = <0x4a100040 0x0196>;
- #address-cells = <1>;
- #size-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- pinctrl-single,register-width = <16>;
- pinctrl-single,function-mask = <0xffff>;
-};
-
-/* second controller instance for pins in wkup domain */
-pmx_wkup: pinmux@4a31e040 {
- compatible = "pinctrl-single";
- reg = <0x4a31e040 0x0038>;
- #address-cells = <1>;
- #size-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- pinctrl-single,register-width = <16>;
- pinctrl-single,function-mask = <0xffff>;
-};
-
-control_devconf0: pinmux@48002274 {
- compatible = "pinctrl-single";
- reg = <0x48002274 4>; /* Single register */
- #address-cells = <1>;
- #size-cells = <0>;
- pinctrl-single,bit-per-mux;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x5F>;
-};
-
-/* third controller instance for pins in gpio domain */
-pmx_gpio: pinmux@d401e000 {
- compatible = "pinconf-single";
- reg = <0xd401e000 0x0330>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <7>;
-
- /* sparse GPIO range could be supported */
- pinctrl-single,gpio-range = <&range 0 3 0>, <&range 3 9 1>,
- <&range 12 1 0>, <&range 13 29 1>,
- <&range 43 1 0>, <&range 44 49 1>,
- <&range 94 1 1>, <&range 96 2 1>;
-
- range: gpio-range {
- #pinctrl-single,gpio-range-cells = <3>;
- };
-};
-
-
-/* board specific .dts file */
-
-&pmx_core {
-
- /*
- * map all board specific static pins enabled by the pinctrl driver
- * itself during the boot (or just set them up in the bootloader)
- */
- pinctrl-names = "default";
- pinctrl-0 = <&board_pins>;
-
- board_pins: pinmux_board_pins {
- pinctrl-single,pins = <
- 0x6c 0xf
- 0x6e 0xf
- 0x70 0xf
- 0x72 0xf
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- 0x208 0 /* UART0_RXD (IOCFG138) */
- 0x20c 0 /* UART0_TXD (IOCFG139) */
- >;
- pinctrl-single,bias-pulldown = <0 2 2>;
- pinctrl-single,bias-pullup = <0 1 1>;
- };
-
- /* map uart2 pins */
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- 0xd8 0x118
- 0xda 0
- 0xdc 0x118
- 0xde 0
- >;
- };
-};
-
-&control_devconf0 {
- mcbsp1_pins: pinmux_mcbsp1_pins {
- pinctrl-single,bits = <
- 0x00 0x18 0x18 /* FSR/CLKR signal from FSX/CLKX pin */
- >;
- };
-
- mcbsp2_clks_pins: pinmux_mcbsp2_clks_pins {
- pinctrl-single,bits = <
- 0x00 0x40 0x40 /* McBSP2 CLKS from McBSP_CLKS pin */
- >;
- };
-
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
new file mode 100644
index 0000000..45a307d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
@@ -0,0 +1,207 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Pin Controller with a Single Register for One or More Pins
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description:
+ Some pin controller devices use a single register for one or more pins. The
+ range of pin control registers can vary from one to many for each controller
+ instance. Some SoCs from Altera, Broadcom, HiSilicon, Ralink, and TI have this
+ kind of pin controller instances.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - pinctrl-single
+ - pinconf-single
+ - items:
+ - enum:
+ - ti,am437-padconf
+ - ti,am654-padconf
+ - ti,dra7-padconf
+ - ti,omap2420-padconf
+ - ti,omap2430-padconf
+ - ti,omap3-padconf
+ - ti,omap4-padconf
+ - ti,omap5-padconf
+ - const: pinctrl-single
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#pinctrl-cells':
+ description:
+ Number of cells. Usually 2, consisting of register offset, pin configuration
+ value, and pinmux mode. Some controllers may use 1 for just offset and value.
+ enum: [ 1, 2 ]
+
+ pinctrl-single,bit-per-mux:
+ description: Optional flag to indicate register controls more than one pin
+ type: boolean
+
+ pinctrl-single,function-mask:
+ description: Mask of the allowed register bits
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pinctrl-single,function-off:
+ description: Optional function off mode for disabled state
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pinctrl-single,register-width:
+ description: Width of pin specific bits in the register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 8, 16, 32 ]
+
+ pinctrl-single,gpio-range:
+ description: Optional list of pin base, nr pins & gpio function
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle of a gpio-range node
+ - description: pin base
+ - description: number of pins
+ - description: gpio function
+
+ '#gpio-range-cells':
+ description: No longer needed, may exist in older files for gpio-ranges
+ deprecated: true
+ const: 3
+
+ gpio-range:
+ description: Optional node for gpio range cells
+ type: object
+ additionalProperties: false
+ properties:
+ '#pinctrl-single,gpio-range-cells':
+ description: Number of gpio range cells
+ const: 3
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+patternProperties:
+ '-pins(-[0-9]+)?$|-pin$':
+ description:
+ Pin group node name using naming ending in -pins followed by an optional
+ instance number
+ type: object
+ additionalProperties: false
+
+ properties:
+ pinctrl-single,pins:
+ description:
+ Array of pins as described in pinmux-node.yaml for pinctrl-pin-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ pinctrl-single,bits:
+ description: Register bit configuration for pinctrl-single,bit-per-mux
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: register offset
+ - description: value
+ - description: pin bitmask in the register
+
+ pinctrl-single,bias-pullup:
+ description: Optional bias pull up configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: input
+ - description: enabled pull up bits
+ - description: disabled pull up bits
+ - description: bias pull up mask
+
+ pinctrl-single,bias-pulldown:
+ description: Optional bias pull down configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: input
+ - description: enabled pull down bits
+ - description: disabled pull down bits
+ - description: bias pull down mask
+
+ pinctrl-single,drive-strength:
+ description: Optional drive strength configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: drive strength current
+ - description: drive strength mask
+
+ pinctrl-single,input-schmitt:
+ description: Optional input schmitt configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: input
+ - description: enable bits
+ - description: disable bits
+ - description: input schmitt mask
+
+ pinctrl-single,low-power-mode:
+ description: Optional low power mode configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: low power mode value
+ - description: low power mode mask
+
+ pinctrl-single,slew-rate:
+ description: Optional slew rate configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: slew rate
+ - description: slew rate mask
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - pinctrl-single,register-width
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pinmux@4a100040 {
+ compatible = "pinctrl-single";
+ reg = <0x4a100040 0x0196>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pinctrl-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0xffff>;
+ pinctrl-single,gpio-range = <&range 0 3 0>;
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+
+ uart2-pins {
+ pinctrl-single,pins =
+ <0xd8 0x118>,
+ <0xda 0>,
+ <0xdc 0x118>,
+ <0xde 0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index 8aaf501..3f8ad07 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -26,6 +26,7 @@
- qcom,pm6350-gpio
- qcom,pm7250b-gpio
- qcom,pm7325-gpio
+ - qcom,pm7550ba-gpio
- qcom,pm8005-gpio
- qcom,pm8008-gpio
- qcom,pm8018-gpio
@@ -53,6 +54,8 @@
- qcom,pm8994-gpio
- qcom,pm8998-gpio
- qcom,pma8084-gpio
+ - qcom,pmc8180-gpio
+ - qcom,pmc8180c-gpio
- qcom,pmi632-gpio
- qcom,pmi8950-gpio
- qcom,pmi8994-gpio
@@ -68,6 +71,7 @@
- qcom,pms405-gpio
- qcom,pmx55-gpio
- qcom,pmx65-gpio
+ - qcom,pmx75-gpio
- enum:
- qcom,spmi-gpio
@@ -172,6 +176,7 @@
compatible:
contains:
enum:
+ - qcom,pm7550ba-gpio
- qcom,pm8226-gpio
- qcom,pm8350b-gpio
- qcom,pm8550ve-gpio
@@ -301,6 +306,7 @@
contains:
enum:
- qcom,pmx65-gpio
+ - qcom,pmx75-gpio
then:
properties:
gpio-line-names:
@@ -413,6 +419,7 @@
- gpio1-gpio9 for pm6350
- gpio1-gpio12 for pm7250b
- gpio1-gpio10 for pm7325
+ - gpio1-gpio8 for pm7550ba
- gpio1-gpio4 for pm8005
- gpio1-gpio2 for pm8008
- gpio1-gpio6 for pm8018
@@ -456,6 +463,7 @@
- gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10
and gpio11)
- gpio1-gpio16 for pmx65
+ - gpio1-gpio16 for pmx75
items:
pattern: "^gpio([0-9]+)$"
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
index e608a4f..e119a22 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
@@ -87,7 +87,7 @@
emac0_mdc, emac0_mdio, emac0_ptp_aux, emac0_ptp_pps, emac1_mcg0,
emac1_mcg1, emac1_mcg2, emac1_mcg3, emac1_mdc, emac1_mdio,
emac1_ptp_aux, emac1_ptp_pps, gcc_gp1, gcc_gp2, gcc_gp3,
- gcc_gp4, gcc_gp5, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c,
+ gcc_gp4, gcc_gp5, gpio, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c,
jitter_bist, mdp0_vsync0, mdp0_vsync1, mdp0_vsync2, mdp0_vsync3,
mdp0_vsync4, mdp0_vsync5, mdp0_vsync6, mdp0_vsync7, mdp0_vsync8,
mdp1_vsync0, mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
index fa51fa9..00c5a00 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
@@ -17,11 +17,6 @@
compatible:
const: qcom,sc7280-lpass-lpi-pinctrl
- qcom,adsp-bypass-mode:
- description:
- Tells ADSP is in bypass mode.
- type: boolean
-
reg:
maxItems: 2
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml
new file mode 100644
index 0000000..abac331
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6115 SoC LPASS LPI TLMM
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM6115 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm6115-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: audio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm6115-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm6115-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm6115-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-8])$"
+
+ function:
+ enum: [ dmic01_clk, dmic01_data, dmic23_clk, dmic23_data, gpio, i2s1_clk,
+ i2s1_data, i2s1_ws, i2s2_clk, i2s2_data, i2s2_ws, i2s3_clk,
+ i2s3_data, i2s3_ws, qua_mi2s_data, qua_mi2s_sclk, qua_mi2s_ws,
+ swr_rx_clk, swr_rx_data, swr_tx_clk, swr_tx_data, wsa_mclk ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ slew-rate:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ 0: No adjustments
+ 1: Higher Slew rate (faster edges)
+ 2: Lower Slew rate (slower edges)
+ 3: Reserved (No adjustments)
+
+ bias-bus-hold: true
+ bias-pull-down: true
+ bias-pull-up: true
+ bias-disable: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+
+ lpass_tlmm: pinctrl@a7c0000 {
+ compatible = "qcom,sm6115-lpass-lpi-pinctrl";
+ reg = <0x0a7c0000 0x20000>,
+ <0x0a950000 0x10000>;
+ clocks = <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 19>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml
new file mode 100644
index 0000000..2e65ae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 SoC LPASS LPI TLMM
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8350 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm8350-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ description: Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8350-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8350-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8350-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
+
+ function:
+ enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk,
+ dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b,
+ ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk,
+ i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk,
+ i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, i2s4_clk,
+ i2s4_data, i2s4_ws, slimbus_clk, slimbus_data, swr_rx_clk,
+ swr_rx_data, swr_tx_clk, swr_tx_data, wsa_swr_clk,
+ wsa_swr_data, wsa2_swr_clk, wsa2_swr_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ slew-rate:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ 0: No adjustments
+ 1: Higher Slew rate (faster edges)
+ 2: Lower Slew rate (slower edges)
+ 3: Reserved (No adjustments)
+
+ bias-bus-hold: true
+ bias-pull-down: true
+ bias-pull-up: true
+ bias-disable: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+
+ lpass_tlmm: pinctrl@33c0000 {
+ compatible = "qcom,sm8350-lpass-lpi-pinctrl";
+ reg = <0x033c0000 0x20000>,
+ <0x03550000 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 = <&lpass_tlmm 0 0 15>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
index 0fc3c0f..181cd16 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
@@ -107,7 +107,6 @@
Client device subnodes use below standard properties.
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -127,9 +126,6 @@
additionalProperties: false
- type: object
- properties:
- phandle: true
-
additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
index 83800fc..2bd7d47 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
@@ -108,7 +108,6 @@
Integers values in "pinmux" argument list are assembled as:
((PORT * 16 + PIN) | MUX_FUNC << 16)
- phandle: true
input-enable: true
output-enable: true
@@ -118,9 +117,6 @@
additionalProperties: false
- type: object
- properties:
- phandle: true
-
additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml
index 37173a6..8271e7b 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml
@@ -37,40 +37,37 @@
gpio-ranges:
maxItems: 1
-patternProperties:
- "^.*$":
- if:
- type: object
- then:
- allOf:
- - $ref: pincfg-node.yaml#
- - $ref: pinmux-node.yaml#
+additionalProperties:
+ type: object
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ description:
+ The child nodes of the pin controller designate pins to be used for
+ specific peripheral functions or as GPIO.
+
+ A pin multiplexing sub-node describes how to configure a set of
+ (or a single) pin in some desired alternate function mode.
+ The values for the pinmux properties are a combination of port name,
+ pin number and the desired function index. Use the RZA2_PINMUX macro
+ located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily
+ define these.
+ For assigning GPIO pins, use the macro RZA2_PIN also in
+ to express the desired port pin.
+
+ properties:
+ pinmux:
description:
- The child nodes of the pin controller designate pins to be used for
- specific peripheral functions or as GPIO.
+ Values are constructed from GPIO port number, pin number, and
+ alternate function configuration number using the RZA2_PINMUX()
+ helper macro in r7s9210-pinctrl.h.
- A pin multiplexing sub-node describes how to configure a set of
- (or a single) pin in some desired alternate function mode.
- The values for the pinmux properties are a combination of port name,
- pin number and the desired function index. Use the RZA2_PINMUX macro
- located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily
- define these.
- For assigning GPIO pins, use the macro RZA2_PIN also in
- to express the desired port pin.
+ required:
+ - pinmux
- properties:
- phandle: true
-
- pinmux:
- description:
- Values are constructed from GPIO port number, pin number, and
- alternate function configuration number using the RZA2_PINMUX()
- helper macro in r7s9210-pinctrl.h.
-
- required:
- - pinmux
-
- additionalProperties: false
+ additionalProperties: false
allOf:
- $ref: pinctrl.yaml#
@@ -82,8 +79,6 @@
- '#gpio-cells'
- gpio-ranges
-additionalProperties: false
-
examples:
- |
#include <dt-bindings/pinctrl/r7s9210-pinctrl.h>
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
index 9ce1a07..145c544 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
@@ -83,7 +83,6 @@
Client device subnodes use below standard properties.
properties:
- phandle: true
pinmux:
description:
Values are constructed from GPIO port number, pin number, and
@@ -106,9 +105,6 @@
line-name: true
- type: object
- properties:
- phandle: true
-
additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml
index 19d4d2f..8166885 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml
@@ -74,7 +74,6 @@
offset by 10. Additional identifiers are provided to specify the
MDIO source peripheral.
- phandle: true
bias-disable: true
bias-pull-up:
description: Pull up the pin with 50 kOhm
@@ -91,9 +90,6 @@
$ref: "#/additionalProperties/anyOf/0"
- type: object
- properties:
- phandle: true
-
additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml
index c87161f..cb81a17 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml
@@ -63,7 +63,6 @@
Client device subnodes use below standard properties.
properties:
- phandle: true
pinmux:
description:
Values are constructed from GPIO port number, pin number, and
@@ -87,9 +86,6 @@
line-name: true
- type: object
- properties:
- phandle: true
-
additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
index a6f34df..880da72 100644
--- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
@@ -32,7 +32,6 @@
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -49,7 +48,6 @@
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
diff --git a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
index b1cea7a..779b8ef 100644
--- a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
@@ -8,7 +8,7 @@
pad driving level, system control select and so on ("domain pad
driving level": One pin can output 3.0v or 1.8v, depending on the
related domain pad driving selection, if the related domain pad
-slect 3.0v, then the pin can output 3.0v. "system control" is used
+select 3.0v, then the pin can output 3.0v. "system control" is used
to choose one function (like: UART0) for which system, since we
have several systems (AP/CP/CM4) on one SoC.).
diff --git a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt
deleted file mode 100644
index 88c8027..0000000
--- a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-OMAP Pinctrl definitions
-
-Required properties:
-- compatible : Should be one of:
- "ti,omap2420-padconf" - OMAP2420 compatible pinctrl
- "ti,omap2430-padconf" - OMAP2430 compatible pinctrl
- "ti,omap3-padconf" - OMAP3 compatible pinctrl
- "ti,omap4-padconf" - OMAP4 compatible pinctrl
- "ti,omap5-padconf" - OMAP5 compatible pinctrl
- "ti,dra7-padconf" - DRA7 compatible pinctrl
- "ti,am437-padconf" - AM437x compatible pinctrl
-
-See Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt for further details.
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
index 24ad061..01b6f2b 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -273,6 +273,10 @@
slew-rate:
enum: [0, 1]
+ output-enable:
+ description:
+ This will internally disable the tri-state for MIO pins.
+
drive-strength:
description:
Selects the drive strength for MIO pins, in mA.
diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.txt b/Documentation/devicetree/bindings/pmem/pmem-region.txt
index 5cfa4f0..cd79975 100644
--- a/Documentation/devicetree/bindings/pmem/pmem-region.txt
+++ b/Documentation/devicetree/bindings/pmem/pmem-region.txt
@@ -19,7 +19,7 @@
- compatible = "pmem-region"
- reg = <base, size>;
- The reg property should specificy an address range that is
+ The reg property should specify an address range that is
translatable to a system physical address range. This address
range should be mappable as normal system memory would be
(i.e cacheable).
@@ -30,7 +30,7 @@
node implies no special relationship between the two ranges.
Optional properties:
- - Any relevant NUMA assocativity properties for the target platform.
+ - Any relevant NUMA associativity properties for the target platform.
- volatile; This property indicates that this region is actually
backed by non-persistent memory. This lets the OS know that it
diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
index eab21bb..d80bbed 100644
--- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
+++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
@@ -12,7 +12,7 @@
- Jianxin Pan <jianxin.pan@amlogic.com>
description: |+
- Secure Power Domains used in Meson A1/C1/S4 SoCs, and should be the child node
+ Secure Power Domains used in Meson A1/C1/S4 & C3 SoCs, and should be the child node
of secure-monitor.
properties:
@@ -20,6 +20,7 @@
enum:
- amlogic,meson-a1-pwrc
- amlogic,meson-s4-pwrc
+ - amlogic,c3-pwrc
"#power-domain-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index f9c211a..9b03c41 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -41,6 +41,7 @@
- qcom,sdm845-rpmhpd
- qcom,sdx55-rpmhpd
- qcom,sdx65-rpmhpd
+ - qcom,sdx75-rpmhpd
- qcom,sm6115-rpmpd
- qcom,sm6125-rpmpd
- qcom,sm6350-rpmhpd
diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml
index 5597189..fba6914 100644
--- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml
@@ -58,7 +58,7 @@
pd-node:
type: object
description:
- PM domain node representing a PM domain. This node hould be named by
+ PM domain node representing a PM domain. This node should be named by
the real power area name, and thus its name should be unique.
properties:
diff --git a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
index 45d66c7..b54ec00 100644
--- a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
+++ b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/reset/gpio-poweroff.yaml#
diff --git a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
index d3d18e0..53535de 100644
--- a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
+++ b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/reset/gpio-restart.yaml#
diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
index f2ffdd2..965a834 100644
--- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
+++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/reset/restart-handler.yaml#
diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
index 4fe9c370..a76afe3 100644
--- a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
%YAML 1.2
---
diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml
index 99f506d..f255f38 100644
--- a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml
+++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/sbs,sbs-manager.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SBS compliant manger
+title: SBS compliant manager
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
deleted file mode 100644
index 54b9f9d..0000000
--- a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
+++ /dev/null
@@ -1,34 +0,0 @@
------------------------------------------------------------
-Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
------------------------------------------------------------
-The binding for zynqmp-power-controller follow the common
-generic PM domain binding[1].
-
-[1] Documentation/devicetree/bindings/power/power-domain.yaml
-
-== Zynq MPSoC Generic PM Domain Node ==
-
-Required property:
- - Below property should be in zynqmp-firmware node.
- - #power-domain-cells: Number of cells in a PM domain specifier. Must be 1.
-
-Power domain ID indexes are mentioned in
-include/dt-bindings/power/xlnx-zynqmp-power.h.
-
--------
-Example
--------
-
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- ...
- #power-domain-cells = <1>;
- ...
- };
-};
-
-sata {
- ...
- power-domains = <&zynqmp_firmware 28>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
index 801c660..4787db8 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -28,6 +28,6 @@
Snoop ID Port Mapping registers, which are part of the CoreNet
Coherency fabric (CCF), provide a CoreNet Coherency Subdomain
ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from
- these registers should be set if the coresponding CPU should be
+ these registers should be set if the corresponding CPU should be
snooped. This property defines a bitmask which selects the bit
that should be set if this cpu should be snooped.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
index 4b01e1a..62744af 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
@@ -185,10 +185,10 @@
with distinct functionality.
The first register range describes the CoreNet Debug Controller
- functionalty to perform transaction and transaction attribute matches.
+ functionality to perform transaction and transaction attribute matches.
The second register range describes the CoreNet Debug Controller
- functionalty to trigger event notifications and debug traces.
+ functionality to trigger event notifications and debug traces.
EXAMPLE
dcsr-corenet {
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
index 4ad29b9..ea902bc5 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
@@ -60,7 +60,7 @@
- fsl,liodn: Specifies the LIODN to be used for Job Ring. This
property is normally set by firmware. Value
is of 12-bits which is the LIODN number for this JR.
- This property is used by the IOMMU (PAMU) to distinquish
+ This property is used by the IOMMU (PAMU) to distinguish
transactions from this JR and than be able to do address
translation & protection accordingly.
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt
index b558585..3826bd1 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt
@@ -42,7 +42,7 @@
- compatible : should be "nintendo,flipper-pic"
-1.c) The Digital Signal Procesor (DSP) node
+1.c) The Digital Signal Processor (DSP) node
Represents the digital signal processor interface, designed to offload
audio related tasks.
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index 3ff6ebb..6f69a9d 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -53,7 +53,7 @@
- compatible : should be "nintendo,flipper-pic"
- interrupt-controller
-1.c) The Digital Signal Procesor (DSP) node
+1.c) The Digital Signal Processor (DSP) node
Represents the digital signal processor interface, designed to offload
audio related tasks.
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt
deleted file mode 100644
index 9012a2a..0000000
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Device-Tree Bindings for a PPS Signal on GPIO
-
-These properties describe a PPS (pulse-per-second) signal connected to
-a GPIO pin.
-
-Required properties:
-- compatible: should be "pps-gpio"
-- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
-
-Additional required properties for the PPS ECHO functionality:
-- echo-gpios: one PPS ECHO GPIO in the format described by ../gpio/gpio.txt
-- echo-active-ms: duration in ms of the active portion of the echo pulse
-
-Optional properties:
-- assert-falling-edge: when present, assert is indicated by a falling edge
- (instead of by a rising edge)
-
-Example:
- pps {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pps>;
-
- gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
- assert-falling-edge;
-
- echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
- echo-active-ms = <100>;
-
- compatible = "pps-gpio";
- };
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.yaml b/Documentation/devicetree/bindings/pps/pps-gpio.yaml
new file mode 100644
index 0000000..fd4adfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pps/pps-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PPS Signal via GPIO
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+properties:
+ compatible:
+ const: pps-gpio
+
+ gpios:
+ description: The GPIO that provides the PPS signal.
+ maxItems: 1
+
+ echo-gpios:
+ description: The GPIO that provides the PPS ECHO signal.
+ maxItems: 1
+
+ echo-active-ms:
+ description: Duration in ms of the active portion of the echo pulse.
+
+ assert-falling-edge:
+ description: Indicates a falling edge assert, when present. Rising edge if absent.
+ type: boolean
+
+required:
+ - compatible
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ pps {
+ compatible = "pps-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pps>;
+ gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ assert-falling-edge;
+ echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+ echo-active-ms = <100>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
index fe603fb..2162f66 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
@@ -20,12 +20,17 @@
properties:
compatible:
- enum:
- - samsung,s3c2410-pwm # 16-bit, S3C24xx
- - samsung,s3c6400-pwm # 32-bit, S3C64xx
- - samsung,s5p6440-pwm # 32-bit, S5P64x0
- - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs
- - samsung,exynos4210-pwm # 32-bit, Exynos
+ oneOf:
+ - enum:
+ - samsung,s3c2410-pwm # 16-bit, S3C24xx
+ - samsung,s3c6400-pwm # 32-bit, S3C64xx
+ - samsung,s5p6440-pwm # 32-bit, S5P64x0
+ - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs
+ - samsung,exynos4210-pwm # 32-bit, Exynos
+ - items:
+ - enum:
+ - samsung,exynosautov9-pwm
+ - const: samsung,exynos4210-pwm
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
index 9aabdb3..4d0b596 100644
--- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
+++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
@@ -18,7 +18,7 @@
The IP block has a version register so this can be used for detection
instead of having to encode the IP version number in the device tree
- comaptible.
+ compatible.
allOf:
- $ref: pwm.yaml#
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
index 3725348..02f45b5 100644
--- a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
@@ -28,75 +28,37 @@
the VSEL pin is assumed to be low.
type: boolean
+ inl1-supply:
+ description: Handle to the INL1 input supply (REG5-7)
+
+ inl2-supply:
+ description: Handle to the INL2 input supply (REG8-9)
+
+ inl3-supply:
+ description: Handle to the INL3 input supply (REG10-12)
+
+ vp1-supply:
+ description: Handle to the VP1 input supply (REG1)
+
+ vp2-supply:
+ description: Handle to the VP2 input supply (REG2)
+
+ vp3-supply:
+ description: Handle to the VP3 input supply (REG3)
+
+ vp4-supply:
+ description: Handle to the VP4 input supply (REG4)
+
regulators:
type: object
additionalProperties: false
- properties:
- REG1:
- type: object
- $ref: /schemas/regulator/regulator.yaml#
- unevaluatedProperties: false
-
- properties:
- vp1-supply:
- description: Handle to the VP1 input supply
-
- REG2:
- type: object
- $ref: /schemas/regulator/regulator.yaml#
- unevaluatedProperties: false
-
- properties:
- vp2-supply:
- description: Handle to the VP2 input supply
-
- REG3:
- type: object
- $ref: /schemas/regulator/regulator.yaml#
- unevaluatedProperties: false
-
- properties:
- vp3-supply:
- description: Handle to the VP3 input supply
-
- REG4:
- type: object
- $ref: /schemas/regulator/regulator.yaml#
- unevaluatedProperties: false
-
- properties:
- vp4-supply:
- description: Handle to the VP4 input supply
-
patternProperties:
- "^REG[5-7]$":
+ "^REG([1-9]|1[0-2])$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
- properties:
- inl1-supply:
- description: Handle to the INL1 input supply
-
- "^REG[8-9]$":
- type: object
- $ref: /schemas/regulator/regulator.yaml#
- unevaluatedProperties: false
-
- properties:
- inl2-supply:
- description: Handle to the INL2 input supply
-
- "^REG1[0-2]$":
- type: object
- $ref: /schemas/regulator/regulator.yaml#
- unevaluatedProperties: false
-
- properties:
- inl3-supply:
- description: Handle to the INL3 input supply
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/regulator/adi,max77857.yaml b/Documentation/devicetree/bindings/regulator/adi,max77857.yaml
new file mode 100644
index 0000000..d1fa74a
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/adi,max77857.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2022 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/adi,max77857.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX77857 Buck-Boost Converter
+
+maintainers:
+ - Ibrahim Tilki <Ibrahim.Tilki@analog.com>
+ - Okan Sahin <Okan.Sahin@analog.com>
+
+description: Analog Devices MAX77857 Buck-Boost Converter
+
+properties:
+ compatible:
+ enum:
+ - adi,max77831
+ - adi,max77857
+ - adi,max77859
+ - adi,max77859a
+
+ reg:
+ description: I2C address of the device
+ items:
+ - enum: [0x66, 0x67, 0x6E, 0x6F]
+
+ interrupts:
+ maxItems: 1
+
+ adi,switch-frequency-hz:
+ description: Switching frequency of the Buck-Boost converter in Hz.
+ items:
+ - enum: [1200000, 1500000, 1800000, 2100000]
+
+ adi,rtop-ohms:
+ description: Top feedback resistor value in ohms for external feedback.
+ minimum: 150000
+ maximum: 330000
+
+ adi,rbot-ohms:
+ description: Bottom feedback resistor value in ohms for external feedback.
+
+dependencies:
+ adi,rtop-ohms: [ 'adi,rbot-ohms' ]
+ adi,rbot-ohms: [ 'adi,rtop-ohms' ]
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: regulator.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,max77831
+
+ then:
+ properties:
+ adi,switch-frequency-hz:
+ items:
+ enum: [1200000, 1500000, 1800000]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@66 {
+ reg = <0x66>;
+ compatible = "adi,max77857";
+ interrupt-parent = <&gpio>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,rtop-ohms = <312000>;
+ adi,rbot-ohms = <12000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml b/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml
new file mode 100644
index 0000000..c92a881
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/awinic,aw37503.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW37503 Voltage Regulator
+
+maintainers:
+ - Alec Li <like@awinic.com>
+
+description:
+ The AW37503 are dual voltage regulator, designed to support positive/negative
+ supply for driving TFT-LCD panels. It support software-configurable output
+ switching and monitoring. The output voltages can be programmed via an I2C
+ compatible interface.
+
+properties:
+ compatible:
+ const: awinic,aw37503
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^out[pn]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single regulator.
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier to enable the GPIO control (on/off) for regulator.
+
+ required:
+ - regulator-name
+
+required:
+ - compatible
+ - reg
+ - outp
+ - outn
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@3e {
+ compatible = "awinic,aw37503";
+ reg = <0x3e>;
+
+ outp {
+ regulator-name = "outp";
+ regulator-boot-on;
+ regulator-always-on;
+ enable-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ };
+
+ outn {
+ regulator-name = "outn";
+ regulator-boot-on;
+ regulator-always-on;
+ enable-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
index dc62651..13b3f75 100644
--- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
+++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
@@ -95,11 +95,6 @@
Properties for a single BUCK regulator
properties:
- regulator-name:
- pattern: "^BUCK([1-2])$"
- description: |
- BUCK2 present in DA9122, DA9220, DA9131, DA9132 only
-
regulator-initial-mode:
enum: [ 0, 1, 2, 3 ]
description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
@@ -122,6 +117,23 @@
- reg
- regulators
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - dlg,da9122
+ - dlg,da9131
+ - dlg,da9132
+ - dlg,da9220
+ then:
+ properties:
+ regulators:
+ properties:
+ buck2: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml b/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml
new file mode 100644
index 0000000..bad1404
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/dlg,slg51000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor SLG51000 Voltage Regulator
+
+maintainers:
+ - Eric Jeong <eric.jeong.opensource@diasemi.com>
+ - Support Opensource <support.opensource@diasemi.com>
+
+properties:
+ compatible:
+ const: dlg,slg51000
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dlg,cs-gpios:
+ maxItems: 1
+ description:
+ GPIO for chip select
+
+ vin3-supply:
+ description:
+ Input supply for ldo3, required if regulator is enabled
+
+ vin4-supply:
+ description:
+ Input supply for ldo4, required if regulator is enabled
+
+ vin5-supply:
+ description:
+ Input supply for ldo5, required if regulator is enabled
+
+ vin6-supply:
+ description:
+ Input supply for ldo6, required if regulator is enabled
+
+ vin7-supply:
+ description:
+ Input supply for ldo7, required if regulator is enabled
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^ldo[1-7]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+
+ required:
+ - regulator-name
+
+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@75 {
+ compatible = "dlg,slg51000";
+ reg = <0x75>;
+ dlg,cs-gpios = <&tlmm 69 GPIO_ACTIVE_HIGH>;
+ vin5-supply = <&vreg_s1f_1p2>;
+ vin6-supply = <&vreg_s1f_1p2>;
+
+ regulators {
+ ldo1 {
+ regulator-name = "slg51000_b_ldo1";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo2 {
+ regulator-name = "slg51000_b_ldo2";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo3 {
+ regulator-name = "slg51000_b_ldo3";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ };
+
+ ldo4 {
+ regulator-name = "slg51000_b_ldo4";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ };
+
+ ldo5 {
+ regulator-name = "slg51000_b_ldo5";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ ldo6 {
+ regulator-name = "slg51000_b_ldo6";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ ldo7 {
+ regulator-name = "slg51000_b_ldo7";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
index 2e720d1..0221397 100644
--- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
+++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
@@ -29,10 +29,12 @@
patternProperties:
"^buck[1-4]$":
$ref: regulator.yaml#
+ unevaluatedProperties: false
type: object
"^ldo[1-4]$":
$ref: regulator.yaml#
+ unevaluatedProperties: false
type: object
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
index f3fcfc8..6de5b02 100644
--- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
+++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
@@ -21,7 +21,6 @@
regulators:
type: object
- $ref: regulator.yaml#
description: |
list of regulators provided by this controller, must be named
@@ -39,11 +38,13 @@
ldortc:
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
patternProperties:
"^ldo[1-4]$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
"^buck[1-4]$":
type: object
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml
index e384e49..0eda447 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml
@@ -68,18 +68,22 @@
"^sw([1-4]|[1-4][a-c]|[1-4][a-c][a-c])$":
$ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
"^vgen[1-6]$":
$ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
"^vldo[1-4]$":
$ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
"^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$":
$ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
index 8a08698..b4eb400 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
@@ -49,7 +49,7 @@
".*-supply$":
description: Input supply phandle(s) for this node
- "^((s|l|lvs)[0-9]*)|(s[1-2][a-b])|(ncp)|(mvs)|(usb-switch)|(hdmi-switch)$":
+ "^((s|l|lvs)[0-9]*|s[1-2][a-b]|ncp|mvs|usb-switch|hdmi-switch)$":
description: List of regulators and its properties
$ref: regulator.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
index b949850..127a6f3 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
@@ -53,6 +53,7 @@
For PMR735A, smps1 - smps3, ldo1 - ldo7
For PMX55, smps1 - smps7, ldo1 - ldo16
For PMX65, smps1 - smps8, ldo1 - ldo21
+ For PMX75, smps1 - smps10, ldo1 - ldo21
properties:
compatible:
@@ -84,13 +85,14 @@
- qcom,pmr735a-rpmh-regulators
- qcom,pmx55-rpmh-regulators
- qcom,pmx65-rpmh-regulators
+ - qcom,pmx75-rpmh-regulators
qcom,pmic-id:
description: |
RPMh resource name suffix used for the regulators found
on this PMIC.
$ref: /schemas/types.yaml#/definitions/string
- enum: [a, b, c, d, e, f, g, h, k]
+ enum: [a, b, c, d, e, f, g, h, i, j, k, l, m, n]
qcom,always-wait-for-ack:
description: |
@@ -109,6 +111,7 @@
bob:
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
description: BOB regulator node.
dependencies:
regulator-allow-set-load: [ regulator-allowed-modes ]
@@ -117,6 +120,7 @@
"^(smps|ldo|lvs|bob)[0-9]+$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
description: smps/ldo regulator nodes(s).
dependencies:
regulator-allow-set-load: [ regulator-allowed-modes ]
@@ -424,10 +428,28 @@
vdd-l11-l13-supply: true
patternProperties:
"^vdd-l[1347]-supply$": true
- "^vdd-l1[0245789]-supply$": true
+ "^vdd-l1[024579]-supply$": true
"^vdd-l2[01]-supply$": true
"^vdd-s[1-8]-supply$": true
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,pmx75-rpmh-regulators
+ then:
+ properties:
+ vdd-l2-l18-supply: true
+ vdd-l4-l16-supply: true
+ vdd-l5-l6-supply: true
+ vdd-l8-l9-supply: true
+ vdd-l11-l13-supply: true
+ vdd-l20-l21-supply: true
+ patternProperties:
+ "^vdd-l[137]-supply$": true
+ "^vdd-l1[024579]-supply$": true
+ "^vdd-s([1-9]|10)-supply$": true
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
new file mode 100644
index 0000000..f02f97d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. REFGEN Regulator
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The REFGEN (reference voltage generator) regulator provides reference
+ voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sc7180-refgen-regulator
+ - qcom,sc8180x-refgen-regulator
+ - qcom,sm8150-refgen-regulator
+ - const: qcom,sdm845-refgen-regulator
+
+ - items:
+ - enum:
+ - qcom,sc7280-refgen-regulator
+ - qcom,sc8280xp-refgen-regulator
+ - qcom,sm6350-refgen-regulator
+ - qcom,sm6375-refgen-regulator
+ - qcom,sm8350-refgen-regulator
+ - const: qcom,sm8250-refgen-regulator
+
+ - enum:
+ - qcom,sdm845-refgen-regulator
+ - qcom,sm8250-refgen-regulator
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ regulator@162f000 {
+ compatible = "qcom,sm8250-refgen-regulator";
+ reg = <0x0162f000 0x84>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
index a8ca8e0..9ea8ac0 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
@@ -110,6 +110,7 @@
"^((s|l|lvs|5vs)[0-9]*)|(boost-bypass)|(bob)$":
description: List of regulators and its properties
$ref: regulator.yaml#
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
index 1c4bfe7..bcf7888 100644
--- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
@@ -35,7 +35,7 @@
nodes is defined using the standard binding for regulators found at
<Documentation/devicetree/bindings/regulator/regulator.txt>.
-Theres are also additional properties for SD/LDOs. These additional properties
+There are also additional properties for SD/LDOs. These additional properties
are required to configure FPS configuration parameters for SDs and LDOs.
Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible
Power Sequence (FPS).
diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml
index e158c2d..9daf0fc 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/regulator.yaml
@@ -126,7 +126,7 @@
regulator-oc-error-microamp:
description: Set over current error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested.
+ the hardware probably is malfunctional and damage prevention is requested.
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted.
@@ -146,7 +146,7 @@
regulator-ov-error-microvolt:
description: Set over voltage error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested
+ the hardware probably is malfunctional and damage prevention is requested
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted. Limit
is given as microvolt offset from voltage set to regulator.
@@ -168,7 +168,7 @@
regulator-uv-error-microvolt:
description: Set under voltage error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested
+ the hardware probably is malfunctional and damage prevention is requested
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted. Limit
is given as microvolt offset from voltage set to regulator.
@@ -189,7 +189,7 @@
regulator-temp-error-kelvin:
description: Set over temperature error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested
+ the hardware probably is malfunctional and damage prevention is requested
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted.
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml
index d9c2333..cd06e95 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml
@@ -29,6 +29,7 @@
"^DSV(LCM|P|N)$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
description:
Properties for single Display Bias Voltage regulator.
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml
index edb411b..89341fd 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml
@@ -11,7 +11,7 @@
description: |
The RT5190A integrates 1 channel buck controller, 3 channels high efficiency
- synchronous buck converters, 1 LDO, I2C control interface and peripherial
+ synchronous buck converters, 1 LDO, I2C control interface and peripheral
logical control.
It also supports mute AC OFF depop sound and quick setting storage while
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
index 358297d..e95e046 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
@@ -21,6 +21,7 @@
properties:
compatible:
enum:
+ - richtek,rt5733
- richtek,rt5739
reg:
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml
index 446ec51..fec3d39 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml
@@ -121,6 +121,7 @@
description: load switch current regulator description.
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
new file mode 100644
index 0000000..609c066
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -0,0 +1,197 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rtq2208.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RTQ2208 SubPMIC Regulator
+
+maintainers:
+ - Alina Yu <alina_yu@richtek.com>
+
+description: |
+ RTQ2208 is a highly integrated power converter that offers functional safety dual
+ multi-configurable synchronous buck converters and two LDOs.
+
+ Bucks support "regulator-allowed-modes" and "regulator-mode". The former defines the permitted
+ switching operation in normal mode; the latter defines the operation in suspend to RAM mode.
+
+ No matter the RTQ2208 is configured to normal or suspend to RAM mode, there are two switching
+ operation modes for all buck rails, automatic power saving mode (Auto mode) and forced continuous
+ conduction mode (FCCM).
+
+ The definition of modes is in the datasheet which is available in below link
+ and their meaning is::
+ 0 - Auto mode for power saving, which reducing the switching frequency at light load condition
+ to maintain high frequency.
+ 1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
+
+ Datasheet will be available soon at
+ https://www.richtek.com/assets/Products
+
+properties:
+ compatible:
+ enum:
+ - richtek,rtq2208
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ richtek,mtp-sel-high:
+ type: boolean
+ description:
+ vout register selection based on this boolean value.
+ false - Using DVS0 register setting to adjust vout
+ true - Using DVS1 register setting to adjust vout
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^buck-[a-h]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ description for buck-[a-h] regulator.
+
+ properties:
+ regulator-allowed-modes:
+ description:
+ two buck modes in different switching accuracy.
+ 0 - Auto mode
+ 1 - FCCM
+ items:
+ enum: [0, 1]
+
+ "^ldo[1-2]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ regulator description for ldo[1-2].
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@10 {
+ compatible = "richtek,rtq2208";
+ reg = <0x10>;
+ interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
+ richtek,mtp-sel-high;
+
+ regulators {
+ buck-a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-c {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-d {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-e {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-f {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-g {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-h {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ ldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ ldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml
index e6e5a9a..ef62c61 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml
@@ -35,6 +35,7 @@
"^(p|n)avdd$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
description: |
regulator description for pavdd and navdd.
diff --git a/Documentation/devicetree/bindings/regulator/slg51000.txt b/Documentation/devicetree/bindings/regulator/slg51000.txt
deleted file mode 100644
index aa0733e..0000000
--- a/Documentation/devicetree/bindings/regulator/slg51000.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-* Dialog Semiconductor SLG51000 Voltage Regulator
-
-Required properties:
-- compatible : Should be "dlg,slg51000" for SLG51000
-- reg : Specifies the I2C slave address.
-- xxx-supply: Input voltage supply regulator for ldo3 to ldo7.
- These entries are required if regulators are enabled for a device.
- An absence of these properties can cause the regulator registration to fail.
- If some of input supply is powered through battery or always-on supply then
- also it is required to have these parameters with proper node handle of always
- on power supply.
- vin3-supply: Input supply for ldo3
- vin4-supply: Input supply for ldo4
- vin5-supply: Input supply for ldo5
- vin6-supply: Input supply for ldo6
- vin7-supply: Input supply for ldo7
-
-Optional properties:
-- interrupt-parent : Specifies the reference to the interrupt controller.
-- interrupts : IRQ line information.
-- dlg,cs-gpios : Specify a valid GPIO for chip select
-
-Sub-nodes:
-- regulators : This node defines the settings for the regulators.
- The content of the sub-node is defined by the standard binding
- for regulators; see regulator.txt.
-
- The SLG51000 regulators are bound using their names listed below:
- ldo1
- ldo2
- ldo3
- ldo4
- ldo5
- ldo6
- ldo7
-
-Optional properties for regulators:
-- enable-gpios : Specify a valid GPIO for platform control of the regulator.
-
-Example:
- pmic: slg51000@75 {
- compatible = "dlg,slg51000";
- reg = <0x75>;
-
- regulators {
- ldo1 {
- regulator-name = "ldo1";
- regulator-min-microvolt = <2400000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo2 {
- regulator-name = "ldo2";
- regulator-min-microvolt = <2400000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo3 {
- regulator-name = "ldo3";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- };
-
- ldo4 {
- regulator-name = "ldo4";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- };
-
- ldo5 {
- regulator-name = "ldo5";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1200000>;
- };
-
- ldo6 {
- regulator-name = "ldo6";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1200000>;
- };
-
- ldo7 {
- regulator-name = "ldo7";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
index 7d53cfa..c9586d2 100644
--- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
+++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
@@ -25,8 +25,8 @@
patternProperties:
"^(reg11|reg18|usb33)$":
type: object
-
$ref: regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/regulator/vctrl.txt b/Documentation/devicetree/bindings/regulator/vctrl.txt
index 601328d..e940377 100644
--- a/Documentation/devicetree/bindings/regulator/vctrl.txt
+++ b/Documentation/devicetree/bindings/regulator/vctrl.txt
@@ -21,7 +21,7 @@
margin from the expected value for a given control
voltage. On larger voltage decreases this can occur
undesiredly since the output voltage does not adjust
- inmediately to changes in the control voltage. To
+ immediately to changes in the control voltage. To
avoid this situation the vctrl driver breaks down
larger voltage decreases into multiple steps, where
each step is within the OVP threshold.
diff --git a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
index 011819c..11e3786 100644
--- a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
+++ b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
@@ -29,11 +29,13 @@
Initial data for the LDO1 regulator.
$ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
micvdd:
description:
Initial data for the MICVDD regulator.
$ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 0c3910f..30632ef 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -20,7 +20,9 @@
- fsl,imx7ulp-cm4
- fsl,imx8mm-cm4
- fsl,imx8mn-cm7
+ - fsl,imx8mn-cm7-mmio
- fsl,imx8mp-cm7
+ - fsl,imx8mp-cm7-mmio
- fsl,imx8mq-cm4
- fsl,imx8qm-cm4
- fsl,imx8qxp-cm4
@@ -70,6 +72,11 @@
description:
Specify CPU entry address for SCU enabled processor.
+ fsl,iomuxc-gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to IOMUXC GPR block which provide access to CM7 CPUWAIT bit.
+
fsl,resource-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -79,6 +86,19 @@
required:
- compatible
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - fsl,imx8mn-cm7-mmio
+ - fsl,imx8mp-cm7-mmio
+ then:
+ properties:
+ fsl,iomuxc-gpr: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
index 643ee78..a2b0079 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
@@ -26,6 +26,7 @@
- qcom,sdm660-adsp-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
+ - qcom,sdm845-slpi-pas
reg:
maxItems: 1
@@ -44,8 +45,13 @@
maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
required:
- compatible
+ - memory-region
unevaluatedProperties: false
@@ -63,6 +69,7 @@
- qcom,msm8998-adsp-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
+ - qcom,sdm845-slpi-pas
then:
properties:
clocks:
@@ -104,6 +111,7 @@
- qcom,msm8998-slpi-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
+ - qcom,sdm845-slpi-pas
then:
properties:
interrupts:
@@ -160,6 +168,22 @@
- if:
properties:
compatible:
+ enum:
+ - qcom,sdm845-slpi-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
contains:
enum:
- qcom,msm8226-adsp-pil
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
index 7b43ad3..e78a89c 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
@@ -14,9 +14,6 @@
related to the remote processor.
properties:
- $nodename:
- const: glink-edge
-
apr:
$ref: /schemas/soc/qcom/qcom,apr.yaml#
required:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
index f5a044e..884158b 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
@@ -84,7 +84,7 @@
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- rpm-glink {
+ glink-edge {
compatible = "qcom,glink-rpm";
interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
mboxes = <&apcs_glb 0>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
index c1ac6ca..0643faa 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
@@ -19,6 +19,7 @@
enum:
- qcom,msm8996-mss-pil
- qcom,msm8998-mss-pil
+ - qcom,sdm660-mss-pil
- qcom,sdm845-mss-pil
reg:
@@ -215,13 +216,12 @@
- description: GCC MSS IFACE clock
- description: GCC MSS BUS clock
- description: GCC MSS MEM clock
- - description: RPMH XO clock
+ - description: RPM XO clock
- description: GCC MSS GPLL0 clock
- description: GCC MSS SNOC_AXI clock
- description: GCC MSS MNOC_AXI clock
- - description: RPMH PNOC clock
- - description: GCC MSS PRNG clock
- - description: RPMH QDSS clock
+ - description: RPM PNOC clock
+ - description: RPM QDSS clock
clock-names:
items:
- const: iface
@@ -245,7 +245,9 @@
- if:
properties:
compatible:
- const: qcom,msm8998-mss-pil
+ enum:
+ - qcom,msm8998-mss-pil
+ - qcom,sdm660-mss-pil
then:
properties:
clocks:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
index 171ef85..63a82e7 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -82,7 +82,6 @@
- clock-names
- interrupts
- interrupt-names
- - memory-region
- qcom,smem-states
- qcom,smem-state-names
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
index 5efa0e5..eb868a7 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
@@ -42,7 +42,7 @@
smd-edge: false
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
@@ -52,6 +52,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
new file mode 100644
index 0000000..7afafde
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,rpm-proc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Resource Power Manager (RPM) Processor/Subsystem
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+ - Stephan Gerhold <stephan@gerhold.net>
+
+description: |
+ Resource Power Manager (RPM) subsystem found in various Qualcomm platforms:
+
+ +--------------------------------------------+
+ | RPM subsystem (qcom,rpm-proc) |
+ | |
+ reset | +---------------+ +-----+ +-----+ |
+ --------->| | | MPM | | CPR | ... |
+ IPC interrupts | | ARM Cortex-M3 |--- +-----+ +-----+ |
+ ----------------->| | | | | |
+ | +---------------+ |---------------------- |
+ | +---------------+ | |
+ | | Code RAM |--| +------------------+ |
+ | +---------------+ | | | |
+ | +---------------+ |--| Message RAM | |
+ | | Data RAM |--| | | |
+ | +---------------+ | +------------------+ |
+ +--------------------|-----------------------+
+ v
+ NoC
+
+ The firmware running on the processor inside the RPM subsystem allows each
+ component in the system to vote for state of the system resources, such as
+ clocks, regulators and bus frequencies. It implements multiple separate
+ communication interfaces that are described in subnodes, e.g. SMD and MPM:
+
+ +------------------------------+
+ | ARM Cortex-M3 |
+ | | +------------------------------+
+ | +--------------------------+ | | Message RAM |
+ | | RPM firmware | | | |
+ IPC IRQ 0 | | +----------------------+ | | | +--------------------------+ |
+ -------------->| SMD server |<------->| SMD data structures | |
+ | | | +--------------+ | | | | | +--------------+ | |
+ | | | | rpm_requests | ... | | | | | | rpm_requests | ... | |
+ | | | +--------------+ | | | | | +--------------+ | |
+ IPC IRQ 1 | | +----------------------+ | | | +--------------------------+ |
+ -------------->| MPM virtualization |<--------| MPM register copy (vMPM) | |
+ | | +----------------------+ | | | +--------------------------+ |
+ | | ... | | | | ... |
+ | +--------------------|-----+ | +------------------------------+
+ +----------------------|-------+
+ v
+ +--------------+
+ | MPM Hardware |
+ +--------------+
+
+ The services provided by the firmware are only available after the firmware
+ has been loaded and the processor has been released from reset. Usually this
+ happens early in the boot process before the operating system is started.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,apq8084-rpm-proc
+ - qcom,ipq6018-rpm-proc
+ - qcom,ipq9574-rpm-proc
+ - qcom,mdm9607-rpm-proc
+ - qcom,msm8226-rpm-proc
+ - qcom,msm8610-rpm-proc
+ - qcom,msm8909-rpm-proc
+ - qcom,msm8916-rpm-proc
+ - qcom,msm8917-rpm-proc
+ - qcom,msm8936-rpm-proc
+ - qcom,msm8937-rpm-proc
+ - qcom,msm8952-rpm-proc
+ - qcom,msm8953-rpm-proc
+ - qcom,msm8974-rpm-proc
+ - qcom,msm8976-rpm-proc
+ - qcom,msm8994-rpm-proc
+ - qcom,msm8996-rpm-proc
+ - qcom,msm8998-rpm-proc
+ - qcom,qcm2290-rpm-proc
+ - qcom,qcs404-rpm-proc
+ - qcom,sdm660-rpm-proc
+ - qcom,sm6115-rpm-proc
+ - qcom,sm6125-rpm-proc
+ - qcom,sm6375-rpm-proc
+ - const: qcom,rpm-proc
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the RPM subsystem.
+
+ glink-edge:
+ $ref: /schemas/remoteproc/qcom,glink-rpm-edge.yaml#
+ description:
+ Qualcomm G-Link subnode which represents communication edge,
+ channels and devices related to the RPM subsystem.
+
+ interrupt-controller:
+ type: object
+ $ref: /schemas/interrupt-controller/qcom,mpm.yaml#
+ description:
+ MSM Power Manager (MPM) interrupt controller that monitors interrupts
+ when the system is asleep.
+
+ master-stats:
+ $ref: /schemas/soc/qcom/qcom,rpm-master-stats.yaml#
+ description:
+ Subsystem-level low-power mode statistics provided by RPM.
+
+required:
+ - compatible
+
+oneOf:
+ - required:
+ - smd-edge
+ - required:
+ - glink-edge
+
+additionalProperties: false
+
+examples:
+ # SMD
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ remoteproc {
+ compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc";
+
+ smd-edge {
+ interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-msm8916";
+ qcom,smd-channels = "rpm_requests";
+ /* ... */
+ };
+ };
+ };
+ # GLINK
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ remoteproc {
+ compatible = "qcom,qcm2290-rpm-proc", "qcom,rpm-proc";
+
+ glink-edge {
+ compatible = "qcom,glink-rpm";
+ interrupts = <GIC_SPI 194 IRQ_TYPE_EDGE_RISING>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+ mboxes = <&apcs_glb 0>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-qcm2290";
+ qcom,glink-channels = "rpm_requests";
+ /* ... */
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
index 5cefd2c..689d5d5 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
@@ -51,7 +51,7 @@
- const: mss
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
qcom,qmp:
@@ -67,6 +67,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml
index c1f8dd8..4744a37 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml
@@ -38,7 +38,7 @@
smd-edge: false
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
@@ -48,6 +48,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
index f6fbc53..96d53ba 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
@@ -38,7 +38,7 @@
smd-edge: false
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
@@ -48,6 +48,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
index c66e298..5d46327 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
@@ -46,7 +46,7 @@
- const: mss
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
qcom,qmp:
@@ -62,6 +62,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
index f5d1fa9..0282872 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
@@ -15,10 +15,19 @@
properties:
compatible:
- enum:
- - qcom,sm6115-adsp-pas
- - qcom,sm6115-cdsp-pas
- - qcom,sm6115-mpss-pas
+ oneOf:
+ - enum:
+ - qcom,sm6115-adsp-pas
+ - qcom,sm6115-cdsp-pas
+ - qcom,sm6115-mpss-pas
+
+ - items:
+ - const: qcom,qcm2290-adsp-pas
+ - const: qcom,sm6115-adsp-pas
+
+ - items:
+ - const: qcom,qcm2290-mpss-pas
+ - const: qcom,sm6115-mpss-pas
reg:
maxItems: 1
@@ -32,7 +41,7 @@
- const: xo
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
smd-edge: false
@@ -44,15 +53,17 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
- if:
properties:
compatible:
- enum:
- - qcom,sm6115-adsp-pas
- - qcom,sm6115-cdsp-pas
+ contains:
+ enum:
+ - qcom,sm6115-adsp-pas
+ - qcom,sm6115-cdsp-pas
then:
properties:
interrupts:
@@ -69,9 +80,10 @@
- if:
properties:
compatible:
- enum:
- - qcom,sm6115-cdsp-pas
- - qcom,sm6115-mpss-pas
+ contains:
+ enum:
+ - qcom,sm6115-cdsp-pas
+ - qcom,sm6115-mpss-pas
then:
properties:
power-domains:
@@ -84,8 +96,9 @@
- if:
properties:
compatible:
- enum:
- - qcom,sm6115-adsp-pas
+ contains:
+ enum:
+ - qcom,sm6115-adsp-pas
then:
properties:
power-domains:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
index fee02fa..f7e40fb 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
@@ -36,7 +36,7 @@
description: Reference to the AOSS side-channel message RAM.
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
smd-edge: false
@@ -48,6 +48,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
index 2c085ac..238c6e5 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
@@ -40,7 +40,7 @@
description: Reference to the AOSS side-channel message RAM.
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
smd-edge: false
@@ -52,6 +52,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
index af24f9a..53cea8e 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
@@ -43,7 +43,7 @@
smd-edge: false
memory-region:
- minItems: 1
+ maxItems: 1
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
@@ -53,6 +53,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
@@ -139,7 +140,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
remoteproc@30000000 {
compatible = "qcom,sm8450-adsp-pas";
@@ -160,8 +161,8 @@
memory-region = <&adsp_mem>;
- power-domains = <&rpmhpd SM8450_LCX>,
- <&rpmhpd SM8450_LMX>;
+ power-domains = <&rpmhpd RPMHPD_LCX>,
+ <&rpmhpd RPMHPD_LMX>;
power-domain-names = "lcx", "lmx";
qcom,qmp = <&aoss_qmp>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
index fe216aa..5812082 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -53,6 +53,7 @@
required:
- compatible
- reg
+ - memory-region
allOf:
- $ref: /schemas/remoteproc/qcom,pas-common.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index f16e903..9768db8 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
index fcc3db9..a492f74 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,k3-r5f-rproc.yaml#
@@ -102,7 +102,7 @@
caches. Each of the TCMs can be enabled or disabled independently and
either of them can be configured to appear at that R5F's address 0x0.
- The cores do not use an MMU, but has a Region Address Translater
+ The cores do not use an MMU, but has a Region Address Translator
(RAT) module that is accessible only from the R5Fs for providing
translations between 32-bit CPU addresses into larger system bus
addresses. Cache and memory access settings are provided through a
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
index 1fdc274..94eb203 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
index 35f0bb3..2811334 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
index cd55d80..baccd98 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,pru-rproc.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
index 9f67736..78aac69 100644
--- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/xlnx,zynqmp-r5fss.yaml#
diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
new file mode 100644
index 0000000..f9b2f0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tegra CPU-NS - BPMP IPC reserved memory
+
+maintainers:
+ - Peter De Schrijver <pdeschrijver@nvidia.com>
+
+description: |
+ Define a memory region used for communication between CPU-NS and BPMP.
+ Typically this node is created by the bootloader as the physical address
+ has to be known to both CPU-NS and BPMP for correct IPC operation.
+ The memory region is defined using a child node under /reserved-memory.
+ The sub-node is named shmem@<address>.
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+ const: nvidia,tegra264-bpmp-shmem
+
+ reg:
+ description: The physical address and size of the shared SDRAM region
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - no-map
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dram_cpu_bpmp_mail: shmem@f1be0000 {
+ compatible = "nvidia,tegra264-bpmp-shmem";
+ reg = <0x0 0xf1be0000 0x0 0x2000>;
+ no-map;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
index 4379cec..761c70c 100644
--- a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
+++ b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
@@ -7,7 +7,7 @@
title: Altera SOCFPGA Reset Manager
maintainers:
- - Dinh Nguyen <dinguyen@altera.com>
+ - Dinh Nguyen <dinguyen@kernel.org>
properties:
compatible:
@@ -32,9 +32,17 @@
required:
- compatible
- reg
- - altr,modrst-offset
- '#reset-cells'
+if:
+ properties:
+ compatible:
+ contains:
+ const: altr,stratix10-rst-mgr
+then:
+ properties:
+ altr,modrst-offset: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
index dcf9206e..e10eb98 100644
--- a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml#
diff --git a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml
index f436f2c..6063784 100644
--- a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/reset/ti,tps380x-reset.yaml#
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 8694550..61a0ff3 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -43,7 +43,7 @@
Cell #6 : bit position of the reset in the
reset status register
Cell #7 : Flags used to control reset behavior,
- availible flags defined in the DT include
+ available flags defined in the DT include
file <dt-bindings/reset/ti-syscon.h>
SysCon Reset Consumer Nodes
diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
index 0d50f6a..49db668 100644
--- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
@@ -32,6 +32,7 @@
enum:
- xlnx,zynqmp-reset
- xlnx,versal-reset
+ - xlnx,versal-net-reset
"#reset-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml
index e62f682..301912d 100644
--- a/Documentation/devicetree/bindings/riscv/thead.yaml
+++ b/Documentation/devicetree/bindings/riscv/thead.yaml
@@ -17,6 +17,10 @@
const: '/'
compatible:
oneOf:
+ - description: BeagleV Ahead single board computer
+ items:
+ - const: beagle,beaglev-ahead
+ - const: thead,th1520
- description: Sipeed Lichee Pi 4A board for the Sipeed Lichee Module 4A
items:
- enum:
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.yaml b/Documentation/devicetree/bindings/rng/omap_rng.yaml
index ccf54fa..c0ac4f6 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.yaml
+++ b/Documentation/devicetree/bindings/rng/omap_rng.yaml
@@ -30,8 +30,8 @@
clocks:
minItems: 1
items:
- - description: EIP150 gatable clock
- - description: Main gatable clock
+ - description: EIP150 gateable clock
+ - description: Main gateable clock
clock-names:
minItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
index b94b35f..7d7b5f6 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
@@ -10,7 +10,7 @@
- ctrl-reg : Contains the initial value of the control register also
called "Register B".
- freq-reg : Contains the initial value of the frequency register also
- called "Regsiter A".
+ called "Register A".
"Register A" and "B" are usually initialized by the firmware (BIOS for
instance). If this is not done, it can be performed by the driver.
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
index 01ec45b..2e189e5 100644
--- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
@@ -33,6 +33,7 @@
- amlogic,meson8b-uart
- amlogic,meson-gx-uart
- amlogic,meson-s4-uart
+ - amlogic,meson-a1-uart
- const: amlogic,meson-ao-uart
- description: Always-on power domain UART controller on G12A SoCs
items:
@@ -46,10 +47,15 @@
- amlogic,meson8b-uart
- amlogic,meson-gx-uart
- amlogic,meson-s4-uart
+ - amlogic,meson-a1-uart
- description: Everything-Else power domain UART controller on G12A SoCs
items:
- const: amlogic,meson-g12a-uart
- const: amlogic,meson-gx-uart
+ - description: UART controller on S4 compatible SoCs
+ items:
+ - const: amlogic,t7-uart
+ - const: amlogic,meson-s4-uart
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
index 9306240..3a5b59f 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
@@ -25,11 +25,15 @@
- fsl,imxrt1050-lpuart
- items:
- enum:
- - fsl,imx93-lpuart
- fsl,imx8ulp-lpuart
- const: fsl,imx7ulp-lpuart
- items:
- enum:
+ - fsl,imx93-lpuart
+ - const: fsl,imx8ulp-lpuart
+ - const: fsl,imx7ulp-lpuart
+ - items:
+ - enum:
- fsl,imx8qm-lpuart
- fsl,imx8dxl-lpuart
- const: fsl,imx8qxp-lpuart
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
deleted file mode 100644
index f709304..0000000
--- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver.
-
-Required properties:
-- compatible : should be,
- "nvidia,tegra20-hsuart" for Tegra20,
- "nvidia,tegra30-hsuart" for Tegra30,
- "nvidia,tegra186-hsuart" for Tegra186,
- "nvidia,tegra194-hsuart" for Tegra194.
-
-- reg: Should contain UART controller registers location and length.
-- interrupts: Should contain UART controller interrupts.
-- clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - serial
-- dmas : Must contain an entry for each entry in dma-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-
-Optional properties:
-- nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
- only if all 8 lines of UART controller are pinmuxed.
-- nvidia,adjust-baud-rates: List of entries providing percentage of baud rate
- adjustment within a range.
- Each entry contains sets of 3 values. Range low/high and adjusted rate.
- <range_low range_high adjusted_rate>
- When baud rate set on controller falls within the range mentioned in this
- field, baud rate will be adjusted by percentage mentioned here.
- Ex: <9600 115200 200>
- Increase baud rate by 2% when set baud rate falls within range 9600 to 115200
-
-Baud Rate tolerance:
- Standard UART devices are expected to have tolerance for baud rate error by
- -4 to +4 %. All Tegra devices till Tegra210 had this support. However,
- Tegra186 chip has a known hardware issue. UART Rx baud rate tolerance level
- is 0% to +4% in 1-stop config. Otherwise, the received data will have
- corruption/invalid framing errors. Parker errata suggests adjusting baud
- rate to be higher than the deviations observed in Tx.
-
- Tx deviation of connected device can be captured over scope (or noted from
- its spec) for valid range and Tegra baud rate has to be set above actual
- Tx baud rate observed. To do this we use nvidia,adjust-baud-rates
-
- As an example, consider there is deviation observed in Tx for baud rates as
- listed below.
- 0 to 9600 has 1% deviation
- 9600 to 115200 2% deviation
- This slight deviation is expcted and Tegra UART is expected to handle it. Due
- to the issue stated above, baud rate on Tegra UART should be set equal to or
- above deviation observed for avoiding frame errors.
- Property should be set like this
- nvidia,adjust-baud-rates = <0 9600 100>,
- <9600 115200 200>;
-
-Example:
-
-serial@70006000 {
- compatible = "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart";
- reg = <0x70006000 0x40>;
- reg-shift = <2>;
- interrupts = <0 36 0x04>;
- nvidia,enable-modem-interrupt;
- clocks = <&tegra_car 6>;
- resets = <&tegra_car 6>;
- reset-names = "serial";
- dmas = <&apbdma 8>, <&apbdma 8>;
- dma-names = "rx", "tx";
- nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */
-};
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml
new file mode 100644
index 0000000..04d55fec
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nvidia,tegra20-hsuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-hsuart
+ - nvidia,tegra30-hsuart
+ - nvidia,tegra186-hsuart
+ - nvidia,tegra194-hsuart
+ - items:
+ - const: nvidia,tegra124-hsuart
+ - const: nvidia,tegra30-hsuart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: serial
+
+ dmas:
+ items:
+ - description: DMA channel used for reception
+ - description: DMA channel used for transmission
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ nvidia,enable-modem-interrupt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enable modem interrupts. Should be enable only if all 8 lines of UART controller
+ are pinmuxed.
+
+ nvidia,adjust-baud-rates:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ List of entries providing percentage of baud rate adjustment within a range. Each entry
+ contains a set of 3 values: range low/high and adjusted rate. When the baud rate set on the
+ controller falls within the range mentioned in this field, the baud rate will be adjusted by
+ percentage mentioned here.
+
+ Example: <9600 115200 200>
+
+ Increase baud rate by 2% when set baud rate falls within range 9600 to 115200.
+
+ Standard UART devices are expected to have tolerance for baud rate error by -4 to +4 %. All
+ Tegra devices till Tegra210 had this support. However, Tegra186 chip has a known hardware
+ issue. UART RX baud rate tolerance level is 0% to +4% in 1-stop config. Otherwise, the
+ received data will have corruption/invalid framing errors. Parker errata suggests adjusting
+ baud rate to be higher than the deviations observed in TX.
+
+ TX deviation of connected device can be captured over scope (or noted from its spec) for
+ valid range and Tegra baud rate has to be set above actual TX baud rate observed. To do this
+ we use nvidia,adjust-baud-rates.
+
+ As an example, consider there is deviation observed in TX for baud rates as listed below. 0
+ to 9600 has 1% deviation 9600 to 115200 2% deviation. This slight deviation is expcted and
+ Tegra UART is expected to handle it. Due to the issue stated above, baud rate on Tegra UART
+ should be set equal to or above deviation observed for avoiding frame errors. Property
+ should be set like this:
+
+ nvidia,adjust-baud-rates = <0 9600 100>,
+ <9600 115200 200>;
+ items:
+ items:
+ - description: range lower bound
+ - description: range upper bound
+ - description: adjustment (in permyriad, i.e. 0.01%)
+
+allOf:
+ - $ref: serial.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ serial@70006000 {
+ compatible = "nvidia,tegra30-hsuart";
+ reg = <0x70006000 0x40>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,enable-modem-interrupt;
+ clocks = <&tegra_car TEGRA30_CLK_UARTA>;
+ resets = <&tegra_car 6>;
+ reset-names = "serial";
+ dmas = <&apbdma 8>, <&apbdma 8>;
+ dma-names = "rx", "tx";
+ nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */
+ };
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
index 0fa8e3e..1a7e4bf 100644
--- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
+++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
@@ -23,6 +23,9 @@
1 = active low.
- irda-mode-ports: An array that lists the indices of the port that
should operate in IrDA mode.
+- nxp,modem-control-line-ports: An array that lists the indices of the port that
+ should have shared GPIO lines configured as
+ modem control lines.
Example:
sc16is750: sc16is750@51 {
@@ -35,6 +38,26 @@
#gpio-cells = <2>;
};
+ sc16is752: sc16is752@53 {
+ compatible = "nxp,sc16is752";
+ reg = <0x53>;
+ clocks = <&clk20m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ nxp,modem-control-line-ports = <1>; /* Port 1 as modem control lines */
+ gpio-controller; /* Port 0 as GPIOs */
+ #gpio-cells = <2>;
+ };
+
+ sc16is752: sc16is752@54 {
+ compatible = "nxp,sc16is752";
+ reg = <0x54>;
+ clocks = <&clk20m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ nxp,modem-control-line-ports = <0 1>; /* Ports 0 and 1 as modem control lines */
+ };
+
* spi as bus
Required properties:
@@ -59,6 +82,9 @@
1 = active low.
- irda-mode-ports: An array that lists the indices of the port that
should operate in IrDA mode.
+- nxp,modem-control-line-ports: An array that lists the indices of the port that
+ should have shared GPIO lines configured as
+ modem control lines.
Example:
sc16is750: sc16is750@0 {
@@ -70,3 +96,23 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ sc16is752: sc16is752@1 {
+ compatible = "nxp,sc16is752";
+ reg = <1>;
+ clocks = <&clk20m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ nxp,modem-control-line-ports = <1>; /* Port 1 as modem control lines */
+ gpio-controller; /* Port 0 as GPIOs */
+ #gpio-cells = <2>;
+ };
+
+ sc16is752: sc16is752@2 {
+ compatible = "nxp,sc16is752";
+ reg = <2>;
+ clocks = <&clk20m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ nxp,modem-control-line-ports = <0 1>; /* Ports 0 and 1 as modem control lines */
+ };
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 3862411..17c5531 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -117,7 +117,6 @@
required:
- compatible
- reg
- - interrupts
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/serial/st-asc.txt b/Documentation/devicetree/bindings/serial/st-asc.txt
index 75d877f..a1b9b6f 100644
--- a/Documentation/devicetree/bindings/serial/st-asc.txt
+++ b/Documentation/devicetree/bindings/serial/st-asc.txt
@@ -8,7 +8,7 @@
Optional properties:
- st,hw-flow-ctrl bool flag to enable hardware flow control.
-- st,force-m1 bool flat to force asc to be in Mode-1 recommeded
+- st,force-m1 bool flat to force asc to be in Mode-1 recommended
for high bit rates (above 19.2K)
Example:
serial@fe440000{
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml
new file mode 100644
index 0000000..16977e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson System Control registers
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - amlogic,meson-gx-hhi-sysctrl
+ - amlogic,meson-gx-ao-sysctrl
+ - amlogic,meson-axg-hhi-sysctrl
+ - amlogic,meson-axg-ao-sysctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ type: object
+
+ power-controller:
+ $ref: /schemas/power/amlogic,meson-ee-pwrc.yaml
+
+ pinctrl:
+ type: object
+
+ phy:
+ type: object
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-hhi-sysctrl
+ - amlogic,meson-axg-hhi-sysctrl
+ then:
+ properties:
+ clock-controller:
+ $ref: /schemas/clock/amlogic,gxbb-clkc.yaml#
+
+ required:
+ - power-controller
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-ao-sysctrl
+ - amlogic,meson-axg-ao-sysctrl
+ then:
+ properties:
+ clock-controller:
+ $ref: /schemas/clock/amlogic,gxbb-aoclkc.yaml#
+
+ power-controller: false
+ phy: false
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-hhi-sysctrl
+ then:
+ properties:
+ phy: false
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-axg-hhi-sysctrl
+ then:
+ properties:
+ phy:
+ oneOf:
+ - $ref: /schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml
+ - $ref: /schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
+
+required:
+ - compatible
+ - reg
+ - clock-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ bus@c883c000 {
+ compatible = "simple-bus";
+ reg = <0xc883c000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xc883c000 0x2000>;
+
+ sysctrl: system-controller@0 {
+ compatible = "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon";
+ reg = <0 0x400>;
+
+ clock-controller {
+ compatible = "amlogic,gxbb-clkc";
+ #clock-cells = <1>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ };
+
+ power-controller {
+ compatible = "amlogic,meson-gxbb-pwrc";
+ #power-domain-cells = <1>;
+ amlogic,ao-sysctrl = <&sysctrl_AO>;
+
+ resets = <&reset_viu>,
+ <&reset_venc>,
+ <&reset_vcbus>,
+ <&reset_bt656>,
+ <&reset_dvin>,
+ <&reset_rdma>,
+ <&reset_venci>,
+ <&reset_vencp>,
+ <&reset_vdac>,
+ <&reset_vdi6>,
+ <&reset_vencl>,
+ <&reset_vid_lock>;
+ reset-names = "viu", "venc", "vcbus", "bt656", "dvin",
+ "rdma", "venci", "vencp", "vdac", "vdi6",
+ "vencl", "vid_lock";
+ clocks = <&clk_vpu>, <&clk_vapb>;
+ clock-names = "vpu", "vapb";
+ };
+ };
+ };
+
+ bus@c8100000 {
+ compatible = "simple-bus";
+ reg = <0xc8100000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xc8100000 0x100000>;
+
+ sysctrl_AO: system-controller@0 {
+ compatible = "amlogic,meson-gx-ao-sysctrl", "simple-mfd", "syscon";
+ reg = <0 0x100>;
+
+ clock-controller {
+ compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&xtal>, <&clk81>;
+ clock-names = "xtal", "mpeg-clk";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml
index 68764071..51aaf34 100644
--- a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml
+++ b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml
@@ -3,8 +3,8 @@
# # Copyright (c) 2021 Aspeed Technology Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aspeed UART Routing Controller
diff --git a/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml b/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml
index 8634865..ceb8164 100644
--- a/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml
+++ b/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2022, Intel Corporation
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/intel/intel,hps-copy-engine.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/intel/intel,hps-copy-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel HPS Copy Engine
diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
index ecae9fa..a64406c 100644
--- a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
@@ -2,8 +2,8 @@
# 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#"
+$id: http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LiteX SoC Controller driver
diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
new file mode 100644
index 0000000..da2dcfe
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 Power Manager controller
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - loongson,ls2k0500-pmc
+ - loongson,ls2k1000-pmc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ loongson,suspend-address:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ The "loongson,suspend-address" is a deep sleep state (Suspend To
+ RAM) firmware entry address which was jumped from kernel and it's
+ value was dependent on specific platform firmware code. In
+ addition, the PM need according to it to indicate that current
+ SoC whether support Suspend To RAM.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ power-management@1fe27000 {
+ compatible = "loongson,ls2k1000-pmc", "syscon";
+ reg = <0x1fe27000 0x58>;
+ interrupt-parent = <&liointc1>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ loongson,suspend-address = <0x0 0x1c000500>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml
index 8e6ba2e..f0fa92b 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml
@@ -12,7 +12,7 @@
description:
The MediaTek wo-ccif provides a configuration interface for WED WO
- controller used to perfrom offload rx packet processing (e.g. 802.11
+ controller used to perform offload rx packet processing (e.g. 802.11
aggregation packet reordering or rx header translation) on MT7986 soc.
properties:
diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
index 04ffee3..365a9fe 100644
--- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
@@ -12,7 +12,7 @@
description: |
PolarFire SoC devices include a microcontroller acting as the system controller,
which provides "services" to the main processor and to the FPGA fabric. These
- services include hardware rng, reprogramming of the FPGA and verfification of the
+ services include hardware rng, reprogramming of the FPGA and verification of the
eNVM contents etc. More information on these services can be found online, at
https://onlinedocs.microchip.com/pr/GUID-1409CF11-8EF9-4C24-A94E-70979A688632-en-US-1/index.html
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
index 9dc8e48..d1c7c2b 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
@@ -77,7 +77,7 @@
description:
The AOSS side channel also provides the controls for three cooling devices,
these are expressed as subnodes of the QMP node. The name of the node is
- used to identify the resource and must therefor be "cx", "mx" or "ebi".
+ used to identify the resource and must therefore be "cx", "mx" or "ebi".
properties:
"#cooling-cells":
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
index 6440dc8..bceb479 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -38,15 +38,9 @@
patternProperties:
'^connector@\d$':
$ref: /schemas/connector/usb-connector.yaml#
-
- properties:
- reg: true
-
required:
- reg
- unevaluatedProperties: false
-
required:
- compatible
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
index 65c02a7..2fa725b 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -34,22 +34,27 @@
- qcom,rpm-apq8084
- qcom,rpm-ipq6018
- qcom,rpm-ipq9574
+ - qcom,rpm-mdm9607
- qcom,rpm-msm8226
+ - qcom,rpm-msm8610
- qcom,rpm-msm8909
- qcom,rpm-msm8916
+ - qcom,rpm-msm8917
- qcom,rpm-msm8936
+ - qcom,rpm-msm8937
+ - qcom,rpm-msm8952
- qcom,rpm-msm8953
- qcom,rpm-msm8974
- qcom,rpm-msm8976
- qcom,rpm-msm8994
- qcom,rpm-msm8996
- qcom,rpm-msm8998
+ - qcom,rpm-qcm2290
+ - qcom,rpm-qcs404
- qcom,rpm-sdm660
- qcom,rpm-sm6115
- qcom,rpm-sm6125
- qcom,rpm-sm6375
- - qcom,rpm-qcm2290
- - qcom,rpm-qcs404
clock-controller:
$ref: /schemas/clock/qcom,rpmcc.yaml#
@@ -81,12 +86,18 @@
contains:
enum:
- qcom,rpm-apq8084
+ - qcom,rpm-mdm9607
- qcom,rpm-msm8226
+ - qcom,rpm-msm8610
+ - qcom,rpm-msm8909
- qcom,rpm-msm8916
+ - qcom,rpm-msm8917
- qcom,rpm-msm8936
+ - qcom,rpm-msm8937
+ - qcom,rpm-msm8952
+ - qcom,rpm-msm8953
- qcom,rpm-msm8974
- qcom,rpm-msm8976
- - qcom,rpm-msm8953
- qcom,rpm-msm8994
then:
properties:
@@ -109,10 +120,10 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
- smd {
- compatible = "qcom,smd";
+ remoteproc {
+ compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc";
- rpm {
+ smd-edge {
interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
qcom,ipc = <&apcs 8 0>;
qcom,smd-edge = <15>;
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
index 063e595..4819ce9 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
@@ -15,6 +15,12 @@
The Qualcomm Shared Memory Driver is a FIFO based communication channel for
sending data between the various subsystems in Qualcomm platforms.
+ Using the top-level SMD node is deprecated. Instead, the SMD edges are defined
+ directly below the device node representing the respective remote subsystem
+ or remote processor.
+
+deprecated: true
+
properties:
compatible:
const: qcom,smd
@@ -37,6 +43,7 @@
# The following example represents a smd node, with one edge representing the
# "rpm" subsystem. For the "rpm" subsystem we have a device tied to the
# "rpm_request" channel.
+ # NOTE: This is deprecated, represent the RPM using "qcom,rpm-proc" instead.
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
index 398663d..e52e176 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/renesas/renesas,rzg2l-sysc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/renesas/renesas,rzg2l-sysc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/{G2L,V2L} System Controller (SYSC)
diff --git a/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
new file mode 100644
index 0000000..0039319
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/starfive/starfive,jh7110-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 SoC system controller
+
+maintainers:
+ - William Qiu <william.qiu@starfivetech.com>
+
+description:
+ The StarFive JH7110 SoC system controller provides register information such
+ as offset, mask and shift to configure related modules such as MMC and PCIe.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: starfive,jh7110-sys-syscon
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - starfive,jh7110-aon-syscon
+ - starfive,jh7110-stg-syscon
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/starfive,jh7110-pll.yaml#
+ type: object
+
+ "#power-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-sys-syscon
+ then:
+ required:
+ - clock-controller
+ else:
+ properties:
+ clock-controller: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-aon-syscon
+ then:
+ required:
+ - "#power-domain-cells"
+ else:
+ properties:
+ "#power-domain-cells": false
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@10240000 {
+ compatible = "starfive,jh7110-stg-syscon", "syscon";
+ reg = <0x10240000 0x1000>;
+ };
+
+ syscon@13030000 {
+ compatible = "starfive,jh7110-sys-syscon", "syscon", "simple-mfd";
+ reg = <0x13030000 0x1000>;
+
+ clock-controller {
+ compatible = "starfive,jh7110-pll";
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
+ };
+
+ syscon@17010000 {
+ compatible = "starfive,jh7110-aon-syscon", "syscon";
+ reg = <0x17010000 0x1000>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml
new file mode 100644
index 0000000..d5261ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,nvec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA compliant embedded controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,nvec
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: divider clock
+ - description: fast clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: div-clk
+ - const: fast-clk
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: i2c
+
+ clock-frequency: true
+
+ request-gpios:
+ description: phandle to the GPIO used for EC request
+
+ slave-addr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: I2C address of the slave controller
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - clock-frequency
+ - request-gpios
+ - slave-addr
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c@7000c500 {
+ compatible = "nvidia,nvec";
+ reg = <0x7000c500 0x100>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <80000>;
+ request-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
+ slave-addr = <138>;
+ clocks = <&tegra_car TEGRA20_CLK_I2C3>,
+ <&tegra_car TEGRA20_CLK_PLL_P_OUT3>;
+ clock-names = "div-clk", "fast-clk";
+ resets = <&tegra_car 67>;
+ reset-names = "i2c";
+ };
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml
new file mode 100644
index 0000000..2f7269a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-ahb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+title: NVIDIA Tegra AHB
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-ahb
+ - nvidia,tegra30-ahb
+ - items:
+ - enum:
+ - nvidia,tegra114-ahb
+ - nvidia,tegra124-ahb
+ - nvidia,tegra210-ahb
+ - const: nvidia,tegra30-ahb
+
+ reg:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ ahb@6000c004 {
+ compatible = "nvidia,tegra20-ahb";
+ reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
+ };
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml
new file mode 100644
index 0000000..705544b
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-flowctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Flow Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-flowctrl
+ - nvidia,tegra30-flowctrl
+ - nvidia,tegra114-flowctrl
+ - nvidia,tegra124-flowctrl
+ - nvidia,tegra210-flowctrl
+
+ - items:
+ - const: nvidia,tegra132-flowctrl
+ - const: nvidia,tegra124-flowctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ flow-controller@60007000 {
+ compatible = "nvidia,tegra20-flowctrl";
+ reg = <0x60007000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
index 22cf900..1581866 100644
--- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 NavigatorSS Ring Accelerator
@@ -34,18 +34,22 @@
- const: ti,am654-navss-ringacc
reg:
+ minItems: 4
items:
- description: real time registers regions
- description: fifos registers regions
- description: proxy gcfg registers regions
- description: proxy target registers regions
+ - description: configuration registers region
reg-names:
+ minItems: 4
items:
- const: rt
- const: fifos
- const: proxy_gcfg
- const: proxy_target
+ - const: cfg
msi-parent: true
@@ -80,8 +84,9 @@
reg = <0x0 0x3c000000 0x0 0x400000>,
<0x0 0x38000000 0x0 0x400000>,
<0x0 0x31120000 0x0 0x100>,
- <0x0 0x33000000 0x0 0x40000>;
- reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
+ <0x0 0x33000000 0x0 0x40000>,
+ <0x0 0x31080000 0x0 0x40000>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
ti,num-rings = <818>;
ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
ti,sci = <&dmsc>;
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
index 5df7688..a750035 100644
--- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml#
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
index bf12345..5db718e 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
@@ -9,6 +9,9 @@
maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
const: amlogic,axg-sound-card
@@ -17,23 +20,12 @@
$ref: /schemas/types.yaml#/definitions/phandle-array
description: list of auxiliary devices
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- description:
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source.
-
audio-widgets:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
description:
A list off component DAPM widget. Each entry is a pair of strings,
the first being the widget type, the second being the widget name
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
patternProperties:
"^dai-link-[0-9]+$":
type: object
@@ -108,7 +100,6 @@
- sound-dai
required:
- - model
- dai-link-0
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
index b358fd6..d4277d3 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
@@ -9,6 +9,9 @@
maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
items:
@@ -18,14 +21,6 @@
$ref: /schemas/types.yaml#/definitions/phandle-array
description: list of auxiliary devices
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- minItems: 2
- description: |-
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source.
-
audio-widgets:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
minItems: 2
@@ -33,10 +28,6 @@
A list off component DAPM widget. Each entry is a pair of strings,
the first being the widget type, the second being the widget name
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
patternProperties:
"^dai-link-[0-9]+$":
type: object
@@ -86,7 +77,7 @@
- model
- dai-link-0
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml b/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml
new file mode 100644
index 0000000..d3cc1ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/audio-iio-aux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio IIO auxiliary
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ Auxiliary device based on Industrial I/O device channels
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: audio-iio-aux
+
+ io-channels:
+ description:
+ Industrial I/O device channels used
+
+ io-channel-names:
+ description:
+ Industrial I/O channel names related to io-channels.
+ These names are used to provides sound controls, widgets and routes names.
+
+ snd-control-invert-range:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ A list of 0/1 flags defining whether or not the related channel is
+ inverted
+ items:
+ enum: [0, 1]
+ default: 0
+ description: |
+ Invert the sound control value compared to the IIO channel raw value.
+ - 1: The related sound control value is inverted meaning that the
+ minimum sound control value correspond to the maximum IIO channel
+ raw value and the maximum sound control value correspond to the
+ minimum IIO channel raw value.
+ - 0: The related sound control value is not inverted meaning that the
+ minimum (resp maximum) sound control value correspond to the
+ minimum (resp maximum) IIO channel raw value.
+
+required:
+ - compatible
+ - io-channels
+ - io-channel-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ iio-aux {
+ compatible = "audio-iio-aux";
+ io-channels = <&iio 0>, <&iio 1>, <&iio 2>, <&iio 3>;
+ io-channel-names = "CH0", "CH1", "CH2", "CH3";
+ /* Invert CH1 and CH2 */
+ snd-control-invert-range = <0 1 1 0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
index 35eef7d..4051c25 100644
--- a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
+++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
@@ -19,7 +19,9 @@
properties:
compatible:
- const: awinic,aw88395
+ enum:
+ - awinic,aw88395
+ - awinic,aw88261
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 9d049d4..b6cc5f6 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -29,7 +29,7 @@
IN2 +---o--+------------+--o---+ OUT2
loop2 relays
-The 'loop1' gpio pin controlls two relays, which are either in loop position,
+The 'loop1' gpio pin controls two relays, which are either in loop position,
meaning that input and output are directly connected, or they are in mixer
position, meaning that the signal is passed through the 'Sum' mixer. Similarly
for 'loop2'.
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml
new file mode 100644
index 0000000..7a6de93
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml
@@ -0,0 +1,313 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs42l43.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS42L43 Audio CODEC
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description: |
+ The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface
+ (Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed
+ for portable applications. It provides a high dynamic range, stereo
+ DAC for headphone output, two integrated Class D amplifiers for
+ loudspeakers, and two ADCs for wired headset microphone input or
+ stereo line input. PDM inputs are provided for digital microphones.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs42l43
+
+ reg:
+ maxItems: 1
+
+ vdd-p-supply:
+ description:
+ Power supply for the high voltage interface.
+
+ vdd-a-supply:
+ description:
+ Power supply for internal analog circuits.
+
+ vdd-d-supply:
+ description:
+ Power supply for internal digital circuits. Can be internally supplied.
+
+ vdd-io-supply:
+ description:
+ Power supply for external interface and internal digital logic.
+
+ vdd-cp-supply:
+ description:
+ Power supply for the amplifier 3 and 4 charge pump.
+
+ vdd-amp-supply:
+ description:
+ Power supply for amplifier 1 and 2.
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 1
+
+ clocks:
+ items:
+ - description: Synchronous audio clock provided on mclk_in.
+
+ clock-names:
+ const: mclk
+
+ cirrus,bias-low:
+ type: boolean
+ description:
+ Select a 1.8V headset micbias rather than 2.8V.
+
+ cirrus,bias-sense-microamp:
+ description:
+ Current at which the headset micbias sense clamp will engage, 0 to
+ disable.
+ enum: [ 0, 14, 23, 41, 50, 60, 68, 86, 95 ]
+ default: 0
+
+ cirrus,bias-ramp-ms:
+ description:
+ Time in milliseconds the hardware allows for the headset micbias to
+ ramp up.
+ enum: [ 10, 40, 90, 170 ]
+ default: 170
+
+ cirrus,detect-us:
+ description:
+ Time in microseconds the type detection will run for. Long values will
+ cause more audible effects, but give more accurate detection.
+ enum: [ 20, 100, 1000, 10000, 50000, 75000, 100000, 200000 ]
+ default: 10000
+
+ cirrus,button-automute:
+ type: boolean
+ description:
+ Enable the hardware automuting of decimator 1 when a headset button is
+ pressed.
+
+ cirrus,buttons-ohms:
+ description:
+ Impedance in Ohms for each headset button, these should be listed in
+ ascending order.
+ minItems: 1
+ maxItems: 6
+
+ cirrus,tip-debounce-ms:
+ description:
+ Software debounce on tip sense triggering in milliseconds.
+ default: 0
+
+ cirrus,tip-invert:
+ type: boolean
+ description:
+ Indicates tip detect polarity, inverted implies open-circuit whilst the
+ jack is inserted.
+
+ cirrus,tip-disable-pullup:
+ type: boolean
+ description:
+ Indicates if the internal pullup on the tip detect should be disabled.
+
+ cirrus,tip-fall-db-ms:
+ description:
+ Time in milliseconds a falling edge on the tip detect should be hardware
+ debounced for. Note the falling edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ cirrus,tip-rise-db-ms:
+ description:
+ Time in milliseconds a rising edge on the tip detect should be hardware
+ debounced for. Note the rising edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ cirrus,use-ring-sense:
+ type: boolean
+ description:
+ Indicates if the ring sense should be used.
+
+ cirrus,ring-invert:
+ type: boolean
+ description:
+ Indicates ring detect polarity, inverted implies open-circuit whilst the
+ jack is inserted.
+
+ cirrus,ring-disable-pullup:
+ type: boolean
+ description:
+ Indicates if the internal pullup on the ring detect should be disabled.
+
+ cirrus,ring-fall-db-ms:
+ description:
+ Time in milliseconds a falling edge on the ring detect should be hardware
+ debounced for. Note the falling edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ cirrus,ring-rise-db-ms:
+ description:
+ Time in milliseconds a rising edge on the ring detect should be hardware
+ debounced for. Note the rising edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ pinctrl:
+ type: object
+ $ref: /schemas/pinctrl/pinctrl.yaml#
+ additionalProperties: false
+
+ properties:
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ items:
+ - description: A phandle to the CODEC pinctrl node
+ minimum: 0
+ - const: 0
+ - const: 0
+ - const: 3
+
+ patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/cirrus-cs42l43-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/cirrus-cs42l43-state"
+ additionalProperties: false
+
+ spi:
+ type: object
+ $ref: /schemas/spi/spi-controller.yaml#
+ unevaluatedProperties: false
+
+$defs:
+ cirrus-cs42l43-state:
+ type: object
+
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
+ additionalProperties: false
+
+ properties:
+ groups:
+ enum: [ gpio1, gpio2, gpio3, asp, pdmout2, pdmout1, i2c, spi ]
+
+ pins:
+ enum: [ gpio1, gpio2, gpio3,
+ asp_dout, asp_fsync, asp_bclk,
+ pdmout2_clk, pdmout2_data, pdmout1_clk, pdmout1_data,
+ i2c_sda, i2c_scl,
+ spi_miso, spi_sck, spi_ssb ]
+
+ function:
+ enum: [ gpio, spdif, irq, mic-shutter, spk-shutter ]
+
+ drive-strength:
+ description: Set drive strength in mA
+ enum: [ 1, 2, 4, 8, 9, 10, 12, 16 ]
+
+ input-debounce:
+ description: Set input debounce in uS
+ enum: [ 0, 85 ]
+
+required:
+ - compatible
+ - reg
+ - vdd-p-supply
+ - vdd-a-supply
+ - vdd-io-supply
+ - vdd-cp-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cs42l43: codec@1a {
+ compatible = "cirrus,cs42l43";
+ reg = <0x1a>;
+
+ vdd-p-supply = <&vdd5v0>;
+ vdd-a-supply = <&vdd1v8>;
+ vdd-io-supply = <&vdd1v8>;
+ vdd-cp-supply = <&vdd1v8>;
+ vdd-amp-supply = <&vdd5v0>;
+
+ reset-gpios = <&gpio 0>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gpio>;
+ interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
+
+ #sound-dai-cells = <1>;
+
+ clocks = <&clks 0>;
+ clock-names = "mclk";
+
+ cs42l43_pins: pinctrl {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cs42l43_pins 0 0 3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinsettings>;
+
+ pinsettings: default-state {
+ shutter-pins {
+ groups = "gpio3";
+ function = "mic-shutter";
+ };
+ };
+ };
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cs-gpios = <&cs42l43_pins 1 0>;
+
+ sensor@0 {
+ compatible = "bosch,bme680";
+ reg = <0>;
+ spi-max-frequency = <1400000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cs35l35.txt b/Documentation/devicetree/bindings/sound/cs35l35.txt
index 7915897..e84f30c 100644
--- a/Documentation/devicetree/bindings/sound/cs35l35.txt
+++ b/Documentation/devicetree/bindings/sound/cs35l35.txt
@@ -110,7 +110,7 @@
See Sections 4.8.2 through 4.8.4 Serial-Port Control in the Datasheet
- -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formating
+ -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formatting
on the I2S Port. Each of the 3 8 bit values in the array contain the settings
for depth, location, and frame.
diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt
index 912bd16..d34117b 100644
--- a/Documentation/devicetree/bindings/sound/cs35l36.txt
+++ b/Documentation/devicetree/bindings/sound/cs35l36.txt
@@ -33,7 +33,7 @@
one amplifier in the system. If more than one it is best to Hi-Z the ASP
port to prevent bus contention on the output signal
- - cirrus,boost-ctl-select : Boost conerter control source selection.
+ - cirrus,boost-ctl-select : Boost converter control source selection.
Selects the source of the BST_CTL target VBST voltage for the boost
converter to generate.
0x00 - Control Port Value
diff --git a/Documentation/devicetree/bindings/sound/cs53l30.txt b/Documentation/devicetree/bindings/sound/cs53l30.txt
index 4dbfb82..dc256ad 100644
--- a/Documentation/devicetree/bindings/sound/cs53l30.txt
+++ b/Documentation/devicetree/bindings/sound/cs53l30.txt
@@ -30,7 +30,7 @@
* frame using two different ways:
* 1) Normal I2S mode on two data pins -- each SDOUT
* carries 2-channel data in the same time.
- * 2) TDM mode on one signle data pin -- SDOUT1 carries
+ * 2) TDM mode on one single data pin -- SDOUT1 carries
* 4-channel data per frame.
Example:
diff --git a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
index bb5af48..eb7d219 100644
--- a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
+++ b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
@@ -74,7 +74,7 @@
$ref: /schemas/types.yaml#/definitions/uint32
dlg,mic-amp-in-sel:
- enum: ["diff", "se_p", "se_n"]
+ enum: [diff, se_p, se_n]
description:
Mic input source type.
@@ -123,7 +123,7 @@
$ref: /schemas/types.yaml#/definitions/uint32
dlg,jack-ins-det-pty:
- enum: ["low", "high"]
+ enum: [low, high]
description:
Polarity for jack insertion detection.
$ref: /schemas/types.yaml#/definitions/string
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
index 0a2480a..90112ca 100644
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -44,7 +44,7 @@
- fsl,esai-synchronous: This is a boolean property. If present, indicating
that ESAI would work in the synchronous mode, which
means all the settings for Receiving would be
- duplicated from Transmition related registers.
+ duplicated from Transmission related registers.
Optional properties:
diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
index e847611a..188f38b 100644
--- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
@@ -17,6 +17,9 @@
such as SAI, MICFIL, .etc through building rpmsg channels between
Cortex-A and Cortex-M.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
@@ -25,10 +28,7 @@
- fsl,imx8mm-rpmsg-audio
- fsl,imx8mp-rpmsg-audio
- fsl,imx8ulp-rpmsg-audio
-
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
+ - fsl,imx93-rpmsg-audio
clocks:
items:
@@ -65,13 +65,6 @@
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle to a node of audio codec
- 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.
-
fsl,enable-lpa:
$ref: /schemas/types.yaml#/definitions/flag
description: enable low power audio path.
@@ -100,9 +93,8 @@
required:
- compatible
- - model
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
index ba5b772..bac9405 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
@@ -13,23 +13,15 @@
description:
This binding describes the SC7180 sound card which uses LPASS for audio.
+allOf:
+ - $ref: sound-card-common.yaml#
+
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
@@ -86,11 +78,10 @@
required:
- compatible
- - model
- "#address-cells"
- "#size-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
index 0b1a01a..ec4b6e5 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
@@ -13,22 +13,14 @@
description:
This binding describes the SC7280 sound card which uses LPASS for audio.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- google,sc7280-herobrine
- 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
@@ -97,11 +89,10 @@
required:
- compatible
- - model
- "#address-cells"
- "#size-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/gtm601.txt b/Documentation/devicetree/bindings/sound/gtm601.txt
deleted file mode 100644
index efa32a4..0000000
--- a/Documentation/devicetree/bindings/sound/gtm601.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-GTM601 UMTS modem audio interface CODEC
-
-This device has no configuration interface. The sample rate and channels are
-based on the compatible string
- "option,gtm601" = 8kHz mono
- "broadmobi,bm818" = 48KHz stereo
-
-Required properties:
-
- - compatible : one of
- "option,gtm601"
- "broadmobi,bm818"
-
-
-Example:
-
-codec: gtm601_codec {
- compatible = "option,gtm601";
-};
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index b6f5d48..f7ad5ea 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -9,23 +9,14 @@
maintainers:
- Shengjiu Wang <shengjiu.wang@nxp.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- fsl,imx-audio-card
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- description:
- A list of the connections between audio components. Each entry is a
- 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.
-
patternProperties:
".*-dai-link$":
description:
@@ -84,9 +75,8 @@
required:
- compatible
- - model
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt
deleted file mode 100644
index 98cb9ba..0000000
--- a/Documentation/devicetree/bindings/sound/max9892x.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
-
-This device supports I2C.
-
-Required properties:
-
- - compatible : should be one of the following
- - "maxim,max98925"
- - "maxim,max98926"
- - "maxim,max98927"
-
- - vmon-slot-no : slot number used to send voltage information
- or in inteleave mode this will be used as
- interleave slot.
- MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
- MAX98927 slot range : 0 ~ 15, Default : 0
-
- - imon-slot-no : slot number used to send current information
- MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
- MAX98927 slot range : 0 ~ 15, Default : 0
-
- - interleave-mode : When using two MAX9892X in a system it is
- possible to create ADC data that that will
- overflow the frame size. Digital Audio Interleave
- mode provides a means to output VMON and IMON data
- from two devices on a single DOUT line when running
- smaller frames sizes such as 32 BCLKS per LRCLK or
- 48 BCLKS per LRCLK.
- Range : 0 (off), 1 (on), Default : 0
-
- - reg : the I2C address of the device for I2C
-
-Optional properties:
- - reset-gpios : GPIO to reset the device
-
-Example:
-
-codec: max98927@3a {
- compatible = "maxim,max98927";
- vmon-slot-no = <0>;
- imon-slot-no = <1>;
- interleave-mode = <0>;
- reg = <0x3a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98925.yaml b/Documentation/devicetree/bindings/sound/maxim,max98925.yaml
new file mode 100644
index 0000000..32fd862
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98925.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98925.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98925/MAX98926/MAX98927 speaker amplifier
+
+maintainers:
+ - Ryan Lee <ryans.lee@maximintegrated.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98925
+ - maxim,max98926
+ - maxim,max98927
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ vmon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 30
+ default: 0
+ description:
+ Slot number used to send voltage information or in inteleave mode this
+ will be used as interleave slot.
+
+ imon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 30
+ default: 0
+ description:
+ Slot number used to send current information.
+
+ maxim,interleave-mode:
+ type: boolean
+ description:
+ When using two MAX9892X in a system it is possible to create ADC data
+ that will overflow the frame size. When enabled, the Digital Audio
+ Interleave mode provides a means to output VMON and IMON data from two
+ devices on a single DOUT line when running smaller frames sizes such as
+ 32 BCLKS per LRCLK or 48 BCLKS per LRCLK.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max98927
+ then:
+ properties:
+ vmon-slot-no:
+ minimum: 0
+ maximum: 15
+
+ imon-slot-no:
+ minimum: 0
+ maximum: 15
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ #include <dt-bindings/gpio/gpio.h>
+ audio-codec@3a {
+ compatible = "maxim,max98927";
+ reg = <0x3a>;
+ #sound-dai-cells = <0>;
+
+ pinctrl-0 = <&speaker_default>;
+ pinctrl-names = "default";
+
+ reset-gpios = <&tlmm 69 GPIO_ACTIVE_LOW>;
+
+ vmon-slot-no = <1>;
+ imon-slot-no = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml
new file mode 100644
index 0000000..398efdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt7986-afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AFE PCM controller for MT7986
+
+maintainers:
+ - Maso Huang <maso.huang@mediatek.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt7986-afe
+ - items:
+ - enum:
+ - mediatek,mt7981-afe
+ - mediatek,mt7988-afe
+ - const: mediatek,mt7986-afe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 5
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ - description: mux for pcm_mck
+ - description: audio i2s/pcm mck
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+ - const: sel
+ - const: i2s_m
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7986-afe
+ then:
+ properties:
+ clocks:
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ clock-names:
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7981-afe
+ then:
+ properties:
+ clocks:
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ - description: mux for pcm_mck
+ clock-names:
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+ - const: sel
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7988-afe
+ then:
+ properties:
+ clocks:
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ - description: mux for pcm_mck
+ - description: audio i2s/pcm mck
+ clock-names:
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+ - const: sel
+ - const: i2s_m
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/mt7986-clk.h>
+
+ afe@11210000 {
+ compatible = "mediatek,mt7986-afe";
+ reg = <0x11210000 0x9000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&infracfg_ao CLK_INFRA_AUD_BUS_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_26M_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_L_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_AUD_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_EG2_CK>;
+ clock-names = "bus_ck",
+ "26m_ck",
+ "l_ck",
+ "aud_ck",
+ "eg2_ck";
+ assigned-clocks = <&topckgen CLK_TOP_A1SYS_SEL>,
+ <&topckgen CLK_TOP_AUD_L_SEL>,
+ <&topckgen CLK_TOP_A_TUNER_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_APLL2_D4>,
+ <&apmixedsys CLK_APMIXED_APLL2>,
+ <&topckgen CLK_TOP_APLL2_D4>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml
new file mode 100644
index 0000000..09247ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.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/mediatek,mt7986-wm8960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7986 sound card with WM8960 codec
+
+maintainers:
+ - Maso Huang <maso.huang@mediatek.com>
+
+allOf:
+ - $ref: sound-card-common.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt7986-wm8960-sound
+
+ platform:
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ description: The phandle of MT7986 platform.
+ maxItems: 1
+ required:
+ - sound-dai
+
+ codec:
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ description: The phandle of wm8960 codec.
+ maxItems: 1
+ required:
+ - sound-dai
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - audio-routing
+ - platform
+ - codec
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt7986-wm8960-sound";
+ model = "mt7986-wm8960";
+ audio-routing =
+ "Headphone", "HP_L",
+ "Headphone", "HP_R",
+ "LINPUT1", "AMIC",
+ "RINPUT1", "AMIC";
+
+ platform {
+ sound-dai = <&afe>;
+ };
+
+ codec {
+ sound-dai = <&wm8960>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
index e6cb711..90520f8 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
@@ -25,6 +25,12 @@
reset-names:
const: audiosys
+ memory-region:
+ maxItems: 1
+ description: |
+ Shared memory region for AFE memif. A "shared-dma-pool".
+ See ../reserved-memory/reserved-memory.yaml for details.
+
mediatek,topckgen:
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek topckgen controller
@@ -135,7 +141,7 @@
maxItems: 16
description:
This is a list of channel IDs which should be disabled.
- By default, all data received from ETDM pins will be outputed to
+ By default, all data received from ETDM pins will be outputted to
memory. etdm in supports disable_out in direct mode(w/o interconn),
so user can disable the specified channels by the property.
uniqueItems: true
@@ -176,6 +182,7 @@
interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>;
resets = <&watchdog 14>;
reset-names = "audiosys";
+ memory-region = <&snd_dma_mem_reserved>;
mediatek,topckgen = <&topckgen>;
mediatek,infracfg = <&infracfg_ao>;
power-domains = <&spm 13>; //MT8188_POWER_DOMAIN_AUDIO
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
index 05e532b..43b3b67 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
@@ -9,23 +9,19 @@
maintainers:
- Trevor Wu <trevor.wu@mediatek.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- mediatek,mt8188-mt6359-evb
- mediatek,mt8188-nau8825
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
description:
- A list of the connections between audio components. Each entry is a
- sink/source pair of strings. Valid names could be the input or output
- widgets of audio components, power supplies, MicBias of codec and the
- software switch.
+ Valid names could be the input or output widgets of audio components,
+ power supplies, MicBias of codec and the software switch.
mediatek,platform:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -86,7 +82,7 @@
required:
- link-name
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
@@ -96,6 +92,7 @@
- |
sound {
compatible = "mediatek,mt8188-mt6359-evb";
+ model = "MT6359-EVB";
mediatek,platform = <&afe>;
pinctrl-names = "default";
pinctrl-0 = <&aud_pins_default>;
diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
index 560762e..f548e6a 100644
--- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
+++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
@@ -1,7 +1,7 @@
Mediatek AFE PCM controller for mt2701
Required properties:
-- compatible: should be one of the followings.
+- compatible: should be one of the following.
- "mediatek,mt2701-audio"
- "mediatek,mt7622-audio"
- interrupts: should contain AFE and ASYS interrupts
diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
index d5adf07..5c8dba2 100644
--- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
@@ -111,7 +111,7 @@
$ref: /schemas/types.yaml#/definitions/uint32
description: |
etdm modules can share the same external clock pin. Specify
- which etdm clock source is required by this etdm in moudule.
+ which etdm clock source is required by this etdm in module.
enum:
- 0 # etdm1_in
- 1 # etdm2_in
@@ -122,7 +122,7 @@
$ref: /schemas/types.yaml#/definitions/uint32
description: |
etdm modules can share the same external clock pin. Specify
- which etdm clock source is required by this etdm out moudule.
+ which etdm clock source is required by this etdm out module.
enum:
- 0 # etdm1_in
- 1 # etdm2_in
diff --git a/Documentation/devicetree/bindings/sound/nau8821.txt b/Documentation/devicetree/bindings/sound/nau8821.txt
deleted file mode 100644
index 7c84e7c..0000000
--- a/Documentation/devicetree/bindings/sound/nau8821.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Nuvoton NAU88L21 audio codec
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "nuvoton,nau8821"
-
- - reg : the I2C address of the device. This is either 0x1B (CSB=0) or 0x54 (CSB=1).
-
-Optional properties:
- - nuvoton,jkdet-enable: Enable jack detection via JKDET pin.
- - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled,
- otherwise pin in high impedance state.
- - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down.
- - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low.
-
- - nuvoton,vref-impedance: VREF Impedance selection
- 0 - Open
- 1 - 25 kOhm
- 2 - 125 kOhm
- 3 - 2.5 kOhm
-
- - nuvoton,micbias-voltage: Micbias voltage level.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
- - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
-
- - nuvoton,dmic-clk-threshold: the ADC threshold of DMIC clock.
- - nuvoton,key_enable: Headset button detection switch.
-
-Example:
-
- headset: nau8821@1b {
- compatible = "nuvoton,nau8821";
- reg = <0x1b>;
- interrupt-parent = <&gpio>;
- interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
- nuvoton,jkdet-enable;
- nuvoton,jkdet-pull-enable;
- nuvoton,jkdet-pull-up;
- nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
- nuvoton,vref-impedance = <2>;
- nuvoton,micbias-voltage = <6>;
- nuvoton,jack-insert-debounce = <7>;
- nuvoton,jack-eject-debounce = <7>;
- nuvoton,dmic-clk-threshold = 3072000;
- };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml
new file mode 100644
index 0000000..3e54abd
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8821.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU88L21 audio codec
+
+maintainers:
+ - Seven Lee <wtli@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: nuvoton,nau8821
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ nuvoton,jkdet-enable:
+ description: Enable jack detection via JKDET pin.
+ type: boolean
+
+ nuvoton,jkdet-pull-enable:
+ description: Enable JKDET pin pull. If set - pin pull enabled,
+ otherwise pin in high impedance state.
+ type: boolean
+
+ nuvoton,jkdet-pull-up:
+ description: Pull-up JKDET pin. If set then JKDET pin is pull up,
+ otherwise pull down.
+ type: boolean
+
+ nuvoton,key-enable:
+ description: handles key press detection.
+ type: boolean
+
+ nuvoton,jkdet-polarity:
+ description: JKDET pin polarity.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # active high
+ - 1 # active low
+ default: 1
+
+ nuvoton,micbias-voltage:
+ description: MICBIAS output level select.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA * 1
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,vref-impedance:
+ description: VMID Tie-off impedance select.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # open
+ - 1 # 25KOhms
+ - 2 # 125KOhms
+ - 3 # 2.5KOhms
+ default: 2
+
+ nuvoton,jack-insert-debounce:
+ description: number from 0 to 7 that sets debounce time to 2^(n+2)ms.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 7
+
+ nuvoton,jack-eject-debounce:
+ description: number from 0 to 7 that sets debounce time to 2^(n+2)ms.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 0
+
+ nuvoton,dmic-clk-threshold:
+ description: DMIC clock speed expected value. Unit is Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 3072000
+
+ nuvoton,left-input-single-end:
+ description: Enable left input with single-ended settings if set.
+ For the headset mic application, the single-ended control is
+ just limited to the left adc for design demand.
+ type: boolean
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1b {
+ compatible = "nuvoton,nau8821";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+ nuvoton,jkdet-enable;
+ nuvoton,jkdet-pull-enable;
+ nuvoton,jkdet-pull-up;
+ nuvoton,key-enable;
+ nuvoton,left-input-single-end;
+ nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
+ nuvoton,micbias-voltage = <6>;
+ nuvoton,vref-impedance = <2>;
+ nuvoton,jack-insert-debounce = <7>;
+ nuvoton,jack-eject-debounce = <0>;
+ nuvoton,dmic-clk-threshold = <3072000>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
index 6510540..cb8182b 100644
--- a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
@@ -21,6 +21,15 @@
reg:
maxItems: 1
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
nuvoton,spk-btl:
description:
If set, configure the two loudspeaker outputs as a Bridge Tied Load output
@@ -31,6 +40,9 @@
- compatible
- reg
+allOf:
+ - $ref: dai-common.yaml#
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml
index fc89dbd..c29d794 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml
@@ -35,12 +35,12 @@
items:
enum:
# Board Connectors
- - "Int Spk"
- - "Headphone Jack"
- - "Earpiece"
- - "Headset Mic"
- - "Internal Mic 1"
- - "Internal Mic 2"
+ - Int Spk
+ - Headphone Jack
+ - Earpiece
+ - Headset Mic
+ - Internal Mic 1
+ - Internal Mic 2
# CODEC Pins
- HPL
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml
index a044870..0c8067c 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml
@@ -31,10 +31,10 @@
items:
enum:
# Board Connectors
- - "Int Spk"
- - "Headphone Jack"
- - "Mic Jack"
- - "Int Mic"
+ - Int Spk
+ - Headphone Jack
+ - Mic Jack
+ - Int Mic
# CODEC Pins
- MIC1
diff --git a/Documentation/devicetree/bindings/sound/option,gtm601.yaml b/Documentation/devicetree/bindings/sound/option,gtm601.yaml
new file mode 100644
index 0000000..ff813d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/option,gtm601.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/option,gtm601.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GTM601 UMTS modem audio interface CODEC
+
+maintainers:
+ - kernel@puri.sm
+
+description: >
+ This device has no configuration interface. The sample rate and channels are
+ based on the compatible string
+
+properties:
+ compatible:
+ oneOf:
+ - description: Broadmobi BM818 (48Khz stereo)
+ items:
+ - const: broadmobi,bm818
+ - const: option,gtm601
+ - description: GTM601 (8kHz mono)
+ const: option,gtm601
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+
+allOf:
+ - $ref: dai-common.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ codec {
+ compatible = "option,gtm601";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt
deleted file mode 100644
index e7d17dda5..0000000
--- a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-msm8916 analog audio CODEC
-
-Bindings for codec Analog IP which is integrated in pmic pm8916,
-
-## Bindings for codec core on pmic:
-
-Required properties
- - compatible = "qcom,pm8916-wcd-analog-codec";
- - reg: represents the slave base address provided to the peripheral.
- - interrupts: List of interrupts in given SPMI peripheral.
- - interrupt-names: Names specified to above list of interrupts in same
- order. List of supported interrupt names are:
- "cdc_spk_cnp_int" - Speaker click and pop interrupt.
- "cdc_spk_clip_int" - Speaker clip interrupt.
- "cdc_spk_ocp_int" - Speaker over current protect interrupt.
- "mbhc_ins_rem_det1" - jack insert removal detect interrupt 1.
- "mbhc_but_rel_det" - button release interrupt.
- "mbhc_but_press_det" - button press event
- "mbhc_ins_rem_det" - jack insert removal detect interrupt.
- "mbhc_switch_int" - multi button headset interrupt.
- "cdc_ear_ocp_int" - Earphone over current protect interrupt.
- "cdc_hphr_ocp_int" - Headphone R over current protect interrupt.
- "cdc_hphl_ocp_det" - Headphone L over current protect interrupt.
- "cdc_ear_cnp_int" - earphone cnp interrupt.
- "cdc_hphr_cnp_int" - hphr click and pop interrupt.
- "cdc_hphl_cnp_int" - hphl click and pop interrupt.
-
- - clocks: Handle to mclk.
- - clock-names: should be "mclk"
- - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node.
- - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node.
- - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node.
-
-Optional Properties:
- - qcom,mbhc-vthreshold-low: Array of 5 threshold voltages in mV for 5 buttons
- detection on headset when the mbhc is powered up
- by internal current source, this is a low power.
- - qcom,mbhc-vthreshold-high: Array of 5 thresold voltages in mV for 5 buttons
- detection on headset when mbhc is powered up
- from micbias.
-- qcom,micbias-lvl: Voltage (mV) for Mic Bias
-- qcom,hphl-jack-type-normally-open: boolean, present if hphl pin on jack is a
- NO (Normally Open). If not specified, then
- its assumed that hphl pin on jack is NC
- (Normally Closed).
-- qcom,gnd-jack-type-normally-open: boolean, present if gnd pin on jack is
- NO (Normally Open). If not specified, then
- its assumed that gnd pin on jack is NC
- (Normally Closed).
-- qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor
- connected.
-- qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor
- connected.
-
-Example:
-
-spmi_bus {
- ...
- audio-codec@f000{
- compatible = "qcom,pm8916-wcd-analog-codec";
- reg = <0xf000 0x200>;
- reg-names = "pmic-codec-core";
- clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
- clock-names = "mclk";
- qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
- qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
- interrupt-parent = <&spmi_bus>;
- interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
- interrupt-names = "cdc_spk_cnp_int",
- "cdc_spk_clip_int",
- "cdc_spk_ocp_int",
- "mbhc_ins_rem_det1",
- "mbhc_but_rel_det",
- "mbhc_but_press_det",
- "mbhc_ins_rem_det",
- "mbhc_switch_int",
- "cdc_ear_ocp_int",
- "cdc_hphr_ocp_int",
- "cdc_hphl_ocp_det",
- "cdc_ear_cnp_int",
- "cdc_hphr_cnp_int",
- "cdc_hphl_cnp_int";
- vdd-cdc-io-supply = <&pm8916_l5>;
- vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
- vdd-micbias-supply = <&pm8916_l13>;
- #sound-dai-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml b/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml
new file mode 100644
index 0000000..94e7a18
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,pm8916-wcd-analog-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8916 WCD Analog Audio Codec
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The analog WCD audio codec found on Qualcomm PM8916 PMIC.
+
+properties:
+ compatible:
+ const: qcom,pm8916-wcd-analog-codec
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 14
+
+ interrupt-names:
+ items:
+ - const: cdc_spk_cnp_int
+ - const: cdc_spk_clip_int
+ - const: cdc_spk_ocp_int
+ - const: mbhc_ins_rem_det1
+ - const: mbhc_but_rel_det
+ - const: mbhc_but_press_det
+ - const: mbhc_ins_rem_det
+ - const: mbhc_switch_int
+ - const: cdc_ear_ocp_int
+ - const: cdc_hphr_ocp_int
+ - const: cdc_hphl_ocp_det
+ - const: cdc_ear_cnp_int
+ - const: cdc_hphr_cnp_int
+ - const: cdc_hphl_cnp_int
+
+ vdd-cdc-io-supply:
+ description: 1.8V buck supply
+
+ vdd-cdc-tx-rx-cx-supply:
+ description: 1.8V SIDO buck supply
+
+ vdd-micbias-supply:
+ description: micbias supply
+
+ qcom,mbhc-vthreshold-low:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Array of 5 threshold voltages in mV for 5-button detection on
+ headset when MBHC is powered by an internal current source.
+ minItems: 5
+ maxItems: 5
+
+ qcom,mbhc-vthreshold-high:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Array of 5 threshold voltages in mV for 5-button detection on
+ headset when MBHC is powered from micbias.
+ minItems: 5
+ maxItems: 5
+
+ qcom,micbias-lvl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Voltage (mV) for Mic Bias
+
+ qcom,hphl-jack-type-normally-open:
+ type: boolean
+ description:
+ True if the HPHL pin on the jack is NO (Normally Open), false if it's
+ NC (Normally Closed).
+
+ qcom,gnd-jack-type-normally-open:
+ type: boolean
+ description:
+ True if the GND pin on the jack is NO (Normally Open), false if it's
+ NC (Normally Closed).
+
+ qcom,micbias1-ext-cap:
+ type: boolean
+ description:
+ True if micbias1 has an external capacitor.
+
+ qcom,micbias2-ext-cap:
+ type: boolean
+ description:
+ True if micbias2 has an external capacitor.
+
+ "#sound-dai-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@1 {
+ compatible = "qcom,pm8916", "qcom,spmi-pmic";
+ reg = <0x1 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@f000 {
+ compatible = "qcom,pm8916-wcd-analog-codec";
+ reg = <0xf000>;
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ interrupt-parent = <&spmi_bus>;
+ interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
+ interrupt-names = "cdc_spk_cnp_int",
+ "cdc_spk_clip_int",
+ "cdc_spk_ocp_int",
+ "mbhc_ins_rem_det1",
+ "mbhc_but_rel_det",
+ "mbhc_but_press_det",
+ "mbhc_ins_rem_det",
+ "mbhc_switch_int",
+ "cdc_ear_ocp_int",
+ "cdc_hphr_ocp_int",
+ "cdc_hphl_ocp_det",
+ "cdc_ear_cnp_int",
+ "cdc_hphr_cnp_int",
+ "cdc_hphl_cnp_int";
+ vdd-cdc-io-supply = <&pm8916_l5>;
+ vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
+ vdd-micbias-supply = <&pm8916_l13>;
+ #sound-dai-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index b731f16..dfd768b 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -94,7 +94,7 @@
[xx]ch [yy]ch
------> [CTU] -------->
-CTU can convert [xx]ch to [yy]ch, or exchange outputed channel.
+CTU can convert [xx]ch to [yy]ch, or exchange outputted channel.
CTU conversion needs matrix settings.
For more detail information, see below
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
index 8a821de..13a5a0a 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
@@ -9,6 +9,20 @@
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+definitions:
+ port-def:
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ unevaluatedProperties: false
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: audio-graph-port.yaml#/definitions/endpoint-base
+ properties:
+ playback:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ capture:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ unevaluatedProperties: false
+
properties:
compatible:
@@ -77,6 +91,12 @@
it must be 1 if your system has audio_clkout0/1/2/3
enum: [0, 1]
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
clock-frequency:
description: for audio_clkout0/1/2/3
@@ -103,35 +123,9 @@
description: List of necessary clock names.
# details are defined below
- ports:
- $ref: audio-graph-port.yaml#/definitions/port-base
- unevaluatedProperties: false
- patternProperties:
- '^port(@[0-9a-f]+)?$':
- $ref: audio-graph-port.yaml#/definitions/port-base
- unevaluatedProperties: false
- patternProperties:
- "^endpoint(@[0-9a-f]+)?":
- $ref: audio-graph-port.yaml#/definitions/endpoint-base
- properties:
- playback:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- capture:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- unevaluatedProperties: false
-
+ # ports is below
port:
- $ref: audio-graph-port.yaml#/definitions/port-base
- unevaluatedProperties: false
- patternProperties:
- "^endpoint(@[0-9a-f]+)?":
- $ref: audio-graph-port.yaml#/definitions/endpoint-base
- properties:
- playback:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- capture:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- unevaluatedProperties: false
+ $ref: "#/definitions/port-def"
rcar_sound,dvc:
description: DVC subnode.
@@ -248,8 +242,9 @@
- interrupts
additionalProperties: false
+patternProperties:
# For DAI base
- rcar_sound,dai:
+ 'rcar_sound,dai(@[0-9a-f]+)?$':
description: DAI subnode.
type: object
patternProperties:
@@ -269,6 +264,13 @@
- capture
additionalProperties: false
+ 'ports(@[0-9a-f]+)?$':
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ unevaluatedProperties: false
+ patternProperties:
+ '^port(@[0-9a-f]+)?$':
+ $ref: "#/definitions/port-def"
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt
index e5430d1..73577ac 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt
@@ -12,7 +12,7 @@
source. For this driver the first string should always be
"Analog".
-Optionnal properties:
+Optional properties:
- rockchip,hp-en-gpios = The phandle of the GPIO that power up/down the
headphone (when the analog output is an headphone).
- rockchip,hp-det-gpios = The phandle of the GPIO that detects the headphone
diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt b/Documentation/devicetree/bindings/sound/rt5663.txt
index 2a55e91..24a6dab 100644
--- a/Documentation/devicetree/bindings/sound/rt5663.txt
+++ b/Documentation/devicetree/bindings/sound/rt5663.txt
@@ -28,7 +28,7 @@
If the value is 0, it means the impedance sensing is not supported.
- "realtek,impedance_sensing_table"
The matrix rows of the impedance sensing table are consisted by impedance
- minimum, impedance maximun, volume, DC offset w/o and w/ mic of each L and
+ minimum, impedance maximum, volume, DC offset w/o and w/ mic of each L and
R channel accordingly. Example is shown as following.
< 0 300 7 0xffd160 0xffd1c0 0xff8a10 0xff8ab0
301 65535 4 0xffe470 0xffe470 0xffb8e0 0xffb8e0>
diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml
index 447e013..5ea0819 100644
--- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml
@@ -9,6 +9,9 @@
maintainers:
- Jonathan Bakker <xc-racer2@live.ca>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
@@ -17,10 +20,6 @@
# Without FM radio and modem slave
- samsung,fascinate4g-wm8994
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: The user-visible name of this sound complex.
-
cpu:
type: object
additionalProperties: false
@@ -46,6 +45,7 @@
samsung,audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ deprecated: true
description: |
List of the connections between audio
components; each entry is a pair of strings, the first being the
@@ -56,6 +56,7 @@
or FM In
For samsung,fascinate4g-wm8994: HP, SPK, RCV, LINE, Main Mic,
or HeadsetMic
+ Deprecated, use audio-routing.
extcon:
description: Extcon phandle for dock detection
@@ -87,10 +88,9 @@
required:
- compatible
- - model
- cpu
- codec
- - samsung,audio-routing
+ - audio-routing
- extcon
- main-micbias-supply
- headset-micbias-supply
@@ -98,7 +98,7 @@
- headset-detect-gpios
- headset-key-gpios
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -121,7 +121,7 @@
headset-detect-gpios = <&gph0 6 GPIO_ACTIVE_HIGH>;
headset-key-gpios = <&gph3 6 GPIO_ACTIVE_HIGH>;
- samsung,audio-routing =
+ audio-routing =
"HP", "HPOUT1L",
"HP", "HPOUT1R",
diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
index 3109591..6ec80f5 100644
--- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
@@ -9,14 +9,13 @@
maintainers:
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
const: samsung,midas-audio
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: The user-visible name of this sound complex.
-
cpu:
type: object
additionalProperties: false
@@ -38,6 +37,7 @@
- sound-dai
samsung,audio-routing:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
description: |
List of the connections between audio components; each entry is
@@ -45,6 +45,7 @@
being the connection's source; valid names for sources and sinks are
the WM1811's pins (as documented in its binding), and the jacks
on the board: HP, SPK, Main Mic, Sub Mic, Headset Mic.
+ Deprecated, use audio-routing.
mic-bias-supply:
description: Supply for the micbias on the Main microphone
@@ -62,14 +63,13 @@
required:
- compatible
- - model
- cpu
- codec
- - samsung,audio-routing
+ - audio-routing
- mic-bias-supply
- submic-bias-supply
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -84,7 +84,7 @@
mic-bias-supply = <&mic_bias_reg>;
submic-bias-supply = <&submic_bias_reg>;
- samsung,audio-routing =
+ audio-routing =
"HP", "HPOUT1L",
"HP", "HPOUT1R",
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
index c6751c4..b77284e 100644
--- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
@@ -10,6 +10,9 @@
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
oneOf:
@@ -24,10 +27,6 @@
- const: samsung,odroid-xu4-audio
deprecated: true
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: The user-visible name of this sound complex.
-
assigned-clock-parents: true
assigned-clock-rates: true
assigned-clocks: true
@@ -52,6 +51,7 @@
samsung,audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ deprecated: true
description: |
List of the connections between audio
components; each entry is a pair of strings, the first being the
@@ -61,6 +61,7 @@
For Odroid X2: "Headphone Jack", "Mic Jack", "DMIC"
For Odroid U3, XU3: "Headphone Jack", "Speakers"
For Odroid XU4: no entries
+ Deprecated, use audio-routing.
samsung,audio-widgets:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
@@ -70,18 +71,17 @@
required:
- compatible
- - model
- cpu
- codec
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
sound {
compatible = "hardkernel,odroid-xu3-audio";
model = "Odroid-XU3";
- samsung,audio-routing =
+ audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"IN1", "Mic Jack",
diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
index 491e080..7605925 100644
--- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
@@ -10,6 +10,9 @@
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
const: samsung,tm2-audio
@@ -32,6 +35,8 @@
being the connection's source; valid names for sources and sinks are the
WM5110's and MAX98504's pins and the jacks on the board: HP, SPK, Main
Mic, Sub Mic, Third Mic, Headset Mic.
+ Deprecated, use audio-routing.
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
i2s-controller:
@@ -44,20 +49,15 @@
mic-bias-gpios:
description: GPIO pin that enables the Main Mic bias regulator.
- model:
- description: The user-visible name of this sound complex.
- $ref: /schemas/types.yaml#/definitions/string
-
required:
- compatible
- audio-amplifier
- audio-codec
- - samsung,audio-routing
+ - audio-routing
- i2s-controller
- mic-bias-gpios
- - model
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -70,7 +70,7 @@
audio-amplifier = <&max98504>;
mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>;
model = "wm5110";
- samsung,audio-routing = "HP", "HPOUT1L",
+ audio-routing = "HP", "HPOUT1L",
"HP", "HPOUT1R",
"SPK", "SPKOUT",
"SPKOUT", "HPOUT2L",
diff --git a/Documentation/devicetree/bindings/sound/serial-midi.yaml b/Documentation/devicetree/bindings/sound/serial-midi.yaml
index 4afc293..f6a8073 100644
--- a/Documentation/devicetree/bindings/sound/serial-midi.yaml
+++ b/Documentation/devicetree/bindings/sound/serial-midi.yaml
@@ -20,7 +20,7 @@
parent serial device. If the standard MIDI baud of 31.25 kBaud is needed
(as would be the case if interfacing with arbitrary external MIDI devices),
configure the clocks of the parent serial device so that a requested baud of 38.4 kBaud
- resuts in the standard MIDI baud rate, and set the 'current-speed' property to 38400 (default)
+ results in the standard MIDI baud rate, and set the 'current-speed' property to 38400 (default)
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml
index b05e05c..59ac2d1 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
@@ -148,6 +148,15 @@
required:
- sound-dai
+ additional-devs:
+ type: object
+ description:
+ Additional devices used by the simple audio card.
+ patternProperties:
+ '^iio-aux(-.+)?$':
+ type: object
+ $ref: audio-iio-aux.yaml#
+
properties:
compatible:
contains:
@@ -187,6 +196,8 @@
$ref: "#/definitions/mclk-fs"
simple-audio-card,aux-devs:
$ref: "#/definitions/aux-devs"
+ simple-audio-card,additional-devs:
+ $ref: "#/definitions/additional-devs"
simple-audio-card,convert-rate:
$ref: "#/definitions/convert-rate"
simple-audio-card,convert-channels:
@@ -360,6 +371,48 @@
};
# --------------------
+# route audio to/from a codec through an amplifier
+# designed with a potentiometer driven by IIO:
+# --------------------
+ - |
+ sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,aux-devs = <&_in>, <&_out>;
+ simple-audio-card,routing =
+ "CODEC LEFTIN", "AMP_IN LEFT OUT",
+ "CODEC RIGHTIN", "AMP_IN RIGHT OUT",
+ "AMP_OUT LEFT IN", "CODEC LEFTOUT",
+ "AMP_OUT RIGHT IN", "CODEC RIGHTOUT";
+
+ simple-audio-card,additional-devs {
+ amp_out: iio-aux-out {
+ compatible = "audio-iio-aux";
+ io-channels = <&pot_out 0>, <&pot_out 1>;
+ io-channel-names = "LEFT", "RIGHT";
+ snd-control-invert-range = <1 1>;
+ sound-name-prefix = "AMP_OUT";
+ };
+
+ amp_in: iio_aux-in {
+ compatible = "audio-iio-aux";
+ io-channels = <&pot_in 0>, <&pot_in 1>;
+ io-channel-names = "LEFT", "RIGHT";
+ sound-name-prefix = "AMP_IN";
+ };
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&cpu>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&codec>;
+ clocks = <&clocks>;
+ };
+ };
+
+# --------------------
# Sampling Rate Conversion
# --------------------
- |
diff --git a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
index a970fd2..a48d040 100644
--- a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
@@ -17,6 +17,9 @@
- const: snps,designware-i2s
- enum:
- snps,designware-i2s
+ - starfive,jh7110-i2stx0
+ - starfive,jh7110-i2stx1
+ - starfive,jh7110-i2srx
reg:
maxItems: 1
@@ -29,15 +32,36 @@
maxItems: 1
clocks:
- description: Sampling rate reference clock
- maxItems: 1
+ items:
+ - description: Sampling rate reference clock
+ - description: APB clock
+ - description: Audio master clock
+ - description: Inner audio master clock source
+ - description: External audio master clock source
+ - description: Bit clock
+ - description: Left/right channel clock
+ - description: External bit clock
+ - description: External left/right channel clock
+ minItems: 1
clock-names:
- const: i2sclk
+ items:
+ - const: i2sclk
+ - const: apb
+ - const: mclk
+ - const: mclk_inner
+ - const: mclk_ext
+ - const: bclk
+ - const: lrck
+ - const: bclk_ext
+ - const: lrck_ext
+ minItems: 1
resets:
items:
- description: Optional controller resets
+ - description: controller reset of Sampling rate
+ minItems: 1
dmas:
items:
@@ -51,6 +75,17 @@
- const: rx
minItems: 1
+ starfive,syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller sys_syscon node.
+ - description: I2S-rx enabled control offset of SYS_SYSCONSAIF__SYSCFG register.
+ - description: I2S-rx enabled control mask
+ description:
+ The phandle to System Register Controller syscon node and the I2S-rx(ADC)
+ enabled control offset and mask of SYS_SYSCONSAIF__SYSCFG register.
+
allOf:
- $ref: dai-common.yaml#
- if:
@@ -66,6 +101,73 @@
properties:
"#sound-dai-cells":
const: 0
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: snps,designware-i2s
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ resets:
+ maxItems: 1
+ else:
+ properties:
+ resets:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-i2stx0
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ minItems: 5
+ maxItems: 5
+ required:
+ - resets
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-i2stx1
+ then:
+ properties:
+ clocks:
+ minItems: 9
+ maxItems: 9
+ clock-names:
+ minItems: 9
+ maxItems: 9
+ required:
+ - resets
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-i2srx
+ then:
+ properties:
+ clocks:
+ minItems: 9
+ maxItems: 9
+ clock-names:
+ minItems: 9
+ maxItems: 9
+ required:
+ - resets
+ - starfive,syscon
+ else:
+ properties:
+ starfive,syscon: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/sound-card-common.yaml b/Documentation/devicetree/bindings/sound/sound-card-common.yaml
new file mode 100644
index 0000000..3a94117
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sound-card-common.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/sound-card-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Board Sound Card Common Properties
+
+maintainers:
+ - Mark Brown <broonie@kernel.org>
+
+properties:
+ 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
+
+required:
+ - model
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/sprd-pcm.txt b/Documentation/devicetree/bindings/sound/sprd-pcm.txt
index 4b23e84..fbbcade 100644
--- a/Documentation/devicetree/bindings/sound/sprd-pcm.txt
+++ b/Documentation/devicetree/bindings/sound/sprd-pcm.txt
@@ -1,4 +1,4 @@
-* Spreadtrum DMA platfrom bindings
+* Spreadtrum DMA platform bindings
Required properties:
- compatible: Should be "sprd,pcm-platform".
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
index 56d206f..59df8a8 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
@@ -63,7 +63,7 @@
additionalProperties: false
description:
Two subnodes corresponding to SAI sub-block instances A et B
- can be defined. Subnode can be omitted for unsused sub-block.
+ can be defined. Subnode can be omitted for unused sub-block.
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
index 859d369..5b2874a 100644
--- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
@@ -13,7 +13,7 @@
description: |
The Infotainment board plugs into the Common Processor Board, the support of the
- extension board is extending the CPB audio support, decribed in:
+ extension board is extending the CPB audio support, described in:
sound/ti,j721e-cpb-audio.txt
The audio support on the Infotainment Expansion Board consists of McASP0
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
index 8d60e4e..a69e6c2 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
@@ -29,7 +29,7 @@
reg:
description:
I2C address, in multiple tas2781s case, all the i2c address
- aggreate as one Audio Device to support multiple audio slots.
+ aggregate as one Audio Device to support multiple audio slots.
maxItems: 8
minItems: 1
items:
diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
index c16e176..f3274bc 100644
--- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
+++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
@@ -32,7 +32,7 @@
reg:
maxItems: 1
description: |
- I2C addresss of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
+ I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
reset-gpios:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml
new file mode 100644
index 0000000..329260c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8904.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM8904/WM8912 audio codecs
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description: |
+ Pins on the device (for linking into audio routes):
+ IN1L, IN1R, IN2L, IN2R, IN3L, IN3R, HPOUTL, HPOUTR, LINEOUTL, LINEOUTR,
+ MICBIAS
+
+properties:
+ compatible:
+ enum:
+ - wlf,wm8904
+ - wlf,wm8912
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+ AVDD-supply: true
+ CPVDD-supply: true
+ DBVDD-supply: true
+ DCVDD-supply: true
+ MICVDD-supply: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - AVDD-supply
+ - CPVDD-supply
+ - DBVDD-supply
+ - DCVDD-supply
+ - MICVDD-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ AVDD-supply = <®_1p8v>;
+ CPVDD-supply = <®_1p8v>;
+ DBVDD-supply = <®_1p8v>;
+ DCVDD-supply = <®_1p8v>;
+ MICVDD-supply = <®_1p8v>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml
index ee8eba7..62e62c3 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml
@@ -26,6 +26,21 @@
'#sound-dai-cells':
const: 0
+ AVDD-supply:
+ description: Analogue supply.
+
+ DBVDD-supply:
+ description: Digital Buffer Supply.
+
+ DCVDD-supply:
+ description: Digital Core Supply.
+
+ SPKVDD1-supply:
+ description: Supply for speaker drivers 1.
+
+ SPKVDD2-supply:
+ description: Supply for speaker drivers 2.
+
wlf,capless:
type: boolean
description:
@@ -84,5 +99,10 @@
wlf,hp-cfg = <3 2 3>;
wlf,gpio-cfg = <1 3>;
wlf,shared-lrclk;
+ DCVDD-supply = <®_audio>;
+ DBVDD-supply = <®_audio>;
+ AVDD-supply = <®_audio>;
+ SPKVDD1-supply = <®_audio>;
+ SPKVDD2-supply = <®_audio>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt
deleted file mode 100644
index 66bf261..0000000
--- a/Documentation/devicetree/bindings/sound/wm8904.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-WM8904 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
- - compatible: "wlf,wm8904" or "wlf,wm8912"
- - reg: the I2C address of the device.
- - clock-names: "mclk"
- - clocks: reference to
- <Documentation/devicetree/bindings/clock/clock-bindings.txt>
-
-Pins on the device (for linking into audio routes):
-
- * IN1L
- * IN1R
- * IN2L
- * IN2R
- * IN3L
- * IN3R
- * HPOUTL
- * HPOUTR
- * LINEOUTL
- * LINEOUTR
- * MICBIAS
-
-Examples:
-
-codec: wm8904@1a {
- compatible = "wlf,wm8904";
- reg = <0x1a>;
- clocks = <&pck0>;
- clock-names = "mclk";
-};
diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
index fb44b89..7d60a96 100644
--- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
+++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
@@ -159,7 +159,7 @@
qcom,ports-hstart:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
- Identifying lowerst numbered coloum in SoundWire Frame,
+ Identifying lowerst numbered column in SoundWire Frame,
i.e. left edge of the Transport sub-frame for each port.
Out ports followed by In ports.
Value of 0xff indicates that this option is not implemented
@@ -176,7 +176,7 @@
qcom,ports-hstop:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
- Identifying highest numbered coloum in SoundWire Frame,
+ Identifying highest numbered column in SoundWire Frame,
i.e. the right edge of the Transport
sub-frame for each port. Out ports followed by In ports.
Value of 0xff indicates that this option is not implemented
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt
index 9887b07..d7668f4 100644
--- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt
@@ -1,4 +1,4 @@
-Broadcom BCM2835 auxiliar SPI1/2 controller
+Broadcom BCM2835 auxiliary SPI1/2 controller
The BCM2835 contains two forms of SPI master controller, one known simply as
SPI0, and the other known as the "Universal SPI Master"; part of the
@@ -9,7 +9,7 @@
- reg: Should contain register location and length for the spi block
- interrupts: Should contain shared interrupt of the aux block
- clocks: The clock feeding the SPI controller - needs to
- point to the auxiliar clock driver of the bcm2835,
+ point to the auxiliary clock driver of the bcm2835,
as this clock will enable the output gate for the specific
clock.
- cs-gpios: the cs-gpios (native cs is NOT supported)
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml
new file mode 100644
index 0000000..fa03cdd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/brcm,bcm63xx-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM6348/BCM6358 SPI controller
+
+maintainers:
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+description: |
+ Broadcom "Low Speed" SPI controller found in many older MIPS based Broadband
+ SoCs.
+
+ This controller has a limitation that can not keep the chip select line active
+ between the SPI transfers within the same SPI message. This can terminate the
+ transaction to some SPI devices prematurely. The issue can be worked around by
+ the controller's prepend mode.
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - brcm,bcm6368-spi
+ - brcm,bcm6362-spi
+ - brcm,bcm63268-spi
+ - const: brcm,bcm6358-spi
+ - enum:
+ - brcm,bcm6348-spi
+ - brcm,bcm6358-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI master reference clock
+
+ clock-names:
+ items:
+ - const: spi
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@10000800 {
+ compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi";
+ reg = <0x10000800 0x70c>;
+ interrupts = <1>;
+ clocks = <&clkctl 9>;
+ clock-names = "spi";
+ num-cs = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
index 28222aa..45975f4 100644
--- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
@@ -12,7 +12,7 @@
description: |
The Broadcom SPI controller is a SPI master found on various SOCs, including
- BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consits
+ BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consists
of:
MSPI : SPI master controller can read and write to a SPI slave device
BSPI : Broadcom SPI in combination with the MSPI hw IP provides acceleration
@@ -20,7 +20,7 @@
io with 3-byte and 4-byte addressing support.
Supported Broadcom SoCs have one instance of MSPI+BSPI controller IP.
- MSPI master can be used wihout BSPI. BRCMSTB SoCs have an additional instance
+ MSPI master can be used without BSPI. BRCMSTB SoCs have an additional instance
of a MSPI master without the BSPI to use with non flash slave devices that
use SPI protocol.
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index 4f15f9a..cca81f8 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -86,7 +86,17 @@
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: ref
+ - items:
+ - const: ref
+ - const: ahb
+ - const: apb
cdns,fifo-depth:
description:
diff --git a/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml b/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml
new file mode 100644
index 0000000..de9d32f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/loongson,ls2k-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson SPI controller
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls2k1000-spi
+ - items:
+ - enum:
+ - loongson,ls2k0500-spi
+ - const: loongson,ls2k1000-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi0: spi@1fff0220{
+ compatible = "loongson,ls2k1000-spi";
+ reg = <0x1fff0220 0x10>;
+ clocks = <&clk 17>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
deleted file mode 100644
index db8e0d7..0000000
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-NVIDIA Tegra114 SPI controller.
-
-Required properties:
-- compatible : For Tegra114, must contain "nvidia,tegra114-spi".
- Otherwise, must contain '"nvidia,<chip>-spi", "nvidia,tegra114-spi"' where
- <chip> is tegra124, tegra132, or tegra210.
-- reg: Should contain SPI registers location and length.
-- interrupts: Should contain SPI interrupts.
-- clock-names : Must include the following entries:
- - spi
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - spi
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-Optional properties:
-- nvidia,tx-clk-tap-delay: Delays the clock going out to the external device
- with this tap value. This property is used to tune the outgoing data from
- Tegra SPI master with respect to outgoing Tegra SPI master clock.
- Tap values vary based on the platform design trace lengths from Tegra SPI
- to corresponding slave devices. Valid tap values are from 0 thru 63.
-- nvidia,rx-clk-tap-delay: Delays the clock coming in from the external device
- with this tap value. This property is used to adjust the Tegra SPI master
- clock with respect to the data from the SPI slave device.
- Tap values vary based on the platform design trace lengths from Tegra SPI
- to corresponding slave devices. Valid tap values are from 0 thru 63.
-
-Example:
-
-spi@7000d600 {
- compatible = "nvidia,tegra114-spi";
- reg = <0x7000d600 0x200>;
- interrupts = <0 82 0x04>;
- spi-max-frequency = <25000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car 44>;
- clock-names = "spi";
- resets = <&tegra_car 44>;
- reset-names = "spi";
- dmas = <&apbdma 16>, <&apbdma 16>;
- dma-names = "rx", "tx";
- <spi-client>@<bus_num> {
- ...
- ...
- nvidia,rx-clk-tap-delay = <0>;
- nvidia,tx-clk-tap-delay = <16>;
- ...
- };
-
-};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml
new file mode 100644
index 0000000..58222ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,tegra114-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra114 SPI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra114-spi
+ - items:
+ - enum:
+ - nvidia,tegra210-spi
+ - nvidia,tegra124-spi
+ - const: nvidia,tegra114-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI module clock
+
+ clock-names:
+ items:
+ - const: spi
+
+ resets:
+ items:
+ - description: SPI module reset
+
+ reset-names:
+ items:
+ - const: spi
+
+ dmas:
+ items:
+ - description: DMA channel for the reception FIFO
+ - description: DMA channel for the transmission FIFO
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+allOf:
+ - $ref: spi-controller.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ spi@7000d600 {
+ compatible = "nvidia,tegra114-spi";
+ reg = <0x7000d600 0x200>;
+ interrupts = <0 82 0x04>;
+ clocks = <&tegra_car 44>;
+ clock-names = "spi";
+ resets = <&tegra_car 44>;
+ reset-names = "spi";
+ dmas = <&apbdma 16>, <&apbdma 16>;
+ dma-names = "rx", "tx";
+
+ spi-max-frequency = <25000000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ nvidia,rx-clk-tap-delay = <0>;
+ nvidia,tx-clk-tap-delay = <16>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
deleted file mode 100644
index c212491..0000000
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-NVIDIA Tegra20 SFLASH controller.
-
-Required properties:
-- compatible : should be "nvidia,tegra20-sflash".
-- reg: Should contain SFLASH registers location and length.
-- interrupts: Should contain SFLASH interrupts.
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - spi
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Example:
-
-spi@7000c380 {
- compatible = "nvidia,tegra20-sflash";
- reg = <0x7000c380 0x80>;
- interrupts = <0 39 0x04>;
- spi-max-frequency = <25000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car 43>;
- resets = <&tegra_car 43>;
- reset-names = "spi";
- dmas = <&apbdma 11>, <&apbdma 11>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml
new file mode 100644
index 0000000..e245bad
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,tegra20-sflash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 SFLASH controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra20-sflash
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: spi
+
+ dmas:
+ items:
+ - description: DMA channel used for reception
+ - description: DMA channel used for transmission
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+allOf:
+ - $ref: spi-controller.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@7000c380 {
+ compatible = "nvidia,tegra20-sflash";
+ reg = <0x7000c380 0x80>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <25000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car TEGRA20_CLK_SPI>;
+ resets = <&tegra_car 43>;
+ reset-names = "spi";
+ dmas = <&apbdma 11>, <&apbdma 11>;
+ dma-names = "rx", "tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
deleted file mode 100644
index 40d80b9..0000000
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-NVIDIA Tegra20/Tegra30 SLINK controller.
-
-Required properties:
-- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
-- reg: Should contain SLINK registers location and length.
-- interrupts: Should contain SLINK interrupts.
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - spi
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Example:
-
-spi@7000d600 {
- compatible = "nvidia,tegra20-slink";
- reg = <0x7000d600 0x200>;
- interrupts = <0 82 0x04>;
- spi-max-frequency = <25000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car 44>;
- resets = <&tegra_car 44>;
- reset-names = "spi";
- dmas = <&apbdma 16>, <&apbdma 16>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml
new file mode 100644
index 0000000..291c25e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,tegra20-slink.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20/30 SLINK controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-slink
+ - nvidia,tegra30-slink
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: spi
+
+ dmas:
+ items:
+ - description: DMA channel used for reception
+ - description: DMA channel used for transmission
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ operating-points-v2:
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ power-domains:
+ items:
+ - description: phandle to the core power domain
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+allOf:
+ - $ref: spi-controller.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@7000d600 {
+ compatible = "nvidia,tegra20-slink";
+ reg = <0x7000d600 0x200>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <25000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car TEGRA20_CLK_SBC2>;
+ resets = <&tegra_car 44>;
+ reset-names = "spi";
+ dmas = <&apbdma 16>, <&apbdma 16>;
+ dma-names = "rx", "tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.yaml b/Documentation/devicetree/bindings/spi/omap-spi.yaml
index 352affa..ff4d361 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/omap-spi.yaml
@@ -68,7 +68,7 @@
dma-names:
description:
List of DMA request names. These strings correspond 1:1 with
- the DMA sepecifiers listed in dmas. The string names is to be
+ the DMA specifiers listed in dmas. The string names is to be
"rxN" and "txN" for RX and TX requests, respectively. Where N
is the chip select number.
minItems: 1
diff --git a/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt b/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt
deleted file mode 100644
index 1c16f66..0000000
--- a/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Binding for Broadcom BCM6348/BCM6358 SPI controller
-
-Required properties:
-- compatible: must contain one of "brcm,bcm6348-spi", "brcm,bcm6358-spi".
-- reg: Base address and size of the controllers memory area.
-- interrupts: Interrupt for the SPI block.
-- clocks: phandle of the SPI clock.
-- clock-names: has to be "spi".
-- #address-cells: <1>, as required by generic SPI binding.
-- #size-cells: <0>, also as required by generic SPI binding.
-
-Optional properties:
-- num-cs: some controllers have less than 8 cs signals. Defaults to 8
- if absent.
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
- spi@10000800 {
- compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi";
- reg = <0x10000800 0x70c>;
-
- interrupts = <1>;
-
- clocks = <&clkctl 9>;
- clock-names = "spi";
-
- num-cs = <5>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
index b755273..d4b61b0 100644
--- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
@@ -49,6 +49,12 @@
enum: [ 0, 1 ]
default: 0
+ power-domains:
+ maxItems: 1
+
+ label:
+ description: Descriptive name of the SPI controller.
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
index e914250..727c534 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
@@ -63,6 +63,9 @@
maximum: 2
default: 1
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
index a813c97..7fd59114 100644
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
@@ -45,6 +45,9 @@
- const: fspi_en
- const: fspi
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
index 91e540a..5e5a704 100644
--- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
@@ -11,6 +11,7 @@
allOf:
- $ref: spi-controller.yaml#
+ - $ref: /schemas/arm/primecell.yaml#
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
diff --git a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
index 4bbf6db..61c784e 100644
--- a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
@@ -15,7 +15,9 @@
properties:
compatible:
- const: qcom,msm8974-ocmem
+ enum:
+ - qcom,msm8226-ocmem # v1.1.0
+ - qcom,msm8974-ocmem # v1.4.0
reg:
items:
@@ -28,11 +30,13 @@
- const: mem
clocks:
+ minItems: 1
items:
- description: Core clock
- description: Interface clock
clock-names:
+ minItems: 1
items:
- const: core
- const: iface
@@ -58,6 +62,26 @@
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8974-ocmem
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ else:
+ properties:
+ clocks:
+ minItems: 1
+ clock-names:
+ minItems: 1
+
patternProperties:
"-sram@[0-9a-f]+$":
type: object
diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
new file mode 100644
index 0000000..7538469
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/loongson,ls2k-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal sensors on Loongson-2 SoCs
+
+maintainers:
+ - zhanghongchen <zhanghongchen@loongson.cn>
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls2k1000-thermal
+ - items:
+ - enum:
+ - loongson,ls2k2000-thermal
+ - const: loongson,ls2k1000-thermal
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ thermal: thermal-sensor@1fe01500 {
+ compatible = "loongson,ls2k1000-thermal";
+ reg = <0x1fe01500 0x30>;
+ interrupt-parent = <&liointc0>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
deleted file mode 100644
index aea4a2a..0000000
--- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
+++ /dev/null
@@ -1,238 +0,0 @@
-Tegra124 SOCTHERM thermal management system
-
-The SOCTHERM IP block contains thermal sensors, support for polled
-or interrupt-based thermal monitoring, CPU and GPU throttling based
-on temperature trip points, and handling external overcurrent
-notifications. It is also used to manage emergency shutdown in an
-overheating situation.
-
-Required properties :
-- compatible : For Tegra124, must contain "nvidia,tegra124-soctherm".
- For Tegra132, must contain "nvidia,tegra132-soctherm".
- For Tegra210, must contain "nvidia,tegra210-soctherm".
-- reg : Should contain at least 2 entries for each entry in reg-names:
- - SOCTHERM register set
- - Tegra CAR register set: Required for Tegra124 and Tegra210.
- - CCROC register set: Required for Tegra132.
-- reg-names : Should contain at least 2 entries:
- - soctherm-reg
- - car-reg
- - ccroc-reg
-- interrupts : Defines the interrupt used by SOCTHERM
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- - tsensor
- - soctherm
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - soctherm
-- #thermal-sensor-cells : Should be 1. For a description of this property, see
- Documentation/devicetree/bindings/thermal/thermal-sensor.yaml.
- See <dt-bindings/thermal/tegra124-soctherm.h> for a list of valid values
- when referring to thermal sensors.
-- throttle-cfgs: A sub-node which is a container of configuration for each
- hardware throttle events. These events can be set as cooling devices.
- * throttle events: Sub-nodes must be named as "light" or "heavy".
- Properties:
- - nvidia,priority: Each throttles has its own throttle settings, so the
- SW need to set priorities for various throttle, the HW arbiter can select
- the final throttle settings.
- Bigger value indicates higher priority, In general, higher priority
- translates to lower target frequency. SW needs to ensure that critical
- thermal alarms are given higher priority, and ensure that there is
- no race if priority of two vectors is set to the same value.
- The range of this value is 1~100.
- - nvidia,cpu-throt-percent: This property is for Tegra124 and Tegra210.
- It is the throttling depth of pulse skippers, it's the percentage
- throttling.
- - nvidia,cpu-throt-level: This property is only for Tegra132, it is the
- level of pulse skippers, which used to throttle clock frequencies. It
- indicates cpu clock throttling depth, and the depth can be programmed.
- Must set as following values:
- TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED
- TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE
- - nvidia,gpu-throt-level: This property is for Tegra124 and Tegra210.
- It is the level of pulse skippers, which used to throttle clock
- frequencies. It indicates gpu clock throttling depth and can be
- programmed to any of the following values which represent a throttling
- percentage:
- TEGRA_SOCTHERM_THROT_LEVEL_NONE (0%)
- TEGRA_SOCTHERM_THROT_LEVEL_LOW (50%),
- TEGRA_SOCTHERM_THROT_LEVEL_MED (75%),
- TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%).
- - #cooling-cells: Should be 1. This cooling device only support on/off state.
- For a description of this property see:
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
-
- Optional properties: The following properties are T210 specific and
- valid only for OCx throttle events.
- - nvidia,count-threshold: Specifies the number of OC events that are
- required for triggering an interrupt. Interrupts are not triggered if
- the property is missing. A value of 0 will interrupt on every OC alarm.
- - nvidia,polarity-active-low: Configures the polarity of the OC alaram
- signal. If present, this means assert low, otherwise assert high.
- - nvidia,alarm-filter: Number of clocks to filter event. When the filter
- expires (which means the OC event has not occurred for a long time),
- the counter is cleared and filter is rearmed. Default value is 0.
- - nvidia,throttle-period-us: Specifies the number of uSec for which
- throttling is engaged after the OC event is deasserted. Default value
- is 0.
-
-Optional properties:
-- nvidia,thermtrips : When present, this property specifies the temperature at
- which the soctherm hardware will assert the thermal trigger signal to the
- Power Management IC, which can be configured to reset or shutdown the device.
- It is an array of pairs where each pair represents a tsensor id followed by a
- temperature in milli Celcius. In the absence of this property the critical
- trip point will be used for thermtrip temperature.
-
-Note:
-- the "critical" type trip points will be used to set the temperature at which
-the SOC_THERM hardware will assert a thermal trigger if the "nvidia,thermtrips"
-property is missing. When the thermtrips property is present, the breach of a
-critical trip point is reported back to the thermal framework to implement
-software shutdown.
-
-- the "hot" type trip points will be set to SOC_THERM hardware as the throttle
-temperature. Once the temperature of this thermal zone is higher
-than it, it will trigger the HW throttle event.
-
-Example :
-
- soctherm@700e2000 {
- compatible = "nvidia,tegra124-soctherm";
- reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
- 0x0 0x60006000 0x0 0x400 /* CAR reg_base */
- reg-names = "soctherm-reg", "car-reg";
- interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
- <&tegra_car TEGRA124_CLK_SOC_THERM>;
- clock-names = "tsensor", "soctherm";
- resets = <&tegra_car 78>;
- reset-names = "soctherm";
-
- #thermal-sensor-cells = <1>;
-
- nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500
- TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
-
- throttle-cfgs {
- /*
- * When the "heavy" cooling device triggered,
- * the HW will skip cpu clock's pulse in 85% depth,
- * skip gpu clock's pulse in 85% level
- */
- throttle_heavy: heavy {
- nvidia,priority = <100>;
- nvidia,cpu-throt-percent = <85>;
- nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * When the "light" cooling device triggered,
- * the HW will skip cpu clock's pulse in 50% depth,
- * skip gpu clock's pulse in 50% level
- */
- throttle_light: light {
- nvidia,priority = <80>;
- nvidia,cpu-throt-percent = <50>;
- nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * If these two devices are triggered in same time, the HW throttle
- * arbiter will select the highest priority as the final throttle
- * settings to skip cpu pulse.
- */
-
- throttle_oc1: oc1 {
- nvidia,priority = <50>;
- nvidia,polarity-active-low;
- nvidia,count-threshold = <100>;
- nvidia,alarm-filter = <5100000>;
- nvidia,throttle-period-us = <0>;
- nvidia,cpu-throt-percent = <75>;
- nvidia,gpu-throt-level =
- <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
- };
- };
- };
-
-Example: referring to Tegra132's "reg", "reg-names" and "throttle-cfgs" :
-
- soctherm@700e2000 {
- compatible = "nvidia,tegra132-soctherm";
- reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
- 0x0 0x70040000 0x0 0x200>; /* CCROC reg_base */;
- reg-names = "soctherm-reg", "ccroc-reg";
-
- throttle-cfgs {
- /*
- * When the "heavy" cooling device triggered,
- * the HW will skip cpu clock's pulse in HIGH level
- */
- throttle_heavy: heavy {
- nvidia,priority = <100>;
- nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * When the "light" cooling device triggered,
- * the HW will skip cpu clock's pulse in MED level
- */
- throttle_light: light {
- nvidia,priority = <80>;
- nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * If these two devices are triggered in same time, the HW throttle
- * arbiter will select the highest priority as the final throttle
- * settings to skip cpu pulse.
- */
-
- };
- };
-
-Example: referring to thermal sensors :
-
- thermal-zones {
- cpu {
- polling-delay-passive = <1000>;
- polling-delay = <1000>;
-
- thermal-sensors =
- <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>;
-
- trips {
- cpu_shutdown_trip: shutdown-trip {
- temperature = <102500>;
- hysteresis = <1000>;
- type = "critical";
- };
-
- cpu_throttle_trip: throttle-trip {
- temperature = <100000>;
- hysteresis = <1000>;
- type = "hot";
- };
- };
-
- cooling-maps {
- map0 {
- trip = <&cpu_throttle_trip>;
- cooling-device = <&throttle_heavy 1 1>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml
new file mode 100644
index 0000000..04a2ba1
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml
@@ -0,0 +1,380 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/nvidia,tegra124-soctherm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra124 SOCTHERM Thermal Management System
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The SOCTHERM IP block contains thermal sensors, support for
+ polled or interrupt-based thermal monitoring, CPU and GPU throttling based
+ on temperature trip points, and handling external overcurrent notifications.
+ It is also used to manage emergency shutdown in an overheating situation.
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra124-soctherm
+ - nvidia,tegra132-soctherm
+ - nvidia,tegra210-soctherm
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: module interrupt
+ - description: EDP interrupt
+
+ interrupt-names:
+ items:
+ - const: thermal
+ - const: edp
+
+ clocks:
+ items:
+ - description: thermal sensor clock
+ - description: module clock
+
+ clock-names:
+ items:
+ - const: tsensor
+ - const: soctherm
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: soctherm
+
+ "#thermal-sensor-cells":
+ const: 1
+
+ throttle-cfgs:
+ $ref: thermal-cooling-devices.yaml
+ description: A sub-node which is a container of configuration for each
+ hardware throttle events. These events can be set as cooling devices.
+ Throttle event sub-nodes must be named as "light" or "heavy".
+ unevaluatedProperties: false
+ patternProperties:
+ "^(light|heavy|oc1)$":
+ type: object
+ properties:
+ nvidia,priority:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 100
+ description: Each throttles has its own throttle settings, so the
+ SW need to set priorities for various throttle, the HW arbiter
+ can select the final throttle settings. Bigger value indicates
+ higher priority, In general, higher priority translates to lower
+ target frequency. SW needs to ensure that critical thermal
+ alarms are given higher priority, and ensure that there is no
+ race if priority of two vectors is set to the same value.
+
+ nvidia,cpu-throt-percent:
+ description: This property is for Tegra124 and Tegra210. It is the
+ throttling depth of pulse skippers, it's the percentage
+ throttling.
+ minimum: 0
+ maximum: 100
+
+ nvidia,cpu-throt-level:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This property is only for Tegra132, it is the level
+ of pulse skippers, which used to throttle clock frequencies. It
+ indicates cpu clock throttling depth, and the depth can be
+ programmed.
+ enum:
+ # none (TEGRA_SOCTHERM_THROT_LEVEL_NONE)
+ - 0
+ # low (TEGRA_SOCTHERM_THROT_LEVEL_LOW)
+ - 1
+ # medium (TEGRA_SOCTHERM_THROT_LEVEL_MED)
+ - 2
+ # high (TEGRA_SOCTHERM_THROT_LEVEL_HIGH)
+ - 3
+
+ nvidia,gpu-throt-level:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This property is for Tegra124 and Tegra210. It is the
+ level of pulse skippers, which used to throttle clock
+ frequencies. It indicates gpu clock throttling depth and can be
+ programmed to any of the following values which represent a
+ throttling percentage.
+ enum:
+ # none (0%, TEGRA_SOCTHERM_THROT_LEVEL_NONE)
+ - 0
+ # low (50%, TEGRA_SOCTHERM_THROT_LEVEL_LOW)
+ - 1
+ # medium (75%, TEGRA_SOCTHERM_THROT_LEVEL_MED)
+ - 2
+ # high (85%, TEGRA_SOCTHERM_THROT_LEVEL_HIGH)
+ - 3
+
+ # optional
+ # Tegra210 specific and valid only for OCx throttle events
+ nvidia,count-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Specifies the number of OC events that are required
+ for triggering an interrupt. Interrupts are not triggered if the
+ property is missing. A value of 0 will interrupt on every OC
+ alarm.
+
+ nvidia,polarity-active-low:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Configures the polarity of the OC alaram signal. If
+ present, this means assert low, otherwise assert high.
+
+ nvidia,alarm-filter:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of clocks to filter event. When the filter
+ expires (which means the OC event has not occurred for a long
+ time), the counter is cleared and filter is rearmed.
+ default: 0
+
+ nvidia,throttle-period-us:
+ description: Specifies the number of microseconds for which
+ throttling is engaged after the OC event is deasserted.
+ default: 0
+
+ # optional
+ nvidia,thermtrips:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ When present, this property specifies the temperature at which the
+ SOCTHERM hardware will assert the thermal trigger signal to the Power
+ Management IC, which can be configured to reset or shutdown the device.
+ It is an array of pairs where each pair represents a tsensor ID followed
+ by a temperature in milli Celcius. In the absence of this property the
+ critical trip point will be used for thermtrip temperature.
+
+ Note:
+ - the "critical" type trip points will be used to set the temperature at
+ which the SOCTHERM hardware will assert a thermal trigger if the
+ "nvidia,thermtrips" property is missing. When the thermtrips property
+ is present, the breach of a critical trip point is reported back to
+ the thermal framework to implement software shutdown.
+
+ - the "hot" type trip points will be set to SOCTHERM hardware as the
+ throttle temperature. Once the temperature of this thermal zone is
+ higher than it, it will trigger the HW throttle event.
+ items:
+ items:
+ - description: sensor ID
+ oneOf:
+ - description: CPU sensor
+ const: 0
+ - description: MEM sensor
+ const: 1
+ - description: GPU sensor
+ const: 2
+ - description: PLLX sensor
+ const: 3
+ - description: temperature threshold (in millidegree Celsius)
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#thermal-sensor-cells"
+
+allOf:
+ - $ref: thermal-sensor.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra124-soctherm
+ - nvidia,tegra210-soctherm
+ then:
+ properties:
+ reg:
+ items:
+ - description: SOCTHERM register set
+ - description: clock and reset controller registers
+
+ reg-names:
+ items:
+ - const: soctherm-reg
+ - const: car-reg
+
+ else:
+ properties:
+ reg:
+ items:
+ - description: SOCTHERM register set
+ - description: CCROC registers
+
+ reg-names:
+ items:
+ - const: soctherm-reg
+ - const: ccroc-reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/thermal/tegra124-soctherm.h>
+
+ soctherm@700e2000 {
+ compatible = "nvidia,tegra124-soctherm";
+ reg = <0x700e2000 0x600>, /* SOC_THERM reg_base */
+ <0x60006000 0x400>; /* CAR reg_base */
+ reg-names = "soctherm-reg", "car-reg";
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "thermal", "edp";
+ clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+ <&tegra_car TEGRA124_CLK_SOC_THERM>;
+ clock-names = "tsensor", "soctherm";
+ resets = <&tegra_car 78>;
+ reset-names = "soctherm";
+
+ #thermal-sensor-cells = <1>;
+
+ nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500>,
+ <TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
+
+ throttle-cfgs {
+ /*
+ * When the "heavy" cooling device triggered,
+ * the HW will skip cpu clock's pulse in 85% depth,
+ * skip gpu clock's pulse in 85% level
+ */
+ heavy {
+ nvidia,priority = <100>;
+ nvidia,cpu-throt-percent = <85>;
+ nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * When the "light" cooling device triggered,
+ * the HW will skip cpu clock's pulse in 50% depth,
+ * skip gpu clock's pulse in 50% level
+ */
+ light {
+ nvidia,priority = <80>;
+ nvidia,cpu-throt-percent = <50>;
+ nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * If these two devices are triggered in same time, the HW throttle
+ * arbiter will select the highest priority as the final throttle
+ * settings to skip cpu pulse.
+ */
+
+ oc1 {
+ nvidia,priority = <50>;
+ nvidia,polarity-active-low;
+ nvidia,count-threshold = <100>;
+ nvidia,alarm-filter = <5100000>;
+ nvidia,throttle-period-us = <0>;
+ nvidia,cpu-throt-percent = <75>;
+ nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
+ };
+ };
+ };
+
+ # referring to Tegra132's "reg", "reg-names" and "throttle-cfgs"
+ - |
+ thermal-sensor@700e2000 {
+ compatible = "nvidia,tegra132-soctherm";
+ reg = <0x700e2000 0x600>, /* SOC_THERM reg_base */
+ <0x70040000 0x200>; /* CCROC reg_base */
+ reg-names = "soctherm-reg", "ccroc-reg";
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "thermal", "edp";
+ clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+ <&tegra_car TEGRA124_CLK_SOC_THERM>;
+ clock-names = "tsensor", "soctherm";
+ resets = <&tegra_car 78>;
+ reset-names = "soctherm";
+ #thermal-sensor-cells = <1>;
+
+ throttle-cfgs {
+ /*
+ * When the "heavy" cooling device triggered,
+ * the HW will skip cpu clock's pulse in HIGH level
+ */
+ heavy {
+ nvidia,priority = <100>;
+ nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * When the "light" cooling device triggered,
+ * the HW will skip cpu clock's pulse in MED level
+ */
+ light {
+ nvidia,priority = <80>;
+ nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * If these two devices are triggered in same time, the HW throttle
+ * arbiter will select the highest priority as the final throttle
+ * settings to skip cpu pulse.
+ */
+ };
+ };
+
+ # referring to thermal sensors
+ - |
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>;
+
+ trips {
+ cpu_shutdown_trip: shutdown-trip {
+ temperature = <102500>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+
+ cpu_throttle_trip: throttle-trip {
+ temperature = <100000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_throttle_trip>;
+ cooling-device = <&throttle_heavy 1 1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
index 92762ef..5ff72ce 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
@@ -8,7 +8,7 @@
title: Qualcomm Limits Management Hardware(LMh)
maintainers:
- - Thara Gopinath <thara.gopinath@linaro.org>
+ - Thara Gopinath <thara.gopinath@gmail.com>
description:
Limits Management Hardware(LMh) is a hardware infrastructure on some
diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
index 2d14610..585b5f5 100644
--- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
+++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
@@ -8,7 +8,7 @@
description: |
For a description of the TCU hardware and drivers, have a look at
- Documentation/mips/ingenic-tcu.rst.
+ Documentation/arch/mips/ingenic-tcu.rst.
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt b/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt
deleted file mode 100644
index d191612..0000000
--- a/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Oxford Semiconductor OXNAS SoCs Family RPS Timer
-================================================
-
-Required properties:
-- compatible: Should be "oxsemi,ox810se-rps-timer" or "oxsemi,ox820-rps-timer"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : The interrupts of the two timers
-- clocks : The phandle of the timer clock source
-
-example:
-
-timer0: timer@200 {
- compatible = "oxsemi,ox810se-rps-timer";
- reg = <0x200 0x40>;
- clocks = <&rpsclk>;
- interrupts = <4 5>;
-};
diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
index 147ef3e7..b02ab0a 100644
--- a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
+++ b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
@@ -1,7 +1,7 @@
Synopsys ARC Local Timer with Interrupt Capabilities
- Found on all ARC CPUs (ARC700/ARCHS)
- Can be optionally programmed to interrupt on Limit
-- Two idential copies TIMER0 and TIMER1 exist in ARC cores and historically
+- Two identical copies TIMER0 and TIMER1 exist in ARC cores and historically
TIMER0 used as clockevent provider (true for all ARC cores)
TIMER1 used for clocksource (mandatory for ARC700, optional for ARC HS)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index ba2bfb5..cd58179a 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -119,6 +119,10 @@
- fsl,mpr121
# Monolithic Power Systems Inc. multi-phase controller mp2888
- mps,mp2888
+ # Monolithic Power Systems Inc. multi-phase controller mp2971
+ - mps,mp2971
+ # Monolithic Power Systems Inc. multi-phase controller mp2973
+ - mps,mp2973
# Monolithic Power Systems Inc. multi-phase controller mp2975
- mps,mp2975
# Honeywell Humidicon HIH-6130 humidity/temperature sensor
@@ -193,13 +197,13 @@
- maxim,max1237
# Temperature Sensor, I2C interface
- maxim,max1619
- # 10-bit 10 kOhm linear programable voltage divider
+ # 10-bit 10 kOhm linear programmable voltage divider
- maxim,max5481
- # 10-bit 50 kOhm linear programable voltage divider
+ # 10-bit 50 kOhm linear programmable voltage divider
- maxim,max5482
- # 10-bit 10 kOhm linear programable variable resistor
+ # 10-bit 10 kOhm linear programmable variable resistor
- maxim,max5483
- # 10-bit 50 kOhm linear programable variable resistor
+ # 10-bit 50 kOhm linear programmable variable resistor
- maxim,max5484
# PECI-to-I2C translator for PECI-to-SMBus/I2C protocol conversion
- maxim,max6621
@@ -291,8 +295,6 @@
- miramems,da311
# Temperature sensor with integrated fan control
- national,lm63
- # I2C TEMP SENSOR
- - national,lm75
# Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
- national,lm80
# Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
@@ -315,6 +317,8 @@
- plx,pex8648
# Pulsedlight LIDAR range-finding sensor
- pulsedlight,lidar-lite-v2
+ # Renesas HS3001 Temperature and Relative Humidity Sensors
+ - renesas,hs3001
# Renesas ISL29501 time-of-flight sensor
- renesas,isl29501
# Rohm DH2228FV
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index bdfa86a..462ead5 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -29,6 +29,7 @@
- qcom,sa8775p-ufshc
- qcom,sc8280xp-ufshc
- qcom,sdm845-ufshc
+ - qcom,sm6115-ufshc
- qcom,sm6350-ufshc
- qcom,sm8150-ufshc
- qcom,sm8250-ufshc
@@ -79,6 +80,11 @@
minItems: 1
maxItems: 2
+ reg-names:
+ items:
+ - const: std
+ - const: ice
+
required-opps:
maxItems: 1
@@ -134,6 +140,8 @@
reg:
minItems: 1
maxItems: 1
+ reg-names:
+ maxItems: 1
- if:
properties:
@@ -162,6 +170,10 @@
reg:
minItems: 2
maxItems: 2
+ reg-names:
+ minItems: 2
+ required:
+ - reg-names
- if:
properties:
@@ -190,6 +202,37 @@
reg:
minItems: 1
maxItems: 1
+ reg-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6115-ufshc
+ then:
+ properties:
+ clocks:
+ minItems: 8
+ maxItems: 8
+ clock-names:
+ items:
+ - const: core_clk
+ - const: bus_aggr_clk
+ - const: iface_clk
+ - const: core_clk_unipro
+ - const: ref_clk
+ - const: tx_lane0_sync_clk
+ - const: rx_lane0_sync_clk
+ - const: ice_core_clk
+ reg:
+ minItems: 2
+ maxItems: 2
+ reg-names:
+ minItems: 2
+ required:
+ - reg-names
# TODO: define clock bindings for qcom,msm8994-ufshc
@@ -274,5 +317,6 @@
<0 0>,
<0 0>,
<0 0>;
+ qcom,ice = <&ice>;
};
};
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index 47a4e9e..bbaee4f5 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -74,7 +74,7 @@
Specifies max. load that can be drawn from VCCQ2 supply.
dependencies:
- freq-table-hz: [ 'clocks' ]
+ freq-table-hz: [ clocks ]
required:
- interrupts
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
index 7824028..1394557 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
@@ -34,6 +34,7 @@
- fsl,imx23-usb
- fsl,imx25-usb
- fsl,imx28-usb
+ - fsl,imx35-usb
- fsl,imx50-usb
- fsl,imx51-usb
- fsl,imx53-usb
@@ -76,11 +77,11 @@
clocks:
minItems: 1
- maxItems: 2
+ maxItems: 3
clock-names:
minItems: 1
- maxItems: 2
+ maxItems: 3
dr_mode: true
@@ -167,7 +168,7 @@
at RTL is 0, so this property only affects siTD.
If this property is not set, the max packet size is 1023 bytes, and
- if the total of packet size for pervious transactions are more than
+ if the total of packet size for previous transactions are more than
256 bytes, it can't accept any transactions within this frame. The
use case is single transaction, but higher frame rate.
@@ -292,6 +293,18 @@
minimum: 0x0
maximum: 0xf
+ fsl,picophy-rise-fall-time-adjust:
+ description:
+ HS Transmitter Rise/Fall Time Adjustment. Adjust the rise/fall times
+ of the high-speed transmitter waveform. It has no unit. The rise/fall
+ time will be increased or decreased by a certain percentage relative
+ to design default time. (0:-10%; 1:design default; 2:+15%; 3:+20%)
+ Details can refer to TXRISETUNE0 bit of USBNC_n_PHY_CFG1.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 1
+
usb-phy:
description: phandle for the PHY device. Use "phys" instead.
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
index 75eec4a..89fc9a4 100644
--- a/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
+++ b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
@@ -43,10 +43,8 @@
patternProperties:
'^connector@[01]$':
$ref: /schemas/connector/usb-connector.yaml#
- unevaluatedProperties: false
- properties:
- reg:
- maxItems: 1
+ required:
+ - reg
required:
- compatible
diff --git a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml
new file mode 100644
index 0000000..47add0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/cypress,hx3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress HX3 USB 3.0 hub controller family
+
+maintainers:
+ - Benjamin Bara <benjamin.bara@skidata.com>
+
+allOf:
+ - $ref: usb-device.yaml#
+
+properties:
+ compatible:
+ enum:
+ - usb4b4,6504
+ - usb4b4,6506
+
+ reg: true
+
+ reset-gpios:
+ items:
+ - description: GPIO specifier for RESETN pin.
+
+ vdd-supply:
+ description:
+ 1V2 power supply (VDD_EFUSE, AVDD12, DVDD12).
+
+ vdd2-supply:
+ description:
+ 3V3 power supply (AVDD33, VDD_IO).
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+required:
+ - compatible
+ - reg
+ - peer-hub
+ - vdd-supply
+ - vdd2-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb4b4,6504";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_1v2_usb>;
+ vdd2-supply = <®_3v3_usb>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb4b4,6506";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_1v2_usb>;
+ vdd2-supply = <®_3v3_usb>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index 3fb4feb..9ea1e4c 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -52,7 +52,7 @@
fsl,permanently-attached:
type: boolean
description:
- Indicates if the device atached to a downstream port is
+ Indicates if the device attached to a downstream port is
permanently attached.
fsl,disable-port-power-control:
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index b956bb5..87986c4 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -38,6 +38,7 @@
- allwinner,sun8i-a83t-ehci
- allwinner,sun8i-h3-ehci
- allwinner,sun8i-r40-ehci
+ - allwinner,sun8i-v3s-ehci
- allwinner,sun9i-a80-ehci
- allwinner,sun20i-d1-ehci
- aspeed,ast2400-ehci
@@ -67,6 +68,7 @@
- const: generic-ehci
- items:
- enum:
+ - atmel,at91sam9g45-ehci
- cavium,octeon-6335-ehci
- ibm,usb-ehci-440epx
- ibm,usb-ehci-460ex
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index be268e2..b9576015 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -25,6 +25,7 @@
- allwinner,sun8i-a83t-ohci
- allwinner,sun8i-h3-ohci
- allwinner,sun8i-r40-ohci
+ - allwinner,sun8i-v3s-ohci
- allwinner,sun9i-a80-ohci
- allwinner,sun20i-d1-ohci
- brcm,bcm3384-ohci
diff --git a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
index cc4cf92..d0927f6 100644
--- a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
+++ b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/genesys,gl850g.yaml#
@@ -17,6 +17,7 @@
enum:
- usb5e3,608
- usb5e3,610
+ - usb5e3,620
reg: true
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 8654a3e..afc30e9 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -53,7 +53,7 @@
- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
- switch-gpio: A phandle + gpio-specifier pair. Some boards are using Dual
- SPDT USB Switch, witch is cotrolled by GPIO to de/multiplex
+ SPDT USB Switch, witch is controlled by GPIO to de/multiplex
D+/D- USB lines between connectors.
- qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index ae24dac..6759105 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -14,6 +14,7 @@
items:
- enum:
- qcom,ipq4019-dwc3
+ - qcom,ipq5332-dwc3
- qcom,ipq6018-dwc3
- qcom,ipq8064-dwc3
- qcom,ipq8074-dwc3
@@ -82,15 +83,6 @@
minItems: 1
maxItems: 9
- assigned-clocks:
- items:
- - description: Phandle and clock specifier of MOCK_UTMI_CLK.
- - description: Phandle and clock specifoer of MASTER_CLK.
-
- assigned-clock-rates:
- items:
- - description: Must be 19.2MHz (19200000).
- - description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode.
resets:
maxItems: 1
@@ -246,6 +238,7 @@
compatible:
contains:
enum:
+ - qcom,ipq5332-dwc3
- qcom,msm8994-dwc3
- qcom,qcs404-dwc3
then:
@@ -290,15 +283,23 @@
then:
properties:
clocks:
- minItems: 6
+ minItems: 5
+ maxItems: 6
clock-names:
- items:
- - const: cfg_noc
- - const: core
- - const: iface
- - const: sleep
- - const: mock_utmi
- - const: bus
+ oneOf:
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - const: bus
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: sleep
+ - const: mock_utmi
+ - const: bus
- if:
properties:
@@ -410,6 +411,7 @@
compatible:
contains:
enum:
+ - qcom,ipq5332-dwc3
- qcom,sdm660-dwc3
then:
properties:
diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml
index 9309f00..f0784d2 100644
--- a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml
+++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/realtek,rts5411.yaml#
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml
index 4ced2f6..07bec1f 100644
--- a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml
@@ -10,7 +10,7 @@
- ChiYuan Huang <cy_huang@richtek.com>
description: |
- The RT1719 is a sink-only USB Type-C contoller that complies with the latest
+ The RT1719 is a sink-only USB Type-C controller that complies with the latest
USB Type-C and PD standards. It does the USB Type-C detection including attach
and orientation. It integrates the physical layer of the USB BMC power
delivery protocol to allow up to 100W of power. The BMC PD block enables full
diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
index 42ceaf1..1ade99e 100644
--- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
@@ -15,6 +15,7 @@
- samsung,exynos5250-dwusb3
- samsung,exynos5433-dwusb3
- samsung,exynos7-dwusb3
+ - samsung,exynos850-dwusb3
'#address-cells':
const: 1
@@ -72,7 +73,7 @@
properties:
compatible:
contains:
- const: samsung,exynos54333-dwusb3
+ const: samsung,exynos5433-dwusb3
then:
properties:
clocks:
@@ -82,8 +83,8 @@
items:
- const: aclk
- const: susp_clk
- - const: pipe_pclk
- const: phyclk
+ - const: pipe_pclk
- if:
properties:
@@ -101,6 +102,21 @@
- const: usbdrd30_susp_clk
- const: usbdrd30_axius_clk
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos850-dwusb3
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: bus_early
+ - const: ref
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
deleted file mode 100644
index 0388634..0000000
--- a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Samsung High Speed USB OTG controller
------------------------------
-
-The Samsung HSOTG IP can be found on Samsung SoCs, from S3C6400 onwards.
-It gives functionality of OTG-compliant USB 2.0 host and device with
-support for USB 2.0 high-speed (480Mbps) and full-speed (12 Mbps)
-operation.
-
-Currently only device mode is supported.
-
-Binding details
------
-
-Required properties:
-- compatible: "samsung,s3c6400-hsotg" should be used for all currently
- supported SoC,
-- interrupts: specifier of interrupt signal of interrupt controller,
- according to bindings of interrupt controller,
-- clocks: contains an array of clock specifiers:
- - first entry: OTG clock
-- clock-names: contains array of clock names:
- - first entry: must be "otg"
-- vusb_d-supply: phandle to voltage regulator of digital section,
-- vusb_a-supply: phandle to voltage regulator of analog section.
-
-Example
------
-
- hsotg@12480000 {
- compatible = "samsung,s3c6400-hsotg";
- reg = <0x12480000 0x20000>;
- interrupts = <0 71 0>;
- clocks = <&clock 305>;
- clock-names = "otg";
- vusb_d-supply = <&vusb_reg>;
- vusb_a-supply = <&vusbdac_reg>;
- };
-
diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml
index 88ea6c9..c2e29bd 100644
--- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml#
diff --git a/Documentation/devicetree/bindings/usb/vialab,vl817.yaml b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
index 23a13e1..76db907 100644
--- a/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
+++ b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/vialab,vl817.yaml#
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index af60bf1..573578d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -190,6 +190,8 @@
description: Compass Electronics Group, LLC
"^beagle,.*":
description: BeagleBoard.org Foundation
+ "^belling,.*":
+ description: Shanghai Belling Co., Ltd.
"^bhf,.*":
description: Beckhoff Automation GmbH & Co. KG
"^bitmain,.*":
@@ -617,6 +619,8 @@
description: Imagination Technologies Ltd.
"^imi,.*":
description: Integrated Micro-Electronics Inc.
+ "^inanbo,.*":
+ description: Shenzhen INANBO Electronic Technology Co., Ltd.
"^incircuit,.*":
description: In-Circuit GmbH
"^indiedroid,.*":
@@ -675,6 +679,8 @@
description: iWave Systems Technologies Pvt. Ltd.
"^jadard,.*":
description: Jadard Technology Inc.
+ "^jasonic,.*":
+ description: Jasonic Technology Ltd.
"^jdi,.*":
description: Japan Display Inc.
"^jedec,.*":
@@ -1151,6 +1157,8 @@
description: Shenzhen Roofull Technology Co, Ltd
"^roseapplepi,.*":
description: RoseapplePi.org
+ "^saef,.*":
+ description: Saef Technology Limited
"^samsung,.*":
description: Samsung Semiconductor
"^samtec,.*":
diff --git a/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
index 51d03d5..3e9fd49 100644
--- a/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 Toshiba Electronic Devices & Storage Corporation
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/watchdog/toshiba,visconti-wdt.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/watchdog/toshiba,visconti-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba Visconti SoCs PIUWDT Watchdog timer
diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst
index 1dcbd73..6ad72ac 100644
--- a/Documentation/doc-guide/kernel-doc.rst
+++ b/Documentation/doc-guide/kernel-doc.rst
@@ -151,9 +151,9 @@
line breaks, so if you try to format some text nicely, as in::
* Return:
- * 0 - OK
- * -EINVAL - invalid argument
- * -ENOMEM - out of memory
+ * %0 - OK
+ * %-EINVAL - invalid argument
+ * %-ENOMEM - out of memory
this will all run together and produce::
@@ -163,8 +163,8 @@
ReST list, e. g.::
* Return:
- * * 0 - OK to runtime suspend the device
- * * -EBUSY - Device should not be runtime suspended
+ * * %0 - OK to runtime suspend the device
+ * * %-EBUSY - Device should not be runtime suspended
#) If the descriptive text you provide has lines that begin with
some phrase followed by a colon, each of those phrases will be taken
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst
index 7671b53..d78b7c3 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -15,8 +15,8 @@
:no-identifiers: pci_device_id
-Delaying, scheduling, and timer routines
-----------------------------------------
+Delaying and scheduling routines
+--------------------------------
.. kernel-doc:: include/linux/sched.h
:internal:
@@ -33,16 +33,16 @@
.. kernel-doc:: include/linux/completion.h
:internal:
-.. kernel-doc:: kernel/time/timer.c
- :export:
+Time and timer routines
+-----------------------
-Wait queues and Wake events
----------------------------
-
-.. kernel-doc:: include/linux/wait.h
+.. kernel-doc:: include/linux/jiffies.h
:internal:
-.. kernel-doc:: kernel/sched/wait.c
+.. kernel-doc:: kernel/time/time.c
+ :export:
+
+.. kernel-doc:: kernel/time/timer.c
:export:
High-resolution timers
@@ -57,6 +57,15 @@
.. kernel-doc:: kernel/time/hrtimer.c
:export:
+Wait queues and Wake events
+---------------------------
+
+.. kernel-doc:: include/linux/wait.h
+ :internal:
+
+.. kernel-doc:: kernel/sched/wait.c
+ :export:
+
Internal Functions
------------------
diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst
index 683bd46..3d52dfd 100644
--- a/Documentation/driver-api/infrastructure.rst
+++ b/Documentation/driver-api/infrastructure.rst
@@ -8,12 +8,24 @@
:internal:
:no-identifiers: device_link_state
+.. kernel-doc:: include/linux/device/bus.h
+ :identifiers: bus_type bus_notifier_event
+
+.. kernel-doc:: include/linux/device/class.h
+ :identifiers: class
+
+.. kernel-doc:: include/linux/device/driver.h
+ :identifiers: probe_type device_driver
+
Device Drivers Base
-------------------
.. kernel-doc:: drivers/base/init.c
:internal:
+.. kernel-doc:: include/linux/device/driver.h
+ :no-identifiers: probe_type device_driver
+
.. kernel-doc:: drivers/base/driver.c
:export:
@@ -23,6 +35,9 @@
.. kernel-doc:: drivers/base/syscore.c
:export:
+.. kernel-doc:: include/linux/device/class.h
+ :no-identifiers: class
+
.. kernel-doc:: drivers/base/class.c
:export:
@@ -41,6 +56,9 @@
.. kernel-doc:: drivers/base/platform.c
:export:
+.. kernel-doc:: include/linux/device/bus.h
+ :no-identifiers: bus_type bus_notifier_event
+
.. kernel-doc:: drivers/base/bus.c
:export:
diff --git a/Documentation/driver-api/interconnect.rst b/Documentation/driver-api/interconnect.rst
index 5ed4f57..a92d0f2 100644
--- a/Documentation/driver-api/interconnect.rst
+++ b/Documentation/driver-api/interconnect.rst
@@ -113,3 +113,28 @@
$ cat /sys/kernel/debug/interconnect/interconnect_graph | \
dot -Tsvg > interconnect_graph.svg
+
+The ``test-client`` directory provides interfaces for issuing BW requests to
+any arbitrary path. Note that for safety reasons, this feature is disabled by
+default without a Kconfig to enable it. Enabling it requires code changes to
+``#define INTERCONNECT_ALLOW_WRITE_DEBUGFS``. Example usage::
+
+ cd /sys/kernel/debug/interconnect/test-client/
+
+ # Configure node endpoints for the path from CPU to DDR on
+ # qcom/sm8550.
+ echo chm_apps > src_node
+ echo ebi > dst_node
+
+ # Get path between src_node and dst_node. This is only
+ # necessary after updating the node endpoints.
+ echo 1 > get
+
+ # Set desired BW to 1GBps avg and 2GBps peak.
+ echo 1000000 > avg_bw
+ echo 2000000 > peak_bw
+
+ # Vote for avg_bw and peak_bw on the latest path from "get".
+ # Voting for multiple paths is possible by repeating this
+ # process for different nodes endpoints.
+ echo 1 > commit
diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst
index 311af516..5da27a7 100644
--- a/Documentation/driver-api/libata.rst
+++ b/Documentation/driver-api/libata.rst
@@ -32,22 +32,6 @@
:c:type:`struct ata_port_operations <ata_port_operations>`
----------------------------------------------------------
-Disable ATA port
-~~~~~~~~~~~~~~~~
-
-::
-
- void (*port_disable) (struct ata_port *);
-
-
-Called from :c:func:`ata_bus_probe` error path, as well as when unregistering
-from the SCSI module (rmmod, hot unplug). This function should do
-whatever needs to be done to take the port out of use. In most cases,
-:c:func:`ata_port_disable` can be used as this hook.
-
-Called from :c:func:`ata_bus_probe` on a failed probe. Called from
-:c:func:`ata_scsi_release`.
-
Post-IDENTIFY device configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -274,14 +258,6 @@
::
- void (*eng_timeout) (struct ata_port *ap);
- void (*phy_reset) (struct ata_port *ap);
-
-
-Deprecated. Use ``->error_handler()`` instead.
-
-::
-
void (*freeze) (struct ata_port *ap);
void (*thaw) (struct ata_port *ap);
@@ -364,8 +340,7 @@
u32 val);
-Read and write standard SATA phy registers. Currently only used if
-``->phy_reset`` hook called the :c:func:`sata_phy_reset` helper function.
+Read and write standard SATA phy registers.
sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE.
Init and shutdown
@@ -536,13 +511,12 @@
:c:func:`ata_scsi_error` is the current ``transportt->eh_strategy_handler()``
for libata. As discussed above, this will be entered in two cases -
-timeout and ATAPI error completion. This function calls low level libata
-driver's :c:func:`eng_timeout` callback, the standard callback for which is
-:c:func:`ata_eng_timeout`. It checks if a qc is active and calls
-:c:func:`ata_qc_timeout` on the qc if so. Actual error handling occurs in
-:c:func:`ata_qc_timeout`.
+timeout and ATAPI error completion. This function will check if a qc is active
+and has not failed yet. Such a qc will be marked with AC_ERR_TIMEOUT such that
+EH will know to handle it later. Then it calls low level libata driver's
+:c:func:`error_handler` callback.
-If EH is invoked for timeout, :c:func:`ata_qc_timeout` stops BMDMA and
+When the :c:func:`error_handler` callback is invoked it stops BMDMA and
completes the qc. Note that as we're currently in EH, we cannot call
scsi_done. As described in SCSI EH doc, a recovered scmd should be
either retried with :c:func:`scsi_queue_insert` or finished with
diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst
index ae0d2079..f1ffdec 100644
--- a/Documentation/driver-api/media/cec-core.rst
+++ b/Documentation/driver-api/media/cec-core.rst
@@ -109,9 +109,11 @@
int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable);
int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
- void (*adap_configured)(struct cec_adapter *adap, bool configured);
+ void (*adap_unconfigured)(struct cec_adapter *adap);
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
u32 signal_free_time, struct cec_msg *msg);
+ void (*adap_nb_transmit_canceled)(struct cec_adapter *adap,
+ const struct cec_msg *msg);
void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
void (*adap_free)(struct cec_adapter *adap);
@@ -122,8 +124,8 @@
...
};
-The seven low-level ops deal with various aspects of controlling the CEC adapter
-hardware:
+These low-level ops deal with various aspects of controlling the CEC adapter
+hardware. They are all called with the mutex adap->lock held.
To enable/disable the hardware::
@@ -179,14 +181,12 @@
Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID.
-Called when the adapter is fully configured or unconfigured::
+Called when the adapter is unconfigured::
- void (*adap_configured)(struct cec_adapter *adap, bool configured);
+ void (*adap_unconfigured)(struct cec_adapter *adap);
-If configured == true, then the adapter is fully configured, i.e. all logical
-addresses have been successfully claimed. If configured == false, then the
-adapter is unconfigured. If the driver has to take specific actions after
-(un)configuration, then that can be done through this optional callback.
+The adapter is unconfigured. If the driver has to take specific actions after
+unconfiguration, then that can be done through this optional callback.
To transmit a new message::
@@ -207,6 +207,19 @@
microseconds (one data bit period is 2.4 ms).
+To pass on the result of a canceled non-blocking transmit::
+
+ void (*adap_nb_transmit_canceled)(struct cec_adapter *adap,
+ const struct cec_msg *msg);
+
+This optional callback can be used to obtain the result of a canceled
+non-blocking transmit with sequence number msg->sequence. This is
+called if the transmit was aborted, the transmit timed out (i.e. the
+hardware never signaled that the transmit finished), or the transmit
+was successful, but the wait for the expected reply was either aborted
+or it timed out.
+
+
To log the current CEC hardware status::
void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
@@ -372,7 +385,8 @@
---------------------------------------
The low-level operations drive the hardware, the high-level operations are
-CEC protocol driven. The following high-level callbacks are available:
+CEC protocol driven. The high-level callbacks are called without the adap->lock
+mutex being held. The following high-level callbacks are available:
.. code-block:: none
@@ -384,9 +398,19 @@
...
/* High-level CEC message callback */
+ void (*configured)(struct cec_adapter *adap);
int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
};
+Called when the adapter is configured::
+
+ void (*configured)(struct cec_adapter *adap);
+
+The adapter is fully configured, i.e. all logical addresses have been
+successfully claimed. If the driver has to take specific actions after
+configuration, then that can be done through this optional callback.
+
+
The received() callback allows the driver to optionally handle a newly
received CEC message::
diff --git a/Documentation/driver-api/media/dtv-common.rst b/Documentation/driver-api/media/dtv-common.rst
index f8b2c4d..207a22b 100644
--- a/Documentation/driver-api/media/dtv-common.rst
+++ b/Documentation/driver-api/media/dtv-common.rst
@@ -3,15 +3,6 @@
Digital TV Common functions
---------------------------
-Math functions
-~~~~~~~~~~~~~~
-
-Provide some commonly-used math functions, usually required in order to
-estimate signal strength and signal to noise measurements in dB.
-
-.. kernel-doc:: include/media/dvb_math.h
-
-
DVB devices
~~~~~~~~~~~
diff --git a/Documentation/driver-api/media/v4l2-cci.rst b/Documentation/driver-api/media/v4l2-cci.rst
new file mode 100644
index 0000000..dd297a4
--- /dev/null
+++ b/Documentation/driver-api/media/v4l2-cci.rst
@@ -0,0 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+V4L2 CCI kAPI
+^^^^^^^^^^^^^
+.. kernel-doc:: include/media/v4l2-cci.h
diff --git a/Documentation/driver-api/media/v4l2-core.rst b/Documentation/driver-api/media/v4l2-core.rst
index 1a8c4a5..239045e 100644
--- a/Documentation/driver-api/media/v4l2-core.rst
+++ b/Documentation/driver-api/media/v4l2-core.rst
@@ -22,6 +22,7 @@
v4l2-mem2mem
v4l2-async
v4l2-fwnode
+ v4l2-cci
v4l2-rect
v4l2-tuner
v4l2-common
diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst
index 602dada..e56b50b 100644
--- a/Documentation/driver-api/media/v4l2-subdev.rst
+++ b/Documentation/driver-api/media/v4l2-subdev.rst
@@ -157,6 +157,9 @@
Using one or the other registration method only affects the probing process, the
run-time bridge-subdevice interaction is in both cases the same.
+Registering synchronous sub-devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
In the **synchronous** case a device (bridge) driver needs to register the
:c:type:`v4l2_subdev` with the v4l2_device:
@@ -175,10 +178,12 @@
:c:func:`v4l2_device_unregister_subdev <v4l2_device_unregister_subdev>`
(:c:type:`sd <v4l2_subdev>`).
-
Afterwards the subdev module can be unloaded and
:c:type:`sd <v4l2_subdev>`->dev == ``NULL``.
+Registering asynchronous sub-devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
In the **asynchronous** case subdevice probing can be invoked independently of
the bridge driver availability. The subdevice driver then has to verify whether
all the requirements for a successful probing are satisfied. This can include a
@@ -190,64 +195,89 @@
registered this way are stored in a global list of subdevices, ready to be
picked up by bridge drivers.
-Bridge drivers in turn have to register a notifier object. This is
-performed using the :c:func:`v4l2_async_nf_register` call. To
-unregister the notifier the driver has to call
-:c:func:`v4l2_async_nf_unregister`. The former of the two functions
-takes two arguments: a pointer to struct :c:type:`v4l2_device` and a
-pointer to struct :c:type:`v4l2_async_notifier`.
+Asynchronous sub-device notifiers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Bridge drivers in turn have to register a notifier object. This is performed
+using the :c:func:`v4l2_async_nf_register` call. To unregister the notifier the
+driver has to call :c:func:`v4l2_async_nf_unregister`. Before releasing memory
+of an unregister notifier, it must be cleaned up by calling
+:c:func:`v4l2_async_nf_cleanup`.
Before registering the notifier, bridge drivers must do two things: first, the
-notifier must be initialized using the :c:func:`v4l2_async_nf_init`.
-Second, bridge drivers can then begin to form a list of subdevice descriptors
-that the bridge device needs for its operation. Several functions are available
-to add subdevice descriptors to a notifier, depending on the type of device and
-the needs of the driver.
+notifier must be initialized using the :c:func:`v4l2_async_nf_init`. Second,
+bridge drivers can then begin to form a list of async connection descriptors
+that the bridge device needs for its
+operation. :c:func:`v4l2_async_nf_add_fwnode`,
+:c:func:`v4l2_async_nf_add_fwnode_remote` and :c:func:`v4l2_async_nf_add_i2c`
-:c:func:`v4l2_async_nf_add_fwnode_remote` and
-:c:func:`v4l2_async_nf_add_i2c` are for bridge and ISP drivers for
-registering their async sub-devices with the notifier.
+Async connection descriptors describe connections to external sub-devices the
+drivers for which are not yet probed. Based on an async connection, a media data
+or ancillary link may be created when the related sub-device becomes
+available. There may be one or more async connections to a given sub-device but
+this is not known at the time of adding the connections to the notifier. Async
+connections are bound as matching async sub-devices are found, one by one.
-:c:func:`v4l2_async_register_subdev_sensor` is a helper function for
-sensor drivers registering their own async sub-device, but it also registers a
-notifier and further registers async sub-devices for lens and flash devices
-found in firmware. The notifier for the sub-device is unregistered with the
-async sub-device.
+Asynchronous sub-device notifier for sub-devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-These functions allocate an async sub-device descriptor which is of type struct
-:c:type:`v4l2_async_subdev` embedded in a driver-specific struct. The &struct
-:c:type:`v4l2_async_subdev` shall be the first member of this struct:
+A driver that registers an asynchronous sub-device may also register an
+asynchronous notifier. This is called an asynchronous sub-device notifier andthe
+process is similar to that of a bridge driver apart from that the notifier is
+initialised using :c:func:`v4l2_async_subdev_nf_init` instead. A sub-device
+notifier may complete only after the V4L2 device becomes available, i.e. there's
+a path via async sub-devices and notifiers to a notifier that is not an
+asynchronous sub-device notifier.
+
+Asynchronous sub-device registration helper for camera sensor drivers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:c:func:`v4l2_async_register_subdev_sensor` is a helper function for sensor
+drivers registering their own async connection, but it also registers a notifier
+and further registers async connections for lens and flash devices found in
+firmware. The notifier for the sub-device is unregistered and cleaned up with
+the async sub-device, using :c:func:`v4l2_async_unregister_subdev`.
+
+Asynchronous sub-device notifier example
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These functions allocate an async connection descriptor which is of type struct
+:c:type:`v4l2_async_connection` embedded in a driver-specific struct. The &struct
+:c:type:`v4l2_async_connection` shall be the first member of this struct:
.. code-block:: c
- struct my_async_subdev {
- struct v4l2_async_subdev asd;
+ struct my_async_connection {
+ struct v4l2_async_connection asc;
...
};
- struct my_async_subdev *my_asd;
+ struct my_async_connection *my_asc;
struct fwnode_handle *ep;
...
- my_asd = v4l2_async_nf_add_fwnode_remote(¬ifier, ep,
- struct my_async_subdev);
+ my_asc = v4l2_async_nf_add_fwnode_remote(¬ifier, ep,
+ struct my_async_connection);
fwnode_handle_put(ep);
- if (IS_ERR(asd))
- return PTR_ERR(asd);
+ if (IS_ERR(my_asc))
+ return PTR_ERR(my_asc);
-The V4L2 core will then use these descriptors to match asynchronously
-registered subdevices to them. If a match is detected the ``.bound()``
-notifier callback is called. After all subdevices have been located the
-.complete() callback is called. When a subdevice is removed from the
-system the .unbind() method is called. All three callbacks are optional.
+Asynchronous sub-device notifier callbacks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The V4L2 core will then use these connection descriptors to match asynchronously
+registered subdevices to them. If a match is detected the ``.bound()`` notifier
+callback is called. After all connections have been bound the .complete()
+callback is called. When a connection is removed from the system the
+``.unbind()`` method is called. All three callbacks are optional.
Drivers can store any type of custom data in their driver-specific
-:c:type:`v4l2_async_subdev` wrapper. If any of that data requires special
+:c:type:`v4l2_async_connection` wrapper. If any of that data requires special
handling when the structure is freed, drivers must implement the ``.destroy()``
notifier callback. The framework will call it right before freeing the
-:c:type:`v4l2_async_subdev`.
+:c:type:`v4l2_async_connection`.
Calling subdev operations
~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/driver-api/s390-drivers.rst b/Documentation/driver-api/s390-drivers.rst
index 5158577b..8c0845c 100644
--- a/Documentation/driver-api/s390-drivers.rst
+++ b/Documentation/driver-api/s390-drivers.rst
@@ -27,7 +27,7 @@
although they are not the focus of this document.
Some additional information can also be found in the kernel source under
-Documentation/s390/driver-model.rst.
+Documentation/arch/s390/driver-model.rst.
The css bus
===========
@@ -38,7 +38,7 @@
* Standard I/O subchannels, for use by the system. They have a child
device on the ccw bus and are described below.
* I/O subchannels bound to the vfio-ccw driver. See
- Documentation/s390/vfio-ccw.rst.
+ Documentation/arch/s390/vfio-ccw.rst.
* Message subchannels. No Linux driver currently exists.
* CHSC subchannels (at most one). The chsc subchannel driver can be used
to send asynchronous chsc commands.
diff --git a/Documentation/driver-api/tty/tty_buffer.rst b/Documentation/driver-api/tty/tty_buffer.rst
index a39d478..4b5ca177 100644
--- a/Documentation/driver-api/tty/tty_buffer.rst
+++ b/Documentation/driver-api/tty/tty_buffer.rst
@@ -15,10 +15,13 @@
======================
.. kernel-doc:: drivers/tty/tty_buffer.c
- :identifiers: tty_prepare_flip_string tty_insert_flip_string_fixed_flag
- tty_insert_flip_string_flags __tty_insert_flip_char
+ :identifiers: tty_prepare_flip_string
tty_flip_buffer_push tty_ldisc_receive_buf
+.. kernel-doc:: include/linux/tty_flip.h
+ :identifiers: tty_insert_flip_string_fixed_flag tty_insert_flip_string_flags
+ tty_insert_flip_char
+
----
Other Functions
diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst
index 2c94ff2..fb41768 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -420,6 +420,12 @@
know the devnum value already, it's the DDD value of the device file
name.
+USBDEVFS_GET_SPEED
+ Returns the speed of the device. The speed is returned as a
+ nummerical value in accordance with enum usb_device_speed
+
+ File modification time is not updated by this request.
+
USBDEVFS_GETDRIVER
Returns the name of the kernel driver bound to a given interface (a
string). Parameter is a pointer to this structure, which is
@@ -771,8 +777,7 @@
======= ======================================================
1.5 Mbit/s for low speed USB
12 Mbit/s for full speed USB
- 480 Mbit/s for high speed USB (added for USB 2.0);
- also used for Wireless USB, which has no fixed speed
+ 480 Mbit/s for high speed USB (added for USB 2.0)
5000 Mbit/s for SuperSpeed USB (added for USB 3.0)
======= ======================================================
diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst
index 68abc08..633d11c 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -239,6 +239,137 @@
/* Gratuitous device reset and go... */
ioctl(device, VFIO_DEVICE_RESET);
+IOMMUFD and vfio_iommu_type1
+----------------------------
+
+IOMMUFD is the new user API to manage I/O page tables from userspace.
+It intends to be the portal of delivering advanced userspace DMA
+features (nested translation [5]_, PASID [6]_, etc.) while also providing
+a backwards compatibility interface for existing VFIO_TYPE1v2_IOMMU use
+cases. Eventually the vfio_iommu_type1 driver, as well as the legacy
+vfio container and group model is intended to be deprecated.
+
+The IOMMUFD backwards compatibility interface can be enabled two ways.
+In the first method, the kernel can be configured with
+CONFIG_IOMMUFD_VFIO_CONTAINER, in which case the IOMMUFD subsystem
+transparently provides the entire infrastructure for the VFIO
+container and IOMMU backend interfaces. The compatibility mode can
+also be accessed if the VFIO container interface, ie. /dev/vfio/vfio is
+simply symlink'd to /dev/iommu. Note that at the time of writing, the
+compatibility mode is not entirely feature complete relative to
+VFIO_TYPE1v2_IOMMU (ex. DMA mapping MMIO) and does not attempt to
+provide compatibility to the VFIO_SPAPR_TCE_IOMMU interface. Therefore
+it is not generally advisable at this time to switch from native VFIO
+implementations to the IOMMUFD compatibility interfaces.
+
+Long term, VFIO users should migrate to device access through the cdev
+interface described below, and native access through the IOMMUFD
+provided interfaces.
+
+VFIO Device cdev
+----------------
+
+Traditionally user acquires a device fd via VFIO_GROUP_GET_DEVICE_FD
+in a VFIO group.
+
+With CONFIG_VFIO_DEVICE_CDEV=y the user can now acquire a device fd
+by directly opening a character device /dev/vfio/devices/vfioX where
+"X" is the number allocated uniquely by VFIO for registered devices.
+cdev interface does not support noiommu devices, so user should use
+the legacy group interface if noiommu is wanted.
+
+The cdev only works with IOMMUFD. Both VFIO drivers and applications
+must adapt to the new cdev security model which requires using
+VFIO_DEVICE_BIND_IOMMUFD to claim DMA ownership before starting to
+actually use the device. Once BIND succeeds then a VFIO device can
+be fully accessed by the user.
+
+VFIO device cdev doesn't rely on VFIO group/container/iommu drivers.
+Hence those modules can be fully compiled out in an environment
+where no legacy VFIO application exists.
+
+So far SPAPR does not support IOMMUFD yet. So it cannot support device
+cdev either.
+
+vfio device cdev access is still bound by IOMMU group semantics, ie. there
+can be only one DMA owner for the group. Devices belonging to the same
+group can not be bound to multiple iommufd_ctx or shared between native
+kernel and vfio bus driver or other driver supporting the driver_managed_dma
+flag. A violation of this ownership requirement will fail at the
+VFIO_DEVICE_BIND_IOMMUFD ioctl, which gates full device access.
+
+Device cdev Example
+-------------------
+
+Assume user wants to access PCI device 0000:6a:01.0::
+
+ $ ls /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/
+ vfio0
+
+This device is therefore represented as vfio0. The user can verify
+its existence::
+
+ $ ls -l /dev/vfio/devices/vfio0
+ crw------- 1 root root 511, 0 Feb 16 01:22 /dev/vfio/devices/vfio0
+ $ cat /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/vfio0/dev
+ 511:0
+ $ ls -l /dev/char/511\:0
+ lrwxrwxrwx 1 root root 21 Feb 16 01:22 /dev/char/511:0 -> ../vfio/devices/vfio0
+
+Then provide the user with access to the device if unprivileged
+operation is desired::
+
+ $ chown user:user /dev/vfio/devices/vfio0
+
+Finally the user could get cdev fd by::
+
+ cdev_fd = open("/dev/vfio/devices/vfio0", O_RDWR);
+
+An opened cdev_fd doesn't give the user any permission of accessing
+the device except binding the cdev_fd to an iommufd. After that point
+then the device is fully accessible including attaching it to an
+IOMMUFD IOAS/HWPT to enable userspace DMA::
+
+ struct vfio_device_bind_iommufd bind = {
+ .argsz = sizeof(bind),
+ .flags = 0,
+ };
+ struct iommu_ioas_alloc alloc_data = {
+ .size = sizeof(alloc_data),
+ .flags = 0,
+ };
+ struct vfio_device_attach_iommufd_pt attach_data = {
+ .argsz = sizeof(attach_data),
+ .flags = 0,
+ };
+ struct iommu_ioas_map map = {
+ .size = sizeof(map),
+ .flags = IOMMU_IOAS_MAP_READABLE |
+ IOMMU_IOAS_MAP_WRITEABLE |
+ IOMMU_IOAS_MAP_FIXED_IOVA,
+ .__reserved = 0,
+ };
+
+ iommufd = open("/dev/iommu", O_RDWR);
+
+ bind.iommufd = iommufd;
+ ioctl(cdev_fd, VFIO_DEVICE_BIND_IOMMUFD, &bind);
+
+ ioctl(iommufd, IOMMU_IOAS_ALLOC, &alloc_data);
+ attach_data.pt_id = alloc_data.out_ioas_id;
+ ioctl(cdev_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, &attach_data);
+
+ /* Allocate some space and setup a DMA mapping */
+ map.user_va = (int64_t)mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+ map.iova = 0; /* 1MB starting at 0x0 from device view */
+ map.length = 1024 * 1024;
+ map.ioas_id = alloc_data.out_ioas_id;;
+
+ ioctl(iommufd, IOMMU_IOAS_MAP, &map);
+
+ /* Other device operations as stated in "VFIO Usage Example" */
+
VFIO User API
-------------------------------------------------------------------------------
@@ -279,6 +410,7 @@
struct iommufd_ctx *ictx, u32 *out_device_id);
void (*unbind_iommufd)(struct vfio_device *vdev);
int (*attach_ioas)(struct vfio_device *vdev, u32 *pt_id);
+ void (*detach_ioas)(struct vfio_device *vdev);
int (*open_device)(struct vfio_device *vdev);
void (*close_device)(struct vfio_device *vdev);
ssize_t (*read)(struct vfio_device *vdev, char __user *buf,
@@ -315,9 +447,10 @@
- The [un]bind_iommufd callbacks are issued when the device is bound to
and unbound from iommufd.
- - The attach_ioas callback is issued when the device is attached to an
- IOAS managed by the bound iommufd. The attached IOAS is automatically
- detached when the device is unbound from iommufd.
+ - The [de]attach_ioas callback is issued when the device is attached to
+ and detached from an IOAS managed by the bound iommufd. However, the
+ attached IOAS can also be automatically detached when the device is
+ unbound from iommufd.
- The read/write/mmap callbacks implement the device region access defined
by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl.
@@ -564,3 +697,11 @@
\-0d.1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
+
+.. [5] Nested translation is an IOMMU feature which supports two stage
+ address translations. This improves the address translation efficiency
+ in IOMMU virtualization.
+
+.. [6] PASID stands for Process Address Space ID, introduced by PCI
+ Express. It is a prerequisite for Shared Virtual Addressing (SVA)
+ and Scalable I/O Virtualization (Scalable IOV).
diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst
index b648095..70380a2 100644
--- a/Documentation/fault-injection/fault-injection.rst
+++ b/Documentation/fault-injection/fault-injection.rst
@@ -243,7 +243,7 @@
Error Injectable Functions
--------------------------
-This part is for the kenrel developers considering to add a function to
+This part is for the kernel developers considering to add a function to
ALLOW_ERROR_INJECTION() macro.
Requirements for the Error Injectable Functions
diff --git a/Documentation/fb/deferred_io.rst b/Documentation/fb/deferred_io.rst
index 7300cff..7fc1933 100644
--- a/Documentation/fb/deferred_io.rst
+++ b/Documentation/fb/deferred_io.rst
@@ -9,7 +9,7 @@
- userspace app like Xfbdev mmaps framebuffer
- deferred IO and driver sets up fault and page_mkwrite handlers
-- userspace app tries to write to mmaped vaddress
+- userspace app tries to write to mmapped vaddress
- we get pagefault and reach fault handler
- fault handler finds and returns physical page
- we get page_mkwrite where we add this page to a list
diff --git a/Documentation/fb/sm712fb.rst b/Documentation/fb/sm712fb.rst
index 994dad3..8e000f8 100644
--- a/Documentation/fb/sm712fb.rst
+++ b/Documentation/fb/sm712fb.rst
@@ -31,5 +31,5 @@
================
(alias TODO list)
- * 2D acceleratrion
+ * 2D acceleration
* dual-head support
diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst
index 42466ff..88d5a52 100644
--- a/Documentation/fb/sstfb.rst
+++ b/Documentation/fb/sstfb.rst
@@ -73,7 +73,7 @@
the device will be /dev/fb0. You can check this by doing a
cat /proc/fb. You can find a copy of con2fb in tools/ directory.
if you don't have another fb device, this step is superfluous,
- as the console subsystem automagicaly binds ttys to the fb.
+ as the console subsystem automagically binds ttys to the fb.
#. switch to the virtual console you just mapped. "tadaaa" ...
Module removal
diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt
index 9c5d39e..97c65ed 100644
--- a/Documentation/features/core/thread-info-in-task/arch-support.txt
+++ b/Documentation/features/core/thread-info-in-task/arch-support.txt
@@ -1,7 +1,7 @@
#
# Feature name: thread-info-in-task
# Kconfig: THREAD_INFO_IN_TASK
-# description: arch makes use of the core kernel facility to embedd thread_info in task_struct
+# description: arch makes use of the core kernel facility to embed thread_info in task_struct
#
-----------------------
| arch |status|
diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
index bcc29d3..38a0a54 100644
--- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
+++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | TODO |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt
index 8a77d62..aad83b5 100644
--- a/Documentation/features/debug/kprobes/arch-support.txt
+++ b/Documentation/features/debug/kprobes/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | ok |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt
index cf4723c..6138001 100644
--- a/Documentation/features/debug/kretprobes/arch-support.txt
+++ b/Documentation/features/debug/kretprobes/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | ok |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt
index 71cd4ba..4c64c5d 100644
--- a/Documentation/features/debug/stackprotector/arch-support.txt
+++ b/Documentation/features/debug/stackprotector/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | TODO |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt
index d53f2f9..24c8423 100644
--- a/Documentation/features/debug/uprobes/arch-support.txt
+++ b/Documentation/features/debug/uprobes/arch-support.txt
@@ -13,7 +13,7 @@
| csky: | ok |
| hexagon: | TODO |
| ia64: | TODO |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt
index ddb9452..a36e2316 100644
--- a/Documentation/features/locking/lockdep/arch-support.txt
+++ b/Documentation/features/locking/lockdep/arch-support.txt
@@ -19,7 +19,7 @@
| mips: | ok |
| nios2: | TODO |
| openrisc: | ok |
- | parisc: | TODO |
+ | parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt
index 15164f3..47909c3 100644
--- a/Documentation/features/vm/ELF-ASLR/arch-support.txt
+++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt
@@ -1,6 +1,7 @@
#
# Feature name: ELF-ASLR
# Kconfig: ARCH_HAS_ELF_RANDOMIZE
+# Kconfig: ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
# description: arch randomizes the stack, heap and binary images of ELF binaries
#
-----------------------
@@ -10,10 +11,10 @@
| arc: | TODO |
| arm: | ok |
| arm64: | ok |
- | csky: | TODO |
+ | csky: | ok |
| hexagon: | TODO |
| ia64: | TODO |
- | loongarch: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt
index 7f049c2..76208db 100644
--- a/Documentation/features/vm/TLB/arch-support.txt
+++ b/Documentation/features/vm/TLB/arch-support.txt
@@ -9,7 +9,7 @@
| alpha: | TODO |
| arc: | TODO |
| arm: | TODO |
- | arm64: | N/A |
+ | arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
| ia64: | TODO |
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst
index 1b5f0cc..1e0e0bb 100644
--- a/Documentation/filesystems/9p.rst
+++ b/Documentation/filesystems/9p.rst
@@ -79,7 +79,7 @@
cache=mode specifies a caching policy. By default, no caches are used.
The mode can be specified as a bitmask or by using one of the
- prexisting common 'shortcuts'.
+ preexisting common 'shortcuts'.
The bitmask is described below: (unspecified bits are reserved)
========== ====================================================
diff --git a/Documentation/filesystems/afs.rst b/Documentation/filesystems/afs.rst
index ca062a7..f15ba38 100644
--- a/Documentation/filesystems/afs.rst
+++ b/Documentation/filesystems/afs.rst
@@ -44,7 +44,7 @@
CONFIG_AF_RXRPC - The RxRPC protocol transport
CONFIG_RXKAD - The RxRPC Kerberos security handler
- CONFIG_AFS - The AFS filesystem
+ CONFIG_AFS_FS - The AFS filesystem
Additionally, the following can be turned on to aid debugging::
diff --git a/Documentation/filesystems/befs.rst b/Documentation/filesystems/befs.rst
index 79f9740..a22f603 100644
--- a/Documentation/filesystems/befs.rst
+++ b/Documentation/filesystems/befs.rst
@@ -106,8 +106,8 @@
debug The driver will output debugging information to the syslog.
============= ===========================================================
-How to Get Lastest Version
-==========================
+How to Get Latest Version
+=========================
The latest version is currently available at:
<http://befs-driver.sourceforge.net/>
diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst
index fc7abf7..e04a27b 100644
--- a/Documentation/filesystems/caching/cachefiles.rst
+++ b/Documentation/filesystems/caching/cachefiles.rst
@@ -416,7 +416,7 @@
example).
The subjective security holds the active security properties of a process, and
-may be overridden. This is not seen externally, and is used whan a process
+may be overridden. This is not seen externally, and is used when a process
acts upon another object, for example SIGKILLing another process or opening a
file.
diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst
index 1d18e9d..665b27f 100644
--- a/Documentation/filesystems/caching/netfs-api.rst
+++ b/Documentation/filesystems/caching/netfs-api.rst
@@ -59,7 +59,7 @@
The filesystem then acquires a cookie for each file within that volume using an
object key. Object keys are binary blobs and only need to be unique within
-their parent volume. The cache backend is reponsible for rendering the binary
+their parent volume. The cache backend is responsible for rendering the binary
blob into something it can use and may employ hash tables, trees or whatever to
improve its ability to find an object. This is transparent to the network
filesystem.
@@ -91,7 +91,7 @@
Volume Registration
===================
-The first step for a network filsystem is to acquire a volume cookie for the
+The first step for a network filesystem is to acquire a volume cookie for the
volume it wants to access::
struct fscache_volume *
@@ -119,7 +119,7 @@
be invalidated.
This function can return errors such as EBUSY if the volume key is already in
-use by an acquired volume or ENOMEM if an allocation failure occured. It may
+use by an acquired volume or ENOMEM if an allocation failure occurred. It may
also return a NULL volume cookie if fscache is not enabled. It is safe to
pass a NULL cookie to any function that takes a volume cookie. This will
cause that function to do nothing.
diff --git a/Documentation/filesystems/configfs.rst b/Documentation/filesystems/configfs.rst
index 8c9342e..ac22138 100644
--- a/Documentation/filesystems/configfs.rst
+++ b/Documentation/filesystems/configfs.rst
@@ -253,7 +253,7 @@
If binary attribute is readable and the config_item provides a
ct_item_ops->read_bin_attribute() method, that method will be called
whenever userspace asks for a read(2) on the attribute. The converse
-will happen for write(2). The reads/writes are bufferred so only a
+will happen for write(2). The reads/writes are buffered so only a
single read/write will occur; the attributes' need not concern itself
with it.
diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst
index c04609d8..719e90f 100644
--- a/Documentation/filesystems/dax.rst
+++ b/Documentation/filesystems/dax.rst
@@ -291,7 +291,7 @@
mapped caches such as ARM, MIPS and SPARC.
Calling :c:func:`get_user_pages()` on a range of user memory that has been
-mmaped from a `DAX` file will fail when there are no 'struct page' to describe
+mmapped from a `DAX` file will fail when there are no 'struct page' to describe
those pages. This problem has been addressed in some device drivers
by adding optional struct page support for pages under the control of
the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of
diff --git a/Documentation/filesystems/devpts.rst b/Documentation/filesystems/devpts.rst
index a03248d..b6324ab 100644
--- a/Documentation/filesystems/devpts.rst
+++ b/Documentation/filesystems/devpts.rst
@@ -5,8 +5,8 @@
=====================
Each mount of the devpts filesystem is now distinct such that ptys
-and their indicies allocated in one mount are independent from ptys
-and their indicies in all other mounts.
+and their indices allocated in one mount are independent from ptys
+and their indices in all other mounts.
All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node
with permissions ``0000``.
diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst
index 0152888..a1eb4a1 100644
--- a/Documentation/filesystems/ext4/super.rst
+++ b/Documentation/filesystems/ext4/super.rst
@@ -772,7 +772,7 @@
* - 0x0010
- Do not support 32-bit UIDs. (EXT4_DEFM_UID16)
* - 0x0020
- - All data and metadata are commited to the journal.
+ - All data and metadata are committed to the journal.
(EXT4_DEFM_JMODE_DATA)
* - 0x0040
- All data are flushed to the disk before metadata are committed to the
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 9359978..d32c620 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -359,7 +359,7 @@
====================== =============== =============== ========
mode continue remount-ro panic
====================== =============== =============== ========
- access ops normal noraml N/A
+ access ops normal normal N/A
syscall errors -EIO -EROFS N/A
mount option rw ro N/A
pending dir write keep keep N/A
@@ -480,7 +480,7 @@
sload.f2fs
----------
-The sload.f2fs gives a way to insert files and directories in the exisiting disk
+The sload.f2fs gives a way to insert files and directories in the existing disk
image. This tool is useful when building f2fs images given compiled files.
Note: please refer to the manpage of sload.f2fs(8) to get full option list.
@@ -792,7 +792,7 @@
as a method of optimally implementing that function.
However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to
-fallocate(fd, DEFAULT_MODE), it allocates on-disk block addressess having
+fallocate(fd, DEFAULT_MODE), it allocates on-disk block addresses having
zero or random data, which is useful to the below scenario where:
1. create(fd)
diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index eccd327..a624e92 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -332,54 +332,121 @@
fscrypt allows one encryption mode to be specified for file contents
and one encryption mode to be specified for filenames. Different
directory trees are permitted to use different encryption modes.
+
+Supported modes
+---------------
+
Currently, the following pairs of encryption modes are supported:
- AES-256-XTS for contents and AES-256-CTS-CBC for filenames
-- AES-128-CBC for contents and AES-128-CTS-CBC for filenames
+- AES-256-XTS for contents and AES-256-HCTR2 for filenames
- Adiantum for both contents and filenames
-- AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only)
-- SM4-XTS for contents and SM4-CTS-CBC for filenames (v2 policies only)
+- AES-128-CBC-ESSIV for contents and AES-128-CTS-CBC for filenames
+- SM4-XTS for contents and SM4-CTS-CBC for filenames
-If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.
+Authenticated encryption modes are not currently supported because of
+the difficulty of dealing with ciphertext expansion. Therefore,
+contents encryption uses a block cipher in `XTS mode
+<https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS>`_ or
+`CBC-ESSIV mode
+<https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_(ESSIV)>`_,
+or a wide-block cipher. Filenames encryption uses a
+block cipher in `CTS-CBC mode
+<https://en.wikipedia.org/wiki/Ciphertext_stealing>`_ or a wide-block
+cipher.
-AES-128-CBC was added only for low-powered embedded devices with
-crypto accelerators such as CAAM or CESA that do not support XTS. To
-use AES-128-CBC, CONFIG_CRYPTO_ESSIV and CONFIG_CRYPTO_SHA256 (or
-another SHA-256 implementation) must be enabled so that ESSIV can be
-used.
+The (AES-256-XTS, AES-256-CTS-CBC) pair is the recommended default.
+It is also the only option that is *guaranteed* to always be supported
+if the kernel supports fscrypt at all; see `Kernel config options`_.
-Adiantum is a (primarily) stream cipher-based mode that is fast even
-on CPUs without dedicated crypto instructions. It's also a true
-wide-block mode, unlike XTS. It can also eliminate the need to derive
-per-file encryption keys. However, it depends on the security of two
-primitives, XChaCha12 and AES-256, rather than just one. See the
-paper "Adiantum: length-preserving encryption for entry-level
-processors" (https://eprint.iacr.org/2018/720.pdf) for more details.
-To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast
-implementations of ChaCha and NHPoly1305 should be enabled, e.g.
-CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM.
+The (AES-256-XTS, AES-256-HCTR2) pair is also a good choice that
+upgrades the filenames encryption to use a wide-block cipher. (A
+*wide-block cipher*, also called a tweakable super-pseudorandom
+permutation, has the property that changing one bit scrambles the
+entire result.) As described in `Filenames encryption`_, a wide-block
+cipher is the ideal mode for the problem domain, though CTS-CBC is the
+"least bad" choice among the alternatives. For more information about
+HCTR2, see `the HCTR2 paper <https://eprint.iacr.org/2021/1441.pdf>`_.
-AES-256-HCTR2 is another true wide-block encryption mode that is intended for
-use on CPUs with dedicated crypto instructions. AES-256-HCTR2 has the property
-that a bitflip in the plaintext changes the entire ciphertext. This property
-makes it desirable for filename encryption since initialization vectors are
-reused within a directory. For more details on AES-256-HCTR2, see the paper
-"Length-preserving encryption with HCTR2"
-(https://eprint.iacr.org/2021/1441.pdf). To use AES-256-HCTR2,
-CONFIG_CRYPTO_HCTR2 must be enabled. Also, fast implementations of XCTR and
-POLYVAL should be enabled, e.g. CRYPTO_POLYVAL_ARM64_CE and
-CRYPTO_AES_ARM64_CE_BLK for ARM64.
+Adiantum is recommended on systems where AES is too slow due to lack
+of hardware acceleration for AES. Adiantum is a wide-block cipher
+that uses XChaCha12 and AES-256 as its underlying components. Most of
+the work is done by XChaCha12, which is much faster than AES when AES
+acceleration is unavailable. For more information about Adiantum, see
+`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf>`_.
-SM4 is a Chinese block cipher that is an alternative to AES. It has
-not seen as much security review as AES, and it only has a 128-bit key
-size. It may be useful in cases where its use is mandated.
-Otherwise, it should not be used. For SM4 support to be available, it
-also needs to be enabled in the kernel crypto API.
+The (AES-128-CBC-ESSIV, AES-128-CTS-CBC) pair exists only to support
+systems whose only form of AES acceleration is an off-CPU crypto
+accelerator such as CAAM or CESA that does not support XTS.
-New encryption modes can be added relatively easily, without changes
-to individual filesystems. However, authenticated encryption (AE)
-modes are not currently supported because of the difficulty of dealing
-with ciphertext expansion.
+The remaining mode pairs are the "national pride ciphers":
+
+- (SM4-XTS, SM4-CTS-CBC)
+
+Generally speaking, these ciphers aren't "bad" per se, but they
+receive limited security review compared to the usual choices such as
+AES and ChaCha. They also don't bring much new to the table. It is
+suggested to only use these ciphers where their use is mandated.
+
+Kernel config options
+---------------------
+
+Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in
+only the basic support from the crypto API needed to use AES-256-XTS
+and AES-256-CTS-CBC encryption. For optimal performance, it is
+strongly recommended to also enable any available platform-specific
+kconfig options that provide acceleration for the algorithm(s) you
+wish to use. Support for any "non-default" encryption modes typically
+requires extra kconfig options as well.
+
+Below, some relevant options are listed by encryption mode. Note,
+acceleration options not listed below may be available for your
+platform; refer to the kconfig menus. File contents encryption can
+also be configured to use inline encryption hardware instead of the
+kernel crypto API (see `Inline encryption support`_); in that case,
+the file contents mode doesn't need to supported in the kernel crypto
+API, but the filenames mode still does.
+
+- AES-256-XTS and AES-256-CTS-CBC
+ - Recommended:
+ - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
+ - x86: CONFIG_CRYPTO_AES_NI_INTEL
+
+- AES-256-HCTR2
+ - Mandatory:
+ - CONFIG_CRYPTO_HCTR2
+ - Recommended:
+ - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
+ - arm64: CONFIG_CRYPTO_POLYVAL_ARM64_CE
+ - x86: CONFIG_CRYPTO_AES_NI_INTEL
+ - x86: CONFIG_CRYPTO_POLYVAL_CLMUL_NI
+
+- Adiantum
+ - Mandatory:
+ - CONFIG_CRYPTO_ADIANTUM
+ - Recommended:
+ - arm32: CONFIG_CRYPTO_CHACHA20_NEON
+ - arm32: CONFIG_CRYPTO_NHPOLY1305_NEON
+ - arm64: CONFIG_CRYPTO_CHACHA20_NEON
+ - arm64: CONFIG_CRYPTO_NHPOLY1305_NEON
+ - x86: CONFIG_CRYPTO_CHACHA20_X86_64
+ - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2
+ - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2
+
+- AES-128-CBC-ESSIV and AES-128-CTS-CBC:
+ - Mandatory:
+ - CONFIG_CRYPTO_ESSIV
+ - CONFIG_CRYPTO_SHA256 or another SHA-256 implementation
+ - Recommended:
+ - AES-CBC acceleration
+
+fscrypt also uses HMAC-SHA512 for key derivation, so enabling SHA-512
+acceleration is recommended:
+
+- SHA-512
+ - Recommended:
+ - arm64: CONFIG_CRYPTO_SHA512_ARM64_CE
+ - x86: CONFIG_CRYPTO_SHA512_SSSE3
Contents encryption
-------------------
@@ -493,7 +560,14 @@
be set to constants from ``<linux/fscrypt.h>`` which identify the
encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS
(1) for ``contents_encryption_mode`` and FSCRYPT_MODE_AES_256_CTS
- (4) for ``filenames_encryption_mode``.
+ (4) for ``filenames_encryption_mode``. For details, see `Encryption
+ modes and usage`_.
+
+ v1 encryption policies only support three combinations of modes:
+ (FSCRYPT_MODE_AES_256_XTS, FSCRYPT_MODE_AES_256_CTS),
+ (FSCRYPT_MODE_AES_128_CBC, FSCRYPT_MODE_AES_128_CTS), and
+ (FSCRYPT_MODE_ADIANTUM, FSCRYPT_MODE_ADIANTUM). v2 policies support
+ all combinations documented in `Supported modes`_.
- ``flags`` contains optional flags from ``<linux/fscrypt.h>``:
diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index cb845e8..13e4b18 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -326,6 +326,8 @@
FS_IOC_GETFLAGS and FS_IOC_MEASURE_VERITY because it doesn't require
opening the file, and opening verity files can be expensive.
+.. _accessing_verity_files:
+
Accessing verity files
======================
diff --git a/Documentation/filesystems/gfs2-glocks.rst b/Documentation/filesystems/gfs2-glocks.rst
index 93a690b..8a58429 100644
--- a/Documentation/filesystems/gfs2-glocks.rst
+++ b/Documentation/filesystems/gfs2-glocks.rst
@@ -77,7 +77,7 @@
grant for which we ignore remote demote requests. This is in order to
prevent a situation where locks are being bounced around the cluster
from node to node with none of the nodes making any progress. This
-tends to show up most with shared mmaped files which are being written
+tends to show up most with shared mmapped files which are being written
to by multiple nodes. By delaying the demotion in response to a
remote callback, that gives the userspace program time to make
some progress before the pages are unmapped.
diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst
index ad6d216..ac0af67 100644
--- a/Documentation/filesystems/idmappings.rst
+++ b/Documentation/filesystems/idmappings.rst
@@ -36,7 +36,7 @@
From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an
idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are
order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
-the set of all possible ids useable on a given system.
+the set of all possible ids usable on a given system.
Looking at this mathematically briefly will help us highlight some properties
that make it easier to understand how we can translate between idmappings. For
@@ -47,7 +47,7 @@
k10002 -> u24
Given that we are dealing with order isomorphisms plus the fact that we're
-dealing with subsets we can embedd idmappings into each other, i.e. we can
+dealing with subsets we can embed idmappings into each other, i.e. we can
sensibly translate between different idmappings. For example, assume we've been
given the three idmappings::
@@ -60,7 +60,7 @@
Because we're dealing with order isomorphic subsets it is meaningful to ask
what id ``k11000`` corresponds to in the second or third idmapping. The
-straightfoward algorithm to use is to apply the inverse of the first idmapping,
+straightforward algorithm to use is to apply the inverse of the first idmapping,
mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using
either the second idmapping mapping or third idmapping mapping. The second
idmapping would map ``u1000`` down to ``21000``. The third idmapping would map
@@ -146,9 +146,10 @@
all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So
an idmapping will be written as ``u0:k10000:r10000``.
-For example, the id ``u1000`` is an id in the upper idmapset or "userspace
-idmapset" starting with ``u1000``. And it is mapped to ``k11000`` which is a
-kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``.
+For example, within this idmapping, the id ``u1000`` is an id in the upper
+idmapset or "userspace idmapset" starting with ``u0``. And it is mapped to
+``k11000`` which is a kernel id in the lower idmapset or "kernel idmapset"
+starting with ``k10000``.
A kernel id is always created by an idmapping. Such idmappings are associated
with user namespaces. Since we mainly care about how idmappings work we're not
@@ -367,12 +368,19 @@
written to disk. If it can't the kernel will refuse the creation request to not
even remotely risk filesystem corruption.
-The astute reader will have realized that this is simply a varation of the
+The astute reader will have realized that this is simply a variation of the
crossmapping algorithm we mentioned above in a previous section. First, the
kernel maps the caller's userspace id down into a kernel id according to the
caller's idmapping and then maps that kernel id up according to the
filesystem's idmapping.
+From the implementation point it's worth mentioning how idmappings are represented.
+All idmappings are taken from the corresponding user namespace.
+
+ - caller's idmapping (usually taken from ``current_user_ns()``)
+ - filesystem's idmapping (``sb->s_user_ns``)
+ - mount's idmapping (``mnt_idmap(vfsmnt)``)
+
Let's see some examples with caller/filesystem idmapping but without mount
idmappings. This will exhibit some problems we can hit. After that we will
revisit/reconsider these examples, this time using mount idmappings, to see how
@@ -458,7 +466,7 @@
consequences.
First, that we can't allow a caller to ultimately write to disk with another
-userspace id. We could only do this if we were to mount the whole fileystem
+userspace id. We could only do this if we were to mount the whole filesystem
with the caller's or another idmapping. But that solution is limited to a few
filesystems and not very flexible. But this is a use-case that is pretty
important in containerized workloads.
@@ -589,7 +597,7 @@
In both cases changing ownership recursively has grave implications. The most
obvious one is that ownership is changed globally and permanently. In the home
-directory case this change in ownership would even need to happen everytime the
+directory case this change in ownership would even need to happen every time the
user switches from their home to their work machine. For really large sets of
files this becomes increasingly costly.
@@ -662,7 +670,7 @@
To illustrate why this helper currently exists, consider what happens when we
change ownership of an inode from an idmapped mount. After we generated
a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to
-this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership.
+this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership.
Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t``
or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and
``vfsgid_into_kgid()``.
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index eb252fc..09cade7 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -122,6 +122,7 @@
virtiofs
vfat
xfs-delayed-logging-design
+ xfs-maintainer-entry-profile
xfs-self-describing-metadata
xfs-online-fsck-design
zonefs
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index 0ca479d..7be2900 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -85,13 +85,14 @@
struct dentry *dentry, struct fileattr *fa);
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
+ struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
locking rules:
all may block
-============== =============================================
+============== ==================================================
ops i_rwsem(inode)
-============== =============================================
+============== ==================================================
lookup: shared
create: exclusive
link: exclusive (both)
@@ -115,7 +116,8 @@
tmpfile: no
fileattr_get: no or exclusive
fileattr_set: exclusive
-============== =============================================
+get_offset_ctx no
+============== ==================================================
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem
@@ -374,10 +376,17 @@
path (and thus calling into ->invalidate_folio) to block races between page
cache invalidation and page cache filling functions (fault, read, ...).
-->release_folio() is called when the kernel is about to try to drop the
-buffers from the folio in preparation for freeing it. It returns false to
-indicate that the buffers are (or may be) freeable. If ->release_folio is
-NULL, the kernel assumes that the fs has no private interest in the buffers.
+->release_folio() is called when the MM wants to make a change to the
+folio that would invalidate the filesystem's private data. For example,
+it may be about to be removed from the address_space or split. The folio
+is locked and not under writeback. It may be dirty. The gfp parameter
+is not usually used for allocation, but rather to indicate what the
+filesystem may do to attempt to free the private data. The filesystem may
+return false to indicate that the folio's private data cannot be freed.
+If it returns true, it should have already removed the private data from
+the folio. If a filesystem does not provide a ->release_folio method,
+the pagecache will assume that private data is buffer_heads and call
+try_to_free_buffers().
->free_folio() is called when the kernel has dropped the folio
from the page cache.
@@ -509,7 +518,6 @@
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
int (*iopoll) (struct kiocb *kiocb, bool spin);
- int (*iterate) (struct file *, struct dir_context *);
int (*iterate_shared) (struct file *, struct dir_context *);
__poll_t (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
@@ -627,26 +635,29 @@
prototypes::
- void (*open)(struct vm_area_struct*);
- void (*close)(struct vm_area_struct*);
- vm_fault_t (*fault)(struct vm_area_struct*, struct vm_fault *);
+ void (*open)(struct vm_area_struct *);
+ void (*close)(struct vm_area_struct *);
+ vm_fault_t (*fault)(struct vm_fault *);
+ vm_fault_t (*huge_fault)(struct vm_fault *, unsigned int order);
+ vm_fault_t (*map_pages)(struct vm_fault *, pgoff_t start, pgoff_t end);
vm_fault_t (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
vm_fault_t (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *);
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
locking rules:
-============= ========= ===========================
+============= ========== ===========================
ops mmap_lock PageLocked(page)
-============= ========= ===========================
-open: yes
-close: yes
-fault: yes can return with page locked
-map_pages: read
-page_mkwrite: yes can return with page locked
-pfn_mkwrite: yes
-access: yes
-============= ========= ===========================
+============= ========== ===========================
+open: write
+close: read/write
+fault: read can return with page locked
+huge_fault: maybe-read
+map_pages: maybe-read
+page_mkwrite: read can return with page locked
+pfn_mkwrite: read
+access: read
+============= ========== ===========================
->fault() is called when a previously not present pte is about to be faulted
in. The filesystem must find and return the page associated with the passed in
@@ -656,11 +667,18 @@
subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
locked. The VM will unlock the page.
+->huge_fault() is called when there is no PUD or PMD entry present. This
+gives the filesystem the opportunity to install a PUD or PMD sized page.
+Filesystems can also use the ->fault method to return a PMD sized page,
+so implementing this function may not be necessary. In particular,
+filesystems should not call filemap_fault() from ->huge_fault().
+The mmap_lock may not be held when this method is called.
+
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from "start_pgoff"
till "end_pgoff". ->map_pages() is called with the RCU lock held and must
not block. If it's not possible to reach a page without blocking,
-filesystem should skip it. Filesystem should use do_set_pte() to setup
+filesystem should skip it. Filesystem should use set_pte_range() to setup
page table entry. Pointer to entry associated with the page is passed in
"pte" field in vm_fault structure. Pointers to entries for other offsets
should be calculated relative to "pte".
diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst
index 73a4176..48b95d0 100644
--- a/Documentation/filesystems/netfs_library.rst
+++ b/Documentation/filesystems/netfs_library.rst
@@ -155,7 +155,7 @@
an error occurs after calling the helper.
The helpers manage the read request, calling back into the network filesystem
-through the suppplied table of operations. Waits will be performed as
+through the supplied table of operations. Waits will be performed as
necessary before returning for helpers that are meant to be synchronous.
If an error occurs, the ->free_request() will be called to clean up the
diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst
index a94c7a9..4804441 100644
--- a/Documentation/filesystems/nfs/client-identifier.rst
+++ b/Documentation/filesystems/nfs/client-identifier.rst
@@ -131,7 +131,7 @@
the node name by itself is not adequately unique, and can change
unexpectedly. Problematic situations include:
- - NFS-root (diskless) clients, where the local DCHP server (or
+ - NFS-root (diskless) clients, where the local DHCP server (or
equivalent) does not provide a unique host name.
- "Containers" within a single Linux host. If each container has
diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst
index 3d97b8d..4b30dae 100644
--- a/Documentation/filesystems/nfs/exporting.rst
+++ b/Documentation/filesystems/nfs/exporting.rst
@@ -215,3 +215,29 @@
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.
+
+ EXPORT_OP_REMOTE_FS - Backing storage for this filesystem is remote
+ PF_LOCAL_THROTTLE exists for loopback NFSD, where a thread needs to
+ write to one bdi (the final bdi) in order to free up writes queued
+ to another bdi (the client bdi). Such threads get a private balance
+ of dirty pages so that dirty pages for the client bdi do not imact
+ the daemon writing to the final bdi. For filesystems whose durable
+ storage is not local (such as exported NFS filesystems), this
+ constraint has negative consequences. EXPORT_OP_REMOTE_FS enables
+ an export to disable writeback throttling.
+
+ EXPORT_OP_NOATOMIC_ATTR - Filesystem does not update attributes atomically
+ EXPORT_OP_NOATOMIC_ATTR indicates that the exported filesystem
+ cannot provide the semantics required by the "atomic" boolean in
+ NFSv4's change_info4. This boolean indicates to a client whether the
+ returned before and after change attributes were obtained atomically
+ with the respect to the requested metadata operation (UNLINK,
+ OPEN/CREATE, MKDIR, etc).
+
+ EXPORT_OP_FLUSH_ON_CLOSE - Filesystem flushes file data on close(2)
+ On most filesystems, inodes can remain under writeback after the
+ file is closed. NFSD relies on client activity or local flusher
+ threads to handle writeback. Certain filesystems, such as NFS, flush
+ all of an inode's dirty data on last close. Exports that behave this
+ way should set EXPORT_OP_FLUSH_ON_CLOSE so that NFSD knows to skip
+ waiting for writeback when closing such files.
diff --git a/Documentation/filesystems/nfs/rpc-cache.rst b/Documentation/filesystems/nfs/rpc-cache.rst
index bb164ee..339efd7 100644
--- a/Documentation/filesystems/nfs/rpc-cache.rst
+++ b/Documentation/filesystems/nfs/rpc-cache.rst
@@ -78,7 +78,7 @@
include taking references to shared objects.
void update(struct cache_head \*orig, struct cache_head \*new)
- Set the 'content' fileds in 'new' from 'orig'.
+ Set the 'content' fields in 'new' from 'orig'.
int cache_show(struct seq_file \*m, struct cache_detail \*cd, struct cache_head \*h)
Optional. Used to provide a /proc file that lists the
diff --git a/Documentation/filesystems/nfs/rpc-server-gss.rst b/Documentation/filesystems/nfs/rpc-server-gss.rst
index ccaea9e7..5c1a1c5 100644
--- a/Documentation/filesystems/nfs/rpc-server-gss.rst
+++ b/Documentation/filesystems/nfs/rpc-server-gss.rst
@@ -29,7 +29,7 @@
depends on GSSAPI extensions that are KRB5 specific.
GSSAPI is a complex library, and implementing it completely in kernel is
-unwarranted. However GSSAPI operations are fundementally separable in 2
+unwarranted. However GSSAPI operations are fundamentally separable in 2
parts:
- initial context establishment
diff --git a/Documentation/filesystems/nilfs2.rst b/Documentation/filesystems/nilfs2.rst
index 6c49f04..e3a5c89 100644
--- a/Documentation/filesystems/nilfs2.rst
+++ b/Documentation/filesystems/nilfs2.rst
@@ -231,7 +231,7 @@
The logs include regular files, directory files, symbolic link files
-and several meta data files. The mata data files are the files used
+and several meta data files. The meta data files are the files used
to maintain file system meta data. The current version of NILFS2 uses
the following meta data files::
diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst
index f0cf05c..2b86a9b 100644
--- a/Documentation/filesystems/ntfs3.rst
+++ b/Documentation/filesystems/ntfs3.rst
@@ -112,7 +112,7 @@
Todo list
=========
- Full journaling support over JBD. Currently journal replaying is supported
- which is not necessarily as effectice as JBD would be.
+ which is not necessarily as effective as JBD would be.
References
==========
diff --git a/Documentation/filesystems/orangefs.rst b/Documentation/filesystems/orangefs.rst
index 463e376..931159e 100644
--- a/Documentation/filesystems/orangefs.rst
+++ b/Documentation/filesystems/orangefs.rst
@@ -274,7 +274,7 @@
of kcalloced memory. This memory is used as an array of pointers
to each of the pages in the IO buffer through a call to get_user_pages.
* desc_array - a pointer to ``desc_count * (sizeof(struct orangefs_bufmap_desc))``
- bytes of kcalloced memory. This memory is further intialized:
+ bytes of kcalloced memory. This memory is further initialized:
user_desc is the kernel's copy of the IO buffer's ORANGEFS_dev_map_desc
structure. user_desc->ptr points to the IO buffer.
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index eb7d2c8..cdefbe7 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -195,7 +195,7 @@
1. return EXDEV error: this error is returned by rename(2) when trying to
move a file or directory across filesystem boundaries. Hence
- applications are usually prepared to hande this error (mv(1) for example
+ applications are usually prepared to handle this error (mv(1) for example
recursively copies the directory tree). This is the default behavior.
2. If the "redirect_dir" feature is enabled, then the directory will be
@@ -235,7 +235,7 @@
Redirects are not created and not followed.
- "redirect_dir=off":
If "redirect_always_follow" is enabled in the kernel/module config,
- this "off" traslates to "follow", otherwise it translates to "nofollow".
+ this "off" translates to "follow", otherwise it translates to "nofollow".
When the NFS export feature is enabled, every copied up directory is
indexed by the file handle of the lower inode and a file handle of the
@@ -405,6 +405,53 @@
to the absolute path of the "lower data" file in the "data-only" lower layer.
+fs-verity support
+----------------------
+
+During metadata copy up of a lower file, if the source file has
+fs-verity enabled and overlay verity support is enabled, then the
+digest of the lower file is added to the "trusted.overlay.metacopy"
+xattr. This is then used to verify the content of the lower file
+each the time the metacopy file is opened.
+
+When a layer containing verity xattrs is used, it means that any such
+metacopy file in the upper layer is guaranteed to match the content
+that was in the lower at the time of the copy-up. If at any time
+(during a mount, after a remount, etc) such a file in the lower is
+replaced or modified in any way, access to the corresponding file in
+overlayfs will result in EIO errors (either on open, due to overlayfs
+digest check, or from a later read due to fs-verity) and a detailed
+error is printed to the kernel logs. For more details of how fs-verity
+file access works, see :ref:`Documentation/filesystems/fsverity.rst
+<accessing_verity_files>`.
+
+Verity can be used as a general robustness check to detect accidental
+changes in the overlayfs directories in use. But, with additional care
+it can also give more powerful guarantees. For example, if the upper
+layer is fully trusted (by using dm-verity or something similar), then
+an untrusted lower layer can be used to supply validated file content
+for all metacopy files. If additionally the untrusted lower
+directories are specified as "Data-only", then they can only supply
+such file content, and the entire mount can be trusted to match the
+upper layer.
+
+This feature is controlled by the "verity" mount option, which
+supports these values:
+
+- "off":
+ The metacopy digest is never generated or used. This is the
+ default if verity option is not specified.
+- "on":
+ Whenever a metacopy files specifies an expected digest, the
+ corresponding data file must match the specified digest. When
+ generating a metacopy file the verity digest will be set in it
+ based on the source file (if it has one).
+- "require":
+ Same as "on", but additionally all metacopy files must specify a
+ digest (or EIO is returned on open). This means metadata copy up
+ will only be used if the data file has fs-verity enabled,
+ otherwise a full copy-up is used.
+
Sharing and copying layers
--------------------------
@@ -610,6 +657,31 @@
is changed. This is only applicable if all lower/upper/work directories are on
the same filesystem, otherwise it will fallback to normal behaviour.
+
+UUID and fsid
+-------------
+
+The UUID of overlayfs instance itself and the fsid reported by statfs(2) are
+controlled by the "uuid" mount option, which supports these values:
+
+- "null":
+ UUID of overlayfs is null. fsid is taken from upper most filesystem.
+- "off":
+ UUID of overlayfs is null. fsid is taken from upper most filesystem.
+ UUID of underlying layers is ignored.
+- "on":
+ UUID of overlayfs is generated and used to report a unique fsid.
+ UUID is stored in xattr "trusted.overlay.uuid", making overlayfs fsid
+ unique and persistent. This option requires an overlayfs with upper
+ filesystem that supports xattrs.
+- "auto": (default)
+ UUID is taken from xattr "trusted.overlay.uuid" if it exists.
+ Upgrade to "uuid=on" on first time mount of new overlay filesystem that
+ meets the prerequites.
+ Downgrade to "uuid=null" for existing overlay filesystems that were never
+ mounted with "uuid=on".
+
+
Volatile mount
--------------
diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
index 0f5da78..deac4e9 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -177,7 +177,7 @@
**mandatory**
s_export_op is now required for exporting a filesystem.
-isofs, ext2, ext3, resierfs, fat
+isofs, ext2, ext3, reiserfs, fat
can be used as examples of very different filesystems.
---
@@ -470,7 +470,7 @@
**mandatory**
If you implement your own ->llseek() you must handle SEEK_HOLE and
-SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to
+SEEK_DATA. You can handle this by returning -EINVAL, but it would be nicer to
support it in some way. The generic handler assumes that the entire file is
data and there is a virtual hole at the end of the file. So if the provided
offset is less than i_size and SEEK_DATA is specified, return the same offset.
@@ -517,7 +517,7 @@
->create() doesn't take ``struct nameidata *``; unlike the previous
two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that
-local filesystems can ignore tha argument - they are guaranteed that the
+local filesystems can ignore this argument - they are guaranteed that the
object doesn't exist. It's remote/distributed ones that might care...
---
@@ -938,3 +938,14 @@
changed to simplify callers. The passed file is in a non-open state and on
success must be opened before returning (e.g. by calling
finish_open_simple()).
+
+---
+
+**mandatory**
+
+Calling convention for ->huge_fault has changed. It now takes a page
+order instead of an enum page_entry_size, and it may be called without the
+mmap_lock held. All in-tree users have been audited and do not seem to
+depend on the mmap_lock being held, but out of tree users should verify
+for themselves. If they do need it, they can return VM_FAULT_RETRY to
+be called with the mmap_lock held.
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 7897a7d..2b59cff 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -461,6 +461,7 @@
Private_Dirty: 0 kB
Referenced: 892 kB
Anonymous: 0 kB
+ KSM: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
@@ -501,18 +502,21 @@
a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
and a page is modified, the file page is replaced by a private anonymous copy.
+"KSM" reports how many of the pages are KSM pages. Note that KSM-placed zeropages
+are not included, only actual KSM pages.
+
"LazyFree" shows the amount of memory which is marked by madvise(MADV_FREE).
The memory isn't freed immediately with madvise(). It's freed in memory
pressure if the memory is clean. Please note that the printed value might
be lower than the real value due to optimizations used in the current
implementation. If this is not desirable please file a bug report.
-"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
+"AnonHugePages" shows the amount of memory backed by transparent hugepage.
-"ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by
+"ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by
huge pages.
-"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by
+"Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by
hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical
reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field.
@@ -561,11 +565,12 @@
mm mixed map area
hg huge page advise flag
nh no huge page advise flag
- mg mergable advise flag
+ mg mergeable advise flag
bt arm64 BTI guarded page
mt arm64 MTE allocation tags are enabled
um userfaultfd missing tracking
uw userfaultfd wr-protect tracking
+ ss shadow stack page
== =======================================
Note that there is no guarantee that every flag and associated mnemonic will
@@ -1081,7 +1086,7 @@
AnonPages
Non-file backed pages mapped into userspace page tables
Mapped
- files which have been mmaped, such as libraries
+ files which have been mmapped, such as libraries
Shmem
Total memory used by shared memory (shmem) and tmpfs
KReclaimable
@@ -2229,7 +2234,7 @@
Chapter 5: Filesystem behavior
==============================
-Originally, before the advent of pid namepsace, procfs was a global file
+Originally, before the advent of pid namespace, procfs was a global file
system. It means that there was only one procfs instance in the system.
When pid namespace was added, a separate procfs instance was mounted in
diff --git a/Documentation/filesystems/qnx6.rst b/Documentation/filesystems/qnx6.rst
index 523b798..560f3d4 100644
--- a/Documentation/filesystems/qnx6.rst
+++ b/Documentation/filesystems/qnx6.rst
@@ -135,7 +135,7 @@
Character and block special devices do not exist in QNX as those files
are handled by the QNX kernel/drivers and created in /dev independent of the
-underlaying filesystem.
+underlying filesystem.
Long filenames
--------------
diff --git a/Documentation/filesystems/seq_file.rst b/Documentation/filesystems/seq_file.rst
index a672608..1e1713d 100644
--- a/Documentation/filesystems/seq_file.rst
+++ b/Documentation/filesystems/seq_file.rst
@@ -130,7 +130,7 @@
show() function (described below) to print a header at the top of the
output. SEQ_START_TOKEN should only be used if the offset is zero,
however. SEQ_START_TOKEN has no special meaning to the core seq_file
-code. It is provided as a convenience for a start() funciton to
+code. It is provided as a convenience for a start() function to
communicate with the next() and show() functions.
The next function to implement is called, amazingly, next(); its job is to
@@ -217,7 +217,7 @@
is a reasonable thing to do. The seq_file code will also avoid taking any
other locks while the iterator is active.
-The iterater value returned by start() or next() is guaranteed to be
+The iterator value returned by start() or next() is guaranteed to be
passed to a subsequent next() or stop() call. This allows resources
such as locks that were taken to be reliably released. There is *no*
guarantee that the iterator will be passed to show(), though in practice
diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst
index 2cd8fa3..56a26c8 100644
--- a/Documentation/filesystems/tmpfs.rst
+++ b/Documentation/filesystems/tmpfs.rst
@@ -21,8 +21,8 @@
fly using a remount ('mount -o remount ...') of the filesystem. A tmpfs
filesystem can be resized but it cannot be resized to a size below its current
usage. tmpfs also supports POSIX ACLs, and extended attributes for the
-trusted.* and security.* namespaces. ramfs does not use swap and you cannot
-modify any parameter for a ramfs filesystem. The size limit of a ramfs
+trusted.*, security.* and user.* namespaces. ramfs does not use swap and you
+cannot modify any parameter for a ramfs filesystem. The size limit of a ramfs
filesystem is how much memory you have available, and so care must be taken if
used so to not run out of memory.
@@ -97,6 +97,9 @@
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.
+If nr_inodes is not 0, that limited space for inodes is also used up by
+extended attributes: "df -i"'s IUsed and IUse% increase, IFree decreases.
+
tmpfs blocks may be swapped out, when there is a shortage of memory.
tmpfs has a mount option to disable its use of swap:
@@ -123,6 +126,37 @@
be used to deny huge pages on all tmpfs mounts in an emergency, or to
force huge pages on all tmpfs mounts for testing.
+tmpfs also supports quota with the following mount options
+
+======================== =================================================
+quota User and group quota accounting and enforcement
+ is enabled on the mount. Tmpfs is using hidden
+ system quota files that are initialized on mount.
+usrquota User quota accounting and enforcement is enabled
+ on the mount.
+grpquota Group quota accounting and enforcement is enabled
+ on the mount.
+usrquota_block_hardlimit Set global user quota block hard limit.
+usrquota_inode_hardlimit Set global user quota inode hard limit.
+grpquota_block_hardlimit Set global group quota block hard limit.
+grpquota_inode_hardlimit Set global group quota inode hard limit.
+======================== =================================================
+
+None of the quota related mount options can be set or changed on remount.
+
+Quota limit parameters accept a suffix k, m or g for kilo, mega and giga
+and can't be changed on remount. Default global quota limits are taking
+effect for any and all user/group/project except root the first time the
+quota entry for user/group/project id is being accessed - typically the
+first time an inode with a particular id ownership is being created after
+the mount. In other words, instead of the limits being initialized to zero,
+they are initialized with the particular value provided with these mount
+options. The limits can be changed for any user/group id at any time as they
+normally can be.
+
+Note that tmpfs quotas do not support user namespaces so no uid/gid
+translation is done if quotas are enabled inside user namespaces.
+
tmpfs has a mount option to set the NUMA memory allocation policy for
all files in that instance (if CONFIG_NUMA is enabled) - which can be
adjusted on the fly via 'mount -o remount ...'
diff --git a/Documentation/filesystems/ubifs-authentication.rst b/Documentation/filesystems/ubifs-authentication.rst
index 5210aed..3d85ee8 100644
--- a/Documentation/filesystems/ubifs-authentication.rst
+++ b/Documentation/filesystems/ubifs-authentication.rst
@@ -130,7 +130,7 @@
Journal
~~~~~~~
-To avoid wearing out the flash, the index is only persisted (*commited*) when
+To avoid wearing out the flash, the index is only persisted (*committed*) when
certain conditions are met (eg. ``fsync(2)``). The journal is used to record
any changes (in form of inode nodes, data nodes etc.) between commits
of the index. During mount, the journal is read from the flash and replayed
diff --git a/Documentation/filesystems/vfat.rst b/Documentation/filesystems/vfat.rst
index 760a4d8..b289c44 100644
--- a/Documentation/filesystems/vfat.rst
+++ b/Documentation/filesystems/vfat.rst
@@ -50,7 +50,7 @@
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
- check is too unflexible. With this option you can
+ check is too inflexible. With this option you can
relax it.
**codepage=###**
diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst
index cb2a97e..99acc2e 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -260,9 +260,11 @@
void (*evict_inode) (struct inode *);
void (*put_super) (struct super_block *);
int (*sync_fs)(struct super_block *sb, int wait);
- int (*freeze_super) (struct super_block *);
+ int (*freeze_super) (struct super_block *sb,
+ enum freeze_holder who);
int (*freeze_fs) (struct super_block *);
- int (*thaw_super) (struct super_block *);
+ int (*thaw_super) (struct super_block *sb,
+ enum freeze_wholder who);
int (*unfreeze_fs) (struct super_block *);
int (*statfs) (struct dentry *, struct kstatfs *);
int (*remount_fs) (struct super_block *, int *, char *);
@@ -515,6 +517,7 @@
int (*fileattr_set)(struct mnt_idmap *idmap,
struct dentry *dentry, struct fileattr *fa);
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
+ struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
};
Again, all methods are called without any locks being held, unless
@@ -675,7 +678,10 @@
called on ioctl(FS_IOC_SETFLAGS) and ioctl(FS_IOC_FSSETXATTR) to
change miscellaneous file flags and attributes. Callers hold
i_rwsem exclusive. If unset, then fall back to f_op->ioctl().
-
+``get_offset_ctx``
+ called to get the offset context for a directory inode. A
+ filesystem must define this operation to use
+ simple_offset_dir_operations.
The Address Space Object
========================
@@ -761,7 +767,7 @@
a file sync request is made. After an error has been reported on one
request, subsequent requests on the same file descriptor should return
0, unless further writeback errors have occurred since the previous file
-syncronization.
+synchronization.
Ideally, the kernel would report errors only on file descriptions on
which writes were done that subsequently failed to be written back. The
@@ -1074,7 +1080,6 @@
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
int (*iopoll)(struct kiocb *kiocb, bool spin);
- int (*iterate) (struct file *, struct dir_context *);
int (*iterate_shared) (struct file *, struct dir_context *);
__poll_t (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
@@ -1126,12 +1131,8 @@
``iopoll``
called when aio wants to poll for completions on HIPRI iocbs
-``iterate``
- called when the VFS needs to read the directory contents
-
``iterate_shared``
- called when the VFS needs to read the directory contents when
- filesystem supports concurrent dir iterators
+ called when the VFS needs to read the directory contents
``poll``
called by the VFS when a process wants to check if there is
diff --git a/Documentation/filesystems/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs-maintainer-entry-profile.rst
new file mode 100644
index 0000000..32b6ac4
--- /dev/null
+++ b/Documentation/filesystems/xfs-maintainer-entry-profile.rst
@@ -0,0 +1,194 @@
+XFS Maintainer Entry Profile
+============================
+
+Overview
+--------
+XFS is a well known high-performance filesystem in the Linux kernel.
+The aim of this project is to provide and maintain a robust and
+performant filesystem.
+
+Patches are generally merged to the for-next branch of the appropriate
+git repository.
+After a testing period, the for-next branch is merged to the master
+branch.
+
+Kernel code are merged to the xfs-linux tree[0].
+Userspace code are merged to the xfsprogs tree[1].
+Test cases are merged to the xfstests tree[2].
+Ondisk format documentation are merged to the xfs-documentation tree[3].
+
+All patchsets involving XFS *must* be cc'd in their entirety to the mailing
+list linux-xfs@vger.kernel.org.
+
+Roles
+-----
+There are eight key roles in the XFS project.
+A person can take on multiple roles, and a role can be filled by
+multiple people.
+Anyone taking on a role is advised to check in with themselves and
+others on a regular basis about burnout.
+
+- **Outside Contributor**: Anyone who sends a patch but is not involved
+ in the XFS project on a regular basis.
+ These folks are usually people who work on other filesystems or
+ elsewhere in the kernel community.
+
+- **Developer**: Someone who is familiar with the XFS codebase enough to
+ write new code, documentation, and tests.
+
+ Developers can often be found in the IRC channel mentioned by the ``C:``
+ entry in the kernel MAINTAINERS file.
+
+- **Senior Developer**: A developer who is very familiar with at least
+ some part of the XFS codebase and/or other subsystems in the kernel.
+ These people collectively decide the long term goals of the project
+ and nudge the community in that direction.
+ They should help prioritize development and review work for each release
+ cycle.
+
+ Senior developers tend to be more active participants in the IRC channel.
+
+- **Reviewer**: Someone (most likely also a developer) who reads code
+ submissions to decide:
+
+ 0. Is the idea behind the contribution sound?
+ 1. Does the idea fit the goals of the project?
+ 2. Is the contribution designed correctly?
+ 3. Is the contribution polished?
+ 4. Can the contribution be tested effectively?
+
+ Reviewers should identify themselves with an ``R:`` entry in the kernel
+ and fstests MAINTAINERS files.
+
+- **Testing Lead**: This person is responsible for setting the test
+ coverage goals of the project, negotiating with developers to decide
+ on new tests for new features, and making sure that developers and
+ release managers execute on the testing.
+
+ The testing lead should identify themselves with an ``M:`` entry in
+ the XFS section of the fstests MAINTAINERS file.
+
+- **Bug Triager**: Someone who examines incoming bug reports in just
+ enough detail to identify the person to whom the report should be
+ forwarded.
+
+ The bug triagers should identify themselves with a ``B:`` entry in
+ the kernel MAINTAINERS file.
+
+- **Release Manager**: This person merges reviewed patchsets into an
+ integration branch, tests the result locally, pushes the branch to a
+ public git repository, and sends pull requests further upstream.
+ The release manager is not expected to work on new feature patchsets.
+ If a developer and a reviewer fail to reach a resolution on some point,
+ the release manager must have the ability to intervene to try to drive a
+ resolution.
+
+ The release manager should identify themselves with an ``M:`` entry in
+ the kernel MAINTAINERS file.
+
+- **Community Manager**: This person calls and moderates meetings of as many
+ XFS participants as they can get when mailing list discussions prove
+ insufficient for collective decisionmaking.
+ They may also serve as liaison between managers of the organizations
+ sponsoring work on any part of XFS.
+
+- **LTS Maintainer**: Someone who backports and tests bug fixes from
+ uptream to the LTS kernels.
+ There tend to be six separate LTS trees at any given time.
+
+ The maintainer for a given LTS release should identify themselves with an
+ ``M:`` entry in the MAINTAINERS file for that LTS tree.
+ Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that
+ same file.
+
+Submission Checklist Addendum
+-----------------------------
+Please follow these additional rules when submitting to XFS:
+
+- Patches affecting only the filesystem itself should be based against
+ the latest -rc or the for-next branch.
+ These patches will be merged back to the for-next branch.
+
+- Authors of patches touching other subsystems need to coordinate with
+ the maintainers of XFS and the relevant subsystems to decide how to
+ proceed with a merge.
+
+- Any patchset changing XFS should be cc'd in its entirety to linux-xfs.
+ Do not send partial patchsets; that makes analysis of the broader
+ context of the changes unnecessarily difficult.
+
+- Anyone making kernel changes that have corresponding changes to the
+ userspace utilities should send the userspace changes as separate
+ patchsets immediately after the kernel patchsets.
+
+- Authors of bug fix patches are expected to use fstests[2] to perform
+ an A/B test of the patch to determine that there are no regressions.
+ When possible, a new regression test case should be written for
+ fstests.
+
+- Authors of new feature patchsets must ensure that fstests will have
+ appropriate functional and input corner-case test cases for the new
+ feature.
+
+- When implementing a new feature, it is strongly suggested that the
+ developers write a design document to answer the following questions:
+
+ * **What** problem is this trying to solve?
+
+ * **Who** will benefit from this solution, and **where** will they
+ access it?
+
+ * **How** will this new feature work? This should touch on major data
+ structures and algorithms supporting the solution at a higher level
+ than code comments.
+
+ * **What** userspace interfaces are necessary to build off of the new
+ features?
+
+ * **How** will this work be tested to ensure that it solves the
+ problems laid out in the design document without causing new
+ problems?
+
+ The design document should be committed in the kernel documentation
+ directory.
+ It may be omitted if the feature is already well known to the
+ community.
+
+- Patchsets for the new tests should be submitted as separate patchsets
+ immediately after the kernel and userspace code patchsets.
+
+- Changes to the on-disk format of XFS must be described in the ondisk
+ format document[3] and submitted as a patchset after the fstests
+ patchsets.
+
+- Patchsets implementing bug fixes and further code cleanups should put
+ the bug fixes at the beginning of the series to ease backporting.
+
+Key Release Cycle Dates
+-----------------------
+Bug fixes may be sent at any time, though the release manager may decide to
+defer a patch when the next merge window is close.
+
+Code submissions targeting the next merge window should be sent between
+-rc1 and -rc6.
+This gives the community time to review the changes, to suggest other changes,
+and for the author to retest those changes.
+
+Code submissions also requiring changes to fs/iomap and targeting the
+next merge window should be sent between -rc1 and -rc4.
+This allows the broader kernel community adequate time to test the
+infrastructure changes.
+
+Review Cadence
+--------------
+In general, please wait at least one week before pinging for feedback.
+To find reviewers, either consult the MAINTAINERS file, or ask
+developers that have Reviewed-by tags for XFS changes to take a look and
+offer their opinion.
+
+References
+----------
+| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/
+| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/
+| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
+| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/
diff --git a/Documentation/filesystems/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs-online-fsck-design.rst
index 791ab26..1625d11 100644
--- a/Documentation/filesystems/xfs-online-fsck-design.rst
+++ b/Documentation/filesystems/xfs-online-fsck-design.rst
@@ -293,7 +293,7 @@
Before starting repairs, the summary counters are checked and any necessary
repairs are performed so that subsequent repairs will not fail the resource
reservation step due to wildly incorrect summary counters.
- Unsuccesful repairs are requeued as long as forward progress on repairs is
+ Unsuccessful repairs are requeued as long as forward progress on repairs is
made somewhere in the filesystem.
Free space in the filesystem is trimmed at the end of phase 4 if the
filesystem is clean.
@@ -542,7 +542,7 @@
Inspiration for quota and file link count repair strategies were drawn from
sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View
-Maintenace") of G. Graefe, `"Concurrent Queries and Updates in Summary Views
+Maintenance") of G. Graefe, `"Concurrent Queries and Updates in Summary Views
and Their Indexes"
<http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011.
@@ -605,7 +605,7 @@
The cron job does not have this protection.
- **Fuzz Kiddiez**: There are many people now who seem to think that running
- automated fuzz testing of ondisk artifacts to find mischevious behavior and
+ automated fuzz testing of ondisk artifacts to find mischievous behavior and
spraying exploit code onto the public mailing list for instant zero-day
disclosure is somehow of some social benefit.
In the view of this author, the benefit is realized only when the fuzz
@@ -1351,7 +1351,7 @@
rooted at block 0) is created to map hashes of the attribute names to leaf
blocks in the attr fork.
-Checking an extended attribute structure is not so straightfoward due to the
+Checking an extended attribute structure is not so straightforward due to the
lack of separation between attr blocks and index blocks.
Scrub must read each block mapped by the attr fork and ignore the non-leaf
blocks:
@@ -1401,7 +1401,7 @@
beyond one block, then a dabtree is used to map hashes of dirent names to
directory data blocks.
-Checking a directory is pretty straightfoward:
+Checking a directory is pretty straightforward:
1. Walk the dabtree in the second partition (if present) to ensure that there
are no irregularities in the blocks or dabtree mappings that do not point to
@@ -1524,7 +1524,7 @@
should be relatively rare as compared to filesystem change operations.
Online fsck coordinates with transaction chains as follows:
-* For each AG, maintain a count of intent items targetting that AG.
+* For each AG, maintain a count of intent items targeting that AG.
The count should be bumped whenever a new item is added to the chain.
The count should be dropped when the filesystem has locked the AG header
buffers and finished the work.
@@ -2102,7 +2102,7 @@
kernel.
To sort records in a reasonably short amount of time, ``xfarray`` takes
advantage of the binary subpartitioning offered by quicksort, but it also uses
-heapsort to hedge aginst performance collapse if the chosen quicksort pivots
+heapsort to hedge against performance collapse if the chosen quicksort pivots
are poor.
Both algorithms are (in general) O(n * lg(n)), but there is a wide performance
gulf between the two implementations.
@@ -2566,8 +2566,8 @@
The transaction rolling in steps 2c and 3 represent a weakness in the repair
algorithm, because a log flush and a crash before the end of the reap step can
result in space leaking.
-Online repair functions minimize the chances of this occuring by using very
-large transactions, which each can accomodate many thousands of block freeing
+Online repair functions minimize the chances of this occurring by using very
+large transactions, which each can accommodate many thousands of block freeing
instructions.
Repair moves on to reaping the old blocks, which will be presented in a
subsequent :ref:`section<reaping>` after a few case studies of bulk loading.
@@ -5090,7 +5090,7 @@
counters) as phase 6.
The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map
to find areas that are allocated to file data fork extents.
-Gaps betweeen data fork extents that are smaller than 64k are treated as if
+Gaps between data fork extents that are smaller than 64k are treated as if
they were data fork extents to reduce the command setup overhead.
When the space map scan accumulates a region larger than 32MB, a media
verification request is sent to the disk as a directio read of the raw block
diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst
index 394b9f1..c22124c 100644
--- a/Documentation/filesystems/zonefs.rst
+++ b/Documentation/filesystems/zonefs.rst
@@ -378,7 +378,7 @@
sequential zone files. Failure to do so can result in write errors.
* **max_active_seq_files**: This attribute reports the maximum number of
sequential zone files that are in an active state, that is, sequential zone
- files that are partially writen (not empty nor full) or that have a zone that
+ files that are partially written (not empty nor full) or that have a zone that
is explicitly open (which happens only if the *explicit-open* mount option is
used). This number is always equal to the maximum number of active zones that
the device supports. A value of 0 means that the mounted device has no limit
diff --git a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst
index f37fc90..89419e1 100644
--- a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst
+++ b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst
@@ -5,9 +5,8 @@
=====================
Hardware functionality specific to Chrome OS is exposed through a Chrome OS ACPI device.
-The plug and play ID of a Chrome OS ACPI device is GGL0001. GGL is a valid PNP ID of Google.
-PNP ID can be used with the ACPI devices according to the guidelines. The following ACPI
-objects are supported:
+The plug and play ID of a Chrome OS ACPI device is GGL0001 and the hardware ID is
+GOOG0016. The following ACPI objects are supported:
.. flat-table:: Supported ACPI Objects
:widths: 1 2
diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst
index 784850a..868a0a4 100644
--- a/Documentation/firmware-guide/acpi/osi.rst
+++ b/Documentation/firmware-guide/acpi/osi.rst
@@ -55,7 +55,7 @@
However this was discovered to be abused by other BIOS vendors to change
completely unrelated code on completely unrelated systems. This prompted
-an evaluation of all of it's uses. This uncovered that they aren't needed
+an evaluation of all of its uses. This uncovered that they aren't needed
for any of the original reasons. As such, the kernel will not respond to
any custom Linux-* strings by default.
diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst
index 0499aa9..59a4f54 100644
--- a/Documentation/gpu/amdgpu/display/mpo-overview.rst
+++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst
@@ -178,7 +178,7 @@
AMDGPU supports display MPO when using multiple displays; however, this feature
behavior heavily relies on the compositor implementation. Keep in mind that
-usespace can define different policies. For example, some OSes can use MPO to
+userspace can define different policies. For example, some OSes can use MPO to
protect the plane that handles the video playback; notice that we don't have
many limitations for a single display. Nonetheless, this manipulation can have
many more restrictions for a multi-display scenario. The below example shows a
diff --git a/Documentation/gpu/amdgpu/flashing.rst b/Documentation/gpu/amdgpu/flashing.rst
new file mode 100644
index 0000000..bd745c4
--- /dev/null
+++ b/Documentation/gpu/amdgpu/flashing.rst
@@ -0,0 +1,33 @@
+=======================
+ dGPU firmware flashing
+=======================
+
+IFWI
+----
+Flashing the dGPU integrated firmware image (IFWI) is supported by GPUs that
+use the PSP to orchestrate the update (Navi3x or newer GPUs).
+For supported GPUs, `amdgpu` will export a series of sysfs files that can be
+used for the flash process.
+
+The IFWI flash process is:
+
+1. Ensure the IFWI image is intended for the dGPU on the system.
+2. "Write" the IFWI image to the sysfs file `psp_vbflash`. This will stage the IFWI in memory.
+3. "Read" from the `psp_vbflash` sysfs file to initiate the flash process.
+4. Poll the `psp_vbflash_status` sysfs file to determine when the flash process completes.
+
+USB-C PD F/W
+------------
+On GPUs that support flashing an updated USB-C PD firmware image, the process
+is done using the `usbc_pd_fw` sysfs file.
+
+* Reading the file will provide the current firmware version.
+* Writing the name of a firmware payload stored in `/lib/firmware/amdgpu` to the sysfs file will initiate the flash process.
+
+The firmware payload stored in `/lib/firmware/amdgpu` can be named any name
+as long as it doesn't conflict with other existing binaries that are used by
+`amdgpu`.
+
+sysfs files
+-----------
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst
index 03c2966..912e699 100644
--- a/Documentation/gpu/amdgpu/index.rst
+++ b/Documentation/gpu/amdgpu/index.rst
@@ -10,6 +10,7 @@
module-parameters
driver-core
display/index
+ flashing
xgmi
ras
thermal
diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst
index 4411e69..c08bcbb 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,14 @@
=============
.. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+================
+
+VM_BIND / EXEC uAPI
+-------------------
+
+.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index b8ab05e..b748b8a 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -378,7 +378,7 @@
HDMI Infoframes Helper Reference
================================
-Strictly speaking this is not a DRM helper library but generally useable
+Strictly speaking this is not a DRM helper library but generally usable
by any driver interfacing with HDMI outputs like v4l or alsa drivers.
But it nicely fits into the overall topic of mode setting helper
libraries and hence is also included here.
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index c92d425..a0c83fc 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -66,11 +66,11 @@
For the output routing the first step is encoders (represented by
:c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those
are really just internal artifacts of the helper libraries used to implement KMS
-drivers. Besides that they make it unecessarily more complicated for userspace
+drivers. Besides that they make it unnecessarily more complicated for userspace
to figure out which connections between a CRTC and a connector are possible, and
what kind of cloning is supported, they serve no purpose in the userspace API.
Unfortunately encoders have been exposed to userspace, hence can't remove them
-at this point. Futhermore the exposed restrictions are often wrongly set by
+at this point. Furthermore the exposed restrictions are often wrongly set by
drivers, and in many cases not powerful enough to express the real restrictions.
A CRTC can be connected to multiple encoders, and for an active CRTC there must
be at least one encoder.
@@ -260,7 +260,7 @@
drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct
drm_connector_state <drm_connector_state>` for connectors. These are the only
objects with userspace-visible and settable state. For internal state drivers
- can subclass these structures through embeddeding, or add entirely new state
+ can subclass these structures through embedding, or add entirely new state
structures for their globally shared hardware functions, see :c:type:`struct
drm_private_state<drm_private_state>`.
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd35..c19b34b 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,42 @@
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
+DRM GPU VA Manager
+==================
+
+Overview
+--------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+ :doc: Overview
+
+Split and Merge
+---------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+ :doc: Split and Merge
+
+Locking
+-------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+ :doc: Locking
+
+Examples
+--------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+ :doc: Examples
+
+DRM GPU VA Manager Function References
+--------------------------------------
+
+.. kernel-doc:: include/drm/drm_gpuva_mgr.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+ :export:
+
DRM Buddy Allocator
===================
@@ -481,8 +517,10 @@
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+.. _drm_sync_objects:
+
DRM Sync Objects
-===========================
+================
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:doc: Overview
@@ -493,6 +531,18 @@
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
+DRM Execution context
+=====================
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :export:
+
GPU Scheduler
=============
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
index fe35a29..044e6b2 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -8,7 +8,7 @@
`fops->show_fdinfo()` as part of the driver specific file operations registered
in the `struct drm_driver` object registered with the DRM core.
-One purpose of this output is to enable writing as generic as practicaly
+One purpose of this output is to enable writing as generic as practically
feasible `top(1)` like userspace monitoring tools.
Given the differences between various DRM drivers the specification of the
@@ -119,7 +119,7 @@
engine. Taken together with drm-cycles-<keystr>, this can be used to calculate
percentage utilization of the engine, whereas drm-engine-<keystr> only reflects
time active without considering what frequency the engine is operating as a
-percentage of it's maximum frequency.
+percentage of its maximum frequency.
Memory
^^^^^^
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 60ea217..378e825 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -304,10 +304,10 @@
and the only way to synchronize across contexts (even from the same
file descriptor) is through the use of fences. At least as far back as
Gen4, also have that a context carries with it a GPU HW context;
-the HW context is essentially (most of atleast) the state of a GPU.
+the HW context is essentially (most of at least) the state of a GPU.
In addition to the ordering guarantees, the kernel will restore GPU
state via HW context when commands are issued to a context, this saves
-user space the need to restore (most of atleast) the GPU state at the
+user space the need to restore (most of at least) the GPU state at the
start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer
work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1)
to identify what context to use with the command.
diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
index 07ed22e..0f95908 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,7 +17,7 @@
,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector
,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB
-i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255."
+i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255."
,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD
,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c8..633a016 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -328,7 +328,7 @@
achieve this, split the komeda device into two layers: CORE and CHIP.
- CORE: for common features and capabilities handling.
-- CHIP: for register programing and HW specific feature (limitation) handling.
+- CHIP: for register programming and HW specific feature (limitation) handling.
CORE can access CHIP by three chip function structures:
@@ -481,7 +481,7 @@
Now we have two level devices:
- komeda_dev: describes the real display hardware.
-- komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS.
+- komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS.
All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev,
the module driver is only a simple wrapper to pass the Linux command
diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
index 240ef20..9509cc4 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -23,7 +23,7 @@
The module that generated the crashdump.
time
- The kernel time at crash formated as seconds.microseconds.
+ The kernel time at crash formatted as seconds.microseconds.
comm
Comm string for the binary that generated the fault.
diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst
index d630f15..c237ebc0 100644
--- a/Documentation/gpu/rfc/i915_scheduler.rst
+++ b/Documentation/gpu/rfc/i915_scheduler.rst
@@ -37,7 +37,7 @@
* Watchdog hooks into DRM scheduler
* Lots of complexity of the GuC backend can be pulled out once
integrated with DRM scheduler (e.g. state machine gets
- simplier, locking gets simplier, etc...)
+ simpler, locking gets simpler, etc...)
* Execlists backend will minimum required to hook in the DRM scheduler
* Legacy interface
* Features like timeslicing / preemption / virtual engines would
@@ -135,9 +135,13 @@
drm_i915_context_engines_parallel_submit to the uAPI to implement this
extension.
+.. c:namespace-push:: rfc
+
.. kernel-doc:: include/uapi/drm/i915_drm.h
:functions: i915_context_engines_parallel_submit
+.. c:namespace-pop::
+
Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
-------------------------------------------------------------------
Contexts that have been configured with the 'set_parallel' extension can only
diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst
index 9a1dcdf..0b3b525 100644
--- a/Documentation/gpu/rfc/i915_vm_bind.rst
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -90,7 +90,7 @@
path (where required mappings are already bound) submission latency is O(1)
w.r.t the number of VM private BOs.
-VM_BIND locking hirarchy
+VM_BIND locking hierarchy
-------------------------
The locking design here supports the older (execlist based) execbuf mode, the
newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 68bdafa..03fe5d1 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -49,14 +49,18 @@
really want an atomic modeset interface, so this is all about the bright
future.
-There is a conversion guide for atomic and all you need is a GPU for a
-non-converted driver (again virtual HW drivers for KVM are still all
-suitable).
+There is a conversion guide for atomic [1]_ and all you need is a GPU for a
+non-converted driver. The "Atomic mode setting design overview" series [2]_
+[3]_ at LWN.net can also be helpful.
As part of this drivers also need to convert to universal plane (which means
exposing primary & cursor as proper plane objects). But that's much easier to
do by directly using the new atomic helper driver callbacks.
+ .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
+ .. [2] https://lwn.net/Articles/653071/
+ .. [3] https://lwn.net/Articles/653466/
+
Contact: Daniel Vetter, respective driver maintainers
Level: Advanced
@@ -65,7 +69,7 @@
---------------------------------------------------------
We have a helper to get this right with drm_plane_helper_check_update(), but
-it's not consistently used. This should be fixed, preferrably in the atomic
+it's not consistently used. This should be fixed, preferably in the atomic
helpers (and drivers then moved over to clipped coordinates). Probably the
helper should also be moved from drm_plane_helper.c to the atomic helpers, to
avoid confusion - the other helpers in that file are all deprecated legacy
@@ -181,13 +185,13 @@
To solve this we need one standard per-object locking mechanism, which is
dma_resv_lock(). This lock needs to be called as the outermost lock, with all
-other driver specific per-object locks removed. The problem is tha rolling out
+other driver specific per-object locks removed. The problem is that rolling out
the actual change to the locking contract is a flag day, due to struct dma_buf
buffer sharing.
Level: Expert
-Convert logging to drm_* functions with drm_device paramater
+Convert logging to drm_* functions with drm_device parameter
------------------------------------------------------------
For drivers which could have multiple instances, it is necessary to
@@ -244,7 +248,7 @@
Benchmark and optimize blitting and format-conversion function
--------------------------------------------------------------
-Drawing to dispay memory quickly is crucial for many applications'
+Drawing to display memory quickly is crucial for many applications'
performance.
On at least x86-64, sys_imageblit() is significantly slower than
@@ -319,15 +323,6 @@
Level: Advanced
-struct drm_gem_object_funcs
----------------------------
-
-GEM objects can now have a function table instead of having the callbacks on the
-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
-
connector register/unregister fixes
-----------------------------------
@@ -452,6 +447,44 @@
Level: Starter
+Remove driver dependencies on FB_DEVICE
+---------------------------------------
+
+A number of fbdev drivers provide attributes via sysfs and therefore depend
+on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make
+any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective
+code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not
+all drivers might be able to drop CONFIG_FB_DEVICE.
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>
+
+Level: Starter
+
+Clean up checks for already prepared/enabled in panels
+------------------------------------------------------
+
+In a whole pile of panel drivers, we have code to make the
+prepare/unprepare/enable/disable callbacks behave as no-ops if they've already
+been called. To get some idea of the duplicated code, try::
+
+ git grep 'if.*>prepared' -- drivers/gpu/drm/panel
+ git grep 'if.*>enabled' -- drivers/gpu/drm/panel
+
+In the patch ("drm/panel: Check for already prepared/enabled in drm_panel")
+we've moved this check to the core. Now we can most definitely remove the
+check from the individual panels and save a pile of code.
+
+In adition to removing the check from the individual panels, it is believed
+that even the core shouldn't need this check and that should be considered
+an error if other code ever relies on this check. The check in the core
+currently prints a warning whenever something is relying on this check with
+dev_warn(). After a little while, we likely want to promote this to a
+WARN(1) to help encourage folks not to rely on this behavior.
+
+Contact: Douglas Anderson <dianders@chromium.org>
+
+Level: Starter/Intermediate
+
Core refactorings
=================
@@ -749,16 +782,16 @@
existing fbdev code.
More complex fbdev drivers can be refactored step-by-step into a DRM
-driver with the help of the DRM fbconv helpers. [1] These helpers provide
+driver with the help of the DRM fbconv helpers [4]_. These helpers provide
the transition layer between the DRM core infrastructure and the fbdev
driver interface. Create a new DRM driver on top of the fbconv helpers,
copy over the fbdev driver, and hook it up to the DRM code. Examples for
-several fbdev drivers are available at [1] and a tutorial of this process
-available at [2]. The result is a primitive DRM driver that can run X11
-and Weston.
+several fbdev drivers are available in Thomas Zimmermann's fbconv tree
+[4]_, as well as a tutorial of this process [5]_. The result is a primitive
+DRM driver that can run X11 and Weston.
- - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
- - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
+ .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
+ .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
Contact: Thomas Zimmermann <tzimmermann@suse.de>
diff --git a/Documentation/hid/hidintro.rst b/Documentation/hid/hidintro.rst
new file mode 100644
index 0000000..73523e3
--- /dev/null
+++ b/Documentation/hid/hidintro.rst
@@ -0,0 +1,524 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Introduction to HID report descriptors
+======================================
+
+This chapter is meant to give a broad overview of what HID report
+descriptors are, and of how a casual (non-kernel) programmer can deal
+with HID devices that are not working well with Linux.
+
+.. contents::
+ :local:
+ :depth: 2
+
+.. toctree::
+ :maxdepth: 2
+
+ hidreport-parsing
+
+
+Introduction
+============
+
+HID stands for Human Interface Device, and can be whatever device you
+are using to interact with a computer, be it a mouse, a touchpad, a
+tablet, a microphone.
+
+Many HID devices work out the box, even if their hardware is different.
+For example, mice can have any number of buttons; they may have a
+wheel; movement sensitivity differs between different models, and so
+on. Nonetheless, most of the time everything just works, without the
+need to have specialized code in the kernel for every mouse model
+developed since 1970.
+
+This is because modern HID devices do advertise their capabilities
+through the *HID report descriptor*, a fixed set of bytes describing
+exactly what *HID reports* may be sent between the device and the host
+and the meaning of each individual bit in those reports. For example,
+a HID Report Descriptor may specify that "in a report with ID 3 the
+bits from 8 to 15 is the delta x coordinate of a mouse".
+
+The HID report itself then merely carries the actual data values
+without any extra meta information. Note that HID reports may be sent
+from the device ("Input Reports", i.e. input events), to the device
+("Output Reports" to e.g. change LEDs) or used for device configuration
+("Feature reports"). A device may support one or more HID reports.
+
+The HID subsystem is in charge of parsing the HID report descriptors,
+and converts HID events into normal input device interfaces (see
+Documentation/hid/hid-transport.rst). Devices may misbehave because the
+HID report descriptor provided by the device is wrong, or because it
+needs to be dealt with in a special way, or because some special
+device or interaction mode is not handled by the default code.
+
+The format of HID report descriptors is described by two documents,
+available from the `USB Implementers Forum <https://www.usb.org/>`_
+`HID web page <https://www.usb.org/hid>`_ address:
+
+ * the `HID USB Device Class Definition
+ <https://www.usb.org/document-library/device-class-definition-hid-111>`_ (HID Spec from now on)
+ * the `HID Usage Tables <https://usb.org/document-library/hid-usage-tables-14>`_ (HUT from now on)
+
+The HID subsystem can deal with different transport drivers
+(USB, I2C, Bluetooth, etc.). See Documentation/hid/hid-transport.rst.
+
+Parsing HID report descriptors
+==============================
+
+The current list of HID devices can be found at ``/sys/bus/hid/devices/``.
+For each device, say ``/sys/bus/hid/devices/0003\:093A\:2510.0002/``,
+one can read the corresponding report descriptor::
+
+ $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
+ 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
+ 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
+ 00000030 81 06 c0 c0 |....|
+ 00000034
+
+Optional: the HID report descriptor can be read also by
+directly accessing the hidraw driver [#hidraw]_.
+
+The basic structure of HID report descriptors is defined in the HID
+spec, while HUT "defines constants that can be interpreted by an
+application to identify the purpose and meaning of a data field in a
+HID report". Each entry is defined by at least two bytes, where the
+first one defines what type of value is following and is described in
+the HID spec, while the second one carries the actual value and is
+described in the HUT.
+
+HID report descriptors can, in principle, be painstakingly parsed by
+hand, byte by byte.
+
+A short introduction on how to do this is sketched in
+Documentation/hid/hidreport-parsing.rst; you only need to understand it
+if you need to patch HID report descriptors.
+
+In practice you should not parse HID report descriptors by hand; rather,
+you should use an existing parser. Among all the available ones
+
+ * the online `USB Descriptor and Request Parser
+ <http://eleccelerator.com/usbdescreqparser/>`_;
+ * `hidrdd <https://github.com/abend0c1/hidrdd>`_,
+ that provides very detailed and somewhat verbose descriptions
+ (verbosity can be useful if you are not familiar with HID report
+ descriptors);
+ * `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_,
+ a complete utility set that allows, among other things,
+ to record and replay the raw HID reports and to debug
+ and replay HID devices.
+ It is being actively developed by the Linux HID subsystem maintainers.
+
+Parsing the mouse HID report descriptor with `hid-tools
+<https://gitlab.freedesktop.org/libevdev/hid-tools>`_ leads to
+(explanations interposed)::
+
+ $ ./hid-decode /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ # device 0:0
+ # 0x05, 0x01, // Usage Page (Generic Desktop) 0
+ # 0x09, 0x02, // Usage (Mouse) 2
+ # 0xa1, 0x01, // Collection (Application) 4
+ # 0x09, 0x01, // Usage (Pointer) 6
+ # 0xa1, 0x00, // Collection (Physical) 8
+ # 0x05, 0x09, // Usage Page (Button) 10
+
+what follows is a button ::
+
+ # 0x19, 0x01, // Usage Minimum (1) 12
+ # 0x29, 0x03, // Usage Maximum (3) 14
+
+first button is button number 1, last button is button number 3 ::
+
+ # 0x15, 0x00, // Logical Minimum (0) 16
+ # 0x25, 0x01, // Logical Maximum (1) 18
+
+each button can send values from 0 up to including 1
+(i.e. they are binary buttons) ::
+
+ # 0x75, 0x01, // Report Size (1) 20
+
+each button is sent as exactly one bit ::
+
+ # 0x95, 0x03, // Report Count (3) 22
+
+and there are three of those bits (matching the three buttons) ::
+
+ # 0x81, 0x02, // Input (Data,Var,Abs) 24
+
+it's actual Data (not constant padding), they represent
+a single variable (Var) and their values are Absolute (not relative);
+See HID spec Sec. 6.2.2.5 "Input, Output, and Feature Items" ::
+
+ # 0x75, 0x05, // Report Size (5) 26
+
+five additional padding bits, needed to reach a byte ::
+
+ # 0x95, 0x01, // Report Count (1) 28
+
+those five bits are repeated only once ::
+
+ # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
+
+and take Constant (Cnst) values i.e. they can be ignored. ::
+
+ # 0x05, 0x01, // Usage Page (Generic Desktop) 32
+ # 0x09, 0x30, // Usage (X) 34
+ # 0x09, 0x31, // Usage (Y) 36
+ # 0x09, 0x38, // Usage (Wheel) 38
+
+The mouse has also two physical positions (Usage (X), Usage (Y))
+and a wheel (Usage (Wheel)) ::
+
+ # 0x15, 0x81, // Logical Minimum (-127) 40
+ # 0x25, 0x7f, // Logical Maximum (127) 42
+
+each of them can send values ranging from -127 up to including 127 ::
+
+ # 0x75, 0x08, // Report Size (8) 44
+
+which is represented by eight bits ::
+
+ # 0x95, 0x03, // Report Count (3) 46
+
+and there are three of those eight bits, matching X, Y and Wheel. ::
+
+ # 0x81, 0x06, // Input (Data,Var,Rel) 48
+
+This time the data values are Relative (Rel), i.e. they represent
+the change from the previously sent report (event) ::
+
+ # 0xc0, // End Collection 50
+ # 0xc0, // End Collection 51
+ #
+ R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0
+ N: device 0:0
+ I: 3 0001 0001
+
+
+This Report Descriptor tells us that the mouse input will be
+transmitted using four bytes: the first one for the buttons (three
+bits used, five for padding), the last three for the mouse X, Y and
+wheel changes, respectively.
+
+Indeed, for any event, the mouse will send a *report* of four bytes.
+We can check the values sent by resorting e.g. to the `hid-recorder`
+tool, from `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_:
+The sequence of bytes sent by clicking and releasing button 1, then button 2, then button 3 is::
+
+ $ sudo ./hid-recorder /dev/hidraw1
+
+ ....
+ output of hid-decode
+ ....
+
+ # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000000.000000 4 01 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000000.183949 4 00 00 00 00
+ # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000001.959698 4 02 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000002.103899 4 00 00 00 00
+ # Button: 0 0 1 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000004.855799 4 04 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000005.103864 4 00 00 00 00
+
+This example shows that when button 2 is clicked,
+the bytes ``02 00 00 00`` are sent, and the immediately subsequent
+event (``00 00 00 00``) is the release of button 2 (no buttons are
+pressed, remember that the data values are *absolute*).
+
+If instead one clicks and holds button 1, then clicks and holds button
+2, releases button 1, and finally releases button 2, the reports are::
+
+ # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000044.175830 4 01 00 00 00
+ # Button: 1 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000045.975997 4 03 00 00 00
+ # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000047.407930 4 02 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000049.199919 4 00 00 00 00
+
+where with ``03 00 00 00`` both buttons are pressed, and with the
+subsequent ``02 00 00 00`` button 1 is released while button 2 is still
+active.
+
+Output, Input and Feature Reports
+---------------------------------
+
+HID devices can have Input Reports, like in the mouse example, Output
+Reports, and Feature Reports. "Output" means that the information is
+sent to the device. For example, a joystick with force feedback will
+have some output; the led of a keyboard would need an output as well.
+"Input" means that data come from the device.
+
+"Feature"s are not meant to be consumed by the end user and define
+configuration options for the device. They can be queried from the host;
+when declared as *Volatile* they should be changed by the host.
+
+
+Collections, Report IDs and Evdev events
+========================================
+
+A single device can logically group data into different independent
+sets, called a *Collection*. Collections can be nested and there are
+different types of collections (see the HID spec 6.2.2.6
+"Collection, End Collection Items" for details).
+
+Different reports are identified by means of different *Report ID*
+fields, i.e. a number identifying the structure of the immediately
+following report.
+Whenever a Report ID is needed it is transmitted as the first byte of
+any report. A device with only one supported HID report (like the mouse
+example above) may omit the report ID.
+
+Consider the following HID report descriptor::
+
+ 05 01 09 02 A1 01 85 01 05 09 19 01 29 05 15 00
+ 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01
+ 09 30 09 31 16 00 F8 26 FF 07 75 0C 95 02 81 06
+ 09 38 15 80 25 7F 75 08 95 01 81 06 05 0C 0A 38
+ 02 15 80 25 7F 75 08 95 01 81 06 C0 05 01 09 02
+ A1 01 85 02 05 09 19 01 29 05 15 00 25 01 95 05
+ 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31
+ 16 00 F8 26 FF 07 75 0C 95 02 81 06 09 38 15 80
+ 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 80 25
+ 7F 75 08 95 01 81 06 C0 05 01 09 07 A1 01 85 05
+ 05 07 15 00 25 01 09 29 09 3E 09 4B 09 4E 09 E3
+ 09 E8 09 E8 09 E8 75 01 95 08 81 02 95 00 81 01
+ C0 05 0C 09 01 A1 01 85 06 15 00 25 01 75 01 95
+ 01 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
+ 06 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
+ 06 C0 05 0C 09 01 A1 01 85 03 09 05 15 00 26 FF
+ 00 75 08 95 02 B1 02 C0
+
+After parsing it (try to parse it on your own using the suggested
+tools!) one can see that the device presents two ``Mouse`` Application
+Collections (with reports identified by Reports IDs 1 and 2,
+respectively), a ``Keypad`` Application Collection (whose report is
+identified by the Report ID 5) and two ``Consumer Controls`` Application
+Collections, (with Report IDs 6 and 3, respectively). Note, however,
+that a device can have different Report IDs for the same Application
+Collection.
+
+The data sent will begin with the Report ID byte, and will be followed
+by the corresponding information. For example, the data transmitted for
+the last consumer control::
+
+ 0x05, 0x0C, // Usage Page (Consumer)
+ 0x09, 0x01, // Usage (Consumer Control)
+ 0xA1, 0x01, // Collection (Application)
+ 0x85, 0x03, // Report ID (3)
+ 0x09, 0x05, // Usage (Headphone)
+ 0x15, 0x00, // Logical Minimum (0)
+ 0x26, 0xFF, 0x00, // Logical Maximum (255)
+ 0x75, 0x08, // Report Size (8)
+ 0x95, 0x02, // Report Count (2)
+ 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
+ 0xC0, // End Collection
+
+will be of three bytes: the first for the Report ID (3), the next two
+for the headphone, with two (``Report Count (2)``) bytes
+(``Report Size (8)``), each ranging from 0 (``Logical Minimum (0)``)
+to 255 (``Logical Maximum (255)``).
+
+All the Input data sent by the device should be translated into
+corresponding Evdev events, so that the remaining part of the stack can
+know what is going on, e.g. the bit for the first button translates into
+the ``EV_KEY/BTN_LEFT`` evdev event and relative X movement translates
+into the ``EV_REL/REL_X`` evdev event".
+
+Events
+======
+
+In Linux, one ``/dev/input/event*`` is created for each ``Application
+Collection``. Going back to the mouse example, and repeating the
+sequence where one clicks and holds button 1, then clicks and holds
+button 2, releases button 1, and finally releases button 2, one gets::
+
+ $ sudo libinput record /dev/input/event1
+ # libinput record
+ version: 1
+ ndevices: 1
+ libinput:
+ version: "1.23.0"
+ git: "unknown"
+ system:
+ os: "opensuse-tumbleweed:20230619"
+ kernel: "6.3.7-1-default"
+ dmi: "dmi:bvnHP:bvrU77Ver.01.05.00:bd03/24/2022:br5.0:efr20.29:svnHP:pnHPEliteBook64514inchG9NotebookPC:pvr:rvnHP:rn89D2:rvrKBCVersion14.1D.00:cvnHP:ct10:cvr:sku5Y3J1EA#ABZ:"
+ devices:
+ - node: /dev/input/event1
+ evdev:
+ # Name: PixArt HP USB Optical Mouse
+ # ID: bus 0x3 vendor 0x3f0 product 0x94a version 0x111
+ # Supported Events:
+ # Event type 0 (EV_SYN)
+ # Event type 1 (EV_KEY)
+ # Event code 272 (BTN_LEFT)
+ # Event code 273 (BTN_RIGHT)
+ # Event code 274 (BTN_MIDDLE)
+ # Event type 2 (EV_REL)
+ # Event code 0 (REL_X)
+ # Event code 1 (REL_Y)
+ # Event code 8 (REL_WHEEL)
+ # Event code 11 (REL_WHEEL_HI_RES)
+ # Event type 4 (EV_MSC)
+ # Event code 4 (MSC_SCAN)
+ # Properties:
+ name: "PixArt HP USB Optical Mouse"
+ id: [3, 1008, 2378, 273]
+ codes:
+ 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN
+ 1: [272, 273, 274] # EV_KEY
+ 2: [0, 1, 8, 11] # EV_REL
+ 4: [4] # EV_MSC
+ properties: []
+ hid: [
+ 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01, 0x09, 0x01, 0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
+ 0x15, 0x00, 0x25, 0x01, 0x95, 0x08, 0x75, 0x01, 0x81, 0x02, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31,
+ 0x09, 0x38, 0x15, 0x81, 0x25, 0x7f, 0x75, 0x08, 0x95, 0x03, 0x81, 0x06, 0xc0, 0xc0
+ ]
+ udev:
+ properties:
+ - ID_INPUT=1
+ - ID_INPUT_MOUSE=1
+ - LIBINPUT_DEVICE_GROUP=3/3f0/94a:usb-0000:05:00.3-2
+ quirks:
+ events:
+ # Current time is 12:31:56
+ - evdev:
+ - [ 0, 0, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 0, 0, 1, 272, 1] # EV_KEY / BTN_LEFT 1
+ - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
+ - evdev:
+ - [ 1, 207892, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 1, 207892, 1, 273, 1] # EV_KEY / BTN_RIGHT 1
+ - [ 1, 207892, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1207ms
+ - evdev:
+ - [ 2, 367823, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 2, 367823, 1, 272, 0] # EV_KEY / BTN_LEFT 0
+ - [ 2, 367823, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1160ms
+ # Current time is 12:32:00
+ - evdev:
+ - [ 3, 247617, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 3, 247617, 1, 273, 0] # EV_KEY / BTN_RIGHT 0
+ - [ 3, 247617, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +880ms
+
+Note: if ``libinput record`` is not available on your system try using
+``evemu-record``.
+
+When something does not work
+============================
+
+There can be a number of reasons why a device does not behave
+correctly. For example
+
+* The HID report descriptor provided by the HID device may be wrong
+ because e.g.
+
+ * it does not follow the standard, so that the kernel
+ will not able to make sense of the HID report descriptor;
+ * the HID report descriptor *does not match* what is actually
+ sent by the device (this can be verified by reading the raw HID
+ data);
+* the HID report descriptor may need some "quirks" (see later on).
+
+As a consequence, a ``/dev/input/event*`` may not be created
+for each Application Collection, and/or the events
+there may not match what you would expect.
+
+
+Quirks
+------
+
+There are some known peculiarities of HID devices that the kernel
+knows how to fix - these are called the HID quirks and a list of those
+is available in `include/linux/hid.h`.
+
+Should this be the case, it should be enough to add the required quirk
+in the kernel, for the HID device at hand. This can be done in the file
+`drivers/hid/hid-quirks.c`. How to do it should be relatively
+straightforward after looking into the file.
+
+The list of currently defined quirks, from `include/linux/hid.h`, is
+
+.. kernel-doc:: include/linux/hid.h
+ :doc: HID quirks
+
+Quirks for USB devices can be specified while loading the usbhid module,
+see ``modinfo usbhid``, although the proper fix should go into
+hid-quirks.c and **be submitted upstream**.
+See Documentation/process/submitting-patches.rst for guidelines on how
+to submit a patch. Quirks for other busses need to go into hid-quirks.c.
+
+Fixing HID report descriptors
+-----------------------------
+
+Should you need to patch HID report descriptors the easiest way is to
+resort to eBPF, as described in Documentation/hid/hid-bpf.rst.
+
+Basically, you can change any byte of the original HID report
+descriptor. The examples in samples/hid should be a good starting point
+for your code, see e.g. `samples/hid/hid_mouse.bpf.c`::
+
+ SEC("fmod_ret/hid_bpf_rdesc_fixup")
+ int BPF_PROG(hid_rdesc_fixup, struct hid_bpf_ctx *hctx)
+ {
+ ....
+ data[39] = 0x31;
+ data[41] = 0x30;
+ return 0;
+ }
+
+Of course this can be also done within the kernel source code, see e.g.
+`drivers/hid/hid-aureal.c` or `drivers/hid/hid-samsung.c` for a slightly
+more complex file.
+
+Check Documentation/hid/hidreport-parsing.rst if you need any help
+navigating the HID manuals and understanding the exact meaning of
+the HID report descriptor hex numbers.
+
+Whatever solution you come up with, please remember to **submit the
+fix to the HID maintainers**, so that it can be directly integrated in
+the kernel and that particular HID device will start working for
+everyone else. See Documentation/process/submitting-patches.rst for
+guidelines on how to do this.
+
+
+Modifying the transmitted data on the fly
+-----------------------------------------
+
+Using eBPF it is also possible to modify the data exchanged with the
+device. See again the examples in `samples/hid`.
+
+Again, **please post your fix**, so that it can be integrated in the
+kernel!
+
+Writing a specialized driver
+----------------------------
+
+This should really be your last resort.
+
+
+.. rubric:: Footnotes
+
+.. [#hidraw] read hidraw: see Documentation/hid/hidraw.rst and
+ file `samples/hidraw/hid-example.c` for an example.
+ The output of ``hid-example`` would be, for the same mouse::
+
+ $ sudo ./hid-example
+ Report Descriptor Size: 52
+ Report Descriptor:
+ 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 25 1 75 1 95 3 81 2 75 5 95 1 81 1 5 1 9 30 9 31 9 38 15 81 25 7f 75 8 95 3 81 6 c0 c0
+
+ Raw Name: PixArt USB Optical Mouse
+ Raw Phys: usb-0000:05:00.4-2.3/input0
+ Raw Info:
+ bustype: 3 (USB)
+ vendor: 0x093a
+ product: 0x2510
+ ...
diff --git a/Documentation/hid/hidreport-parsing.rst b/Documentation/hid/hidreport-parsing.rst
new file mode 100644
index 0000000..1d3c17f
--- /dev/null
+++ b/Documentation/hid/hidreport-parsing.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Manual parsing of HID report descriptors
+========================================
+
+Consider again the mouse HID report descriptor
+introduced in Documentation/hid/hidintro.rst::
+
+ $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
+ 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
+ 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
+ 00000030 81 06 c0 c0 |....|
+ 00000034
+
+and try to parse it by hand.
+
+Start with the first number, 0x05: it carries 2 bits for the
+length of the item, 2 bits for the type of the item and 4 bits for the
+function::
+
+ +----------+
+ | 00000101 |
+ +----------+
+ ^^
+ ---- Length of data (see HID spec 6.2.2.2)
+ ^^
+ ------ Type of the item (see HID spec 6.2.2.2, then jump to 6.2.2.7)
+ ^^^^
+ --------- Function of the item (see HID spec 6.2.2.7, then HUT Sec 3)
+
+In our case, the length is 1 byte, the type is ``Global`` and the
+function is ``Usage Page``, thus for parsing the value 0x01 in the second byte
+we need to refer to HUT Sec 3.
+
+The second number is the actual data, and its meaning can be found in
+the HUT. We have a ``Usage Page``, thus we need to refer to HUT
+Sec. 3, "Usage Pages"; from there, one sees that ``0x01`` stands for
+``Generic Desktop Page``.
+
+Moving now to the second two bytes, and following the same scheme,
+``0x09`` (i.e. ``00001001``) will be followed by one byte (``01``)
+and is a ``Local`` item (``10``). Thus, the meaning of the remaining four bits
+(``0000``) is given in the HID spec Sec. 6.2.2.8 "Local Items", so that
+we have a ``Usage``. From HUT, Sec. 4, "Generic Desktop Page", we see that
+0x02 stands for ``Mouse``.
+
+The following numbers can be parsed in the same way.
diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst
index b2028f3..af02cf7 100644
--- a/Documentation/hid/index.rst
+++ b/Documentation/hid/index.rst
@@ -7,6 +7,7 @@
.. toctree::
:maxdepth: 1
+ hidintro
hiddev
hidraw
hid-sensor
diff --git a/Documentation/hwmon/hs3001.rst b/Documentation/hwmon/hs3001.rst
new file mode 100644
index 0000000..9f59dfc
--- /dev/null
+++ b/Documentation/hwmon/hs3001.rst
@@ -0,0 +1,37 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver HS3001
+====================
+
+Supported chips:
+
+ * Renesas HS3001, HS3002, HS3003, HS3004
+
+ Prefix: 'hs3001'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.renesas.com/us/en/document/dst/hs300x-datasheet?r=417401
+
+Author:
+
+ - Andre Werner <andre.werner@systec-electronic.com>
+
+Description
+-----------
+
+This driver implements support for the Renesas HS3001 chips, a humidity
+and temperature family. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. In the sysfs interface, all values are
+scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+
+The device communicates with the I2C protocol. Sensors have the I2C
+address 0x44 by default.
+
+sysfs-Interface
+---------------
+
+=================== =================
+temp1_input: temperature input
+humidity1_input: humidity input
+=================== =================
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 042e1cf..88dadea 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -78,6 +78,7 @@
gxp-fan-ctrl
hih6130
hp-wmi-sensors
+ hs3001
ibmaem
ibm-cffps
ibmpowernv
@@ -195,7 +196,6 @@
shtc1
sis5595
sl28cpld
- smm665
smpro-hwmon
smsc47b397
smsc47m192
diff --git a/Documentation/hwmon/nct6775.rst b/Documentation/hwmon/nct6775.rst
index 5ba8276..9d7a10d 100644
--- a/Documentation/hwmon/nct6775.rst
+++ b/Documentation/hwmon/nct6775.rst
@@ -80,7 +80,13 @@
Datasheet: Available from Nuvoton upon request
+ * Nuvoton NCT6796D-S/NCT6799D-R
+ Prefix: 'nct6799'
+
+ Addresses scanned: ISA address retrieved from Super I/O registers
+
+ Datasheet: Available from Nuvoton upon request
Authors:
@@ -277,4 +283,7 @@
temperatures, and in some cases the reported temperature declines if the actual
temperature increases (similar to the raw PECI temperature value - see PECI
specification for details). CPUTIN should therefore be ignored on ASUS
-boards. The CPU temperature on ASUS boards is reported from PECI 0.
+boards. The CPU temperature on ASUS boards is reported from PECI 0 or TSI 0.
+
+NCT6796D-S and NCT6799D-R chips are very similar and their chip_id indicates
+they are different versions. This driver treats them the same way.
diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst
index cff93ad..1eaf2b0 100644
--- a/Documentation/hwmon/pmbus-core.rst
+++ b/Documentation/hwmon/pmbus-core.rst
@@ -345,7 +345,7 @@
Some PMBus chips don't respond with valid data when reading the CAPABILITY
register. For such chips, this flag should be set so that the PMBus core
-driver doesn't use CAPABILITY to determine it's behavior.
+driver doesn't use CAPABILITY to determine its behavior.
PMBUS_READ_STATUS_AFTER_FAILED_CHECK
diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst
index 7ecfec6..eb1569b 100644
--- a/Documentation/hwmon/pmbus.rst
+++ b/Documentation/hwmon/pmbus.rst
@@ -163,7 +163,7 @@
.driver = {
.name = "ds1200",
},
- .probe_new = ds1200_probe,
+ .probe = ds1200_probe,
.id_table = ds1200_id,
};
diff --git a/Documentation/hwmon/smm665.rst b/Documentation/hwmon/smm665.rst
deleted file mode 100644
index 481e69d..0000000
--- a/Documentation/hwmon/smm665.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-Kernel driver smm665
-====================
-
-Supported chips:
-
- * Summit Microelectronics SMM465
-
- Prefix: 'smm465'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM465/SMM465DS.pdf
-
- * Summit Microelectronics SMM665, SMM665B
-
- Prefix: 'smm665'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM665/SMM665B_2089_20.pdf
-
- * Summit Microelectronics SMM665C
-
- Prefix: 'smm665c'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM665C/SMM665C_2125.pdf
-
- * Summit Microelectronics SMM764
-
- Prefix: 'smm764'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM764/SMM764_2098.pdf
-
- * Summit Microelectronics SMM766, SMM766B
-
- Prefix: 'smm766'
-
- Addresses scanned: -
-
- Datasheets:
-
- http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
-
- http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
-
-Author: Guenter Roeck <linux@roeck-us.net>
-
-
-Module Parameters
------------------
-
-* vref: int
- Default: 1250 (mV)
-
- Reference voltage on VREF_ADC pin in mV. It should not be necessary to set
- this parameter unless a non-default reference voltage is used.
-
-
-Description
------------
-
-[From datasheet] The SMM665 is an Active DC Output power supply Controller
-that monitors, margins and cascade sequences power. The part monitors six
-power supply channels as well as VDD, 12V input, two general-purpose analog
-inputs and an internal temperature sensor using a 10-bit ADC.
-
-Each monitored channel has its own high and low limits, plus a critical
-limit.
-
-Support for SMM465, SMM764, and SMM766 has been implemented but is untested.
-
-
-Usage Notes
------------
-
-This driver does not probe for devices, since there is no register which
-can be safely used to identify the chip. You will have to instantiate
-the devices explicitly. When instantiating the device, you have to specify
-its configuration register address.
-
-Example: the following will load the driver for an SMM665 at address 0x57
-on I2C bus #1::
-
- $ modprobe smm665
- $ echo smm665 0x57 > /sys/bus/i2c/devices/i2c-1/new_device
-
-
-Sysfs entries
--------------
-
-This driver uses the values in the datasheet to convert ADC register values
-into the values specified in the sysfs-interface document. All attributes are
-read only.
-
-Min, max, lcrit, and crit values are used by the chip to trigger external signals
-and/or other activity. Triggered signals can include HEALTHY, RST, Power Off,
-or Fault depending on the chip configuration. The driver reports values as lcrit
-or crit if exceeding the limits triggers RST, Power Off, or Fault, and as min or
-max otherwise. For details please see the SMM665 datasheet.
-
-For SMM465 and SMM764, values for Channel E and F are reported but undefined.
-
-======================= =======================================================
-in1_input 12V input voltage (mV)
-in2_input 3.3V (VDD) input voltage (mV)
-in3_input Channel A voltage (mV)
-in4_input Channel B voltage (mV)
-in5_input Channel C voltage (mV)
-in6_input Channel D voltage (mV)
-in7_input Channel E voltage (mV)
-in8_input Channel F voltage (mV)
-in9_input AIN1 voltage (mV)
-in10_input AIN2 voltage (mV)
-
-in1_min 12v input minimum voltage (mV)
-in2_min 3.3V (VDD) input minimum voltage (mV)
-in3_min Channel A minimum voltage (mV)
-in4_min Channel B minimum voltage (mV)
-in5_min Channel C minimum voltage (mV)
-in6_min Channel D minimum voltage (mV)
-in7_min Channel E minimum voltage (mV)
-in8_min Channel F minimum voltage (mV)
-in9_min AIN1 minimum voltage (mV)
-in10_min AIN2 minimum voltage (mV)
-
-in1_max 12v input maximum voltage (mV)
-in2_max 3.3V (VDD) input maximum voltage (mV)
-in3_max Channel A maximum voltage (mV)
-in4_max Channel B maximum voltage (mV)
-in5_max Channel C maximum voltage (mV)
-in6_max Channel D maximum voltage (mV)
-in7_max Channel E maximum voltage (mV)
-in8_max Channel F maximum voltage (mV)
-in9_max AIN1 maximum voltage (mV)
-in10_max AIN2 maximum voltage (mV)
-
-in1_lcrit 12v input critical minimum voltage (mV)
-in2_lcrit 3.3V (VDD) input critical minimum voltage (mV)
-in3_lcrit Channel A critical minimum voltage (mV)
-in4_lcrit Channel B critical minimum voltage (mV)
-in5_lcrit Channel C critical minimum voltage (mV)
-in6_lcrit Channel D critical minimum voltage (mV)
-in7_lcrit Channel E critical minimum voltage (mV)
-in8_lcrit Channel F critical minimum voltage (mV)
-in9_lcrit AIN1 critical minimum voltage (mV)
-in10_lcrit AIN2 critical minimum voltage (mV)
-
-in1_crit 12v input critical maximum voltage (mV)
-in2_crit 3.3V (VDD) input critical maximum voltage (mV)
-in3_crit Channel A critical maximum voltage (mV)
-in4_crit Channel B critical maximum voltage (mV)
-in5_crit Channel C critical maximum voltage (mV)
-in6_crit Channel D critical maximum voltage (mV)
-in7_crit Channel E critical maximum voltage (mV)
-in8_crit Channel F critical maximum voltage (mV)
-in9_crit AIN1 critical maximum voltage (mV)
-in10_crit AIN2 critical maximum voltage (mV)
-
-in1_crit_alarm 12v input critical alarm
-in2_crit_alarm 3.3V (VDD) input critical alarm
-in3_crit_alarm Channel A critical alarm
-in4_crit_alarm Channel B critical alarm
-in5_crit_alarm Channel C critical alarm
-in6_crit_alarm Channel D critical alarm
-in7_crit_alarm Channel E critical alarm
-in8_crit_alarm Channel F critical alarm
-in9_crit_alarm AIN1 critical alarm
-in10_crit_alarm AIN2 critical alarm
-
-temp1_input Chip temperature
-temp1_min Minimum chip temperature
-temp1_max Maximum chip temperature
-temp1_crit Critical chip temperature
-temp1_crit_alarm Temperature critical alarm
-======================= =======================================================
diff --git a/Documentation/i2c/i2c-address-translators.rst b/Documentation/i2c/i2c-address-translators.rst
new file mode 100644
index 0000000..b22ce9f4
--- /dev/null
+++ b/Documentation/i2c/i2c-address-translators.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+I2C Address Translators
+=======================
+
+Author: Luca Ceresoli <luca@lucaceresoli.net>
+Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+Description
+-----------
+
+An I2C Address Translator (ATR) is a device with an I2C slave parent
+("upstream") port and N I2C master child ("downstream") ports, and
+forwards transactions from upstream to the appropriate downstream port
+with a modified slave address. The address used on the parent bus is
+called the "alias" and is (potentially) different from the physical
+slave address of the child bus. Address translation is done by the
+hardware.
+
+An ATR looks similar to an i2c-mux except:
+ - the address on the parent and child busses can be different
+ - there is normally no need to select the child port; the alias used on the
+ parent bus implies it
+
+The ATR functionality can be provided by a chip with many other features.
+The kernel i2c-atr provides a helper to implement an ATR within a driver.
+
+The ATR creates a new I2C "child" adapter on each child bus. Adding
+devices on the child bus ends up in invoking the driver code to select
+an available alias. Maintaining an appropriate pool of available aliases
+and picking one for each new device is up to the driver implementer. The
+ATR maintains a table of currently assigned alias and uses it to modify
+all I2C transactions directed to devices on the child buses.
+
+A typical example follows.
+
+Topology::
+
+ Slave X @ 0x10
+ .-----. |
+ .-----. | |---+---- B
+ | CPU |--A--| ATR |
+ `-----' | |---+---- C
+ `-----' |
+ Slave Y @ 0x10
+
+Alias table:
+
+A, B and C are three physical I2C busses, electrically independent from
+each other. The ATR receives the transactions initiated on bus A and
+propagates them on bus B or bus C or none depending on the device address
+in the transaction and based on the alias table.
+
+Alias table:
+
+.. table::
+
+ =============== =====
+ Client Alias
+ =============== =====
+ X (bus B, 0x10) 0x20
+ Y (bus C, 0x10) 0x30
+ =============== =====
+
+Transaction:
+
+ - Slave X driver requests a transaction (on adapter B), slave address 0x10
+ - ATR driver finds slave X is on bus B and has alias 0x20, rewrites
+ messages with address 0x20, forwards to adapter A
+ - Physical I2C transaction on bus A, slave address 0x20
+ - ATR chip detects transaction on address 0x20, finds it in table,
+ propagates transaction on bus B with address translated to 0x10,
+ keeps clock streched on bus A waiting for reply
+ - Slave X chip (on bus B) detects transaction at its own physical
+ address 0x10 and replies normally
+ - ATR chip stops clock stretching and forwards reply on bus A,
+ with address translated back to 0x20
+ - ATR driver receives the reply, rewrites messages with address 0x10
+ as they were initially
+ - Slave X driver gets back the msgs[], with reply and address 0x10
+
+Usage:
+
+ 1. In the driver (typically in the probe function) add an ATR by
+ calling i2c_atr_new() passing attach/detach callbacks
+ 2. When the attach callback is called pick an appropriate alias,
+ configure it in the chip and return the chosen alias in the
+ alias_id parameter
+ 3. When the detach callback is called, deconfigure the alias from
+ the chip and put the alias back in the pool for later usage
+
+I2C ATR functions and data structures
+-------------------------------------
+
+.. kernel-doc:: include/linux/i2c-atr.h
diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst
index 6270f1f..2b213d4 100644
--- a/Documentation/i2c/index.rst
+++ b/Documentation/i2c/index.rst
@@ -18,6 +18,7 @@
i2c-topology
muxes/i2c-mux-gpio
i2c-sysfs
+ i2c-address-translators
Writing device drivers
======================
diff --git a/Documentation/i2c/writing-clients.rst b/Documentation/i2c/writing-clients.rst
index b7d3ae7..41ddc10 100644
--- a/Documentation/i2c/writing-clients.rst
+++ b/Documentation/i2c/writing-clients.rst
@@ -46,7 +46,7 @@
},
.id_table = foo_idtable,
- .probe_new = foo_probe,
+ .probe = foo_probe,
.remove = foo_remove,
/* if device autodetection is needed: */
.class = I2C_CLASS_SOMETHING,
diff --git a/Documentation/input/devices/iforce-protocol.rst b/Documentation/input/devices/iforce-protocol.rst
index 8634bea..52c1e0d 100644
--- a/Documentation/input/devices/iforce-protocol.rst
+++ b/Documentation/input/devices/iforce-protocol.rst
@@ -49,7 +49,7 @@
== ====
The 2B, LEN and CS fields have disappeared, probably because USB handles
-frames and data corruption is handled or unsignificant.
+frames and data corruption is handled or insignificant.
First, I describe effects that are sent by the device to the computer
diff --git a/Documentation/input/devices/pxrc.rst b/Documentation/input/devices/pxrc.rst
index ca11f64..5a86df4 100644
--- a/Documentation/input/devices/pxrc.rst
+++ b/Documentation/input/devices/pxrc.rst
@@ -5,7 +5,7 @@
:Author: Marcus Folkesson <marcus.folkesson@gmail.com>
This driver let you use your own RC controller plugged into the
-adapter that comes with PhoenixRC [1]_ or other compatible adapters.
+adapter that comes with PhoenixRC or other compatible adapters.
The adapter supports 7 analog channels and 1 digital input switch.
@@ -41,7 +41,7 @@
==============
To test this driver's functionality you may use `input-event` which is part of
-the `input layer utilities` suite [2]_.
+the `input layer utilities` suite [1]_.
For example::
@@ -53,5 +53,4 @@
References
==========
-.. [1] http://www.phoenix-sim.com/
-.. [2] https://www.kraxel.org/cgit/input/
+.. [1] https://www.kraxel.org/cgit/input/
diff --git a/Documentation/input/multi-touch-protocol.rst b/Documentation/input/multi-touch-protocol.rst
index 1085cbe..47d3dcb 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -383,7 +383,7 @@
---------------
The process of finger tracking, i.e., to assign a unique trackingID to each
-initiated contact on the surface, is a Euclidian Bipartite Matching
+initiated contact on the surface, is a Euclidean Bipartite Matching
problem. At each event synchronization, the set of actual contacts is
matched to the set of contacts from the previous synchronization. A full
implementation can be found in [#f3]_.
diff --git a/Documentation/kbuild/kconfig.rst b/Documentation/kbuild/kconfig.rst
index 5967c79..c946eb4 100644
--- a/Documentation/kbuild/kconfig.rst
+++ b/Documentation/kbuild/kconfig.rst
@@ -10,6 +10,8 @@
programs also have embedded help text. Be sure to check that for
navigation, search, and other general help text.
+The gconfig ('gconf') program has limited help text.
+
General
-------
@@ -54,6 +56,15 @@
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
break symlinks when .config is a symlink to somewhere else.
+KCONFIG_WARN_UNKNOWN_SYMBOLS
+----------------------------
+This environment variable makes Kconfig warn about all unrecognized
+symbols in the config input.
+
+KCONFIG_WERROR
+--------------
+If set, Kconfig treats warnings as errors.
+
`CONFIG_`
---------
If you set `CONFIG_` in the environment, Kconfig will prefix all symbols
@@ -210,6 +221,10 @@
first (and in alphabetical order), then come all other symbols,
sorted in alphabetical order.
+ In this menu, pressing the key in the (#) prefix will jump
+ directly to that location. You will be returned to the current
+ search results after exiting this new menu.
+
----------------------------------------------------------------------
User interface options for 'menuconfig'
@@ -262,6 +277,10 @@
F8 (SymSearch) searches the configuration symbols for the
given string or regular expression (regex).
+ In the SymSearch, pressing the key in the (#) prefix will
+ jump directly to that location. You will be returned to the
+ current search results after exiting this new menu.
+
NCONFIG_MODE
------------
This mode shows all sub-menus in one large tree.
diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index c3851fe..b1d97fa 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -25,50 +25,38 @@
that supports C and the GNU C extensions required by the kernel, and is
pronounced "klang," not "see-lang."
-Clang
------
+Building with LLVM
+------------------
-The compiler used can be swapped out via ``CC=`` command line argument to ``make``.
-``CC=`` should be set when selecting a config and during a build. ::
+Invoke ``make`` via::
- make CC=clang defconfig
+ make LLVM=1
- make CC=clang
+to compile for the host target. For cross compiling::
-Cross Compiling
----------------
+ make LLVM=1 ARCH=arm64
-A single Clang compiler binary will typically contain all supported backends,
-which can help simplify cross compiling. ::
+The LLVM= argument
+------------------
- make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu-
-
-``CROSS_COMPILE`` is not used to prefix the Clang compiler binary, instead
-``CROSS_COMPILE`` is used to set a command line flag: ``--target=<triple>``. For
-example: ::
-
- clang --target=aarch64-linux-gnu foo.c
-
-LLVM Utilities
---------------
-
-LLVM has substitutes for GNU binutils utilities. They can be enabled individually.
-The full list of supported make variables::
+LLVM has substitutes for GNU binutils utilities. They can be enabled
+individually. The full list of supported make variables::
make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
-To simplify the above command, Kbuild supports the ``LLVM`` variable::
-
- make LLVM=1
+``LLVM=1`` expands to the above.
If your LLVM tools are not available in your PATH, you can supply their
location using the LLVM variable with a trailing slash::
make LLVM=/path/to/llvm/
-which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc.
+which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. The
+following may also be used::
+
+ PATH=/path/to/llvm:$PATH make LLVM=1
If your LLVM tools have a version suffix and you want to test with that
explicit version rather than the unsuffixed executables like ``LLVM=1``, you
@@ -78,31 +66,72 @@
which will use ``clang-14``, ``ld.lld-14``, etc.
+To support combinations of out of tree paths with version suffixes, we
+recommend::
+
+ PATH=/path/to/llvm/:$PATH make LLVM=-14
+
``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like
-``LLVM=1``. If you only wish to use certain LLVM utilities, use their respective
-make variables.
+``LLVM=1``. If you only wish to use certain LLVM utilities, use their
+respective make variables.
-The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to
-disable it.
+The same value used for ``LLVM=`` should be set for each invocation of ``make``
+if configuring and building via distinct commands. ``LLVM=`` should also be set
+as an environment variable when running scripts that will eventually run
+``make``.
-Omitting CROSS_COMPILE
+Cross Compiling
+---------------
+
+A single Clang compiler binary (and corresponding LLVM utilities) will
+typically contain all supported back ends, which can help simplify cross
+compiling especially when ``LLVM=1`` is used. If you use only LLVM tools,
+``CROSS_COMPILE`` or target-triple-prefixes become unnecessary. Example::
+
+ make LLVM=1 ARCH=arm64
+
+As an example of mixing LLVM and GNU utilities, for a target like ``ARCH=s390``
+which does not yet have ``ld.lld`` or ``llvm-objcopy`` support, you could
+invoke ``make`` via::
+
+ make LLVM=1 ARCH=s390 LD=s390x-linux-gnu-ld.bfd \
+ OBJCOPY=s390x-linux-gnu-objcopy
+
+This example will invoke ``s390x-linux-gnu-ld.bfd`` as the linker and
+``s390x-linux-gnu-objcopy``, so ensure those are reachable in your ``$PATH``.
+
+``CROSS_COMPILE`` is not used to prefix the Clang compiler binary (or
+corresponding LLVM utilities) as is the case for GNU utilities when ``LLVM=1``
+is not set.
+
+The LLVM_IAS= argument
----------------------
-As explained above, ``CROSS_COMPILE`` is used to set ``--target=<triple>``.
+Clang can assemble assembler code. You can pass ``LLVM_IAS=0`` to disable this
+behavior and have Clang invoke the corresponding non-integrated assembler
+instead. Example::
-If ``CROSS_COMPILE`` is not specified, the ``--target=<triple>`` is inferred
-from ``ARCH``.
+ make LLVM=1 LLVM_IAS=0
-That means if you use only LLVM tools, ``CROSS_COMPILE`` becomes unnecessary.
+``CROSS_COMPILE`` is necessary when cross compiling and ``LLVM_IAS=0``
+is used in order to set ``--prefix=`` for the compiler to find the
+corresponding non-integrated assembler (typically, you don't want to use the
+system assembler when targeting another architecture). Example::
-For example, to cross-compile the arm64 kernel::
+ make LLVM=1 ARCH=arm LLVM_IAS=0 CROSS_COMPILE=arm-linux-gnueabi-
- make ARCH=arm64 LLVM=1
-If ``LLVM_IAS=0`` is specified, ``CROSS_COMPILE`` is also used to derive
-``--prefix=<path>`` to search for the GNU assembler and linker. ::
+Ccache
+------
- make ARCH=arm64 LLVM=1 LLVM_IAS=0 CROSS_COMPILE=aarch64-linux-gnu-
+``ccache`` can be used with ``clang`` to improve subsequent builds, (though
+KBUILD_BUILD_TIMESTAMP_ should be set to a deterministic value between builds
+in order to avoid 100% cache misses, see Reproducible_builds_ for more info):
+
+ KBUILD_BUILD_TIMESTAMP='' make LLVM=1 CC="ccache clang"
+
+.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
+.. _Reproducible_builds: reproducible-builds.html#timestamps
Supported Architectures
-----------------------
@@ -135,14 +164,17 @@
* - hexagon
- Maintained
- ``LLVM=1``
+ * - loongarch
+ - Maintained
+ - ``LLVM=1``
* - mips
- Maintained
- ``LLVM=1``
* - powerpc
- Maintained
- - ``CC=clang``
+ - ``LLVM=1``
* - riscv
- - Maintained
+ - Supported
- ``LLVM=1``
* - s390
- Maintained
@@ -171,7 +203,11 @@
Getting LLVM
-------------
-We provide prebuilt stable versions of LLVM on `kernel.org <https://kernel.org/pub/tools/llvm/>`_.
+We provide prebuilt stable versions of LLVM on `kernel.org
+<https://kernel.org/pub/tools/llvm/>`_. These have been optimized with profile
+data for building Linux kernels, which should improve kernel build times
+relative to other distributions of LLVM.
+
Below are links that may be useful for building LLVM from source or procuring
it through a distribution's package manager.
diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst
index d56bb70..8d950f3 100644
--- a/Documentation/livepatch/reliable-stacktrace.rst
+++ b/Documentation/livepatch/reliable-stacktrace.rst
@@ -40,7 +40,7 @@
.. note::
In some cases it is legitimate to omit specific functions from the trace,
but all other functions must be reported. These cases are described in
- futher detail below.
+ further detail below.
Secondly, the reliable stacktrace function must be robust to cases where
the stack or other unwind state is corrupt or otherwise unreliable. The
diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst
index 82f36ca..56b90ee 100644
--- a/Documentation/locking/lockdep-design.rst
+++ b/Documentation/locking/lockdep-design.rst
@@ -29,7 +29,7 @@
A lock-class's behavior is constructed by its instances collectively:
when the first instance of a lock-class is used after bootup the class
gets registered, then all (subsequent) instances will be mapped to the
-class and hence their usages and dependecies will contribute to those of
+class and hence their usages and dependencies will contribute to those of
the class. A lock-class does not go away when a lock instance does, but
it can be removed if the memory space of the lock class (static or
dynamic) is reclaimed, this happens for example when a module is
@@ -105,7 +105,7 @@
+--------------+-------------+--------------+
The character '-' suggests irq is disabled because if otherwise the
-charactor '?' would have been shown instead. Similar deduction can be
+character '?' would have been shown instead. Similar deduction can be
applied for '+' too.
Unused locks (e.g., mutexes) cannot be part of the cause of an error.
diff --git a/Documentation/locking/locktorture.rst b/Documentation/locking/locktorture.rst
index 7f56fc0..3e763f7 100644
--- a/Documentation/locking/locktorture.rst
+++ b/Documentation/locking/locktorture.rst
@@ -113,7 +113,7 @@
without pausing.
shuffle_interval
- The number of seconds to keep the test threads affinitied
+ The number of seconds to keep the test threads affinitized
to a particular subset of the CPUs, defaults to 3 seconds.
Used in conjunction with test_no_idle_hz.
diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst
index 9933faa..80c914f 100644
--- a/Documentation/locking/locktypes.rst
+++ b/Documentation/locking/locktypes.rst
@@ -500,7 +500,7 @@
Some bit spinlocks are replaced with regular spinlock_t for PREEMPT_RT
using conditional (#ifdef'ed) code changes at the usage site. In contrast,
usage-site changes are not needed for the spinlock_t substitution.
-Instead, conditionals in header files and the core locking implemementation
+Instead, conditionals in header files and the core locking implementation
enable the compiler to do the substitution transparently.
diff --git a/Documentation/maintainer/configure-git.rst b/Documentation/maintainer/configure-git.rst
index ec0ddfb..0a36831 100644
--- a/Documentation/maintainer/configure-git.rst
+++ b/Documentation/maintainer/configure-git.rst
@@ -1,35 +1,31 @@
-.. _configuregit:
-
-Configure Git
-=============
+Configuring Git
+===============
This chapter describes maintainer level git configuration.
-Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst
-<pullrequests>` should be signed with the developers public GPG key. Signed
-tags can be created by passing the ``-u`` flag to ``git tag``. However,
-since you would *usually* use the same key for the same project, you can
-set it once with
-::
+Tagged branches used in pull requests (see
+Documentation/maintainer/pull-requests.rst) should be signed with the
+developers public GPG key. Signed tags can be created by passing
+``-u <key-id>`` to ``git tag``. However, since you would *usually* use the same
+key for the project, you can set it in the configuration and use the ``-s``
+flag. To set the default ``key-id`` use::
git config user.signingkey "keyname"
-Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:
-::
+Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand::
[user]
name = Jane Developer
email = jd@domain.org
signingkey = jd@domain.org
-You may need to tell ``git`` to use ``gpg2``
-::
+You may need to tell ``git`` to use ``gpg2``::
[gpg]
program = /path/to/gpg2
-You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc file)
-::
+You may also like to tell ``gpg`` which ``tty`` to use (add to your shell
+rc file)::
export GPG_TTY=$(tty)
@@ -37,20 +33,18 @@
Creating commit links to lore.kernel.org
----------------------------------------
-The web site http://lore.kernel.org is meant as a grand archive of all mail
+The web site https://lore.kernel.org is meant as a grand archive of all mail
list traffic concerning or influencing the kernel development. Storing archives
of patches here is a recommended practice, and when a maintainer applies a
patch to a subsystem tree, it is a good idea to provide a Link: tag with a
reference back to the lore archive so that people that browse the commit
history can find related discussions and rationale behind a certain change.
-The link tag will look like this:
+The link tag will look like this::
Link: https://lore.kernel.org/r/<message-id>
This can be configured to happen automatically any time you issue ``git am``
-by adding the following hook into your git:
-
-.. code-block:: none
+by adding the following hook into your git::
$ git config am.messageid true
$ cat >.git/hooks/applypatch-msg <<'EOF'
diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst
new file mode 100644
index 0000000..f04cc18
--- /dev/null
+++ b/Documentation/maintainer/feature-and-driver-maintainers.rst
@@ -0,0 +1,155 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Feature and driver maintainers
+==============================
+
+The term "maintainer" spans a very wide range of levels of engagement
+from people handling patches and pull requests as almost a full time job
+to people responsible for a small feature or a driver.
+
+Unlike most of the chapter, this section is meant for the latter (more
+populous) group. It provides tips and describes the expectations and
+responsibilities of maintainers of a small(ish) section of the code.
+
+Drivers and alike most often do not have their own mailing lists and
+git trees but instead send and review patches on the list of a larger
+subsystem.
+
+Responsibilities
+================
+
+The amount of maintenance work is usually proportional to the size
+and popularity of the code base. Small features and drivers should
+require relatively small amount of care and feeding. Nonetheless
+when the work does arrive (in form of patches which need review,
+user bug reports etc.) it has to be acted upon promptly.
+Even when a particular driver only sees one patch a month, or a quarter,
+a subsystem could well have a hundred such drivers. Subsystem
+maintainers cannot afford to wait a long time to hear from reviewers.
+
+The exact expectations on the response time will vary by subsystem.
+The patch review SLA the subsystem had set for itself can sometimes
+be found in the subsystem documentation. Failing that as a rule of thumb
+reviewers should try to respond quicker than what is the usual patch
+review delay of the subsystem maintainer. The resulting expectations
+may range from two working days for fast-paced subsystems (e.g. networking)
+to as long as a few weeks in slower moving parts of the kernel.
+
+Mailing list participation
+--------------------------
+
+Linux kernel uses mailing lists as the primary form of communication.
+Maintainers must be subscribed and follow the appropriate subsystem-wide
+mailing list. Either by subscribing to the whole list or using more
+modern, selective setup like
+`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.
+
+Maintainers must know how to communicate on the list (plain text, no invasive
+legal footers, no top posting, etc.)
+
+Reviews
+-------
+
+Maintainers must review *all* patches touching exclusively their drivers,
+no matter how trivial. If the patch is a tree wide change and modifies
+multiple drivers - whether to provide a review is left to the maintainer.
+
+When there are multiple maintainers for a piece of code an ``Acked-by``
+or ``Reviewed-by`` tag (or review comments) from a single maintainer is
+enough to satisfy this requirement.
+
+If the review process or validation for a particular change will take longer
+than the expected review timeline for the subsystem, maintainer should
+reply to the submission indicating that the work is being done, and when
+to expect full results.
+
+Refactoring and core changes
+----------------------------
+
+Occasionally core code needs to be changed to improve the maintainability
+of the kernel as a whole. Maintainers are expected to be present and
+help guide and test changes to their code to fit the new infrastructure.
+
+Bug reports
+-----------
+
+Maintainers must ensure severe problems in their code reported to them
+are resolved in a timely manner: regressions, kernel crashes, kernel warnings,
+compilation errors, lockups, data loss, and other bugs of similar scope.
+
+Maintainers furthermore should respond to reports about other kinds of
+bugs as well, if the report is of reasonable quality or indicates a
+problem that might be severe -- especially if they have *Supported*
+status of the codebase in the MAINTAINERS file.
+
+Selecting the maintainer
+========================
+
+The previous section described the expectations of the maintainer,
+this section provides guidance on selecting one and describes common
+misconceptions.
+
+The author
+----------
+
+Most natural and common choice of a maintainer is the author of the code.
+The author is intimately familiar with the code, so it is the best person
+to take care of it on an ongoing basis.
+
+That said, being a maintainer is an active role. The MAINTAINERS file
+is not a list of credits (in fact a separate CREDITS file exists),
+it is a list of those who will actively help with the code.
+If the author does not have the time, interest or ability to maintain
+the code, a different maintainer must be selected.
+
+Multiple maintainers
+--------------------
+
+Modern best practices dictate that there should be at least two maintainers
+for any piece of code, no matter how trivial. It spreads the burden, helps
+people take vacations and prevents burnout, trains new members of
+the community etc. etc. Even when there is clearly one perfect candidate,
+another maintainer should be found.
+
+Maintainers must be human, therefore, it is not acceptable to add a mailing
+list or a group email as a maintainer. Trust and understanding are the
+foundation of kernel maintenance and one cannot build trust with a mailing
+list. Having a mailing list *in addition* to humans is perfectly fine.
+
+Corporate structures
+--------------------
+
+To an outsider the Linux kernel may resemble a hierarchical organization
+with Linus as the CEO. While the code flows in a hierarchical fashion,
+the corporate template does not apply here. Linux is an anarchy held
+together by (rarely expressed) mutual respect, trust and convenience.
+
+All that is to say that managers almost never make good maintainers.
+The maintainer position more closely matches an on-call rotation
+than a position of power.
+
+The following characteristics of a person selected as a maintainer
+are clear red flags:
+
+ - unknown to the community, never sent an email to the list before
+ - did not author any of the code
+ - (when development is contracted) works for a company which paid
+ for the development rather than the company which did the work
+
+Non compliance
+==============
+
+Subsystem maintainers may remove inactive maintainers from the MAINTAINERS
+file. If the maintainer was a significant author or played an important
+role in the development of the code, they should be moved to the CREDITS file.
+
+Removing an inactive maintainer should not be seen as a punitive action.
+Having an inactive maintainer has a real cost as all developers have
+to remember to include the maintainers in discussions and subsystem
+maintainers spend brain power figuring out how to solicit feedback.
+
+Subsystem maintainers may remove code for lacking maintenance.
+
+Subsystem maintainers may refuse accepting code from companies
+which repeatedly neglected their maintainership duties.
diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
index 3e03283..eeee27f 100644
--- a/Documentation/maintainer/index.rst
+++ b/Documentation/maintainer/index.rst
@@ -9,6 +9,7 @@
.. toctree::
:maxdepth: 2
+ feature-and-driver-maintainers
configure-git
rebasing-and-merging
pull-requests
diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst
index cfd37f3..6b64072 100644
--- a/Documentation/maintainer/maintainer-entry-profile.rst
+++ b/Documentation/maintainer/maintainer-entry-profile.rst
@@ -105,3 +105,4 @@
../driver-api/media/maintainer-entry-profile
../driver-api/vfio-pci-device-specific-driver-acceptance
../nvme/feature-and-quirk-policy
+ ../filesystems/xfs-maintainer-entry-profile
diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst
index e072de6..00b200f 100644
--- a/Documentation/maintainer/pull-requests.rst
+++ b/Documentation/maintainer/pull-requests.rst
@@ -1,5 +1,3 @@
-.. _pullrequests:
-
Creating Pull Requests
======================
@@ -41,7 +39,7 @@
that will create a signed tag called ``char-misc-4.15-rc1`` based on the
last commit in the ``char-misc-next`` branch, and sign it with your gpg key
-(see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`).
+(see Documentation/maintainer/configure-git.rst).
Linus will only accept pull requests based on a signed tag. Other
maintainers may differ.
diff --git a/Documentation/mm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst
index af3891f..c82e3ee 100644
--- a/Documentation/mm/arch_pgtable_helpers.rst
+++ b/Documentation/mm/arch_pgtable_helpers.rst
@@ -46,7 +46,11 @@
+---------------------------+--------------------------------------------------+
| pte_mkclean | Creates a clean PTE |
+---------------------------+--------------------------------------------------+
-| pte_mkwrite | Creates a writable PTE |
+| pte_mkwrite | Creates a writable PTE of the type specified by |
+| | the VMA. |
++---------------------------+--------------------------------------------------+
+| pte_mkwrite_novma | Creates a writable PTE, of the conventional type |
+| | of writable. |
+---------------------------+--------------------------------------------------+
| pte_wrprotect | Creates a write protected PTE |
+---------------------------+--------------------------------------------------+
@@ -118,7 +122,11 @@
+---------------------------+--------------------------------------------------+
| pmd_mkclean | Creates a clean PMD |
+---------------------------+--------------------------------------------------+
-| pmd_mkwrite | Creates a writable PMD |
+| pmd_mkwrite | Creates a writable PMD of the type specified by |
+| | the VMA. |
++---------------------------+--------------------------------------------------+
+| pmd_mkwrite_novma | Creates a writable PMD, of the conventional type |
+| | of writable. |
+---------------------------+--------------------------------------------------+
| pmd_wrprotect | Creates a write protected PMD |
+---------------------------+--------------------------------------------------+
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 4bfdf1d..a20383d 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -380,12 +380,24 @@
memory, and whether it should exclude the memory of the type (filter-out), or
all except the memory of the type (filter-in).
-As of this writing, anonymous page type and memory cgroup type are supported by
-the feature. Some filter target types can require additional arguments. For
-example, the memory cgroup filter type asks users to specify the file path of
-the memory cgroup for the filter. Hence, users can apply specific schemes to
-only anonymous pages, non-anonymous pages, pages of specific cgroups, all pages
-excluding those of specific cgroups, and any combination of those.
+Currently, anonymous page, memory cgroup, address range, and DAMON monitoring
+target type filters are supported by the feature. Some filter target types
+require additional arguments. The memory cgroup filter type asks users to
+specify the file path of the memory cgroup for the filter. The address range
+type asks the start and end addresses of the range. The DAMON monitoring
+target type asks the index of the target from the context's monitoring targets
+list. Hence, users can apply specific schemes to only anonymous pages,
+non-anonymous pages, pages of specific cgroups, all pages excluding those of
+specific cgroups, pages in specific address range, pages in specific DAMON
+monitoring targets, and any combination of those.
+
+To handle filters efficiently, the address range and DAMON monitoring target
+type filters are handled by the core layer, while others are handled by
+operations set. If a memory region is filtered by a core layer-handled filter,
+it is not counted as the scheme has tried to the region. In contrast, if a
+memory regions is filtered by an operations set layer-handled filter, it is
+counted as the scheme has tried. The difference in accounting leads to changes
+in the statistics.
Application Programming Interface
diff --git a/Documentation/mm/frontswap.rst b/Documentation/mm/frontswap.rst
deleted file mode 100644
index c892412..0000000
--- a/Documentation/mm/frontswap.rst
+++ /dev/null
@@ -1,264 +0,0 @@
-=========
-Frontswap
-=========
-
-Frontswap provides a "transcendent memory" interface for swap pages.
-In some environments, dramatic performance savings may be obtained because
-swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
-
-.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
-
-Frontswap is so named because it can be thought of as the opposite of
-a "backing" store for a swap device. The storage is assumed to be
-a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
-to the requirements of transcendent memory (such as Xen's "tmem", or
-in-kernel compressed memory, aka "zcache", or future RAM-like devices);
-this pseudo-RAM device is not directly accessible or addressable by the
-kernel and is of unknown and possibly time-varying size. The driver
-links itself to frontswap by calling frontswap_register_ops to set the
-frontswap_ops funcs appropriately and the functions it provides must
-conform to certain policies as follows:
-
-An "init" prepares the device to receive frontswap pages associated
-with the specified swap device number (aka "type"). A "store" will
-copy the page to transcendent memory and associate it with the type and
-offset associated with the page. A "load" will copy the page, if found,
-from transcendent memory into kernel memory, but will NOT remove the page
-from transcendent memory. An "invalidate_page" will remove the page
-from transcendent memory and an "invalidate_area" will remove ALL pages
-associated with the swap type (e.g., like swapoff) and notify the "device"
-to refuse further stores with that swap type.
-
-Once a page is successfully stored, a matching load on the page will normally
-succeed. So when the kernel finds itself in a situation where it needs
-to swap out a page, it first attempts to use frontswap. If the store returns
-success, the data has been successfully saved to transcendent memory and
-a disk write and, if the data is later read back, a disk read are avoided.
-If a store returns failure, transcendent memory has rejected the data, and the
-page can be written to swap as usual.
-
-Note that if a page is stored and the page already exists in transcendent memory
-(a "duplicate" store), either the store succeeds and the data is overwritten,
-or the store fails AND the page is invalidated. This ensures stale data may
-never be obtained from frontswap.
-
-If properly configured, monitoring of frontswap is done via debugfs in
-the `/sys/kernel/debug/frontswap` directory. The effectiveness of
-frontswap can be measured (across all swap devices) with:
-
-``failed_stores``
- how many store attempts have failed
-
-``loads``
- how many loads were attempted (all should succeed)
-
-``succ_stores``
- how many store attempts have succeeded
-
-``invalidates``
- how many invalidates were attempted
-
-A backend implementation may provide additional metrics.
-
-FAQ
-===
-
-* Where's the value?
-
-When a workload starts swapping, performance falls through the floor.
-Frontswap significantly increases performance in many such workloads by
-providing a clean, dynamic interface to read and write swap pages to
-"transcendent memory" that is otherwise not directly addressable to the kernel.
-This interface is ideal when data is transformed to a different form
-and size (such as with compression) or secretly moved (as might be
-useful for write-balancing for some RAM-like devices). Swap pages (and
-evicted page-cache pages) are a great use for this kind of slower-than-RAM-
-but-much-faster-than-disk "pseudo-RAM device".
-
-Frontswap with a fairly small impact on the kernel,
-provides a huge amount of flexibility for more dynamic, flexible RAM
-utilization in various system configurations:
-
-In the single kernel case, aka "zcache", pages are compressed and
-stored in local memory, thus increasing the total anonymous pages
-that can be safely kept in RAM. Zcache essentially trades off CPU
-cycles used in compression/decompression for better memory utilization.
-Benchmarks have shown little or no impact when memory pressure is
-low while providing a significant performance improvement (25%+)
-on some workloads under high memory pressure.
-
-"RAMster" builds on zcache by adding "peer-to-peer" transcendent memory
-support for clustered systems. Frontswap pages are locally compressed
-as in zcache, but then "remotified" to another system's RAM. This
-allows RAM to be dynamically load-balanced back-and-forth as needed,
-i.e. when system A is overcommitted, it can swap to system B, and
-vice versa. RAMster can also be configured as a memory server so
-many servers in a cluster can swap, dynamically as needed, to a single
-server configured with a large amount of RAM... without pre-configuring
-how much of the RAM is available for each of the clients!
-
-In the virtual case, the whole point of virtualization is to statistically
-multiplex physical resources across the varying demands of multiple
-virtual machines. This is really hard to do with RAM and efforts to do
-it well with no kernel changes have essentially failed (except in some
-well-publicized special-case workloads).
-Specifically, the Xen Transcendent Memory backend allows otherwise
-"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
-virtual machines, but the pages can be compressed and deduplicated to
-optimize RAM utilization. And when guest OS's are induced to surrender
-underutilized RAM (e.g. with "selfballooning"), sudden unexpected
-memory pressure may result in swapping; frontswap allows those pages
-to be swapped to and from hypervisor RAM (if overall host system memory
-conditions allow), thus mitigating the potentially awful performance impact
-of unplanned swapping.
-
-A KVM implementation is underway and has been RFC'ed to lkml. And,
-using frontswap, investigation is also underway on the use of NVM as
-a memory extension technology.
-
-* Sure there may be performance advantages in some situations, but
- what's the space/time overhead of frontswap?
-
-If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into
-nothingness and the only overhead is a few extra bytes per swapon'ed
-swap device. If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
-registers, there is one extra global variable compared to zero for
-every swap page read or written. If CONFIG_FRONTSWAP is enabled
-AND a frontswap backend registers AND the backend fails every "store"
-request (i.e. provides no memory despite claiming it might),
-CPU overhead is still negligible -- and since every frontswap fail
-precedes a swap page write-to-disk, the system is highly likely
-to be I/O bound and using a small fraction of a percent of a CPU
-will be irrelevant anyway.
-
-As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend
-registers, one bit is allocated for every swap page for every swap
-device that is swapon'd. This is added to the EIGHT bits (which
-was sixteen until about 2.6.34) that the kernel already allocates
-for every swap page for every swap device that is swapon'd. (Hugh
-Dickins has observed that frontswap could probably steal one of
-the existing eight bits, but let's worry about that minor optimization
-later.) For very large swap disks (which are rare) on a standard
-4K pagesize, this is 1MB per 32GB swap.
-
-When swap pages are stored in transcendent memory instead of written
-out to disk, there is a side effect that this may create more memory
-pressure that can potentially outweigh the other advantages. A
-backend, such as zcache, must implement policies to carefully (but
-dynamically) manage memory limits to ensure this doesn't happen.
-
-* OK, how about a quick overview of what this frontswap patch does
- in terms that a kernel hacker can grok?
-
-Let's assume that a frontswap "backend" has registered during
-kernel initialization; this registration indicates that this
-frontswap backend has access to some "memory" that is not directly
-accessible by the kernel. Exactly how much memory it provides is
-entirely dynamic and random.
-
-Whenever a swap-device is swapon'd frontswap_init() is called,
-passing the swap device number (aka "type") as a parameter.
-This notifies frontswap to expect attempts to "store" swap pages
-associated with that number.
-
-Whenever the swap subsystem is readying a page to write to a swap
-device (c.f swap_writepage()), frontswap_store is called. Frontswap
-consults with the frontswap backend and if the backend says it does NOT
-have room, frontswap_store returns -1 and the kernel swaps the page
-to the swap device as normal. Note that the response from the frontswap
-backend is unpredictable to the kernel; it may choose to never accept a
-page, it could accept every ninth page, or it might accept every
-page. But if the backend does accept a page, the data from the page
-has already been copied and associated with the type and offset,
-and the backend guarantees the persistence of the data. In this case,
-frontswap sets a bit in the "frontswap_map" for the swap device
-corresponding to the page offset on the swap device to which it would
-otherwise have written the data.
-
-When the swap subsystem needs to swap-in a page (swap_readpage()),
-it first calls frontswap_load() which checks the frontswap_map to
-see if the page was earlier accepted by the frontswap backend. If
-it was, the page of data is filled from the frontswap backend and
-the swap-in is complete. If not, the normal swap-in code is
-executed to obtain the page of data from the real swap device.
-
-So every time the frontswap backend accepts a page, a swap device read
-and (potentially) a swap device write are replaced by a "frontswap backend
-store" and (possibly) a "frontswap backend loads", which are presumably much
-faster.
-
-* Can't frontswap be configured as a "special" swap device that is
- just higher priority than any real swap device (e.g. like zswap,
- or maybe swap-over-nbd/NFS)?
-
-No. First, the existing swap subsystem doesn't allow for any kind of
-swap hierarchy. Perhaps it could be rewritten to accommodate a hierarchy,
-but this would require fairly drastic changes. Even if it were
-rewritten, the existing swap subsystem uses the block I/O layer which
-assumes a swap device is fixed size and any page in it is linearly
-addressable. Frontswap barely touches the existing swap subsystem,
-and works around the constraints of the block I/O subsystem to provide
-a great deal of flexibility and dynamicity.
-
-For example, the acceptance of any swap page by the frontswap backend is
-entirely unpredictable. This is critical to the definition of frontswap
-backends because it grants completely dynamic discretion to the
-backend. In zcache, one cannot know a priori how compressible a page is.
-"Poorly" compressible pages can be rejected, and "poorly" can itself be
-defined dynamically depending on current memory constraints.
-
-Further, frontswap is entirely synchronous whereas a real swap
-device is, by definition, asynchronous and uses block I/O. The
-block I/O layer is not only unnecessary, but may perform "optimizations"
-that are inappropriate for a RAM-oriented device including delaying
-the write of some pages for a significant amount of time. Synchrony is
-required to ensure the dynamicity of the backend and to avoid thorny race
-conditions that would unnecessarily and greatly complicate frontswap
-and/or the block I/O subsystem. That said, only the initial "store"
-and "load" operations need be synchronous. A separate asynchronous thread
-is free to manipulate the pages stored by frontswap. For example,
-the "remotification" thread in RAMster uses standard asynchronous
-kernel sockets to move compressed frontswap pages to a remote machine.
-Similarly, a KVM guest-side implementation could do in-guest compression
-and use "batched" hypercalls.
-
-In a virtualized environment, the dynamicity allows the hypervisor
-(or host OS) to do "intelligent overcommit". For example, it can
-choose to accept pages only until host-swapping might be imminent,
-then force guests to do their own swapping.
-
-There is a downside to the transcendent memory specifications for
-frontswap: Since any "store" might fail, there must always be a real
-slot on a real swap device to swap the page. Thus frontswap must be
-implemented as a "shadow" to every swapon'd device with the potential
-capability of holding every page that the swap device might have held
-and the possibility that it might hold no pages at all. This means
-that frontswap cannot contain more pages than the total of swapon'd
-swap devices. For example, if NO swap device is configured on some
-installation, frontswap is useless. Swapless portable devices
-can still use frontswap but a backend for such devices must configure
-some kind of "ghost" swap device and ensure that it is never used.
-
-* Why this weird definition about "duplicate stores"? If a page
- has been previously successfully stored, can't it always be
- successfully overwritten?
-
-Nearly always it can, but no, sometimes it cannot. Consider an example
-where data is compressed and the original 4K page has been compressed
-to 1K. Now an attempt is made to overwrite the page with data that
-is non-compressible and so would take the entire 4K. But the backend
-has no more space. In this case, the store must be rejected. Whenever
-frontswap rejects a store that would overwrite, it also must invalidate
-the old data and ensure that it is no longer accessible. Since the
-swap subsystem then writes the new data to the read swap device,
-this is the correct course of action to ensure coherency.
-
-* Why does the frontswap patch create the new include file swapfile.h?
-
-The frontswap code depends on some swap-subsystem-internal data
-structures that have, over the years, moved back and forth between
-static and global. This seemed a reasonable compromise: Define
-them as global but declare them in a new include file that isn't
-included by the large number of source files that include swap.h.
-
-Dan Magenheimer, last updated April 9, 2012
diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
index c964e08..9d92e3f 100644
--- a/Documentation/mm/highmem.rst
+++ b/Documentation/mm/highmem.rst
@@ -51,11 +51,14 @@
The kernel contains several ways of creating temporary mappings. The following
list shows them in order of preference of use.
-* kmap_local_page(). This function is used to require short term mappings.
- It can be invoked from any context (including interrupts) but the mappings
- can only be used in the context which acquired them.
+* kmap_local_page(), kmap_local_folio() - These functions are used to create
+ short term mappings. They can be invoked from any context (including
+ interrupts) but the mappings can only be used in the context which acquired
+ them. The only differences between them consist in the first taking a pointer
+ to a struct page and the second taking a pointer to struct folio and the byte
+ offset within the folio which identifies the page.
- This function should always be used, whereas kmap_atomic() and kmap() have
+ These functions should always be used, whereas kmap_atomic() and kmap() have
been deprecated.
These mappings are thread-local and CPU-local, meaning that the mapping
@@ -72,17 +75,17 @@
maps of the outgoing task are saved and those of the incoming one are
restored.
- kmap_local_page() always returns a valid virtual address and it is assumed
- that kunmap_local() will never fail.
+ kmap_local_page(), as well as kmap_local_folio() always returns valid virtual
+ kernel addresses and it is assumed that kunmap_local() will never fail.
- On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the
+ On CONFIG_HIGHMEM=n kernels and for low memory pages they return the
virtual address of the direct mapping. Only real highmem pages are
temporarily mapped. Therefore, users may call a plain page_address()
for pages which are known to not come from ZONE_HIGHMEM. However, it is
- always safe to use kmap_local_page() / kunmap_local().
+ always safe to use kmap_local_{page,folio}() / kunmap_local().
- While it is significantly faster than kmap(), for the highmem case it
- comes with restrictions about the pointers validity. Contrary to kmap()
+ While they are significantly faster than kmap(), for the highmem case they
+ come with restrictions about the pointers validity. Contrary to kmap()
mappings, the local mappings are only valid in the context of the caller
and cannot be handed to other contexts. This implies that users must
be absolutely sure to keep the use of the return address local to the
@@ -91,7 +94,7 @@
Most code can be designed to use thread local mappings. User should
therefore try to design their code to avoid the use of kmap() by mapping
pages in the same thread the address will be used and prefer
- kmap_local_page().
+ kmap_local_page() or kmap_local_folio().
Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain
extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered
@@ -206,4 +209,5 @@
=========
.. kernel-doc:: include/linux/highmem.h
+.. kernel-doc:: mm/highmem.c
.. kernel-doc:: include/linux/highmem-internal.h
diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst
index 9aa512c..0595098 100644
--- a/Documentation/mm/hmm.rst
+++ b/Documentation/mm/hmm.rst
@@ -163,16 +163,7 @@
It will trigger a page fault on missing or read-only entries if write access is
requested (see below). Page faults use the generic mm page fault code path just
-like a CPU page fault.
-
-Both functions copy CPU page table entries into their pfns array argument. Each
-entry in that array corresponds to an address in the virtual range. HMM
-provides a set of flags to help the driver identify special CPU page table
-entries.
-
-Locking within the sync_cpu_device_pagetables() callback is the most important
-aspect the driver must respect in order to keep things properly synchronized.
-The usage pattern is::
+like a CPU page fault. The usage pattern is::
int driver_populate_range(...)
{
@@ -417,7 +408,7 @@
resovled by replacing the entry with the original mapping. A driver gets
notified that the mapping has been changed by MMU notifiers, after which point
it will no longer have exclusive access to the page. Exclusive access is
-guranteed to last until the driver drops the page lock and page reference, at
+guaranteed to last until the driver drops the page lock and page reference, at
which point any CPU faults on the page may proceed as described.
Memory cgroup (memcg) and rss accounting
diff --git a/Documentation/mm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst
index d9c2b0f..4914fbf 100644
--- a/Documentation/mm/hugetlbfs_reserv.rst
+++ b/Documentation/mm/hugetlbfs_reserv.rst
@@ -271,12 +271,12 @@
Freeing Huge Pages
==================
-Huge page freeing is performed by the routine free_huge_page(). This routine
-is the destructor for hugetlbfs compound pages. As a result, it is only
-passed a pointer to the page struct. When a huge page is freed, reservation
-accounting may need to be performed. This would be the case if the page was
-associated with a subpool that contained reserves, or the page is being freed
-on an error path where a global reserve count must be restored.
+Huge pages are freed by free_huge_folio(). It is only passed a pointer
+to the folio as it is called from the generic MM code. When a huge page
+is freed, reservation accounting may need to be performed. This would
+be the case if the page was associated with a subpool that contained
+reserves, or the page is being freed on an error path where a global
+reserve count must be restored.
The page->private field points to any subpool associated with the page.
If the PagePrivate flag is set, it indicates the global reserve count should
@@ -525,7 +525,7 @@
page is allocated but before it is instantiated. In this case, the page
allocation has consumed the reservation and made the appropriate subpool,
reservation map and global count adjustments. If the page is freed at this
-time (before instantiation and clearing of PagePrivate), then free_huge_page
+time (before instantiation and clearing of PagePrivate), then free_huge_folio
will increment the global reservation count. However, the reservation map
indicates the reservation was consumed. This resulting inconsistent state
will cause the 'leak' of a reserved huge page. The global reserve count will
diff --git a/Documentation/mm/hwpoison.rst b/Documentation/mm/hwpoison.rst
index ba48a44..483b72a 100644
--- a/Documentation/mm/hwpoison.rst
+++ b/Documentation/mm/hwpoison.rst
@@ -48,7 +48,7 @@
For the KVM use there was need for a new signal type so that
KVM can inject the machine check into the guest with the proper
address. This in theory allows other applications to handle
-memory failures too. The expection is that near all applications
+memory failures too. The expectation is that most applications
won't do that, but some very specialized ones might.
Failure recovery modes
diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
index 5a94a92..31d2ac3 100644
--- a/Documentation/mm/index.rst
+++ b/Documentation/mm/index.rst
@@ -44,7 +44,6 @@
balance
damon/index
free_page_reporting
- frontswap
hmm
hwpoison
hugetlbfs_reserv
diff --git a/Documentation/mm/page_migration.rst b/Documentation/mm/page_migration.rst
index e35af78..f1ce67a 100644
--- a/Documentation/mm/page_migration.rst
+++ b/Documentation/mm/page_migration.rst
@@ -180,7 +180,7 @@
4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split.
5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had
- to be split. After splitting, a migration retry was used for it's sub-pages.
+ to be split. After splitting, a migration retry was used for its sub-pages.
THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or
PGMIGRATE_FAIL events. For example, a THP migration failure will cause both
diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
index a834fad9..e4f6972 100644
--- a/Documentation/mm/split_page_table_lock.rst
+++ b/Documentation/mm/split_page_table_lock.rst
@@ -58,7 +58,7 @@
===================================================
There's no need in special enabling of PTE split page table lock: everything
-required is done by pgtable_pte_page_ctor() and pgtable_pte_page_dtor(), which
+required is done by pagetable_pte_ctor() and pagetable_pte_dtor(), which
must be called on PTE table allocation / freeing.
Make sure the architecture doesn't use slab allocator for page table
@@ -68,8 +68,8 @@
PMD split lock only makes sense if you have more than two page table
levels.
-PMD split lock enabling requires pgtable_pmd_page_ctor() call on PMD table
-allocation and pgtable_pmd_page_dtor() on freeing.
+PMD split lock enabling requires pagetable_pmd_ctor() call on PMD table
+allocation and pagetable_pmd_dtor() on freeing.
Allocation usually happens in pmd_alloc_one(), freeing in pmd_free() and
pmd_free_tlb(), but make sure you cover all PMD table allocation / freeing
@@ -77,7 +77,7 @@
With everything in place you can set CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK.
-NOTE: pgtable_pte_page_ctor() and pgtable_pmd_page_ctor() can fail -- it must
+NOTE: pagetable_pte_ctor() and pagetable_pmd_ctor() can fail -- it must
be handled properly.
page->ptl
@@ -97,7 +97,7 @@
split lock with enabled DEBUG_SPINLOCK or DEBUG_LOCK_ALLOC, but costs
one more cache line for indirect access;
-The spinlock_t allocated in pgtable_pte_page_ctor() for PTE table and in
-pgtable_pmd_page_ctor() for PMD table.
+The spinlock_t allocated in pagetable_pte_ctor() for PTE table and in
+pagetable_pmd_ctor() for PMD table.
Please, never access page->ptl directly -- use appropriate helper.
diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst
index d5ac851..67f1338 100644
--- a/Documentation/mm/unevictable-lru.rst
+++ b/Documentation/mm/unevictable-lru.rst
@@ -463,7 +463,7 @@
to the mmap() call. There is one important and subtle difference here, though.
mmap() + mlock() will fail if the range cannot be faulted in (e.g. because
mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail.
-The mmaped area will still have properties of the locked area - pages will not
+The mmapped area will still have properties of the locked area - pages will not
get swapped out - but major page faults to fault memory in might still happen.
Furthermore, any mmap() call or brk() call that expands the heap by a task
diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst
index a4b12ff..59891f7 100644
--- a/Documentation/mm/vmemmap_dedup.rst
+++ b/Documentation/mm/vmemmap_dedup.rst
@@ -1,3 +1,4 @@
+
.. SPDX-License-Identifier: GPL-2.0
=========================================
@@ -10,14 +11,14 @@
This section is to explain how HugeTLB Vmemmap Optimization (HVO) works.
The ``struct page`` structures are used to describe a physical page frame. By
-default, there is a one-to-one mapping from a page frame to it's corresponding
+default, there is a one-to-one mapping from a page frame to its corresponding
``struct page``.
HugeTLB pages consist of multiple base page size pages and is supported by many
architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more
details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are
currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page
-consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages.
+consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages.
For each base page, there is a corresponding ``struct page``.
Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to
@@ -210,6 +211,7 @@
The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64),
PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64).
+For powerpc equivalent details see Documentation/powerpc/vmemmap_dedup.rst
The differences with HugeTLB are relatively minor.
diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst
index a3c26d5..7690283 100644
--- a/Documentation/mm/zsmalloc.rst
+++ b/Documentation/mm/zsmalloc.rst
@@ -263,3 +263,8 @@
objects and release zspages. In these cases, it is recommended to decrease
the limit on the size of the zspage chains (as specified by the
CONFIG_ZSMALLOC_CHAIN_SIZE option).
+
+Functions
+=========
+
+.. kernel-doc:: mm/zsmalloc.c
diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml
index 57d1c1c..9806c44 100644
--- a/Documentation/netlink/genetlink-c.yaml
+++ b/Documentation/netlink/genetlink-c.yaml
@@ -41,7 +41,7 @@
description: Name of the define for the family name.
type: string
c-version-name:
- description: Name of the define for the verion of the family.
+ description: Name of the define for the version of the family.
type: string
max-by-define:
description: Makes the number of attributes and commands be specified by a define, not an enum value.
@@ -274,7 +274,7 @@
description: Kernel attribute validation flags.
type: array
items:
- enum: [ strict, dump ]
+ enum: [ strict, dump, dump-strict ]
do: &subop-type
description: Main command handler.
type: object
diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml
index 43b769c..12a0a04 100644
--- a/Documentation/netlink/genetlink-legacy.yaml
+++ b/Documentation/netlink/genetlink-legacy.yaml
@@ -41,7 +41,7 @@
description: Name of the define for the family name.
type: string
c-version-name:
- description: Name of the define for the verion of the family.
+ description: Name of the define for the version of the family.
type: string
max-by-define:
description: Makes the number of attributes and commands be specified by a define, not an enum value.
@@ -321,7 +321,7 @@
description: Kernel attribute validation flags.
type: array
items:
- enum: [ strict, dump ]
+ enum: [ strict, dump, dump-strict ]
# Start genetlink-legacy
fixed-header: *fixed-header
# End genetlink-legacy
diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml
index 1cbb448..3d338c4 100644
--- a/Documentation/netlink/genetlink.yaml
+++ b/Documentation/netlink/genetlink.yaml
@@ -243,7 +243,7 @@
description: Kernel attribute validation flags.
type: array
items:
- enum: [ strict, dump ]
+ enum: [ strict, dump, dump-strict ]
do: &subop-type
description: Main command handler.
type: object
diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml
new file mode 100644
index 0000000..8967978
--- /dev/null
+++ b/Documentation/netlink/netlink-raw.yaml
@@ -0,0 +1,410 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://kernel.org/schemas/netlink/netlink-raw.yaml#
+$schema: https://json-schema.org/draft-07/schema
+
+# Common defines
+$defs:
+ uint:
+ type: integer
+ minimum: 0
+ len-or-define:
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_]+( - 1)?$
+ minimum: 0
+
+# Schema for specs
+title: Protocol
+description: Specification of a raw netlink protocol
+type: object
+required: [ name, doc, attribute-sets, operations ]
+additionalProperties: False
+properties:
+ name:
+ description: Name of the netlink family.
+ type: string
+ doc:
+ type: string
+ protocol:
+ description: Schema compatibility level.
+ enum: [ netlink-raw ] # Trim
+ # Start netlink-raw
+ protonum:
+ description: Protocol number to use for netlink-raw
+ type: integer
+ # End netlink-raw
+ uapi-header:
+ description: Path to the uAPI header, default is linux/${family-name}.h
+ type: string
+ # Start genetlink-c
+ c-family-name:
+ description: Name of the define for the family name.
+ type: string
+ c-version-name:
+ description: Name of the define for the version of the family.
+ type: string
+ max-by-define:
+ description: Makes the number of attributes and commands be specified by a define, not an enum value.
+ type: boolean
+ # End genetlink-c
+ # Start genetlink-legacy
+ kernel-policy:
+ description: |
+ Defines if the input policy in the kernel is global, per-operation, or split per operation type.
+ Default is split.
+ enum: [ split, per-op, global ]
+ # End genetlink-legacy
+
+ definitions:
+ description: List of type and constant definitions (enums, flags, defines).
+ type: array
+ items:
+ type: object
+ required: [ type, name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ header:
+ description: For C-compatible languages, header which already defines this value.
+ type: string
+ type:
+ enum: [ const, enum, flags, struct ] # Trim
+ doc:
+ type: string
+ # For const
+ value:
+ description: For const - the value.
+ type: [ string, integer ]
+ # For enum and flags
+ value-start:
+ description: For enum or flags the literal initializer for the first value.
+ type: [ string, integer ]
+ entries:
+ description: For enum or flags array of values.
+ type: array
+ items:
+ oneOf:
+ - type: string
+ - type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ value:
+ type: integer
+ doc:
+ type: string
+ render-max:
+ description: Render the max members for this enum.
+ type: boolean
+ # Start genetlink-c
+ enum-name:
+ description: Name for enum, if empty no name will be used.
+ type: [ string, "null" ]
+ name-prefix:
+ description: For enum the prefix of the values, optional.
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ members:
+ description: List of struct members. Only scalars and strings members allowed.
+ type: array
+ items:
+ type: object
+ required: [ name, type ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ type:
+ description: The netlink attribute type
+ enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string, binary ]
+ len:
+ $ref: '#/$defs/len-or-define'
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ doc:
+ description: Documentation for the struct member attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, uuid ]
+ # End genetlink-legacy
+
+ attribute-sets:
+ description: Definition of attribute spaces for this family.
+ type: array
+ items:
+ description: Definition of a single attribute space.
+ type: object
+ required: [ name, attributes ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ Name used when referring to this space in other definitions, not used outside of the spec.
+ type: string
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the attributes. Default family[name]-set[name]-a-
+ type: string
+ enum-name:
+ description: Name for the enum type of the attribute.
+ type: string
+ doc:
+ description: Documentation of the space.
+ type: string
+ subset-of:
+ description: |
+ Name of another space which this is a logical part of. Sub-spaces can be used to define
+ a limited group of attributes which are used in a nest.
+ type: string
+ # Start genetlink-c
+ attr-cnt-name:
+ description: The explicit name for constant holding the count of attributes (last attr + 1).
+ type: string
+ attr-max-name:
+ description: The explicit name for last member of attribute enum.
+ type: string
+ # End genetlink-c
+ attributes:
+ description: List of attributes in the space.
+ type: array
+ items:
+ type: object
+ required: [ name, type ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ type: &attr-type
+ description: The netlink attribute type
+ enum: [ unused, pad, flag, binary, u8, u16, u32, u64, s32, s64,
+ string, nest, array-nest, nest-type-value ]
+ doc:
+ description: Documentation of the attribute.
+ type: string
+ value:
+ description: Value for the enum item representing this attribute in the uAPI.
+ $ref: '#/$defs/uint'
+ type-value:
+ description: Name of the value extracted from the type of a nest-type-value attribute.
+ type: array
+ items:
+ type: string
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ multi-attr:
+ type: boolean
+ nested-attributes:
+ description: Name of the space (sub-space) used inside the attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ checks:
+ description: Kernel input validation.
+ type: object
+ additionalProperties: False
+ properties:
+ flags-mask:
+ description: Name of the flags constant on which to base mask (unsigned scalar types only).
+ type: string
+ min:
+ description: Min value for an integer attribute.
+ type: integer
+ min-len:
+ description: Min length for a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ max-len:
+ description: Max length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ sub-type: *attr-type
+ display-hint: *display-hint
+ # Start genetlink-c
+ name-prefix:
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ struct:
+ description: Name of the struct type used for the attribute.
+ type: string
+ # End genetlink-legacy
+
+ # Make sure name-prefix does not appear in subsets (subsets inherit naming)
+ dependencies:
+ name-prefix:
+ not:
+ required: [ subset-of ]
+ subset-of:
+ not:
+ required: [ name-prefix ]
+
+ operations:
+ description: Operations supported by the protocol.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ enum-model:
+ description: |
+ The model of assigning values to the operations.
+ "unified" is the recommended model where all message types belong
+ to a single enum.
+ "directional" has the messages sent to the kernel and from the kernel
+ enumerated separately.
+ enum: [ unified, directional ] # Trim
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the command. The name is formed by concatenating
+ the prefix with the upper case name of the command, with dashes replaced by underscores.
+ type: string
+ enum-name:
+ description: Name for the enum type with commands.
+ type: string
+ async-prefix:
+ description: Same as name-prefix but used to render notifications and events to separate enum.
+ type: string
+ async-enum:
+ description: Name for the enum type with notifications/events.
+ type: string
+ # Start genetlink-legacy
+ fixed-header: &fixed-header
+ description: |
+ Name of the structure defining the optional fixed-length protocol
+ header. This header is placed in a message after the netlink and
+ genetlink headers and before any attributes.
+ type: string
+ # End genetlink-legacy
+ list:
+ description: List of commands
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, doc ]
+ properties:
+ name:
+ description: Name of the operation, also defining its C enum value in uAPI.
+ type: string
+ doc:
+ description: Documentation for the command.
+ type: string
+ value:
+ description: Value for the enum in the uAPI.
+ $ref: '#/$defs/uint'
+ attribute-set:
+ description: |
+ Attribute space from which attributes directly in the requests and replies
+ to this command are defined.
+ type: string
+ flags: &cmd_flags
+ description: Command flags.
+ type: array
+ items:
+ enum: [ admin-perm ]
+ dont-validate:
+ description: Kernel attribute validation flags.
+ type: array
+ items:
+ enum: [ strict, dump ]
+ # Start genetlink-legacy
+ fixed-header: *fixed-header
+ # End genetlink-legacy
+ do: &subop-type
+ description: Main command handler.
+ type: object
+ additionalProperties: False
+ properties:
+ request: &subop-attr-list
+ description: Definition of the request message for a given command.
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: |
+ Names of attributes from the attribute-set (not full attribute
+ definitions, just names).
+ type: array
+ items:
+ type: string
+ # Start genetlink-legacy
+ value:
+ description: |
+ ID of this message if value for request and response differ,
+ i.e. requests and responses have different message enums.
+ $ref: '#/$defs/uint'
+ # End genetlink-legacy
+ reply: *subop-attr-list
+ pre:
+ description: Hook for a function to run before the main callback (pre_doit or start).
+ type: string
+ post:
+ description: Hook for a function to run after the main callback (post_doit or done).
+ type: string
+ dump: *subop-type
+ notify:
+ description: Name of the command sharing the reply type with this notification.
+ type: string
+ event:
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: Explicit list of the attributes for the notification.
+ type: array
+ items:
+ type: string
+ mcgrp:
+ description: Name of the multicast group generating given notification.
+ type: string
+ mcast-groups:
+ description: List of multicast groups.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ list:
+ description: List of groups.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ The name for the group, used to form the define and the value of the define.
+ type: string
+ # Start genetlink-c
+ c-define-name:
+ description: Override for the name of the define in C uAPI.
+ type: string
+ # End genetlink-c
+ flags: *cmd_flags
+ # Start netlink-raw
+ value:
+ description: Value of the netlink multicast group in the uAPI.
+ type: integer
+ # End netlink-raw
diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml
index 5d46ca9..d1ebcd9 100644
--- a/Documentation/netlink/specs/devlink.yaml
+++ b/Documentation/netlink/specs/devlink.yaml
@@ -6,6 +6,16 @@
doc: Partial family for Devlink.
+definitions:
+ -
+ type: enum
+ name: sb-pool-type
+ entries:
+ -
+ name: ingress
+ -
+ name: egress
+
attribute-sets:
-
name: devlink
@@ -25,6 +35,46 @@
# TODO: fill in the attributes in between
-
+ name: sb-index
+ type: u32
+ value: 11
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: sb-pool-index
+ type: u16
+ value: 17
+
+ -
+ name: sb-pool-type
+ type: u8
+ enum: sb-pool-type
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: sb-tc-index
+ type: u16
+ value: 22
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: param-name
+ type: string
+ value: 81
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: region-name
+ type: string
+ value: 88
+
+ # TODO: fill in the attributes in between
+
+ -
name: info-driver-name
type: string
value: 98
@@ -56,9 +106,34 @@
# TODO: fill in the attributes in between
-
+ name: health-reporter-name
+ type: string
+ value: 115
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: trap-name
+ type: string
+ value: 130
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: trap-group-name
+ type: string
+ value: 135
+
+ -
name: reload-failed
type: u8
- value: 136
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: trap-policer-id
+ type: u32
+ value: 142
# TODO: fill in the attributes in between
@@ -103,6 +178,21 @@
type: nest
multi-attr: true
nested-attributes: dl-reload-act-stats
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: rate-node-name
+ type: string
+ value: 168
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: linecard-index
+ type: u32
+ value: 171
+
-
name: dl-dev-stats
subset-of: devlink
@@ -165,8 +255,13 @@
name: get
doc: Get devlink instances.
attribute-set: devlink
+ dont-validate:
+ - strict
+ - dump
do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
request:
value: 1
attributes: &dev-id-attrs
@@ -183,18 +278,212 @@
dump:
reply: *get-reply
+ -
+ name: port-get
+ doc: Get devlink port instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ value: 5
+ attributes: &port-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ reply:
+ value: 7
+ attributes: *port-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply:
+ value: 3 # due to a bug, port dump returns DEVLINK_CMD_NEW
+ attributes: *port-id-attrs
+
+ # TODO: fill in the operations in between
+
+ -
+ name: sb-get
+ doc: Get shared buffer instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 11
+ attributes: &sb-id-attrs
+ - bus-name
+ - dev-name
+ - sb-index
+ reply: &sb-get-reply
+ value: 11
+ attributes: *sb-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: sb-pool-get
+ doc: Get shared buffer pool instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 15
+ attributes: &sb-pool-id-attrs
+ - bus-name
+ - dev-name
+ - sb-index
+ - sb-pool-index
+ reply: &sb-pool-get-reply
+ value: 15
+ attributes: *sb-pool-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-pool-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: sb-port-pool-get
+ doc: Get shared buffer port-pool combinations and threshold.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ value: 19
+ attributes: &sb-port-pool-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - sb-index
+ - sb-pool-index
+ reply: &sb-port-pool-get-reply
+ value: 19
+ attributes: *sb-port-pool-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-port-pool-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: sb-tc-pool-bind-get
+ doc: Get shared buffer port-TC to pool bindings and threshold.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ value: 23
+ attributes: &sb-tc-pool-bind-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - sb-index
+ - sb-pool-type
+ - sb-tc-index
+ reply: &sb-tc-pool-bind-get-reply
+ value: 23
+ attributes: *sb-tc-pool-bind-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-tc-pool-bind-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: param-get
+ doc: Get param instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 38
+ attributes: ¶m-id-attrs
+ - bus-name
+ - dev-name
+ - param-name
+ reply: ¶m-get-reply
+ value: 38
+ attributes: *param-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *param-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: region-get
+ doc: Get region instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit-port-optional
+ post: devlink-nl-post-doit
+ request:
+ value: 42
+ attributes: ®ion-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - region-name
+ reply: ®ion-get-reply
+ value: 42
+ attributes: *region-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *region-get-reply
+
# TODO: fill in the operations in between
-
name: info-get
doc: Get device information, like driver name, hardware and firmware versions etc.
attribute-set: devlink
+ dont-validate:
+ - strict
+ - dump
do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
request:
value: 51
attributes: *dev-id-attrs
- reply:
+ reply: &info-get-reply
value: 51
attributes:
- bus-name
@@ -204,3 +493,181 @@
- info-version-fixed
- info-version-running
- info-version-stored
+ dump:
+ reply: *info-get-reply
+
+ -
+ name: health-reporter-get
+ doc: Get health reporter instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit-port-optional
+ post: devlink-nl-post-doit
+ request:
+ attributes: &health-reporter-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - health-reporter-name
+ reply: &health-reporter-get-reply
+ attributes: *health-reporter-id-attrs
+ dump:
+ request:
+ attributes: *port-id-attrs
+ reply: *health-reporter-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: trap-get
+ doc: Get trap instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 61
+ attributes: &trap-id-attrs
+ - bus-name
+ - dev-name
+ - trap-name
+ reply: &trap-get-reply
+ value: 61
+ attributes: *trap-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *trap-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: trap-group-get
+ doc: Get trap group instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 65
+ attributes: &trap-group-id-attrs
+ - bus-name
+ - dev-name
+ - trap-group-name
+ reply: &trap-group-get-reply
+ value: 65
+ attributes: *trap-group-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *trap-group-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: trap-policer-get
+ doc: Get trap policer instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 69
+ attributes: &trap-policer-id-attrs
+ - bus-name
+ - dev-name
+ - trap-policer-id
+ reply: &trap-policer-get-reply
+ value: 69
+ attributes: *trap-policer-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *trap-policer-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: rate-get
+ doc: Get rate instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 74
+ attributes: &rate-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - rate-node-name
+ reply: &rate-get-reply
+ value: 74
+ attributes: *rate-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *rate-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: linecard-get
+ doc: Get line card instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 78
+ attributes: &linecard-id-attrs
+ - bus-name
+ - dev-name
+ - linecard-index
+ reply: &linecard-get-reply
+ value: 78
+ attributes: *linecard-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *linecard-get-reply
+
+ # TODO: fill in the operations in between
+
+ -
+ name: selftests-get
+ doc: Get device selftest instances.
+ attribute-set: devlink
+ dont-validate:
+ - strict
+ - dump
+
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 82
+ attributes: *dev-id-attrs
+ reply: &selftests-get-reply
+ value: 82
+ attributes: *dev-id-attrs
+ dump:
+ reply: *selftests-get-reply
diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml
index 3e13826..0af5ab8 100644
--- a/Documentation/netlink/specs/fou.yaml
+++ b/Documentation/netlink/specs/fou.yaml
@@ -107,16 +107,16 @@
flags: [ admin-perm ]
do:
- request: &select_attrs
+ request: &select_attrs
attributes:
- - af
- - ifindex
- - port
- - peer_port
- - local_v4
- - peer_v4
- - local_v6
- - peer_v6
+ - af
+ - ifindex
+ - port
+ - peer_port
+ - local_v4
+ - peer_v4
+ - local_v6
+ - peer_v6
-
name: get
diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml
index b99e7ff..1c7284fd 100644
--- a/Documentation/netlink/specs/netdev.yaml
+++ b/Documentation/netlink/specs/netdev.yaml
@@ -14,7 +14,7 @@
-
name: basic
doc:
- XDP feautues set supported by all drivers
+ XDP features set supported by all drivers
(XDP_ABORTED, XDP_DROP, XDP_PASS, XDP_TX)
-
name: redirect
@@ -62,6 +62,12 @@
type: u64
enum: xdp-act
enum-as-flags: true
+ -
+ name: xdp-zc-max-segs
+ doc: max fragment count supported by ZC driver
+ type: u32
+ checks:
+ min: 1
operations:
list:
@@ -77,6 +83,7 @@
attributes:
- ifindex
- xdp-features
+ - xdp-zc-max-segs
dump:
reply: *dev-all
-
diff --git a/Documentation/netlink/specs/ovs_vport.yaml b/Documentation/netlink/specs/ovs_vport.yaml
index 1733645..f65ce62 100644
--- a/Documentation/netlink/specs/ovs_vport.yaml
+++ b/Documentation/netlink/specs/ovs_vport.yaml
@@ -82,6 +82,10 @@
enum-name: ovs-vport-attr
attributes:
-
+ name: unspec
+ type: unused
+ value: 0
+ -
name: port-no
type: u32
-
@@ -121,9 +125,34 @@
name-prefix: ovs-vport-cmd-
list:
-
+ name: new
+ doc: Create a new OVS vport
+ attribute-set: vport
+ fixed-header: ovs-header
+ do:
+ request:
+ attributes:
+ - name
+ - type
+ - upcall-pid
+ - dp-ifindex
+ - ifindex
+ - options
+ -
+ name: del
+ doc: Delete existing OVS vport from a data path
+ attribute-set: vport
+ fixed-header: ovs-header
+ do:
+ request:
+ attributes:
+ - dp-ifindex
+ - port-no
+ - type
+ - name
+ -
name: get
doc: Get / dump OVS vport configuration and state
- value: 3
attribute-set: vport
fixed-header: ovs-header
do: &vport-get-op
diff --git a/Documentation/netlink/specs/rt_addr.yaml b/Documentation/netlink/specs/rt_addr.yaml
new file mode 100644
index 0000000..cbee1ce
--- /dev/null
+++ b/Documentation/netlink/specs/rt_addr.yaml
@@ -0,0 +1,179 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+
+name: rt-addr
+protocol: netlink-raw
+protonum: 0
+
+doc:
+ Address configuration over rtnetlink.
+
+definitions:
+ -
+ name: ifaddrmsg
+ type: struct
+ members:
+ -
+ name: ifa-family
+ type: u8
+ -
+ name: ifa-prefixlen
+ type: u8
+ -
+ name: ifa-flags
+ type: u8
+ enum: ifa-flags
+ enum-as-flags: true
+ -
+ name: ifa-scope
+ type: u8
+ -
+ name: ifa-index
+ type: u32
+ -
+ name: ifa-cacheinfo
+ type: struct
+ members:
+ -
+ name: ifa-prefered
+ type: u32
+ -
+ name: ifa-valid
+ type: u32
+ -
+ name: cstamp
+ type: u32
+ -
+ name: tstamp
+ type: u32
+
+ -
+ name: ifa-flags
+ type: flags
+ entries:
+ -
+ name: secondary
+ -
+ name: nodad
+ -
+ name: optimistic
+ -
+ name: dadfailed
+ -
+ name: homeaddress
+ -
+ name: deprecated
+ -
+ name: tentative
+ -
+ name: permanent
+ -
+ name: managetempaddr
+ -
+ name: noprefixroute
+ -
+ name: mcautojoin
+ -
+ name: stable-privacy
+
+attribute-sets:
+ -
+ name: addr-attrs
+ attributes:
+ -
+ name: ifa-address
+ type: binary
+ display-hint: ipv4
+ -
+ name: ifa-local
+ type: binary
+ display-hint: ipv4
+ -
+ name: ifa-label
+ type: string
+ -
+ name: ifa-broadcast
+ type: binary
+ display-hint: ipv4
+ -
+ name: ifa-anycast
+ type: binary
+ -
+ name: ifa-cacheinfo
+ type: binary
+ struct: ifa-cacheinfo
+ -
+ name: ifa-multicast
+ type: binary
+ -
+ name: ifa-flags
+ type: u32
+ enum: ifa-flags
+ enum-as-flags: true
+ -
+ name: ifa-rt-priority
+ type: u32
+ -
+ name: ifa-target-netnsid
+ type: binary
+ -
+ name: ifa-proto
+ type: u8
+
+
+operations:
+ fixed-header: ifaddrmsg
+ enum-model: directional
+ list:
+ -
+ name: newaddr
+ doc: Add new address
+ attribute-set: addr-attrs
+ do:
+ request:
+ value: 20
+ attributes: &ifaddr-all
+ - ifa-family
+ - ifa-flags
+ - ifa-prefixlen
+ - ifa-scope
+ - ifa-index
+ - ifa-address
+ - ifa-label
+ - ifa-local
+ - ifa-cacheinfo
+ -
+ name: deladdr
+ doc: Remove address
+ attribute-set: addr-attrs
+ do:
+ request:
+ value: 21
+ attributes:
+ - ifa-family
+ - ifa-flags
+ - ifa-prefixlen
+ - ifa-scope
+ - ifa-index
+ - ifa-address
+ - ifa-local
+ -
+ name: getaddr
+ doc: Dump address information.
+ attribute-set: addr-attrs
+ dump:
+ request:
+ value: 22
+ attributes:
+ - ifa-index
+ reply:
+ value: 20
+ attributes: *ifaddr-all
+
+mcast-groups:
+ list:
+ -
+ name: rtnlgrp-ipv4-ifaddr
+ value: 5
+ -
+ name: rtnlgrp-ipv6-ifaddr
+ value: 9
diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt_link.yaml
new file mode 100644
index 0000000..d86a68f
--- /dev/null
+++ b/Documentation/netlink/specs/rt_link.yaml
@@ -0,0 +1,1432 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+
+name: rt-link
+protocol: netlink-raw
+protonum: 0
+
+doc:
+ Link configuration over rtnetlink.
+
+definitions:
+ -
+ name: ifinfo-flags
+ type: flags
+ entries:
+ -
+ name: up
+ -
+ name: broadcast
+ -
+ name: debug
+ -
+ name: loopback
+ -
+ name: point-to-point
+ -
+ name: no-trailers
+ -
+ name: running
+ -
+ name: no-arp
+ -
+ name: promisc
+ -
+ name: all-multi
+ -
+ name: master
+ -
+ name: slave
+ -
+ name: multicast
+ -
+ name: portsel
+ -
+ name: auto-media
+ -
+ name: dynamic
+ -
+ name: lower-up
+ -
+ name: dormant
+ -
+ name: echo
+
+ -
+ name: rtgenmsg
+ type: struct
+ members:
+ -
+ name: family
+ type: u8
+ -
+ name: ifinfomsg
+ type: struct
+ members:
+ -
+ name: ifi-family
+ type: u8
+ -
+ name: padding
+ type: u8
+ -
+ name: ifi-type
+ type: u16
+ -
+ name: ifi-index
+ type: s32
+ -
+ name: ifi-flags
+ type: u32
+ enum: ifinfo-flags
+ enum-as-flags: true
+ -
+ name: ifi-change
+ type: u32
+ -
+ name: ifla-cacheinfo
+ type: struct
+ members:
+ -
+ name: max-reasm-len
+ type: u32
+ -
+ name: tstamp
+ type: u32
+ -
+ name: reachable-time
+ type: s32
+ -
+ name: retrans-time
+ type: u32
+ -
+ name: rtnl-link-stats
+ type: struct
+ members:
+ -
+ name: rx-packets
+ type: u32
+ -
+ name: tx-packets
+ type: u32
+ -
+ name: rx-bytes
+ type: u32
+ -
+ name: tx-bytes
+ type: u32
+ -
+ name: rx-errors
+ type: u32
+ -
+ name: tx-errors
+ type: u32
+ -
+ name: rx-dropped
+ type: u32
+ -
+ name: tx-dropped
+ type: u32
+ -
+ name: multicast
+ type: u32
+ -
+ name: collisions
+ type: u32
+ -
+ name: rx-length-errors
+ type: u32
+ -
+ name: rx-over-errors
+ type: u32
+ -
+ name: rx-crc-errors
+ type: u32
+ -
+ name: rx-frame-errors
+ type: u32
+ -
+ name: rx-fifo-errors
+ type: u32
+ -
+ name: rx-missed-errors
+ type: u32
+ -
+ name: tx-aborted-errors
+ type: u32
+ -
+ name: tx-carrier-errors
+ type: u32
+ -
+ name: tx-fifo-errors
+ type: u32
+ -
+ name: tx-heartbeat-errors
+ type: u32
+ -
+ name: tx-window-errors
+ type: u32
+ -
+ name: rx-compressed
+ type: u32
+ -
+ name: tx-compressed
+ type: u32
+ -
+ name: rx-nohandler
+ type: u32
+ -
+ name: rtnl-link-stats64
+ type: struct
+ members:
+ -
+ name: rx-packets
+ type: u64
+ -
+ name: tx-packets
+ type: u64
+ -
+ name: rx-bytes
+ type: u64
+ -
+ name: tx-bytes
+ type: u64
+ -
+ name: rx-errors
+ type: u64
+ -
+ name: tx-errors
+ type: u64
+ -
+ name: rx-dropped
+ type: u64
+ -
+ name: tx-dropped
+ type: u64
+ -
+ name: multicast
+ type: u64
+ -
+ name: collisions
+ type: u64
+ -
+ name: rx-length-errors
+ type: u64
+ -
+ name: rx-over-errors
+ type: u64
+ -
+ name: rx-crc-errors
+ type: u64
+ -
+ name: rx-frame-errors
+ type: u64
+ -
+ name: rx-fifo-errors
+ type: u64
+ -
+ name: rx-missed-errors
+ type: u64
+ -
+ name: tx-aborted-errors
+ type: u64
+ -
+ name: tx-carrier-errors
+ type: u64
+ -
+ name: tx-fifo-errors
+ type: u64
+ -
+ name: tx-heartbeat-errors
+ type: u64
+ -
+ name: tx-window-errors
+ type: u64
+ -
+ name: rx-compressed
+ type: u64
+ -
+ name: tx-compressed
+ type: u64
+ -
+ name: rx-nohandler
+ type: u64
+ -
+ name: rx-otherhost-dropped
+ type: u64
+ -
+ name: rtnl-link-ifmap
+ type: struct
+ members:
+ -
+ name: mem-start
+ type: u64
+ -
+ name: mem-end
+ type: u64
+ -
+ name: base-addr
+ type: u64
+ -
+ name: irq
+ type: u16
+ -
+ name: dma
+ type: u8
+ -
+ name: port
+ type: u8
+ -
+ name: ipv4-devconf
+ type: struct
+ members:
+ -
+ name: forwarding
+ type: u32
+ -
+ name: mc-forwarding
+ type: u32
+ -
+ name: proxy-arp
+ type: u32
+ -
+ name: accept-redirects
+ type: u32
+ -
+ name: secure-redirects
+ type: u32
+ -
+ name: send-redirects
+ type: u32
+ -
+ name: shared-media
+ type: u32
+ -
+ name: rp-filter
+ type: u32
+ -
+ name: accept-source-route
+ type: u32
+ -
+ name: bootp-relay
+ type: u32
+ -
+ name: log-martians
+ type: u32
+ -
+ name: tag
+ type: u32
+ -
+ name: arpfilter
+ type: u32
+ -
+ name: medium-id
+ type: u32
+ -
+ name: noxfrm
+ type: u32
+ -
+ name: nopolicy
+ type: u32
+ -
+ name: force-igmp-version
+ type: u32
+ -
+ name: arp-announce
+ type: u32
+ -
+ name: arp-ignore
+ type: u32
+ -
+ name: promote-secondaries
+ type: u32
+ -
+ name: arp-accept
+ type: u32
+ -
+ name: arp-notify
+ type: u32
+ -
+ name: accept-local
+ type: u32
+ -
+ name: src-vmark
+ type: u32
+ -
+ name: proxy-arp-pvlan
+ type: u32
+ -
+ name: route-localnet
+ type: u32
+ -
+ name: igmpv2-unsolicited-report-interval
+ type: u32
+ -
+ name: igmpv3-unsolicited-report-interval
+ type: u32
+ -
+ name: ignore-routes-with-linkdown
+ type: u32
+ -
+ name: drop-unicast-in-l2-multicast
+ type: u32
+ -
+ name: drop-gratuitous-arp
+ type: u32
+ -
+ name: bc-forwarding
+ type: u32
+ -
+ name: arp-evict-nocarrier
+ type: u32
+ -
+ name: ipv6-devconf
+ type: struct
+ members:
+ -
+ name: forwarding
+ type: u32
+ -
+ name: hoplimit
+ type: u32
+ -
+ name: mtu6
+ type: u32
+ -
+ name: accept-ra
+ type: u32
+ -
+ name: accept-redirects
+ type: u32
+ -
+ name: autoconf
+ type: u32
+ -
+ name: dad-transmits
+ type: u32
+ -
+ name: rtr-solicits
+ type: u32
+ -
+ name: rtr-solicit-interval
+ type: u32
+ -
+ name: rtr-solicit-delay
+ type: u32
+ -
+ name: use-tempaddr
+ type: u32
+ -
+ name: temp-valid-lft
+ type: u32
+ -
+ name: temp-prefered-lft
+ type: u32
+ -
+ name: regen-max-retry
+ type: u32
+ -
+ name: max-desync-factor
+ type: u32
+ -
+ name: max-addresses
+ type: u32
+ -
+ name: force-mld-version
+ type: u32
+ -
+ name: accept-ra-defrtr
+ type: u32
+ -
+ name: accept-ra-pinfo
+ type: u32
+ -
+ name: accept-ra-rtr-pref
+ type: u32
+ -
+ name: rtr-probe-interval
+ type: u32
+ -
+ name: accept-ra-rt-info-max-plen
+ type: u32
+ -
+ name: proxy-ndp
+ type: u32
+ -
+ name: optimistic-dad
+ type: u32
+ -
+ name: accept-source-route
+ type: u32
+ -
+ name: mc-forwarding
+ type: u32
+ -
+ name: disable-ipv6
+ type: u32
+ -
+ name: accept-dad
+ type: u32
+ -
+ name: force-tllao
+ type: u32
+ -
+ name: ndisc-notify
+ type: u32
+ -
+ name: mldv1-unsolicited-report-interval
+ type: u32
+ -
+ name: mldv2-unsolicited-report-interval
+ type: u32
+ -
+ name: suppress-frag-ndisc
+ type: u32
+ -
+ name: accept-ra-from-local
+ type: u32
+ -
+ name: use-optimistic
+ type: u32
+ -
+ name: accept-ra-mtu
+ type: u32
+ -
+ name: stable-secret
+ type: u32
+ -
+ name: use-oif-addrs-only
+ type: u32
+ -
+ name: accept-ra-min-hop-limit
+ type: u32
+ -
+ name: ignore-routes-with-linkdown
+ type: u32
+ -
+ name: drop-unicast-in-l2-multicast
+ type: u32
+ -
+ name: drop-unsolicited-na
+ type: u32
+ -
+ name: keep-addr-on-down
+ type: u32
+ -
+ name: rtr-solicit-max-interval
+ type: u32
+ -
+ name: seg6-enabled
+ type: u32
+ -
+ name: seg6-require-hmac
+ type: u32
+ -
+ name: enhanced-dad
+ type: u32
+ -
+ name: addr-gen-mode
+ type: u8
+ -
+ name: disable-policy
+ type: u32
+ -
+ name: accept-ra-rt-info-min-plen
+ type: u32
+ -
+ name: ndisc-tclass
+ type: u32
+ -
+ name: rpl-seg-enabled
+ type: u32
+ -
+ name: ra-defrtr-metric
+ type: u32
+ -
+ name: ioam6-enabled
+ type: u32
+ -
+ name: ioam6-id
+ type: u32
+ -
+ name: ioam6-id-wide
+ type: u32
+ -
+ name: ndisc-evict-nocarrier
+ type: u32
+ -
+ name: accept-untracked-na
+ type: u32
+ -
+ name: ifla-icmp6-stats
+ type: struct
+ members:
+ -
+ name: inmsgs
+ type: u64
+ -
+ name: inerrors
+ type: u64
+ -
+ name: outmsgs
+ type: u64
+ -
+ name: outerrors
+ type: u64
+ -
+ name: csumerrors
+ type: u64
+ -
+ name: ratelimithost
+ type: u64
+ -
+ name: ifla-inet6-stats
+ type: struct
+ members:
+ -
+ name: inpkts
+ type: u64
+ -
+ name: inoctets
+ type: u64
+ -
+ name: indelivers
+ type: u64
+ -
+ name: outforwdatagrams
+ type: u64
+ -
+ name: outpkts
+ type: u64
+ -
+ name: outoctets
+ type: u64
+ -
+ name: inhdrerrors
+ type: u64
+ -
+ name: intoobigerrors
+ type: u64
+ -
+ name: innoroutes
+ type: u64
+ -
+ name: inaddrerrors
+ type: u64
+ -
+ name: inunknownprotos
+ type: u64
+ -
+ name: intruncatedpkts
+ type: u64
+ -
+ name: indiscards
+ type: u64
+ -
+ name: outdiscards
+ type: u64
+ -
+ name: outnoroutes
+ type: u64
+ -
+ name: reasmtimeout
+ type: u64
+ -
+ name: reasmreqds
+ type: u64
+ -
+ name: reasmoks
+ type: u64
+ -
+ name: reasmfails
+ type: u64
+ -
+ name: fragoks
+ type: u64
+ -
+ name: fragfails
+ type: u64
+ -
+ name: fragcreates
+ type: u64
+ -
+ name: inmcastpkts
+ type: u64
+ -
+ name: outmcastpkts
+ type: u64
+ -
+ name: inbcastpkts
+ type: u64
+ -
+ name: outbcastpkts
+ type: u64
+ -
+ name: inmcastoctets
+ type: u64
+ -
+ name: outmcastoctets
+ type: u64
+ -
+ name: inbcastoctets
+ type: u64
+ -
+ name: outbcastoctets
+ type: u64
+ -
+ name: csumerrors
+ type: u64
+ -
+ name: noectpkts
+ type: u64
+ -
+ name: ect1-pkts
+ type: u64
+ -
+ name: ect0-pkts
+ type: u64
+ -
+ name: cepkts
+ type: u64
+ -
+ name: reasm-overlaps
+ type: u64
+ - name: br-boolopt-multi
+ type: struct
+ members:
+ -
+ name: optval
+ type: u32
+ -
+ name: optmask
+ type: u32
+ -
+ name: if_stats_msg
+ type: struct
+ members:
+ -
+ name: family
+ type: u8
+ -
+ name: pad1
+ type: u8
+ -
+ name: pad2
+ type: u16
+ -
+ name: ifindex
+ type: u32
+ -
+ name: filter-mask
+ type: u32
+
+
+attribute-sets:
+ -
+ name: link-attrs
+ name-prefix: ifla-
+ attributes:
+ -
+ name: address
+ type: binary
+ display-hint: mac
+ -
+ name: broadcast
+ type: binary
+ display-hint: mac
+ -
+ name: ifname
+ type: string
+ -
+ name: mtu
+ type: u32
+ -
+ name: link
+ type: u32
+ -
+ name: qdisc
+ type: string
+ -
+ name: stats
+ type: binary
+ struct: rtnl-link-stats
+ -
+ name: cost
+ type: string
+ -
+ name: priority
+ type: string
+ -
+ name: master
+ type: u32
+ -
+ name: wireless
+ type: string
+ -
+ name: protinfo
+ type: string
+ -
+ name: txqlen
+ type: u32
+ -
+ name: map
+ type: binary
+ struct: rtnl-link-ifmap
+ -
+ name: weight
+ type: u32
+ -
+ name: operstate
+ type: u8
+ -
+ name: linkmode
+ type: u8
+ -
+ name: linkinfo
+ type: nest
+ nested-attributes: linkinfo-attrs
+ -
+ name: net-ns-pid
+ type: u32
+ -
+ name: ifalias
+ type: string
+ -
+ name: num-vf
+ type: u32
+ -
+ name: vfinfo-list
+ type: nest
+ nested-attributes: vfinfo-attrs
+ -
+ name: stats64
+ type: binary
+ struct: rtnl-link-stats64
+ -
+ name: vf-ports
+ type: nest
+ nested-attributes: vf-ports-attrs
+ -
+ name: port-self
+ type: nest
+ nested-attributes: port-self-attrs
+ -
+ name: af-spec
+ type: nest
+ nested-attributes: af-spec-attrs
+ -
+ name: group
+ type: u32
+ -
+ name: net-ns-fd
+ type: u32
+ -
+ name: ext-mask
+ type: u32
+ -
+ name: promiscuity
+ type: u32
+ -
+ name: num-tx-queues
+ type: u32
+ -
+ name: num-rx-queues
+ type: u32
+ -
+ name: carrier
+ type: u8
+ -
+ name: phys-port-id
+ type: binary
+ -
+ name: carrier-changes
+ type: u32
+ -
+ name: phys-switch-id
+ type: binary
+ -
+ name: link-netnsid
+ type: s32
+ -
+ name: phys-port-name
+ type: string
+ -
+ name: proto-down
+ type: u8
+ -
+ name: gso-max-segs
+ type: u32
+ -
+ name: gso-max-size
+ type: u32
+ -
+ name: pad
+ type: pad
+ -
+ name: xdp
+ type: nest
+ nested-attributes: xdp-attrs
+ -
+ name: event
+ type: u32
+ -
+ name: new-netnsid
+ type: s32
+ -
+ name: target-netnsid
+ type: s32
+ -
+ name: carrier-up-count
+ type: u32
+ -
+ name: carrier-down-count
+ type: u32
+ -
+ name: new-ifindex
+ type: s32
+ -
+ name: min-mtu
+ type: u32
+ -
+ name: max-mtu
+ type: u32
+ -
+ name: prop-list
+ type: nest
+ nested-attributes: link-attrs
+ -
+ name: alt-ifname
+ type: string
+ multi-attr: true
+ -
+ name: perm-address
+ type: binary
+ display-hint: mac
+ -
+ name: proto-down-reason
+ type: string
+ -
+ name: parent-dev-name
+ type: string
+ -
+ name: parent-dev-bus-name
+ type: string
+ -
+ name: gro-max-size
+ type: u32
+ -
+ name: tso-max-size
+ type: u32
+ -
+ name: tso-max-segs
+ type: u32
+ -
+ name: allmulti
+ type: u32
+ -
+ name: devlink-port
+ type: binary
+ -
+ name: gso-ipv4-max-size
+ type: u32
+ -
+ name: gro-ipv4-max-size
+ type: u32
+ -
+ name: af-spec-attrs
+ attributes:
+ -
+ name: "inet"
+ type: nest
+ value: 2
+ nested-attributes: ifla-attrs
+ -
+ name: "inet6"
+ type: nest
+ value: 10
+ nested-attributes: ifla6-attrs
+ -
+ name: "mctp"
+ type: nest
+ value: 45
+ nested-attributes: mctp-attrs
+ -
+ name: vfinfo-attrs
+ attributes: []
+ -
+ name: vf-ports-attrs
+ attributes: []
+ -
+ name: port-self-attrs
+ attributes: []
+ -
+ name: linkinfo-attrs
+ attributes:
+ -
+ name: kind
+ type: string
+ -
+ name: data
+ type: binary
+ # kind specific nest, e.g. linkinfo-bridge-attrs
+ -
+ name: xstats
+ type: binary
+ -
+ name: slave-kind
+ type: string
+ -
+ name: slave-data
+ type: binary
+ # kind specific nest
+ -
+ name: linkinfo-bridge-attrs
+ attributes:
+ -
+ name: forward-delay
+ type: u32
+ -
+ name: hello-time
+ type: u32
+ -
+ name: max-age
+ type: u32
+ -
+ name: ageing-time
+ type: u32
+ -
+ name: stp-state
+ type: u32
+ -
+ name: priority
+ type: u16
+ -
+ name: vlan-filtering
+ type: u8
+ -
+ name: vlan-protocol
+ type: u16
+ -
+ name: group-fwd-mask
+ type: u16
+ -
+ name: root-id
+ type: binary
+ -
+ name: bridge-id
+ type: binary
+ -
+ name: root-port
+ type: u16
+ -
+ name: root-path-cost
+ type: u32
+ -
+ name: topology-change
+ type: u8
+ -
+ name: topology-change-detected
+ type: u8
+ -
+ name: hello-timer
+ type: u64
+ -
+ name: tcn-timer
+ type: u64
+ -
+ name: topology-change-timer
+ type: u64
+ -
+ name: gc-timer
+ type: u64
+ -
+ name: group-addr
+ type: binary
+ -
+ name: fdb-flush
+ type: binary
+ -
+ name: mcast-router
+ type: u8
+ -
+ name: mcast-snooping
+ type: u8
+ -
+ name: mcast-query-use-ifaddr
+ type: u8
+ -
+ name: mcast-querier
+ type: u8
+ -
+ name: mcast-hash-elasticity
+ type: u32
+ -
+ name: mcast-hash-max
+ type: u32
+ -
+ name: mcast-last-member-cnt
+ type: u32
+ -
+ name: mcast-startup-query-cnt
+ type: u32
+ -
+ name: mcast-last-member-intvl
+ type: u64
+ -
+ name: mcast-membership-intvl
+ type: u64
+ -
+ name: mcast-querier-intvl
+ type: u64
+ -
+ name: mcast-query-intvl
+ type: u64
+ -
+ name: mcast-query-response-intvl
+ type: u64
+ -
+ name: mcast-startup-query-intvl
+ type: u64
+ -
+ name: nf-call-iptables
+ type: u8
+ -
+ name: nf-call-ip6-tables
+ type: u8
+ -
+ name: nf-call-arptables
+ type: u8
+ -
+ name: vlan-default-pvid
+ type: u16
+ -
+ name: pad
+ type: pad
+ -
+ name: vlan-stats-enabled
+ type: u8
+ -
+ name: mcast-stats-enabled
+ type: u8
+ -
+ name: mcast-igmp-version
+ type: u8
+ -
+ name: mcast-mld-version
+ type: u8
+ -
+ name: vlan-stats-per-port
+ type: u8
+ -
+ name: multi-boolopt
+ type: binary
+ struct: br-boolopt-multi
+ -
+ name: mcast-querier-state
+ type: binary
+ -
+ name: xdp-attrs
+ attributes:
+ -
+ name: fd
+ type: s32
+ -
+ name: attached
+ type: u8
+ -
+ name: flags
+ type: u32
+ -
+ name: prog-id
+ type: u32
+ -
+ name: drv-prog-id
+ type: u32
+ -
+ name: skb-prog-id
+ type: u32
+ -
+ name: hw-prog-id
+ type: u32
+ -
+ name: expected-fd
+ type: s32
+ -
+ name: ifla-attrs
+ attributes:
+ -
+ name: conf
+ type: binary
+ struct: ipv4-devconf
+ -
+ name: ifla6-attrs
+ attributes:
+ -
+ name: flags
+ type: u32
+ -
+ name: conf
+ type: binary
+ struct: ipv6-devconf
+ -
+ name: stats
+ type: binary
+ struct: ifla-inet6-stats
+ -
+ name: mcast
+ type: binary
+ -
+ name: cacheinfo
+ type: binary
+ struct: ifla-cacheinfo
+ -
+ name: icmp6-stats
+ type: binary
+ struct: ifla-icmp6-stats
+ -
+ name: token
+ type: binary
+ -
+ name: addr-gen-mode
+ type: u8
+ -
+ name: ra-mtu
+ type: u32
+ -
+ name: mctp-attrs
+ attributes:
+ -
+ name: mctp-net
+ type: u32
+ -
+ name: stats-attrs
+ name-prefix: ifla-stats-
+ attributes:
+ -
+ name: link-64
+ type: binary
+ struct: rtnl-link-stats64
+ -
+ name: link-xstats
+ type: binary
+ -
+ name: link-xstats-slave
+ type: binary
+ -
+ name: link-offload-xstats
+ type: nest
+ nested-attributes: link-offload-xstats
+ -
+ name: af-spec
+ type: binary
+ -
+ name: link-offload-xstats
+ attributes:
+ -
+ name: cpu-hit
+ type: binary
+ -
+ name: hw-s-info
+ type: array-nest
+ nested-attributes: hw-s-info-one
+ -
+ name: l3-stats
+ type: binary
+ -
+ name: hw-s-info-one
+ attributes:
+ -
+ name: request
+ type: u8
+ -
+ name: used
+ type: u8
+
+operations:
+ enum-model: directional
+ list:
+ -
+ name: newlink
+ doc: Create a new link.
+ attribute-set: link-attrs
+ fixed-header: ifinfomsg
+ do:
+ request:
+ value: 16
+ attributes: &link-new-attrs
+ - ifi-index
+ - ifname
+ - net-ns-pid
+ - net-ns-fd
+ - target-netnsid
+ - link-netnsid
+ - linkinfo
+ - group
+ - num-tx-queues
+ - num-rx-queues
+ - address
+ - broadcast
+ - mtu
+ - txqlen
+ - operstate
+ - linkmode
+ - group
+ - gso-max-size
+ - gso-max-segs
+ - gro-max-size
+ - gso-ipv4-max-size
+ - gro-ipv4-max-size
+ - af-spec
+ -
+ name: dellink
+ doc: Delete an existing link.
+ attribute-set: link-attrs
+ fixed-header: ifinfomsg
+ do:
+ request:
+ value: 17
+ attributes:
+ - ifi-index
+ - ifname
+ -
+ name: getlink
+ doc: Get / dump information about a link.
+ attribute-set: link-attrs
+ fixed-header: ifinfomsg
+ do:
+ request:
+ value: 18
+ attributes:
+ - ifi-index
+ - ifname
+ - alt-ifname
+ - ext-mask
+ - target-netnsid
+ reply:
+ value: 16
+ attributes: &link-all-attrs
+ - ifi-family
+ - ifi-type
+ - ifi-index
+ - ifi-flags
+ - ifi-change
+ - address
+ - broadcast
+ - ifname
+ - mtu
+ - link
+ - qdisc
+ - stats
+ - cost
+ - priority
+ - master
+ - wireless
+ - protinfo
+ - txqlen
+ - map
+ - weight
+ - operstate
+ - linkmode
+ - linkinfo
+ - net-ns-pid
+ - ifalias
+ - num-vf
+ - vfinfo-list
+ - stats64
+ - vf-ports
+ - port-self
+ - af-spec
+ - group
+ - net-ns-fd
+ - ext-mask
+ - promiscuity
+ - num-tx-queues
+ - num-rx-queues
+ - carrier
+ - phys-port-id
+ - carrier-changes
+ - phys-switch-id
+ - link-netnsid
+ - phys-port-name
+ - proto-down
+ - gso-max-segs
+ - gso-max-size
+ - pad
+ - xdp
+ - event
+ - new-netnsid
+ - if-netnsid
+ - target-netnsid
+ - carrier-up-count
+ - carrier-down-count
+ - new-ifindex
+ - min-mtu
+ - max-mtu
+ - prop-list
+ - alt-ifname
+ - perm-address
+ - proto-down-reason
+ - parent-dev-name
+ - parent-dev-bus-name
+ - gro-max-size
+ - tso-max-size
+ - tso-max-segs
+ - allmulti
+ - devlink-port
+ - gso-ipv4-max-size
+ - gro-ipv4-max-size
+ dump:
+ request:
+ value: 18
+ attributes:
+ - target-netnsid
+ - ext-mask
+ - master
+ - linkinfo
+ reply:
+ value: 16
+ attributes: *link-all-attrs
+ -
+ name: setlink
+ doc: Set information about a link.
+ attribute-set: link-attrs
+ fixed-header: ifinfomsg
+ do:
+ request:
+ value: 19
+ attributes: *link-all-attrs
+ -
+ name: getstats
+ doc: Get / dump link stats.
+ attribute-set: stats-attrs
+ fixed-header: if_stats_msg
+ do:
+ request:
+ value: 94
+ attributes:
+ - ifindex
+ reply:
+ value: 92
+ attributes: &link-stats-attrs
+ - family
+ - ifindex
+ - filter-mask
+ - link-64
+ - link-xstats
+ - link-xstats-slave
+ - link-offload-xstats
+ - af-spec
+ dump:
+ request:
+ value: 94
+ reply:
+ value: 92
+ attributes: *link-stats-attrs
+
+mcast-groups:
+ list:
+ -
+ name: rtnlgrp-link
+ value: 1
+ -
+ name: rtnlgrp-stats
+ value: 36
diff --git a/Documentation/netlink/specs/rt_route.yaml b/Documentation/netlink/specs/rt_route.yaml
new file mode 100644
index 0000000..f4368be
--- /dev/null
+++ b/Documentation/netlink/specs/rt_route.yaml
@@ -0,0 +1,327 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+
+name: rt-route
+protocol: netlink-raw
+protonum: 0
+
+doc:
+ Route configuration over rtnetlink.
+
+definitions:
+ -
+ name: rtm-type
+ name-prefix: rtn-
+ type: enum
+ entries:
+ - unspec
+ - unicast
+ - local
+ - broadcast
+ - anycast
+ - multicast
+ - blackhole
+ - unreachable
+ - prohibit
+ - throw
+ - nat
+ - xresolve
+ -
+ name: rtmsg
+ type: struct
+ members:
+ -
+ name: rtm-family
+ type: u8
+ -
+ name: rtm-dst-len
+ type: u8
+ -
+ name: rtm-src-len
+ type: u8
+ -
+ name: rtm-tos
+ type: u8
+ -
+ name: rtm-table
+ type: u8
+ -
+ name: rtm-protocol
+ type: u8
+ -
+ name: rtm-scope
+ type: u8
+ -
+ name: rtm-type
+ type: u8
+ enum: rtm-type
+ -
+ name: rtm-flags
+ type: u32
+ -
+ name: rta-cacheinfo
+ type: struct
+ members:
+ -
+ name: rta-clntref
+ type: u32
+ -
+ name: rta-lastuse
+ type: u32
+ -
+ name: rta-expires
+ type: u32
+ -
+ name: rta-error
+ type: u32
+ -
+ name: rta-used
+ type: u32
+
+attribute-sets:
+ -
+ name: route-attrs
+ attributes:
+ -
+ name: rta-dst
+ type: binary
+ display-hint: ipv4
+ -
+ name: rta-src
+ type: binary
+ display-hint: ipv4
+ -
+ name: rta-iif
+ type: u32
+ -
+ name: rta-oif
+ type: u32
+ -
+ name: rta-gateway
+ type: binary
+ display-hint: ipv4
+ -
+ name: rta-priority
+ type: u32
+ -
+ name: rta-prefsrc
+ type: binary
+ display-hint: ipv4
+ -
+ name: rta-metrics
+ type: nest
+ nested-attributes: rta-metrics
+ -
+ name: rta-multipath
+ type: binary
+ -
+ name: rta-protoinfo # not used
+ type: binary
+ -
+ name: rta-flow
+ type: u32
+ -
+ name: rta-cacheinfo
+ type: binary
+ struct: rta-cacheinfo
+ -
+ name: rta-session # not used
+ type: binary
+ -
+ name: rta-mp-algo # not used
+ type: binary
+ -
+ name: rta-table
+ type: u32
+ -
+ name: rta-mark
+ type: u32
+ -
+ name: rta-mfc-stats
+ type: binary
+ -
+ name: rta-via
+ type: binary
+ -
+ name: rta-newdst
+ type: binary
+ -
+ name: rta-pref
+ type: u8
+ -
+ name: rta-encap-type
+ type: u16
+ -
+ name: rta-encap
+ type: binary # tunnel specific nest
+ -
+ name: rta-expires
+ type: u32
+ -
+ name: rta-pad
+ type: binary
+ -
+ name: rta-uid
+ type: u32
+ -
+ name: rta-ttl-propagate
+ type: u8
+ -
+ name: rta-ip-proto
+ type: u8
+ -
+ name: rta-sport
+ type: u16
+ -
+ name: rta-dport
+ type: u16
+ -
+ name: rta-nh-id
+ type: u32
+ -
+ name: rta-metrics
+ attributes:
+ -
+ name: rtax-unspec
+ type: unused
+ value: 0
+ -
+ name: rtax-lock
+ type: u32
+ -
+ name: rtax-mtu
+ type: u32
+ -
+ name: rtax-window
+ type: u32
+ -
+ name: rtax-rtt
+ type: u32
+ -
+ name: rtax-rttvar
+ type: u32
+ -
+ name: rtax-ssthresh
+ type: u32
+ -
+ name: rtax-cwnd
+ type: u32
+ -
+ name: rtax-advmss
+ type: u32
+ -
+ name: rtax-reordering
+ type: u32
+ -
+ name: rtax-hoplimit
+ type: u32
+ -
+ name: rtax-initcwnd
+ type: u32
+ -
+ name: rtax-features
+ type: u32
+ -
+ name: rtax-rto-min
+ type: u32
+ -
+ name: rtax-initrwnd
+ type: u32
+ -
+ name: rtax-quickack
+ type: u32
+ -
+ name: rtax-cc-algo
+ type: string
+ -
+ name: rtax-fastopen-no-cookie
+ type: u32
+
+operations:
+ enum-model: directional
+ list:
+ -
+ name: getroute
+ doc: Dump route information.
+ attribute-set: route-attrs
+ fixed-header: rtmsg
+ do:
+ request:
+ value: 26
+ attributes:
+ - rtm-family
+ - rta-src
+ - rtm-src-len
+ - rta-dst
+ - rtm-dst-len
+ - rta-iif
+ - rta-oif
+ - rta-ip-proto
+ - rta-sport
+ - rta-dport
+ - rta-mark
+ - rta-uid
+ reply:
+ value: 24
+ attributes: &all-route-attrs
+ - rtm-family
+ - rtm-dst-len
+ - rtm-src-len
+ - rtm-tos
+ - rtm-table
+ - rtm-protocol
+ - rtm-scope
+ - rtm-type
+ - rtm-flags
+ - rta-dst
+ - rta-src
+ - rta-iif
+ - rta-oif
+ - rta-gateway
+ - rta-priority
+ - rta-prefsrc
+ - rta-metrics
+ - rta-multipath
+ - rta-flow
+ - rta-cacheinfo
+ - rta-table
+ - rta-mark
+ - rta-mfc-stats
+ - rta-via
+ - rta-newdst
+ - rta-pref
+ - rta-encap-type
+ - rta-encap
+ - rta-expires
+ - rta-pad
+ - rta-uid
+ - rta-ttl-propagate
+ - rta-ip-proto
+ - rta-sport
+ - rta-dport
+ - rta-nh-id
+ dump:
+ request:
+ value: 26
+ attributes:
+ - rtm-family
+ reply:
+ value: 24
+ attributes: *all-route-attrs
+ -
+ name: newroute
+ doc: Create a new route
+ attribute-set: route-attrs
+ fixed-header: rtmsg
+ do:
+ request:
+ value: 24
+ attributes: *all-route-attrs
+ -
+ name: delroute
+ doc: Delete an existing route
+ attribute-set: route-attrs
+ fixed-header: rtmsg
+ do:
+ request:
+ value: 25
+ attributes: *all-route-attrs
diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
index 1cc35de..dceeb0d 100644
--- a/Documentation/networking/af_xdp.rst
+++ b/Documentation/networking/af_xdp.rst
@@ -462,8 +462,92 @@
Gets options from an XDP socket. The only one supported so far is
XDP_OPTIONS_ZEROCOPY which tells you if zero-copy is on or not.
+Multi-Buffer Support
+====================
+
+With multi-buffer support, programs using AF_XDP sockets can receive
+and transmit packets consisting of multiple buffers both in copy and
+zero-copy mode. For example, a packet can consist of two
+frames/buffers, one with the header and the other one with the data,
+or a 9K Ethernet jumbo frame can be constructed by chaining together
+three 4K frames.
+
+Some definitions:
+
+* A packet consists of one or more frames
+
+* A descriptor in one of the AF_XDP rings always refers to a single
+ frame. In the case the packet consists of a single frame, the
+ descriptor refers to the whole packet.
+
+To enable multi-buffer support for an AF_XDP socket, use the new bind
+flag XDP_USE_SG. If this is not provided, all multi-buffer packets
+will be dropped just as before. Note that the XDP program loaded also
+needs to be in multi-buffer mode. This can be accomplished by using
+"xdp.frags" as the section name of the XDP program used.
+
+To represent a packet consisting of multiple frames, a new flag called
+XDP_PKT_CONTD is introduced in the options field of the Rx and Tx
+descriptors. If it is true (1) the packet continues with the next
+descriptor and if it is false (0) it means this is the last descriptor
+of the packet. Why the reverse logic of end-of-packet (eop) flag found
+in many NICs? Just to preserve compatibility with non-multi-buffer
+applications that have this bit set to false for all packets on Rx,
+and the apps set the options field to zero for Tx, as anything else
+will be treated as an invalid descriptor.
+
+These are the semantics for producing packets onto AF_XDP Tx ring
+consisting of multiple frames:
+
+* When an invalid descriptor is found, all the other
+ descriptors/frames of this packet are marked as invalid and not
+ completed. The next descriptor is treated as the start of a new
+ packet, even if this was not the intent (because we cannot guess
+ the intent). As before, if your program is producing invalid
+ descriptors you have a bug that must be fixed.
+
+* Zero length descriptors are treated as invalid descriptors.
+
+* For copy mode, the maximum supported number of frames in a packet is
+ equal to CONFIG_MAX_SKB_FRAGS + 1. If it is exceeded, all
+ descriptors accumulated so far are dropped and treated as
+ invalid. To produce an application that will work on any system
+ regardless of this config setting, limit the number of frags to 18,
+ as the minimum value of the config is 17.
+
+* For zero-copy mode, the limit is up to what the NIC HW
+ supports. Usually at least five on the NICs we have checked. We
+ consciously chose to not enforce a rigid limit (such as
+ CONFIG_MAX_SKB_FRAGS + 1) for zero-copy mode, as it would have
+ resulted in copy actions under the hood to fit into what limit the
+ NIC supports. Kind of defeats the purpose of zero-copy mode. How to
+ probe for this limit is explained in the "probe for multi-buffer
+ support" section.
+
+On the Rx path in copy-mode, the xsk core copies the XDP data into
+multiple descriptors, if needed, and sets the XDP_PKT_CONTD flag as
+detailed before. Zero-copy mode works the same, though the data is not
+copied. When the application gets a descriptor with the XDP_PKT_CONTD
+flag set to one, it means that the packet consists of multiple buffers
+and it continues with the next buffer in the following
+descriptor. When a descriptor with XDP_PKT_CONTD == 0 is received, it
+means that this is the last buffer of the packet. AF_XDP guarantees
+that only a complete packet (all frames in the packet) is sent to the
+application. If there is not enough space in the AF_XDP Rx ring, all
+frames of the packet will be dropped.
+
+If application reads a batch of descriptors, using for example the libxdp
+interfaces, it is not guaranteed that the batch will end with a full
+packet. It might end in the middle of a packet and the rest of the
+buffers of that packet will arrive at the beginning of the next batch,
+since the libxdp interface does not read the whole ring (unless you
+have an enormous batch size or a very small ring size).
+
+An example program each for Rx and Tx multi-buffer support can be found
+later in this document.
+
Usage
-=====
+-----
In order to use AF_XDP sockets two parts are needed. The
user-space application and the XDP program. For a complete setup and
@@ -541,6 +625,131 @@
But please use the libbpf functions as they are optimized and ready to
use. Will make your life easier.
+Usage Multi-Buffer Rx
+---------------------
+
+Here is a simple Rx path pseudo-code example (using libxdp interfaces
+for simplicity). Error paths have been excluded to keep it short:
+
+.. code-block:: c
+
+ void rx_packets(struct xsk_socket_info *xsk)
+ {
+ static bool new_packet = true;
+ u32 idx_rx = 0, idx_fq = 0;
+ static char *pkt;
+
+ int rcvd = xsk_ring_cons__peek(&xsk->rx, opt_batch_size, &idx_rx);
+
+ xsk_ring_prod__reserve(&xsk->umem->fq, rcvd, &idx_fq);
+
+ for (int i = 0; i < rcvd; i++) {
+ struct xdp_desc *desc = xsk_ring_cons__rx_desc(&xsk->rx, idx_rx++);
+ char *frag = xsk_umem__get_data(xsk->umem->buffer, desc->addr);
+ bool eop = !(desc->options & XDP_PKT_CONTD);
+
+ if (new_packet)
+ pkt = frag;
+ else
+ add_frag_to_pkt(pkt, frag);
+
+ if (eop)
+ process_pkt(pkt);
+
+ new_packet = eop;
+
+ *xsk_ring_prod__fill_addr(&xsk->umem->fq, idx_fq++) = desc->addr;
+ }
+
+ xsk_ring_prod__submit(&xsk->umem->fq, rcvd);
+ xsk_ring_cons__release(&xsk->rx, rcvd);
+ }
+
+Usage Multi-Buffer Tx
+---------------------
+
+Here is an example Tx path pseudo-code (using libxdp interfaces for
+simplicity) ignoring that the umem is finite in size, and that we
+eventually will run out of packets to send. Also assumes pkts.addr
+points to a valid location in the umem.
+
+.. code-block:: c
+
+ void tx_packets(struct xsk_socket_info *xsk, struct pkt *pkts,
+ int batch_size)
+ {
+ u32 idx, i, pkt_nb = 0;
+
+ xsk_ring_prod__reserve(&xsk->tx, batch_size, &idx);
+
+ for (i = 0; i < batch_size;) {
+ u64 addr = pkts[pkt_nb].addr;
+ u32 len = pkts[pkt_nb].size;
+
+ do {
+ struct xdp_desc *tx_desc;
+
+ tx_desc = xsk_ring_prod__tx_desc(&xsk->tx, idx + i++);
+ tx_desc->addr = addr;
+
+ if (len > xsk_frame_size) {
+ tx_desc->len = xsk_frame_size;
+ tx_desc->options = XDP_PKT_CONTD;
+ } else {
+ tx_desc->len = len;
+ tx_desc->options = 0;
+ pkt_nb++;
+ }
+ len -= tx_desc->len;
+ addr += xsk_frame_size;
+
+ if (i == batch_size) {
+ /* Remember len, addr, pkt_nb for next iteration.
+ * Skipped for simplicity.
+ */
+ break;
+ }
+ } while (len);
+ }
+
+ xsk_ring_prod__submit(&xsk->tx, i);
+ }
+
+Probing for Multi-Buffer Support
+--------------------------------
+
+To discover if a driver supports multi-buffer AF_XDP in SKB or DRV
+mode, use the XDP_FEATURES feature of netlink in linux/netdev.h to
+query for NETDEV_XDP_ACT_RX_SG support. This is the same flag as for
+querying for XDP multi-buffer support. If XDP supports multi-buffer in
+a driver, then AF_XDP will also support that in SKB and DRV mode.
+
+To discover if a driver supports multi-buffer AF_XDP in zero-copy
+mode, use XDP_FEATURES and first check the NETDEV_XDP_ACT_XSK_ZEROCOPY
+flag. If it is set, it means that at least zero-copy is supported and
+you should go and check the netlink attribute
+NETDEV_A_DEV_XDP_ZC_MAX_SEGS in linux/netdev.h. An unsigned integer
+value will be returned stating the max number of frags that are
+supported by this device in zero-copy mode. These are the possible
+return values:
+
+1: Multi-buffer for zero-copy is not supported by this device, as max
+ one fragment supported means that multi-buffer is not possible.
+
+>=2: Multi-buffer is supported in zero-copy mode for this device. The
+ returned number signifies the max number of frags supported.
+
+For an example on how these are used through libbpf, please take a
+look at tools/testing/selftests/bpf/xskxceiver.c.
+
+Multi-Buffer Support for Zero-Copy Drivers
+------------------------------------------
+
+Zero-copy drivers usually use the batched APIs for Rx and Tx
+processing. Note that the Tx batch API guarantees that it will provide
+a batch of Tx descriptors that ends with full packet at the end. This
+to facilitate extending a zero-copy driver with multi-buffer support.
+
Sample application
==================
diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst
index 28925e1..f7a7342 100644
--- a/Documentation/networking/bonding.rst
+++ b/Documentation/networking/bonding.rst
@@ -1636,7 +1636,7 @@
-----------------------------------------
This section applies to distros which use /etc/network/interfaces file
-to describe network interface configuration, most notably Debian and it's
+to describe network interface configuration, most notably Debian and its
derivatives.
The ifup and ifdown commands on Debian don't support bonding out of
diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst
new file mode 100644
index 0000000..7a6bc84
--- /dev/null
+++ b/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. note: can be edited and viewed with /usr/bin/formiko-vim
+
+==========================================================
+PCI VFIO driver for the AMD/Pensando(R) DSC adapter family
+==========================================================
+
+AMD/Pensando Linux VFIO PCI Device Driver
+Copyright(c) 2023 Advanced Micro Devices, Inc.
+
+Overview
+========
+
+The ``pds-vfio-pci`` module is a PCI driver that supports Live Migration
+capable Virtual Function (VF) devices in the DSC hardware.
+
+Using the device
+================
+
+The pds-vfio-pci device is enabled via multiple configuration steps and
+depends on the ``pds_core`` driver to create and enable SR-IOV Virtual
+Function devices.
+
+Shown below are the steps to bind the driver to a VF and also to the
+associated auxiliary device created by the ``pds_core`` driver. This
+example assumes the pds_core and pds-vfio-pci modules are already
+loaded.
+
+.. code-block:: bash
+ :name: example-setup-script
+
+ #!/bin/bash
+
+ PF_BUS="0000:60"
+ PF_BDF="0000:60:00.0"
+ VF_BDF="0000:60:00.1"
+
+ # Prevent non-vfio VF driver from probing the VF device
+ echo 0 > /sys/class/pci_bus/$PF_BUS/device/$PF_BDF/sriov_drivers_autoprobe
+
+ # Create single VF for Live Migration via pds_core
+ echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs
+
+ # Allow the VF to be bound to the pds-vfio-pci driver
+ echo "pds-vfio-pci" > /sys/class/pci_bus/$PF_BUS/device/$VF_BDF/driver_override
+
+ # Bind the VF to the pds-vfio-pci driver
+ echo "$VF_BDF" > /sys/bus/pci/drivers/pds-vfio-pci/bind
+
+After performing the steps above, a file in /dev/vfio/<iommu_group>
+should have been created.
+
+
+Enabling the driver
+===================
+
+The driver is enabled via the standard kernel configuration system,
+using the make command::
+
+ make oldconfig/menuconfig/etc.
+
+The driver is located in the menu structure at:
+
+ -> Device Drivers
+ -> VFIO Non-Privileged userspace driver framework
+ -> VFIO support for PDS PCI devices
+
+Support
+=======
+
+For general Linux networking support, please use the netdev mailing
+list, which is monitored by Pensando personnel::
+
+ netdev@vger.kernel.org
+
+For more specific support needs, please use the Pensando driver support
+email::
+
+ drivers@pensando.io
diff --git a/Documentation/networking/device_drivers/ethernet/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst
index 6d73ee7..31d621b 100644
--- a/Documentation/networking/device_drivers/ethernet/google/gve.rst
+++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst
@@ -52,6 +52,15 @@
GVE supports two descriptor formats: GQI and DQO. These two formats have
entirely different descriptors, which will be described below.
+Addressing Mode
+------------------
+GVE supports two addressing modes: QPL and RDA.
+QPL ("queue-page-list") mode communicates data through a set of
+pre-registered pages.
+
+For RDA ("raw DMA addressing") mode, the set of pages is dynamic.
+Therefore, the packet buffers can be anywhere in guest memory.
+
Registers
---------
All registers are MMIO.
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst
index 94ecb67..9827e81 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -16,6 +16,7 @@
altera/altera_tse
amd/pds_core
amd/pds_vdpa
+ amd/pds_vfio_pci
aquantia/atlantic
chelsio/cxgb
cirrus/cs89x0
diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
index bfd233c..1e196cb 100644
--- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
+++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
@@ -332,3 +332,11 @@
# tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 1
# tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 7
+
+4. Create tc classes with same priorities and different quantum::
+
+ # tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 2 quantum 409600
+
+ # tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 2 quantum 188416
+
+ # tc class add dev <interface> parent 1: classid 1:3 htb rate 10Gbit prio 2 quantum 32768
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
index a395df9..f69ee1e 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
@@ -346,6 +346,24 @@
- The number of receive packets with CQE compression on ring i [#accel]_.
- Acceleration
+ * - `rx[i]_arfs_add`
+ - The number of aRFS flow rules added to the device for direct RQ steering
+ on ring i [#accel]_.
+ - Acceleration
+
+ * - `rx[i]_arfs_request_in`
+ - Number of flow rules that have been requested to move into ring i for
+ direct RQ steering [#accel]_.
+ - Acceleration
+
+ * - `rx[i]_arfs_request_out`
+ - Number of flow rules that have been requested to move out of ring i [#accel]_.
+ - Acceleration
+
+ * - `rx[i]_arfs_expired`
+ - Number of flow rules that have been expired and removed [#accel]_.
+ - Acceleration
+
* - `rx[i]_arfs_err`
- Number of flow rules that failed to be added to the flow table.
- Error
@@ -445,11 +463,6 @@
context.
- Error
- * - `rx[i]_xsk_arfs_err`
- - aRFS (accelerated Receive Flow Steering) does not occur in the XSK RQ
- context, so this counter should never increment.
- - Error
-
* - `rx[i]_xdp_tx_xmit`
- The number of packets forwarded back to the port due to XDP program
`XDP_TX` action (bouncing). these packets are not counted by other
@@ -683,6 +696,12 @@
time protocol.
- Error
+ * - `ptp_cq[i]_late_cqe`
+ - Number of times a CQE has been delivered on the PTP timestamping CQ when
+ the CQE was not expected since a certain amount of time had elapsed where
+ the device typically ensures not posting the CQE.
+ - Error
+
.. [#ring_global] The corresponding ring and global counters do not share the
same name (i.e. do not follow the common naming scheme).
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst
deleted file mode 100644
index a4edf90..0000000
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst
+++ /dev/null
@@ -1,313 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
-.. include:: <isonum.txt>
-
-=======
-Devlink
-=======
-
-:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
-
-Contents
-========
-
-- `Info`_
-- `Parameters`_
-- `Health reporters`_
-
-Info
-====
-
-The devlink info reports the running and stored firmware versions on device.
-It also prints the device PSID which represents the HCA board type ID.
-
-User command example::
-
- $ devlink dev info pci/0000:00:06.0
- pci/0000:00:06.0:
- driver mlx5_core
- versions:
- fixed:
- fw.psid MT_0000000009
- running:
- fw.version 16.26.0100
- stored:
- fw.version 16.26.0100
-
-Parameters
-==========
-
-flow_steering_mode: Device flow steering mode
----------------------------------------------
-The flow steering mode parameter controls the flow steering mode of the driver.
-Two modes are supported:
-
-1. 'dmfs' - Device managed flow steering.
-2. 'smfs' - Software/Driver managed flow steering.
-
-In DMFS mode, the HW steering entities are created and managed through the
-Firmware.
-In SMFS mode, the HW steering entities are created and managed though by
-the driver directly into hardware without firmware intervention.
-
-SMFS mode is faster and provides better rule insertion rate compared to default DMFS mode.
-
-User command examples:
-
-- Set SMFS flow steering mode::
-
- $ devlink dev param set pci/0000:06:00.0 name flow_steering_mode value "smfs" cmode runtime
-
-- Read device flow steering mode::
-
- $ devlink dev param show pci/0000:06:00.0 name flow_steering_mode
- pci/0000:06:00.0:
- name flow_steering_mode type driver-specific
- values:
- cmode runtime value smfs
-
-enable_roce: RoCE enablement state
-----------------------------------
-If the device supports RoCE disablement, RoCE enablement state controls device
-support for RoCE capability. Otherwise, the control occurs in the driver stack.
-When RoCE is disabled at the driver level, only raw ethernet QPs are supported.
-
-To change RoCE enablement state, a user must change the driverinit cmode value
-and run devlink reload.
-
-User command examples:
-
-- Disable RoCE::
-
- $ devlink dev param set pci/0000:06:00.0 name enable_roce value false cmode driverinit
- $ devlink dev reload pci/0000:06:00.0
-
-- Read RoCE enablement state::
-
- $ devlink dev param show pci/0000:06:00.0 name enable_roce
- pci/0000:06:00.0:
- name enable_roce type generic
- values:
- cmode driverinit value true
-
-esw_port_metadata: Eswitch port metadata state
-----------------------------------------------
-When applicable, disabling eswitch metadata can increase packet rate
-up to 20% depending on the use case and packet sizes.
-
-Eswitch port metadata state controls whether to internally tag packets with
-metadata. Metadata tagging must be enabled for multi-port RoCE, failover
-between representors and stacked devices.
-By default metadata is enabled on the supported devices in E-switch.
-Metadata is applicable only for E-switch in switchdev mode and
-users may disable it when NONE of the below use cases will be in use:
-
-1. HCA is in Dual/multi-port RoCE mode.
-2. VF/SF representor bonding (Usually used for Live migration)
-3. Stacked devices
-
-When metadata is disabled, the above use cases will fail to initialize if
-users try to enable them.
-
-- Show eswitch port metadata::
-
- $ devlink dev param show pci/0000:06:00.0 name esw_port_metadata
- pci/0000:06:00.0:
- name esw_port_metadata type driver-specific
- values:
- cmode runtime value true
-
-- Disable eswitch port metadata::
-
- $ devlink dev param set pci/0000:06:00.0 name esw_port_metadata value false cmode runtime
-
-- Change eswitch mode to switchdev mode where after choosing the metadata value::
-
- $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
-
-hairpin_num_queues: Number of hairpin queues
---------------------------------------------
-We refer to a TC NIC rule that involves forwarding as "hairpin".
-
-Hairpin queues are mlx5 hardware specific implementation for hardware
-forwarding of such packets.
-
-- Show the number of hairpin queues::
-
- $ devlink dev param show pci/0000:06:00.0 name hairpin_num_queues
- pci/0000:06:00.0:
- name hairpin_num_queues type driver-specific
- values:
- cmode driverinit value 2
-
-- Change the number of hairpin queues::
-
- $ devlink dev param set pci/0000:06:00.0 name hairpin_num_queues value 4 cmode driverinit
-
-hairpin_queue_size: Size of the hairpin queues
-----------------------------------------------
-Control the size of the hairpin queues.
-
-- Show the size of the hairpin queues::
-
- $ devlink dev param show pci/0000:06:00.0 name hairpin_queue_size
- pci/0000:06:00.0:
- name hairpin_queue_size type driver-specific
- values:
- cmode driverinit value 1024
-
-- Change the size (in packets) of the hairpin queues::
-
- $ devlink dev param set pci/0000:06:00.0 name hairpin_queue_size value 512 cmode driverinit
-
-Health reporters
-================
-
-tx reporter
------------
-The tx reporter is responsible for reporting and recovering of the following two error scenarios:
-
-- tx timeout
- Report on kernel tx timeout detection.
- Recover by searching lost interrupts.
-- tx error completion
- Report on error tx completion.
- Recover by flushing the tx queue and reset it.
-
-tx reporter also support on demand diagnose callback, on which it provides
-real time information of its send queues status.
-
-User commands examples:
-
-- Diagnose send queues status::
-
- $ devlink health diagnose pci/0000:82:00.0 reporter tx
-
-.. note::
- This command has valid output only when interface is up, otherwise the command has empty output.
-
-- Show number of tx errors indicated, number of recover flows ended successfully,
- is autorecover enabled and graceful period from last recover::
-
- $ devlink health show pci/0000:82:00.0 reporter tx
-
-rx reporter
------------
-The rx reporter is responsible for reporting and recovering of the following two error scenarios:
-
-- rx queues' initialization (population) timeout
- Population of rx queues' descriptors on ring initialization is done
- in napi context via triggering an irq. In case of a failure to get
- the minimum amount of descriptors, a timeout would occur, and
- descriptors could be recovered by polling the EQ (Event Queue).
-- rx completions with errors (reported by HW on interrupt context)
- Report on rx completion error.
- Recover (if needed) by flushing the related queue and reset it.
-
-rx reporter also supports on demand diagnose callback, on which it
-provides real time information of its receive queues' status.
-
-- Diagnose rx queues' status and corresponding completion queue::
-
- $ devlink health diagnose pci/0000:82:00.0 reporter rx
-
-NOTE: This command has valid output only when interface is up. Otherwise, the command has empty output.
-
-- Show number of rx errors indicated, number of recover flows ended successfully,
- is autorecover enabled, and graceful period from last recover::
-
- $ devlink health show pci/0000:82:00.0 reporter rx
-
-fw reporter
------------
-The fw reporter implements `diagnose` and `dump` callbacks.
-It follows symptoms of fw error such as fw syndrome by triggering
-fw core dump and storing it into the dump buffer.
-The fw reporter diagnose command can be triggered any time by the user to check
-current fw status.
-
-User commands examples:
-
-- Check fw heath status::
-
- $ devlink health diagnose pci/0000:82:00.0 reporter fw
-
-- Read FW core dump if already stored or trigger new one::
-
- $ devlink health dump show pci/0000:82:00.0 reporter fw
-
-.. note::
- This command can run only on the PF which has fw tracer ownership,
- running it on other PF or any VF will return "Operation not permitted".
-
-fw fatal reporter
------------------
-The fw fatal reporter implements `dump` and `recover` callbacks.
-It follows fatal errors indications by CR-space dump and recover flow.
-The CR-space dump uses vsc interface which is valid even if the FW command
-interface is not functional, which is the case in most FW fatal errors.
-The recover function runs recover flow which reloads the driver and triggers fw
-reset if needed.
-On firmware error, the health buffer is dumped into the dmesg. The log
-level is derived from the error's severity (given in health buffer).
-
-User commands examples:
-
-- Run fw recover flow manually::
-
- $ devlink health recover pci/0000:82:00.0 reporter fw_fatal
-
-- Read FW CR-space dump if already stored or trigger new one::
-
- $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal
-
-.. note::
- This command can run only on PF.
-
-vnic reporter
--------------
-The vnic reporter implements only the `diagnose` callback.
-It is responsible for querying the vnic diagnostic counters from fw and displaying
-them in realtime.
-
-Description of the vnic counters:
-
-- total_q_under_processor_handle
- number of queues in an error state due to
- an async error or errored command.
-- send_queue_priority_update_flow
- number of QP/SQ priority/SL update events.
-- cq_overrun
- number of times CQ entered an error state due to an overflow.
-- async_eq_overrun
- number of times an EQ mapped to async events was overrun.
- comp_eq_overrun number of times an EQ mapped to completion events was
- overrun.
-- quota_exceeded_command
- number of commands issued and failed due to quota exceeded.
-- invalid_command
- number of commands issued and failed dues to any reason other than quota
- exceeded.
-- nic_receive_steering_discard
- number of packets that completed RX flow
- steering but were discarded due to a mismatch in flow table.
-- generated_pkt_steering_fail
- number of packets generated by the VNIC experiencing unexpected steering
- failure (at any point in steering flow).
-- handled_pkt_steering_fail
- number of packets handled by the VNIC experiencing unexpected steering
- failure (at any point in steering flow owned by the VNIC, including the FDB
- for the eswitch owner).
-
-User commands examples:
-
-- Diagnose PF/VF vnic counters::
-
- $ devlink health diagnose pci/0000:82:00.1 reporter vnic
-
-- Diagnose representor vnic counters (performed by supplying devlink port of the
- representor, which can be obtained via devlink port command)::
-
- $ devlink health diagnose pci/0000:82:00.1/65537 reporter vnic
-
-.. note::
- This command can run over all interfaces such as PF/VF and representor ports.
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst
index 3fdcd6b..581a91c 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst
@@ -13,7 +13,6 @@
:maxdepth: 2
kconfig
- devlink
switchdev
tracepoints
counters
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
index 43b1f7e8..0a42c33 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
@@ -36,7 +36,7 @@
**CONFIG_MLX5_CORE_EN_DCB=(y/n)**:
-| Enables `Data Center Bridging (DCB) Support <https://community.mellanox.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_.
+| Enables `Data Center Bridging (DCB) Support <https://enterprise-support.nvidia.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_.
**CONFIG_MLX5_CORE_IPOIB=(y/n)**
@@ -59,12 +59,12 @@
**CONFIG_MLX5_EN_ARFS=(y/n)**
| Enables Hardware-accelerated receive flow steering (arfs) support, and ntuple filtering.
-| https://community.mellanox.com/s/article/howto-configure-arfs-on-connectx-4
+| https://enterprise-support.nvidia.com/s/article/howto-configure-arfs-on-connectx-4
**CONFIG_MLX5_EN_IPSEC=(y/n)**
-| Enables `IPSec XFRM cryptography-offload acceleration <https://support.mellanox.com/s/article/ConnectX-6DX-Bluefield-2-IPsec-HW-Full-Offload-Configuration-Guide>`_.
+| Enables :ref:`IPSec XFRM cryptography-offload acceleration <xfrm_device>`.
**CONFIG_MLX5_EN_MACSEC=(y/n)**
@@ -87,8 +87,8 @@
| Ethernet SRIOV E-Switch support in ConnectX NIC. E-Switch provides internal SRIOV packet steering
| and switching for the enabled VFs and PF in two available modes:
-| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://community.mellanox.com/s/article/howto-configure-sr-iov-for-connectx-4-connectx-5-with-kvm--ethernet-x>`_.
-| 2) `Switchdev mode (eswitch offloads) <https://www.mellanox.com/related-docs/prod_software/ASAP2_Hardware_Offloading_for_vSwitches_User_Manual_v4.4.pdf>`_.
+| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://enterprise-support.nvidia.com/s/article/HowTo-Configure-SR-IOV-for-ConnectX-4-ConnectX-5-ConnectX-6-with-KVM-Ethernet>`_.
+| 2) :ref:`Switchdev mode (eswitch offloads) <switchdev>`.
**CONFIG_MLX5_FPGA=(y/n)**
@@ -101,13 +101,13 @@
**CONFIG_MLX5_INFINIBAND=(y/n/m)** (module mlx5_ib.ko)
-| Provides low-level InfiniBand/RDMA and `RoCE <https://community.mellanox.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support.
+| Provides low-level InfiniBand/RDMA and `RoCE <https://enterprise-support.nvidia.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support.
**CONFIG_MLX5_MPFS=(y/n)**
| Ethernet Multi-Physical Function Switch (MPFS) support in ConnectX NIC.
-| MPFs is required for when `Multi-Host <http://www.mellanox.com/page/multihost>`_ configuration is enabled to allow passing
+| MPFs is required for when `Multi-Host <https://www.nvidia.com/en-us/networking/multi-host/>`_ configuration is enabled to allow passing
| user configured unicast MAC addresses to the requesting PF.
diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
index 6e3f5ee..b617e93 100644
--- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
+++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
@@ -190,6 +190,26 @@
mlx5 driver support devlink port function attr mechanism to setup migratable
capability. (refer to Documentation/networking/devlink/devlink-port.rst)
+IPsec crypto capability setup
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+User who wants mlx5 PCI VFs to be able to perform IPsec crypto offloading need
+to explicitly enable the VF ipsec_crypto capability. Enabling IPsec capability
+for VFs is supported starting with ConnectX6dx devices and above. When a VF has
+IPsec capability enabled, any IPsec offloading is blocked on the PF.
+
+mlx5 driver support devlink port function attr mechanism to setup ipsec_crypto
+capability. (refer to Documentation/networking/devlink/devlink-port.rst)
+
+IPsec packet capability setup
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+User who wants mlx5 PCI VFs to be able to perform IPsec packet offloading need
+to explicitly enable the VF ipsec_packet capability. Enabling IPsec capability
+for VFs is supported starting with ConnectX6dx devices and above. When a VF has
+IPsec capability enabled, any IPsec offloading is blocked on the PF.
+
+mlx5 driver support devlink port function attr mechanism to setup ipsec_packet
+capability. (refer to Documentation/networking/devlink/devlink-port.rst)
+
SF state setup
--------------
diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst
index 3da5909..e33ad24 100644
--- a/Documentation/networking/devlink/devlink-port.rst
+++ b/Documentation/networking/devlink/devlink-port.rst
@@ -128,6 +128,12 @@
Users may also set the function as migratable using
'devlink port function set migratable' command.
+Users may also set the IPsec crypto capability of the function using
+`devlink port function set ipsec_crypto` command.
+
+Users may also set the IPsec packet capability of the function using
+`devlink port function set ipsec_packet` command.
+
Function attributes
===================
@@ -240,6 +246,55 @@
Start the VM.
Perform live migration.
+IPsec crypto capability setup
+-----------------------------
+When user enables IPsec crypto capability for a VF, user application can offload
+XFRM state crypto operation (Encrypt/Decrypt) to this VF.
+
+When IPsec crypto capability is disabled (default) for a VF, the XFRM state is
+processed in software by the kernel.
+
+- Get IPsec crypto capability of the VF device::
+
+ $ devlink port show pci/0000:06:00.0/2
+ pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1
+ function:
+ hw_addr 00:00:00:00:00:00 ipsec_crypto disabled
+
+- Set IPsec crypto capability of the VF device::
+
+ $ devlink port function set pci/0000:06:00.0/2 ipsec_crypto enable
+
+ $ devlink port show pci/0000:06:00.0/2
+ pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1
+ function:
+ hw_addr 00:00:00:00:00:00 ipsec_crypto enabled
+
+IPsec packet capability setup
+-----------------------------
+When user enables IPsec packet capability for a VF, user application can offload
+XFRM state and policy crypto operation (Encrypt/Decrypt) to this VF, as well as
+IPsec encapsulation.
+
+When IPsec packet capability is disabled (default) for a VF, the XFRM state and
+policy is processed in software by the kernel.
+
+- Get IPsec packet capability of the VF device::
+
+ $ devlink port show pci/0000:06:00.0/2
+ pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1
+ function:
+ hw_addr 00:00:00:00:00:00 ipsec_packet disabled
+
+- Set IPsec packet capability of the VF device::
+
+ $ devlink port function set pci/0000:06:00.0/2 ipsec_packet enable
+
+ $ devlink port show pci/0000:06:00.0/2
+ pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1
+ function:
+ hw_addr 00:00:00:00:00:00 ipsec_packet enabled
+
Subfunction
============
@@ -321,9 +376,9 @@
Allows for usage of Weighted Fair Queuing arbitration scheme among
siblings. This arbitration scheme can be used simultaneously with the
strict priority. As a node is configured with a higher rate it gets more
- BW relative to it's siblings. Values are relative like a percentage
+ BW relative to its siblings. Values are relative like a percentage
points, they basically tell how much BW should node take relative to
- it's siblings.
+ its siblings.
``parent``
Parent node name. Parent node rate limits are considered as additional limits
@@ -343,7 +398,7 @@
#. If group of nodes have the same priority perform WFQ arbitration on
that subgroup. Use ``tx_weight`` as a parameter for this arbitration.
-#. Select the winner node, and continue arbitration flow among it's children,
+#. Select the winner node, and continue arbitration flow among its children,
until leaf node is reached, and the winner is established.
#. If all the nodes from the highest priority sub-group are satisfied, or
diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst
index 202798d6..702f204 100644
--- a/Documentation/networking/devlink/mlx5.rst
+++ b/Documentation/networking/devlink/mlx5.rst
@@ -18,6 +18,11 @@
* - ``enable_roce``
- driverinit
- Type: Boolean
+
+ If the device supports RoCE disablement, RoCE enablement state controls
+ device support for RoCE capability. Otherwise, the control occurs in the
+ driver stack. When RoCE is disabled at the driver level, only raw
+ ethernet QPs are supported.
* - ``io_eq_size``
- driverinit
- The range is between 64 and 4096.
@@ -48,6 +53,9 @@
* ``smfs`` Software managed flow steering. In SMFS mode, the HW
steering entities are created and manage through the driver without
firmware intervention.
+
+ SMFS mode is faster and provides better rule insertion rate compared to
+ default DMFS mode.
* - ``fdb_large_groups``
- u32
- driverinit
@@ -71,7 +79,24 @@
deprecated.
Default: disabled
+ * - ``esw_port_metadata``
+ - Boolean
+ - runtime
+ - When applicable, disabling eswitch metadata can increase packet rate up
+ to 20% depending on the use case and packet sizes.
+ Eswitch port metadata state controls whether to internally tag packets
+ with metadata. Metadata tagging must be enabled for multi-port RoCE,
+ failover between representors and stacked devices. By default metadata is
+ enabled on the supported devices in E-switch. Metadata is applicable only
+ for E-switch in switchdev mode and users may disable it when NONE of the
+ below use cases will be in use:
+ 1. HCA is in Dual/multi-port RoCE mode.
+ 2. VF/SF representor bonding (Usually used for Live migration)
+ 3. Stacked devices
+
+ When metadata is disabled, the above use cases will fail to initialize if
+ users try to enable them.
* - ``hairpin_num_queues``
- u32
- driverinit
@@ -104,3 +129,160 @@
* - ``fw.version``
- stored, running
- Three digit major.minor.subminor firmware version number.
+
+Health reporters
+================
+
+tx reporter
+-----------
+The tx reporter is responsible for reporting and recovering of the following three error scenarios:
+
+- tx timeout
+ Report on kernel tx timeout detection.
+ Recover by searching lost interrupts.
+- tx error completion
+ Report on error tx completion.
+ Recover by flushing the tx queue and reset it.
+- tx PTP port timestamping CQ unhealthy
+ Report too many CQEs never delivered on port ts CQ.
+ Recover by flushing and re-creating all PTP channels.
+
+tx reporter also support on demand diagnose callback, on which it provides
+real time information of its send queues status.
+
+User commands examples:
+
+- Diagnose send queues status::
+
+ $ devlink health diagnose pci/0000:82:00.0 reporter tx
+
+.. note::
+ This command has valid output only when interface is up, otherwise the command has empty output.
+
+- Show number of tx errors indicated, number of recover flows ended successfully,
+ is autorecover enabled and graceful period from last recover::
+
+ $ devlink health show pci/0000:82:00.0 reporter tx
+
+rx reporter
+-----------
+The rx reporter is responsible for reporting and recovering of the following two error scenarios:
+
+- rx queues' initialization (population) timeout
+ Population of rx queues' descriptors on ring initialization is done
+ in napi context via triggering an irq. In case of a failure to get
+ the minimum amount of descriptors, a timeout would occur, and
+ descriptors could be recovered by polling the EQ (Event Queue).
+- rx completions with errors (reported by HW on interrupt context)
+ Report on rx completion error.
+ Recover (if needed) by flushing the related queue and reset it.
+
+rx reporter also supports on demand diagnose callback, on which it
+provides real time information of its receive queues' status.
+
+- Diagnose rx queues' status and corresponding completion queue::
+
+ $ devlink health diagnose pci/0000:82:00.0 reporter rx
+
+.. note::
+ This command has valid output only when interface is up. Otherwise, the command has empty output.
+
+- Show number of rx errors indicated, number of recover flows ended successfully,
+ is autorecover enabled, and graceful period from last recover::
+
+ $ devlink health show pci/0000:82:00.0 reporter rx
+
+fw reporter
+-----------
+The fw reporter implements `diagnose` and `dump` callbacks.
+It follows symptoms of fw error such as fw syndrome by triggering
+fw core dump and storing it into the dump buffer.
+The fw reporter diagnose command can be triggered any time by the user to check
+current fw status.
+
+User commands examples:
+
+- Check fw heath status::
+
+ $ devlink health diagnose pci/0000:82:00.0 reporter fw
+
+- Read FW core dump if already stored or trigger new one::
+
+ $ devlink health dump show pci/0000:82:00.0 reporter fw
+
+.. note::
+ This command can run only on the PF which has fw tracer ownership,
+ running it on other PF or any VF will return "Operation not permitted".
+
+fw fatal reporter
+-----------------
+The fw fatal reporter implements `dump` and `recover` callbacks.
+It follows fatal errors indications by CR-space dump and recover flow.
+The CR-space dump uses vsc interface which is valid even if the FW command
+interface is not functional, which is the case in most FW fatal errors.
+The recover function runs recover flow which reloads the driver and triggers fw
+reset if needed.
+On firmware error, the health buffer is dumped into the dmesg. The log
+level is derived from the error's severity (given in health buffer).
+
+User commands examples:
+
+- Run fw recover flow manually::
+
+ $ devlink health recover pci/0000:82:00.0 reporter fw_fatal
+
+- Read FW CR-space dump if already stored or trigger new one::
+
+ $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal
+
+.. note::
+ This command can run only on PF.
+
+vnic reporter
+-------------
+The vnic reporter implements only the `diagnose` callback.
+It is responsible for querying the vnic diagnostic counters from fw and displaying
+them in realtime.
+
+Description of the vnic counters:
+
+- total_q_under_processor_handle
+ number of queues in an error state due to
+ an async error or errored command.
+- send_queue_priority_update_flow
+ number of QP/SQ priority/SL update events.
+- cq_overrun
+ number of times CQ entered an error state due to an overflow.
+- async_eq_overrun
+ number of times an EQ mapped to async events was overrun.
+ comp_eq_overrun number of times an EQ mapped to completion events was
+ overrun.
+- quota_exceeded_command
+ number of commands issued and failed due to quota exceeded.
+- invalid_command
+ number of commands issued and failed dues to any reason other than quota
+ exceeded.
+- nic_receive_steering_discard
+ number of packets that completed RX flow
+ steering but were discarded due to a mismatch in flow table.
+- generated_pkt_steering_fail
+ number of packets generated by the VNIC experiencing unexpected steering
+ failure (at any point in steering flow).
+- handled_pkt_steering_fail
+ number of packets handled by the VNIC experiencing unexpected steering
+ failure (at any point in steering flow owned by the VNIC, including the FDB
+ for the eswitch owner).
+
+User commands examples:
+
+- Diagnose PF/VF vnic counters::
+
+ $ devlink health diagnose pci/0000:82:00.1 reporter vnic
+
+- Diagnose representor vnic counters (performed by supplying devlink port of the
+ representor, which can be obtained via devlink port command)::
+
+ $ devlink health diagnose pci/0000:82:00.1/65537 reporter vnic
+
+.. note::
+ This command can run over all interfaces such as PF/VF and representor ports.
diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst
index 4a010a7..a66054d 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -321,6 +321,7 @@
option can harm clients of your server.
tcp_adv_win_scale - INTEGER
+ Obsolete since linux-6.6
Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
@@ -2287,6 +2288,14 @@
Default: 1
+accept_ra_min_lft - INTEGER
+ Minimum acceptable lifetime value in Router Advertisement.
+
+ RA sections with a lifetime less than this value shall be
+ ignored. Zero lifetimes stay unaffected.
+
+ Default: 0
+
accept_ra_pinfo - BOOLEAN
Learn Prefix Information in Router Advertisement.
diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst
index 2135106..15f1919 100644
--- a/Documentation/networking/mptcp-sysctl.rst
+++ b/Documentation/networking/mptcp-sysctl.rst
@@ -74,3 +74,11 @@
This is a per-namespace sysctl.
Default: 4
+
+scheduler - STRING
+ Select the scheduler of your choice.
+
+ Support for selection of different schedulers. This is a per-namespace
+ sysctl.
+
+ Default: "default"
diff --git a/Documentation/networking/netconsole.rst b/Documentation/networking/netconsole.rst
index dd0518e..7a9de05 100644
--- a/Documentation/networking/netconsole.rst
+++ b/Documentation/networking/netconsole.rst
@@ -13,6 +13,8 @@
Extended console support by Tejun Heo <tj@kernel.org>, May 1 2015
+Release prepend support by Breno Leitao <leitao@debian.org>, Jul 7 2023
+
Please send bug reports to Matt Mackall <mpm@selenic.com>
Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com>
@@ -34,10 +36,11 @@
It takes a string configuration parameter "netconsole" in the
following format::
- netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
+ netconsole=[+][r][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
where
+ if present, enable extended console support
+ r if present, prepend kernel version (release) to the message
src-port source for UDP packets (defaults to 6665)
src-ip source IP to use (interface address)
dev network interface (eth0)
@@ -125,6 +128,7 @@
============== ================================= ============
enabled Is this target currently enabled? (read-write)
extended Extended mode enabled (read-write)
+ release Prepend kernel release to message (read-write)
dev_name Local network interface name (read-write)
local_port Source UDP port to use (read-write)
remote_port Remote agent's UDP port (read-write)
@@ -165,6 +169,11 @@
<level>,<sequnum>,<timestamp>,<contflag>;<message text>
+If 'r' (release) feature is enabled, the kernel release version is
+prepended to the start of the message. Example::
+
+ 6.4.0,6,444,501151268,-;netconsole: network logging started
+
Non printable characters in <message text> are escaped using "\xff"
notation. If the message contains optional dictionary, verbatim
newline is used as the delimiter.
diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst
index 8b1045c..c383a39 100644
--- a/Documentation/networking/nf_conntrack-sysctl.rst
+++ b/Documentation/networking/nf_conntrack-sysctl.rst
@@ -178,10 +178,10 @@
Default is set to (hb_interval * path_max_retrans + rto_max)
nf_conntrack_sctp_timeout_shutdown_sent - INTEGER (seconds)
- default 0.3
+ default 3
nf_conntrack_sctp_timeout_shutdown_recd - INTEGER (seconds)
- default 0.3
+ default 3
nf_conntrack_sctp_timeout_shutdown_ack_sent - INTEGER (seconds)
default 3
diff --git a/Documentation/networking/packet_mmap.rst b/Documentation/networking/packet_mmap.rst
index c5da1a5..30a3be3 100644
--- a/Documentation/networking/packet_mmap.rst
+++ b/Documentation/networking/packet_mmap.rst
@@ -755,7 +755,7 @@
============================
AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame
-sizes by doing it's own memory management. It is based on blocks where polling
+sizes by doing its own memory management. It is based on blocks where polling
works on a per block basis instead of per ring as in TPACKET_V2 and predecessor.
It is said that TPACKET_V3 brings the following benefits:
diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst
index 873efd9..215ebc9 100644
--- a/Documentation/networking/page_pool.rst
+++ b/Documentation/networking/page_pool.rst
@@ -4,22 +4,8 @@
Page Pool API
=============
-The page_pool allocator is optimized for the XDP mode that uses one frame
-per-page, but it can fallback on the regular page allocator APIs.
-
-Basic use involves replacing alloc_pages() calls with the
-page_pool_alloc_pages() call. Drivers should use page_pool_dev_alloc_pages()
-replacing dev_alloc_pages().
-
-API keeps track of in-flight pages, in order to let API user know
-when it is safe to free a page_pool object. Thus, API users
-must run page_pool_release_page() when a page is leaving the page_pool or
-call page_pool_put_page() where appropriate in order to maintain correct
-accounting.
-
-API user must call page_pool_put_page() once on a page, as it
-will either recycle the page, or in case of refcnt > 1, it will
-release the DMA mapping and in-flight state accounting.
+.. kernel-doc:: include/net/page_pool/helpers.h
+ :doc: page_pool allocator
Architecture overview
=====================
@@ -64,87 +50,68 @@
The protection doesn't strictly have to be NAPI, any guarantee that allocating
a page will cause no race conditions is enough.
-* page_pool_create(): Create a pool.
- * flags: PP_FLAG_DMA_MAP, PP_FLAG_DMA_SYNC_DEV
- * order: 2^order pages on allocation
- * pool_size: size of the ptr_ring
- * nid: preferred NUMA node for allocation
- * dev: struct device. Used on DMA operations
- * dma_dir: DMA direction
- * max_len: max DMA sync memory size
- * offset: DMA address offset
+.. kernel-doc:: net/core/page_pool.c
+ :identifiers: page_pool_create
-* page_pool_put_page(): The outcome of this depends on the page refcnt. If the
- driver bumps the refcnt > 1 this will unmap the page. If the page refcnt is 1
- the allocator owns the page and will try to recycle it in one of the pool
- caches. If PP_FLAG_DMA_SYNC_DEV is set, the page will be synced for_device
- using dma_sync_single_range_for_device().
+.. kernel-doc:: include/net/page_pool/types.h
+ :identifiers: struct page_pool_params
-* page_pool_put_full_page(): Similar to page_pool_put_page(), but will DMA sync
- for the entire memory area configured in area pool->max_len.
+.. kernel-doc:: include/net/page_pool/helpers.h
+ :identifiers: page_pool_put_page page_pool_put_full_page
+ page_pool_recycle_direct page_pool_dev_alloc_pages
+ page_pool_get_dma_addr page_pool_get_dma_dir
-* page_pool_recycle_direct(): Similar to page_pool_put_full_page() but caller
- must guarantee safe context (e.g NAPI), since it will recycle the page
- directly into the pool fast cache.
+.. kernel-doc:: net/core/page_pool.c
+ :identifiers: page_pool_put_page_bulk page_pool_get_stats
-* page_pool_release_page(): Unmap the page (if mapped) and account for it on
- in-flight counters.
+DMA sync
+--------
+Driver is always responsible for syncing the pages for the CPU.
+Drivers may choose to take care of syncing for the device as well
+or set the ``PP_FLAG_DMA_SYNC_DEV`` flag to request that pages
+allocated from the page pool are already synced for the device.
-* page_pool_dev_alloc_pages(): Get a page from the page allocator or page_pool
- caches.
+If ``PP_FLAG_DMA_SYNC_DEV`` is set, the driver must inform the core what portion
+of the buffer has to be synced. This allows the core to avoid syncing the entire
+page when the drivers knows that the device only accessed a portion of the page.
-* page_pool_get_dma_addr(): Retrieve the stored DMA address.
+Most drivers will reserve headroom in front of the frame. This part
+of the buffer is not touched by the device, so to avoid syncing
+it drivers can set the ``offset`` field in struct page_pool_params
+appropriately.
-* page_pool_get_dma_dir(): Retrieve the stored DMA direction.
+For pages recycled on the XDP xmit and skb paths the page pool will
+use the ``max_len`` member of struct page_pool_params to decide how
+much of the page needs to be synced (starting at ``offset``).
+When directly freeing pages in the driver (page_pool_put_page())
+the ``dma_sync_size`` argument specifies how much of the buffer needs
+to be synced.
-* 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.
+If in doubt set ``offset`` to 0, ``max_len`` to ``PAGE_SIZE`` and
+pass -1 as ``dma_sync_size``. That combination of arguments is always
+correct.
-* page_pool_get_stats(): Retrieve statistics about the page_pool. This API
- is only available if the kernel has been configured with
- ``CONFIG_PAGE_POOL_STATS=y``. A pointer to a caller allocated ``struct
- page_pool_stats`` structure is passed to this API which is filled in. The
- caller can then report those stats to the user (perhaps via ethtool,
- debugfs, etc.). See below for an example usage of this API.
+Note that the syncing parameters are for the entire page.
+This is important to remember when using fragments (``PP_FLAG_PAGE_FRAG``),
+where allocated buffers may be smaller than a full page.
+Unless the driver author really understands page pool internals
+it's recommended to always use ``offset = 0``, ``max_len = PAGE_SIZE``
+with fragmented page pools.
Stats API and structures
------------------------
If the kernel is configured with ``CONFIG_PAGE_POOL_STATS=y``, the API
-``page_pool_get_stats()`` and structures described below are available. It
-takes a pointer to a ``struct page_pool`` and a pointer to a ``struct
-page_pool_stats`` allocated by the caller.
+page_pool_get_stats() and structures described below are available.
+It takes a pointer to a ``struct page_pool`` and a pointer to a struct
+page_pool_stats allocated by the caller.
-The API will fill in the provided ``struct page_pool_stats`` with
+The API will fill in the provided struct page_pool_stats with
statistics about the page_pool.
-The stats structure has the following fields::
-
- struct page_pool_stats {
- struct page_pool_alloc_stats alloc_stats;
- struct page_pool_recycle_stats recycle_stats;
- };
-
-
-The ``struct page_pool_alloc_stats`` has the following fields:
- * ``fast``: successful fast path allocations
- * ``slow``: slow path order-0 allocations
- * ``slow_high_order``: slow path high order allocations
- * ``empty``: ptr ring is empty, so a slow path allocation was forced.
- * ``refill``: an allocation which triggered a refill of the cache
- * ``waive``: pages obtained from the ptr ring that cannot be added to
- the cache due to a NUMA mismatch.
-
-The ``struct page_pool_recycle_stats`` has the following fields:
- * ``cached``: recycling placed page in the page pool cache
- * ``cache_full``: page pool cache was full
- * ``ring``: page placed into the ptr ring
- * ``ring_full``: page released from page pool because the ptr ring was full
- * ``released_refcnt``: page released (and not recycled) because refcnt > 1
+.. kernel-doc:: include/net/page_pool/types.h
+ :identifiers: struct page_pool_recycle_stats
+ struct page_pool_alloc_stats
+ struct page_pool_stats
Coding examples
===============
@@ -194,7 +161,7 @@
if XDP_DROP:
page_pool_recycle_direct(page_pool, page);
} else (packet_is_skb) {
- page_pool_release_page(page_pool, page);
+ skb_mark_for_recycle(skb);
new_page = page_pool_dev_alloc_pages(page_pool);
}
}
diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst
index b7ac4c6..1283240 100644
--- a/Documentation/networking/phy.rst
+++ b/Documentation/networking/phy.rst
@@ -323,6 +323,10 @@
contrast with the 1000BASE-X phy mode used for Clause 38 and 39 PMDs, this
interface mode has different autonegotiation and only supports full duplex.
+``PHY_INTERFACE_MODE_PSGMII``
+ This is the Penta SGMII mode, it is similar to QSGMII but it combines 5
+ SGMII lines into a single link compared to 4 on QSGMII.
+
Pause frames / flow control
===========================
diff --git a/Documentation/networking/xfrm_device.rst b/Documentation/networking/xfrm_device.rst
index 83abdfe..535077cb 100644
--- a/Documentation/networking/xfrm_device.rst
+++ b/Documentation/networking/xfrm_device.rst
@@ -1,4 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
+.. _xfrm_device:
===============================================
XFRM device - offloading the IPsec computations
diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst
index ef341be2..1322596 100644
--- a/Documentation/power/energy-model.rst
+++ b/Documentation/power/energy-model.rst
@@ -87,9 +87,9 @@
Registration of 'advanced' EM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The 'advanced' EM gets it's name due to the fact that the driver is allowed
+The 'advanced' EM gets its name due to the fact that the driver is allowed
to provide more precised power model. It's not limited to some implemented math
-formula in the framework (like it's in 'simple' EM case). It can better reflect
+formula in the framework (like it is in 'simple' EM case). It can better reflect
the real power measurements performed for each performance state. Thus, this
registration method should be preferred in case considering EM static power
(leakage) is important.
diff --git a/Documentation/powerpc/dscr.rst b/Documentation/powerpc/dscr.rst
index 2ab9900..f735ec5 100644
--- a/Documentation/powerpc/dscr.rst
+++ b/Documentation/powerpc/dscr.rst
@@ -6,7 +6,7 @@
stream in the processor. Please refer to the ISA documents or related manual
for more detailed information regarding how to use this DSCR to attain this
control of the prefetches . This document here provides an overview of kernel
-support for DSCR, related kernel objects, it's functionalities and exported
+support for DSCR, related kernel objects, its functionalities and exported
user interface.
(A) Data Structures:
diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index d33b554..a508347 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -36,6 +36,7 @@
ultravisor
vas-api
vcpudispatch_stats
+ vmemmap_dedup
features
diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt
index f032b4e..a4f647e 100644
--- a/Documentation/powerpc/kasan.txt
+++ b/Documentation/powerpc/kasan.txt
@@ -40,7 +40,7 @@
instrument any code that runs with translations off after booting. This is the
current approach.
-To avoid this limitiation, the KASAN shadow would have to be placed inside the
+To avoid this limitation, the KASAN shadow would have to be placed inside the
linear mapping, using the same high-bits trick we use for the rest of the linear
mapping. This is tricky:
diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
index fce8bc79..80d2c0a 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/powerpc/papr_hcalls.rst
@@ -22,7 +22,7 @@
On PPC64 arch a guest kernel running on top of a PAPR hypervisor is called
a *pSeries guest*. A pseries guest runs in a supervisor mode (HV=0) and must
issue hypercalls to the hypervisor whenever it needs to perform an action
-that is hypervisor priviledged [3]_ or for other services managed by the
+that is hypervisor privileged [3]_ or for other services managed by the
hypervisor.
Hence a Hypercall (hcall) is essentially a request by the pseries guest
diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/powerpc/ptrace.rst
index 77725d6..5629edf 100644
--- a/Documentation/powerpc/ptrace.rst
+++ b/Documentation/powerpc/ptrace.rst
@@ -15,7 +15,7 @@
that GDB doesn't need to special-case each of them. We added the
following 3 new ptrace requests.
-1. PTRACE_PPC_GETHWDEBUGINFO
+1. PPC_PTRACE_GETHWDBGINFO
============================
Query for GDB to discover the hardware debug features. The main info to
@@ -48,7 +48,7 @@
#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
#define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 0x20
-2. PTRACE_SETHWDEBUG
+2. PPC_PTRACE_SETHWDEBUG
Sets a hardware breakpoint or watchpoint, according to the provided structure::
@@ -88,7 +88,7 @@
are not contemplated, but that is out of the scope of this work.
ptrace will return an integer (handle) uniquely identifying the breakpoint or
-watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
+watchpoint just created. This integer will be used in the PPC_PTRACE_DELHWDEBUG
request to ask for its removal. Return -ENOSPC if the requested breakpoint
can't be allocated on the registers.
@@ -150,7 +150,7 @@
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
-3. PTRACE_DELHWDEBUG
+3. PPC_PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
diff --git a/Documentation/powerpc/qe_firmware.rst b/Documentation/powerpc/qe_firmware.rst
index 42f5103..a358f15 100644
--- a/Documentation/powerpc/qe_firmware.rst
+++ b/Documentation/powerpc/qe_firmware.rst
@@ -232,11 +232,11 @@
'extended_modes' is a bitfield that defines special functionality which has an
impact on the device drivers. Each bit has its own impact and has special
instructions for the driver associated with it. This field is stored in
-the QE library and available to any driver that calles qe_get_firmware_info().
+the QE library and available to any driver that calls qe_get_firmware_info().
'vtraps' is an array of 8 words that contain virtual trap values for each
virtual traps. As with 'extended_modes', this field is stored in the QE
-library and available to any driver that calles qe_get_firmware_info().
+library and available to any driver that calls qe_get_firmware_info().
'microcode' (type: struct qe_microcode):
For each RISC processor there is one 'microcode' structure. The first
diff --git a/Documentation/powerpc/vas-api.rst b/Documentation/powerpc/vas-api.rst
index bdb50fe..a9625a2 100644
--- a/Documentation/powerpc/vas-api.rst
+++ b/Documentation/powerpc/vas-api.rst
@@ -46,7 +46,7 @@
The application can then submit one or more requests to the engine by
using copy/paste instructions and pasting the CRBs to the virtual address
(aka paste_address) returned by mmap(). User space can close the
-established connection or send window by closing the file descriptior
+established connection or send window by closing the file descriptor
(close(fd)) or upon the process exit.
Note that applications can send several requests with the same window or
@@ -240,7 +240,7 @@
siginfo.si_signo = SIGSEGV;
siginfo.si_errno = EFAULT;
siginfo.si_code = SEGV_MAPERR;
- siginfo.si_addr = CSB adress;
+ siginfo.si_addr = CSB address;
In the case of multi-thread applications, NX send windows can be shared
across all threads. For example, a child thread can open a send window,
diff --git a/Documentation/powerpc/vmemmap_dedup.rst b/Documentation/powerpc/vmemmap_dedup.rst
new file mode 100644
index 0000000..dc4db59
--- /dev/null
+++ b/Documentation/powerpc/vmemmap_dedup.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========
+Device DAX
+==========
+
+The device-dax interface uses the tail deduplication technique explained in
+Documentation/mm/vmemmap_dedup.rst
+
+On powerpc, vmemmap deduplication is only used with radix MMU translation. Also
+with a 64K page size, only the devdax namespace with 1G alignment uses vmemmap
+deduplication.
+
+With 2M PMD level mapping, we require 32 struct pages and a single 64K vmemmap
+page can contain 1024 struct pages (64K/sizeof(struct page)). Hence there is no
+vmemmap deduplication possible.
+
+With 1G PUD level mapping, we require 16384 struct pages and a single 64K
+vmemmap page can contain 1024 struct pages (64K/sizeof(struct page)). Hence we
+require 16 64K pages in vmemmap to map the struct page for 1G PUD level mapping.
+
+Here's how things look like on device-dax after the sections are populated::
+ +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
+ | | | 0 | -------------> | 0 |
+ | | +-----------+ +-----------+
+ | | | 1 | -------------> | 1 |
+ | | +-----------+ +-----------+
+ | | | 2 | ----------------^ ^ ^ ^ ^ ^
+ | | +-----------+ | | | | |
+ | | | 3 | ------------------+ | | | |
+ | | +-----------+ | | | |
+ | | | 4 | --------------------+ | | |
+ | PUD | +-----------+ | | |
+ | level | | . | ----------------------+ | |
+ | mapping | +-----------+ | |
+ | | | . | ------------------------+ |
+ | | +-----------+ |
+ | | | 15 | --------------------------+
+ | | +-----------+
+ | |
+ | |
+ | |
+ +-----------+
+
+
+With 4K page size, 2M PMD level mapping requires 512 struct pages and a single
+4K vmemmap page contains 64 struct pages(4K/sizeof(struct page)). Hence we
+require 8 4K pages in vmemmap to map the struct page for 2M pmd level mapping.
+
+Here's how things look like on device-dax after the sections are populated::
+
+ +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
+ | | | 0 | -------------> | 0 |
+ | | +-----------+ +-----------+
+ | | | 1 | -------------> | 1 |
+ | | +-----------+ +-----------+
+ | | | 2 | ----------------^ ^ ^ ^ ^ ^
+ | | +-----------+ | | | | |
+ | | | 3 | ------------------+ | | | |
+ | | +-----------+ | | | |
+ | | | 4 | --------------------+ | | |
+ | PMD | +-----------+ | | |
+ | level | | 5 | ----------------------+ | |
+ | mapping | +-----------+ | |
+ | | | 6 | ------------------------+ |
+ | | +-----------+ |
+ | | | 7 | --------------------------+
+ | | +-----------+
+ | |
+ | |
+ | |
+ +-----------+
+
+With 1G PUD level mapping, we require 262144 struct pages and a single 4K
+vmemmap page can contain 64 struct pages (4K/sizeof(struct page)). Hence we
+require 4096 4K pages in vmemmap to map the struct pages for 1G PUD level
+mapping.
+
+Here's how things look like on device-dax after the sections are populated::
+
+ +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
+ | | | 0 | -------------> | 0 |
+ | | +-----------+ +-----------+
+ | | | 1 | -------------> | 1 |
+ | | +-----------+ +-----------+
+ | | | 2 | ----------------^ ^ ^ ^ ^ ^
+ | | +-----------+ | | | | |
+ | | | 3 | ------------------+ | | | |
+ | | +-----------+ | | | |
+ | | | 4 | --------------------+ | | |
+ | PUD | +-----------+ | | |
+ | level | | . | ----------------------+ | |
+ | mapping | +-----------+ | |
+ | | | . | ------------------------+ |
+ | | +-----------+ |
+ | | | 4095 | --------------------------+
+ | | +-----------+
+ | |
+ | |
+ | |
+ +-----------+
diff --git a/Documentation/process/botching-up-ioctls.rst b/Documentation/process/botching-up-ioctls.rst
index 9739b88..a05e840 100644
--- a/Documentation/process/botching-up-ioctls.rst
+++ b/Documentation/process/botching-up-ioctls.rst
@@ -208,7 +208,7 @@
it's much quicker to push a driver-private interface than engaging in
lengthy discussions for a more generic solution. And occasionally doing a
private interface to spearhead a new concept is what's required. But in the
- end, once the generic interface comes around you'll end up maintainer two
+ end, once the generic interface comes around you'll end up maintaining two
interfaces. Indefinitely.
* Consider other interfaces than ioctls. A sysfs attribute is much better for
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 5561dae..b48da69 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -31,8 +31,8 @@
====================== =============== ========================================
GNU C 5.1 gcc --version
Clang/LLVM (optional) 11.0.0 clang --version
-Rust (optional) 1.68.2 rustc --version
-bindgen (optional) 0.56.0 bindgen --version
+Rust (optional) 1.71.1 rustc --version
+bindgen (optional) 0.65.1 bindgen --version
GNU make 3.82 make --version
bash 4.2 bash --version
binutils 2.25 ld -v
@@ -482,7 +482,7 @@
JFSutils
--------
-- <http://jfs.sourceforge.net/>
+- <https://jfs.sourceforge.net/>
Reiserfsprogs
-------------
@@ -503,7 +503,7 @@
Quota-tools
-----------
-- <http://sourceforge.net/projects/linuxquota/>
+- <https://sourceforge.net/projects/linuxquota/>
Intel P6 microcode
@@ -524,7 +524,7 @@
mcelog
------
-- <http://www.mcelog.org/>
+- <https://www.mcelog.org/>
cpio
----
@@ -544,7 +544,8 @@
NFS-utils
---------
-- <http://sourceforge.net/project/showfiles.php?group_id=14>
+- <https://sourceforge.net/project/showfiles.php?group_id=14>
+- <https://nfs.sourceforge.net/>
Iptables
--------
@@ -559,12 +560,7 @@
OProfile
--------
-- <http://oprofile.sf.net/download/>
-
-NFS-Utils
----------
-
-- <http://nfs.sourceforge.net/>
+- <https://oprofile.sf.net/download/>
Kernel documentation
********************
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index f91b844..1f7f3e6 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -77,7 +77,7 @@
If no 2-factor form is available, the saturate-on-overflow helpers should
be used::
- bar = vmalloc(array_size(count, size));
+ bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL);
Another common case to avoid is calculating the size of a structure with
a trailing array of others structures, as in::
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index 46f927a..8660493 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -29,7 +29,7 @@
The documents on each section of this document are ordered by its
published date, from the newest to the oldest. The maintainer(s) should
- periodically retire resources as they become obsolte or outdated; with
+ periodically retire resources as they become obsolete or outdated; with
the exception of foundational books.
Docs at the Linux Kernel tree
@@ -118,6 +118,15 @@
:ISBN: 978-0672329463
:Notes: Foundational book
+ * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition**
+
+ :Author: Kenneth Hess
+ :Publisher: O'Reilly Media
+ :Date: May, 2023
+ :Pages: 246
+ :ISBN: 978-1098109035
+ :Notes: System administration
+
.. _ldd3_published:
* Title: **Linux Device Drivers, 3rd Edition**
diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst
index 9992bfd..976391c 100644
--- a/Documentation/process/maintainer-handbooks.rst
+++ b/Documentation/process/maintainer-handbooks.rst
@@ -17,5 +17,6 @@
maintainer-netdev
maintainer-soc
+ maintainer-soc-clean-dts
maintainer-tip
maintainer-kvm-x86
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 2ab843c..c1c732e 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -167,6 +167,8 @@
patch is a good way to ensure your patch is ignored or pushed to the
bottom of the priority list.
+.. _Changes requested:
+
Changes requested
~~~~~~~~~~~~~~~~~
@@ -359,6 +361,10 @@
version of the code if the discussion about the previous version is still
ongoing, unless directly instructed by a reviewer.
+The new version of patches should be posted as a separate thread,
+not as a reply to the previous posting. Change log should include a link
+to the previous posting (see :ref:`Changes requested`).
+
Testing
-------
diff --git a/Documentation/process/maintainer-soc-clean-dts.rst b/Documentation/process/maintainer-soc-clean-dts.rst
new file mode 100644
index 0000000..1b32430
--- /dev/null
+++ b/Documentation/process/maintainer-soc-clean-dts.rst
@@ -0,0 +1,25 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================================
+SoC Platforms with DTS Compliance Requirements
+==============================================
+
+Overview
+--------
+
+SoC platforms or subarchitectures should follow all the rules from
+Documentation/process/maintainer-soc.rst. This document referenced in
+MAINTAINERS impose additional requirements listed below.
+
+Strict DTS DT Schema and dtc Compliance
+---------------------------------------
+
+No changes to the SoC platform Devicetree sources (DTS files) should introduce
+new ``make dtbs_check W=1`` warnings. Warnings in a new board DTS, which are
+results of issues in an included DTSI file, are considered existing, not new
+warnings. The platform maintainers have automation in place which should point
+out any new warnings.
+
+If a commit introducing new warnings gets accepted somehow, the resulting
+issues shall be fixed in reasonable time (e.g. within one release) or the
+commit reverted.
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 49f0828..1263753 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -133,8 +133,8 @@
more information on the validation of devicetrees.
For new platforms, or additions to existing ones, ``make dtbs_check`` should not
-add any new warnings. For RISC-V, as it has the advantage of being a newer
-architecture, ``make dtbs_check W=1`` is required to not add any new warnings.
+add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
+required to not add any new warnings.
If in any doubt about a devicetree change, reach out to the devicetree
maintainers.
diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst
index 9fcfed3..d159cd4 100644
--- a/Documentation/process/researcher-guidelines.rst
+++ b/Documentation/process/researcher-guidelines.rst
@@ -44,6 +44,33 @@
involved. Developers cannot be interacted with/experimented on without
consent; this, too, is standard research ethics.
+Surveys
+=======
+
+Research often takes the form of surveys sent to maintainers or
+contributors. As a general rule, though, the kernel community derives
+little value from these surveys. The kernel development process works
+because every developer benefits from their participation, even working
+with others who have different goals. Responding to a survey, though, is a
+one-way demand placed on busy developers with no corresponding benefit to
+themselves or to the kernel community as a whole. For this reason, this
+method of research is discouraged.
+
+Kernel community members already receive far too much email and are likely
+to perceive survey requests as just another demand on their time. Sending
+such requests deprives the community of valuable contributor time and is
+unlikely to yield a statistically useful response.
+
+As an alternative, researchers should consider attending developer events,
+hosting sessions where the research project and its benefits to the
+participants can be explained, and interacting directly with the community
+there. The information received will be far richer than that obtained from
+an email survey, and the community will gain from the ability to learn from
+your insights as well.
+
+Patches
+=======
+
To help clarify: sending patches to developers *is* interacting
with them, but they have already consented to receiving *good faith
contributions*. Sending intentionally flawed/vulnerable patches or
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 51df119..41f1e07 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -6,30 +6,29 @@
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
+ - It or an equivalent fix must already exist in Linus' tree (upstream).
- It must be obviously correct and tested.
- It cannot be bigger than 100 lines, with context.
- - It must fix only one thing.
- - It must fix a real bug that bothers people (not a, "This could be a
- problem..." type thing).
- - It must fix a problem that causes a build error (but not for things
- marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
- security issue, or some "oh, that's not good" issue. In short, something
- critical.
- - Serious issues as reported by a user of a distribution kernel may also
- be considered if they fix a notable performance or interactivity issue.
- As these fixes are not as obvious and have a higher risk of a subtle
- regression they should only be submitted by a distribution kernel
- maintainer and include an addendum linking to a bugzilla entry if it
- exists and additional information on the user-visible impact.
- - New device IDs and quirks are also accepted.
- - No "theoretical race condition" issues, unless an explanation of how the
- race can be exploited is also provided.
- - It cannot contain any "trivial" fixes in it (spelling changes,
- whitespace cleanups, etc).
- It must follow the
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
rules.
- - It or an equivalent fix must already exist in Linus' tree (upstream).
+ - It must either fix a real bug that bothers people or just add a device ID.
+ To elaborate on the former:
+
+ - It fixes a problem like an oops, a hang, data corruption, a real security
+ issue, a hardware quirk, a build error (but not for things marked
+ CONFIG_BROKEN), or some "oh, that's not good" issue.
+ - Serious issues as reported by a user of a distribution kernel may also
+ be considered if they fix a notable performance or interactivity issue.
+ As these fixes are not as obvious and have a higher risk of a subtle
+ regression they should only be submitted by a distribution kernel
+ maintainer and include an addendum linking to a bugzilla entry if it
+ exists and additional information on the user-visible impact.
+ - No "This could be a problem..." type of things like a "theoretical race
+ condition", unless an explanation of how the bug can be exploited is also
+ provided.
+ - No "trivial" fixes without benefit for users (spelling changes, whitespace
+ cleanups, etc).
Procedure for submitting patches to the -stable tree
@@ -41,32 +40,106 @@
process but should follow the procedures in
:ref:`Documentation/process/security-bugs.rst <securitybugs>`.
-For all other submissions, choose one of the following procedures
------------------------------------------------------------------
+There are three options to submit a change to -stable trees:
+
+ 1. Add a 'stable tag' to the description of a patch you then submit for
+ mainline inclusion.
+ 2. Ask the stable team to pick up a patch already mainlined.
+ 3. Submit a patch to the stable team that is equivalent to a change already
+ mainlined.
+
+The sections below describe each of the options in more detail.
+
+:ref:`option_1` is **strongly** preferred, it is the easiest and most common.
+:ref:`option_2` is mainly meant for changes where backporting was not considered
+at the time of submission. :ref:`option_3` is an alternative to the two earlier
+options for cases where a mainlined patch needs adjustments to apply in older
+series (for example due to API changes).
+
+When using option 2 or 3 you can ask for your change to be included in specific
+stable series. When doing so, ensure the fix or an equivalent is applicable,
+submitted, or already present in all newer stable trees still supported. This is
+meant to prevent regressions that users might later encounter on updating, if
+e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y.
.. _option_1:
Option 1
********
-To have the patch automatically included in the stable tree, add the tag
+To have a patch you submit for mainline inclusion later automatically picked up
+for stable trees, add the tag
.. code-block:: none
Cc: stable@vger.kernel.org
-in the sign-off area. Once the patch is merged it will be applied to
-the stable tree without anything else needing to be done by the author
-or subsystem maintainer.
+in the sign-off area. Once the patch is mainlined it will be applied to the
+stable tree without anything else needing to be done by the author or
+subsystem maintainer.
+
+To sent additional instructions to the stable team, use a shell-style inline
+comment:
+
+ * To specify any additional patch prerequisites for cherry picking use the
+ following format in the sign-off area:
+
+ .. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
+ Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
+ Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
+ Cc: <stable@vger.kernel.org> # 3.3.x
+ Signed-off-by: Ingo Molnar <mingo@elte.hu>
+
+ The tag sequence has the meaning of:
+
+ .. code-block:: none
+
+ git cherry-pick a1f84a3
+ git cherry-pick 1b9508f
+ git cherry-pick fd21073
+ git cherry-pick <this commit>
+
+ * For patches that may have kernel version prerequisites specify them using
+ the following format in the sign-off area:
+
+ .. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # 3.3.x
+
+ The tag has the meaning of:
+
+ .. code-block:: none
+
+ git cherry-pick <this commit>
+
+ For each "-stable" tree starting with the specified version.
+
+ Note, such tagging is unnecessary if the stable team can derive the
+ appropriate versions from Fixes: tags.
+
+ * To delay pick up of patches, use the following format:
+
+ .. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
+
+ * For any other requests, just add a note to the stable tag. This for example
+ can be used to point out known problems:
+
+ .. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
.. _option_2:
Option 2
********
-After the patch has been merged to Linus' tree, send an email to
+If the patch already has been merged to mainline, send an email to
stable@vger.kernel.org containing the subject of the patch, the commit ID,
-why you think it should be applied, and what kernel version you wish it to
+why you think it should be applied, and what kernel versions you wish it to
be applied to.
.. _option_3:
@@ -75,23 +148,9 @@
********
Send the patch, after verifying that it follows the above rules, to
-stable@vger.kernel.org. You must note the upstream commit ID in the
-changelog of your submission, as well as the kernel version you wish
-it to be applied to.
-
-:ref:`option_1` is **strongly** preferred, is the easiest and most common.
-:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed
-worthy at the time it is applied to a public git tree (for instance, because
-it deserves more regression testing first). :ref:`option_3` is especially
-useful if the original upstream patch needs to be backported (for example
-the backport needs some special handling due to e.g. API changes).
-
-Note that for :ref:`option_3`, if the patch deviates from the original
-upstream patch (for example because it had to be backported) this must be very
-clearly documented and justified in the patch description.
-
-The upstream commit ID must be specified with a separate line above the commit
-text, like this:
+stable@vger.kernel.org and mention the kernel versions you wish it to be applied
+to. When doing so, you must note the upstream commit ID in the changelog of your
+submission with a separate line above the commit text, like this:
.. code-block:: none
@@ -103,49 +162,20 @@
[ Upstream commit <sha1> ]
-Additionally, some patches submitted via :ref:`option_1` may have additional
-patch prerequisites which can be cherry-picked. This can be specified in the
-following format in the sign-off area:
+If the submitted patch deviates from the original upstream patch (for example
+because it had to be adjusted for the older API), this must be very clearly
+documented and justified in the patch description.
-.. code-block:: none
- Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
- Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
- Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
- Cc: <stable@vger.kernel.org> # 3.3.x
- Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Following the submission
+------------------------
-The tag sequence has the meaning of:
+The sender will receive an ACK when the patch has been accepted into the
+queue, or a NAK if the patch is rejected. This response might take a few
+days, according to the schedules of the stable team members.
-.. code-block:: none
-
- git cherry-pick a1f84a3
- git cherry-pick 1b9508f
- git cherry-pick fd21073
- git cherry-pick <this commit>
-
-Also, some patches may have kernel version prerequisites. This can be
-specified in the following format in the sign-off area:
-
-.. code-block:: none
-
- Cc: <stable@vger.kernel.org> # 3.3.x
-
-The tag has the meaning of:
-
-.. code-block:: none
-
- git cherry-pick <this commit>
-
-For each "-stable" tree starting with the specified version.
-
-Following the submission:
-
- - The sender will receive an ACK when the patch has been accepted into the
- queue, or a NAK if the patch is rejected. This response might take a few
- days, according to the developer's schedules.
- - If accepted, the patch will be added to the -stable queue, for review by
- other developers and by the relevant subsystem maintainer.
+If accepted, the patch will be added to the -stable queue, for review by other
+developers and by the relevant subsystem maintainer.
Review cycle
@@ -174,6 +204,7 @@
security kernel team, and not go through the normal review cycle.
Contact the kernel security team for more details on this procedure.
+
Trees
-----
diff --git a/Documentation/riscv/boot-image-header.rst b/Documentation/riscv/boot-image-header.rst
index d775253..df2ffc1 100644
--- a/Documentation/riscv/boot-image-header.rst
+++ b/Documentation/riscv/boot-image-header.rst
@@ -7,9 +7,6 @@
This document only describes the boot image header details for RISC-V Linux.
-TODO:
- Write a complete booting guide.
-
The following 64-byte header is present in decompressed Linux kernel image::
u32 code0; /* Executable code */
@@ -31,11 +28,11 @@
Notes
=====
-- This header can also be reused to support EFI stub for RISC-V in future. EFI
- specification needs PE/COFF image header in the beginning of the kernel image
- in order to load it as an EFI application. In order to support EFI stub,
- code0 should be replaced with "MZ" magic string and res3(at offset 0x3c) should
- point to the rest of the PE/COFF header.
+- This header is also reused to support EFI stub for RISC-V. EFI specification
+ needs PE/COFF image header in the beginning of the kernel image in order to
+ load it as an EFI application. In order to support EFI stub, code0 is replaced
+ with "MZ" magic string and res3(at offset 0x3c) points to the rest of the
+ PE/COFF header.
- version field indicate header version number
diff --git a/Documentation/riscv/boot.rst b/Documentation/riscv/boot.rst
new file mode 100644
index 0000000..6077b58
--- /dev/null
+++ b/Documentation/riscv/boot.rst
@@ -0,0 +1,169 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+RISC-V Kernel Boot Requirements and Constraints
+===============================================
+
+:Author: Alexandre Ghiti <alexghiti@rivosinc.com>
+:Date: 23 May 2023
+
+This document describes what the RISC-V kernel expects from bootloaders and
+firmware, and also the constraints that any developer must have in mind when
+touching the early boot process. For the purposes of this document, the
+``early boot process`` refers to any code that runs before the final virtual
+mapping is set up.
+
+Pre-kernel Requirements and Constraints
+=======================================
+
+The RISC-V kernel expects the following of bootloaders and platform firmware:
+
+Register state
+--------------
+
+The RISC-V kernel expects:
+
+ * ``$a0`` to contain the hartid of the current core.
+ * ``$a1`` to contain the address of the devicetree in memory.
+
+CSR state
+---------
+
+The RISC-V kernel expects:
+
+ * ``$satp = 0``: the MMU, if present, must be disabled.
+
+Reserved memory for resident firmware
+-------------------------------------
+
+The RISC-V kernel must not map any resident memory, or memory protected with
+PMPs, in the direct mapping, so the firmware must correctly mark those regions
+as per the devicetree specification and/or the UEFI specification.
+
+Kernel location
+---------------
+
+The RISC-V kernel expects to be placed at a PMD boundary (2MB aligned for rv64
+and 4MB aligned for rv32). Note that the EFI stub will physically relocate the
+kernel if that's not the case.
+
+Hardware description
+--------------------
+
+The firmware can pass either a devicetree or ACPI tables to the RISC-V kernel.
+
+The devicetree is either passed directly to the kernel from the previous stage
+using the ``$a1`` register, or when booting with UEFI, it can be passed using the
+EFI configuration table.
+
+The ACPI tables are passed to the kernel using the EFI configuration table. In
+this case, a tiny devicetree is still created by the EFI stub. Please refer to
+"EFI stub and devicetree" section below for details about this devicetree.
+
+Kernel entry
+------------
+
+On SMP systems, there are 2 methods to enter the kernel:
+
+- ``RISCV_BOOT_SPINWAIT``: the firmware releases all harts in the kernel, one hart
+ wins a lottery and executes the early boot code while the other harts are
+ parked waiting for the initialization to finish. This method is mostly used to
+ support older firmwares without SBI HSM extension and M-mode RISC-V kernel.
+- ``Ordered booting``: the firmware releases only one hart that will execute the
+ initialization phase and then will start all other harts using the SBI HSM
+ extension. The ordered booting method is the preferred booting method for
+ booting the RISC-V kernel because it can support CPU hotplug and kexec.
+
+UEFI
+----
+
+UEFI memory map
+~~~~~~~~~~~~~~~
+
+When booting with UEFI, the RISC-V kernel will use only the EFI memory map to
+populate the system memory.
+
+The UEFI firmware must parse the subnodes of the ``/reserved-memory`` devicetree
+node and abide by the devicetree specification to convert the attributes of
+those subnodes (``no-map`` and ``reusable``) into their correct EFI equivalent
+(refer to section "3.5.4 /reserved-memory and UEFI" of the devicetree
+specification v0.4-rc1).
+
+RISCV_EFI_BOOT_PROTOCOL
+~~~~~~~~~~~~~~~~~~~~~~~
+
+When booting with UEFI, the EFI stub requires the boot hartid in order to pass
+it to the RISC-V kernel in ``$a1``. The EFI stub retrieves the boot hartid using
+one of the following methods:
+
+- ``RISCV_EFI_BOOT_PROTOCOL`` (**preferred**).
+- ``boot-hartid`` devicetree subnode (**deprecated**).
+
+Any new firmware must implement ``RISCV_EFI_BOOT_PROTOCOL`` as the devicetree
+based approach is deprecated now.
+
+Early Boot Requirements and Constraints
+=======================================
+
+The RISC-V kernel's early boot process operates under the following constraints:
+
+EFI stub and devicetree
+-----------------------
+
+When booting with UEFI, the devicetree is supplemented (or created) by the EFI
+stub with the same parameters as arm64 which are described at the paragraph
+"UEFI kernel support on ARM" in Documentation/arch/arm/uefi.rst.
+
+Virtual mapping installation
+----------------------------
+
+The installation of the virtual mapping is done in 2 steps in the RISC-V kernel:
+
+1. ``setup_vm()`` installs a temporary kernel mapping in ``early_pg_dir`` which
+ allows discovery of the system memory. Only the kernel text/data are mapped
+ at this point. When establishing this mapping, no allocation can be done
+ (since the system memory is not known yet), so ``early_pg_dir`` page table is
+ statically allocated (using only one table for each level).
+
+2. ``setup_vm_final()`` creates the final kernel mapping in ``swapper_pg_dir``
+ and takes advantage of the discovered system memory to create the linear
+ mapping. When establishing this mapping, the kernel can allocate memory but
+ cannot access it directly (since the direct mapping is not present yet), so
+ it uses temporary mappings in the fixmap region to be able to access the
+ newly allocated page table levels.
+
+For ``virt_to_phys()`` and ``phys_to_virt()`` to be able to correctly convert
+direct mapping addresses to physical addresses, they need to know the start of
+the DRAM. This happens after step 1, right before step 2 installs the direct
+mapping (see ``setup_bootmem()`` function in arch/riscv/mm/init.c). Any usage of
+those macros before the final virtual mapping is installed must be carefully
+examined.
+
+Devicetree mapping via fixmap
+-----------------------------
+
+As the ``reserved_mem`` array is initialized with virtual addresses established
+by ``setup_vm()``, and used with the mapping established by
+``setup_vm_final()``, the RISC-V kernel uses the fixmap region to map the
+devicetree. This ensures that the devicetree remains accessible by both virtual
+mappings.
+
+Pre-MMU execution
+-----------------
+
+A few pieces of code need to run before even the first virtual mapping is
+established. These are the installation of the first virtual mapping itself,
+patching of early alternatives and the early parsing of the kernel command line.
+That code must be very carefully compiled as:
+
+- ``-fno-pie``: This is needed for relocatable kernels which use ``-fPIE``,
+ since otherwise, any access to a global symbol would go through the GOT which
+ is only relocated virtually.
+- ``-mcmodel=medany``: Any access to a global symbol must be PC-relative to
+ avoid any relocations to happen before the MMU is setup.
+- *all* instrumentation must also be disabled (that includes KASAN, ftrace and
+ others).
+
+As using a symbol from a different compilation unit requires this unit to be
+compiled with those flags, we advise, as much as possible, not to use external
+symbols.
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 933c715..20eff96 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -88,11 +88,11 @@
always extremely slow.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported
- in hardware, but are slower than the cooresponding aligned accesses
+ in hardware, but are slower than the corresponding aligned accesses
sequences.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported
- in hardware and are faster than the cooresponding aligned accesses
+ in hardware and are faster than the corresponding aligned accesses
sequences.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index 81cf6e6..4dab0cb 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -6,6 +6,7 @@
:maxdepth: 1
acpi
+ boot
boot-image-header
vm-layout
hwprobe
diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst
index 165b7ed..75dd88a 100644
--- a/Documentation/riscv/vector.rst
+++ b/Documentation/riscv/vector.rst
@@ -13,7 +13,7 @@
Two new prctl() calls are added to allow programs to manage the enablement
status for the use of Vector in userspace. The intended usage guideline for
these interfaces is to give init systems a way to modify the availability of V
-for processes running under its domain. Calling thess interfaces is not
+for processes running under its domain. Calling these interfaces is not
recommended in libraries routines because libraries should not override policies
configured from the parant process. Also, users must noted that these interfaces
are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
index 5462c84..69ff6da 100644
--- a/Documentation/riscv/vm-layout.rst
+++ b/Documentation/riscv/vm-layout.rst
@@ -133,3 +133,25 @@
ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
__________________|____________|__________________|_________|____________________________________________________________
+
+
+Userspace VAs
+--------------------
+To maintain compatibility with software that relies on the VA space with a
+maximum of 48 bits the kernel will, by default, return virtual addresses to
+userspace from a 48-bit range (sv48). This default behavior is achieved by
+passing 0 into the hint address parameter of mmap. On CPUs with an address space
+smaller than sv48, the CPU maximum supported address space will be the default.
+
+Software can "opt-in" to receiving VAs from another VA space by providing
+a hint address to mmap. A hint address passed to mmap will cause the largest
+address space that fits entirely into the hint to be used, unless there is no
+space left in the address space. If there is no space available in the requested
+address space, an address in the next smallest available address space will be
+returned.
+
+For example, in order to obtain 48-bit VA space, a hint address greater than
+:code:`1 << 47` must be provided. Note that this is 47 due to sv48 userspace
+ending at :code:`1 << 47` and the addresses beyond this are reserved for the
+kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
+than or equal to :code:`1 << 56` must be provided.
diff --git a/Documentation/rust/index.rst b/Documentation/rust/index.rst
index 4ae8c66..e599be2 100644
--- a/Documentation/rust/index.rst
+++ b/Documentation/rust/index.rst
@@ -6,6 +6,14 @@
Documentation related to Rust within the kernel. To start using Rust
in the kernel, please read the quick-start.rst guide.
+.. only:: rustdoc and html
+
+ You can also browse `rustdoc documentation <rustdoc/kernel/index.html>`_.
+
+.. only:: not rustdoc and html
+
+ This documentation does not include rustdoc generated information.
+
.. toctree::
:maxdepth: 1
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index a893151..f382914 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -38,7 +38,9 @@
rustup override set $(scripts/min-tool-version.sh rustc)
-Otherwise, fetch a standalone installer from:
+This will configure your working directory to use the correct version of
+``rustc`` without affecting your default toolchain. If you are not using
+``rustup``, fetch a standalone installer from:
https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
@@ -56,16 +58,17 @@
The components are installed per toolchain, thus upgrading the Rust compiler
version later on requires re-adding the component.
-Otherwise, if a standalone installer is used, the Rust repository may be cloned
-into the installation folder of the toolchain::
+Otherwise, if a standalone installer is used, the Rust source tree may be
+downloaded into the toolchain's installation folder::
- git clone --recurse-submodules \
- --branch $(scripts/min-tool-version.sh rustc) \
- https://github.com/rust-lang/rust \
- $(rustc --print sysroot)/lib/rustlib/src/rust
+ curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" |
+ tar -xzf - -C "$(rustc --print sysroot)/lib" \
+ "rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \
+ --strip-components=3
In this case, upgrading the Rust compiler version later on requires manually
-updating this clone.
+updating the source tree (this can be done by removing ``$(rustc --print
+sysroot)/lib/rustlib/src/rust`` then rerunning the above command).
libclang
@@ -98,7 +101,24 @@
Install it via (note that this will download and build the tool from source)::
- cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen
+ cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli
+
+``bindgen`` needs to find a suitable ``libclang`` in order to work. If it is
+not found (or a different ``libclang`` than the one found should be used),
+the process can be tweaked using the environment variables understood by
+``clang-sys`` (the Rust bindings crate that ``bindgen`` uses to access
+``libclang``):
+
+* ``LLVM_CONFIG_PATH`` can be pointed to an ``llvm-config`` executable.
+
+* Or ``LIBCLANG_PATH`` can be pointed to a ``libclang`` shared library
+ or to the directory containing it.
+
+* Or ``CLANG_PATH`` can be pointed to a ``clang`` executable.
+
+For details, please see ``clang-sys``'s documentation at:
+
+ https://github.com/KyleMayes/clang-sys#environment-variables
Requirements: Developing
@@ -179,7 +199,9 @@
definition, and other features.
``rust-analyzer`` needs a configuration file, ``rust-project.json``, which
-can be generated by the ``rust-analyzer`` Make target.
+can be generated by the ``rust-analyzer`` Make target::
+
+ make LLVM=1 rust-analyzer
Configuration
diff --git a/Documentation/s390/3270.rst b/Documentation/s390/3270.rst
deleted file mode 100644
index e09e779..0000000
--- a/Documentation/s390/3270.rst
+++ /dev/null
@@ -1,298 +0,0 @@
-===============================
-IBM 3270 Display System support
-===============================
-
-This file describes the driver that supports local channel attachment
-of IBM 3270 devices. It consists of three sections:
-
- * Introduction
- * Installation
- * Operation
-
-
-Introduction
-============
-
-This paper describes installing and operating 3270 devices under
-Linux/390. A 3270 device is a block-mode rows-and-columns terminal of
-which I'm sure hundreds of millions were sold by IBM and clonemakers
-twenty and thirty years ago.
-
-You may have 3270s in-house and not know it. If you're using the
-VM-ESA operating system, define a 3270 to your virtual machine by using
-the command "DEF GRAF <hex-address>" This paper presumes you will be
-defining four 3270s with the CP/CMS commands:
-
- - DEF GRAF 620
- - DEF GRAF 621
- - DEF GRAF 622
- - DEF GRAF 623
-
-Your network connection from VM-ESA allows you to use x3270, tn3270, or
-another 3270 emulator, started from an xterm window on your PC or
-workstation. With the DEF GRAF command, an application such as xterm,
-and this Linux-390 3270 driver, you have another way of talking to your
-Linux box.
-
-This paper covers installation of the driver and operation of a
-dialed-in x3270.
-
-
-Installation
-============
-
-You install the driver by installing a patch, doing a kernel build, and
-running the configuration script (config3270.sh, in this directory).
-
-WARNING: If you are using 3270 console support, you must rerun the
-configuration script every time you change the console's address (perhaps
-by using the condev= parameter in silo's /boot/parmfile). More precisely,
-you should rerun the configuration script every time your set of 3270s,
-including the console 3270, changes subchannel identifier relative to
-one another. ReIPL as soon as possible after running the configuration
-script and the resulting /tmp/mkdev3270.
-
-If you have chosen to make tub3270 a module, you add a line to a
-configuration file under /etc/modprobe.d/. If you are working on a VM
-virtual machine, you can use DEF GRAF to define virtual 3270 devices.
-
-You may generate both 3270 and 3215 console support, or one or the
-other, or neither. If you generate both, the console type under VM is
-not changed. Use #CP Q TERM to see what the current console type is.
-Use #CP TERM CONMODE 3270 to change it to 3270. If you generate only
-3270 console support, then the driver automatically converts your console
-at boot time to a 3270 if it is a 3215.
-
-In brief, these are the steps:
-
- 1. Install the tub3270 patch
- 2. (If a module) add a line to a file in `/etc/modprobe.d/*.conf`
- 3. (If VM) define devices with DEF GRAF
- 4. Reboot
- 5. Configure
-
-To test that everything works, assuming VM and x3270,
-
- 1. Bring up an x3270 window.
- 2. Use the DIAL command in that window.
- 3. You should immediately see a Linux login screen.
-
-Here are the installation steps in detail:
-
- 1. The 3270 driver is a part of the official Linux kernel
- source. Build a tree with the kernel source and any necessary
- patches. Then do::
-
- make oldconfig
- (If you wish to disable 3215 console support, edit
- .config; change CONFIG_TN3215's value to "n";
- and rerun "make oldconfig".)
- make image
- make modules
- make modules_install
-
- 2. (Perform this step only if you have configured tub3270 as a
- module.) Add a line to a file `/etc/modprobe.d/*.conf` to automatically
- load the driver when it's needed. With this line added, you will see
- login prompts appear on your 3270s as soon as boot is complete (or
- with emulated 3270s, as soon as you dial into your vm guest using the
- command "DIAL <vmguestname>"). Since the line-mode major number is
- 227, the line to add should be::
-
- alias char-major-227 tub3270
-
- 3. Define graphic devices to your vm guest machine, if you
- haven't already. Define them before you reboot (reipl):
-
- - DEFINE GRAF 620
- - DEFINE GRAF 621
- - DEFINE GRAF 622
- - DEFINE GRAF 623
-
- 4. Reboot. The reboot process scans hardware devices, including
- 3270s, and this enables the tub3270 driver once loaded to respond
- correctly to the configuration requests of the next step. If
- you have chosen 3270 console support, your console now behaves
- as a 3270, not a 3215.
-
- 5. Run the 3270 configuration script config3270. It is
- distributed in this same directory, Documentation/s390, as
- config3270.sh. Inspect the output script it produces,
- /tmp/mkdev3270, and then run that script. This will create the
- necessary character special device files and make the necessary
- changes to /etc/inittab.
-
- Then notify /sbin/init that /etc/inittab has changed, by issuing
- the telinit command with the q operand::
-
- cd Documentation/s390
- sh config3270.sh
- sh /tmp/mkdev3270
- telinit q
-
- This should be sufficient for your first time. If your 3270
- configuration has changed and you're reusing config3270, you
- should follow these steps::
-
- Change 3270 configuration
- Reboot
- Run config3270 and /tmp/mkdev3270
- Reboot
-
-Here are the testing steps in detail:
-
- 1. Bring up an x3270 window, or use an actual hardware 3278 or
- 3279, or use the 3270 emulator of your choice. You would be
- running the emulator on your PC or workstation. You would use
- the command, for example::
-
- x3270 vm-esa-domain-name &
-
- if you wanted a 3278 Model 4 with 43 rows of 80 columns, the
- default model number. The driver does not take advantage of
- extended attributes.
-
- The screen you should now see contains a VM logo with input
- lines near the bottom. Use TAB to move to the bottom line,
- probably labeled "COMMAND ===>".
-
- 2. Use the DIAL command instead of the LOGIN command to connect
- to one of the virtual 3270s you defined with the DEF GRAF
- commands::
-
- dial my-vm-guest-name
-
- 3. You should immediately see a login prompt from your
- Linux-390 operating system. If that does not happen, you would
- see instead the line "DIALED TO my-vm-guest-name 0620".
-
- To troubleshoot: do these things.
-
- A. Is the driver loaded? Use the lsmod command (no operands)
- to find out. Probably it isn't. Try loading it manually, with
- the command "insmod tub3270". Does that command give error
- messages? Ha! There's your problem.
-
- B. Is the /etc/inittab file modified as in installation step 3
- above? Use the grep command to find out; for instance, issue
- "grep 3270 /etc/inittab". Nothing found? There's your
- problem!
-
- C. Are the device special files created, as in installation
- step 2 above? Use the ls -l command to find out; for instance,
- issue "ls -l /dev/3270/tty620". The output should start with the
- letter "c" meaning character device and should contain "227, 1"
- just to the left of the device name. No such file? no "c"?
- Wrong major number? Wrong minor number? There's your
- problem!
-
- D. Do you get the message::
-
- "HCPDIA047E my-vm-guest-name 0620 does not exist"?
-
- If so, you must issue the command "DEF GRAF 620" from your VM
- 3215 console and then reboot the system.
-
-
-
-OPERATION.
-==========
-
-The driver defines three areas on the 3270 screen: the log area, the
-input area, and the status area.
-
-The log area takes up all but the bottom two lines of the screen. The
-driver writes terminal output to it, starting at the top line and going
-down. When it fills, the status area changes from "Linux Running" to
-"Linux More...". After a scrolling timeout of (default) 5 sec, the
-screen clears and more output is written, from the top down.
-
-The input area extends from the beginning of the second-to-last screen
-line to the start of the status area. You type commands in this area
-and hit ENTER to execute them.
-
-The status area initializes to "Linux Running" to give you a warm
-fuzzy feeling. When the log area fills up and output awaits, it
-changes to "Linux More...". At this time you can do several things or
-nothing. If you do nothing, the screen will clear in (default) 5 sec
-and more output will appear. You may hit ENTER with nothing typed in
-the input area to toggle between "Linux More..." and "Linux Holding",
-which indicates no scrolling will occur. (If you hit ENTER with "Linux
-Running" and nothing typed, the application receives a newline.)
-
-You may change the scrolling timeout value. For example, the following
-command line::
-
- echo scrolltime=60 > /proc/tty/driver/tty3270
-
-changes the scrolling timeout value to 60 sec. Set scrolltime to 0 if
-you wish to prevent scrolling entirely.
-
-Other things you may do when the log area fills up are: hit PA2 to
-clear the log area and write more output to it, or hit CLEAR to clear
-the log area and the input area and write more output to the log area.
-
-Some of the Program Function (PF) and Program Attention (PA) keys are
-preassigned special functions. The ones that are not yield an alarm
-when pressed.
-
-PA1 causes a SIGINT to the currently running application. You may do
-the same thing from the input area, by typing "^C" and hitting ENTER.
-
-PA2 causes the log area to be cleared. If output awaits, it is then
-written to the log area.
-
-PF3 causes an EOF to be received as input by the application. You may
-cause an EOF also by typing "^D" and hitting ENTER.
-
-No PF key is preassigned to cause a job suspension, but you may cause a
-job suspension by typing "^Z" and hitting ENTER. You may wish to
-assign this function to a PF key. To make PF7 cause job suspension,
-execute the command::
-
- echo pf7=^z > /proc/tty/driver/tty3270
-
-If the input you type does not end with the two characters "^n", the
-driver appends a newline character and sends it to the tty driver;
-otherwise the driver strips the "^n" and does not append a newline.
-The IBM 3215 driver behaves similarly.
-
-Pf10 causes the most recent command to be retrieved from the tube's
-command stack (default depth 20) and displayed in the input area. You
-may hit PF10 again for the next-most-recent command, and so on. A
-command is entered into the stack only when the input area is not made
-invisible (such as for password entry) and it is not identical to the
-current top entry. PF10 rotates backward through the command stack;
-PF11 rotates forward. You may assign the backward function to any PF
-key (or PA key, for that matter), say, PA3, with the command::
-
- echo -e pa3=\\033k > /proc/tty/driver/tty3270
-
-This assigns the string ESC-k to PA3. Similarly, the string ESC-j
-performs the forward function. (Rationale: In bash with vi-mode line
-editing, ESC-k and ESC-j retrieve backward and forward history.
-Suggestions welcome.)
-
-Is a stack size of twenty commands not to your liking? Change it on
-the fly. To change to saving the last 100 commands, execute the
-command::
-
- echo recallsize=100 > /proc/tty/driver/tty3270
-
-Have a command you issue frequently? Assign it to a PF or PA key! Use
-the command::
-
- echo pf24="mkdir foobar; cd foobar" > /proc/tty/driver/tty3270
-
-to execute the commands mkdir foobar and cd foobar immediately when you
-hit PF24. Want to see the command line first, before you execute it?
-Use the -n option of the echo command::
-
- echo -n pf24="mkdir foo; cd foo" > /proc/tty/driver/tty3270
-
-
-
-Happy testing! I welcome any and all comments about this document, the
-driver, etc etc.
-
-Dick Hitt <rbh00@utsglobal.com>
diff --git a/Documentation/s390/cds.rst b/Documentation/s390/cds.rst
deleted file mode 100644
index 7006d82..0000000
--- a/Documentation/s390/cds.rst
+++ /dev/null
@@ -1,530 +0,0 @@
-===========================
-Linux for S/390 and zSeries
-===========================
-
-Common Device Support (CDS)
-Device Driver I/O Support Routines
-
-Authors:
- - Ingo Adlung
- - Cornelia Huck
-
-Copyright, IBM Corp. 1999-2002
-
-Introduction
-============
-
-This document describes the common device support routines for Linux/390.
-Different than other hardware architectures, ESA/390 has defined a unified
-I/O access method. This gives relief to the device drivers as they don't
-have to deal with different bus types, polling versus interrupt
-processing, shared versus non-shared interrupt processing, DMA versus port
-I/O (PIO), and other hardware features more. However, this implies that
-either every single device driver needs to implement the hardware I/O
-attachment functionality itself, or the operating system provides for a
-unified method to access the hardware, providing all the functionality that
-every single device driver would have to provide itself.
-
-The document does not intend to explain the ESA/390 hardware architecture in
-every detail.This information can be obtained from the ESA/390 Principles of
-Operation manual (IBM Form. No. SA22-7201).
-
-In order to build common device support for ESA/390 I/O interfaces, a
-functional layer was introduced that provides generic I/O access methods to
-the hardware.
-
-The common device support layer comprises the I/O support routines defined
-below. Some of them implement common Linux device driver interfaces, while
-some of them are ESA/390 platform specific.
-
-Note:
- In order to write a driver for S/390, you also need to look into the interface
- described in Documentation/s390/driver-model.rst.
-
-Note for porting drivers from 2.4:
-
-The major changes are:
-
-* The functions use a ccw_device instead of an irq (subchannel).
-* All drivers must define a ccw_driver (see driver-model.txt) and the associated
- functions.
-* request_irq() and free_irq() are no longer done by the driver.
-* The oper_handler is (kindof) replaced by the probe() and set_online() functions
- of the ccw_driver.
-* The not_oper_handler is (kindof) replaced by the remove() and set_offline()
- functions of the ccw_driver.
-* The channel device layer is gone.
-* The interrupt handlers must be adapted to use a ccw_device as argument.
- Moreover, they don't return a devstat, but an irb.
-* Before initiating an io, the options must be set via ccw_device_set_options().
-* Instead of calling read_dev_chars()/read_conf_data(), the driver issues
- the channel program and handles the interrupt itself.
-
-ccw_device_get_ciw()
- get commands from extended sense data.
-
-ccw_device_start(), ccw_device_start_timeout(), ccw_device_start_key(), ccw_device_start_key_timeout()
- initiate an I/O request.
-
-ccw_device_resume()
- resume channel program execution.
-
-ccw_device_halt()
- terminate the current I/O request processed on the device.
-
-do_IRQ()
- generic interrupt routine. This function is called by the interrupt entry
- routine whenever an I/O interrupt is presented to the system. The do_IRQ()
- routine determines the interrupt status and calls the device specific
- interrupt handler according to the rules (flags) defined during I/O request
- initiation with do_IO().
-
-The next chapters describe the functions other than do_IRQ() in more details.
-The do_IRQ() interface is not described, as it is called from the Linux/390
-first level interrupt handler only and does not comprise a device driver
-callable interface. Instead, the functional description of do_IO() also
-describes the input to the device specific interrupt handler.
-
-Note:
- All explanations apply also to the 64 bit architecture s390x.
-
-
-Common Device Support (CDS) for Linux/390 Device Drivers
-========================================================
-
-General Information
--------------------
-
-The following chapters describe the I/O related interface routines the
-Linux/390 common device support (CDS) provides to allow for device specific
-driver implementations on the IBM ESA/390 hardware platform. Those interfaces
-intend to provide the functionality required by every device driver
-implementation to allow to drive a specific hardware device on the ESA/390
-platform. Some of the interface routines are specific to Linux/390 and some
-of them can be found on other Linux platforms implementations too.
-Miscellaneous function prototypes, data declarations, and macro definitions
-can be found in the architecture specific C header file
-linux/arch/s390/include/asm/irq.h.
-
-Overview of CDS interface concepts
-----------------------------------
-
-Different to other hardware platforms, the ESA/390 architecture doesn't define
-interrupt lines managed by a specific interrupt controller and bus systems
-that may or may not allow for shared interrupts, DMA processing, etc.. Instead,
-the ESA/390 architecture has implemented a so called channel subsystem, that
-provides a unified view of the devices physically attached to the systems.
-Though the ESA/390 hardware platform knows about a huge variety of different
-peripheral attachments like disk devices (aka. DASDs), tapes, communication
-controllers, etc. they can all be accessed by a well defined access method and
-they are presenting I/O completion a unified way : I/O interruptions. Every
-single device is uniquely identified to the system by a so called subchannel,
-where the ESA/390 architecture allows for 64k devices be attached.
-
-Linux, however, was first built on the Intel PC architecture, with its two
-cascaded 8259 programmable interrupt controllers (PICs), that allow for a
-maximum of 15 different interrupt lines. All devices attached to such a system
-share those 15 interrupt levels. Devices attached to the ISA bus system must
-not share interrupt levels (aka. IRQs), as the ISA bus bases on edge triggered
-interrupts. MCA, EISA, PCI and other bus systems base on level triggered
-interrupts, and therewith allow for shared IRQs. However, if multiple devices
-present their hardware status by the same (shared) IRQ, the operating system
-has to call every single device driver registered on this IRQ in order to
-determine the device driver owning the device that raised the interrupt.
-
-Up to kernel 2.4, Linux/390 used to provide interfaces via the IRQ (subchannel).
-For internal use of the common I/O layer, these are still there. However,
-device drivers should use the new calling interface via the ccw_device only.
-
-During its startup the Linux/390 system checks for peripheral devices. Each
-of those devices is uniquely defined by a so called subchannel by the ESA/390
-channel subsystem. While the subchannel numbers are system generated, each
-subchannel also takes a user defined attribute, the so called device number.
-Both subchannel number and device number cannot exceed 65535. During sysfs
-initialisation, the information about control unit type and device types that
-imply specific I/O commands (channel command words - CCWs) in order to operate
-the device are gathered. Device drivers can retrieve this set of hardware
-information during their initialization step to recognize the devices they
-support using the information saved in the struct ccw_device given to them.
-This methods implies that Linux/390 doesn't require to probe for free (not
-armed) interrupt request lines (IRQs) to drive its devices with. Where
-applicable, the device drivers can use issue the READ DEVICE CHARACTERISTICS
-ccw to retrieve device characteristics in its online routine.
-
-In order to allow for easy I/O initiation the CDS layer provides a
-ccw_device_start() interface that takes a device specific channel program (one
-or more CCWs) as input sets up the required architecture specific control blocks
-and initiates an I/O request on behalf of the device driver. The
-ccw_device_start() routine allows to specify whether it expects the CDS layer
-to notify the device driver for every interrupt it observes, or with final status
-only. See ccw_device_start() for more details. A device driver must never issue
-ESA/390 I/O commands itself, but must use the Linux/390 CDS interfaces instead.
-
-For long running I/O request to be canceled, the CDS layer provides the
-ccw_device_halt() function. Some devices require to initially issue a HALT
-SUBCHANNEL (HSCH) command without having pending I/O requests. This function is
-also covered by ccw_device_halt().
-
-
-get_ciw() - get command information word
-
-This call enables a device driver to get information about supported commands
-from the extended SenseID data.
-
-::
-
- struct ciw *
- ccw_device_get_ciw(struct ccw_device *cdev, __u32 cmd);
-
-==== ========================================================
-cdev The ccw_device for which the command is to be retrieved.
-cmd The command type to be retrieved.
-==== ========================================================
-
-ccw_device_get_ciw() returns:
-
-===== ================================================================
- NULL No extended data available, invalid device or command not found.
-!NULL The command requested.
-===== ================================================================
-
-::
-
- ccw_device_start() - Initiate I/O Request
-
-The ccw_device_start() routines is the I/O request front-end processor. All
-device driver I/O requests must be issued using this routine. A device driver
-must not issue ESA/390 I/O commands itself. Instead the ccw_device_start()
-routine provides all interfaces required to drive arbitrary devices.
-
-This description also covers the status information passed to the device
-driver's interrupt handler as this is related to the rules (flags) defined
-with the associated I/O request when calling ccw_device_start().
-
-::
-
- int ccw_device_start(struct ccw_device *cdev,
- struct ccw1 *cpa,
- unsigned long intparm,
- __u8 lpm,
- unsigned long flags);
- int ccw_device_start_timeout(struct ccw_device *cdev,
- struct ccw1 *cpa,
- unsigned long intparm,
- __u8 lpm,
- unsigned long flags,
- int expires);
- int ccw_device_start_key(struct ccw_device *cdev,
- struct ccw1 *cpa,
- unsigned long intparm,
- __u8 lpm,
- __u8 key,
- unsigned long flags);
- int ccw_device_start_key_timeout(struct ccw_device *cdev,
- struct ccw1 *cpa,
- unsigned long intparm,
- __u8 lpm,
- __u8 key,
- unsigned long flags,
- int expires);
-
-============= =============================================================
-cdev ccw_device the I/O is destined for
-cpa logical start address of channel program
-user_intparm user specific interrupt information; will be presented
- back to the device driver's interrupt handler. Allows a
- device driver to associate the interrupt with a
- particular I/O request.
-lpm defines the channel path to be used for a specific I/O
- request. A value of 0 will make cio use the opm.
-key the storage key to use for the I/O (useful for operating on a
- storage with a storage key != default key)
-flag defines the action to be performed for I/O processing
-expires timeout value in jiffies. The common I/O layer will terminate
- the running program after this and call the interrupt handler
- with ERR_PTR(-ETIMEDOUT) as irb.
-============= =============================================================
-
-Possible flag values are:
-
-========================= =============================================
-DOIO_ALLOW_SUSPEND channel program may become suspended
-DOIO_DENY_PREFETCH don't allow for CCW prefetch; usually
- this implies the channel program might
- become modified
-DOIO_SUPPRESS_INTER don't call the handler on intermediate status
-========================= =============================================
-
-The cpa parameter points to the first format 1 CCW of a channel program::
-
- struct ccw1 {
- __u8 cmd_code;/* command code */
- __u8 flags; /* flags, like IDA addressing, etc. */
- __u16 count; /* byte count */
- __u32 cda; /* data address */
- } __attribute__ ((packed,aligned(8)));
-
-with the following CCW flags values defined:
-
-=================== =========================
-CCW_FLAG_DC data chaining
-CCW_FLAG_CC command chaining
-CCW_FLAG_SLI suppress incorrect length
-CCW_FLAG_SKIP skip
-CCW_FLAG_PCI PCI
-CCW_FLAG_IDA indirect addressing
-CCW_FLAG_SUSPEND suspend
-=================== =========================
-
-
-Via ccw_device_set_options(), the device driver may specify the following
-options for the device:
-
-========================= ======================================
-DOIO_EARLY_NOTIFICATION allow for early interrupt notification
-DOIO_REPORT_ALL report all interrupt conditions
-========================= ======================================
-
-
-The ccw_device_start() function returns:
-
-======== ======================================================================
- 0 successful completion or request successfully initiated
- -EBUSY The device is currently processing a previous I/O request, or there is
- a status pending at the device.
--ENODEV cdev is invalid, the device is not operational or the ccw_device is
- not online.
-======== ======================================================================
-
-When the I/O request completes, the CDS first level interrupt handler will
-accumulate the status in a struct irb and then call the device interrupt handler.
-The intparm field will contain the value the device driver has associated with a
-particular I/O request. If a pending device status was recognized,
-intparm will be set to 0 (zero). This may happen during I/O initiation or delayed
-by an alert status notification. In any case this status is not related to the
-current (last) I/O request. In case of a delayed status notification no special
-interrupt will be presented to indicate I/O completion as the I/O request was
-never started, even though ccw_device_start() returned with successful completion.
-
-The irb may contain an error value, and the device driver should check for this
-first:
-
-========== =================================================================
--ETIMEDOUT the common I/O layer terminated the request after the specified
- timeout value
--EIO the common I/O layer terminated the request due to an error state
-========== =================================================================
-
-If the concurrent sense flag in the extended status word (esw) in the irb is
-set, the field erw.scnt in the esw describes the number of device specific
-sense bytes available in the extended control word irb->scsw.ecw[]. No device
-sensing by the device driver itself is required.
-
-The device interrupt handler can use the following definitions to investigate
-the primary unit check source coded in sense byte 0 :
-
-======================= ====
-SNS0_CMD_REJECT 0x80
-SNS0_INTERVENTION_REQ 0x40
-SNS0_BUS_OUT_CHECK 0x20
-SNS0_EQUIPMENT_CHECK 0x10
-SNS0_DATA_CHECK 0x08
-SNS0_OVERRUN 0x04
-SNS0_INCOMPL_DOMAIN 0x01
-======================= ====
-
-Depending on the device status, multiple of those values may be set together.
-Please refer to the device specific documentation for details.
-
-The irb->scsw.cstat field provides the (accumulated) subchannel status :
-
-========================= ============================
-SCHN_STAT_PCI program controlled interrupt
-SCHN_STAT_INCORR_LEN incorrect length
-SCHN_STAT_PROG_CHECK program check
-SCHN_STAT_PROT_CHECK protection check
-SCHN_STAT_CHN_DATA_CHK channel data check
-SCHN_STAT_CHN_CTRL_CHK channel control check
-SCHN_STAT_INTF_CTRL_CHK interface control check
-SCHN_STAT_CHAIN_CHECK chaining check
-========================= ============================
-
-The irb->scsw.dstat field provides the (accumulated) device status :
-
-===================== =================
-DEV_STAT_ATTENTION attention
-DEV_STAT_STAT_MOD status modifier
-DEV_STAT_CU_END control unit end
-DEV_STAT_BUSY busy
-DEV_STAT_CHN_END channel end
-DEV_STAT_DEV_END device end
-DEV_STAT_UNIT_CHECK unit check
-DEV_STAT_UNIT_EXCEP unit exception
-===================== =================
-
-Please see the ESA/390 Principles of Operation manual for details on the
-individual flag meanings.
-
-Usage Notes:
-
-ccw_device_start() must be called disabled and with the ccw device lock held.
-
-The device driver is allowed to issue the next ccw_device_start() call from
-within its interrupt handler already. It is not required to schedule a
-bottom-half, unless a non deterministically long running error recovery procedure
-or similar needs to be scheduled. During I/O processing the Linux/390 generic
-I/O device driver support has already obtained the IRQ lock, i.e. the handler
-must not try to obtain it again when calling ccw_device_start() or we end in a
-deadlock situation!
-
-If a device driver relies on an I/O request to be completed prior to start the
-next it can reduce I/O processing overhead by chaining a NoOp I/O command
-CCW_CMD_NOOP to the end of the submitted CCW chain. This will force Channel-End
-and Device-End status to be presented together, with a single interrupt.
-However, this should be used with care as it implies the channel will remain
-busy, not being able to process I/O requests for other devices on the same
-channel. Therefore e.g. read commands should never use this technique, as the
-result will be presented by a single interrupt anyway.
-
-In order to minimize I/O overhead, a device driver should use the
-DOIO_REPORT_ALL only if the device can report intermediate interrupt
-information prior to device-end the device driver urgently relies on. In this
-case all I/O interruptions are presented to the device driver until final
-status is recognized.
-
-If a device is able to recover from asynchronously presented I/O errors, it can
-perform overlapping I/O using the DOIO_EARLY_NOTIFICATION flag. While some
-devices always report channel-end and device-end together, with a single
-interrupt, others present primary status (channel-end) when the channel is
-ready for the next I/O request and secondary status (device-end) when the data
-transmission has been completed at the device.
-
-Above flag allows to exploit this feature, e.g. for communication devices that
-can handle lost data on the network to allow for enhanced I/O processing.
-
-Unless the channel subsystem at any time presents a secondary status interrupt,
-exploiting this feature will cause only primary status interrupts to be
-presented to the device driver while overlapping I/O is performed. When a
-secondary status without error (alert status) is presented, this indicates
-successful completion for all overlapping ccw_device_start() requests that have
-been issued since the last secondary (final) status.
-
-Channel programs that intend to set the suspend flag on a channel command word
-(CCW) must start the I/O operation with the DOIO_ALLOW_SUSPEND option or the
-suspend flag will cause a channel program check. At the time the channel program
-becomes suspended an intermediate interrupt will be generated by the channel
-subsystem.
-
-ccw_device_resume() - Resume Channel Program Execution
-
-If a device driver chooses to suspend the current channel program execution by
-setting the CCW suspend flag on a particular CCW, the channel program execution
-is suspended. In order to resume channel program execution the CIO layer
-provides the ccw_device_resume() routine.
-
-::
-
- int ccw_device_resume(struct ccw_device *cdev);
-
-==== ================================================
-cdev ccw_device the resume operation is requested for
-==== ================================================
-
-The ccw_device_resume() function returns:
-
-========= ==============================================
- 0 suspended channel program is resumed
- -EBUSY status pending
- -ENODEV cdev invalid or not-operational subchannel
- -EINVAL resume function not applicable
--ENOTCONN there is no I/O request pending for completion
-========= ==============================================
-
-Usage Notes:
-
-Please have a look at the ccw_device_start() usage notes for more details on
-suspended channel programs.
-
-ccw_device_halt() - Halt I/O Request Processing
-
-Sometimes a device driver might need a possibility to stop the processing of
-a long-running channel program or the device might require to initially issue
-a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt()
-command is provided.
-
-ccw_device_halt() must be called disabled and with the ccw device lock held.
-
-::
-
- int ccw_device_halt(struct ccw_device *cdev,
- unsigned long intparm);
-
-======= =====================================================
-cdev ccw_device the halt operation is requested for
-intparm interruption parameter; value is only used if no I/O
- is outstanding, otherwise the intparm associated with
- the I/O request is returned
-======= =====================================================
-
-The ccw_device_halt() function returns:
-
-======= ==============================================================
- 0 request successfully initiated
--EBUSY the device is currently busy, or status pending.
--ENODEV cdev invalid.
--EINVAL The device is not operational or the ccw device is not online.
-======= ==============================================================
-
-Usage Notes:
-
-A device driver may write a never-ending channel program by writing a channel
-program that at its end loops back to its beginning by means of a transfer in
-channel (TIC) command (CCW_CMD_TIC). Usually this is performed by network
-device drivers by setting the PCI CCW flag (CCW_FLAG_PCI). Once this CCW is
-executed a program controlled interrupt (PCI) is generated. The device driver
-can then perform an appropriate action. Prior to interrupt of an outstanding
-read to a network device (with or without PCI flag) a ccw_device_halt()
-is required to end the pending operation.
-
-::
-
- ccw_device_clear() - Terminage I/O Request Processing
-
-In order to terminate all I/O processing at the subchannel, the clear subchannel
-(CSCH) command is used. It can be issued via ccw_device_clear().
-
-ccw_device_clear() must be called disabled and with the ccw device lock held.
-
-::
-
- int ccw_device_clear(struct ccw_device *cdev, unsigned long intparm);
-
-======= ===============================================
-cdev ccw_device the clear operation is requested for
-intparm interruption parameter (see ccw_device_halt())
-======= ===============================================
-
-The ccw_device_clear() function returns:
-
-======= ==============================================================
- 0 request successfully initiated
--ENODEV cdev invalid
--EINVAL The device is not operational or the ccw device is not online.
-======= ==============================================================
-
-Miscellaneous Support Routines
-------------------------------
-
-This chapter describes various routines to be used in a Linux/390 device
-driver programming environment.
-
-get_ccwdev_lock()
-
-Get the address of the device specific lock. This is then used in
-spin_lock() / spin_unlock() calls.
-
-::
-
- __u8 ccw_device_get_path_mask(struct ccw_device *cdev);
-
-Get the mask of the path currently available for cdev.
diff --git a/Documentation/s390/common_io.rst b/Documentation/s390/common_io.rst
deleted file mode 100644
index 8464856..0000000
--- a/Documentation/s390/common_io.rst
+++ /dev/null
@@ -1,140 +0,0 @@
-======================
-S/390 common I/O-Layer
-======================
-
-command line parameters, procfs and debugfs entries
-===================================================
-
-Command line parameters
------------------------
-
-* ccw_timeout_log
-
- Enable logging of debug information in case of ccw device timeouts.
-
-* cio_ignore = device[,device[,..]]
-
- device := {all | [!]ipldev | [!]condev | [!]<devno> | [!]<devno>-<devno>}
-
- The given devices will be ignored by the common I/O-layer; no detection
- and device sensing will be done on any of those devices. The subchannel to
- which the device in question is attached will be treated as if no device was
- attached.
-
- An ignored device can be un-ignored later; see the "/proc entries"-section for
- details.
-
- The devices must be given either as bus ids (0.x.abcd) or as hexadecimal
- device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
- give a device number 0xabcd, it will be interpreted as 0.0.abcd.
-
- You can use the 'all' keyword to ignore all devices. The 'ipldev' and 'condev'
- keywords can be used to refer to the CCW based boot device and CCW console
- device respectively (these are probably useful only when combined with the '!'
- operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.
- The command line
- is parsed from left to right.
-
- For example::
-
- cio_ignore=0.0.0023-0.0.0042,0.0.4711
-
- will ignore all devices ranging from 0.0.0023 to 0.0.0042 and the device
- 0.0.4711, if detected.
-
- As another example::
-
- cio_ignore=all,!0.0.4711,!0.0.fd00-0.0.fd02
-
- will ignore all devices but 0.0.4711, 0.0.fd00, 0.0.fd01, 0.0.fd02.
-
- By default, no devices are ignored.
-
-
-/proc entries
--------------
-
-* /proc/cio_ignore
-
- Lists the ranges of devices (by bus id) which are ignored by common I/O.
-
- You can un-ignore certain or all devices by piping to /proc/cio_ignore.
- "free all" will un-ignore all ignored devices,
- "free <device range>, <device range>, ..." will un-ignore the specified
- devices.
-
- For example, if devices 0.0.0023 to 0.0.0042 and 0.0.4711 are ignored,
-
- - echo free 0.0.0030-0.0.0032 > /proc/cio_ignore
- will un-ignore devices 0.0.0030 to 0.0.0032 and will leave devices 0.0.0023
- to 0.0.002f, 0.0.0033 to 0.0.0042 and 0.0.4711 ignored;
- - echo free 0.0.0041 > /proc/cio_ignore will furthermore un-ignore device
- 0.0.0041;
- - echo free all > /proc/cio_ignore will un-ignore all remaining ignored
- devices.
-
- When a device is un-ignored, device recognition and sensing is performed and
- the device driver will be notified if possible, so the device will become
- available to the system. Note that un-ignoring is performed asynchronously.
-
- You can also add ranges of devices to be ignored by piping to
- /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
- specified devices.
-
- Note: While already known devices can be added to the list of devices to be
- ignored, there will be no effect on then. However, if such a device
- disappears and then reappears, it will then be ignored. To make
- known devices go away, you need the "purge" command (see below).
-
- For example::
-
- "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
-
- will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
- devices.
-
- You can remove already known but now ignored devices via::
-
- "echo purge > /proc/cio_ignore"
-
- All devices ignored but still registered and not online (= not in use)
- will be deregistered and thus removed from the system.
-
- The devices can be specified either by bus id (0.x.abcd) or, for 2.4 backward
- compatibility, by the device number in hexadecimal (0xabcd or abcd). Device
- numbers given as 0xabcd will be interpreted as 0.0.abcd.
-
-* /proc/cio_settle
-
- A write request to this file is blocked until all queued cio actions are
- handled. This will allow userspace to wait for pending work affecting
- device availability after changing cio_ignore or the hardware configuration.
-
-* For some of the information present in the /proc filesystem in 2.4 (namely,
- /proc/subchannels and /proc/chpids), see driver-model.txt.
- Information formerly in /proc/irq_count is now in /proc/interrupts.
-
-
-debugfs entries
----------------
-
-* /sys/kernel/debug/s390dbf/cio_*/ (S/390 debug feature)
-
- Some views generated by the debug feature to hold various debug outputs.
-
- - /sys/kernel/debug/s390dbf/cio_crw/sprintf
- Messages from the processing of pending channel report words (machine check
- handling).
-
- - /sys/kernel/debug/s390dbf/cio_msg/sprintf
- Various debug messages from the common I/O-layer.
-
- - /sys/kernel/debug/s390dbf/cio_trace/hex_ascii
- Logs the calling of functions in the common I/O-layer and, if applicable,
- which subchannel they were called for, as well as dumps of some data
- structures (like irb in an error case).
-
- The level of logging can be changed to be more or less verbose by piping to
- /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
- documentation on the S/390 debug feature (Documentation/s390/s390dbf.rst)
- for details.
diff --git a/Documentation/s390/pci.rst b/Documentation/s390/pci.rst
deleted file mode 100644
index a1a72a4..0000000
--- a/Documentation/s390/pci.rst
+++ /dev/null
@@ -1,133 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=========
-S/390 PCI
-=========
-
-Authors:
- - Pierre Morel
-
-Copyright, IBM Corp. 2020
-
-
-Command line parameters and debugfs entries
-===========================================
-
-Command line parameters
------------------------
-
-* nomio
-
- Do not use PCI Mapped I/O (MIO) instructions.
-
-* norid
-
- Ignore the RID field and force use of one PCI domain per PCI function.
-
-debugfs entries
----------------
-
-The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form:
-
- * /sys/kernel/debug/s390dbf/pci_*/
-
-For example:
-
- - /sys/kernel/debug/s390dbf/pci_msg/sprintf
- Holds messages from the processing of PCI events, like machine check handling
- and setting of global functionality, like UID checking.
-
- Change the level of logging to be more or less verbose by piping
- a number between 0 and 6 to /sys/kernel/debug/s390dbf/pci_*/level. For
- details, see the documentation on the S/390 debug feature at
- Documentation/s390/s390dbf.rst.
-
-Sysfs entries
-=============
-
-Entries specific to zPCI functions and entries that hold zPCI information.
-
-* /sys/bus/pci/slots/XXXXXXXX
-
- The slot entries are set up using the function identifier (FID) of the
- PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
- with 0 padding and lower case hexadecimal digits.
-
- - /sys/bus/pci/slots/XXXXXXXX/power
-
- A physical function that currently supports a virtual function cannot be
- powered off until all virtual functions are removed with:
- echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf
-
-* /sys/bus/pci/devices/XXXX:XX:XX.X/
-
- - function_id
- A zPCI function identifier that uniquely identifies the function in the Z server.
-
- - function_handle
- Low-level identifier used for a configured PCI function.
- It might be useful for debugging.
-
- - pchid
- Model-dependent location of the I/O adapter.
-
- - pfgid
- PCI function group ID, functions that share identical functionality
- use a common identifier.
- A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics.
-
- - vfn
- The virtual function number, from 1 to N for virtual functions,
- 0 for physical functions.
-
- - pft
- The PCI function type
-
- - port
- The port corresponds to the physical port the function is attached to.
- It also gives an indication of the physical function a virtual function
- is attached to.
-
- - uid
- The user identifier (UID) may be defined as part of the machine
- configuration or the z/VM or KVM guest configuration. If the accompanying
- uid_is_unique attribute is 1 the platform guarantees that the UID is unique
- within that instance and no devices with the same UID can be attached
- during the lifetime of the system.
-
- - uid_is_unique
- Indicates whether the user identifier (UID) is guaranteed to be and remain
- unique within this Linux instance.
-
- - pfip/segmentX
- The segments determine the isolation of a function.
- They correspond to the physical path to the function.
- The more the segments are different, the more the functions are isolated.
-
-Enumeration and hotplug
-=======================
-
-The PCI address consists of four parts: domain, bus, device and function,
-and is of this form: DDDD:BB:dd.f
-
-* When not using multi-functions (norid is set, or the firmware does not
- support multi-functions):
-
- - There is only one function per domain.
-
- - The domain is set from the zPCI function's UID as defined during the
- LPAR creation.
-
-* When using multi-functions (norid parameter is not set),
- zPCI functions are addressed differently:
-
- - There is still only one bus per domain.
-
- - There can be up to 256 functions per bus.
-
- - The domain part of the address of all functions for
- a multi-Function device is set from the zPCI function's UID as defined
- in the LPAR creation for the function zero.
-
- - New functions will only be ready for use after the function zero
- (the function with devfn 0) has been enumerated.
diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst
deleted file mode 100644
index bb3f4c4..0000000
--- a/Documentation/s390/vfio-ap.rst
+++ /dev/null
@@ -1,1069 +0,0 @@
-===============================
-Adjunct Processor (AP) facility
-===============================
-
-
-Introduction
-============
-The Adjunct Processor (AP) facility is an IBM Z cryptographic facility comprised
-of three AP instructions and from 1 up to 256 PCIe cryptographic adapter cards.
-The AP devices provide cryptographic functions to all CPUs assigned to a
-linux system running in an IBM Z system LPAR.
-
-The AP adapter cards are exposed via the AP bus. The motivation for vfio-ap
-is to make AP cards available to KVM guests using the VFIO mediated device
-framework. This implementation relies considerably on the s390 virtualization
-facilities which do most of the hard work of providing direct access to AP
-devices.
-
-AP Architectural Overview
-=========================
-To facilitate the comprehension of the design, let's start with some
-definitions:
-
-* AP adapter
-
- An AP adapter is an IBM Z adapter card that can perform cryptographic
- functions. There can be from 0 to 256 adapters assigned to an LPAR. Adapters
- assigned to the LPAR in which a linux host is running will be available to
- the linux host. Each adapter is identified by a number from 0 to 255; however,
- the maximum adapter number is determined by machine model and/or adapter type.
- When installed, an AP adapter is accessed by AP instructions executed by any
- CPU.
-
- The AP adapter cards are assigned to a given LPAR via the system's Activation
- Profile which can be edited via the HMC. When the linux host system is IPL'd
- in the LPAR, the AP bus detects the AP adapter cards assigned to the LPAR and
- creates a sysfs device for each assigned adapter. For example, if AP adapters
- 4 and 10 (0x0a) are assigned to the LPAR, the AP bus will create the following
- sysfs device entries::
-
- /sys/devices/ap/card04
- /sys/devices/ap/card0a
-
- Symbolic links to these devices will also be created in the AP bus devices
- sub-directory::
-
- /sys/bus/ap/devices/[card04]
- /sys/bus/ap/devices/[card04]
-
-* AP domain
-
- An adapter is partitioned into domains. An adapter can hold up to 256 domains
- depending upon the adapter type and hardware configuration. A domain is
- identified by a number from 0 to 255; however, the maximum domain number is
- determined by machine model and/or adapter type.. A domain can be thought of
- as a set of hardware registers and memory used for processing AP commands. A
- domain can be configured with a secure private key used for clear key
- encryption. A domain is classified in one of two ways depending upon how it
- may be accessed:
-
- * Usage domains are domains that are targeted by an AP instruction to
- process an AP command.
-
- * Control domains are domains that are changed by an AP command sent to a
- usage domain; for example, to set the secure private key for the control
- domain.
-
- The AP usage and control domains are assigned to a given LPAR via the system's
- Activation Profile which can be edited via the HMC. When a linux host system
- is IPL'd in the LPAR, the AP bus module detects the AP usage and control
- domains assigned to the LPAR. The domain number of each usage domain and
- adapter number of each AP adapter are combined to create AP queue devices
- (see AP Queue section below). The domain number of each control domain will be
- represented in a bitmask and stored in a sysfs file
- /sys/bus/ap/ap_control_domain_mask. The bits in the mask, from most to least
- significant bit, correspond to domains 0-255.
-
-* AP Queue
-
- An AP queue is the means by which an AP command is sent to a usage domain
- inside a specific adapter. An AP queue is identified by a tuple
- comprised of an AP adapter ID (APID) and an AP queue index (APQI). The
- APQI corresponds to a given usage domain number within the adapter. This tuple
- forms an AP Queue Number (APQN) uniquely identifying an AP queue. AP
- instructions include a field containing the APQN to identify the AP queue to
- which the AP command is to be sent for processing.
-
- The AP bus will create a sysfs device for each APQN that can be derived from
- the cross product of the AP adapter and usage domain numbers detected when the
- AP bus module is loaded. For example, if adapters 4 and 10 (0x0a) and usage
- domains 6 and 71 (0x47) are assigned to the LPAR, the AP bus will create the
- following sysfs entries::
-
- /sys/devices/ap/card04/04.0006
- /sys/devices/ap/card04/04.0047
- /sys/devices/ap/card0a/0a.0006
- /sys/devices/ap/card0a/0a.0047
-
- The following symbolic links to these devices will be created in the AP bus
- devices subdirectory::
-
- /sys/bus/ap/devices/[04.0006]
- /sys/bus/ap/devices/[04.0047]
- /sys/bus/ap/devices/[0a.0006]
- /sys/bus/ap/devices/[0a.0047]
-
-* AP Instructions:
-
- There are three AP instructions:
-
- * NQAP: to enqueue an AP command-request message to a queue
- * DQAP: to dequeue an AP command-reply message from a queue
- * PQAP: to administer the queues
-
- AP instructions identify the domain that is targeted to process the AP
- command; this must be one of the usage domains. An AP command may modify a
- domain that is not one of the usage domains, but the modified domain
- must be one of the control domains.
-
-AP and SIE
-==========
-Let's now take a look at how AP instructions executed on a guest are interpreted
-by the hardware.
-
-A satellite control block called the Crypto Control Block (CRYCB) is attached to
-our main hardware virtualization control block. The CRYCB contains an AP Control
-Block (APCB) that has three fields to identify the adapters, usage domains and
-control domains assigned to the KVM guest:
-
-* The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned
- to the KVM guest. Each bit in the mask, from left to right, corresponds to
- an APID from 0-255. If a bit is set, the corresponding adapter is valid for
- use by the KVM guest.
-
-* The AP Queue Mask (AQM) field is a bit mask identifying the AP usage domains
- assigned to the KVM guest. Each bit in the mask, from left to right,
- corresponds to an AP queue index (APQI) from 0-255. If a bit is set, the
- corresponding queue is valid for use by the KVM guest.
-
-* The AP Domain Mask field is a bit mask that identifies the AP control domains
- assigned to the KVM guest. The ADM bit mask controls which domains can be
- changed by an AP command-request message sent to a usage domain from the
- guest. Each bit in the mask, from left to right, corresponds to a domain from
- 0-255. If a bit is set, the corresponding domain can be modified by an AP
- command-request message sent to a usage domain.
-
-If you recall from the description of an AP Queue, AP instructions include
-an APQN to identify the AP queue to which an AP command-request message is to be
-sent (NQAP and PQAP instructions), or from which a command-reply message is to
-be received (DQAP instruction). The validity of an APQN is defined by the matrix
-calculated from the APM and AQM; it is the Cartesian product of all assigned
-adapter numbers (APM) with all assigned queue indexes (AQM). For example, if
-adapters 1 and 2 and usage domains 5 and 6 are assigned to a guest, the APQNs
-(1,5), (1,6), (2,5) and (2,6) will be valid for the guest.
-
-The APQNs can provide secure key functionality - i.e., a private key is stored
-on the adapter card for each of its domains - so each APQN must be assigned to
-at most one guest or to the linux host::
-
- Example 1: Valid configuration:
- ------------------------------
- Guest1: adapters 1,2 domains 5,6
- Guest2: adapter 1,2 domain 7
-
- This is valid because both guests have a unique set of APQNs:
- Guest1 has APQNs (1,5), (1,6), (2,5), (2,6);
- Guest2 has APQNs (1,7), (2,7)
-
- Example 2: Valid configuration:
- ------------------------------
- Guest1: adapters 1,2 domains 5,6
- Guest2: adapters 3,4 domains 5,6
-
- This is also valid because both guests have a unique set of APQNs:
- Guest1 has APQNs (1,5), (1,6), (2,5), (2,6);
- Guest2 has APQNs (3,5), (3,6), (4,5), (4,6)
-
- Example 3: Invalid configuration:
- --------------------------------
- Guest1: adapters 1,2 domains 5,6
- Guest2: adapter 1 domains 6,7
-
- This is an invalid configuration because both guests have access to
- APQN (1,6).
-
-The Design
-==========
-The design introduces three new objects:
-
-1. AP matrix device
-2. VFIO AP device driver (vfio_ap.ko)
-3. VFIO AP mediated pass-through device
-
-The VFIO AP device driver
--------------------------
-The VFIO AP (vfio_ap) device driver serves the following purposes:
-
-1. Provides the interfaces to secure APQNs for exclusive use of KVM guests.
-
-2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated
- device and creates the sysfs interfaces for assigning adapters, usage
- domains, and control domains comprising the matrix for a KVM guest.
-
-3. Configures the APM, AQM and ADM in the APCB contained in the CRYCB referenced
- by a KVM guest's SIE state description to grant the guest access to a matrix
- of AP devices
-
-Reserve APQNs for exclusive use of KVM guests
----------------------------------------------
-The following block diagram illustrates the mechanism by which APQNs are
-reserved::
-
- +------------------+
- 7 remove | |
- +--------------------> cex4queue driver |
- | | |
- | +------------------+
- |
- |
- | +------------------+ +----------------+
- | 5 register driver | | 3 create | |
- | +----------------> Device core +----------> matrix device |
- | | | | | |
- | | +--------^---------+ +----------------+
- | | |
- | | +-------------------+
- | | +-----------------------------------+ |
- | | | 4 register AP driver | | 2 register device
- | | | | |
- +--------+---+-v---+ +--------+-------+-+
- | | | |
- | ap_bus +--------------------- > vfio_ap driver |
- | | 8 probe | |
- +--------^---------+ +--^--^------------+
- 6 edit | | |
- apmask | +-----------------------------+ | 11 mdev create
- aqmask | | 1 modprobe |
- +--------+-----+---+ +----------------+-+ +----------------+
- | | | |10 create| mediated |
- | admin | | VFIO device core |---------> matrix |
- | + | | | device |
- +------+-+---------+ +--------^---------+ +--------^-------+
- | | | |
- | | 9 create vfio_ap-passthrough | |
- | +------------------------------+ |
- +-------------------------------------------------------------+
- 12 assign adapter/domain/control domain
-
-The process for reserving an AP queue for use by a KVM guest is:
-
-1. The administrator loads the vfio_ap device driver
-2. The vfio-ap driver during its initialization will register a single 'matrix'
- device with the device core. This will serve as the parent device for
- all vfio_ap mediated devices used to configure an AP matrix for a guest.
-3. The /sys/devices/vfio_ap/matrix device is created by the device core
-4. The vfio_ap device driver will register with the AP bus for AP queue devices
- of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap
- driver's probe and remove callback interfaces. Devices older than CEX4 queues
- are not supported to simplify the implementation by not needlessly
- complicating the design by supporting older devices that will go out of
- service in the relatively near future, and for which there are few older
- systems around on which to test.
-5. The AP bus registers the vfio_ap device driver with the device core
-6. The administrator edits the AP adapter and queue masks to reserve AP queues
- for use by the vfio_ap device driver.
-7. The AP bus removes the AP queues reserved for the vfio_ap driver from the
- default zcrypt cex4queue driver.
-8. The AP bus probes the vfio_ap device driver to bind the queues reserved for
- it.
-9. The administrator creates a passthrough type vfio_ap mediated device to be
- used by a guest
-10. The administrator assigns the adapters, usage domains and control domains
- to be exclusively used by a guest.
-
-Set up the VFIO mediated device interfaces
-------------------------------------------
-The VFIO AP device driver utilizes the common interfaces of the VFIO mediated
-device core driver to:
-
-* Register an AP mediated bus driver to add a vfio_ap mediated device to and
- remove it from a VFIO group.
-* Create and destroy a vfio_ap mediated device
-* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver
-* Add a vfio_ap mediated device to and remove it from an IOMMU group
-
-The following high-level block diagram shows the main components and interfaces
-of the VFIO AP mediated device driver::
-
- +-------------+
- | |
- | +---------+ | mdev_register_driver() +--------------+
- | | Mdev | +<-----------------------+ |
- | | bus | | | vfio_mdev.ko |
- | | driver | +----------------------->+ |<-> VFIO user
- | +---------+ | probe()/remove() +--------------+ APIs
- | |
- | MDEV CORE |
- | MODULE |
- | mdev.ko |
- | +---------+ | mdev_register_parent() +--------------+
- | |Physical | +<-----------------------+ |
- | | device | | | vfio_ap.ko |<-> matrix
- | |interface| +----------------------->+ | device
- | +---------+ | callback +--------------+
- +-------------+
-
-During initialization of the vfio_ap module, the matrix device is registered
-with an 'mdev_parent_ops' structure that provides the sysfs attribute
-structures, mdev functions and callback interfaces for managing the mediated
-matrix device.
-
-* sysfs attribute structures:
-
- supported_type_groups
- The VFIO mediated device framework supports creation of user-defined
- mediated device types. These mediated device types are specified
- via the 'supported_type_groups' structure when a device is registered
- with the mediated device framework. The registration process creates the
- sysfs structures for each mediated device type specified in the
- 'mdev_supported_types' sub-directory of the device being registered. Along
- with the device type, the sysfs attributes of the mediated device type are
- provided.
-
- The VFIO AP device driver will register one mediated device type for
- passthrough devices:
-
- /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough
-
- Only the read-only attributes required by the VFIO mdev framework will
- be provided::
-
- ... name
- ... device_api
- ... available_instances
- ... device_api
-
- Where:
-
- * name:
- specifies the name of the mediated device type
- * device_api:
- the mediated device type's API
- * available_instances:
- the number of vfio_ap mediated passthrough devices
- that can be created
- * device_api:
- specifies the VFIO API
- mdev_attr_groups
- This attribute group identifies the user-defined sysfs attributes of the
- mediated device. When a device is registered with the VFIO mediated device
- framework, the sysfs attribute files identified in the 'mdev_attr_groups'
- structure will be created in the vfio_ap mediated device's directory. The
- sysfs attributes for a vfio_ap mediated device are:
-
- assign_adapter / unassign_adapter:
- Write-only attributes for assigning/unassigning an AP adapter to/from the
- vfio_ap mediated device. To assign/unassign an adapter, the APID of the
- adapter is echoed into the respective attribute file.
- assign_domain / unassign_domain:
- Write-only attributes for assigning/unassigning an AP usage domain to/from
- the vfio_ap mediated device. To assign/unassign a domain, the domain
- number of the usage domain is echoed into the respective attribute
- file.
- matrix:
- A read-only file for displaying the APQNs derived from the Cartesian
- product of the adapter and domain numbers assigned to the vfio_ap mediated
- device.
- guest_matrix:
- A read-only file for displaying the APQNs derived from the Cartesian
- product of the adapter and domain numbers assigned to the APM and AQM
- fields respectively of the KVM guest's CRYCB. This may differ from the
- the APQNs assigned to the vfio_ap mediated device if any APQN does not
- reference a queue device bound to the vfio_ap device driver (i.e., the
- queue is not in the host's AP configuration).
- assign_control_domain / unassign_control_domain:
- Write-only attributes for assigning/unassigning an AP control domain
- to/from the vfio_ap mediated device. To assign/unassign a control domain,
- the ID of the domain to be assigned/unassigned is echoed into the
- respective attribute file.
- control_domains:
- A read-only file for displaying the control domain numbers assigned to the
- vfio_ap mediated device.
-
-* functions:
-
- create:
- allocates the ap_matrix_mdev structure used by the vfio_ap driver to:
-
- * Store the reference to the KVM structure for the guest using the mdev
- * Store the AP matrix configuration for the adapters, domains, and control
- domains assigned via the corresponding sysfs attributes files
- * Store the AP matrix configuration for the adapters, domains and control
- domains available to a guest. A guest may not be provided access to APQNs
- referencing queue devices that do not exist, or are not bound to the
- vfio_ap device driver.
-
- remove:
- deallocates the vfio_ap mediated device's ap_matrix_mdev structure.
- This will be allowed only if a running guest is not using the mdev.
-
-* callback interfaces
-
- open_device:
- The vfio_ap driver uses this callback to register a
- VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the matrix mdev
- devices. The open_device callback is invoked by userspace to connect the
- VFIO iommu group for the matrix mdev device to the MDEV bus. Access to the
- KVM structure used to configure the KVM guest is provided via this callback.
- The KVM structure, is used to configure the guest's access to the AP matrix
- defined via the vfio_ap mediated device's sysfs attribute files.
-
- close_device:
- unregisters the VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the
- matrix mdev device and deconfigures the guest's AP matrix.
-
- ioctl:
- this callback handles the VFIO_DEVICE_GET_INFO and VFIO_DEVICE_RESET ioctls
- defined by the vfio framework.
-
-Configure the guest's AP resources
-----------------------------------
-Configuring the AP resources for a KVM guest will be performed when the
-VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier
-function is called when userspace connects to KVM. The guest's AP resources are
-configured via it's APCB by:
-
-* Setting the bits in the APM corresponding to the APIDs assigned to the
- vfio_ap mediated device via its 'assign_adapter' interface.
-* Setting the bits in the AQM corresponding to the domains assigned to the
- vfio_ap mediated device via its 'assign_domain' interface.
-* Setting the bits in the ADM corresponding to the domain dIDs assigned to the
- vfio_ap mediated device via its 'assign_control_domains' interface.
-
-The linux device model precludes passing a device through to a KVM guest that
-is not bound to the device driver facilitating its pass-through. Consequently,
-an APQN that does not reference a queue device bound to the vfio_ap device
-driver will not be assigned to a KVM guest's matrix. The AP architecture,
-however, does not provide a means to filter individual APQNs from the guest's
-matrix, so the adapters, domains and control domains assigned to vfio_ap
-mediated device via its sysfs 'assign_adapter', 'assign_domain' and
-'assign_control_domain' interfaces will be filtered before providing the AP
-configuration to a guest:
-
-* The APIDs of the adapters, the APQIs of the domains and the domain numbers of
- the control domains assigned to the matrix mdev that are not also assigned to
- the host's AP configuration will be filtered.
-
-* Each APQN derived from the Cartesian product of the APIDs and APQIs assigned
- to the vfio_ap mdev is examined and if any one of them does not reference a
- queue device bound to the vfio_ap device driver, the adapter will not be
- plugged into the guest (i.e., the bit corresponding to its APID will not be
- set in the APM of the guest's APCB).
-
-The CPU model features for AP
------------------------------
-The AP stack relies on the presence of the AP instructions as well as three
-facilities: The AP Facilities Test (APFT) facility; the AP Query
-Configuration Information (QCI) facility; and the AP Queue Interruption Control
-facility. These features/facilities are made available to a KVM guest via the
-following CPU model features:
-
-1. ap: Indicates whether the AP instructions are installed on the guest. This
- feature will be enabled by KVM only if the AP instructions are installed
- on the host.
-
-2. apft: Indicates the APFT facility is available on the guest. This facility
- can be made available to the guest only if it is available on the host (i.e.,
- facility bit 15 is set).
-
-3. apqci: Indicates the AP QCI facility is available on the guest. This facility
- can be made available to the guest only if it is available on the host (i.e.,
- facility bit 12 is set).
-
-4. apqi: Indicates AP Queue Interruption Control faclity is available on the
- guest. This facility can be made available to the guest only if it is
- available on the host (i.e., facility bit 65 is set).
-
-Note: If the user chooses to specify a CPU model different than the 'host'
-model to QEMU, the CPU model features and facilities need to be turned on
-explicitly; for example::
-
- /usr/bin/qemu-system-s390x ... -cpu z13,ap=on,apqci=on,apft=on,apqi=on
-
-A guest can be precluded from using AP features/facilities by turning them off
-explicitly; for example::
-
- /usr/bin/qemu-system-s390x ... -cpu host,ap=off,apqci=off,apft=off,apqi=off
-
-Note: If the APFT facility is turned off (apft=off) for the guest, the guest
-will not see any AP devices. The zcrypt device drivers on the guest that
-register for type 10 and newer AP devices - i.e., the cex4card and cex4queue
-device drivers - need the APFT facility to ascertain the facilities installed on
-a given AP device. If the APFT facility is not installed on the guest, then no
-adapter or domain devices will get created by the AP bus running on the
-guest because only type 10 and newer devices can be configured for guest use.
-
-Example
-=======
-Let's now provide an example to illustrate how KVM guests may be given
-access to AP facilities. For this example, we will show how to configure
-three guests such that executing the lszcrypt command on the guests would
-look like this:
-
-Guest1
-------
-=========== ===== ============
-CARD.DOMAIN TYPE MODE
-=========== ===== ============
-05 CEX5C CCA-Coproc
-05.0004 CEX5C CCA-Coproc
-05.00ab CEX5C CCA-Coproc
-06 CEX5A Accelerator
-06.0004 CEX5A Accelerator
-06.00ab CEX5A Accelerator
-=========== ===== ============
-
-Guest2
-------
-=========== ===== ============
-CARD.DOMAIN TYPE MODE
-=========== ===== ============
-05 CEX5C CCA-Coproc
-05.0047 CEX5C CCA-Coproc
-05.00ff CEX5C CCA-Coproc
-=========== ===== ============
-
-Guest3
-------
-=========== ===== ============
-CARD.DOMAIN TYPE MODE
-=========== ===== ============
-06 CEX5A Accelerator
-06.0047 CEX5A Accelerator
-06.00ff CEX5A Accelerator
-=========== ===== ============
-
-These are the steps:
-
-1. Install the vfio_ap module on the linux host. The dependency chain for the
- vfio_ap module is:
- * iommu
- * s390
- * zcrypt
- * vfio
- * vfio_mdev
- * vfio_mdev_device
- * KVM
-
- To build the vfio_ap module, the kernel build must be configured with the
- following Kconfig elements selected:
- * IOMMU_SUPPORT
- * S390
- * ZCRYPT
- * VFIO
- * KVM
-
- If using make menuconfig select the following to build the vfio_ap module::
-
- -> Device Drivers
- -> IOMMU Hardware Support
- select S390 AP IOMMU Support
- -> VFIO Non-Privileged userspace driver framework
- -> Mediated device driver frramework
- -> VFIO driver for Mediated devices
- -> I/O subsystem
- -> VFIO support for AP devices
-
-2. Secure the AP queues to be used by the three guests so that the host can not
- access them. To secure them, there are two sysfs files that specify
- bitmasks marking a subset of the APQN range as usable only by the default AP
- queue device drivers. All remaining APQNs are available for use by
- any other device driver. The vfio_ap device driver is currently the only
- non-default device driver. The location of the sysfs files containing the
- masks are::
-
- /sys/bus/ap/apmask
- /sys/bus/ap/aqmask
-
- The 'apmask' is a 256-bit mask that identifies a set of AP adapter IDs
- (APID). Each bit in the mask, from left to right, corresponds to an APID from
- 0-255. If a bit is set, the APID belongs to the subset of APQNs marked as
- available only to the default AP queue device drivers.
-
- The 'aqmask' is a 256-bit mask that identifies a set of AP queue indexes
- (APQI). Each bit in the mask, from left to right, corresponds to an APQI from
- 0-255. If a bit is set, the APQI belongs to the subset of APQNs marked as
- available only to the default AP queue device drivers.
-
- The Cartesian product of the APIDs corresponding to the bits set in the
- apmask and the APQIs corresponding to the bits set in the aqmask comprise
- the subset of APQNs that can be used only by the host default device drivers.
- All other APQNs are available to the non-default device drivers such as the
- vfio_ap driver.
-
- Take, for example, the following masks::
-
- apmask:
- 0x7d00000000000000000000000000000000000000000000000000000000000000
-
- aqmask:
- 0x8000000000000000000000000000000000000000000000000000000000000000
-
- The masks indicate:
-
- * Adapters 1, 2, 3, 4, 5, and 7 are available for use by the host default
- device drivers.
-
- * Domain 0 is available for use by the host default device drivers
-
- * The subset of APQNs available for use only by the default host device
- drivers are:
-
- (1,0), (2,0), (3,0), (4.0), (5,0) and (7,0)
-
- * All other APQNs are available for use by the non-default device drivers.
-
- The APQN of each AP queue device assigned to the linux host is checked by the
- AP bus against the set of APQNs derived from the Cartesian product of APIDs
- and APQIs marked as available to the default AP queue device drivers. If a
- match is detected, only the default AP queue device drivers will be probed;
- otherwise, the vfio_ap device driver will be probed.
-
- By default, the two masks are set to reserve all APQNs for use by the default
- AP queue device drivers. There are two ways the default masks can be changed:
-
- 1. The sysfs mask files can be edited by echoing a string into the
- respective sysfs mask file in one of two formats:
-
- * An absolute hex string starting with 0x - like "0x12345678" - sets
- the mask. If the given string is shorter than the mask, it is padded
- with 0s on the right; for example, specifying a mask value of 0x41 is
- the same as specifying::
-
- 0x4100000000000000000000000000000000000000000000000000000000000000
-
- Keep in mind that the mask reads from left to right, so the mask
- above identifies device numbers 1 and 7 (01000001).
-
- If the string is longer than the mask, the operation is terminated with
- an error (EINVAL).
-
- * Individual bits in the mask can be switched on and off by specifying
- each bit number to be switched in a comma separated list. Each bit
- number string must be prepended with a ('+') or minus ('-') to indicate
- the corresponding bit is to be switched on ('+') or off ('-'). Some
- valid values are:
-
- - "+0" switches bit 0 on
- - "-13" switches bit 13 off
- - "+0x41" switches bit 65 on
- - "-0xff" switches bit 255 off
-
- The following example:
-
- +0,-6,+0x47,-0xf0
-
- Switches bits 0 and 71 (0x47) on
-
- Switches bits 6 and 240 (0xf0) off
-
- Note that the bits not specified in the list remain as they were before
- the operation.
-
- 2. The masks can also be changed at boot time via parameters on the kernel
- command line like this:
-
- ap.apmask=0xffff ap.aqmask=0x40
-
- This would create the following masks::
-
- apmask:
- 0xffff000000000000000000000000000000000000000000000000000000000000
-
- aqmask:
- 0x4000000000000000000000000000000000000000000000000000000000000000
-
- Resulting in these two pools::
-
- default drivers pool: adapter 0-15, domain 1
- alternate drivers pool: adapter 16-255, domains 0, 2-255
-
- **Note:**
- Changing a mask such that one or more APQNs will be taken from a vfio_ap
- mediated device (see below) will fail with an error (EBUSY). A message
- is logged to the kernel ring buffer which can be viewed with the 'dmesg'
- command. The output identifies each APQN flagged as 'in use' and identifies
- the vfio_ap mediated device to which it is assigned; for example:
-
- Userspace may not re-assign queue 05.0054 already assigned to 62177883-f1bb-47f0-914d-32a22e3a8804
- Userspace may not re-assign queue 04.0054 already assigned to cef03c3c-903d-4ecc-9a83-40694cb8aee4
-
-Securing the APQNs for our example
-----------------------------------
- To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047,
- 06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding
- APQNs can be removed from the default masks using either of the following
- commands::
-
- echo -5,-6 > /sys/bus/ap/apmask
-
- echo -4,-0x47,-0xab,-0xff > /sys/bus/ap/aqmask
-
- Or the masks can be set as follows::
-
- echo 0xf9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
- > apmask
-
- echo 0xf7fffffffffffffffeffffffffffffffffffffffffeffffffffffffffffffffe \
- > aqmask
-
- This will result in AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004,
- 06.0047, 06.00ab, and 06.00ff getting bound to the vfio_ap device driver. The
- sysfs directory for the vfio_ap device driver will now contain symbolic links
- to the AP queue devices bound to it::
-
- /sys/bus/ap
- ... [drivers]
- ...... [vfio_ap]
- ......... [05.0004]
- ......... [05.0047]
- ......... [05.00ab]
- ......... [05.00ff]
- ......... [06.0004]
- ......... [06.0047]
- ......... [06.00ab]
- ......... [06.00ff]
-
- Keep in mind that only type 10 and newer adapters (i.e., CEX4 and later)
- can be bound to the vfio_ap device driver. The reason for this is to
- simplify the implementation by not needlessly complicating the design by
- supporting older devices that will go out of service in the relatively near
- future and for which there are few older systems on which to test.
-
- The administrator, therefore, must take care to secure only AP queues that
- can be bound to the vfio_ap device driver. The device type for a given AP
- queue device can be read from the parent card's sysfs directory. For example,
- to see the hardware type of the queue 05.0004:
-
- cat /sys/bus/ap/devices/card05/hwtype
-
- The hwtype must be 10 or higher (CEX4 or newer) in order to be bound to the
- vfio_ap device driver.
-
-3. Create the mediated devices needed to configure the AP matrixes for the
- three guests and to provide an interface to the vfio_ap driver for
- use by the guests::
-
- /sys/devices/vfio_ap/matrix/
- --- [mdev_supported_types]
- ------ [vfio_ap-passthrough] (passthrough vfio_ap mediated device type)
- --------- create
- --------- [devices]
-
- To create the mediated devices for the three guests::
-
- uuidgen > create
- uuidgen > create
- uuidgen > create
-
- or
-
- echo $uuid1 > create
- echo $uuid2 > create
- echo $uuid3 > create
-
- This will create three mediated devices in the [devices] subdirectory named
- after the UUID written to the create attribute file. We call them $uuid1,
- $uuid2 and $uuid3 and this is the sysfs directory structure after creation::
-
- /sys/devices/vfio_ap/matrix/
- --- [mdev_supported_types]
- ------ [vfio_ap-passthrough]
- --------- [devices]
- ------------ [$uuid1]
- --------------- assign_adapter
- --------------- assign_control_domain
- --------------- assign_domain
- --------------- matrix
- --------------- unassign_adapter
- --------------- unassign_control_domain
- --------------- unassign_domain
-
- ------------ [$uuid2]
- --------------- assign_adapter
- --------------- assign_control_domain
- --------------- assign_domain
- --------------- matrix
- --------------- unassign_adapter
- ----------------unassign_control_domain
- ----------------unassign_domain
-
- ------------ [$uuid3]
- --------------- assign_adapter
- --------------- assign_control_domain
- --------------- assign_domain
- --------------- matrix
- --------------- unassign_adapter
- ----------------unassign_control_domain
- ----------------unassign_domain
-
- Note *****: The vfio_ap mdevs do not persist across reboots unless the
- mdevctl tool is used to create and persist them.
-
-4. The administrator now needs to configure the matrixes for the mediated
- devices $uuid1 (for Guest1), $uuid2 (for Guest2) and $uuid3 (for Guest3).
-
- This is how the matrix is configured for Guest1::
-
- echo 5 > assign_adapter
- echo 6 > assign_adapter
- echo 4 > assign_domain
- echo 0xab > assign_domain
-
- Control domains can similarly be assigned using the assign_control_domain
- sysfs file.
-
- If a mistake is made configuring an adapter, domain or control domain,
- you can use the unassign_xxx files to unassign the adapter, domain or
- control domain.
-
- To display the matrix configuration for Guest1::
-
- cat matrix
-
- To display the matrix that is or will be assigned to Guest1::
-
- cat guest_matrix
-
- This is how the matrix is configured for Guest2::
-
- echo 5 > assign_adapter
- echo 0x47 > assign_domain
- echo 0xff > assign_domain
-
- This is how the matrix is configured for Guest3::
-
- echo 6 > assign_adapter
- echo 0x47 > assign_domain
- echo 0xff > assign_domain
-
- In order to successfully assign an adapter:
-
- * The adapter number specified must represent a value from 0 up to the
- maximum adapter number configured for the system. If an adapter number
- higher than the maximum is specified, the operation will terminate with
- an error (ENODEV).
-
- Note: The maximum adapter number can be obtained via the sysfs
- /sys/bus/ap/ap_max_adapter_id attribute file.
-
- * Each APQN derived from the Cartesian product of the APID of the adapter
- being assigned and the APQIs of the domains previously assigned:
-
- - Must only be available to the vfio_ap device driver as specified in the
- sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even
- one APQN is reserved for use by the host device driver, the operation
- will terminate with an error (EADDRNOTAVAIL).
-
- - Must NOT be assigned to another vfio_ap mediated device. If even one APQN
- is assigned to another vfio_ap mediated device, the operation will
- terminate with an error (EBUSY).
-
- - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and
- sys/bus/ap/aqmask attribute files are being edited or the operation may
- terminate with an error (EBUSY).
-
- In order to successfully assign a domain:
-
- * The domain number specified must represent a value from 0 up to the
- maximum domain number configured for the system. If a domain number
- higher than the maximum is specified, the operation will terminate with
- an error (ENODEV).
-
- Note: The maximum domain number can be obtained via the sysfs
- /sys/bus/ap/ap_max_domain_id attribute file.
-
- * Each APQN derived from the Cartesian product of the APQI of the domain
- being assigned and the APIDs of the adapters previously assigned:
-
- - Must only be available to the vfio_ap device driver as specified in the
- sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even
- one APQN is reserved for use by the host device driver, the operation
- will terminate with an error (EADDRNOTAVAIL).
-
- - Must NOT be assigned to another vfio_ap mediated device. If even one APQN
- is assigned to another vfio_ap mediated device, the operation will
- terminate with an error (EBUSY).
-
- - Must NOT be assigned while the sysfs /sys/bus/ap/apmask and
- sys/bus/ap/aqmask attribute files are being edited or the operation may
- terminate with an error (EBUSY).
-
- In order to successfully assign a control domain:
-
- * The domain number specified must represent a value from 0 up to the maximum
- domain number configured for the system. If a control domain number higher
- than the maximum is specified, the operation will terminate with an
- error (ENODEV).
-
-5. Start Guest1::
-
- /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \
- -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ...
-
-7. Start Guest2::
-
- /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \
- -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ...
-
-7. Start Guest3::
-
- /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \
- -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ...
-
-When the guest is shut down, the vfio_ap mediated devices may be removed.
-
-Using our example again, to remove the vfio_ap mediated device $uuid1::
-
- /sys/devices/vfio_ap/matrix/
- --- [mdev_supported_types]
- ------ [vfio_ap-passthrough]
- --------- [devices]
- ------------ [$uuid1]
- --------------- remove
-
-::
-
- echo 1 > remove
-
-This will remove all of the matrix mdev device's sysfs structures including
-the mdev device itself. To recreate and reconfigure the matrix mdev device,
-all of the steps starting with step 3 will have to be performed again. Note
-that the remove will fail if a guest using the vfio_ap mdev is still running.
-
-It is not necessary to remove a vfio_ap mdev, but one may want to
-remove it if no guest will use it during the remaining lifetime of the linux
-host. If the vfio_ap mdev is removed, one may want to also reconfigure
-the pool of adapters and queues reserved for use by the default drivers.
-
-Hot plug/unplug support:
-========================
-An adapter, domain or control domain may be hot plugged into a running KVM
-guest by assigning it to the vfio_ap mediated device being used by the guest if
-the following conditions are met:
-
-* The adapter, domain or control domain must also be assigned to the host's
- AP configuration.
-
-* Each APQN derived from the Cartesian product comprised of the APID of the
- adapter being assigned and the APQIs of the domains assigned must reference a
- queue device bound to the vfio_ap device driver.
-
-* To hot plug a domain, each APQN derived from the Cartesian product
- comprised of the APQI of the domain being assigned and the APIDs of the
- adapters assigned must reference a queue device bound to the vfio_ap device
- driver.
-
-An adapter, domain or control domain may be hot unplugged from a running KVM
-guest by unassigning it from the vfio_ap mediated device being used by the
-guest.
-
-Over-provisioning of AP queues for a KVM guest:
-===============================================
-Over-provisioning is defined herein as the assignment of adapters or domains to
-a vfio_ap mediated device that do not reference AP devices in the host's AP
-configuration. The idea here is that when the adapter or domain becomes
-available, it will be automatically hot-plugged into the KVM guest using
-the vfio_ap mediated device to which it is assigned as long as each new APQN
-resulting from plugging it in references a queue device bound to the vfio_ap
-device driver.
-
-Limitations
-===========
-Live guest migration is not supported for guests using AP devices without
-intervention by a system administrator. Before a KVM guest can be migrated,
-the vfio_ap mediated device must be removed. Unfortunately, it can not be
-removed manually (i.e., echo 1 > /sys/devices/vfio_ap/matrix/$UUID/remove) while
-the mdev is in use by a KVM guest. If the guest is being emulated by QEMU,
-its mdev can be hot unplugged from the guest in one of two ways:
-
-1. If the KVM guest was started with libvirt, you can hot unplug the mdev via
- the following commands:
-
- virsh detach-device <guestname> <path-to-device-xml>
-
- For example, to hot unplug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 from
- the guest named 'my-guest':
-
- virsh detach-device my-guest ~/config/my-guest-hostdev.xml
-
- The contents of my-guest-hostdev.xml:
-
-.. code-block:: xml
-
- <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'>
- <source>
- <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/>
- </source>
- </hostdev>
-
-
- virsh qemu-monitor-command <guest-name> --hmp "device-del <device-id>"
-
- For example, to hot unplug the vfio_ap mediated device identified on the
- qemu command line with 'id=hostdev0' from the guest named 'my-guest':
-
-.. code-block:: sh
-
- virsh qemu-monitor-command my-guest --hmp "device_del hostdev0"
-
-2. A vfio_ap mediated device can be hot unplugged by attaching the qemu monitor
- to the guest and using the following qemu monitor command:
-
- (QEMU) device-del id=<device-id>
-
- For example, to hot unplug the vfio_ap mediated device that was specified
- on the qemu command line with 'id=hostdev0' when the guest was started:
-
- (QEMU) device-del id=hostdev0
-
-After live migration of the KVM guest completes, an AP configuration can be
-restored to the KVM guest by hot plugging a vfio_ap mediated device on the target
-system into the guest in one of two ways:
-
-1. If the KVM guest was started with libvirt, you can hot plug a matrix mediated
- device into the guest via the following virsh commands:
-
- virsh attach-device <guestname> <path-to-device-xml>
-
- For example, to hot plug mdev 62177883-f1bb-47f0-914d-32a22e3a8804 into
- the guest named 'my-guest':
-
- virsh attach-device my-guest ~/config/my-guest-hostdev.xml
-
- The contents of my-guest-hostdev.xml:
-
-.. code-block:: xml
-
- <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ap'>
- <source>
- <address uuid='62177883-f1bb-47f0-914d-32a22e3a8804'/>
- </source>
- </hostdev>
-
-
- virsh qemu-monitor-command <guest-name> --hmp \
- "device_add vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>"
-
- For example, to hot plug the vfio_ap mediated device
- 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with
- device-id hostdev0:
-
- virsh qemu-monitor-command my-guest --hmp \
- "device_add vfio-ap,\
- sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\
- id=hostdev0"
-
-2. A vfio_ap mediated device can be hot plugged by attaching the qemu monitor
- to the guest and using the following qemu monitor command:
-
- (qemu) device_add "vfio-ap,sysfsdev=<path-to-mdev>,id=<device-id>"
-
- For example, to plug the vfio_ap mediated device
- 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id
- hostdev0:
-
- (QEMU) device-add "vfio-ap,\
- sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\
- id=hostdev0"
diff --git a/Documentation/s390/vfio-ccw.rst b/Documentation/s390/vfio-ccw.rst
deleted file mode 100644
index 37026fa..0000000
--- a/Documentation/s390/vfio-ccw.rst
+++ /dev/null
@@ -1,445 +0,0 @@
-==================================
-vfio-ccw: the basic infrastructure
-==================================
-
-Introduction
-------------
-
-Here we describe the vfio support for I/O subchannel devices for
-Linux/s390. Motivation for vfio-ccw is to passthrough subchannels to a
-virtual machine, while vfio is the means.
-
-Different than other hardware architectures, s390 has defined a unified
-I/O access method, which is so called Channel I/O. It has its own access
-patterns:
-
-- Channel programs run asynchronously on a separate (co)processor.
-- The channel subsystem will access any memory designated by the caller
- in the channel program directly, i.e. there is no iommu involved.
-
-Thus when we introduce vfio support for these devices, we realize it
-with a mediated device (mdev) implementation. The vfio mdev will be
-added to an iommu group, so as to make itself able to be managed by the
-vfio framework. And we add read/write callbacks for special vfio I/O
-regions to pass the channel programs from the mdev to its parent device
-(the real I/O subchannel device) to do further address translation and
-to perform I/O instructions.
-
-This document does not intend to explain the s390 I/O architecture in
-every detail. More information/reference could be found here:
-
-- A good start to know Channel I/O in general:
- https://en.wikipedia.org/wiki/Channel_I/O
-- s390 architecture:
- s390 Principles of Operation manual (IBM Form. No. SA22-7832)
-- The existing QEMU code which implements a simple emulated channel
- subsystem could also be a good reference. It makes it easier to follow
- the flow.
- qemu/hw/s390x/css.c
-
-For vfio mediated device framework:
-- Documentation/driver-api/vfio-mediated-device.rst
-
-Motivation of vfio-ccw
-----------------------
-
-Typically, a guest virtualized via QEMU/KVM on s390 only sees
-paravirtualized virtio devices via the "Virtio Over Channel I/O
-(virtio-ccw)" transport. This makes virtio devices discoverable via
-standard operating system algorithms for handling channel devices.
-
-However this is not enough. On s390 for the majority of devices, which
-use the standard Channel I/O based mechanism, we also need to provide
-the functionality of passing through them to a QEMU virtual machine.
-This includes devices that don't have a virtio counterpart (e.g. tape
-drives) or that have specific characteristics which guests want to
-exploit.
-
-For passing a device to a guest, we want to use the same interface as
-everybody else, namely vfio. We implement this vfio support for channel
-devices via the vfio mediated device framework and the subchannel device
-driver "vfio_ccw".
-
-Access patterns of CCW devices
-------------------------------
-
-s390 architecture has implemented a so called channel subsystem, that
-provides a unified view of the devices physically attached to the
-systems. Though the s390 hardware platform knows about a huge variety of
-different peripheral attachments like disk devices (aka. DASDs), tapes,
-communication controllers, etc. They can all be accessed by a well
-defined access method and they are presenting I/O completion a unified
-way: I/O interruptions.
-
-All I/O requires the use of channel command words (CCWs). A CCW is an
-instruction to a specialized I/O channel processor. A channel program is
-a sequence of CCWs which are executed by the I/O channel subsystem. To
-issue a channel program to the channel subsystem, it is required to
-build an operation request block (ORB), which can be used to point out
-the format of the CCW and other control information to the system. The
-operating system signals the I/O channel subsystem to begin executing
-the channel program with a SSCH (start sub-channel) instruction. The
-central processor is then free to proceed with non-I/O instructions
-until interrupted. The I/O completion result is received by the
-interrupt handler in the form of interrupt response block (IRB).
-
-Back to vfio-ccw, in short:
-
-- ORBs and channel programs are built in guest kernel (with guest
- physical addresses).
-- ORBs and channel programs are passed to the host kernel.
-- Host kernel translates the guest physical addresses to real addresses
- and starts the I/O with issuing a privileged Channel I/O instruction
- (e.g SSCH).
-- channel programs run asynchronously on a separate processor.
-- I/O completion will be signaled to the host with I/O interruptions.
- And it will be copied as IRB to user space to pass it back to the
- guest.
-
-Physical vfio ccw device and its child mdev
--------------------------------------------
-
-As mentioned above, we realize vfio-ccw with a mdev implementation.
-
-Channel I/O does not have IOMMU hardware support, so the physical
-vfio-ccw device does not have an IOMMU level translation or isolation.
-
-Subchannel I/O instructions are all privileged instructions. When
-handling the I/O instruction interception, vfio-ccw has the software
-policing and translation how the channel program is programmed before
-it gets sent to hardware.
-
-Within this implementation, we have two drivers for two types of
-devices:
-
-- The vfio_ccw driver for the physical subchannel device.
- This is an I/O subchannel driver for the real subchannel device. It
- realizes a group of callbacks and registers to the mdev framework as a
- parent (physical) device. As a consequence, mdev provides vfio_ccw a
- generic interface (sysfs) to create mdev devices. A vfio mdev could be
- created by vfio_ccw then and added to the mediated bus. It is the vfio
- device that added to an IOMMU group and a vfio group.
- vfio_ccw also provides an I/O region to accept channel program
- request from user space and store I/O interrupt result for user
- space to retrieve. To notify user space an I/O completion, it offers
- an interface to setup an eventfd fd for asynchronous signaling.
-
-- The vfio_mdev driver for the mediated vfio ccw device.
- This is provided by the mdev framework. It is a vfio device driver for
- the mdev that created by vfio_ccw.
- It realizes a group of vfio device driver callbacks, adds itself to a
- vfio group, and registers itself to the mdev framework as a mdev
- driver.
- It uses a vfio iommu backend that uses the existing map and unmap
- ioctls, but rather than programming them into an IOMMU for a device,
- it simply stores the translations for use by later requests. This
- means that a device programmed in a VM with guest physical addresses
- can have the vfio kernel convert that address to process virtual
- address, pin the page and program the hardware with the host physical
- address in one step.
- For a mdev, the vfio iommu backend will not pin the pages during the
- VFIO_IOMMU_MAP_DMA ioctl. Mdev framework will only maintain a database
- of the iova<->vaddr mappings in this operation. And they export a
- vfio_pin_pages and a vfio_unpin_pages interfaces from the vfio iommu
- backend for the physical devices to pin and unpin pages by demand.
-
-Below is a high Level block diagram::
-
- +-------------+
- | |
- | +---------+ | mdev_register_driver() +--------------+
- | | Mdev | +<-----------------------+ |
- | | bus | | | vfio_mdev.ko |
- | | driver | +----------------------->+ |<-> VFIO user
- | +---------+ | probe()/remove() +--------------+ APIs
- | |
- | MDEV CORE |
- | MODULE |
- | mdev.ko |
- | +---------+ | mdev_register_parent() +--------------+
- | |Physical | +<-----------------------+ |
- | | device | | | vfio_ccw.ko |<-> subchannel
- | |interface| +----------------------->+ | device
- | +---------+ | callback +--------------+
- +-------------+
-
-The process of how these work together.
-
-1. vfio_ccw.ko drives the physical I/O subchannel, and registers the
- physical device (with callbacks) to mdev framework.
- When vfio_ccw probing the subchannel device, it registers device
- pointer and callbacks to the mdev framework. Mdev related file nodes
- under the device node in sysfs would be created for the subchannel
- device, namely 'mdev_create', 'mdev_destroy' and
- 'mdev_supported_types'.
-2. Create a mediated vfio ccw device.
- Use the 'mdev_create' sysfs file, we need to manually create one (and
- only one for our case) mediated device.
-3. vfio_mdev.ko drives the mediated ccw device.
- vfio_mdev is also the vfio device driver. It will probe the mdev and
- add it to an iommu_group and a vfio_group. Then we could pass through
- the mdev to a guest.
-
-
-VFIO-CCW Regions
-----------------
-
-The vfio-ccw driver exposes MMIO regions to accept requests from and return
-results to userspace.
-
-vfio-ccw I/O region
--------------------
-
-An I/O region is used to accept channel program request from user
-space and store I/O interrupt result for user space to retrieve. The
-definition of the region is::
-
- struct ccw_io_region {
- #define ORB_AREA_SIZE 12
- __u8 orb_area[ORB_AREA_SIZE];
- #define SCSW_AREA_SIZE 12
- __u8 scsw_area[SCSW_AREA_SIZE];
- #define IRB_AREA_SIZE 96
- __u8 irb_area[IRB_AREA_SIZE];
- __u32 ret_code;
- } __packed;
-
-This region is always available.
-
-While starting an I/O request, orb_area should be filled with the
-guest ORB, and scsw_area should be filled with the SCSW of the Virtual
-Subchannel.
-
-irb_area stores the I/O result.
-
-ret_code stores a return code for each access of the region. The following
-values may occur:
-
-``0``
- The operation was successful.
-
-``-EOPNOTSUPP``
- The ORB specified transport mode or the
- SCSW specified a function other than the start function.
-
-``-EIO``
- A request was issued while the device was not in a state ready to accept
- requests, or an internal error occurred.
-
-``-EBUSY``
- The subchannel was status pending or busy, or a request is already active.
-
-``-EAGAIN``
- A request was being processed, and the caller should retry.
-
-``-EACCES``
- The channel path(s) used for the I/O were found to be not operational.
-
-``-ENODEV``
- The device was found to be not operational.
-
-``-EINVAL``
- The orb specified a chain longer than 255 ccws, or an internal error
- occurred.
-
-
-vfio-ccw cmd region
--------------------
-
-The vfio-ccw cmd region is used to accept asynchronous instructions
-from userspace::
-
- #define VFIO_CCW_ASYNC_CMD_HSCH (1 << 0)
- #define VFIO_CCW_ASYNC_CMD_CSCH (1 << 1)
- struct ccw_cmd_region {
- __u32 command;
- __u32 ret_code;
- } __packed;
-
-This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_ASYNC_CMD.
-
-Currently, CLEAR SUBCHANNEL and HALT SUBCHANNEL use this region.
-
-command specifies the command to be issued; ret_code stores a return code
-for each access of the region. The following values may occur:
-
-``0``
- The operation was successful.
-
-``-ENODEV``
- The device was found to be not operational.
-
-``-EINVAL``
- A command other than halt or clear was specified.
-
-``-EIO``
- A request was issued while the device was not in a state ready to accept
- requests.
-
-``-EAGAIN``
- A request was being processed, and the caller should retry.
-
-``-EBUSY``
- The subchannel was status pending or busy while processing a halt request.
-
-vfio-ccw schib region
----------------------
-
-The vfio-ccw schib region is used to return Subchannel-Information
-Block (SCHIB) data to userspace::
-
- struct ccw_schib_region {
- #define SCHIB_AREA_SIZE 52
- __u8 schib_area[SCHIB_AREA_SIZE];
- } __packed;
-
-This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_SCHIB.
-
-Reading this region triggers a STORE SUBCHANNEL to be issued to the
-associated hardware.
-
-vfio-ccw crw region
----------------------
-
-The vfio-ccw crw region is used to return Channel Report Word (CRW)
-data to userspace::
-
- struct ccw_crw_region {
- __u32 crw;
- __u32 pad;
- } __packed;
-
-This region is exposed via region type VFIO_REGION_SUBTYPE_CCW_CRW.
-
-Reading this region returns a CRW if one that is relevant for this
-subchannel (e.g. one reporting changes in channel path state) is
-pending, or all zeroes if not. If multiple CRWs are pending (including
-possibly chained CRWs), reading this region again will return the next
-one, until no more CRWs are pending and zeroes are returned. This is
-similar to how STORE CHANNEL REPORT WORD works.
-
-vfio-ccw operation details
---------------------------
-
-vfio-ccw follows what vfio-pci did on the s390 platform and uses
-vfio-iommu-type1 as the vfio iommu backend.
-
-* CCW translation APIs
- A group of APIs (start with `cp_`) to do CCW translation. The CCWs
- passed in by a user space program are organized with their guest
- physical memory addresses. These APIs will copy the CCWs into kernel
- space, and assemble a runnable kernel channel program by updating the
- guest physical addresses with their corresponding host physical addresses.
- Note that we have to use IDALs even for direct-access CCWs, as the
- referenced memory can be located anywhere, including above 2G.
-
-* vfio_ccw device driver
- This driver utilizes the CCW translation APIs and introduces
- vfio_ccw, which is the driver for the I/O subchannel devices you want
- to pass through.
- vfio_ccw implements the following vfio ioctls::
-
- VFIO_DEVICE_GET_INFO
- VFIO_DEVICE_GET_IRQ_INFO
- VFIO_DEVICE_GET_REGION_INFO
- VFIO_DEVICE_RESET
- VFIO_DEVICE_SET_IRQS
-
- This provides an I/O region, so that the user space program can pass a
- channel program to the kernel, to do further CCW translation before
- issuing them to a real device.
- This also provides the SET_IRQ ioctl to setup an event notifier to
- notify the user space program the I/O completion in an asynchronous
- way.
-
-The use of vfio-ccw is not limited to QEMU, while QEMU is definitely a
-good example to get understand how these patches work. Here is a little
-bit more detail how an I/O request triggered by the QEMU guest will be
-handled (without error handling).
-
-Explanation:
-
-- Q1-Q7: QEMU side process.
-- K1-K5: Kernel side process.
-
-Q1.
- Get I/O region info during initialization.
-
-Q2.
- Setup event notifier and handler to handle I/O completion.
-
-... ...
-
-Q3.
- Intercept a ssch instruction.
-Q4.
- Write the guest channel program and ORB to the I/O region.
-
- K1.
- Copy from guest to kernel.
- K2.
- Translate the guest channel program to a host kernel space
- channel program, which becomes runnable for a real device.
- K3.
- With the necessary information contained in the orb passed in
- by QEMU, issue the ccwchain to the device.
- K4.
- Return the ssch CC code.
-Q5.
- Return the CC code to the guest.
-
-... ...
-
- K5.
- Interrupt handler gets the I/O result and write the result to
- the I/O region.
- K6.
- Signal QEMU to retrieve the result.
-
-Q6.
- Get the signal and event handler reads out the result from the I/O
- region.
-Q7.
- Update the irb for the guest.
-
-Limitations
------------
-
-The current vfio-ccw implementation focuses on supporting basic commands
-needed to implement block device functionality (read/write) of DASD/ECKD
-device only. Some commands may need special handling in the future, for
-example, anything related to path grouping.
-
-DASD is a kind of storage device. While ECKD is a data recording format.
-More information for DASD and ECKD could be found here:
-https://en.wikipedia.org/wiki/Direct-access_storage_device
-https://en.wikipedia.org/wiki/Count_key_data
-
-Together with the corresponding work in QEMU, we can bring the passed
-through DASD/ECKD device online in a guest now and use it as a block
-device.
-
-The current code allows the guest to start channel programs via
-START SUBCHANNEL, and to issue HALT SUBCHANNEL, CLEAR SUBCHANNEL,
-and STORE SUBCHANNEL.
-
-Currently all channel programs are prefetched, regardless of the
-p-bit setting in the ORB. As a result, self modifying channel
-programs are not supported. For this reason, IPL has to be handled as
-a special case by a userspace/guest program; this has been implemented
-in QEMU's s390-ccw bios as of QEMU 4.1.
-
-vfio-ccw supports classic (command mode) channel I/O only. Transport
-mode (HPF) is not supported.
-
-QDIO subchannels are currently not supported. Classic devices other than
-DASD/ECKD might work, but have not been tested.
-
-Reference
----------
-1. ESA/s390 Principles of Operation manual (IBM Form. No. SA22-7832)
-2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204)
-3. https://en.wikipedia.org/wiki/Channel_I/O
-4. Documentation/s390/cds.rst
-5. Documentation/driver-api/vfio.rst
-6. Documentation/driver-api/vfio-mediated-device.rst
diff --git a/Documentation/scheduler/completion.rst b/Documentation/scheduler/completion.rst
index 9f039b4..f19aca2 100644
--- a/Documentation/scheduler/completion.rst
+++ b/Documentation/scheduler/completion.rst
@@ -157,7 +157,7 @@
/* run non-dependent code */ /* do setup */
- wait_for_completion(&setup_done); complete(setup_done);
+ wait_for_completion(&setup_done); complete(&setup_done);
This is not implying any particular order between wait_for_completion() and
the call to complete() - if the call to complete() happened before the call
diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst
index f166b18..41ed2ce 100644
--- a/Documentation/scheduler/sched-bwc.rst
+++ b/Documentation/scheduler/sched-bwc.rst
@@ -186,7 +186,7 @@
also limits the burst ability to no more than 1ms per cpu. This provides
better more predictable user experience for highly threaded applications with
small quota limits on high core count machines. It also eliminates the
-propensity to throttle these applications while simultanously using less than
+propensity to throttle these applications while simultaneously using less than
quota amounts of cpu. Another way to say this, is that by allowing the unused
portion of a slice to remain valid across periods we have decreased the
possibility of wastefully expiring quota on cpu-local silos that don't need a
diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst
index 03db555..f689198 100644
--- a/Documentation/scheduler/sched-design-CFS.rst
+++ b/Documentation/scheduler/sched-design-CFS.rst
@@ -94,7 +94,7 @@
way the previous scheduler had, and has no heuristics whatsoever. There is
only one central tunable (you have to switch on CONFIG_SCHED_DEBUG):
- /sys/kernel/debug/sched/min_granularity_ns
+ /sys/kernel/debug/sched/base_slice_ns
which can be used to tune the scheduler from "desktop" (i.e., low latencies) to
"server" (i.e., good batching) workloads. It defaults to a setting suitable
diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst
index 8fbce5e..fc853c8 100644
--- a/Documentation/scheduler/sched-energy.rst
+++ b/Documentation/scheduler/sched-energy.rst
@@ -82,7 +82,7 @@
The rest of platform knowledge used by EAS is directly read from the Energy
Model (EM) framework. The EM of a platform is composed of a power cost table
per 'performance domain' in the system (see Documentation/power/energy-model.rst
-for futher details about performance domains).
+for further details about performance domains).
The scheduler manages references to the EM objects in the topology code when the
scheduling domains are built, or re-built. For each root domain (rd), the
@@ -281,7 +281,7 @@
From a general standpoint, the use-cases where EAS can help the most are those
involving a light/medium CPU utilization. Whenever long CPU-bound tasks are
being run, they will require all of the available CPU capacity, and there isn't
-much that can be done by the scheduler to save energy without severly harming
+much that can be done by the scheduler to save energy without severely harming
throughput. In order to avoid hurting performance with EAS, CPUs are flagged as
'over-utilized' as soon as they are used at more than 80% of their compute
capacity. As long as no CPUs are over-utilized in a root domain, load balancing
diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc
index d16e687..ccc48b8 100644
--- a/Documentation/scsi/ChangeLog.lpfc
+++ b/Documentation/scsi/ChangeLog.lpfc
@@ -427,7 +427,7 @@
* Changed version number to 8.0.17
* Fix sparse warnings by adding __iomem markers to lpfc_compat.h.
* Fix some sparse warnings -- 0 used as NULL pointer.
- * Make sure there's a space between every if and it's (.
+ * Make sure there's a space between every if and its (.
* Fix some overly long lines and make sure hard tabs are used for
indentation.
* Remove all trailing whitespace.
diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst
index 6fa3a62..022198c 100644
--- a/Documentation/scsi/scsi_mid_low_api.rst
+++ b/Documentation/scsi/scsi_mid_low_api.rst
@@ -1190,11 +1190,11 @@
- pointer to scsi_device object that this command is
associated with.
resid
- - an LLD should set this signed integer to the requested
+ - an LLD should set this unsigned integer to the requested
transfer length (i.e. 'request_bufflen') less the number
of bytes that are actually transferred. 'resid' is
preset to 0 so an LLD can ignore it if it cannot detect
- underruns (overruns should be rare). If possible an LLD
+ underruns (overruns should not be reported). An LLD
should set 'resid' prior to invoking 'done'. The most
interesting case is data transfers from a SCSI target
device (e.g. READs) that underrun.
diff --git a/Documentation/security/digsig.rst b/Documentation/security/digsig.rst
index f6a8902..de035f2 100644
--- a/Documentation/security/digsig.rst
+++ b/Documentation/security/digsig.rst
@@ -82,7 +82,7 @@
to generate signatures, to load keys into the kernel keyring.
Keys can be in PEM or converted to the kernel format.
When the key is added to the kernel keyring, the keyid defines the name
-of the key: 5D2B05FC633EE3E8 in the example bellow.
+of the key: 5D2B05FC633EE3E8 in the example below.
Here is example output of the keyctl utility::
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 811b905..326b8a973 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -869,7 +869,7 @@
- ``char *hashname`` specifies the NUL terminated string identifying
the hash used from the kernel crypto API and applied for the KDF
- operation. The KDF implemenation complies with SP800-56A as well
+ operation. The KDF implementation complies with SP800-56A as well
as with SP800-108 (the counter KDF).
- ``char *otherinfo`` specifies the OtherInfo data as documented in
diff --git a/Documentation/security/secrets/coco.rst b/Documentation/security/secrets/coco.rst
index 087e2d1..a1210db 100644
--- a/Documentation/security/secrets/coco.rst
+++ b/Documentation/security/secrets/coco.rst
@@ -34,7 +34,7 @@
During the VM's launch, the virtual machine manager may inject a secret to that
area. In AMD SEV and SEV-ES this is performed using the
-``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The strucutre of the injected
+``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The structure of the injected
Guest Owner secret data should be a GUIDed table of secret values; the binary
format is described in ``drivers/virt/coco/efi_secret/efi_secret.c`` under
"Structure of the EFI secret area".
diff --git a/Documentation/sound/cards/audigy-mixer.rst b/Documentation/sound/cards/audigy-mixer.rst
index ea66b50..7ebaacb 100644
--- a/Documentation/sound/cards/audigy-mixer.rst
+++ b/Documentation/sound/cards/audigy-mixer.rst
@@ -46,157 +46,158 @@
name='PCM Front Playback Volume',index=0
----------------------------------------
-This control is used to attenuate samples for left and right front PCM FX-bus
+This control is used to attenuate samples from left and right front PCM FX-bus
accumulators. ALSA uses accumulators 8 and 9 for left and right front PCM
-samples for 5.1 playback. The result samples are forwarded to the front DAC PCM
-slots of the Philips DAC.
+samples for 5.1 playback. The result samples are forwarded to the front speakers.
name='PCM Surround Playback Volume',index=0
-------------------------------------------
-This control is used to attenuate samples for left and right surround PCM FX-bus
+This control is used to attenuate samples from left and right surround PCM FX-bus
accumulators. ALSA uses accumulators 2 and 3 for left and right surround PCM
-samples for 5.1 playback. The result samples are forwarded to the surround DAC PCM
-slots of the Philips DAC.
+samples for 5.1 playback. The result samples are forwarded to the surround (rear)
+speakers.
+
+name='PCM Side Playback Volume',index=0
+---------------------------------------
+This control is used to attenuate samples from left and right side PCM FX-bus
+accumulators. ALSA uses accumulators 14 and 15 for left and right side PCM
+samples for 7.1 playback. The result samples are forwarded to the side speakers.
name='PCM Center Playback Volume',index=0
-----------------------------------------
-This control is used to attenuate samples for center PCM FX-bus accumulator.
-ALSA uses accumulator 6 for center PCM sample for 5.1 playback. The result sample
-is forwarded to the center DAC PCM slot of the Philips DAC.
+This control is used to attenuate samples from center PCM FX-bus accumulator.
+ALSA uses accumulator 6 for center PCM samples for 5.1 playback. The result
+samples are forwarded to the center speaker.
name='PCM LFE Playback Volume',index=0
--------------------------------------
This control is used to attenuate sample for LFE PCM FX-bus accumulator.
-ALSA uses accumulator 7 for LFE PCM sample for 5.1 playback. The result sample
-is forwarded to the LFE DAC PCM slot of the Philips DAC.
+ALSA uses accumulator 7 for LFE PCM samples for 5.1 playback. The result
+samples are forwarded to the subwoofer.
name='PCM Playback Volume',index=0
----------------------------------
-This control is used to attenuate samples for left and right PCM FX-bus
+This control is used to attenuate samples from left and right PCM FX-bus
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for
-stereo playback. The result samples are forwarded to the front DAC PCM slots
-of the Philips DAC.
+stereo playback. The result samples are forwarded to the front speakers.
name='PCM Capture Volume',index=0
---------------------------------
-This control is used to attenuate samples for left and right PCM FX-bus
-accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
-The result is forwarded to the ADC capture FIFO (thus to the standard capture
-PCM device).
+This control is used to attenuate samples from left and right PCM FX-bus
+accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for
+stereo playback. The result is forwarded to the standard capture PCM device.
name='Music Playback Volume',index=0
------------------------------------
-This control is used to attenuate samples for left and right MIDI FX-bus
+This control is used to attenuate samples from left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
-The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
+The result samples are forwarded to the virtual stereo mixer.
name='Music Capture Volume',index=0
-----------------------------------
-These controls are used to attenuate samples for left and right MIDI FX-bus
-accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.
-The result is forwarded to the ADC capture FIFO (thus to the standard capture
-PCM device).
+These controls are used to attenuate samples from left and right MIDI FX-bus
+accumulator. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
+The result is forwarded to the standard capture PCM device.
name='Mic Playback Volume',index=0
----------------------------------
-This control is used to attenuate samples for left and right Mic input.
-For Mic input is used AC97 codec. The result samples are forwarded to
-the front DAC PCM slots of the Philips DAC. Samples are forwarded to Mic
-capture FIFO (device 1 - 16bit/8KHz mono) too without volume control.
+This control is used to attenuate samples from left and right Mic input of
+the AC97 codec. The result samples are forwarded to the virtual stereo mixer.
name='Mic Capture Volume',index=0
---------------------------------
-This control is used to attenuate samples for left and right Mic input.
-The result is forwarded to the ADC capture FIFO (thus to the standard capture
-PCM device).
+This control is used to attenuate samples from left and right Mic input of
+the AC97 codec. The result is forwarded to the standard capture PCM device.
+
+The original samples are also forwarded to the Mic capture PCM device (device 1;
+16bit/8KHz mono) without volume control.
name='Audigy CD Playback Volume',index=0
----------------------------------------
This control is used to attenuate samples from left and right IEC958 TTL
digital inputs (usually used by a CDROM drive). The result samples are
-forwarded to the front DAC PCM slots of the Philips DAC.
+forwarded to the virtual stereo mixer.
name='Audigy CD Capture Volume',index=0
---------------------------------------
This control is used to attenuate samples from left and right IEC958 TTL
-digital inputs (usually used by a CDROM drive). The result samples are
-forwarded to the ADC capture FIFO (thus to the standard capture PCM device).
+digital inputs (usually used by a CDROM drive). The result is forwarded
+to the standard capture PCM device.
name='IEC958 Optical Playback Volume',index=0
---------------------------------------------
This control is used to attenuate samples from left and right IEC958 optical
-digital input. The result samples are forwarded to the front DAC PCM slots
-of the Philips DAC.
+digital input. The result samples are forwarded to the virtual stereo mixer.
name='IEC958 Optical Capture Volume',index=0
--------------------------------------------
This control is used to attenuate samples from left and right IEC958 optical
-digital inputs. The result samples are forwarded to the ADC capture FIFO
-(thus to the standard capture PCM device).
+digital inputs. The result is forwarded to the standard capture PCM device.
name='Line2 Playback Volume',index=0
------------------------------------
This control is used to attenuate samples from left and right I2S ADC
-inputs (on the AudigyDrive). The result samples are forwarded to the front
-DAC PCM slots of the Philips DAC.
+inputs (on the AudigyDrive). The result samples are forwarded to the virtual
+stereo mixer.
name='Line2 Capture Volume',index=1
-----------------------------------
This control is used to attenuate samples from left and right I2S ADC
-inputs (on the AudigyDrive). The result samples are forwarded to the ADC
-capture FIFO (thus to the standard capture PCM device).
+inputs (on the AudigyDrive). The result is forwarded to the standard capture
+PCM device.
name='Analog Mix Playback Volume',index=0
-----------------------------------------
This control is used to attenuate samples from left and right I2S ADC
-inputs from Philips ADC. The result samples are forwarded to the front
-DAC PCM slots of the Philips DAC. This contains mix from analog sources
-like CD, Line In, Aux, ....
+inputs from Philips ADC. The result samples are forwarded to the virtual
+stereo mixer. This contains mix from analog sources like CD, Line In, Aux, ....
name='Analog Mix Capture Volume',index=1
----------------------------------------
This control is used to attenuate samples from left and right I2S ADC
-inputs Philips ADC. The result samples are forwarded to the ADC
-capture FIFO (thus to the standard capture PCM device).
+inputs Philips ADC. The result is forwarded to the standard capture PCM device.
name='Aux2 Playback Volume',index=0
-----------------------------------
This control is used to attenuate samples from left and right I2S ADC
-inputs (on the AudigyDrive). The result samples are forwarded to the front
-DAC PCM slots of the Philips DAC.
+inputs (on the AudigyDrive). The result samples are forwarded to the virtual
+stereo mixer.
name='Aux2 Capture Volume',index=1
----------------------------------
This control is used to attenuate samples from left and right I2S ADC
-inputs (on the AudigyDrive). The result samples are forwarded to the ADC
-capture FIFO (thus to the standard capture PCM device).
+inputs (on the AudigyDrive). The result is forwarded to the standard capture
+PCM device.
name='Front Playback Volume',index=0
------------------------------------
-All stereo signals are mixed together and mirrored to surround, center and LFE.
-This control is used to attenuate samples for left and right front speakers of
-this mix.
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the front speakers.
name='Surround Playback Volume',index=0
---------------------------------------
-All stereo signals are mixed together and mirrored to surround, center and LFE.
-This control is used to attenuate samples for left and right surround speakers of
-this mix.
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the surround (rear) speakers.
+
+name='Side Playback Volume',index=0
+-----------------------------------
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the side speakers.
name='Center Playback Volume',index=0
-------------------------------------
-All stereo signals are mixed together and mirrored to surround, center and LFE.
-This control is used to attenuate sample for center speaker of this mix.
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the center speaker.
name='LFE Playback Volume',index=0
----------------------------------
-All stereo signals are mixed together and mirrored to surround, center and LFE.
-This control is used to attenuate sample for LFE speaker of this mix.
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the subwoofer.
name='Tone Control - Switch',index=0
------------------------------------
-This control turns the tone control on or off. The samples for front, rear
-and center / LFE outputs are affected.
+This control turns the tone control on or off. The samples forwarded to
+the speaker outputs are affected.
name='Tone Control - Bass',index=0
----------------------------------
@@ -212,8 +213,7 @@
name='Master Playback Volume',index=0
-------------------------------------
-This control is used to attenuate samples for front, surround, center and
-LFE outputs.
+This control is used to attenuate samples forwarded to the speaker outputs.
name='IEC958 Optical Raw Playback Switch',index=0
-------------------------------------------------
@@ -303,69 +303,4 @@
MANUALS/PATENTS
===============
-ftp://opensource.creative.com/pub/doc
--------------------------------------
-
-Note that the site is defunct, but the documents are available
-from various other locations.
-
-LM4545.pdf
- AC97 Codec
-
-m2049.pdf
- The EMU10K1 Digital Audio Processor
-
-hog63.ps
- FX8010 - A DSP Chip Architecture for Audio Effects
-
-
-WIPO Patents
-------------
-
-WO 9901813 (A1)
- Audio Effects Processor with multiple asynchronous streams
- (Jan. 14, 1999)
-
-WO 9901814 (A1)
- Processor with Instruction Set for Audio Effects (Jan. 14, 1999)
-
-WO 9901953 (A1)
- Audio Effects Processor having Decoupled Instruction
- Execution and Audio Data Sequencing (Jan. 14, 1999)
-
-
-US Patents (https://www.uspto.gov/)
------------------------------------
-
-US 5925841
- Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
-
-US 5928342
- Audio Effects Processor integrated on a single chip
- with a multiport memory onto which multiple asynchronous
- digital sound samples can be concurrently loaded
- (Jul. 27, 1999)
-
-US 5930158
- Processor with Instruction Set for Audio Effects (Jul. 27, 1999)
-
-US 6032235
- Memory initialization circuit (Tram) (Feb. 29, 2000)
-
-US 6138207
- Interpolation looping of audio samples in cache connected to
- system bus with prioritization and modification of bus transfers
- in accordance with loop ends and minimum block sizes
- (Oct. 24, 2000)
-
-US 6151670
- Method for conserving memory storage using a
- pool of short term memory registers
- (Nov. 21, 2000)
-
-US 6195715
- Interrupt control for multiple programs communicating with
- a common interrupt by associating programs to GP registers,
- defining interrupt register, polling GP registers, and invoking
- callback routine associated with defined interrupt register
- (Feb. 27, 2001)
+See sb-live-mixer.rst.
diff --git a/Documentation/sound/cards/emu-mixer.rst b/Documentation/sound/cards/emu-mixer.rst
new file mode 100644
index 0000000..d87a633
--- /dev/null
+++ b/Documentation/sound/cards/emu-mixer.rst
@@ -0,0 +1,226 @@
+==================================================
+E-MU Digital Audio System mixer / default DSP code
+==================================================
+
+This document covers the E-MU 0404/1010/1212/1616/1820 PCI/PCI-e/CardBus
+cards.
+
+These cards use regular EMU10K2 (SoundBlaster Audigy) chips, but with an
+alternative front-end geared towards semi-professional studio recording.
+
+This document is based on audigy-mixer.rst.
+
+
+Hardware compatibility
+======================
+
+The EMU10K2 chips have a very short capture FIFO, which makes recording
+unreliable if the card's PCI bus requests are not handled with the
+appropriate priority.
+This is the case on more modern motherboards, where the PCI bus is only a
+secondary peripheral, rather than the actual arbiter of device access.
+In particular, I got recording glitches during simultaneous playback on an
+Intel DP55 board (memory controller in the CPU), but had success with an
+Intel DP45 board (memory controller in the north bridge).
+
+The PCI Express variants of these cards (which have a PCI bridge on board,
+but are otherwise identical) may be less problematic.
+
+
+Driver capabilities
+===================
+
+This driver supports only 16-bit 44.1/48 kHz operation. The multi-channel
+device (see emu10k1-jack.rst) additionally supports 24-bit capture.
+
+A patchset to enhance the driver is available from `a GitHub repository
+<https://github.com/ossilator/linux/tree/ossis-emu10k1>`_.
+Its multi-channel device supports 24-bit for both playback and capture,
+and also supports full 88.2/96/176.4/192 kHz operation.
+It is not going to be upstreamed due to a fundamental disagreement about
+what constitutes a good user experience.
+
+
+Digital mixer controls
+======================
+
+Note that the controls work as attenuators: the maximum value is the neutral
+position leaving the signal unchanged. Note that if the same destination is
+mentioned in multiple controls, the signal is accumulated and can be clipped
+(set to maximal or minimal value without checking for overflow).
+
+Explanation of used abbreviations:
+
+DAC
+ digital to analog converter
+ADC
+ analog to digital converter
+LFE
+ low frequency effects (used as subwoofer signal)
+IEC958
+ S/PDIF
+FX-bus
+ the EMU10K2 chip has an effect bus containing 64 accumulators.
+ Each of the synthesizer voices can feed its output to these accumulators
+ and the DSP microcontroller can operate with the resulting sum.
+
+name='Clock Source',index=0
+---------------------------
+This control allows switching the word clock between interally generated
+44.1 or 48 kHz, or a number of external sources.
+
+Note: the sources for the 1616 CardBus card are unclear. Please report your
+findings.
+
+name='Clock Fallback',index=0
+-----------------------------
+This control determines the internal clock which the card switches to when
+the selected external clock source is/becomes invalid.
+
+name='DAC1 0202 14dB PAD',index=0, etc.
+---------------------------------------
+Output attenuation controls. Not available on 0404 cards.
+
+name='ADC1 14dB PAD 0202',index=0, etc.
+---------------------------------------
+Input attenuation controls. Not available on 0404 cards.
+
+name='Optical Output Mode',index=0
+----------------------------------
+Switches the TOSLINK output port between S/PDIF and ADAT.
+Not available on 0404 cards (fixed to S/PDIF).
+
+name='Optical Input Mode',index=0
+---------------------------------
+Switches the TOSLINK input port between S/PDIF and ADAT.
+Not available on 0404 cards (fixed to S/PDIF).
+
+name='PCM Front Playback Volume',index=0
+----------------------------------------
+This control is used to attenuate samples from left and right front PCM FX-bus
+accumulators. ALSA uses accumulators 8 and 9 for left and right front PCM
+samples for 5.1 playback. The result samples are forwarded to the DSP 0 & 1
+playback channels.
+
+name='PCM Surround Playback Volume',index=0
+-------------------------------------------
+This control is used to attenuate samples from left and right surround PCM FX-bus
+accumulators. ALSA uses accumulators 2 and 3 for left and right surround PCM
+samples for 5.1 playback. The result samples are forwarded to the DSP 2 & 3
+playback channels.
+
+name='PCM Side Playback Volume',index=0
+---------------------------------------
+This control is used to attenuate samples from left and right side PCM FX-bus
+accumulators. ALSA uses accumulators 14 and 15 for left and right side PCM
+samples for 7.1 playback. The result samples are forwarded to the DSP 6 & 7
+playback channels.
+
+name='PCM Center Playback Volume',index=0
+-----------------------------------------
+This control is used to attenuate samples from the center PCM FX-bus accumulator.
+ALSA uses accumulator 6 for center PCM samples for 5.1 playback. The result samples
+are forwarded to the DSP 4 playback channel.
+
+name='PCM LFE Playback Volume',index=0
+--------------------------------------
+This control is used to attenuate samples from the LFE PCM FX-bus accumulator.
+ALSA uses accumulator 7 for LFE PCM samples for 5.1 playback. The result samples
+are forwarded to the DSP 5 playback channel.
+
+name='PCM Playback Volume',index=0
+----------------------------------
+This control is used to attenuate samples from left and right PCM FX-bus
+accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for
+stereo playback. The result samples are forwarded to the virtual stereo mixer.
+
+name='PCM Capture Volume',index=0
+---------------------------------
+This control is used to attenuate samples from left and right PCM FX-bus
+accumulators. ALSA uses accumulators 0 and 1 for left and right PCM.
+The result is forwarded to the standard capture PCM device.
+
+name='Music Playback Volume',index=0
+------------------------------------
+This control is used to attenuate samples from left and right MIDI FX-bus
+accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
+The result samples are forwarded to the virtual stereo mixer.
+
+name='Music Capture Volume',index=0
+-----------------------------------
+These controls are used to attenuate samples from left and right MIDI FX-bus
+accumulator. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
+The result is forwarded to the standard capture PCM device.
+
+name='Front Playback Volume',index=0
+------------------------------------
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the DSP 0 & 1 playback channels.
+
+name='Surround Playback Volume',index=0
+---------------------------------------
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the DSP 2 & 3 playback channels.
+
+name='Side Playback Volume',index=0
+-----------------------------------
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the DSP 6 & 7 playback channels.
+
+name='Center Playback Volume',index=0
+-------------------------------------
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the DSP 4 playback channel.
+
+name='LFE Playback Volume',index=0
+----------------------------------
+This control is used to attenuate samples from the virtual stereo mixer.
+The result samples are forwarded to the DSP 5 playback channel.
+
+name='Tone Control - Switch',index=0
+------------------------------------
+This control turns the tone control on or off. The samples forwarded to
+the DSP playback channels are affected.
+
+name='Tone Control - Bass',index=0
+----------------------------------
+This control sets the bass intensity. There is no neutral value!!
+When the tone control code is activated, the samples are always modified.
+The closest value to pure signal is 20.
+
+name='Tone Control - Treble',index=0
+------------------------------------
+This control sets the treble intensity. There is no neutral value!!
+When the tone control code is activated, the samples are always modified.
+The closest value to pure signal is 20.
+
+name='Master Playback Volume',index=0
+-------------------------------------
+This control is used to attenuate samples for all DSP playback channels.
+
+name='EMU Capture Volume',index=0
+----------------------------------
+This control is used to attenuate samples from the DSP 0 & 1 capture channels.
+The result is forwarded to the standard capture PCM device.
+
+name='DAC Left',index=0, etc.
+-----------------------------
+Select the source for the given physical audio output. These may be physical
+inputs, playback channels (DSP xx, specified as a decimal number), or silence.
+
+name='DSP x',index=0
+--------------------
+Select the source for the given capture channel (specified as a hexadecimal
+digit). Same options as for the physical audio outputs.
+
+
+PCM stream related controls
+===========================
+
+These controls are described in audigy-mixer.rst.
+
+
+MANUALS/PATENTS
+===============
+
+See sb-live-mixer.rst.
diff --git a/Documentation/sound/cards/index.rst b/Documentation/sound/cards/index.rst
index 49c1f2f..e68bbb1 100644
--- a/Documentation/sound/cards/index.rst
+++ b/Documentation/sound/cards/index.rst
@@ -8,6 +8,7 @@
cmipci
sb-live-mixer
audigy-mixer
+ emu-mixer
emu10k1-jack
via82xx-mixer
audiophile-usb
diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst
index 4dd9bfe..27667f5 100644
--- a/Documentation/sound/cards/sb-live-mixer.rst
+++ b/Documentation/sound/cards/sb-live-mixer.rst
@@ -61,61 +61,61 @@
``name='Wave Playback Volume',index=0``
---------------------------------------
-This control is used to attenuate samples for left and right PCM FX-bus
+This control is used to attenuate samples from left and right PCM FX-bus
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
``name='Wave Surround Playback Volume',index=0``
------------------------------------------------
-This control is used to attenuate samples for left and right PCM FX-bus
+This control is used to attenuate samples from left and right PCM FX-bus
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples.
The result samples are forwarded to the rear I2S DACs. These DACs operates
separately (they are not inside the AC97 codec).
``name='Wave Center Playback Volume',index=0``
----------------------------------------------
-This control is used to attenuate samples for left and right PCM FX-bus
+This control is used to attenuate samples from left and right PCM FX-bus
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples.
The result is mixed to mono signal (single channel) and forwarded to
the ??rear?? right DAC PCM slot of the AC97 codec.
``name='Wave LFE Playback Volume',index=0``
-------------------------------------------
-This control is used to attenuate samples for left and right PCM FX-bus
+This control is used to attenuate samples from left and right PCM FX-bus
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM.
The result is mixed to mono signal (single channel) and forwarded to
the ??rear?? left DAC PCM slot of the AC97 codec.
``name='Wave Capture Volume',index=0``, ``name='Wave Capture Switch',index=0``
------------------------------------------------------------------------------
-These controls are used to attenuate samples for left and right PCM FX-bus
+These controls are used to attenuate samples from left and right PCM FX-bus
accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
The result is forwarded to the ADC capture FIFO (thus to the standard capture
PCM device).
``name='Synth Playback Volume',index=0``
----------------------------------------
-This control is used to attenuate samples for left and right MIDI FX-bus
+This control is used to attenuate samples from left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
``name='Synth Capture Volume',index=0``, ``name='Synth Capture Switch',index=0``
--------------------------------------------------------------------------------
-These controls are used to attenuate samples for left and right MIDI FX-bus
-accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.
+These controls are used to attenuate samples from left and right MIDI FX-bus
+accumulator. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result is forwarded to the ADC capture FIFO (thus to the standard capture
PCM device).
``name='Surround Playback Volume',index=0``
-------------------------------------------
-This control is used to attenuate samples for left and right rear PCM FX-bus
+This control is used to attenuate samples from left and right rear PCM FX-bus
accumulators. ALSA uses accumulators 2 and 3 for left and right rear PCM samples.
The result samples are forwarded to the rear I2S DACs. These DACs operate
separately (they are not inside the AC97 codec).
``name='Surround Capture Volume',index=0``, ``name='Surround Capture Switch',index=0``
--------------------------------------------------------------------------------------
-These controls are used to attenuate samples for left and right rear PCM FX-bus
+These controls are used to attenuate samples from left and right rear PCM FX-bus
accumulators. ALSA uses accumulators 2 and 3 for left and right rear PCM samples.
The result is forwarded to the ADC capture FIFO (thus to the standard capture
PCM device).
@@ -134,7 +134,7 @@
``name='AC97 Playback Volume',index=0``
---------------------------------------
-This control is used to attenuate samples for left and right front ADC PCM slots
+This control is used to attenuate samples from left and right front ADC PCM slots
of the AC97 codec. The result samples are forwarded to the front DAC PCM
slots of the AC97 codec.
@@ -145,7 +145,7 @@
``name='AC97 Capture Volume',index=0``
--------------------------------------
-This control is used to attenuate samples for left and right front ADC PCM slots
+This control is used to attenuate samples from left and right front ADC PCM slots
of the AC97 codec. The result is forwarded to the ADC capture FIFO (thus to
the standard capture PCM device).
diff --git a/Documentation/sound/designs/midi-2.0.rst b/Documentation/sound/designs/midi-2.0.rst
index 27d0d3d..45987f2 100644
--- a/Documentation/sound/designs/midi-2.0.rst
+++ b/Documentation/sound/designs/midi-2.0.rst
@@ -376,3 +376,191 @@
name and attributes accordingly, and notifies the changes via the
announcement to the ALSA sequencer system port, similarly like the
normal port change notification.
+
+
+MIDI2 USB Gadget Function Driver
+================================
+
+The latest kernel contains the support for USB MIDI 2.0 gadget
+function driver, which can be used for prototyping and debugging MIDI
+2.0 features.
+
+`CONFIG_USB_GADGET`, `CONFIG_USB_CONFIGFS` and
+`CONFIG_USB_CONFIGFS_F_MIDI2` need to be enabled for the MIDI2 gadget
+driver.
+
+In addition, for using a gadget driver, you need a working UDC driver.
+In the example below, we use `dummy_hcd` driver (enabled via
+`CONFIG_USB_DUMMY_HCD`) that is available on PC and VM for debugging
+purpose. There are other UDC drivers depending on the platform, and
+those can be used for a real device, instead, too.
+
+At first, on a system to run the gadget, load `libcomposite` module::
+
+ % modprobe libcomposite
+
+and you'll have `usb_gadget` subdirectory under configfs space
+(typically `/sys/kernel/config` on modern OS). Then create a gadget
+instance and add configurations there, for example::
+
+ % cd /sys/kernel/config
+ % mkdir usb_gadget/g1
+
+ % cd usb_gadget/g1
+ % mkdir configs/c.1
+ % mkdir functions/midi2.usb0
+
+ % echo 0x0004 > idProduct
+ % echo 0x17b3 > idVendor
+ % mkdir strings/0x409
+ % echo "ACME Enterprises" > strings/0x409/manufacturer
+ % echo "ACMESynth" > strings/0x409/product
+ % echo "ABCD12345" > strings/0x409/serialnumber
+
+ % mkdir configs/c.1/strings/0x409
+ % echo "Monosynth" > configs/c.1/strings/0x409/configuration
+ % echo 120 > configs/c.1/MaxPower
+
+At this point, there must be a subdirectory `ep.0`, and that is the
+configuration for a UMP Endpoint. You can fill the Endpoint
+information like::
+
+ % echo "ACMESynth" > functions/midi2.usb0/iface_name
+ % echo "ACMESynth" > functions/midi2.usb0/ep.0/ep_name
+ % echo "ABCD12345" > functions/midi2.usb0/ep.0/product_id
+ % echo 0x0123 > functions/midi2.usb0/ep.0/family
+ % echo 0x4567 > functions/midi2.usb0/ep.0/model
+ % echo 0x123456 > functions/midi2.usb0/ep.0/manufacturer
+ % echo 0x12345678 > functions/midi2.usb0/ep.0/sw_revision
+
+The default MIDI protocol can be set either 1 or 2::
+
+ % echo 2 > functions/midi2.usb0/ep.0/protocol
+
+And, you can find a subdirectory `block.0` under this Endpoint
+subdirectory. This defines the Function Block information::
+
+ % echo "Monosynth" > functions/midi2.usb0/ep.0/block.0/name
+ % echo 0 > functions/midi2.usb0/ep.0/block.0/first_group
+ % echo 1 > functions/midi2.usb0/ep.0/block.0/num_groups
+
+Finally, link the configuration and enable it::
+
+ % ln -s functions/midi2.usb0 configs/c.1
+ % echo dummy_udc.0 > UDC
+
+where `dummy_udc.0` is an example case and it differs depending on the
+system. You can find the UDC instances in `/sys/class/udc` and pass
+the found name instead::
+
+ % ls /sys/class/udc
+ dummy_udc.0
+
+Now, the MIDI 2.0 gadget device is enabled, and the gadget host
+creates a new sound card instance containing a UMP rawmidi device by
+`f_midi2` driver::
+
+ % cat /proc/asound/cards
+ ....
+ 1 [Gadget ]: f_midi2 - MIDI 2.0 Gadget
+ MIDI 2.0 Gadget
+
+And on the connected host, a similar card should appear, too, but with
+the card and device names given in the configfs above::
+
+ % cat /proc/asound/cards
+ ....
+ 2 [ACMESynth ]: USB-Audio - ACMESynth
+ ACME Enterprises ACMESynth at usb-dummy_hcd.0-1, high speed
+
+You can play a MIDI file on the gadget side::
+
+ % aplaymidi -p 20:1 to_host.mid
+
+and this will appear as an input from a MIDI device on the connected
+host::
+
+ % aseqdump -p 20:0 -u 2
+
+Vice versa, a playback on the connected host will work as an input on
+the gadget, too.
+
+Each Function Block may have different direction and UI-hint,
+specified via `direction` and `ui_hint` attributes.
+Passing `1` is for input-only, `2` for out-only and `3` for
+bidirectional (the default value). For example::
+
+ % echo 2 > functions/midi2.usb0/ep.0/block.0/direction
+ % echo 2 > functions/midi2.usb0/ep.0/block.0/ui_hint
+
+When you need more than one Function Blocks, you can create
+subdirectories `block.1`, `block.2`, etc dynamically, and configure
+them in the configuration procedure above before linking.
+For example, to create a second Function Block for a keyboard::
+
+ % mkdir functions/midi2.usb0/ep.0/block.1
+ % echo "Keyboard" > functions/midi2.usb0/ep.0/block.1/name
+ % echo 1 > functions/midi2.usb0/ep.0/block.1/first_group
+ % echo 1 > functions/midi2.usb0/ep.0/block.1/num_groups
+ % echo 1 > functions/midi2.usb0/ep.0/block.1/direction
+ % echo 1 > functions/midi2.usb0/ep.0/block.1/ui_hint
+
+The `block.*` subdirectories can be removed dynamically, too (except
+for `block.0` which is persistent).
+
+For assigning a Function Block for MIDI 1.0 I/O, set up in `is_midi1`
+attribute. 1 is for MIDI 1.0, and 2 is for MIDI 1.0 with low speed
+connection::
+
+ % echo 2 > functions/midi2.usb0/ep.0/block.1/is_midi1
+
+For disabling the processing of UMP Stream messages in the gadget
+driver, pass `0` to `process_ump` attribute in the top-level config::
+
+ % echo 0 > functions/midi2.usb0/process_ump
+
+The MIDI 1.0 interface at altset 0 is supported by the gadget driver,
+too. When MIDI 1.0 interface is selected by the connected host, the
+UMP I/O on the gadget is translated from/to USB MIDI 1.0 packets
+accordingly while the gadget driver keeps communicating with the
+user-space over UMP rawmidi.
+
+MIDI 1.0 ports are set up from the config in each Function Block.
+For example::
+
+ % echo 0 > functions/midi2.usb0/ep.0/block.0/midi1_first_group
+ % echo 1 > functions/midi2.usb0/ep.0/block.0/midi1_num_groups
+
+The configuration above will enable the Group 1 (the index 0) for MIDI
+1.0 interface. Note that those groups must be in the groups defined
+for the Function Block itself.
+
+The gadget driver supports more than one UMP Endpoints, too.
+Similarly like the Function Blocks, you can create a new subdirectory
+`ep.1` (but under the card top-level config) to enable a new Endpoint::
+
+ % mkdir functions/midi2.usb0/ep.1
+
+and create a new Function Block there. For example, to create 4
+Groups for the Function Block of this new Endpoint::
+
+ % mkdir functions/midi2.usb0/ep.1/block.0
+ % echo 4 > functions/midi2.usb0/ep.1/block.0/num_groups
+
+Now, you'll have 4 rawmidi devices in total: the first two are UMP
+rawmidi devices for Endpoint 0 and Endpoint 1, and other two for the
+legacy MIDI 1.0 rawmidi devices corresponding to both EP 0 and EP 1.
+
+The current altsetting on the gadget can be informed via a control
+element "Operation Mode" with `RAWMIDI` iface. e.g. you can read it
+via `amixer` program running on the gadget host like::
+
+ % amixer -c1 cget iface=RAWMIDI,name='Operation Mode'
+ ; type=INTEGER,access=r--v----,values=1,min=0,max=2,step=0
+ : values=2
+
+The value (shown in the second returned line with `: values=`)
+indicates 1 for MIDI 1.0 (altset 0), 2 for MIDI 2.0 (altset 1) and 0
+for unset.
+
+As of now, the configurations can't be changed after binding.
diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index 4335c98..cd42185 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -2018,8 +2018,8 @@
This callback is also atomic by default.
-copy_user, copy_kernel and fill_silence ops
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+copy and fill_silence ops
+~~~~~~~~~~~~~~~~~~~~~~~~~
These callbacks are not mandatory, and can be omitted in most cases.
These callbacks are used when the hardware buffer cannot be in the
@@ -3444,8 +3444,8 @@
The first case works fine if the external hardware buffer is large
enough. This method doesn't need any extra buffers and thus is more
-efficient. You need to define the ``copy_user`` and ``copy_kernel``
-callbacks for the data transfer, in addition to the ``fill_silence``
+efficient. You need to define the ``copy`` callback
+for the data transfer, in addition to the ``fill_silence``
callback for playback. However, there is a drawback: it cannot be
mmapped. The examples are GUS's GF1 PCM or emu8000's wavetable PCM.
@@ -3458,22 +3458,22 @@
buffer instead of the host memory. In this case, mmap is available only
on certain architectures like the Intel one. In non-mmap mode, the data
cannot be transferred as in the normal way. Thus you need to define the
-``copy_user``, ``copy_kernel`` and ``fill_silence`` callbacks as well,
+``copy`` and ``fill_silence`` callbacks as well,
as in the cases above. Examples are found in ``rme32.c`` and
``rme96.c``.
-The implementation of the ``copy_user``, ``copy_kernel`` and
+The implementation of the ``copy`` and
``silence`` callbacks depends upon whether the hardware supports
-interleaved or non-interleaved samples. The ``copy_user`` callback is
+interleaved or non-interleaved samples. The ``copy`` callback is
defined like below, a bit differently depending on whether the direction
is playback or capture::
- static int playback_copy_user(struct snd_pcm_substream *substream,
+ static int playback_copy(struct snd_pcm_substream *substream,
int channel, unsigned long pos,
- void __user *src, unsigned long count);
- static int capture_copy_user(struct snd_pcm_substream *substream,
+ struct iov_iter *src, unsigned long count);
+ static int capture_copy(struct snd_pcm_substream *substream,
int channel, unsigned long pos,
- void __user *dst, unsigned long count);
+ struct iov_iter *dst, unsigned long count);
In the case of interleaved samples, the second argument (``channel``) is
not used. The third argument (``pos``) specifies the position in bytes.
@@ -3490,18 +3490,17 @@
offset (``pos``) in the hardware buffer. When coded like memcpy-like
way, the copy would look like::
- my_memcpy_from_user(my_buffer + pos, src, count);
+ my_memcpy_from_iter(my_buffer + pos, src, count);
For the capture direction, you copy the given amount of data (``count``)
at the specified offset (``pos``) in the hardware buffer to the
specified pointer (``dst``)::
- my_memcpy_to_user(dst, my_buffer + pos, count);
+ my_memcpy_to_iter(dst, my_buffer + pos, count);
-Here the functions are named ``from_user`` and ``to_user`` because
-it's the user-space buffer that is passed to these callbacks. That
-is, the callback is supposed to copy data from/to the user-space
-directly to/from the hardware buffer.
+The given ``src`` or ``dst`` a struct iov_iter pointer containing the
+pointer and the size. Use the existing helpers to copy or access the
+data as defined in ``linux/uio.h``.
Careful readers might notice that these callbacks receive the
arguments in bytes, not in frames like other callbacks. It's because
@@ -3519,25 +3518,6 @@
details, please check ``isa/gus/gus_pcm.c`` or ``pci/rme9652/rme9652.c``
as examples.
-The above callbacks are the copies from/to the user-space buffer. There
-are some cases where we want to copy from/to the kernel-space buffer
-instead. In such a case, the ``copy_kernel`` callback is called. It'd
-look like::
-
- static int playback_copy_kernel(struct snd_pcm_substream *substream,
- int channel, unsigned long pos,
- void *src, unsigned long count);
- static int capture_copy_kernel(struct snd_pcm_substream *substream,
- int channel, unsigned long pos,
- void *dst, unsigned long count);
-
-As found easily, the only difference is that the buffer pointer is
-without a ``__user`` prefix; that is, a kernel-buffer pointer is passed
-in the fourth argument. Correspondingly, the implementation would be
-a version without the user-copy, such as::
-
- my_memcpy(my_buffer + pos, src, count);
-
Usually for the playback, another callback ``fill_silence`` is
defined. It's implemented in a similar way as the copy callbacks
above::
@@ -3545,10 +3525,10 @@
static int silence(struct snd_pcm_substream *substream, int channel,
unsigned long pos, unsigned long count);
-The meanings of arguments are the same as in the ``copy_user`` and
-``copy_kernel`` callbacks, although there is no buffer pointer
+The meanings of arguments are the same as in the ``copy`` callback,
+although there is no buffer pointer
argument. In the case of interleaved samples, the channel argument has
-no meaning, as for the ``copy_*`` callbacks.
+no meaning, as for the ``copy`` callback.
The role of the ``fill_silence`` callback is to set the given amount
(``count``) of silence data at the specified offset (``pos``) in the
diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
index ca8ac9e..a99716b 100644
--- a/Documentation/sphinx/cdomain.py
+++ b/Documentation/sphinx/cdomain.py
@@ -178,7 +178,7 @@
if len(arglist[0].split(" ")) > 1:
return False
- # This is a function-like macro, it's arguments are typeless!
+ # This is a function-like macro, its arguments are typeless!
signode += addnodes.desc_name(fullname, fullname)
paramlist = addnodes.desc_parameterlist()
signode += paramlist
diff --git a/Documentation/spi/spi-lm70llp.rst b/Documentation/spi/spi-lm70llp.rst
index 0144e12..2f20e5b 100644
--- a/Documentation/spi/spi-lm70llp.rst
+++ b/Documentation/spi/spi-lm70llp.rst
@@ -69,7 +69,7 @@
and not grounded by the host via D7), the transistor conducts and switches
the collector to zero, which is reflected on pin 13 of the DB25 parport
connector. When SI/O is Low (driven by the LM70 or the host) on the other
-hand, the transistor is cut off and the voltage tied to it's collector is
+hand, the transistor is cut off and the voltage tied to its collector is
reflected on pin 13 as a High level.
So: the getmiso inline routine in this driver takes this fact into account,
diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst
index b67a1b6..90a0535 100644
--- a/Documentation/subsystem-apis.rst
+++ b/Documentation/subsystem-apis.rst
@@ -10,6 +10,20 @@
as needed (or at least as we managed to add it — probably *not* all that is
needed).
+Core subsystems
+---------------
+
+.. toctree::
+ :maxdepth: 1
+
+ core-api/index
+ driver-api/index
+ mm/index
+ power/index
+ scheduler/index
+ timers/index
+ locking/index
+
Human interfaces
----------------
@@ -22,6 +36,18 @@
gpu/index
fb/index
+Networking interfaces
+---------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ networking/index
+ netlabel/index
+ infiniband/index
+ isdn/index
+ mhi/index
+
Storage interfaces
------------------
@@ -39,22 +65,13 @@
.. toctree::
:maxdepth: 1
- driver-api/index
- core-api/index
- locking/index
accounting/index
cpu-freq/index
fpga/index
i2c/index
iio/index
- isdn/index
- infiniband/index
leds/index
- netlabel/index
- networking/index
pcmcia/index
- power/index
- timers/index
spi/index
w1/index
watchdog/index
@@ -63,12 +80,9 @@
accel/index
security/index
crypto/index
- mm/index
bpf/index
usb/index
PCI/index
misc-devices/index
- scheduler/index
- mhi/index
peci/index
wmi/index
diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst
index 1b7cf4e..ab6cb60 100644
--- a/Documentation/tools/rtla/rtla-timerlat-top.rst
+++ b/Documentation/tools/rtla/rtla-timerlat-top.rst
@@ -117,7 +117,7 @@
The raw trace is saved in the **timerlat_trace.txt** file for further analysis.
Note that **rtla timerlat** was dispatched without changing *timerlat* tracer
-threads' priority. That is generally not needed because these threads hava
+threads' priority. That is generally not needed because these threads have
priority *FIFO:95* by default, which is a common priority used by real-time
kernel developers to analyze scheduling delays.
diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
index 70e34b8..89ac4e6 100644
--- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
+++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
@@ -675,7 +675,7 @@
reconstructed using only conditional branches.
There is currently no support in Perf for supplying modified binaries to the decoder, so this
- feature is only inteded to be used for debugging purposes or with a 3rd party tool.
+ feature is only intended to be used for debugging purposes or with a 3rd party tool.
Choosing this option will result in a significant increase in the amount of trace generated -
possible danger of overflows, or fewer instructions covered. Note, that this option also
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index f5fcb8e..759907c 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -219,6 +219,20 @@
The ".function" postfix can only be attached to values of size long, and can only
be compared with "==" or "!=".
+Cpumask fields or scalar fields that encode a CPU number can be filtered using
+a user-provided cpumask in cpulist format. The format is as follows::
+
+ CPUS{$cpulist}
+
+Operators available to cpumask filtering are:
+
+& (intersection), ==, !=
+
+For example, this will filter events that have their .target_cpu field present
+in the given cpumask::
+
+ target_cpu & CPUS{17-42}
+
5.2 Setting filters
-------------------
@@ -915,7 +929,7 @@
To create a kprobe event, an empty or partially empty kprobe event
should first be created using kprobe_event_gen_cmd_start(). The name
-of the event and the probe location should be specfied along with one
+of the event and the probe location should be specified along with one
or args each representing a probe field should be supplied to this
function. Before calling kprobe_event_gen_cmd_start(), the user
should create and initialize a dynevent_cmd object using
@@ -995,7 +1009,7 @@
layer that can be used to generate trace event commands. The
generated command strings can then be passed to the command-parsing
and event creation code that already exists in the trace event
-subystem for creating the corresponding trace events.
+subsystem for creating the corresponding trace events.
In a nutshell, the way it works is that the higher-level interface
code creates a struct dynevent_cmd object, then uses a couple
@@ -1068,7 +1082,7 @@
appended onto the end of the arg pair (here ';').
There's also a dynevent_str_add() function that can be used to simply
-add a string as-is, with no spaces, delimeters, or arg check.
+add a string as-is, with no spaces, delimiters, or arg check.
Any number of dynevent_*_add() calls can be made to build up the string
(until its length surpasses cmd->maxlen). When all the arguments have
diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst
index 40dd2fb..7a89551 100644
--- a/Documentation/trace/fprobe.rst
+++ b/Documentation/trace/fprobe.rst
@@ -113,7 +113,7 @@
the instruction pointer of @regs may be different from the @entry_ip
in the entry_handler. If you need traced instruction pointer, you need
to use @entry_ip. On the other hand, in the exit_handler, the instruction
- pointer of @regs is set to the currect return address.
+ pointer of @regs is set to the current return address.
@entry_data
This is a local storage to share the data between entry and exit handlers.
diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
index 7297f94..8e9bebc 100644
--- a/Documentation/trace/fprobetrace.rst
+++ b/Documentation/trace/fprobetrace.rst
@@ -79,9 +79,9 @@
f:fprobes/myprobe vfs_read count=count pos=pos
It also chooses the fetch type from BTF information. For example, in the above
-example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus, both
-are converted to 64bit unsigned long, but only ``pos`` has "%Lx" print-format as
-below ::
+example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus,
+both are converted to 64bit unsigned long, but only ``pos`` has "%Lx"
+print-format as below ::
# cat events/fprobes/myprobe/format
name: myprobe
@@ -105,9 +105,47 @@
# cat dynamic_events
f:fprobes/myprobe vfs_read file=file buf=buf count=count pos=pos
-BTF also affects the ``$retval``. If user doesn't set any type, the retval type is
-automatically picked from the BTF. If the function returns ``void``, ``$retval``
-is rejected.
+BTF also affects the ``$retval``. If user doesn't set any type, the retval
+type is automatically picked from the BTF. If the function returns ``void``,
+``$retval`` is rejected.
+
+You can access the data fields of a data structure using allow operator ``->``
+(for pointer type) and dot operator ``.`` (for data structure type.)::
+
+# echo 't sched_switch preempt prev_pid=prev->pid next_pid=next->pid' >> dynamic_events
+
+The field access operators, ``->`` and ``.`` can be combined for accessing deeper
+members and other structure members pointed by the member. e.g. ``foo->bar.baz->qux``
+If there is non-name union member, you can directly access it as the C code does.
+For example::
+
+ struct {
+ union {
+ int a;
+ int b;
+ };
+ } *foo;
+
+To access ``a`` and ``b``, use ``foo->a`` and ``foo->b`` in this case.
+
+This data field access is available for the return value via ``$retval``,
+e.g. ``$retval->name``.
+
+For these BTF arguments and fields, ``:string`` and ``:ustring`` change the
+behavior. If these are used for BTF argument or field, it checks whether
+the BTF type of the argument or the data field is ``char *`` or ``char []``,
+or not. If not, it rejects applying the string types. Also, with the BTF
+support, you don't need a memory dereference operator (``+0(PTR)``) for
+accessing the string pointed by a ``PTR``. It automatically adds the memory
+dereference operator according to the BTF type. e.g. ::
+
+# echo 't sched_switch prev->comm:string' >> dynamic_events
+# echo 'f getname_flags%return $retval->name:string' >> dynamic_events
+
+The ``prev->comm`` is an embedded char array in the data structure, and
+``$retval->name`` is a char pointer in the data structure. But in both
+cases, you can use ``:string`` type to get the string.
+
Usage examples
--------------
@@ -161,10 +199,10 @@
structure pointed by the ``prev`` and ``next`` arguments.
For example, usually ``task_struct::start_time`` is not traced, but with this
-traceprobe event, you can trace it as below.
+traceprobe event, you can trace that field as below.
::
- # echo 't sched_switch comm=+1896(next):string start_time=+1728(next):u64' > dynamic_events
+ # echo 't sched_switch comm=next->comm:string next->start_time' > dynamic_events
# head -n 20 trace | tail
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
@@ -176,13 +214,3 @@
<idle>-0 [000] d..3. 5606.690317: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
kworker/0:1-14 [000] d..3. 5606.690339: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
<idle>-0 [000] d..3. 5606.692368: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
-
-Currently, to find the offset of a specific field in the data structure,
-you need to build kernel with debuginfo and run `perf probe` command with
-`-D` option. e.g.
-::
-
- # perf probe -D "__probestub_sched_switch next->comm:string next->start_time"
- p:probe/__probestub_sched_switch __probestub_sched_switch+0 comm=+1896(%cx):string start_time=+1728(%cx):u64
-
-And replace the ``%cx`` with the ``next``.
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index f606c5b..23572f6 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -2725,7 +2725,7 @@
The return value of each traced function can be displayed after
an equal sign "=". When encountering system call failures, it
-can be verfy helpful to quickly locate the function that first
+can be very helpful to quickly locate the function that first
returns an error code.
- hide: echo nofuncgraph-retval > trace_options
diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst
index de94b49..11b749c 100644
--- a/Documentation/trace/hwlat_detector.rst
+++ b/Documentation/trace/hwlat_detector.rst
@@ -14,7 +14,7 @@
kernel is highly latency sensitive.
SMIs are not serviced by the Linux kernel, which means that it does not
-even know that they are occuring. SMIs are instead set up by BIOS code
+even know that they are occurring. SMIs are instead set up by BIOS code
and are serviced by BIOS code, usually for "critical" events such as
management of thermal sensors and fans. Sometimes though, SMIs are used for
other tasks and those tasks can spend an inordinate amount of time in the
diff --git a/Documentation/trace/rv/da_monitor_synthesis.rst b/Documentation/trace/rv/da_monitor_synthesis.rst
index 0dbdcd1..0a92729 100644
--- a/Documentation/trace/rv/da_monitor_synthesis.rst
+++ b/Documentation/trace/rv/da_monitor_synthesis.rst
@@ -1,7 +1,7 @@
Deterministic Automata Monitor Synthesis
========================================
-The starting point for the application of runtime verification (RV) technics
+The starting point for the application of runtime verification (RV) techniques
is the *specification* or *modeling* of the desired (or undesired) behavior
of the system under scrutiny.
diff --git a/Documentation/trace/rv/monitor_wwnr.rst b/Documentation/trace/rv/monitor_wwnr.rst
index 80f1777..9f73903 100644
--- a/Documentation/trace/rv/monitor_wwnr.rst
+++ b/Documentation/trace/rv/monitor_wwnr.rst
@@ -26,7 +26,7 @@
| running | -+
+-------------+
-This model is borken, the reason is that a task can be running
+This model is broken, the reason is that a task can be running
in the processor without being set as RUNNABLE. Think about a
task about to sleep::
diff --git a/Documentation/trace/rv/runtime-verification.rst b/Documentation/trace/rv/runtime-verification.rst
index c46b614..dae78df 100644
--- a/Documentation/trace/rv/runtime-verification.rst
+++ b/Documentation/trace/rv/runtime-verification.rst
@@ -31,7 +31,7 @@
*RV monitor* abstraction. A *RV monitor* includes a reference model of the
system, a set of instances of the monitor (per-cpu monitor, per-task monitor,
and so on), and the helper functions that glue the monitor to the system via
-trace, as depicted bellow::
+trace, as depicted below::
Linux +---- RV Monitor ----------------------------------+ Formal
Realm | | Realm
diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst
index 122d155..01f6a78 100644
--- a/Documentation/trace/uprobetracer.rst
+++ b/Documentation/trace/uprobetracer.rst
@@ -55,7 +55,7 @@
(\*1) only for return probe.
(\*2) this is useful for fetching a field of data structures.
- (\*3) Unlike kprobe event, "u" prefix will just be ignored, becuse uprobe
+ (\*3) Unlike kprobe event, "u" prefix will just be ignored, because uprobe
events can access only user-space memory.
Types
diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst
index e7b0731..f9530d0 100644
--- a/Documentation/trace/user_events.rst
+++ b/Documentation/trace/user_events.rst
@@ -93,7 +93,7 @@
**NOTE:** The event subsystem name by default is "user_events". Callers should
not assume it will always be "user_events". Operators reserve the right in the
-future to change the subsystem name per-process to accomodate event isolation.
+future to change the subsystem name per-process to accommodate event isolation.
Command Format
^^^^^^^^^^^^^^
diff --git a/Documentation/translations/sp_SP/process/contribution-maturity-model.rst b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst
new file mode 100644
index 0000000..cc052ae
--- /dev/null
+++ b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst
@@ -0,0 +1,120 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-sp.rst
+
+:Original: Documentation/process/contribution-maturity-model.rst
+:Translator: Avadhut Naik <avadhut.naik@amd.com>
+
+====================================================
+Modelo de Madurez de Contribución al Kernel de Linux
+====================================================
+
+
+Los Antecedentes
+================
+
+Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo
+una `discusión <https://lwn.net/Articles/870581/>`_ sobre los desafíos
+en el reclutamiento de mantenedores del kernel, así como la sucesión de
+los mantenedores. Algunas de las conclusiones de esa discusión incluyeron
+que las empresas que forman parte de la comunidad del kernel de Linux
+necesitan permitir que los ingenieros sean mantenedores como parte de su
+trabajo, para que puedan convertirse en lideres respetados y finalmente,
+en mantenedores del kernel. Para apoyar una fuente solida de talento, se
+debe permitir y alentar a los desarrolladores a asumir contribuciones
+upstream, como revisar los parches de otras personas, reestructurar la
+infraestructura del kernel y escribir documentación.
+
+Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone
+este Modelo de Madurez de Contribución al Kernel de Linux. Estas
+expectativas comunes para la participación con la comunidad upstream
+tienen como objetivo aumentar la influencia de los desarrolladores
+individuales, aumentar la colaboración de las organizaciones y mejorar
+la salud general del ecosistema del kernel de Linux.
+
+El TAB insta a las organizaciones a evaluar continuamente su modelo de
+madurez de Código Abierto y comprometerse a realizar mejoras para
+alinearse con este modelo. Para ser eficaz, esta evaluación debe
+incorporar la reacción de toda la organización, incluyendo la gerencia
+y los desarrolladores en todos los niveles de antigüedad. En el espíritu
+de Código Abierto, alentamos a las organizaciones a publicar sus
+evaluaciones y planes para mejorar su participación con la comunidad
+upstream.
+
+Nivel 0
+=======
+
+* A los ingenieros de software no se les permite contribuir con parches
+ al kernel de Linux.
+
+Nivel 1
+=======
+
+* A los ingenieros de software se les permite contribuir con parches al
+ kernel de Linux, ya sea como parte de sus responsabilidades de trabajo
+ o en su propio tiempo.
+
+Nivel 2
+=======
+
+* Se espera que los ingenieros de software contribuyan al kernel de Linux
+ como parte de sus responsabilidades de trabajo.
+* Se proporcionará apoyo a los ingenieros de software para asistir a
+ conferencias relacionadas con Linux como parte de su trabajo.
+* Las contribuciones de código upstream de un ingeniero de software se
+ considerarán en la promoción y las revisiones de rendimiento.
+
+Nivel 3
+=======
+
+* Se espera que los ingenieros de software revisen los parches (incluidos
+ los parches escritos por ingenieros de otras empresas) como parte de
+ sus responsabilidades de trabajo.
+* Contribuir con presentaciones o ponencias a conferencias relacionadas
+ con Linux o académicas (como las organizadas por la Fundación Linux,
+ Usenix, ACM, etc.), se consideran parte del trabajo de un ingeniero.
+* Las contribuciones a la comunidad de un ingeniero de software se
+ considerarán en la promoción y las revisiones de rendimiento.
+* Las organizaciones informarán regularmente sobre las métricas de sus
+ contribuciones de código abierto y harán un seguimiento de estas
+ métricas a lo largo del tiempo. Estas métricas pueden publicarse
+ solo internamente dentro de la organización, o a discreción de la
+ organización, algunas o todas pueden publicarse externamente. Las
+ métricas que se sugieren encarecidamente incluyen:
+
+ * El número de contribuciones al kernel upstream por equipo u
+ organización (por ejemplo, todas las personas que reportan a un
+ gerente o director o vicepresidente).
+ * El porcentaje de desarrolladores del kernel que han realizado
+ contribuciones upstream relativo al total de desarrolladores
+ del kernel en la organización.
+ * El intervalo de tiempo entre los kernels utilizados en los servidores
+ y/o productos de la organización y la fecha de publicación del kernel
+ upstream en el que se basa el kernel interno.
+ * El número de commits fuera del árbol de desarrollo presentes en los
+ kernels internos.
+
+Nivel 4
+=======
+
+* Se anima a los ingenieros de software a pasar una parte de su tiempo de
+ trabajo centrado en el Trabajo Ascendente, que se define como revisar
+ parches, servir en los comités de programas, mejorar la infraestructura
+ del proyecto central como escribir o mantener pruebas, reducir la deuda
+ de tecnología upstream, escribir documentación, etc.
+* Los ingenieros de software son apoyados para ayudar a organizar
+ conferencias relacionadas con Linux.
+* Las organizaciones considerarán los comentarios de los miembros de la
+ comunidad en las revisiones oficiales de rendimiento.
+
+Nivel 5
+=======
+
+* El desarrollo del kernel upstream se considera un puesto de trabajo
+ formal, con al menos un tercio del tiempo del ingeniero pasado a hacer
+ el Trabajo Ascendente.
+* Las organizaciones buscarán activamente las reacciones de los miembros
+ de la comunidad como un factor en las revisiones oficiales de
+ rendimiento.
+* Las organizaciones informarán regularmente internamente sobre la ratio
+ de trabajo upstream a trabajo enfocado en perseguir directamente los
+ objetivos comerciales.
diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst
index 0bdeb1e..09bfece 100644
--- a/Documentation/translations/sp_SP/process/index.rst
+++ b/Documentation/translations/sp_SP/process/index.rst
@@ -20,3 +20,5 @@
programming-language
deprecated
adding-syscalls
+ researcher-guidelines
+ contribution-maturity-model
diff --git a/Documentation/translations/sp_SP/process/researcher-guidelines.rst b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
new file mode 100644
index 0000000..462b329
--- /dev/null
+++ b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
@@ -0,0 +1,150 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+:Original: :ref:`Documentation/process/researcher-guidelines.rst`
+:Translator: Avadhut Naik <avadhut.naik@amd.com>
+
+Directrices para Investigadores
+++++++++++++++++++++++++++++++++
+
+La comunidad del kernel de Linux da la bienvenida a la investigación
+transparente sobre el kernel de Linux, las actividades involucradas
+en su producción, otros subproductos de su desarrollo. Linux se
+beneficia mucho de este tipo de investigación, y la mayoría de los
+aspectos de Linux son impulsados por investigación en una forma u otra.
+
+La comunidad agradece mucho si los investigadores pueden compartir
+los hallazgos preliminares antes de hacer públicos sus resultados,
+especialmente si tal investigación involucra seguridad. Involucrarse
+temprano ayuda a mejorar la calidad de investigación y la capacidad
+de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
+compartir copias de acceso abierto de la investigación publicada con
+la comunidad.
+
+Este documento busca clarificar lo que la comunidad del kernel de Linux
+considera practicas aceptables y no aceptables al llevar a cabo
+investigación de este tipo. Por lo menos, dicha investigación y
+actividades afines deben seguir las reglas estándar de ética de la
+investigación. Para más información sobre la ética de la investigación
+en general, ética en la tecnología y la investigación de las comunidades
+de desarrolladores en particular, ver:
+
+
+* `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
+* `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_
+* `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_
+
+La comunidad del kernel de Linux espera que todos los que interactúan con
+el proyecto están participando en buena fe para mejorar Linux. La
+investigación sobre cualquier artefacto disponible públicamente (incluido,
+pero no limitado a código fuente) producido por la comunidad del kernel
+de Linux es bienvenida, aunque la investigación sobre los desarrolladores
+debe ser claramente opcional.
+
+La investigación pasiva que se basa completamente en fuentes disponibles
+públicamente, incluidas las publicaciones en listas de correo públicas y
+las contribuciones a los repositorios públicos, es claramente permitida.
+Aunque, como con cualquier investigación, todavía se debe seguir la ética
+estándar.
+
+La investigación activa sobre el comportamiento de los desarrolladores,
+sin embargo, debe hacerse con el acuerdo explícito y la divulgación
+completa a los desarrolladores individuales involucrados. No se puede
+interactuar / experimentar con los desarrolladores sin consentimiento;
+esto también es ética de investigación estándar.
+
+Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar
+con ellos, pero ya han dado su consentimiento para recibir contribuciones
+en buena fe. No se ha dado consentimiento para enviar parches intencionalmente
+defectuosos / vulnerables o contribuir con la información engañosa a las
+discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por
+ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el
+proyecto al erosionar la confianza de toda la comunidad de desarrolladores en
+el colaborador (y la organización del colaborador en conjunto), socavando
+los esfuerzos para proporcionar reacciones constructivas a los colaboradores
+y poniendo a los usuarios finales en riesgo de fallas de software.
+
+La participación en el desarrollo de Linux en sí mismo por parte de
+investigadores, como con cualquiera, es bienvenida y alentada. La
+investigación del código de Linux es una práctica común, especialmente
+cuando se trata de desarrollar o ejecutar herramientas de análisis que
+producen resultados procesables.
+
+Cuando se interactúa con la comunidad de desarrolladores, enviar un
+parche ha sido tradicionalmente la mejor manera para hacer un impacto.
+Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
+tener soluciones verificadas. Antes de contribuir, lea cuidadosamente
+la documentación adecuada.
+
+* Documentation/process/development-process.rst
+* Documentation/process/submitting-patches.rst
+* Documentation/admin-guide/reporting-issues.rst
+* Documentation/process/security-bugs.rst
+
+Entonces envíe un parche (incluyendo un registro de confirmación con
+todos los detalles enumerados abajo) y haga un seguimiento de cualquier
+comentario de otros desarrolladores.
+
+* ¿Cuál es el problema específico que se ha encontrado?
+* ¿Como podría llegar al problema en un sistema en ejecución?
+* ¿Qué efecto tendría encontrar el problema en el sistema?
+* ¿Como se encontró el problema? Incluya específicamente detalles sobre
+ cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier
+ otra herramienta o método utilizado para realizar el trabajo.
+* ¿En qué versión de Linux se encontró el problema? Se prefiere usar la
+ versión más reciente o una rama reciente de linux-next (ver
+ Documentation/process/howto.rst).
+* ¿Que se cambió para solucionar el problema y por qué se cree es correcto?
+* ¿Como se probó el cambio para la complicación y el tiempo de ejecución?
+* ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:”
+ etiqueta como se describe en la documentación.
+* ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by”
+ etiqueta; Vea abajo.
+
+Por ejemplo (en inglés, pues es en las listas)::
+
+ From: Author <author@email>
+ Subject: [PATCH] drivers/foo_bar: Add missing kfree()
+
+ The error path in foo_bar driver does not correctly free the allocated
+ struct foo_bar_info. This can happen if the attached foo_bar device
+ rejects the initialization packets sent during foo_bar_probe(). This
+ would result in a 64 byte slab memory leak once per device attach,
+ wasting memory resources over time.
+
+ This flaw was found using an experimental static analysis tool we are
+ developing, LeakMagic[1], which reported the following warning when
+ analyzing the v5.15 kernel release:
+
+ path/to/foo_bar.c:187: missing kfree() call?
+
+ Add the missing kfree() to the error path. No other references to
+ this memory exist outside the probe function, so this is the only
+ place it can be freed.
+
+ x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
+ 11.2 show no new warnings, and LeakMagic no longer warns about this
+ code path. As we don't have a FooBar device to test with, no runtime
+ testing was able to be performed.
+
+ [1] https://url/to/leakmagic/details
+
+ Reported-by: Researcher <researcher@email>
+ Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
+ Signed-off-by: Author <author@email>
+ Reviewed-by: Reviewer <reviewer@email>
+
+Si usted es un colaborador por primera vez, se recomienda que el parche en
+si sea examinado por otros en privado antes de ser publicado en listas
+públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches
+necesitan una revisión interna más cuidadosa.) Se espera que estas personas
+tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar
+otro desarrollador con conocimiento de las contribuciones a Linux, especialmente
+dentro de su propia organización, y tener su ayuda con las revisiones antes de
+enviarlas a las listas de correo publico tiende a mejorar significativamente la
+calidad de los parches resultantes, y reduce así la carga de otros desarrolladores.
+
+Si no se puede encontrar a nadie para revisar internamente los parches y necesita
+ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada
+con este documento y las expectativas de la comunidad de desarrolladores, por
+favor contacte con la lista de correo privada Technical Advisory Board:
+<tech-board@lists.linux-foundation.org>.
diff --git a/Documentation/translations/zh_CN/arch/index.rst b/Documentation/translations/zh_CN/arch/index.rst
index 6fa0cb6..e3d273d 100644
--- a/Documentation/translations/zh_CN/arch/index.rst
+++ b/Documentation/translations/zh_CN/arch/index.rst
@@ -8,12 +8,12 @@
.. toctree::
:maxdepth: 2
- ../mips/index
+ mips/index
arm64/index
../riscv/index
openrisc/index
parisc/index
- ../loongarch/index
+ loongarch/index
TODOList:
diff --git a/Documentation/translations/zh_CN/arch/loongarch/booting.rst b/Documentation/translations/zh_CN/arch/loongarch/booting.rst
new file mode 100644
index 0000000..d2f5587
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/loongarch/booting.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/loongarch/booting.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+====================
+启动 Linux/LoongArch
+====================
+
+:作者: 司延腾 <siyanteng@loongson.cn>
+:日期: 2022年11月18日
+
+BootLoader传递给内核的信息
+==========================
+
+LoongArch支持ACPI和FDT启动，需要传递给内核的信息包括memmap、initrd、cmdline、可
+选的ACPI/FDT表等。
+
+内核在 `kernel_entry` 入口处被传递以下参数:
+
+ - a0 = efi_boot: `efi_boot` 是一个标志，表示这个启动环境是否完全符合UEFI
+ 的要求。
+
+ - a1 = cmdline: `cmdline` 是一个指向内核命令行的指针。
+
+ - a2 = systemtable: `systemtable` 指向EFI的系统表，在这个阶段涉及的所有
+ 指针都是物理地址。
+
+Linux/LoongArch内核镜像文件头
+=============================
+
+内核镜像是EFI镜像。作为PE文件，它们有一个64字节的头部结构体，如下所示::
+
+ u32 MZ_MAGIC /* "MZ", MS-DOS 头 */
+ u32 res0 = 0 /* 保留 */
+ u64 kernel_entry /* 内核入口点 */
+ u64 _end - _text /* 内核镜像有效大小 */
+ u64 load_offset /* 加载内核镜像相对内存起始地址的偏移量 */
+ u64 res1 = 0 /* 保留 */
+ u64 res2 = 0 /* 保留 */
+ u64 res3 = 0 /* 保留 */
+ u32 LINUX_PE_MAGIC /* 魔术数 */
+ u32 pe_header - _head /* 到PE头的偏移量 */
diff --git a/Documentation/translations/zh_CN/arch/loongarch/features.rst b/Documentation/translations/zh_CN/arch/loongarch/features.rst
new file mode 100644
index 0000000..82bfac1
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/loongarch/features.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/loongarch/features.rst
+:Translator: Huacai Chen <chenhuacai@loongson.cn>
+
+.. kernel-feat:: $srctree/Documentation/features loongarch
diff --git a/Documentation/translations/zh_CN/arch/loongarch/index.rst b/Documentation/translations/zh_CN/arch/loongarch/index.rst
new file mode 100644
index 0000000..4bd24f5
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/loongarch/index.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/loongarch/index.rst
+:Translator: Huacai Chen <chenhuacai@loongson.cn>
+
+=================
+LoongArch体系结构
+=================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ introduction
+ booting
+ irq-chip-model
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/arch/loongarch/introduction.rst b/Documentation/translations/zh_CN/arch/loongarch/introduction.rst
new file mode 100644
index 0000000..cba04be
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/loongarch/introduction.rst
@@ -0,0 +1,353 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/loongarch/introduction.rst
+:Translator: Huacai Chen <chenhuacai@loongson.cn>
+
+=============
+LoongArch介绍
+=============
+
+LoongArch是一种新的RISC ISA，在一定程度上类似于MIPS和RISC-V。LoongArch指令集
+包括一个精简32位版（LA32R）、一个标准32位版（LA32S）、一个64位版（LA64）。
+LoongArch定义了四个特权级（PLV0~PLV3），其中PLV0是最高特权级，用于内核；而PLV3
+是最低特权级，用于应用程序。本文档介绍了LoongArch的寄存器、基础指令集、虚拟内
+存以及其他一些主题。
+
+寄存器
+======
+
+LoongArch的寄存器包括通用寄存器（GPRs）、浮点寄存器（FPRs）、向量寄存器（VRs）
+和用于特权模式（PLV0）的控制状态寄存器（CSRs）。
+
+通用寄存器
+----------
+
+LoongArch包括32个通用寄存器（ ``$r0`` ~ ``$r31`` ），LA32中每个寄存器为32位宽，
+LA64中每个寄存器为64位宽。 ``$r0`` 的内容总是固定为0，而其他寄存器在体系结构层面
+没有特殊功能。（ ``$r1`` 算是一个例外，在BL指令中固定用作链接返回寄存器。）
+
+内核使用了一套LoongArch寄存器约定，定义在LoongArch ELF psABI规范中，详细描述参见
+:ref:`参考文献 <loongarch-references-zh_CN>`:
+
+================= =============== =================== ==========
+寄存器名 别名 用途 跨调用保持
+================= =============== =================== ==========
+``$r0`` ``$zero`` 常量0 不使用
+``$r1`` ``$ra`` 返回地址 否
+``$r2`` ``$tp`` TLS/线程信息指针 不使用
+``$r3`` ``$sp`` 栈指针 是
+``$r4``-``$r11`` ``$a0``-``$a7`` 参数寄存器 否
+``$r4``-``$r5`` ``$v0``-``$v1`` 返回值 否
+``$r12``-``$r20`` ``$t0``-``$t8`` 临时寄存器 否
+``$r21`` ``$u0`` 每CPU变量基地址 不使用
+``$r22`` ``$fp`` 帧指针 是
+``$r23``-``$r31`` ``$s0``-``$s8`` 静态寄存器 是
+================= =============== =================== ==========
+
+.. note::
+ 注意： ``$r21`` 寄存器在ELF psABI中保留未使用，但是在Linux内核用于保
+ 存每CPU变量基地址。该寄存器没有ABI命名，不过在内核中称为 ``$u0`` 。在
+ 一些遗留代码中有时可能见到 ``$v0`` 和 ``$v1`` ，它们是 ``$a0`` 和
+ ``$a1`` 的别名，属于已经废弃的用法。
+
+浮点寄存器
+----------
+
+当系统中存在FPU时，LoongArch有32个浮点寄存器（ ``$f0`` ~ ``$f31`` ）。在LA64
+的CPU核上，每个寄存器均为64位宽。
+
+浮点寄存器的使用约定与LoongArch ELF psABI规范的描述相同：
+
+================= ================== =================== ==========
+寄存器名 别名 用途 跨调用保持
+================= ================== =================== ==========
+``$f0``-``$f7`` ``$fa0``-``$fa7`` 参数寄存器 否
+``$f0``-``$f1`` ``$fv0``-``$fv1`` 返回值 否
+``$f8``-``$f23`` ``$ft0``-``$ft15`` 临时寄存器 否
+``$f24``-``$f31`` ``$fs0``-``$fs7`` 静态寄存器 是
+================= ================== =================== ==========
+
+.. note::
+ 注意：在一些遗留代码中有时可能见到 ``$fv0`` 和 ``$fv1`` ，它们是
+ ``$fa0`` 和 ``$fa1`` 的别名，属于已经废弃的用法。
+
+
+向量寄存器
+----------
+
+LoongArch现有两种向量扩展：
+
+- 128位向量扩展LSX（全称Loongson SIMD eXtention），
+- 256位向量扩展LASX（全称Loongson Advanced SIMD eXtention）。
+
+LSX使用 ``$v0`` ~ ``$v31`` 向量寄存器，而LASX则使用 ``$x0`` ~ ``$x31`` 。
+
+浮点寄存器和向量寄存器是复用的，比如：在一个实现了LSX和LASX的核上， ``$x0`` 的
+低128位与 ``$v0`` 共用， ``$v0`` 的低64位与 ``$f0`` 共用，其他寄存器依此类推。
+
+控制状态寄存器
+--------------
+
+控制状态寄存器只能在特权模式（PLV0）下访问:
+
+================= ==================================== ==========
+地址 全称描述 简称
+================= ==================================== ==========
+0x0 当前模式信息 CRMD
+0x1 异常前模式信息 PRMD
+0x2 扩展部件使能 EUEN
+0x3 杂项控制 MISC
+0x4 异常配置 ECFG
+0x5 异常状态 ESTAT
+0x6 异常返回地址 ERA
+0x7 出错(Faulting)虚拟地址 BADV
+0x8 出错(Faulting)指令字 BADI
+0xC 异常入口地址 EENTRY
+0x10 TLB索引 TLBIDX
+0x11 TLB表项高位 TLBEHI
+0x12 TLB表项低位0 TLBELO0
+0x13 TLB表项低位1 TLBELO1
+0x18 地址空间标识符 ASID
+0x19 低半地址空间页全局目录基址 PGDL
+0x1A 高半地址空间页全局目录基址 PGDH
+0x1B 页全局目录基址 PGD
+0x1C 页表遍历控制低半部分 PWCL
+0x1D 页表遍历控制高半部分 PWCH
+0x1E STLB页大小 STLBPS
+0x1F 缩减虚地址配置 RVACFG
+0x20 CPU编号 CPUID
+0x21 特权资源配置信息1 PRCFG1
+0x22 特权资源配置信息2 PRCFG2
+0x23 特权资源配置信息3 PRCFG3
+0x30+n (0≤n≤15) 数据保存寄存器 SAVEn
+0x40 定时器编号 TID
+0x41 定时器配置 TCFG
+0x42 定时器值 TVAL
+0x43 计时器补偿 CNTC
+0x44 定时器中断清除 TICLR
+0x60 LLBit相关控制 LLBCTL
+0x80 实现相关控制1 IMPCTL1
+0x81 实现相关控制2 IMPCTL2
+0x88 TLB重填异常入口地址 TLBRENTRY
+0x89 TLB重填异常出错(Faulting)虚地址 TLBRBADV
+0x8A TLB重填异常返回地址 TLBRERA
+0x8B TLB重填异常数据保存 TLBRSAVE
+0x8C TLB重填异常表项低位0 TLBRELO0
+0x8D TLB重填异常表项低位1 TLBRELO1
+0x8E TLB重填异常表项高位 TLBEHI
+0x8F TLB重填异常前模式信息 TLBRPRMD
+0x90 机器错误控制 MERRCTL
+0x91 机器错误信息1 MERRINFO1
+0x92 机器错误信息2 MERRINFO2
+0x93 机器错误异常入口地址 MERRENTRY
+0x94 机器错误异常返回地址 MERRERA
+0x95 机器错误异常数据保存 MERRSAVE
+0x98 高速缓存标签 CTAG
+0x180+n (0≤n≤3) 直接映射配置窗口n DMWn
+0x200+2n (0≤n≤31) 性能监测配置n PMCFGn
+0x201+2n (0≤n≤31) 性能监测计数器n PMCNTn
+0x300 内存读写监视点整体控制 MWPC
+0x301 内存读写监视点整体状态 MWPS
+0x310+8n (0≤n≤7) 内存读写监视点n配置1 MWPnCFG1
+0x311+8n (0≤n≤7) 内存读写监视点n配置2 MWPnCFG2
+0x312+8n (0≤n≤7) 内存读写监视点n配置3 MWPnCFG3
+0x313+8n (0≤n≤7) 内存读写监视点n配置4 MWPnCFG4
+0x380 取指监视点整体控制 FWPC
+0x381 取指监视点整体状态 FWPS
+0x390+8n (0≤n≤7) 取指监视点n配置1 FWPnCFG1
+0x391+8n (0≤n≤7) 取指监视点n配置2 FWPnCFG2
+0x392+8n (0≤n≤7) 取指监视点n配置3 FWPnCFG3
+0x393+8n (0≤n≤7) 取指监视点n配置4 FWPnCFG4
+0x500 调试寄存器 DBG
+0x501 调试异常返回地址 DERA
+0x502 调试数据保存 DSAVE
+================= ==================================== ==========
+
+ERA，TLBRERA，MERRERA和DERA有时也分别称为EPC，TLBREPC，MERREPC和DEPC。
+
+基础指令集
+==========
+
+指令格式
+--------
+
+LoongArch的指令字长为32位，一共有9种基本指令格式（以及一些变体）:
+
+=========== ==========================
+格式名称 指令构成
+=========== ==========================
+2R Opcode + Rj + Rd
+3R Opcode + Rk + Rj + Rd
+4R Opcode + Ra + Rk + Rj + Rd
+2RI8 Opcode + I8 + Rj + Rd
+2RI12 Opcode + I12 + Rj + Rd
+2RI14 Opcode + I14 + Rj + Rd
+2RI16 Opcode + I16 + Rj + Rd
+1RI21 Opcode + I21L + Rj + I21H
+I26 Opcode + I26L + I26H
+=========== ==========================
+
+Opcode是指令操作码，Rj和Rk是源操作数（寄存器），Rd是目标操作数（寄存器），Ra是
+4R-type格式特有的附加操作数（寄存器）。I8/I12/I14/I16/I21/I26分别是8位/12位/14位/
+16位/21位/26位的立即数。其中较长的21位和26位立即数在指令字中被分割为高位部分与低位
+部分，所以你们在这里的格式描述中能够看到I21L/I21H和I26L/I26H这样带后缀的表述。
+
+指令列表
+--------
+
+为了简便起见，我们在此只罗列一下指令名称（助记符），需要详细信息请阅读
+:ref:`参考文献 <loongarch-references-zh_CN>` 中的文档。
+
+1. 算术运算指令::
+
+ ADD.W SUB.W ADDI.W ADD.D SUB.D ADDI.D
+ SLT SLTU SLTI SLTUI
+ AND OR NOR XOR ANDN ORN ANDI ORI XORI
+ MUL.W MULH.W MULH.WU DIV.W DIV.WU MOD.W MOD.WU
+ MUL.D MULH.D MULH.DU DIV.D DIV.DU MOD.D MOD.DU
+ PCADDI PCADDU12I PCADDU18I
+ LU12I.W LU32I.D LU52I.D ADDU16I.D
+
+2. 移位运算指令::
+
+ SLL.W SRL.W SRA.W ROTR.W SLLI.W SRLI.W SRAI.W ROTRI.W
+ SLL.D SRL.D SRA.D ROTR.D SLLI.D SRLI.D SRAI.D ROTRI.D
+
+3. 位域操作指令::
+
+ EXT.W.B EXT.W.H CLO.W CLO.D SLZ.W CLZ.D CTO.W CTO.D CTZ.W CTZ.D
+ BYTEPICK.W BYTEPICK.D BSTRINS.W BSTRINS.D BSTRPICK.W BSTRPICK.D
+ REVB.2H REVB.4H REVB.2W REVB.D REVH.2W REVH.D BITREV.4B BITREV.8B BITREV.W BITREV.D
+ MASKEQZ MASKNEZ
+
+4. 分支转移指令::
+
+ BEQ BNE BLT BGE BLTU BGEU BEQZ BNEZ B BL JIRL
+
+5. 访存读写指令::
+
+ LD.B LD.BU LD.H LD.HU LD.W LD.WU LD.D ST.B ST.H ST.W ST.D
+ LDX.B LDX.BU LDX.H LDX.HU LDX.W LDX.WU LDX.D STX.B STX.H STX.W STX.D
+ LDPTR.W LDPTR.D STPTR.W STPTR.D
+ PRELD PRELDX
+
+6. 原子操作指令::
+
+ LL.W SC.W LL.D SC.D
+ AMSWAP.W AMSWAP.D AMADD.W AMADD.D AMAND.W AMAND.D AMOR.W AMOR.D AMXOR.W AMXOR.D
+ AMMAX.W AMMAX.D AMMIN.W AMMIN.D
+
+7. 栅障指令::
+
+ IBAR DBAR
+
+8. 特殊指令::
+
+ SYSCALL BREAK CPUCFG NOP IDLE ERTN(ERET) DBCL(DBGCALL) RDTIMEL.W RDTIMEH.W RDTIME.D
+ ASRTLE.D ASRTGT.D
+
+9. 特权指令::
+
+ CSRRD CSRWR CSRXCHG
+ IOCSRRD.B IOCSRRD.H IOCSRRD.W IOCSRRD.D IOCSRWR.B IOCSRWR.H IOCSRWR.W IOCSRWR.D
+ CACOP TLBP(TLBSRCH) TLBRD TLBWR TLBFILL TLBCLR TLBFLUSH INVTLB LDDIR LDPTE
+
+虚拟内存
+========
+
+LoongArch可以使用直接映射虚拟内存和分页映射虚拟内存。
+
+直接映射虚拟内存通过CSR.DMWn（n=0~3）来进行配置，虚拟地址（VA）和物理地址（PA）
+之间有简单的映射关系::
+
+ VA = PA + 固定偏移
+
+分页映射的虚拟地址（VA）和物理地址（PA）有任意的映射关系，这种关系记录在TLB和页
+表中。LoongArch的TLB包括一个全相联的MTLB（Multiple Page Size TLB，多样页大小TLB）
+和一个组相联的STLB（Single Page Size TLB，单一页大小TLB）。
+
+缺省状态下，LA32的整个虚拟地址空间配置如下：
+
+============ =========================== ===========================
+区段名 地址范围 属性
+============ =========================== ===========================
+``UVRANGE`` ``0x00000000 - 0x7FFFFFFF`` 分页映射, 可缓存, PLV0~3
+``KPRANGE0`` ``0x80000000 - 0x9FFFFFFF`` 直接映射, 非缓存, PLV0
+``KPRANGE1`` ``0xA0000000 - 0xBFFFFFFF`` 直接映射, 可缓存, PLV0
+``KVRANGE`` ``0xC0000000 - 0xFFFFFFFF`` 分页映射, 可缓存, PLV0
+============ =========================== ===========================
+
+用户态（PLV3）只能访问UVRANGE，对于直接映射的KPRANGE0和KPRANGE1，将虚拟地址的第
+30~31位清零就等于物理地址。例如：物理地址0x00001000对应的非缓存直接映射虚拟地址
+是0x80001000，而其可缓存直接映射虚拟地址是0xA0001000。
+
+缺省状态下，LA64的整个虚拟地址空间配置如下：
+
+============ ====================== ==================================
+区段名 地址范围 属性
+============ ====================== ==================================
+``XUVRANGE`` ``0x0000000000000000 - 分页映射, 可缓存, PLV0~3
+ 0x3FFFFFFFFFFFFFFF``
+``XSPRANGE`` ``0x4000000000000000 - 直接映射, 可缓存 / 非缓存, PLV0
+ 0x7FFFFFFFFFFFFFFF``
+``XKPRANGE`` ``0x8000000000000000 - 直接映射, 可缓存 / 非缓存, PLV0
+ 0xBFFFFFFFFFFFFFFF``
+``XKVRANGE`` ``0xC000000000000000 - 分页映射, 可缓存, PLV0
+ 0xFFFFFFFFFFFFFFFF``
+============ ====================== ==================================
+
+用户态（PLV3）只能访问XUVRANGE，对于直接映射的XSPRANGE和XKPRANGE，将虚拟地址的第
+60~63位清零就等于物理地址，而其缓存属性是通过虚拟地址的第60~61位配置的（0表示强序
+非缓存，1表示一致可缓存，2表示弱序非缓存）。
+
+目前，我们仅用XKPRANGE来进行直接映射，XSPRANGE保留给以后用。
+
+此处给出一个直接映射的例子：物理地址0x00000000_00001000的强序非缓存直接映射虚拟地址
+（在XKPRANGE中）是0x80000000_00001000，其一致可缓存直接映射虚拟地址（在XKPRANGE中）
+是0x90000000_00001000，而其弱序非缓存直接映射虚拟地址（在XKPRANGE中）是0xA0000000_
+00001000。
+
+Loongson与LoongArch的关系
+=========================
+
+LoongArch是一种RISC指令集架构（ISA），不同于现存的任何一种ISA，而Loongson（即龙
+芯）是一个处理器家族。龙芯包括三个系列：Loongson-1（龙芯1号）是32位处理器系列，
+Loongson-2（龙芯2号）是低端64位处理器系列，而Loongson-3（龙芯3号）是高端64位处理
+器系列。旧的龙芯处理器基于MIPS架构，而新的龙芯处理器基于LoongArch架构。以龙芯3号
+为例：龙芯3A1000/3B1500/3A2000/3A3000/3A4000都是兼容MIPS的，而龙芯3A5000（以及将
+来的型号）都是基于LoongArch的。
+
+.. _loongarch-references-zh_CN:
+
+参考文献
+========
+
+Loongson官方网站（龙芯中科技术股份有限公司）：
+
+ http://www.loongson.cn/
+
+Loongson与LoongArch的开发者网站（软件与文档资源）：
+
+ http://www.loongnix.cn/
+
+ https://github.com/loongson/
+
+ https://loongson.github.io/LoongArch-Documentation/
+
+LoongArch指令集架构的文档：
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-CN.pdf （中文版）
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-EN.pdf （英文版）
+
+LoongArch的ELF psABI文档：
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-CN.pdf （中文版）
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-EN.pdf （英文版）
+
+Loongson与LoongArch的Linux内核源码仓库：
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
diff --git a/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst b/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst
new file mode 100644
index 0000000..f1e9ab1
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst
@@ -0,0 +1,157 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/loongarch/irq-chip-model.rst
+:Translator: Huacai Chen <chenhuacai@loongson.cn>
+
+==================================
+LoongArch的IRQ芯片模型（层级关系）
+==================================
+
+目前，基于LoongArch的处理器（如龙芯3A5000）只能与LS7A芯片组配合工作。LoongArch计算机
+中的中断控制器（即IRQ芯片）包括CPUINTC（CPU Core Interrupt Controller）、LIOINTC（
+Legacy I/O Interrupt Controller）、EIOINTC（Extended I/O Interrupt Controller）、
+HTVECINTC（Hyper-Transport Vector Interrupt Controller）、PCH-PIC（LS7A芯片组的主中
+断控制器）、PCH-LPC（LS7A芯片组的LPC中断控制器）和PCH-MSI（MSI中断控制器）。
+
+CPUINTC是一种CPU内部的每个核本地的中断控制器，LIOINTC/EIOINTC/HTVECINTC是CPU内部的
+全局中断控制器（每个芯片一个，所有核共享），而PCH-PIC/PCH-LPC/PCH-MSI是CPU外部的中
+断控制器（在配套芯片组里面）。这些中断控制器（或者说IRQ芯片）以一种层次树的组织形式
+级联在一起，一共有两种层级关系模型（传统IRQ模型和扩展IRQ模型）。
+
+传统IRQ模型
+===========
+
+在这种模型里面，IPI（Inter-Processor Interrupt）和CPU本地时钟中断直接发送到CPUINTC，
+CPU串口（UARTs）中断发送到LIOINTC，而其他所有设备的中断则分别发送到所连接的PCH-PIC/
+PCH-LPC/PCH-MSI，然后被HTVECINTC统一收集，再发送到LIOINTC，最后到达CPUINTC::
+
+ +-----+ +---------+ +-------+
+ | IPI | --> | CPUINTC | <-- | Timer |
+ +-----+ +---------+ +-------+
+ ^
+ |
+ +---------+ +-------+
+ | LIOINTC | <-- | UARTs |
+ +---------+ +-------+
+ ^
+ |
+ +-----------+
+ | HTVECINTC |
+ +-----------+
+ ^ ^
+ | |
+ +---------+ +---------+
+ | PCH-PIC | | PCH-MSI |
+ +---------+ +---------+
+ ^ ^ ^
+ | | |
+ +---------+ +---------+ +---------+
+ | PCH-LPC | | Devices | | Devices |
+ +---------+ +---------+ +---------+
+ ^
+ |
+ +---------+
+ | Devices |
+ +---------+
+
+扩展IRQ模型
+===========
+
+在这种模型里面，IPI（Inter-Processor Interrupt）和CPU本地时钟中断直接发送到CPUINTC，
+CPU串口（UARTs）中断发送到LIOINTC，而其他所有设备的中断则分别发送到所连接的PCH-PIC/
+PCH-LPC/PCH-MSI，然后被EIOINTC统一收集，再直接到达CPUINTC::
+
+ +-----+ +---------+ +-------+
+ | IPI | --> | CPUINTC | <-- | Timer |
+ +-----+ +---------+ +-------+
+ ^ ^
+ | |
+ +---------+ +---------+ +-------+
+ | EIOINTC | | LIOINTC | <-- | UARTs |
+ +---------+ +---------+ +-------+
+ ^ ^
+ | |
+ +---------+ +---------+
+ | PCH-PIC | | PCH-MSI |
+ +---------+ +---------+
+ ^ ^ ^
+ | | |
+ +---------+ +---------+ +---------+
+ | PCH-LPC | | Devices | | Devices |
+ +---------+ +---------+ +---------+
+ ^
+ |
+ +---------+
+ | Devices |
+ +---------+
+
+ACPI相关的定义
+==============
+
+CPUINTC::
+
+ ACPI_MADT_TYPE_CORE_PIC;
+ struct acpi_madt_core_pic;
+ enum acpi_madt_core_pic_version;
+
+LIOINTC::
+
+ ACPI_MADT_TYPE_LIO_PIC;
+ struct acpi_madt_lio_pic;
+ enum acpi_madt_lio_pic_version;
+
+EIOINTC::
+
+ ACPI_MADT_TYPE_EIO_PIC;
+ struct acpi_madt_eio_pic;
+ enum acpi_madt_eio_pic_version;
+
+HTVECINTC::
+
+ ACPI_MADT_TYPE_HT_PIC;
+ struct acpi_madt_ht_pic;
+ enum acpi_madt_ht_pic_version;
+
+PCH-PIC::
+
+ ACPI_MADT_TYPE_BIO_PIC;
+ struct acpi_madt_bio_pic;
+ enum acpi_madt_bio_pic_version;
+
+PCH-MSI::
+
+ ACPI_MADT_TYPE_MSI_PIC;
+ struct acpi_madt_msi_pic;
+ enum acpi_madt_msi_pic_version;
+
+PCH-LPC::
+
+ ACPI_MADT_TYPE_LPC_PIC;
+ struct acpi_madt_lpc_pic;
+ enum acpi_madt_lpc_pic_version;
+
+参考文献
+========
+
+龙芯3A5000的文档：
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-CN.pdf (中文版)
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-EN.pdf (英文版)
+
+龙芯LS7A芯片组的文档：
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-CN.pdf (中文版)
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-EN.pdf (英文版)
+
+.. note::
+ - CPUINTC：即《龙芯架构参考手册卷一》第7.4节所描述的CSR.ECFG/CSR.ESTAT寄存器及其
+ 中断控制逻辑；
+ - LIOINTC：即《龙芯3A5000处理器使用手册》第11.1节所描述的“传统I/O中断”；
+ - EIOINTC：即《龙芯3A5000处理器使用手册》第11.2节所描述的“扩展I/O中断”；
+ - HTVECINTC：即《龙芯3A5000处理器使用手册》第14.3节所描述的“HyperTransport中断”；
+ - PCH-PIC/PCH-MSI：即《龙芯7A1000桥片用户手册》第5章所描述的“中断控制器”；
+ - PCH-LPC：即《龙芯7A1000桥片用户手册》第24.3节所描述的“LPC中断”。
diff --git a/Documentation/translations/zh_CN/arch/mips/booting.rst b/Documentation/translations/zh_CN/arch/mips/booting.rst
new file mode 100644
index 0000000..485b57e
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/mips/booting.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/mips/booting.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+.. _cn_booting:
+
+BMIPS设备树引导
+------------------------
+
+ 一些bootloaders只支持在内核镜像开始地址处的单一入口点。而其它
+ bootloaders将跳转到ELF的开始地址处。两种方案都支持的；因为
+ CONFIG_BOOT_RAW=y and CONFIG_NO_EXCEPT_FILL=y, 所以第一条指令
+ 会立即跳转到kernel_entry()入口处执行。
+
+ 与arch/arm情况(b)类似，dt感知的引导加载程序需要设置以下寄存器:
+
+ a0 : 0
+
+ a1 : 0xffffffff
+
+ a2 : RAM中指向设备树块的物理指针(在chapterII中定义)。
+ 设备树可以位于前512MB物理地址空间(0x00000000 -
+ 0x1fffffff)的任何位置，以64位边界对齐。
+
+ 传统bootloaders不会使用这样的约定，并且它们不传入DT块。
+ 在这种情况下，Linux将通过选中CONFIG_DT_*查找DTB。
+
+ 以上约定只在32位系统中定义，因为目前没有任何64位的BMIPS实现。
diff --git a/Documentation/translations/zh_CN/arch/mips/features.rst b/Documentation/translations/zh_CN/arch/mips/features.rst
new file mode 100644
index 0000000..da1b956e
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/mips/features.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/mips/features.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+.. _cn_features:
+
+.. kernel-feat:: $srctree/Documentation/features mips
diff --git a/Documentation/translations/zh_CN/arch/mips/index.rst b/Documentation/translations/zh_CN/arch/mips/index.rst
new file mode 100644
index 0000000..2a34217
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/mips/index.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/mips/index.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+===========================
+MIPS特性文档
+===========================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ booting
+ ingenic-tcu
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst
new file mode 100644
index 0000000..3d599a3
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/mips/ingenic-tcu.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+.. _cn_ingenic-tcu:
+
+===============================================
+君正 JZ47xx SoC定时器/计数器硬件单元
+===============================================
+
+君正 JZ47xx SoC中的定时器/计数器单元(TCU)是一个多功能硬件块。它有多达
+8个通道，可以用作计数器，计时器，或脉冲宽度调制器。
+
+- JZ4725B, JZ4750, JZ4755 只有６个TCU通道。其它SoC都有８个通道。
+
+- JZ4725B引入了一个独立的通道，称为操作系统计时器(OST)。这是一个32位可
+ 编程定时器。在JZ4760B及以上型号上，它是64位的。
+
+- 每个TCU通道都有自己的时钟源，可以通过 TCSR 寄存器设置通道的父级时钟
+ 源（pclk、ext、rtc）、开关以及分频。
+
+ - 看门狗和OST硬件模块在它们的寄存器空间中也有相同形式的TCSR寄存器。
+ - 用于关闭/开启的 TCU 寄存器也可以关闭/开启看门狗和 OST 时钟。
+
+- 每个TCU通道在两种模式的其中一种模式下运行：
+
+ - 模式 TCU1：通道无法在睡眠模式下运行，但更易于操作。
+ - 模式 TCU2：通道可以在睡眠模式下运行，但操作比 TCU1 通道复杂一些。
+
+- 每个 TCU 通道的模式取决于使用的SoC：
+
+ - 在最老的SoC（高于JZ4740），八个通道都运行在TCU1模式。
+ - 在 JZ4725B，通道5运行在TCU2,其它通道则运行在TCU1。
+ - 在最新的SoC（JZ4750及之后），通道1-2运行在TCU2，其它通道则运行
+ 在TCU1。
+
+- 每个通道都可以生成中断。有些通道共享一条中断线，而有些没有，其在SoC型
+ 号之间的变更：
+
+ - 在很老的SoC（JZ4740及更低），通道0和通道1有它们自己的中断线；通
+ 道2-7共享最后一条中断线。
+ - 在 JZ4725B，通道0有它自己的中断线；通道1-5共享一条中断线；OST
+ 使用最后一条中断线。
+ - 在比较新的SoC（JZ4750及以后），通道5有它自己的中断线；通
+ 道0-4和（如果是8通道）6-7全部共享一条中断线；OST使用最后一条中
+ 断线。
+
+实现
+====
+
+TCU硬件的功能分布在多个驱动程序：
+
+============== ===================================
+时钟 drivers/clk/ingenic/tcu.c
+中断 drivers/irqchip/irq-ingenic-tcu.c
+定时器 drivers/clocksource/ingenic-timer.c
+OST drivers/clocksource/ingenic-ost.c
+脉冲宽度调制器 drivers/pwm/pwm-jz4740.c
+看门狗 drivers/watchdog/jz4740_wdt.c
+============== ===================================
+
+因为可以从相同的寄存器控制属于不同驱动程序和框架的TCU的各种功能，所以
+所有这些驱动程序都通过相同的控制总线通用接口访问它们的寄存器。
+
+有关TCU驱动程序的设备树绑定的更多信息，请参阅:
+Documentation/devicetree/bindings/timer/ingenic,tcu.yaml.
diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
index af65e7e..69e7e4c 100644
--- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -3,7 +3,7 @@
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/dev-tools/testing-overview.rst
-:Translator: 胡皓文 Hu Haowen <src.res@email.cn>
+:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
============
内核测试指南
diff --git a/Documentation/translations/zh_CN/loongarch/booting.rst b/Documentation/translations/zh_CN/loongarch/booting.rst
deleted file mode 100644
index fb6440c..0000000
--- a/Documentation/translations/zh_CN/loongarch/booting.rst
+++ /dev/null
@@ -1,48 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/loongarch/booting.rst
-
-:翻译:
-
- 司延腾 Yanteng Si <siyanteng@loongson.cn>
-
-====================
-启动 Linux/LoongArch
-====================
-
-:作者: 司延腾 <siyanteng@loongson.cn>
-:日期: 2022年11月18日
-
-BootLoader传递给内核的信息
-==========================
-
-LoongArch支持ACPI和FDT启动，需要传递给内核的信息包括memmap、initrd、cmdline、可
-选的ACPI/FDT表等。
-
-内核在 `kernel_entry` 入口处被传递以下参数:
-
- - a0 = efi_boot: `efi_boot` 是一个标志，表示这个启动环境是否完全符合UEFI
- 的要求。
-
- - a1 = cmdline: `cmdline` 是一个指向内核命令行的指针。
-
- - a2 = systemtable: `systemtable` 指向EFI的系统表，在这个阶段涉及的所有
- 指针都是物理地址。
-
-Linux/LoongArch内核镜像文件头
-=============================
-
-内核镜像是EFI镜像。作为PE文件，它们有一个64字节的头部结构体，如下所示::
-
- u32 MZ_MAGIC /* "MZ", MS-DOS 头 */
- u32 res0 = 0 /* 保留 */
- u64 kernel_entry /* 内核入口点 */
- u64 _end - _text /* 内核镜像有效大小 */
- u64 load_offset /* 加载内核镜像相对内存起始地址的偏移量 */
- u64 res1 = 0 /* 保留 */
- u64 res2 = 0 /* 保留 */
- u64 res3 = 0 /* 保留 */
- u32 LINUX_PE_MAGIC /* 魔术数 */
- u32 pe_header - _head /* 到PE头的偏移量 */
diff --git a/Documentation/translations/zh_CN/loongarch/features.rst b/Documentation/translations/zh_CN/loongarch/features.rst
deleted file mode 100644
index 3886e63..0000000
--- a/Documentation/translations/zh_CN/loongarch/features.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/loongarch/features.rst
-:Translator: Huacai Chen <chenhuacai@loongson.cn>
-
-.. kernel-feat:: $srctree/Documentation/features loongarch
diff --git a/Documentation/translations/zh_CN/loongarch/index.rst b/Documentation/translations/zh_CN/loongarch/index.rst
deleted file mode 100644
index 0273a08..0000000
--- a/Documentation/translations/zh_CN/loongarch/index.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/loongarch/index.rst
-:Translator: Huacai Chen <chenhuacai@loongson.cn>
-
-=================
-LoongArch体系结构
-=================
-
-.. toctree::
- :maxdepth: 2
- :numbered:
-
- introduction
- booting
- irq-chip-model
-
- features
-
-.. only:: subproject and html
-
- Indices
- =======
-
- * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/loongarch/introduction.rst b/Documentation/translations/zh_CN/loongarch/introduction.rst
deleted file mode 100644
index 470c38a..0000000
--- a/Documentation/translations/zh_CN/loongarch/introduction.rst
+++ /dev/null
@@ -1,353 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/loongarch/introduction.rst
-:Translator: Huacai Chen <chenhuacai@loongson.cn>
-
-=============
-LoongArch介绍
-=============
-
-LoongArch是一种新的RISC ISA，在一定程度上类似于MIPS和RISC-V。LoongArch指令集
-包括一个精简32位版（LA32R）、一个标准32位版（LA32S）、一个64位版（LA64）。
-LoongArch定义了四个特权级（PLV0~PLV3），其中PLV0是最高特权级，用于内核；而PLV3
-是最低特权级，用于应用程序。本文档介绍了LoongArch的寄存器、基础指令集、虚拟内
-存以及其他一些主题。
-
-寄存器
-======
-
-LoongArch的寄存器包括通用寄存器（GPRs）、浮点寄存器（FPRs）、向量寄存器（VRs）
-和用于特权模式（PLV0）的控制状态寄存器（CSRs）。
-
-通用寄存器
-----------
-
-LoongArch包括32个通用寄存器（ ``$r0`` ~ ``$r31`` ），LA32中每个寄存器为32位宽，
-LA64中每个寄存器为64位宽。 ``$r0`` 的内容总是固定为0，而其他寄存器在体系结构层面
-没有特殊功能。（ ``$r1`` 算是一个例外，在BL指令中固定用作链接返回寄存器。）
-
-内核使用了一套LoongArch寄存器约定，定义在LoongArch ELF psABI规范中，详细描述参见
-:ref:`参考文献 <loongarch-references-zh_CN>`:
-
-================= =============== =================== ==========
-寄存器名 别名 用途 跨调用保持
-================= =============== =================== ==========
-``$r0`` ``$zero`` 常量0 不使用
-``$r1`` ``$ra`` 返回地址 否
-``$r2`` ``$tp`` TLS/线程信息指针 不使用
-``$r3`` ``$sp`` 栈指针 是
-``$r4``-``$r11`` ``$a0``-``$a7`` 参数寄存器 否
-``$r4``-``$r5`` ``$v0``-``$v1`` 返回值 否
-``$r12``-``$r20`` ``$t0``-``$t8`` 临时寄存器 否
-``$r21`` ``$u0`` 每CPU变量基地址 不使用
-``$r22`` ``$fp`` 帧指针 是
-``$r23``-``$r31`` ``$s0``-``$s8`` 静态寄存器 是
-================= =============== =================== ==========
-
-.. note::
- 注意： ``$r21`` 寄存器在ELF psABI中保留未使用，但是在Linux内核用于保
- 存每CPU变量基地址。该寄存器没有ABI命名，不过在内核中称为 ``$u0`` 。在
- 一些遗留代码中有时可能见到 ``$v0`` 和 ``$v1`` ，它们是 ``$a0`` 和
- ``$a1`` 的别名，属于已经废弃的用法。
-
-浮点寄存器
-----------
-
-当系统中存在FPU时，LoongArch有32个浮点寄存器（ ``$f0`` ~ ``$f31`` ）。在LA64
-的CPU核上，每个寄存器均为64位宽。
-
-浮点寄存器的使用约定与LoongArch ELF psABI规范的描述相同：
-
-================= ================== =================== ==========
-寄存器名 别名 用途 跨调用保持
-================= ================== =================== ==========
-``$f0``-``$f7`` ``$fa0``-``$fa7`` 参数寄存器 否
-``$f0``-``$f1`` ``$fv0``-``$fv1`` 返回值 否
-``$f8``-``$f23`` ``$ft0``-``$ft15`` 临时寄存器 否
-``$f24``-``$f31`` ``$fs0``-``$fs7`` 静态寄存器 是
-================= ================== =================== ==========
-
-.. note::
- 注意：在一些遗留代码中有时可能见到 ``$fv0`` 和 ``$fv1`` ，它们是
- ``$fa0`` 和 ``$fa1`` 的别名，属于已经废弃的用法。
-
-
-向量寄存器
-----------
-
-LoongArch现有两种向量扩展：
-
-- 128位向量扩展LSX（全称Loongson SIMD eXtention），
-- 256位向量扩展LASX（全称Loongson Advanced SIMD eXtention）。
-
-LSX使用 ``$v0`` ~ ``$v31`` 向量寄存器，而LASX则使用 ``$x0`` ~ ``$x31`` 。
-
-浮点寄存器和向量寄存器是复用的，比如：在一个实现了LSX和LASX的核上， ``$x0`` 的
-低128位与 ``$v0`` 共用， ``$v0`` 的低64位与 ``$f0`` 共用，其他寄存器依此类推。
-
-控制状态寄存器
---------------
-
-控制状态寄存器只能在特权模式（PLV0）下访问:
-
-================= ==================================== ==========
-地址 全称描述 简称
-================= ==================================== ==========
-0x0 当前模式信息 CRMD
-0x1 异常前模式信息 PRMD
-0x2 扩展部件使能 EUEN
-0x3 杂项控制 MISC
-0x4 异常配置 ECFG
-0x5 异常状态 ESTAT
-0x6 异常返回地址 ERA
-0x7 出错(Faulting)虚拟地址 BADV
-0x8 出错(Faulting)指令字 BADI
-0xC 异常入口地址 EENTRY
-0x10 TLB索引 TLBIDX
-0x11 TLB表项高位 TLBEHI
-0x12 TLB表项低位0 TLBELO0
-0x13 TLB表项低位1 TLBELO1
-0x18 地址空间标识符 ASID
-0x19 低半地址空间页全局目录基址 PGDL
-0x1A 高半地址空间页全局目录基址 PGDH
-0x1B 页全局目录基址 PGD
-0x1C 页表遍历控制低半部分 PWCL
-0x1D 页表遍历控制高半部分 PWCH
-0x1E STLB页大小 STLBPS
-0x1F 缩减虚地址配置 RVACFG
-0x20 CPU编号 CPUID
-0x21 特权资源配置信息1 PRCFG1
-0x22 特权资源配置信息2 PRCFG2
-0x23 特权资源配置信息3 PRCFG3
-0x30+n (0≤n≤15) 数据保存寄存器 SAVEn
-0x40 定时器编号 TID
-0x41 定时器配置 TCFG
-0x42 定时器值 TVAL
-0x43 计时器补偿 CNTC
-0x44 定时器中断清除 TICLR
-0x60 LLBit相关控制 LLBCTL
-0x80 实现相关控制1 IMPCTL1
-0x81 实现相关控制2 IMPCTL2
-0x88 TLB重填异常入口地址 TLBRENTRY
-0x89 TLB重填异常出错(Faulting)虚地址 TLBRBADV
-0x8A TLB重填异常返回地址 TLBRERA
-0x8B TLB重填异常数据保存 TLBRSAVE
-0x8C TLB重填异常表项低位0 TLBRELO0
-0x8D TLB重填异常表项低位1 TLBRELO1
-0x8E TLB重填异常表项高位 TLBEHI
-0x8F TLB重填异常前模式信息 TLBRPRMD
-0x90 机器错误控制 MERRCTL
-0x91 机器错误信息1 MERRINFO1
-0x92 机器错误信息2 MERRINFO2
-0x93 机器错误异常入口地址 MERRENTRY
-0x94 机器错误异常返回地址 MERRERA
-0x95 机器错误异常数据保存 MERRSAVE
-0x98 高速缓存标签 CTAG
-0x180+n (0≤n≤3) 直接映射配置窗口n DMWn
-0x200+2n (0≤n≤31) 性能监测配置n PMCFGn
-0x201+2n (0≤n≤31) 性能监测计数器n PMCNTn
-0x300 内存读写监视点整体控制 MWPC
-0x301 内存读写监视点整体状态 MWPS
-0x310+8n (0≤n≤7) 内存读写监视点n配置1 MWPnCFG1
-0x311+8n (0≤n≤7) 内存读写监视点n配置2 MWPnCFG2
-0x312+8n (0≤n≤7) 内存读写监视点n配置3 MWPnCFG3
-0x313+8n (0≤n≤7) 内存读写监视点n配置4 MWPnCFG4
-0x380 取指监视点整体控制 FWPC
-0x381 取指监视点整体状态 FWPS
-0x390+8n (0≤n≤7) 取指监视点n配置1 FWPnCFG1
-0x391+8n (0≤n≤7) 取指监视点n配置2 FWPnCFG2
-0x392+8n (0≤n≤7) 取指监视点n配置3 FWPnCFG3
-0x393+8n (0≤n≤7) 取指监视点n配置4 FWPnCFG4
-0x500 调试寄存器 DBG
-0x501 调试异常返回地址 DERA
-0x502 调试数据保存 DSAVE
-================= ==================================== ==========
-
-ERA，TLBRERA，MERRERA和DERA有时也分别称为EPC，TLBREPC，MERREPC和DEPC。
-
-基础指令集
-==========
-
-指令格式
---------
-
-LoongArch的指令字长为32位，一共有9种基本指令格式（以及一些变体）:
-
-=========== ==========================
-格式名称 指令构成
-=========== ==========================
-2R Opcode + Rj + Rd
-3R Opcode + Rk + Rj + Rd
-4R Opcode + Ra + Rk + Rj + Rd
-2RI8 Opcode + I8 + Rj + Rd
-2RI12 Opcode + I12 + Rj + Rd
-2RI14 Opcode + I14 + Rj + Rd
-2RI16 Opcode + I16 + Rj + Rd
-1RI21 Opcode + I21L + Rj + I21H
-I26 Opcode + I26L + I26H
-=========== ==========================
-
-Opcode是指令操作码，Rj和Rk是源操作数（寄存器），Rd是目标操作数（寄存器），Ra是
-4R-type格式特有的附加操作数（寄存器）。I8/I12/I14/I16/I21/I26分别是8位/12位/14位/
-16位/21位/26位的立即数。其中较长的21位和26位立即数在指令字中被分割为高位部分与低位
-部分，所以你们在这里的格式描述中能够看到I21L/I21H和I26L/I26H这样带后缀的表述。
-
-指令列表
---------
-
-为了简便起见，我们在此只罗列一下指令名称（助记符），需要详细信息请阅读
-:ref:`参考文献 <loongarch-references-zh_CN>` 中的文档。
-
-1. 算术运算指令::
-
- ADD.W SUB.W ADDI.W ADD.D SUB.D ADDI.D
- SLT SLTU SLTI SLTUI
- AND OR NOR XOR ANDN ORN ANDI ORI XORI
- MUL.W MULH.W MULH.WU DIV.W DIV.WU MOD.W MOD.WU
- MUL.D MULH.D MULH.DU DIV.D DIV.DU MOD.D MOD.DU
- PCADDI PCADDU12I PCADDU18I
- LU12I.W LU32I.D LU52I.D ADDU16I.D
-
-2. 移位运算指令::
-
- SLL.W SRL.W SRA.W ROTR.W SLLI.W SRLI.W SRAI.W ROTRI.W
- SLL.D SRL.D SRA.D ROTR.D SLLI.D SRLI.D SRAI.D ROTRI.D
-
-3. 位域操作指令::
-
- EXT.W.B EXT.W.H CLO.W CLO.D SLZ.W CLZ.D CTO.W CTO.D CTZ.W CTZ.D
- BYTEPICK.W BYTEPICK.D BSTRINS.W BSTRINS.D BSTRPICK.W BSTRPICK.D
- REVB.2H REVB.4H REVB.2W REVB.D REVH.2W REVH.D BITREV.4B BITREV.8B BITREV.W BITREV.D
- MASKEQZ MASKNEZ
-
-4. 分支转移指令::
-
- BEQ BNE BLT BGE BLTU BGEU BEQZ BNEZ B BL JIRL
-
-5. 访存读写指令::
-
- LD.B LD.BU LD.H LD.HU LD.W LD.WU LD.D ST.B ST.H ST.W ST.D
- LDX.B LDX.BU LDX.H LDX.HU LDX.W LDX.WU LDX.D STX.B STX.H STX.W STX.D
- LDPTR.W LDPTR.D STPTR.W STPTR.D
- PRELD PRELDX
-
-6. 原子操作指令::
-
- LL.W SC.W LL.D SC.D
- AMSWAP.W AMSWAP.D AMADD.W AMADD.D AMAND.W AMAND.D AMOR.W AMOR.D AMXOR.W AMXOR.D
- AMMAX.W AMMAX.D AMMIN.W AMMIN.D
-
-7. 栅障指令::
-
- IBAR DBAR
-
-8. 特殊指令::
-
- SYSCALL BREAK CPUCFG NOP IDLE ERTN(ERET) DBCL(DBGCALL) RDTIMEL.W RDTIMEH.W RDTIME.D
- ASRTLE.D ASRTGT.D
-
-9. 特权指令::
-
- CSRRD CSRWR CSRXCHG
- IOCSRRD.B IOCSRRD.H IOCSRRD.W IOCSRRD.D IOCSRWR.B IOCSRWR.H IOCSRWR.W IOCSRWR.D
- CACOP TLBP(TLBSRCH) TLBRD TLBWR TLBFILL TLBCLR TLBFLUSH INVTLB LDDIR LDPTE
-
-虚拟内存
-========
-
-LoongArch可以使用直接映射虚拟内存和分页映射虚拟内存。
-
-直接映射虚拟内存通过CSR.DMWn（n=0~3）来进行配置，虚拟地址（VA）和物理地址（PA）
-之间有简单的映射关系::
-
- VA = PA + 固定偏移
-
-分页映射的虚拟地址（VA）和物理地址（PA）有任意的映射关系，这种关系记录在TLB和页
-表中。LoongArch的TLB包括一个全相联的MTLB（Multiple Page Size TLB，多样页大小TLB）
-和一个组相联的STLB（Single Page Size TLB，单一页大小TLB）。
-
-缺省状态下，LA32的整个虚拟地址空间配置如下：
-
-============ =========================== ===========================
-区段名 地址范围 属性
-============ =========================== ===========================
-``UVRANGE`` ``0x00000000 - 0x7FFFFFFF`` 分页映射, 可缓存, PLV0~3
-``KPRANGE0`` ``0x80000000 - 0x9FFFFFFF`` 直接映射, 非缓存, PLV0
-``KPRANGE1`` ``0xA0000000 - 0xBFFFFFFF`` 直接映射, 可缓存, PLV0
-``KVRANGE`` ``0xC0000000 - 0xFFFFFFFF`` 分页映射, 可缓存, PLV0
-============ =========================== ===========================
-
-用户态（PLV3）只能访问UVRANGE，对于直接映射的KPRANGE0和KPRANGE1，将虚拟地址的第
-30~31位清零就等于物理地址。例如：物理地址0x00001000对应的非缓存直接映射虚拟地址
-是0x80001000，而其可缓存直接映射虚拟地址是0xA0001000。
-
-缺省状态下，LA64的整个虚拟地址空间配置如下：
-
-============ ====================== ==================================
-区段名 地址范围 属性
-============ ====================== ==================================
-``XUVRANGE`` ``0x0000000000000000 - 分页映射, 可缓存, PLV0~3
- 0x3FFFFFFFFFFFFFFF``
-``XSPRANGE`` ``0x4000000000000000 - 直接映射, 可缓存 / 非缓存, PLV0
- 0x7FFFFFFFFFFFFFFF``
-``XKPRANGE`` ``0x8000000000000000 - 直接映射, 可缓存 / 非缓存, PLV0
- 0xBFFFFFFFFFFFFFFF``
-``XKVRANGE`` ``0xC000000000000000 - 分页映射, 可缓存, PLV0
- 0xFFFFFFFFFFFFFFFF``
-============ ====================== ==================================
-
-用户态（PLV3）只能访问XUVRANGE，对于直接映射的XSPRANGE和XKPRANGE，将虚拟地址的第
-60~63位清零就等于物理地址，而其缓存属性是通过虚拟地址的第60~61位配置的（0表示强序
-非缓存，1表示一致可缓存，2表示弱序非缓存）。
-
-目前，我们仅用XKPRANGE来进行直接映射，XSPRANGE保留给以后用。
-
-此处给出一个直接映射的例子：物理地址0x00000000_00001000的强序非缓存直接映射虚拟地址
-（在XKPRANGE中）是0x80000000_00001000，其一致可缓存直接映射虚拟地址（在XKPRANGE中）
-是0x90000000_00001000，而其弱序非缓存直接映射虚拟地址（在XKPRANGE中）是0xA0000000_
-00001000。
-
-Loongson与LoongArch的关系
-=========================
-
-LoongArch是一种RISC指令集架构（ISA），不同于现存的任何一种ISA，而Loongson（即龙
-芯）是一个处理器家族。龙芯包括三个系列：Loongson-1（龙芯1号）是32位处理器系列，
-Loongson-2（龙芯2号）是低端64位处理器系列，而Loongson-3（龙芯3号）是高端64位处理
-器系列。旧的龙芯处理器基于MIPS架构，而新的龙芯处理器基于LoongArch架构。以龙芯3号
-为例：龙芯3A1000/3B1500/3A2000/3A3000/3A4000都是兼容MIPS的，而龙芯3A5000（以及将
-来的型号）都是基于LoongArch的。
-
-.. _loongarch-references-zh_CN:
-
-参考文献
-========
-
-Loongson官方网站（龙芯中科技术股份有限公司）：
-
- http://www.loongson.cn/
-
-Loongson与LoongArch的开发者网站（软件与文档资源）：
-
- http://www.loongnix.cn/
-
- https://github.com/loongson/
-
- https://loongson.github.io/LoongArch-Documentation/
-
-LoongArch指令集架构的文档：
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-CN.pdf （中文版）
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-EN.pdf （英文版）
-
-LoongArch的ELF psABI文档：
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-CN.pdf （中文版）
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-EN.pdf （英文版）
-
-Loongson与LoongArch的Linux内核源码仓库：
-
- https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
diff --git a/Documentation/translations/zh_CN/loongarch/irq-chip-model.rst b/Documentation/translations/zh_CN/loongarch/irq-chip-model.rst
deleted file mode 100644
index fb5d23b..0000000
--- a/Documentation/translations/zh_CN/loongarch/irq-chip-model.rst
+++ /dev/null
@@ -1,157 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/loongarch/irq-chip-model.rst
-:Translator: Huacai Chen <chenhuacai@loongson.cn>
-
-==================================
-LoongArch的IRQ芯片模型（层级关系）
-==================================
-
-目前，基于LoongArch的处理器（如龙芯3A5000）只能与LS7A芯片组配合工作。LoongArch计算机
-中的中断控制器（即IRQ芯片）包括CPUINTC（CPU Core Interrupt Controller）、LIOINTC（
-Legacy I/O Interrupt Controller）、EIOINTC（Extended I/O Interrupt Controller）、
-HTVECINTC（Hyper-Transport Vector Interrupt Controller）、PCH-PIC（LS7A芯片组的主中
-断控制器）、PCH-LPC（LS7A芯片组的LPC中断控制器）和PCH-MSI（MSI中断控制器）。
-
-CPUINTC是一种CPU内部的每个核本地的中断控制器，LIOINTC/EIOINTC/HTVECINTC是CPU内部的
-全局中断控制器（每个芯片一个，所有核共享），而PCH-PIC/PCH-LPC/PCH-MSI是CPU外部的中
-断控制器（在配套芯片组里面）。这些中断控制器（或者说IRQ芯片）以一种层次树的组织形式
-级联在一起，一共有两种层级关系模型（传统IRQ模型和扩展IRQ模型）。
-
-传统IRQ模型
-===========
-
-在这种模型里面，IPI（Inter-Processor Interrupt）和CPU本地时钟中断直接发送到CPUINTC，
-CPU串口（UARTs）中断发送到LIOINTC，而其他所有设备的中断则分别发送到所连接的PCH-PIC/
-PCH-LPC/PCH-MSI，然后被HTVECINTC统一收集，再发送到LIOINTC，最后到达CPUINTC::
-
- +-----+ +---------+ +-------+
- | IPI | --> | CPUINTC | <-- | Timer |
- +-----+ +---------+ +-------+
- ^
- |
- +---------+ +-------+
- | LIOINTC | <-- | UARTs |
- +---------+ +-------+
- ^
- |
- +-----------+
- | HTVECINTC |
- +-----------+
- ^ ^
- | |
- +---------+ +---------+
- | PCH-PIC | | PCH-MSI |
- +---------+ +---------+
- ^ ^ ^
- | | |
- +---------+ +---------+ +---------+
- | PCH-LPC | | Devices | | Devices |
- +---------+ +---------+ +---------+
- ^
- |
- +---------+
- | Devices |
- +---------+
-
-扩展IRQ模型
-===========
-
-在这种模型里面，IPI（Inter-Processor Interrupt）和CPU本地时钟中断直接发送到CPUINTC，
-CPU串口（UARTs）中断发送到LIOINTC，而其他所有设备的中断则分别发送到所连接的PCH-PIC/
-PCH-LPC/PCH-MSI，然后被EIOINTC统一收集，再直接到达CPUINTC::
-
- +-----+ +---------+ +-------+
- | IPI | --> | CPUINTC | <-- | Timer |
- +-----+ +---------+ +-------+
- ^ ^
- | |
- +---------+ +---------+ +-------+
- | EIOINTC | | LIOINTC | <-- | UARTs |
- +---------+ +---------+ +-------+
- ^ ^
- | |
- +---------+ +---------+
- | PCH-PIC | | PCH-MSI |
- +---------+ +---------+
- ^ ^ ^
- | | |
- +---------+ +---------+ +---------+
- | PCH-LPC | | Devices | | Devices |
- +---------+ +---------+ +---------+
- ^
- |
- +---------+
- | Devices |
- +---------+
-
-ACPI相关的定义
-==============
-
-CPUINTC::
-
- ACPI_MADT_TYPE_CORE_PIC;
- struct acpi_madt_core_pic;
- enum acpi_madt_core_pic_version;
-
-LIOINTC::
-
- ACPI_MADT_TYPE_LIO_PIC;
- struct acpi_madt_lio_pic;
- enum acpi_madt_lio_pic_version;
-
-EIOINTC::
-
- ACPI_MADT_TYPE_EIO_PIC;
- struct acpi_madt_eio_pic;
- enum acpi_madt_eio_pic_version;
-
-HTVECINTC::
-
- ACPI_MADT_TYPE_HT_PIC;
- struct acpi_madt_ht_pic;
- enum acpi_madt_ht_pic_version;
-
-PCH-PIC::
-
- ACPI_MADT_TYPE_BIO_PIC;
- struct acpi_madt_bio_pic;
- enum acpi_madt_bio_pic_version;
-
-PCH-MSI::
-
- ACPI_MADT_TYPE_MSI_PIC;
- struct acpi_madt_msi_pic;
- enum acpi_madt_msi_pic_version;
-
-PCH-LPC::
-
- ACPI_MADT_TYPE_LPC_PIC;
- struct acpi_madt_lpc_pic;
- enum acpi_madt_lpc_pic_version;
-
-参考文献
-========
-
-龙芯3A5000的文档：
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-CN.pdf (中文版)
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-EN.pdf (英文版)
-
-龙芯LS7A芯片组的文档：
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-CN.pdf (中文版)
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-EN.pdf (英文版)
-
-.. note::
- - CPUINTC：即《龙芯架构参考手册卷一》第7.4节所描述的CSR.ECFG/CSR.ESTAT寄存器及其
- 中断控制逻辑；
- - LIOINTC：即《龙芯3A5000处理器使用手册》第11.1节所描述的“传统I/O中断”；
- - EIOINTC：即《龙芯3A5000处理器使用手册》第11.2节所描述的“扩展I/O中断”；
- - HTVECINTC：即《龙芯3A5000处理器使用手册》第14.3节所描述的“HyperTransport中断”；
- - PCH-PIC/PCH-MSI：即《龙芯7A1000桥片用户手册》第5章所描述的“中断控制器”；
- - PCH-LPC：即《龙芯7A1000桥片用户手册》第24.3节所描述的“LPC中断”。
diff --git a/Documentation/translations/zh_CN/mips/booting.rst b/Documentation/translations/zh_CN/mips/booting.rst
deleted file mode 100644
index e0bbd3f..0000000
--- a/Documentation/translations/zh_CN/mips/booting.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/mips/booting.rst
-
-:翻译:
-
- 司延腾 Yanteng Si <siyanteng@loongson.cn>
-
-.. _cn_booting:
-
-BMIPS设备树引导
-------------------------
-
- 一些bootloaders只支持在内核镜像开始地址处的单一入口点。而其它
- bootloaders将跳转到ELF的开始地址处。两种方案都支持的；因为
- CONFIG_BOOT_RAW=y and CONFIG_NO_EXCEPT_FILL=y, 所以第一条指令
- 会立即跳转到kernel_entry()入口处执行。
-
- 与arch/arm情况(b)类似，dt感知的引导加载程序需要设置以下寄存器:
-
- a0 : 0
-
- a1 : 0xffffffff
-
- a2 : RAM中指向设备树块的物理指针(在chapterII中定义)。
- 设备树可以位于前512MB物理地址空间(0x00000000 -
- 0x1fffffff)的任何位置，以64位边界对齐。
-
- 传统bootloaders不会使用这样的约定，并且它们不传入DT块。
- 在这种情况下，Linux将通过选中CONFIG_DT_*查找DTB。
-
- 以上约定只在32位系统中定义，因为目前没有任何64位的BMIPS实现。
diff --git a/Documentation/translations/zh_CN/mips/features.rst b/Documentation/translations/zh_CN/mips/features.rst
deleted file mode 100644
index b61dab0..0000000
--- a/Documentation/translations/zh_CN/mips/features.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/mips/features.rst
-
-:翻译:
-
- 司延腾 Yanteng Si <siyanteng@loongson.cn>
-
-.. _cn_features:
-
-.. kernel-feat:: $srctree/Documentation/features mips
diff --git a/Documentation/translations/zh_CN/mips/index.rst b/Documentation/translations/zh_CN/mips/index.rst
deleted file mode 100644
index 192c6ad..0000000
--- a/Documentation/translations/zh_CN/mips/index.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/mips/index.rst
-
-:翻译:
-
- 司延腾 Yanteng Si <siyanteng@loongson.cn>
-
-===========================
-MIPS特性文档
-===========================
-
-.. toctree::
- :maxdepth: 2
- :numbered:
-
- booting
- ingenic-tcu
-
- features
-
-.. only:: subproject and html
-
- Indices
- =======
-
- * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst b/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
deleted file mode 100644
index ddbe149..0000000
--- a/Documentation/translations/zh_CN/mips/ingenic-tcu.rst
+++ /dev/null
@@ -1,72 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: ../disclaimer-zh_CN.rst
-
-:Original: Documentation/mips/ingenic-tcu.rst
-
-:翻译:
-
- 司延腾 Yanteng Si <siyanteng@loongson.cn>
-
-.. _cn_ingenic-tcu:
-
-===============================================
-君正 JZ47xx SoC定时器/计数器硬件单元
-===============================================
-
-君正 JZ47xx SoC中的定时器/计数器单元(TCU)是一个多功能硬件块。它有多达
-8个通道，可以用作计数器，计时器，或脉冲宽度调制器。
-
-- JZ4725B, JZ4750, JZ4755 只有６个TCU通道。其它SoC都有８个通道。
-
-- JZ4725B引入了一个独立的通道，称为操作系统计时器(OST)。这是一个32位可
- 编程定时器。在JZ4760B及以上型号上，它是64位的。
-
-- 每个TCU通道都有自己的时钟源，可以通过 TCSR 寄存器设置通道的父级时钟
- 源（pclk、ext、rtc）、开关以及分频。
-
- - 看门狗和OST硬件模块在它们的寄存器空间中也有相同形式的TCSR寄存器。
- - 用于关闭/开启的 TCU 寄存器也可以关闭/开启看门狗和 OST 时钟。
-
-- 每个TCU通道在两种模式的其中一种模式下运行：
-
- - 模式 TCU1：通道无法在睡眠模式下运行，但更易于操作。
- - 模式 TCU2：通道可以在睡眠模式下运行，但操作比 TCU1 通道复杂一些。
-
-- 每个 TCU 通道的模式取决于使用的SoC：
-
- - 在最老的SoC（高于JZ4740），八个通道都运行在TCU1模式。
- - 在 JZ4725B，通道5运行在TCU2,其它通道则运行在TCU1。
- - 在最新的SoC（JZ4750及之后），通道1-2运行在TCU2，其它通道则运行
- 在TCU1。
-
-- 每个通道都可以生成中断。有些通道共享一条中断线，而有些没有，其在SoC型
- 号之间的变更：
-
- - 在很老的SoC（JZ4740及更低），通道0和通道1有它们自己的中断线；通
- 道2-7共享最后一条中断线。
- - 在 JZ4725B，通道0有它自己的中断线；通道1-5共享一条中断线；OST
- 使用最后一条中断线。
- - 在比较新的SoC（JZ4750及以后），通道5有它自己的中断线；通
- 道0-4和（如果是8通道）6-7全部共享一条中断线；OST使用最后一条中
- 断线。
-
-实现
-====
-
-TCU硬件的功能分布在多个驱动程序：
-
-============== ===================================
-时钟 drivers/clk/ingenic/tcu.c
-中断 drivers/irqchip/irq-ingenic-tcu.c
-定时器 drivers/clocksource/ingenic-timer.c
-OST drivers/clocksource/ingenic-ost.c
-脉冲宽度调制器 drivers/pwm/pwm-jz4740.c
-看门狗 drivers/watchdog/jz4740_wdt.c
-============== ===================================
-
-因为可以从相同的寄存器控制属于不同驱动程序和框架的TCU的各种功能，所以
-所有这些驱动程序都通过相同的控制总线通用接口访问它们的寄存器。
-
-有关TCU驱动程序的设备树绑定的更多信息，请参阅:
-Documentation/devicetree/bindings/timer/ingenic,tcu.yaml.
diff --git a/Documentation/translations/zh_CN/mm/frontswap.rst b/Documentation/translations/zh_CN/mm/frontswap.rst
deleted file mode 100644
index 4349753..0000000
--- a/Documentation/translations/zh_CN/mm/frontswap.rst
+++ /dev/null
@@ -1,196 +0,0 @@
-:Original: Documentation/mm/frontswap.rst
-
-:翻译:
-
- 司延腾 Yanteng Si <siyanteng@loongson.cn>
-
-:校译:
-
-=========
-Frontswap
-=========
-
-Frontswap为交换页提供了一个 “transcendent memory” 的接口。在一些环境中，由
-于交换页被保存在RAM（或类似RAM的设备）中，而不是交换磁盘，因此可以获得巨大的性能
-节省（提高）。
-
-.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
-
-Frontswap之所以这么命名，是因为它可以被认为是与swap设备的“back”存储相反。存
-储器被认为是一个同步并发安全的面向页面的“伪RAM设备”，符合transcendent memory
-（如Xen的“tmem”，或内核内压缩内存，又称“zcache”，或未来的类似RAM的设备）的要
-求；这个伪RAM设备不能被内核直接访问或寻址，其大小未知且可能随时间变化。驱动程序通过
-调用frontswap_register_ops将自己与frontswap链接起来，以适当地设置frontswap_ops
-的功能，它提供的功能必须符合某些策略，如下所示:
-
-一个 “init” 将设备准备好接收与指定的交换设备编号（又称“类型”）相关的frontswap
-交换页。一个 “store” 将把该页复制到transcendent memory，并与该页的类型和偏移
-量相关联。一个 “load” 将把该页，如果找到的话，从transcendent memory复制到内核
-内存，但不会从transcendent memory中删除该页。一个 “invalidate_page” 将从
-transcendent memory中删除该页，一个 “invalidate_area” 将删除所有与交换类型
-相关的页（例如，像swapoff）并通知 “device” 拒绝进一步存储该交换类型。
-
-一旦一个页面被成功存储，在该页面上的匹配加载通常会成功。因此，当内核发现自己处于需
-要交换页面的情况时，它首先尝试使用frontswap。如果存储的结果是成功的，那么数据就已
-经成功的保存到了transcendent memory中，并且避免了磁盘写入，如果后来再读回数据，
-也避免了磁盘读取。如果存储返回失败，transcendent memory已经拒绝了该数据，且该页
-可以像往常一样被写入交换空间。
-
-请注意，如果一个页面被存储，而该页面已经存在于transcendent memory中（一个 “重复”
-的存储），要么存储成功，数据被覆盖，要么存储失败，该页面被废止。这确保了旧的数据永远
-不会从frontswap中获得。
-
-如果配置正确，对frontswap的监控是通过 `/sys/kernel/debug/frontswap` 目录下的
-debugfs完成的。frontswap的有效性可以通过以下方式测量（在所有交换设备中）:
-
-``failed_stores``
- 有多少次存储的尝试是失败的
-
-``loads``
- 尝试了多少次加载（应该全部成功）
-
-``succ_stores``
- 有多少次存储的尝试是成功的
-
-``invalidates``
- 尝试了多少次作废
-
-后台实现可以提供额外的指标。
-
-经常问到的问题
-==============
-
-* 价值在哪里?
-
-当一个工作负载开始交换时，性能就会下降。Frontswap通过提供一个干净的、动态的接口来
-读取和写入交换页到 “transcendent memory”，从而大大增加了许多这样的工作负载的性
-能，否则内核是无法直接寻址的。当数据被转换为不同的形式和大小（比如压缩）或者被秘密
-移动（对于一些类似RAM的设备来说，这可能对写平衡很有用）时，这个接口是理想的。交换
-页（和被驱逐的页面缓存页）是这种比RAM慢但比磁盘快得多的“伪RAM设备”的一大用途。
-
-Frontswap对内核的影响相当小，为各种系统配置中更动态、更灵活的RAM利用提供了巨大的
-灵活性：
-
-在单一内核的情况下，又称“zcache”，页面被压缩并存储在本地内存中，从而增加了可以安
-全保存在RAM中的匿名页面总数。Zcache本质上是用压缩/解压缩的CPU周期换取更好的内存利
-用率。Benchmarks测试显示，当内存压力较低时，几乎没有影响，而在高内存压力下的一些
-工作负载上，则有明显的性能改善（25%以上）。
-
-“RAMster” 在zcache的基础上增加了对集群系统的 “peer-to-peer” transcendent memory
-的支持。Frontswap页面像zcache一样被本地压缩，但随后被“remotified” 到另一个系
-统的RAM。这使得RAM可以根据需要动态地来回负载平衡，也就是说，当系统A超载时，它可以
-交换到系统B，反之亦然。RAMster也可以被配置成一个内存服务器，因此集群中的许多服务器
-可以根据需要动态地交换到配置有大量内存的单一服务器上......而不需要预先配置每个客户
-有多少内存可用
-
-在虚拟情况下，虚拟化的全部意义在于统计地将物理资源在多个虚拟机的不同需求之间进行复
-用。对于RAM来说，这真的很难做到，而且在不改变内核的情况下，要做好这一点的努力基本上
-是失败的（除了一些广为人知的特殊情况下的工作负载）。具体来说，Xen Transcendent Memory
-后端允许管理器拥有的RAM “fallow”，不仅可以在多个虚拟机之间进行“time-shared”，
-而且页面可以被压缩和重复利用，以优化RAM的利用率。当客户操作系统被诱导交出未充分利用
-的RAM时（如 “selfballooning”），突然出现的意外内存压力可能会导致交换；frontswap
-允许这些页面被交换到管理器RAM中或从管理器RAM中交换（如果整体主机系统内存条件允许），
-从而减轻计划外交换可能带来的可怕的性能影响。
-
-一个KVM的实现正在进行中，并且已经被RFC'ed到lkml。而且，利用frontswap，对NVM作为
-内存扩展技术的调查也在进行中。
-
-* 当然，在某些情况下可能有性能上的优势，但frontswap的空间/时间开销是多少？
-
-如果 CONFIG_FRONTSWAP 被禁用，每个 frontswap 钩子都会编译成空，唯一的开销是每
-个 swapon'ed swap 设备的几个额外字节。如果 CONFIG_FRONTSWAP 被启用，但没有
-frontswap的 “backend” 寄存器，每读或写一个交换页就会有一个额外的全局变量，而不
-是零。如果 CONFIG_FRONTSWAP 被启用，并且有一个frontswap的backend寄存器，并且
-后端每次 “store” 请求都失败（即尽管声称可能，但没有提供内存），CPU 的开销仍然可以
-忽略不计 - 因为每次frontswap失败都是在交换页写到磁盘之前，系统很可能是 I/O 绑定
-的，无论如何使用一小部分的 CPU 都是不相关的。
-
-至于空间，如果CONFIG_FRONTSWAP被启用，并且有一个frontswap的backend注册，那么
-每个交换设备的每个交换页都会被分配一个比特。这是在内核已经为每个交换设备的每个交换
-页分配的8位（在2.6.34之前是16位）上增加的。(Hugh Dickins观察到，frontswap可能
-会偷取现有的8个比特，但是我们以后再来担心这个小的优化问题)。对于标准的4K页面大小的
-非常大的交换盘（这很罕见），这是每32GB交换盘1MB开销。
-
-当交换页存储在transcendent memory中而不是写到磁盘上时，有一个副作用，即这可能会
-产生更多的内存压力，有可能超过其他的优点。一个backend，比如zcache，必须实现策略
-来仔细（但动态地）管理内存限制，以确保这种情况不会发生。
-
-* 好吧，那就用内核骇客能理解的术语来快速概述一下这个frontswap补丁的作用如何？
-
-我们假设在内核初始化过程中，一个frontswap 的 “backend” 已经注册了；这个注册表
-明这个frontswap 的 “backend” 可以访问一些不被内核直接访问的“内存”。它到底提
-供了多少内存是完全动态和随机的。
-
-每当一个交换设备被交换时，就会调用frontswap_init()，把交换设备的编号（又称“类
-型”）作为一个参数传给它。这就通知了frontswap，以期待 “store” 与该号码相关的交
-换页的尝试。
-
-每当交换子系统准备将一个页面写入交换设备时（参见swap_writepage()），就会调用
-frontswap_store。Frontswap与frontswap backend协商，如果backend说它没有空
-间，frontswap_store返回-1，内核就会照常把页换到交换设备上。注意，来自frontswap
-backend的响应对内核来说是不可预测的；它可能选择从不接受一个页面，可能接受每九个
-页面，也可能接受每一个页面。但是如果backend确实接受了一个页面，那么这个页面的数
-据已经被复制并与类型和偏移量相关联了，而且backend保证了数据的持久性。在这种情况
-下，frontswap在交换设备的“frontswap_map” 中设置了一个位，对应于交换设备上的
-页面偏移量，否则它就会将数据写入该设备。
-
-当交换子系统需要交换一个页面时（swap_readpage()），它首先调用frontswap_load()，
-检查frontswap_map，看这个页面是否早先被frontswap backend接受。如果是，该页
-的数据就会从frontswap后端填充，换入就完成了。如果不是，正常的交换代码将被执行，
-以便从真正的交换设备上获得这一页的数据。
-
-所以每次frontswap backend接受一个页面时，交换设备的读取和（可能）交换设备的写
-入都被 “frontswap backend store” 和（可能）“frontswap backend loads”
-所取代，这可能会快得多。
-
-* frontswap不能被配置为一个 “特殊的” 交换设备，它的优先级要高于任何真正的交换
- 设备（例如像zswap，或者可能是swap-over-nbd/NFS）？
-
-首先，现有的交换子系统不允许有任何种类的交换层次结构。也许它可以被重写以适应层次
-结构，但这将需要相当大的改变。即使它被重写，现有的交换子系统也使用了块I/O层，它
-假定交换设备是固定大小的，其中的任何页面都是可线性寻址的。Frontswap几乎没有触
-及现有的交换子系统，而是围绕着块I/O子系统的限制，提供了大量的灵活性和动态性。
-
-例如，frontswap backend对任何交换页的接受是完全不可预测的。这对frontswap backend
-的定义至关重要，因为它赋予了backend完全动态的决定权。在zcache中，人们无法预
-先知道一个页面的可压缩性如何。可压缩性 “差” 的页面会被拒绝，而 “差” 本身也可
-以根据当前的内存限制动态地定义。
-
-此外，frontswap是完全同步的，而真正的交换设备，根据定义，是异步的，并且使用
-块I/O。块I/O层不仅是不必要的，而且可能进行 “优化”，这对面向RAM的设备来说是
-不合适的，包括将一些页面的写入延迟相当长的时间。同步是必须的，以确保后端的动
-态性，并避免棘手的竞争条件，这将不必要地大大增加frontswap和/或块I/O子系统的
-复杂性。也就是说，只有最初的 “store” 和 “load” 操作是需要同步的。一个独立
-的异步线程可以自由地操作由frontswap存储的页面。例如，RAMster中的 “remotification”
-线程使用标准的异步内核套接字，将压缩的frontswap页面移动到远程机器。同样，
-KVM的客户方实现可以进行客户内压缩，并使用 “batched” hypercalls。
-
-在虚拟化环境中，动态性允许管理程序（或主机操作系统）做“intelligent overcommit”。
-例如，它可以选择只接受页面，直到主机交换可能即将发生，然后强迫客户机做他们
-自己的交换。
-
-transcendent memory规格的frontswap有一个坏处。因为任何 “store” 都可
-能失败，所以必须在一个真正的交换设备上有一个真正的插槽来交换页面。因此，
-frontswap必须作为每个交换设备的 “影子” 来实现，它有可能容纳交换设备可能
-容纳的每一个页面，也有可能根本不容纳任何页面。这意味着frontswap不能包含比
-swap设备总数更多的页面。例如，如果在某些安装上没有配置交换设备，frontswap
-就没有用。无交换设备的便携式设备仍然可以使用frontswap，但是这种设备的
-backend必须配置某种 “ghost” 交换设备，并确保它永远不会被使用。
-
-
-* 为什么会有这种关于 “重复存储” 的奇怪定义？如果一个页面以前被成功地存储过，
- 难道它不能总是被成功地覆盖吗？
-
-几乎总是可以的，不，有时不能。考虑一个例子，数据被压缩了，原来的4K页面被压
-缩到了1K。现在，有人试图用不可压缩的数据覆盖该页，因此会占用整个4K。但是
-backend没有更多的空间了。在这种情况下，这个存储必须被拒绝。每当frontswap
-拒绝一个会覆盖的存储时，它也必须使旧的数据作废，并确保它不再被访问。因为交
-换子系统会把新的数据写到读交换设备上，这是确保一致性的正确做法。
-
-* 为什么frontswap补丁会创建新的头文件swapfile.h？
-
-frontswap代码依赖于一些swap子系统内部的数据结构，这些数据结构多年来一直
-在静态和全局之间来回移动。这似乎是一个合理的妥协：将它们定义为全局，但在一
-个新的包含文件中声明它们，该文件不被包含swap.h的大量源文件所包含。
-
-Dan Magenheimer，最后更新于2012年4月9日
diff --git a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst
index b7a05442..20947f8 100644
--- a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst
+++ b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst
@@ -219,7 +219,7 @@
释放巨页
========
-巨页释放是由函数free_huge_page()执行的。这个函数是hugetlbfs复合页的析构器。因此，它只传
+巨页释放是由函数free_huge_folio()执行的。这个函数是hugetlbfs复合页的析构器。因此，它只传
递一个指向页面结构体的指针。当一个巨页被释放时，可能需要进行预留计算。如果该页与包含保
留的子池相关联，或者该页在错误路径上被释放，必须恢复全局预留计数，就会出现这种情况。
@@ -296,7 +296,7 @@
调用代码执行全局检查和分配，以确定是否有足够的巨页使操作成功。
2)
- a) 如果操作能够成功，regi_add()将被调用，以实际修改先前传递给regi_chg()的相同范围
+ a) 如果操作能够成功，region_add()将被调用，以实际修改先前传递给region_chg()的相同范围
[f, t]的预留映射。
b) 如果操作不能成功，region_abort被调用，在相同的范围[f, t]内中止操作。
@@ -307,7 +307,7 @@
如上所述，region_chg()确定该范围内当前没有在映射中表示的页面的数量。region_add()返回添加
到映射中的范围内的页数。在大多数情况下， region_add() 的返回值与 region_chg() 的返回值相
同。然而，在共享映射的情况下，有可能在调用 region_chg() 和 region_add() 之间对预留映射进
-行更改。在这种情况下，regi_add()的返回值将与regi_chg()的返回值不符。在这种情况下，全局计数
+行更改。在这种情况下，region_add()的返回值将与region_chg()的返回值不符。在这种情况下，全局计数
和子池计数很可能是不正确的，需要调整。检查这种情况并进行适当的调整是调用者的责任。
函数region_del()被调用以从预留映射中移除区域。
@@ -387,7 +387,7 @@
然而，有几种情况是，在一个巨页被分配后，但在它被实例化之前，就遇到了错误。在这种情况下，
页面分配已经消耗了预留，并进行了适当的子池、预留映射和全局计数调整。如果页面在这个时候被释放
-（在实例化和清除PagePrivate之前），那么free_huge_page将增加全局预留计数。然而，预留映射
+（在实例化和清除PagePrivate之前），那么free_huge_folio将增加全局预留计数。然而，预留映射
显示报留被消耗了。这种不一致的状态将导致预留的巨页的 “泄漏” 。全局预留计数将比它原本的要高，
并阻止分配一个预先分配的页面。
diff --git a/Documentation/translations/zh_CN/mm/index.rst b/Documentation/translations/zh_CN/mm/index.rst
index 2f53e37..b950dd1 100644
--- a/Documentation/translations/zh_CN/mm/index.rst
+++ b/Documentation/translations/zh_CN/mm/index.rst
@@ -42,7 +42,6 @@
damon/index
free_page_reporting
ksm
- frontswap
hmm
hwpoison
hugetlbfs_reserv
diff --git a/Documentation/translations/zh_CN/mm/split_page_table_lock.rst b/Documentation/translations/zh_CN/mm/split_page_table_lock.rst
index 4fb7aa6..a2c2886 100644
--- a/Documentation/translations/zh_CN/mm/split_page_table_lock.rst
+++ b/Documentation/translations/zh_CN/mm/split_page_table_lock.rst
@@ -56,16 +56,16 @@
架构对分页表锁的支持
====================
-没有必要特别启用PTE分页表锁：所有需要的东西都由pgtable_pte_page_ctor()
-和pgtable_pte_page_dtor()完成，它们必须在PTE表分配/释放时被调用。
+没有必要特别启用PTE分页表锁：所有需要的东西都由pagetable_pte_ctor()
+和pagetable_pte_dtor()完成，它们必须在PTE表分配/释放时被调用。
确保架构不使用slab分配器来分配页表：slab使用page->slab_cache来分配其页
面。这个区域与page->ptl共享存储。
PMD分页锁只有在你有两个以上的页表级别时才有意义。
-启用PMD分页锁需要在PMD表分配时调用pgtable_pmd_page_ctor()，在释放时调
-用pgtable_pmd_page_dtor()。
+启用PMD分页锁需要在PMD表分配时调用pagetable_pmd_ctor()，在释放时调
+用pagetable_pmd_dtor()。
分配通常发生在pmd_alloc_one()中，释放发生在pmd_free()和pmd_free_tlb()
中，但要确保覆盖所有的PMD表分配/释放路径：即X86_PAE在pgd_alloc()中预先
@@ -73,7 +73,7 @@
一切就绪后，你可以设置CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK。
-注意：pgtable_pte_page_ctor()和pgtable_pmd_page_ctor()可能失败--必
+注意：pagetable_pte_ctor()和pagetable_pmd_ctor()可能失败--必
须正确处理。
page->ptl
@@ -90,7 +90,7 @@
的指针并动态分配它。这允许在启用DEBUG_SPINLOCK或DEBUG_LOCK_ALLOC的
情况下使用分页锁，但由于间接访问而多花了一个缓存行。
-PTE表的spinlock_t分配在pgtable_pte_page_ctor()中，PMD表的spinlock_t
-分配在pgtable_pmd_page_ctor()中。
+PTE表的spinlock_t分配在pagetable_pte_ctor()中，PMD表的spinlock_t
+分配在pagetable_pmd_ctor()中。
请不要直接访问page->ptl - -使用适当的辅助函数。
diff --git a/Documentation/translations/zh_TW/IRQ.txt b/Documentation/translations/zh_TW/IRQ.txt
index 73d435a..fd78ca7 100644
--- a/Documentation/translations/zh_TW/IRQ.txt
+++ b/Documentation/translations/zh_TW/IRQ.txt
@@ -7,7 +7,7 @@
or if there is a problem with the translation.
Maintainer: Eric W. Biederman <ebiederman@xmission.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/core-api/irq/index.rst 的繁體中文翻譯
@@ -16,9 +16,9 @@
者翻譯存在問題，請聯繫繁體中文版維護者。
英文版維護者： Eric W. Biederman <ebiederman@xmission.com>
-繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst
index 6ce97ed..7fc56e1 100644
--- a/Documentation/translations/zh_TW/admin-guide/README.rst
+++ b/Documentation/translations/zh_TW/admin-guide/README.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
Linux內核5.x版本 <http://kernel.org/>
=========================================
diff --git a/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst b/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst
index 41a39ae..b448dbf 100644
--- a/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst
+++ b/Documentation/translations/zh_TW/admin-guide/bug-bisect.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
二分（bisect）缺陷
+++++++++++++++++++
diff --git a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst
index 4d813ae..9a3de3b 100644
--- a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst
+++ b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
追蹤缺陷
=========
diff --git a/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst b/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst
index bdc1a22..bd0c08a 100644
--- a/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst
+++ b/Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst
@@ -2,7 +2,7 @@
.. include:: ../disclaimer-zh_TW.rst
-:Translator: 胡皓文 Hu Haowen <src.res@email.cn>
+:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
清除 WARN_ONCE
--------------
diff --git a/Documentation/translations/zh_TW/admin-guide/cpu-load.rst b/Documentation/translations/zh_TW/admin-guide/cpu-load.rst
index be087ce..9e04aea 100644
--- a/Documentation/translations/zh_TW/admin-guide/cpu-load.rst
+++ b/Documentation/translations/zh_TW/admin-guide/cpu-load.rst
@@ -2,7 +2,7 @@
.. include:: ../disclaimer-zh_TW.rst
-:Translator: 胡皓文 Hu Haowen <src.res@email.cn>
+:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
========
CPU 負載
diff --git a/Documentation/translations/zh_TW/admin-guide/index.rst b/Documentation/translations/zh_TW/admin-guide/index.rst
index 293c202..2804d61 100644
--- a/Documentation/translations/zh_TW/admin-guide/index.rst
+++ b/Documentation/translations/zh_TW/admin-guide/index.rst
@@ -3,7 +3,7 @@
.. include:: ../disclaimer-zh_TW.rst
:Original: :doc:`../../../admin-guide/index`
-:Translator: 胡皓文 Hu Haowen <src.res@email.cn>
+:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
Linux 內核用戶和管理員指南
==========================
diff --git a/Documentation/translations/zh_TW/admin-guide/init.rst b/Documentation/translations/zh_TW/admin-guide/init.rst
index 32cdf13..db3fdf6 100644
--- a/Documentation/translations/zh_TW/admin-guide/init.rst
+++ b/Documentation/translations/zh_TW/admin-guide/init.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
解釋「No working init found.」啓動掛起消息
==========================================
diff --git a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst
index 27638e1..ea51342 100644
--- a/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst
+++ b/Documentation/translations/zh_TW/admin-guide/reporting-issues.rst
@@ -16,7 +16,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
報告問題
diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
index 15f8e90..65c8dd2 100644
--- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
+++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
安全缺陷
=========
diff --git a/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst b/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst
index d7b3c42..ebe3812 100644
--- a/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst
+++ b/Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
受汙染的內核
-------------
diff --git a/Documentation/translations/zh_TW/admin-guide/unicode.rst b/Documentation/translations/zh_TW/admin-guide/unicode.rst
index 720875b..7908b36 100644
--- a/Documentation/translations/zh_TW/admin-guide/unicode.rst
+++ b/Documentation/translations/zh_TW/admin-guide/unicode.rst
@@ -7,7 +7,7 @@
:譯者:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
Unicode（統一碼）支持
======================
diff --git a/Documentation/translations/zh_TW/arch/arm64/amu.rst b/Documentation/translations/zh_TW/arch/arm64/amu.rst
index f947a6c..21ac0db6 100644
--- a/Documentation/translations/zh_TW/arch/arm64/amu.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/amu.rst
@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
==================================
AArch64 Linux 中擴展的活動監控單元
diff --git a/Documentation/translations/zh_TW/arch/arm64/booting.txt b/Documentation/translations/zh_TW/arch/arm64/booting.txt
index 24817b8..3cc8f59 100644
--- a/Documentation/translations/zh_TW/arch/arm64/booting.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/booting.txt
@@ -10,7 +10,7 @@
M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com>
-zh_TW: Hu Haowen <src.res@email.cn>
+zh_TW: Hu Haowen <src.res.211@gmail.com>
C: 55f058e7574c3615dea4615573a19bdb258696c6
---------------------------------------------------------------------
Documentation/arch/arm64/booting.rst 的中文翻譯
@@ -23,7 +23,7 @@
中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
本文翻譯提交時的 Git 檢出點爲： 55f058e7574c3615dea4615573a19bdb258696c6
以下爲正文
diff --git a/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
index fca3c6f..ca7ff74 100644
--- a/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst
@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
================
ARM64 ELF hwcaps
diff --git a/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst
index 10feb32..a17858c 100644
--- a/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst
@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
=====================
ARM64中的 HugeTLBpage
diff --git a/Documentation/translations/zh_TW/arch/arm64/index.rst b/Documentation/translations/zh_TW/arch/arm64/index.rst
index 68befee..a62b5f0 100644
--- a/Documentation/translations/zh_TW/arch/arm64/index.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/index.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>`
:Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_arm64_index:
diff --git a/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
index 3c915df..c2d02cd 100644
--- a/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt
@@ -11,7 +11,7 @@
Maintainer: Punit Agrawal <punit.agrawal@arm.com>
Suzuki K. Poulose <suzuki.poulose@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯
@@ -26,7 +26,7 @@
中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
---------------------------------------------------------------------
diff --git a/Documentation/translations/zh_TW/arch/arm64/memory.txt b/Documentation/translations/zh_TW/arch/arm64/memory.txt
index 2437380a..0280200 100644
--- a/Documentation/translations/zh_TW/arch/arm64/memory.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/memory.txt
@@ -10,7 +10,7 @@
Maintainer: Catalin Marinas <catalin.marinas@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/arch/arm64/memory.rst 的中文翻譯
@@ -24,7 +24,7 @@
中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
---------------------------------------------------------------------
diff --git a/Documentation/translations/zh_TW/arch/arm64/perf.rst b/Documentation/translations/zh_TW/arch/arm64/perf.rst
index 3b39997..645f394 100644
--- a/Documentation/translations/zh_TW/arch/arm64/perf.rst
+++ b/Documentation/translations/zh_TW/arch/arm64/perf.rst
@@ -5,7 +5,7 @@
:Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
=============
Perf 事件屬性
diff --git a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
index 66c3a35..f6f4183 100644
--- a/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt
@@ -10,7 +10,7 @@
M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com>
-zh_TW: Hu Haowen <src.res@email.cn>
+zh_TW: Hu Haowen <src.res.211@gmail.com>
C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
---------------------------------------------------------------------
Documentation/arch/arm64/silicon-errata.rst 的中文翻譯
@@ -23,7 +23,7 @@
中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
本文翻譯提交時的 Git 檢出點爲： 1926e54f115725a9248d0c4c65c22acaf94de4c4
以下爲正文
diff --git a/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
index b7f683f..c0be1d1 100644
--- a/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
+++ b/Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt
@@ -10,7 +10,7 @@
Maintainer: Will Deacon <will.deacon@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯
@@ -22,7 +22,7 @@
中文版維護者： 傅煒 Fu Wei <wefu@redhat.com>
中文版翻譯者： 傅煒 Fu Wei <wefu@redhat.com>
中文版校譯者： 傅煒 Fu Wei <wefu@redhat.com>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
---------------------------------------------------------------------
diff --git a/Documentation/translations/zh_TW/cpu-freq/core.rst b/Documentation/translations/zh_TW/cpu-freq/core.rst
index 3d890c2..f1951e1 100644
--- a/Documentation/translations/zh_TW/cpu-freq/core.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/core.rst
@@ -4,7 +4,7 @@
:Original: :doc:`../../../cpu-freq/core`
:Translator: Yanteng Si <siyanteng@loongson.cn>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_core.rst:
diff --git a/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst
index 2bb8197..671b1bf0 100644
--- a/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst
@@ -4,7 +4,7 @@
:Original: :doc:`../../../cpu-freq/cpu-drivers`
:Translator: Yanteng Si <siyanteng@loongson.cn>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_cpu-drivers.rst:
diff --git a/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst b/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst
index d80bfed..49088be 100644
--- a/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst
@@ -4,7 +4,7 @@
:Original: :doc:`../../../cpu-freq/cpufreq-stats`
:Translator: Yanteng Si <siyanteng@loongson.cn>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_cpufreq-stats.rst:
diff --git a/Documentation/translations/zh_TW/cpu-freq/index.rst b/Documentation/translations/zh_TW/cpu-freq/index.rst
index 1a8e680..c6cf825 100644
--- a/Documentation/translations/zh_TW/cpu-freq/index.rst
+++ b/Documentation/translations/zh_TW/cpu-freq/index.rst
@@ -4,7 +4,7 @@
:Original: :doc:`../../../cpu-freq/index`
:Translator: Yanteng Si <siyanteng@loongson.cn>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_index.rst:
diff --git a/Documentation/translations/zh_TW/disclaimer-zh_TW.rst b/Documentation/translations/zh_TW/disclaimer-zh_TW.rst
index f4cf87d..0d0ffb1 100644
--- a/Documentation/translations/zh_TW/disclaimer-zh_TW.rst
+++ b/Documentation/translations/zh_TW/disclaimer-zh_TW.rst
@@ -7,5 +7,5 @@
.. note::
如果您發現本文檔與原始文件有任何不同或者有翻譯問題，請聯繫該文件的譯者，
- 或者發送電子郵件給胡皓文以獲取幫助：<src.res@email.cn>。
+ 或者發送電子郵件給胡皓文以獲取幫助：<src.res.211@gmail.com>。
diff --git a/Documentation/translations/zh_TW/filesystems/debugfs.rst b/Documentation/translations/zh_TW/filesystems/debugfs.rst
index 270dd94..ddf8019 100644
--- a/Documentation/translations/zh_TW/filesystems/debugfs.rst
+++ b/Documentation/translations/zh_TW/filesystems/debugfs.rst
@@ -14,12 +14,12 @@
中文版維護者：羅楚成 Chucheng Luo <luochucheng@vivo.com>
中文版翻譯者：羅楚成 Chucheng Luo <luochucheng@vivo.com>
中文版校譯者: 羅楚成 Chucheng Luo <luochucheng@vivo.com>
- 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res@email.cn>
+ 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com>
版權所有2020 羅楚成 <luochucheng@vivo.com>
-版權所有2021 胡皓文 Hu Haowen <src.res@email.cn>
+版權所有2021 胡皓文 Hu Haowen <src.res.211@gmail.com>
Debugfs是內核開發人員在用戶空間獲取信息的簡單方法。與/proc不同，proc只提供進程
diff --git a/Documentation/translations/zh_TW/filesystems/index.rst b/Documentation/translations/zh_TW/filesystems/index.rst
index 4e5dde0..789e742 100644
--- a/Documentation/translations/zh_TW/filesystems/index.rst
+++ b/Documentation/translations/zh_TW/filesystems/index.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/filesystems/index.rst <filesystems_index>`
:Translator: Wang Wenhu <wenhu.wang@vivo.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_filesystems_index:
diff --git a/Documentation/translations/zh_TW/filesystems/sysfs.txt b/Documentation/translations/zh_TW/filesystems/sysfs.txt
index 280824c..a84eba2 100644
--- a/Documentation/translations/zh_TW/filesystems/sysfs.txt
+++ b/Documentation/translations/zh_TW/filesystems/sysfs.txt
@@ -22,7 +22,7 @@
中文版維護者： 傅煒 Fu Wei <tekkamanninja@gmail.com>
中文版翻譯者： 傅煒 Fu Wei <tekkamanninja@gmail.com>
中文版校譯者： 傅煒 Fu Wei <tekkamanninja@gmail.com>
-繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
diff --git a/Documentation/translations/zh_TW/filesystems/tmpfs.rst b/Documentation/translations/zh_TW/filesystems/tmpfs.rst
index 8d753a3..2c8439b 100644
--- a/Documentation/translations/zh_TW/filesystems/tmpfs.rst
+++ b/Documentation/translations/zh_TW/filesystems/tmpfs.rst
@@ -5,7 +5,7 @@
:Original: Documentation/filesystems/tmpfs.rst
Translated by Wang Qing <wangqing@vivo.com>
-and Hu Haowen <src.res@email.cn>
+and Hu Haowen <src.res.211@gmail.com>
=====
Tmpfs
diff --git a/Documentation/translations/zh_TW/filesystems/virtiofs.rst b/Documentation/translations/zh_TW/filesystems/virtiofs.rst
index 2b05e84..086fce5 100644
--- a/Documentation/translations/zh_TW/filesystems/virtiofs.rst
+++ b/Documentation/translations/zh_TW/filesystems/virtiofs.rst
@@ -11,7 +11,7 @@
中文版翻譯者： 王文虎 Wang Wenhu <wenhu.wang@vivo.com>
中文版校譯者： 王文虎 Wang Wenhu <wenhu.wang@vivo.com>
中文版校譯者： 王文虎 Wang Wenhu <wenhu.wang@vivo.com>
- 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn>
+ 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com>
===========================================
virtiofs: virtio-fs 主機<->客機共享文件系統
diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt
index b93788a..555e4b1 100644
--- a/Documentation/translations/zh_TW/gpio.txt
+++ b/Documentation/translations/zh_TW/gpio.txt
@@ -8,7 +8,7 @@
Maintainer: Grant Likely <grant.likely@secretlab.ca>
Linus Walleij <linus.walleij@linaro.org>
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/admin-guide/gpio 的繁體中文翻譯
@@ -18,9 +18,9 @@
英文版維護者： Grant Likely <grant.likely@secretlab.ca>
Linus Walleij <linus.walleij@linaro.org>
-繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
---------------------------------------------------------------------
diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst
index e7c8386..d1cf0b4 100644
--- a/Documentation/translations/zh_TW/index.rst
+++ b/Documentation/translations/zh_TW/index.rst
@@ -15,159 +15,115 @@
.. note::
內核文檔繁體中文版的翻譯工作正在進行中。如果您願意並且有時間參與這項工
- 作，歡迎提交補丁給胡皓文 <src.res@email.cn>。
+ 作，歡迎提交補丁給胡皓文 <src.res.211@gmail.com>。
-許可證文檔
-----------
+與Linux 內核社區一起工作
+------------------------
-下面的文檔介紹了Linux內核原始碼的許可證（GPLv2）、如何在原始碼樹中正確標記
-單個文件的許可證、以及指向完整許可證文本的連結。
-
-Documentation/translations/zh_TW/process/license-rules.rst
-
-用戶文檔
---------
-
-下面的手冊是爲內核用戶編寫的——即那些試圖讓它在給定系統上以最佳方式工作的
-用戶。
+與內核開發社區進行協作並將工作推向上游的基本指南。
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
- admin-guide/index
+ process/development-process
+ process/submitting-patches
+ 行爲準則 <process/code-of-conduct>
+ 完整開發流程文檔 <process/index>
TODOList:
-* kbuild/index
+* maintainer/index
+
+內部API文檔
+-----------
+
+開發人員使用的內核內部交互接口手冊。
+
+TODOList:
+
+* core-api/index
+* driver-api/index
+* 內核中的鎖 <locking/index>
+* subsystem-apis
+
+開發工具和流程
+--------------
+
+爲所有內核開發人員提供有用信息的各種其他手冊。
+
+.. toctree::
+ :maxdepth: 1
+
+ process/license-rules
+
+TODOList:
+
+* doc-guide/index
+* dev-tools/index
+* dev-tools/testing-overview
+* kernel-hacking/index
+* rust/index
+* trace/index
+* fault-injection/index
+* livepatch/index
+
+面向用戶的文檔
+--------------
+
+下列手冊針對
+希望內核在給定系統上以最佳方式工作的*用戶*，
+和查找內核用戶空間API信息的程序開發人員。
+
+.. toctree::
+ :maxdepth: 1
+
+ admin-guide/index
+ admin-guide/reporting-issues.rst
+
+TODOList:
+
+* userspace-api/index
+* 內核構建系統 <kbuild/index>
+* 用戶空間工具 <tools/index>
+
+也可參考獨立於內核文檔的 `Linux 手冊頁 <https://www.kernel.org/doc/man-pages/>`_ 。
固件相關文檔
------------
-下列文檔描述了內核需要的平台固件相關信息。
+下列文檔描述了內核需要的平臺固件相關信息。
TODOList:
-* firmware-guide/index
* devicetree/index
+* firmware-guide/index
-應用程式開發人員文檔
---------------------
-
-用戶空間API手冊涵蓋了描述應用程式開發人員可見內核接口方面的文檔。
-
-TODOlist:
-
-* userspace-api/index
-
-內核開發簡介
+體系結構文檔
------------
-這些手冊包含有關如何開發內核的整體信息。內核社區非常龐大，一年下來有數千名
-開發人員做出貢獻。與任何大型社區一樣，知道如何完成任務將使得更改合併的過程
-變得更加容易。
-
-.. toctree::
- :maxdepth: 2
-
- process/index
-
TODOList:
-* dev-tools/index
-* doc-guide/index
-* kernel-hacking/index
-* trace/index
-* maintainer/index
-* fault-injection/index
-* livepatch/index
-* rust/index
-
-內核API文檔
------------
-
-以下手冊從內核開發人員的角度詳細介紹了特定的內核子系統是如何工作的。這裡的
-大部分信息都是直接從內核原始碼獲取的，並根據需要添加補充材料（或者至少是在
-我們設法添加的時候——可能不是所有的都是有需要的）。
-
-.. toctree::
- :maxdepth: 2
-
- cpu-freq/index
- filesystems/index
-
-TODOList:
-
-* driver-api/index
-* core-api/index
-* locking/index
-* accounting/index
-* block/index
-* cdrom/index
-* ide/index
-* fb/index
-* fpga/index
-* hid/index
-* i2c/index
-* iio/index
-* isdn/index
-* infiniband/index
-* leds/index
-* netlabel/index
-* networking/index
-* pcmcia/index
-* power/index
-* target/index
-* timers/index
-* spi/index
-* w1/index
-* watchdog/index
-* virt/index
-* input/index
-* hwmon/index
-* gpu/index
-* security/index
-* sound/index
-* crypto/index
-* mm/index
-* bpf/index
-* usb/index
-* PCI/index
-* scsi/index
-* misc-devices/index
-* scheduler/index
-* mhi/index
-
-體系結構無關文檔
-----------------
-
-TODOList:
-
-* asm-annotations
-
-特定體系結構文檔
-----------------
-
-.. toctree::
- :maxdepth: 2
-
- arch/arm64/index
-
-TODOList:
-
-* arch
+* arch/index
其他文檔
--------
-有幾份未排序的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或
+有幾份未分類的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或
轉換爲reStructureText格式，也有可能太舊。
TODOList:
* staging/index
-* watch_queue
-目錄和表格
+術語表
+------
+
+TODOList:
+
+* glossary
+
+
+索引和表格
----------
* :ref:`genindex`
diff --git a/Documentation/translations/zh_TW/io_ordering.txt b/Documentation/translations/zh_TW/io_ordering.txt
index 1e99206..03f8684 100644
--- a/Documentation/translations/zh_TW/io_ordering.txt
+++ b/Documentation/translations/zh_TW/io_ordering.txt
@@ -6,7 +6,7 @@
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/driver-api/io_ordering.rst 的繁體中文翻譯
@@ -14,9 +14,9 @@
交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或
者翻譯存在問題，請聯繫繁體中文版維護者。
-繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版校譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版校譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
diff --git a/Documentation/translations/zh_TW/process/1.Intro.rst b/Documentation/translations/zh_TW/process/1.Intro.rst
index ca2b931..f236fe95 100644
--- a/Documentation/translations/zh_TW/process/1.Intro.rst
+++ b/Documentation/translations/zh_TW/process/1.Intro.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_process_intro:
diff --git a/Documentation/translations/zh_TW/process/2.Process.rst b/Documentation/translations/zh_TW/process/2.Process.rst
index 9d465df..17bb4e0 100644
--- a/Documentation/translations/zh_TW/process/2.Process.rst
+++ b/Documentation/translations/zh_TW/process/2.Process.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_process:
diff --git a/Documentation/translations/zh_TW/process/3.Early-stage.rst b/Documentation/translations/zh_TW/process/3.Early-stage.rst
index 076873c..636e506 100644
--- a/Documentation/translations/zh_TW/process/3.Early-stage.rst
+++ b/Documentation/translations/zh_TW/process/3.Early-stage.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_early_stage:
diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst
index 7fc0344..adb5339 100644
--- a/Documentation/translations/zh_TW/process/4.Coding.rst
+++ b/Documentation/translations/zh_TW/process/4.Coding.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_coding:
diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst
index 280a883..2701562 100644
--- a/Documentation/translations/zh_TW/process/5.Posting.rst
+++ b/Documentation/translations/zh_TW/process/5.Posting.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_posting:
diff --git a/Documentation/translations/zh_TW/process/6.Followthrough.rst b/Documentation/translations/zh_TW/process/6.Followthrough.rst
index 4af7827..5073b6e 100644
--- a/Documentation/translations/zh_TW/process/6.Followthrough.rst
+++ b/Documentation/translations/zh_TW/process/6.Followthrough.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_followthrough:
diff --git a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
index 4fbc104..2cbd16b 100644
--- a/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
@@ -11,7 +11,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_advancedtopics:
diff --git a/Documentation/translations/zh_TW/process/8.Conclusion.rst b/Documentation/translations/zh_TW/process/8.Conclusion.rst
index 044fcc1..1207991 100644
--- a/Documentation/translations/zh_TW/process/8.Conclusion.rst
+++ b/Documentation/translations/zh_TW/process/8.Conclusion.rst
@@ -10,7 +10,7 @@
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
.. _tw_development_conclusion:
diff --git a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
index 949d831..920bb0f 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_code_of_conduct_interpretation:
diff --git a/Documentation/translations/zh_TW/process/code-of-conduct.rst b/Documentation/translations/zh_TW/process/code-of-conduct.rst
index 716e584..e308711 100644
--- a/Documentation/translations/zh_TW/process/code-of-conduct.rst
+++ b/Documentation/translations/zh_TW/process/code-of-conduct.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_code_of_conduct:
diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst
index 61e614a..83862e4 100644
--- a/Documentation/translations/zh_TW/process/coding-style.rst
+++ b/Documentation/translations/zh_TW/process/coding-style.rst
@@ -15,7 +15,7 @@
管旭東 Xudong Guan <xudong.guan@gmail.com>
Li Zefan <lizf@cn.fujitsu.com>
Wang Chen <wangchen@cn.fujitsu.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
Linux 內核代碼風格
=========================
diff --git a/Documentation/translations/zh_TW/process/development-process.rst b/Documentation/translations/zh_TW/process/development-process.rst
index 45e6385..f4cf5c2 100644
--- a/Documentation/translations/zh_TW/process/development-process.rst
+++ b/Documentation/translations/zh_TW/process/development-process.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/development-process.rst <development_process_main>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_development_process_main:
diff --git a/Documentation/translations/zh_TW/process/email-clients.rst b/Documentation/translations/zh_TW/process/email-clients.rst
index 4ba543d..ae63e41 100644
--- a/Documentation/translations/zh_TW/process/email-clients.rst
+++ b/Documentation/translations/zh_TW/process/email-clients.rst
@@ -14,7 +14,7 @@
中文版校譯者： Yinglin Luan <synmyth@gmail.com>
Xiaochen Wang <wangxiaochen0@gmail.com>
yaxinsn <yaxinsn@163.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
Linux郵件客戶端配置信息
=======================
diff --git a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
index fbde3e2..8e4db8b 100644
--- a/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
+++ b/Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
被限制的硬體問題
================
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index ea2f468..306f5b7 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -16,7 +16,7 @@
鍾宇 TripleX Chung <xxx.phy@gmail.com>
陳琦 Maggie Chen <chenqi@beyondsoft.com>
王聰 Wang Cong <xiyou.wangcong@gmail.com>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
如何參與Linux內核開發
=====================
diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst
index c5c59b4..d742642 100644
--- a/Documentation/translations/zh_TW/process/index.rst
+++ b/Documentation/translations/zh_TW/process/index.rst
@@ -9,7 +9,7 @@
:Original: :ref:`Documentation/process/index.rst <process_index>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_process_index:
diff --git a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst
index 8f22537..963ecec 100644
--- a/Documentation/translations/zh_TW/process/kernel-driver-statement.rst
+++ b/Documentation/translations/zh_TW/process/kernel-driver-statement.rst
@@ -6,7 +6,7 @@
:Original: :ref:`Documentation/process/kernel-driver-statement.rst <process_statement_driver>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
內核驅動聲明
------------
diff --git a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst
index 99e21d2..2861f4a 100644
--- a/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst
+++ b/Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst
@@ -6,7 +6,7 @@
:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
Linux 內核執行聲明
------------------
diff --git a/Documentation/translations/zh_TW/process/license-rules.rst b/Documentation/translations/zh_TW/process/license-rules.rst
index ad2b80f..503b670 100644
--- a/Documentation/translations/zh_TW/process/license-rules.rst
+++ b/Documentation/translations/zh_TW/process/license-rules.rst
@@ -6,7 +6,7 @@
:Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_kernel_licensing:
diff --git a/Documentation/translations/zh_TW/process/magic-number.rst b/Documentation/translations/zh_TW/process/magic-number.rst
index c9e3db1..5657d5c 100644
--- a/Documentation/translations/zh_TW/process/magic-number.rst
+++ b/Documentation/translations/zh_TW/process/magic-number.rst
@@ -12,7 +12,7 @@
中文版維護者： 賈威威 Jia Wei Wei <harryxiyou@gmail.com>
中文版翻譯者： 賈威威 Jia Wei Wei <harryxiyou@gmail.com>
中文版校譯者： 賈威威 Jia Wei Wei <harryxiyou@gmail.com>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
Linux 魔術數
============
diff --git a/Documentation/translations/zh_TW/process/management-style.rst b/Documentation/translations/zh_TW/process/management-style.rst
index dce2484..e9d2902 100644
--- a/Documentation/translations/zh_TW/process/management-style.rst
+++ b/Documentation/translations/zh_TW/process/management-style.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/management-style.rst <managementstyle>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_managementstyle:
diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst
index 144bdaf..e333896 100644
--- a/Documentation/translations/zh_TW/process/programming-language.rst
+++ b/Documentation/translations/zh_TW/process/programming-language.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/programming-language.rst <programming_language>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_programming_language:
diff --git a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst
index 22caa5b..33fc85c 100644
--- a/Documentation/translations/zh_TW/process/stable-api-nonsense.rst
+++ b/Documentation/translations/zh_TW/process/stable-api-nonsense.rst
@@ -12,7 +12,7 @@
中文版維護者： 鍾宇 TripleX Chung <xxx.phy@gmail.com>
中文版翻譯者： 鍾宇 TripleX Chung <xxx.phy@gmail.com>
中文版校譯者： 李陽 Li Yang <leoyang.li@nxp.com>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
Linux 內核驅動接口
==================
diff --git a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
index 9bb0d9b..29d9a70 100644
--- a/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
+++ b/Documentation/translations/zh_TW/process/stable-kernel-rules.rst
@@ -15,7 +15,7 @@
中文版校譯者：
- 李陽 Li Yang <leoyang.li@nxp.com>
- Kangkai Yin <e12051@motorola.com>
- - 胡皓文 Hu Haowen <src.res@email.cn>
+ - 胡皓文 Hu Haowen <src.res.211@gmail.com>
所有你想知道的事情 - 關於linux穩定版發布
========================================
diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst
index ff2f89c..12bf6f5 100644
--- a/Documentation/translations/zh_TW/process/submit-checklist.rst
+++ b/Documentation/translations/zh_TW/process/submit-checklist.rst
@@ -4,7 +4,7 @@
:Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`
:Translator: Alex Shi <alex.shi@linux.alibaba.com>
- Hu Haowen <src.res@email.cn>
+ Hu Haowen <src.res.211@gmail.com>
.. _tw_submitchecklist:
diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst
index 3f77ef5..0746809 100644
--- a/Documentation/translations/zh_TW/process/submitting-patches.rst
+++ b/Documentation/translations/zh_TW/process/submitting-patches.rst
@@ -13,7 +13,7 @@
時奎亮 Alex Shi <alex.shi@linux.alibaba.com>
中文版校譯者： 李陽 Li Yang <leoyang.li@nxp.com>
王聰 Wang Cong <xiyou.wangcong@gmail.com>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
如何讓你的改動進入內核
diff --git a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst
index 097fe80..469cb5b 100644
--- a/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst
+++ b/Documentation/translations/zh_TW/process/volatile-considered-harmful.rst
@@ -17,7 +17,7 @@
中文版校譯者： 張漢輝 Eugene Teo <eugeneteo@kernel.sg>
楊瑞 Dave Young <hidave.darkstar@gmail.com>
時奎亮 Alex Shi <alex.shi@linux.alibaba.com>
- 胡皓文 Hu Haowen <src.res@email.cn>
+ 胡皓文 Hu Haowen <src.res.211@gmail.com>
爲什麼不應該使用「volatile」類型
================================
diff --git a/Documentation/translations/zh_TW/sparse.txt b/Documentation/translations/zh_TW/sparse.txt
index c9acb2c..35d3d1d 100644
--- a/Documentation/translations/zh_TW/sparse.txt
+++ b/Documentation/translations/zh_TW/sparse.txt
@@ -6,7 +6,7 @@
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
-Traditional Chinese maintainer: Hu Haowen <src.res@email.cn>
+Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com>
---------------------------------------------------------------------
Documentation/dev-tools/sparse.rst 的繁體中文翻譯
@@ -14,8 +14,8 @@
交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或
者翻譯存在問題，請聯繫繁體中文版維護者。
-繁體中文版維護者： 胡皓文 Hu Haowen <src.res@email.cn>
-繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res@email.cn>
+繁體中文版維護者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
+繁體中文版翻譯者： 胡皓文 Hu Haowen <src.res.211@gmail.com>
以下爲正文
---------------------------------------------------------------------
@@ -66,11 +66,11 @@
你可以從 Sparse 的主頁獲取最新的發布版本：
- http://www.kernel.org/pub/linux/kernel/people/josh/sparse/
+ https://www.kernel.org/pub/software/devel/sparse/dist/
或者，你也可以使用 git 克隆最新的 sparse 開發版本：
- git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git
+ git://git.kernel.org/pub/scm/devel/sparse/sparse.git
一旦你下載了源碼，只要以普通用戶身份運行：
diff --git a/Documentation/usb/authorization.rst b/Documentation/usb/authorization.rst
index 9e53909..150a149 100644
--- a/Documentation/usb/authorization.rst
+++ b/Documentation/usb/authorization.rst
@@ -33,12 +33,9 @@
$ echo 1 > /sys/bus/usb/devices/usbX/authorized_default
-By default, Wired USB devices are authorized by default to
-connect. Wireless USB hosts deauthorize by default all new connected
-devices (this is so because we need to do an authentication phase
-before authorizing). Writing "2" to the authorized_default attribute
-causes kernel to only authorize by default devices connected to internal
-USB ports.
+By default, all USB devices are authorized. Writing "2" to the
+authorized_default attribute causes the kernel to authorize by default
+only devices connected to internal USB ports.
Example system lockdown (lame)
diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst
index 2fca404..394cd22 100644
--- a/Documentation/usb/gadget-testing.rst
+++ b/Documentation/usb/gadget-testing.rst
@@ -27,6 +27,7 @@
18. UVC function
19. PRINTER function
20. UAC1 function (new API)
+ 21. MIDI2 function
1. ACM function
@@ -965,3 +966,156 @@
$ arecord -f dat -t wav -D hw:CARD=UAC1Gadget,DEV=0 | \
aplay -D default:CARD=OdroidU3
+
+
+21. MIDI2 function
+==================
+
+The function is provided by usb_f_midi2.ko module.
+It will create a virtual ALSA card containing a UMP rawmidi device
+where the UMP packet is looped back. In addition, a legacy rawmidi
+device is created. The UMP rawmidi is bound with ALSA sequencer
+clients, too.
+
+Function-specific configfs interface
+------------------------------------
+
+The function name to use when creating the function directory is "midi2".
+The midi2 function provides these attributes in its function directory
+as the card top-level information:
+
+ ============= =================================================
+ process_ump Bool flag to process UMP Stream messages (0 or 1)
+ static_block Bool flag for static blocks (0 or 1)
+ iface_name Optional interface name string
+ ============= =================================================
+
+The directory contains a subdirectory "ep.0", and this provides the
+attributes for a UMP Endpoint (which is a pair of USB MIDI Endpoints):
+
+ ============= =================================================
+ protocol_caps MIDI protocol capabilities;
+ 1: MIDI 1.0, 2: MIDI 2.0, or 3: both protocols
+ protocol Default MIDI protocol (either 1 or 2)
+ ep_name UMP Endpoint name string
+ product_id Product ID string
+ manufacturer Manufacture ID number (24 bit)
+ family Device family ID number (16 bit)
+ model Device model ID number (16 bit)
+ sw_revision Software revision (32 bit)
+ ============= =================================================
+
+Each Endpoint subdirectory contains a subdirectory "block.0", which
+represents the Function Block for Block 0 information.
+Its attributes are:
+
+ ================= ===============================================
+ name Function Block name string
+ direction Direction of this FB
+ 1: input, 2: output, or 3: bidirectional
+ first_group The first UMP Group number (0-15)
+ num_groups The number of groups in this FB (1-16)
+ midi1_first_group The first UMP Group number for MIDI 1.0 (0-15)
+ midi1_num_groups The number of groups for MIDI 1.0 (0-16)
+ ui_hint UI-hint of this FB
+ 0: unknown, 1: receiver, 2: sender, 3: both
+ midi_ci_verison Supported MIDI-CI version number (8 bit)
+ is_midi1 Legacy MIDI 1.0 device (0-2)
+ 0: MIDI 2.0 device,
+ 1: MIDI 1.0 without restriction, or
+ 2: MIDI 1.0 with low speed
+ sysex8_streams Max number of SysEx8 streams (8 bit)
+ active Bool flag for FB activity (0 or 1)
+ ================= ===============================================
+
+If multiple Function Blocks are required, you can add more Function
+Blocks by creating subdirectories "block.<num>" with the corresponding
+Function Block number (1, 2, ....). The FB subdirectories can be
+dynamically removed, too. Note that the Function Block numbers must be
+continuous.
+
+Similarly, if you multiple UMP Endpoints are required, you can add
+more Endpoints by creating subdirectories "ep.<num>". The number must
+be continuous.
+
+For emulating the old MIDI 2.0 device without UMP v1.1 support, pass 0
+to `process_ump` flag. Then the whole UMP v1.1 requests are ignored.
+
+Testing the MIDI2 function
+--------------------------
+
+On the device: run the gadget, and running::
+
+ $ cat /proc/asound/cards
+
+will show a new sound card containing a MIDI2 device.
+
+OTOH, on the host::
+
+ $ cat /proc/asound/cards
+
+will show a new sound card containing either MIDI1 or MIDI2 device,
+depending on the USB audio driver configuration.
+
+On both, when ALSA sequencer is enabled on the host, you can find the
+UMP MIDI client such as "MIDI 2.0 Gadget".
+
+As the driver simply loops back the data, there is no need for a real
+device just for testing.
+
+For testing a MIDI input from the gadget to the host (e.g. emulating a
+MIDI keyboard), you can send a MIDI stream like the following.
+
+On the gadget::
+
+ $ aconnect -o
+ ....
+ client 20: 'MIDI 2.0 Gadget' [type=kernel,card=1]
+ 0 'MIDI 2.0 '
+ 1 'Group 1 (MIDI 2.0 Gadget I/O)'
+ $ aplaymidi -p 20:1 to_host.mid
+
+On the host::
+
+ $ aconnect -i
+ ....
+ client 24: 'MIDI 2.0 Gadget' [type=kernel,card=2]
+ 0 'MIDI 2.0 '
+ 1 'Group 1 (MIDI 2.0 Gadget I/O)'
+ $ arecordmidi -p 24:1 from_gadget.mid
+
+If you have a UMP-capable application, you can use the UMP port to
+send/receive the raw UMP packets, too. For example, aseqdump program
+with UMP support can receive from UMP port. On the host::
+
+ $ aseqdump -u 2 -p 24:1
+ Waiting for data. Press Ctrl+C to end.
+ Source Group Event Ch Data
+ 24:1 Group 0, Program change 0, program 0, Bank select 0:0
+ 24:1 Group 0, Channel pressure 0, value 0x80000000
+
+For testing a MIDI output to the gadget to the host (e.g. emulating a
+MIDI synth), it'll be just other way round.
+
+On the gadget::
+
+ $ arecordmidi -p 20:1 from_host.mid
+
+On the host::
+
+ $ aplaymidi -p 24:1 to_gadget.mid
+
+The access to MIDI 1.0 on altset 0 on the host is supported, and it's
+translated from/to UMP packets on the gadget. It's bound to only
+Function Block 0.
+
+The current operation mode can be observed in ALSA control element
+"Operation Mode" for SND_CTL_IFACE_RAWMIDI. For example::
+
+ $ amixer -c1 contents
+ numid=1,iface=RAWMIDI,name='Operation Mode'
+ ; type=INTEGER,access=r--v----,values=1,min=0,max=2,step=0
+ : values=2
+
+where 0 = unused, 1 = MIDI 1.0 (altset 0), 2 = MIDI 2.0 (altset 1).
+The example above shows it's running in 2, i.e. MIDI 2.0.
diff --git a/Documentation/usb/gadget_uvc.rst b/Documentation/usb/gadget_uvc.rst
index 62bd81b..80a1f03 100644
--- a/Documentation/usb/gadget_uvc.rst
+++ b/Documentation/usb/gadget_uvc.rst
@@ -168,7 +168,7 @@
The UVC specification requires that Format and Frame descriptors be preceded by
Headers detailing things such as the number and cumulative size of the different
-Format descriptors that follow. This and similar operations are acheived in
+Format descriptors that follow. This and similar operations are achieved in
configfs by linking between the configfs item representing the header and the
config items representing those other descriptors, in this manner:
diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst
index 675bc2c..ef8e8cf 100644
--- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
@@ -277,7 +277,7 @@
other fields
follow standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``sizeimage``
adjusted size of ``OUTPUT`` buffers.
@@ -311,7 +311,7 @@
``memory``
follows standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``count``
the actual number of buffers allocated.
@@ -339,7 +339,7 @@
``format``
follows standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``count``
adjusted to the number of allocated buffers.
@@ -410,7 +410,7 @@
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
- * **Return fields:**
+ * **Returned fields:**
``width``, ``height``
frame buffer resolution for the decoded frames.
@@ -443,7 +443,7 @@
``target``
set to ``V4L2_SEL_TGT_COMPOSE``.
- * **Return fields:**
+ * **Returned fields:**
``r.left``, ``r.top``, ``r.width``, ``r.height``
the visible rectangle; it must fit within the frame buffer resolution
@@ -552,7 +552,7 @@
frame is written; defaults to ``V4L2_SEL_TGT_COMPOSE_DEFAULT``;
read-only on hardware without additional compose/scaling capabilities.
- * **Return fields:**
+ * **Returned fields:**
``r.left``, ``r.top``, ``r.width``, ``r.height``
the visible rectangle; it must fit within the frame buffer resolution
@@ -629,7 +629,7 @@
``memory``
follows standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``count``
actual number of buffers allocated.
@@ -668,7 +668,7 @@
a format representing the maximum framebuffer resolution to be
accommodated by newly allocated buffers.
- * **Return fields:**
+ * **Returned fields:**
``count``
adjusted to the number of allocated buffers.
diff --git a/Documentation/userspace-api/media/v4l/dev-encoder.rst b/Documentation/userspace-api/media/v4l/dev-encoder.rst
index aa338b9..6c523c69 100644
--- a/Documentation/userspace-api/media/v4l/dev-encoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-encoder.rst
@@ -115,8 +115,8 @@
4. The client may use :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` to detect supported
frame intervals for a given format and resolution, passing the desired pixel
- format in :c:type:`v4l2_frmsizeenum` ``pixel_format`` and the resolution
- in :c:type:`v4l2_frmsizeenum` ``width`` and :c:type:`v4l2_frmsizeenum`
+ format in :c:type:`v4l2_frmivalenum` ``pixel_format`` and the resolution
+ in :c:type:`v4l2_frmivalenum` ``width`` and :c:type:`v4l2_frmivalenum`
``height``.
* Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a coded pixel
@@ -163,7 +163,7 @@
other fields
follow standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``sizeimage``
adjusted size of ``CAPTURE`` buffers.
@@ -189,7 +189,7 @@
other fields
follow standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``pixelformat``
raw format supported for the coded format currently selected on
@@ -215,7 +215,7 @@
other fields
follow standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``width``, ``height``
may be adjusted to match encoder minimums, maximums and alignment
@@ -233,7 +233,7 @@
:c:func:`VIDIOC_S_PARM`. This also sets the coded frame interval on the
``CAPTURE`` queue to the same value.
- * ** Required fields:**
+ * **Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
@@ -245,7 +245,7 @@
the desired frame interval; the encoder may adjust it to
match hardware requirements.
- * **Return fields:**
+ * **Returned fields:**
``parm.output.timeperframe``
the adjusted frame interval.
@@ -284,7 +284,7 @@
the case for off-line encoding. Support for this feature is signalled
by the :ref:`V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL <fmtdesc-flags>` format flag.
- * ** Required fields:**
+ * **Required fields:**
``type``
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
@@ -296,7 +296,7 @@
the desired coded frame interval; the encoder may adjust it to
match hardware requirements.
- * **Return fields:**
+ * **Returned fields:**
``parm.capture.timeperframe``
the adjusted frame interval.
@@ -339,7 +339,7 @@
rectangle and may be subject to adjustment to match codec and
hardware constraints.
- * **Return fields:**
+ * **Returned fields:**
``r.left``, ``r.top``, ``r.width``, ``r.height``
visible rectangle adjusted by the encoder.
@@ -387,7 +387,7 @@
other fields
follow standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``count``
actual number of buffers allocated.
@@ -420,7 +420,7 @@
other fields
follow standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``count``
adjusted to the number of allocated buffers.
diff --git a/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst b/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst
index 4a26646..35ed05f 100644
--- a/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst
@@ -180,7 +180,7 @@
``memory``
follows standard semantics.
- * **Return fields:**
+ * **Returned fields:**
``count``
actual number of buffers allocated.
@@ -208,7 +208,7 @@
follows standard semantics. ``V4L2_MEMORY_USERPTR`` is not supported
for ``CAPTURE`` buffers.
- * **Return fields:**
+ * **Returned fields:**
``count``
adjusted to allocated number of buffers, in case the codec requires
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 81e60f4..786127b 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -3293,7 +3293,7 @@
.. c:type:: v4l2_av1_loop_restoration
-AV1 Loop Restauration as described in section 6.10.15 "Loop restoration params
+AV1 Loop Restoration as described in section 6.10.15 "Loop restoration params
semantics" of :ref:`av1`.
.. cssclass:: longtable
diff --git a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
index 5418360..0686413 100644
--- a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
+++ b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
@@ -237,7 +237,7 @@
camera projectors. As we have another field for "Laser Power" we introduced
"LED Power" for extra emitter.
-The "Laser mode" __u32 fiels has been split into: ::
+The "Laser mode" __u32 fields has been split into: ::
1 __u8 Emitter mode
2 __u8 RFU byte
3 __u16 LED Power
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
index 58f6ae2..296ad20 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
@@ -275,6 +275,19 @@
Decoder's implementation can be found here,
`aspeed_codec <https://github.com/AspeedTech-BMC/aspeed_codec/>`__
+ * .. _V4L2-PIX-FMT-MT2110T:
+
+ - ``V4L2_PIX_FMT_MT2110T``
+ - 'MT2110T'
+ - This format is two-planar 10-Bit tile mode and having similitude with
+ ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling. Used for VP9, AV1
+ and HEVC.
+ * .. _V4L2-PIX-FMT-MT2110R:
+
+ - ``V4L2_PIX_FMT_MT2110R``
+ - 'MT2110R'
+ - This format is two-planar 10-Bit raster mode and having similitude with
+ ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling. Used for AVC.
.. raw:: latex
\normalsize
diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
index 2d6e3bb..72677a2 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst
@@ -58,6 +58,9 @@
value of the ``num_routes`` field. Application should then reserve enough memory
for all the route entries and call ``VIDIOC_SUBDEV_G_ROUTING`` again.
+On a successful ``VIDIOC_SUBDEV_G_ROUTING`` call the driver updates the
+``num_routes`` field to reflect the actual number of routes returned.
+
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
.. c:type:: v4l2_subdev_routing
@@ -138,9 +141,7 @@
EINVAL
The sink or source pad identifiers reference a non-existing pad, or reference
- pads of different types (ie. the sink_pad identifiers refers to a source pad)
- or the sink or source stream identifiers reference a non-existing stream on
- the sink or source pad.
+ pads of different types (ie. the sink_pad identifiers refers to a source pad).
E2BIG
The application provided ``num_routes`` for ``VIDIOC_SUBDEV_S_ROUTING`` is
diff --git a/Documentation/userspace-api/netlink/genetlink-legacy.rst b/Documentation/userspace-api/netlink/genetlink-legacy.rst
index 802875a..40b82ad 100644
--- a/Documentation/userspace-api/netlink/genetlink-legacy.rst
+++ b/Documentation/userspace-api/netlink/genetlink-legacy.rst
@@ -8,11 +8,8 @@
required to describe older Generic Netlink families which form
the ``genetlink-legacy`` protocol level.
-The spec is a work in progress, some of the quirks are just documented
-for future reference.
-
-Specification (defined)
-=======================
+Specification
+=============
Attribute type nests
--------------------
@@ -156,16 +153,27 @@
with a request section and the value of 2) and 8 for response (``c`` is
the previous operation in the "from-kernel" direction).
-Other quirks (todo)
-===================
+Other quirks
+============
Structures
----------
Legacy families can define C structures both to be used as the contents of
an attribute and as a fixed message header. Structures are defined in
-``definitions`` and referenced in operations or attributes. Note that
-structures defined in YAML are implicitly packed according to C
+``definitions`` and referenced in operations or attributes.
+
+members
+~~~~~~~
+
+ - ``name`` - The attribute name of the struct member
+ - ``type`` - One of the scalar types ``u8``, ``u16``, ``u32``, ``u64``, ``s8``,
+ ``s16``, ``s32``, ``s64``, ``string`` or ``binary``.
+ - ``byte-order`` - ``big-endian`` or ``little-endian``
+ - ``doc``, ``enum``, ``enum-as-flags``, ``display-hint`` - Same as for
+ :ref:`attribute definitions <attribute_properties>`
+
+Note that structures defined in YAML are implicitly packed according to C
conventions. For example, the following struct is 4 bytes, not 6 bytes:
.. code-block:: c
diff --git a/Documentation/userspace-api/netlink/index.rst b/Documentation/userspace-api/netlink/index.rst
index 26f3720c..62725da 100644
--- a/Documentation/userspace-api/netlink/index.rst
+++ b/Documentation/userspace-api/netlink/index.rst
@@ -14,5 +14,6 @@
specs
c-code-gen
genetlink-legacy
+ netlink-raw
See also :ref:`Documentation/core-api/netlink.rst <kernel_netlink>`.
diff --git a/Documentation/userspace-api/netlink/intro.rst b/Documentation/userspace-api/netlink/intro.rst
index 0955e9f..af94e71 100644
--- a/Documentation/userspace-api/netlink/intro.rst
+++ b/Documentation/userspace-api/netlink/intro.rst
@@ -615,7 +615,7 @@
is defined by the 2 lowest bits of the message type, so commands for
new objects would always be allocated with a stride of 4.
-Each object would also have it's own fixed metadata shared by all request
+Each object would also have its own fixed metadata shared by all request
types (e.g. struct ifinfomsg for netdev requests, struct ifaddrmsg for address
requests, struct tcmsg for qdisc requests).
diff --git a/Documentation/userspace-api/netlink/netlink-raw.rst b/Documentation/userspace-api/netlink/netlink-raw.rst
new file mode 100644
index 0000000..f07fb9b
--- /dev/null
+++ b/Documentation/userspace-api/netlink/netlink-raw.rst
@@ -0,0 +1,58 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+
+======================================================
+Netlink specification support for raw Netlink families
+======================================================
+
+This document describes the additional properties required by raw Netlink
+families such as ``NETLINK_ROUTE`` which use the ``netlink-raw`` protocol
+specification.
+
+Specification
+=============
+
+The netlink-raw schema extends the :doc:`genetlink-legacy <genetlink-legacy>`
+schema with properties that are needed to specify the protocol numbers and
+multicast IDs used by raw netlink families. See :ref:`classic_netlink` for more
+information.
+
+Globals
+-------
+
+protonum
+~~~~~~~~
+
+The ``protonum`` property is used to specify the protocol number to use when
+opening a netlink socket.
+
+.. code-block:: yaml
+
+ # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+
+ name: rt-addr
+ protocol: netlink-raw
+ protonum: 0 # part of the NETLINK_ROUTE protocol
+
+
+Multicast group properties
+--------------------------
+
+value
+~~~~~
+
+The ``value`` property is used to specify the group ID to use for multicast
+group registration.
+
+.. code-block:: yaml
+
+ mcast-groups:
+ list:
+ -
+ name: rtnlgrp-ipv4-ifaddr
+ value: 5
+ -
+ name: rtnlgrp-ipv6-ifaddr
+ value: 9
+ -
+ name: rtnlgrp-mctp-ifaddr
+ value: 34
diff --git a/Documentation/userspace-api/netlink/specs.rst b/Documentation/userspace-api/netlink/specs.rst
index 2e4acde..cc4e2430 100644
--- a/Documentation/userspace-api/netlink/specs.rst
+++ b/Documentation/userspace-api/netlink/specs.rst
@@ -68,6 +68,10 @@
schema. See the documentation of :doc:`genetlink-c <c-code-gen>`
for information on how C names are derived from name properties.
+See also :ref:`Documentation/core-api/netlink.rst <kernel_netlink>` for
+information on the Netlink specification properties that are only relevant to
+the kernel space and not part of the user space API.
+
genetlink
=========
@@ -180,6 +184,8 @@
List of attributes in the set.
+.. _attribute_properties:
+
Attribute properties
--------------------
@@ -264,6 +270,13 @@
``sub-type: u32``. Binary types and legacy array formats are described in
more detail in :doc:`genetlink-legacy`.
+display-hint
+~~~~~~~~~~~~
+
+Optional format indicator that is intended only for choosing the right
+formatting mechanism when displaying values of this type. Currently supported
+hints are ``hex``, ``mac``, ``fddi``, ``ipv4``, ``ipv6`` and ``uuid``.
+
operations
----------
diff --git a/Documentation/virt/hyperv/clocks.rst b/Documentation/virt/hyperv/clocks.rst
index 2da2879..a56f483 100644
--- a/Documentation/virt/hyperv/clocks.rst
+++ b/Documentation/virt/hyperv/clocks.rst
@@ -60,7 +60,7 @@
entirely in user space. The vDSO is implemented by mapping the
shared page with scale and offset values into user space. User
space code performs the same algorithm of reading the TSC and
-appying the scale and offset to get the constant 10 MHz clock.
+applying the scale and offset to get the constant 10 MHz clock.
Linux clockevents are based on Hyper-V synthetic timer 0. While
Hyper-V offers 4 synthetic timers for each CPU, Linux only uses
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index c0ddd30..73db30c 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -578,7 +578,7 @@
RISC-V:
^^^^^^^
-Queues an external interrupt to be injected into the virutal CPU. This ioctl
+Queues an external interrupt to be injected into the virtual CPU. This ioctl
is overloaded with 2 different irq values:
a) KVM_INTERRUPT_SET
@@ -2722,7 +2722,7 @@
a Guest VCPU runs. It will have ISA feature bits matching underlying host
set by default.
-RISC-V core registers represent the general excution state of a Guest VCPU
+RISC-V core registers represent the general execution state of a Guest VCPU
and it has the following id bit patterns::
0x8020 0000 02 <index into the kvm_riscv_core struct:24> (32bit Host)
@@ -5232,7 +5232,7 @@
Deregister the VM from the Ultravisor and reclaim the memory that had
been donated to the Ultravisor, making it usable by the kernel again.
All registered VCPUs are converted back to non-protected ones. If a
- previous protected VM had been prepared for asynchonous teardown with
+ previous protected VM had been prepared for asynchronous teardown with
KVM_PV_ASYNC_CLEANUP_PREPARE and not subsequently torn down with
KVM_PV_ASYNC_CLEANUP_PERFORM, it will be torn down in this call
together with the current protected VM.
@@ -5692,7 +5692,7 @@
``KVM_SREGS2_FLAGS_PDPTRS_VALID``
- Indicates thats the struct contain valid PDPTR values.
+ Indicates that the struct contains valid PDPTR values.
4.132 KVM_SET_SREGS2
@@ -6263,7 +6263,7 @@
It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or
``KVM_EXIT_MMIO`` (all except s390) to implement functionality that
-requires a guest to interact with host userpace.
+requires a guest to interact with host userspace.
.. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.
@@ -6336,7 +6336,7 @@
} s390_ucontrol;
s390 specific. A page fault has occurred for a user controlled virtual
-machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be
+machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be
resolved by the kernel.
The program code and the translation exception code that were placed
in the cpu's lowcore are presented here as defined by the z Architecture
@@ -7510,7 +7510,7 @@
attribute is not supported by KVM.
KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or
-more priveleged enclave attributes. args[0] must hold a file handle to a valid
+more privileged enclave attributes. args[0] must hold a file handle to a valid
SGX attribute file corresponding to an attribute that is supported/restricted
by KVM (currently only PROVISIONKEY).
@@ -7928,7 +7928,7 @@
This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr. Its
value is used to denote the target vcpu for a SynIC interrupt. For
-compatibilty, KVM initializes this msr to KVM's internal vcpu index. When this
+compatibility, KVM initializes this msr to KVM's internal vcpu index. When this
capability is absent, userspace can still query this msr's value.
8.13 KVM_CAP_S390_AIS_MIGRATION
@@ -8118,10 +8118,10 @@
: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.
+mmapped 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``. Each dirty entry is defined as::
struct kvm_dirty_gfn {
__u32 flags;
@@ -8160,7 +8160,7 @@
| |
+------------------------------------------+
-To harvest the dirty pages, userspace accesses the mmaped ring buffer
+To harvest the dirty pages, userspace accesses the mmapped 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
@@ -8286,7 +8286,7 @@
and KVM_XEN_GET_ATTR ioctls. This controls whether KVM will set the
XEN_RUNSTATE_UPDATE flag in guest memory mapped vcpu_runstate_info during
updates of the runstate information. Note that versions of KVM which support
-the RUNSTATE feature above, but not thie RUNSTATE_UPDATE_FLAG feature, will
+the RUNSTATE feature above, but not the RUNSTATE_UPDATE_FLAG feature, will
always set the XEN_RUNSTATE_UPDATE flag when updating the guest structure,
which is perhaps counterintuitive. When this flag is advertised, KVM will
behave more correctly, not using the XEN_RUNSTATE_UPDATE flag until/unless
@@ -8335,7 +8335,7 @@
When enabled, KVM will disable emulated Hyper-V features provided to the
guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all
-currently implmented Hyper-V features are provided unconditionally when
+currently implemented Hyper-V features are provided unconditionally when
Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001)
leaf.
diff --git a/Documentation/virt/kvm/devices/vfio.rst b/Documentation/virt/kvm/devices/vfio.rst
index 08b5442..c549143 100644
--- a/Documentation/virt/kvm/devices/vfio.rst
+++ b/Documentation/virt/kvm/devices/vfio.rst
@@ -9,22 +9,34 @@
- KVM_DEV_TYPE_VFIO
Only one VFIO instance may be created per VM. The created device
-tracks VFIO groups in use by the VM and features of those groups
-important to the correctness and acceleration of the VM. As groups
-are enabled and disabled for use by the VM, KVM should be updated
-about their presence. When registered with KVM, a reference to the
-VFIO-group is held by KVM.
+tracks VFIO files (group or device) in use by the VM and features
+of those groups/devices important to the correctness and acceleration
+of the VM. As groups/devices are enabled and disabled for use by the
+VM, KVM should be updated about their presence. When registered with
+KVM, a reference to the VFIO file is held by KVM.
Groups:
- KVM_DEV_VFIO_GROUP
+ KVM_DEV_VFIO_FILE
+ alias: KVM_DEV_VFIO_GROUP
-KVM_DEV_VFIO_GROUP attributes:
- KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
- kvm_device_attr.addr points to an int32_t file descriptor
- for the VFIO group.
- KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
- kvm_device_attr.addr points to an int32_t file descriptor
- for the VFIO group.
+KVM_DEV_VFIO_FILE attributes:
+ KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
+ tracking
+
+ kvm_device_attr.addr points to an int32_t file descriptor for the
+ VFIO file.
+
+ KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
+ device tracking
+
+ kvm_device_attr.addr points to an int32_t file descriptor for the
+ VFIO file.
+
+KVM_DEV_VFIO_GROUP (legacy kvm device group restricted to the handling of VFIO group fd):
+ KVM_DEV_VFIO_GROUP_ADD: same as KVM_DEV_VFIO_FILE_ADD for group fd only
+
+ KVM_DEV_VFIO_GROUP_DEL: same as KVM_DEV_VFIO_FILE_DEL for group fd only
+
KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
allocated by sPAPR KVM.
kvm_device_attr.addr points to a struct::
@@ -40,7 +52,10 @@
- @tablefd is a file descriptor for a TCE table allocated via
KVM_CREATE_SPAPR_TCE.
-The GROUP_ADD operation above should be invoked prior to accessing the
+The FILE/GROUP_ADD operation above should be invoked prior to accessing the
device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support
drivers which require a kvm pointer to be set in their .open_device()
-callback.
+callback. It is the same for device file descriptor via character device
+open which gets device access via VFIO_DEVICE_BIND_IOMMUFD. For such file
+descriptors, FILE_ADD should be invoked before VFIO_DEVICE_BIND_IOMMUFD
+to support the drivers mentioned in prior sentence as well.
diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst
index 9d726e6..a4d39fa 100644
--- a/Documentation/virt/kvm/devices/vm.rst
+++ b/Documentation/virt/kvm/devices/vm.rst
@@ -92,7 +92,7 @@
KVM does not enforce or limit the cpu model data in any form. Take the information
retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration
setups. Instruction interceptions triggered by additionally set facility bits that
-are not handled by KVM need to by imlemented in the VM driver code.
+are not handled by KVM need to by implemented in the VM driver code.
:Parameters: address of buffer to store/set the processor related cpu
data of type struct kvm_s390_vm_cpu_processor*.
diff --git a/Documentation/virt/kvm/devices/xive.rst b/Documentation/virt/kvm/devices/xive.rst
index 8b5e7b4..a07e16d 100644
--- a/Documentation/virt/kvm/devices/xive.rst
+++ b/Documentation/virt/kvm/devices/xive.rst
@@ -50,7 +50,7 @@
When a device is passed-through into the guest, the source
interrupts are from a different HW controller (PHB4) and the ESB
- pages exposed to the guest should accommadate this change.
+ pages exposed to the guest should accommodate this change.
The passthru_irq helpers, kvmppc_xive_set_mapped() and
kvmppc_xive_clr_mapped() are called when the device HW irqs are
diff --git a/Documentation/virt/kvm/halt-polling.rst b/Documentation/virt/kvm/halt-polling.rst
index 4f1a1b2..c82a04b 100644
--- a/Documentation/virt/kvm/halt-polling.rst
+++ b/Documentation/virt/kvm/halt-polling.rst
@@ -14,7 +14,7 @@
Polling provides a latency advantage in cases where the guest can be run again
very quickly by at least saving us a trip through the scheduler, normally on
the order of a few micro-seconds, although performance benefits are workload
-dependant. In the event that no wakeup source arrives during the polling
+dependent. In the event that no wakeup source arrives during the polling
interval or some other task on the runqueue is runnable the scheduler is
invoked. Thus halt polling is especially useful on workloads with very short
wakeup periods where the time spent halt polling is minimised and the time
diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst
index 26f6203..d47595b 100644
--- a/Documentation/virt/kvm/x86/mmu.rst
+++ b/Documentation/virt/kvm/x86/mmu.rst
@@ -245,7 +245,7 @@
unsynchronized children).
unsync_child_bitmap:
A bitmap indicating which sptes in spt point (directly or indirectly) at
- pages that may be unsynchronized. Used to quickly locate all unsychronized
+ pages that may be unsynchronized. Used to quickly locate all unsynchronized
pages reachable from a given page.
clear_spte_count:
Only present on 32-bit hosts, where a 64-bit spte cannot be written
diff --git a/Documentation/virt/kvm/x86/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst
index 71136fe..8732641 100644
--- a/Documentation/virt/kvm/x86/running-nested-guests.rst
+++ b/Documentation/virt/kvm/x86/running-nested-guests.rst
@@ -169,7 +169,7 @@
$ modprobe kvm nested=1
.. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
- with the ``nested`` paramter — i.e. to be able to enable
+ with the ``nested`` parameter — i.e. to be able to enable
``nested``, the ``hpage`` parameter *must* be disabled.
2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
index af2a974..d1cfe41 100644
--- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst
+++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
@@ -1224,7 +1224,7 @@
security-wise. Allowing it as a loadable module parameter
isn't.
-If such functionality is desireable for a particular application
+If such functionality is desirable for a particular application
(e.g. loading BPF "firmware" for raw socket network transports),
it should be off by default and should be explicitly turned on
as a command line parameter at startup.
diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst
index 758dadb..6aec04d 100644
--- a/Documentation/w1/slaves/w1_therm.rst
+++ b/Documentation/w1/slaves/w1_therm.rst
@@ -58,7 +58,7 @@
``conv_time`` is used to get current conversion time (read), and
adjust it (write). A temperature conversion time depends on the device type and
-it's current resolution. Default conversion time is set by the driver according
+its current resolution. Default conversion time is set by the driver according
to the device datasheet. A conversion time for many original device clones
deviate from datasheet specs. There are three options: 1) manually set the
correct conversion time by writing a value in milliseconds to ``conv_time``; 2)
diff --git a/Documentation/w1/w1-generic.rst b/Documentation/w1/w1-generic.rst
index 99255b6..96a0425 100644
--- a/Documentation/w1/w1-generic.rst
+++ b/Documentation/w1/w1-generic.rst
@@ -101,7 +101,7 @@
w1_master_slave_count (ro) the number of slaves found
w1_master_slaves (ro) the names of the slaves, one per line
w1_master_timeout (ro) the delay in seconds between searches
-w1_master_timeout_us (ro) the delay in microseconds beetwen searches
+w1_master_timeout_us (ro) the delay in microseconds between searches
========================= =====================================================
If you have a w1 bus that never changes (you don't add or remove devices),
diff --git a/Documentation/w1/w1-netlink.rst b/Documentation/w1/w1-netlink.rst
index aaa1324..be4f7b82 100644
--- a/Documentation/w1/w1-netlink.rst
+++ b/Documentation/w1/w1-netlink.rst
@@ -66,7 +66,7 @@
zero or more attached w1_netlink_cmd messages.
For event messages there are no w1_netlink_cmd embedded structures,
-only connector header and w1_netlink_msg strucutre with "len" field
+only connector header and w1_netlink_msg structure with "len" field
being zero and filled type (one of event types) and id:
either 8 bytes of slave unique id in host order,
or master's id, which is assigned to bus master device
diff --git a/Documentation/watchdog/watchdog-kernel-api.rst b/Documentation/watchdog/watchdog-kernel-api.rst
index baf44e9..243231f 100644
--- a/Documentation/watchdog/watchdog-kernel-api.rst
+++ b/Documentation/watchdog/watchdog-kernel-api.rst
@@ -77,7 +77,7 @@
* groups: List of sysfs attribute groups to create when creating the watchdog
device.
* info: a pointer to a watchdog_info structure. This structure gives some
- additional information about the watchdog timer itself. (Like it's unique name)
+ additional information about the watchdog timer itself. (Like its unique name)
* ops: a pointer to the list of watchdog operations that the watchdog supports.
* gov: a pointer to the assigned watchdog device pretimeout governor or NULL.
* timeout: the watchdog timer's timeout value (in seconds).
diff --git a/Documentation/wmi/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst
index bf963d9..2fcdfcf 100644
--- a/Documentation/wmi/devices/dell-wmi-ddv.rst
+++ b/Documentation/wmi/devices/dell-wmi-ddv.rst
@@ -185,7 +185,7 @@
WMI method BatteryeRawAnalytics()
---------------------------------
-Returns a buffer usually containg 12 blocks of analytics data.
+Returns a buffer usually containing 12 blocks of analytics data.
Those blocks contain:
- a block number starting with 0 (u8)
@@ -218,7 +218,7 @@
WMI method FanSensorInformation()
---------------------------------
-Returns a buffer containg fan sensor entries, terminated
+Returns a buffer containing fan sensor entries, terminated
with a single ``0xff``.
Those entries contain:
diff --git a/MAINTAINERS b/MAINTAINERS
index 1131d84..c8fdd0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -915,6 +915,18 @@
F: drivers/crypto/ccp/sev*
F: include/uapi/linux/psp-sev.h
+AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER - DBC SUPPORT
+M: Mario Limonciello <mario.limonciello@amd.com>
+L: linux-crypto@vger.kernel.org
+S: Supported
+F: drivers/crypto/ccp/dbc.c
+F: drivers/crypto/ccp/dbc.h
+F: drivers/crypto/ccp/platform-access.c
+F: drivers/crypto/ccp/platform-access.h
+F: include/uapi/linux/psp-dbc.h
+F: tools/crypto/ccp/*.c
+F: tools/crypto/ccp/*.py
+
AMD DISPLAY CORE
M: Harry Wentland <harry.wentland@amd.com>
M: Leo Li <sunpeng.li@amd.com>
@@ -1006,7 +1018,7 @@
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.c
+F: drivers/platform/x86/amd/pmc/
AMD PMF DRIVER
M: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
@@ -1074,7 +1086,6 @@
AMPHION VPU CODEC V4L2 DRIVER
M: Ming Qian <ming.qian@nxp.com>
-M: Shijie Qin <shijie.qin@nxp.com>
M: Zhou Peng <eagle.zhou@nxp.com>
L: linux-media@vger.kernel.org
S: Maintained
@@ -1558,9 +1569,10 @@
M: soc@kernel.org
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
+P: Documentation/process/maintainer-soc.rst
C: irc://irc.libera.chat/armlinux
T: git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
-F: Documentation/process/maintainer-soc.rst
+F: Documentation/process/maintainer-soc*.rst
F: arch/arm/boot/dts/Makefile
F: arch/arm64/boot/dts/Makefile
@@ -1843,6 +1855,7 @@
F: arch/arm/boot/dts/amlogic/
F: arch/arm/mach-meson/
F: arch/arm64/boot/dts/amlogic/
+F: drivers/genpd/amlogic/
F: drivers/mmc/host/meson*
F: drivers/phy/amlogic/
F: drivers/pinctrl/meson/
@@ -1905,6 +1918,7 @@
F: drivers/clk/clk-apple-nco.c
F: drivers/cpufreq/apple-soc-cpufreq.c
F: drivers/dma/apple-admac.c
+F: drivers/genpd/apple/
F: drivers/i2c/busses/i2c-pasemi-core.c
F: drivers/i2c/busses/i2c-pasemi-platform.c
F: drivers/iommu/apple-dart.c
@@ -2339,7 +2353,7 @@
ARM/MICROCHIP (ARM64) SoC support
M: Conor Dooley <conor@kernel.org>
M: Nicolas Ferre <nicolas.ferre@microchip.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
T: git https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
@@ -2348,7 +2362,7 @@
ARM/Microchip (AT91) SoC support
M: Nicolas Ferre <nicolas.ferre@microchip.com>
M: Alexandre Belloni <alexandre.belloni@bootlin.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
W: http://www.linux4sam.org
@@ -2421,6 +2435,7 @@
F: drivers/clk/clk-nomadik.c
F: drivers/clocksource/clksrc-dbx500-prcmu.c
F: drivers/dma/ste_dma40*
+F: drivers/genpd/st/ste-ux500-pm-domain.c
F: drivers/hwspinlock/u8500_hsem.c
F: drivers/i2c/busses/i2c-nomadik.c
F: drivers/iio/adc/ab8500-gpadc.c
@@ -2493,16 +2508,6 @@
W: http://www.digriz.org.uk/ts78xx/kernel
F: arch/arm/mach-orion5x/ts78xx-*
-ARM/OXNAS platform support
-M: Neil Armstrong <neil.armstrong@linaro.org>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: linux-oxnas@groups.io (moderated for non-subscribers)
-S: Maintained
-F: arch/arm/boot/dts/ox8*.dts*
-F: arch/arm/mach-oxnas/
-F: drivers/power/reset/oxnas-restart.c
-N: oxnas
-
ARM/QUALCOMM CHROMEBOOK SUPPORT
R: cros-qcom-dts-watchers@chromium.org
F: arch/arm64/boot/dts/qcom/sc7180*
@@ -2593,6 +2598,7 @@
F: arch/arm/mach-shmobile/
F: arch/arm64/boot/dts/renesas/
F: arch/riscv/boot/dts/renesas/
+F: drivers/genpd/renesas/
F: drivers/soc/renesas/
F: include/linux/soc/renesas/
K: \brenesas,
@@ -2635,6 +2641,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org
S: Maintained
+P: Documentation/process/maintainer-soc-clean-dts.rst
Q: https://patchwork.kernel.org/project/linux-samsung-soc/list/
B: mailto:linux-samsung-soc@vger.kernel.org
C: irc://irc.libera.chat/linux-exynos
@@ -2929,14 +2936,13 @@
M: Lorenzo Pieralisi <lpieralisi@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: */*/*/vexpress*
-F: */*/vexpress*
-F: arch/arm/boot/dts/arm/vexpress*
+N: mps2
+N: vexpress
F: arch/arm/mach-versatile/
F: arch/arm64/boot/dts/arm/
-F: drivers/clk/versatile/clk-vexpress-osc.c
F: drivers/clocksource/timer-versatile.c
-N: mps2
+X: drivers/cpufreq/vexpress-spc-cpufreq.c
+X: Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
ARM/VFP SUPPORT
M: Russell King <linux@armlinux.org.uk>
@@ -3250,7 +3256,7 @@
ATMEL MACB ETHERNET DRIVER
M: Nicolas Ferre <nicolas.ferre@microchip.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
S: Supported
F: drivers/net/ethernet/cadence/
@@ -3685,6 +3691,7 @@
F: include/linux/tnum.h
F: kernel/bpf/core.c
F: kernel/bpf/dispatcher.c
+F: kernel/bpf/mprog.c
F: kernel/bpf/syscall.c
F: kernel/bpf/tnum.c
F: kernel/bpf/trampoline.c
@@ -3695,7 +3702,7 @@
L: bpf@vger.kernel.org
L: bpf@ietf.org
S: Maintained
-F: Documentation/bpf/instruction-set.rst
+F: Documentation/bpf/standardization/
BPF [GENERAL] (Safe Dynamic Programs and Tools)
M: Alexei Starovoitov <ast@kernel.org>
@@ -3703,7 +3710,7 @@
M: Andrii Nakryiko <andrii@kernel.org>
R: Martin KaFai Lau <martin.lau@linux.dev>
R: Song Liu <song@kernel.org>
-R: Yonghong Song <yhs@fb.com>
+R: Yonghong Song <yonghong.song@linux.dev>
R: John Fastabend <john.fastabend@gmail.com>
R: KP Singh <kpsingh@kernel.org>
R: Stanislav Fomichev <sdf@google.com>
@@ -3742,7 +3749,7 @@
F: tools/testing/selftests/bpf/
BPF [ITERATOR]
-M: Yonghong Song <yhs@fb.com>
+M: Yonghong Song <yonghong.song@linux.dev>
L: bpf@vger.kernel.org
S: Maintained
F: kernel/bpf/*iter.c
@@ -3778,13 +3785,15 @@
S: Maintained
F: kernel/bpf/bpf_struct*
-BPF [NETWORKING] (tc BPF, sock_addr)
+BPF [NETWORKING] (tcx & tc BPF, sock_addr)
M: Martin KaFai Lau <martin.lau@linux.dev>
M: Daniel Borkmann <daniel@iogearbox.net>
R: John Fastabend <john.fastabend@gmail.com>
L: bpf@vger.kernel.org
L: netdev@vger.kernel.org
S: Maintained
+F: include/net/tcx.h
+F: kernel/bpf/tcx.c
F: net/core/filter.c
F: net/sched/act_bpf.c
F: net/sched/cls_bpf.c
@@ -3836,6 +3845,15 @@
F: kernel/bpf/stackmap.c
F: kernel/trace/bpf_trace.c
+BROADCOM ASP 2.0 ETHERNET DRIVER
+M: Justin Chen <justin.chen@broadcom.com>
+M: Florian Fainelli <florian.fainelli@broadcom.com>
+L: bcm-kernel-feedback-list@broadcom.com
+L: netdev@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
+F: drivers/net/ethernet/broadcom/asp2/
+
BROADCOM B44 10/100 ETHERNET DRIVER
M: Michael Chan <michael.chan@broadcom.com>
L: netdev@vger.kernel.org
@@ -4008,7 +4026,7 @@
F: drivers/irqchip/irq-bcm63*
F: drivers/irqchip/irq-bcm7*
F: drivers/irqchip/irq-brcmstb*
-F: drivers/soc/bcm/bcm63xx
+F: drivers/genpd/bcm/bcm63xx-power.c
F: include/linux/bcm963xx_nvram.h
F: include/linux/bcm963xx_tag.h
@@ -4126,7 +4144,7 @@
M: Jonas Gorski <jonas.gorski@gmail.com>
L: linux-spi@vger.kernel.org
S: Odd Fixes
-F: Documentation/devicetree/bindings/spi/spi-bcm63xx.txt
+F: Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml
F: drivers/spi/spi-bcm63xx.c
BROADCOM ETHERNET PHY DRIVERS
@@ -4195,7 +4213,7 @@
M: Ray Jui <rjui@broadcom.com>
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
S: Supported
-F: Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt
+F: Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml
F: drivers/gpio/gpio-bcm-kona.c
BROADCOM MPI3 STORAGE CONTROLLER DRIVER
@@ -4230,7 +4248,7 @@
L: linux-pm@vger.kernel.org
S: Maintained
T: git https://github.com/broadcom/stblinux.git
-F: drivers/soc/bcm/bcm63xx/bcm-pmb.c
+F: drivers/genpd/bcm/bcm-pmb.c
F: include/dt-bindings/soc/bcm-pmb.h
BROADCOM SPECIFIC AMBA DRIVER (BCMA)
@@ -4450,6 +4468,7 @@
L: linux-media@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/cdns,*.txt
+F: Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
F: drivers/media/platform/cadence/cdns-csi2*
CADENCE NAND DRIVER
@@ -4819,6 +4838,7 @@
CHROME HARDWARE PLATFORM SUPPORT
M: Benson Leung <bleung@chromium.org>
+M: Tzung-Bi Shih <tzungbi@kernel.org>
L: chrome-platform@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
@@ -4886,7 +4906,11 @@
L: patches@opensource.cirrus.com
S: Maintained
F: Documentation/devicetree/bindings/sound/cirrus,cs*
+F: drivers/mfd/cs42l43*
+F: drivers/pinctrl/cirrus/pinctrl-cs42l43*
+F: drivers/spi/spi-cs42l43*
F: include/dt-bindings/sound/cs*
+F: include/linux/mfd/cs42l43*
F: include/sound/cs*
F: sound/pci/hda/cs*
F: sound/pci/hda/hda_cs_dsp_ctl.*
@@ -5231,6 +5255,8 @@
F: Documentation/admin-guide/cgroup-v1/cpusets.rst
F: include/linux/cpuset.h
F: kernel/cgroup/cpuset.c
+F: tools/testing/selftests/cgroup/test_cpuset.c
+F: tools/testing/selftests/cgroup/test_cpuset_prs.sh
CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)
M: Johannes Weiner <hannes@cmpxchg.org>
@@ -5369,7 +5395,7 @@
R: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
L: linux-pm@vger.kernel.org
L: linux-samsung-soc@vger.kernel.org
-S: Supported
+S: Maintained
F: arch/arm/mach-exynos/pm.c
F: drivers/cpuidle/cpuidle-exynos.c
F: include/linux/platform_data/cpuidle-exynos.h
@@ -6009,7 +6035,7 @@
F: Documentation/devicetree/bindings/mfd/dlg,da90*.yaml
F: Documentation/devicetree/bindings/regulator/da92*.txt
F: Documentation/devicetree/bindings/regulator/dlg,da9*.yaml
-F: Documentation/devicetree/bindings/regulator/slg51000.txt
+F: Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml
F: Documentation/devicetree/bindings/sound/da[79]*.txt
F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt
@@ -6151,10 +6177,9 @@
DMA-BUF HEAPS FRAMEWORK
M: Sumit Semwal <sumit.semwal@linaro.org>
R: Benjamin Gaignard <benjamin.gaignard@collabora.com>
-R: Liam Mark <lmark@codeaurora.org>
-R: Laura Abbott <labbott@redhat.com>
R: Brian Starkey <Brian.Starkey@arm.com>
R: John Stultz <jstultz@google.com>
+R: T.J. Mercier <tjmercier@google.com>
L: linux-media@vger.kernel.org
L: dri-devel@lists.freedesktop.org
L: linaro-mm-sig@lists.linaro.org (moderated for non-subscribers)
@@ -6214,6 +6239,7 @@
M: Jonathan Corbet <corbet@lwn.net>
L: workflows@vger.kernel.org
S: Maintained
+F: Documentation/maintainer/
F: Documentation/process/
DOCUMENTATION REPORTING ISSUES
@@ -6251,11 +6277,17 @@
F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml
F: drivers/media/i2c/dw9714.c
-DONGWOON DW9768 LENS VOICE COIL DRIVER
-M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+DONGWOON DW9719 LENS VOICE COIL DRIVER
+M: Daniel Scally <djrscally@gmail.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
+F: drivers/media/i2c/dw9719.c
+
+DONGWOON DW9768 LENS VOICE COIL DRIVER
+L: linux-media@vger.kernel.org
+S: Orphan
+T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
F: drivers/media/i2c/dw9768.c
@@ -6396,6 +6428,7 @@
DRM DRIVER FOR AST SERVER GRAPHICS CHIPS
M: Dave Airlie <airlied@redhat.com>
R: Thomas Zimmermann <tzimmermann@suse.de>
+R: Jocelyn Falempe <jfalempe@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -6547,6 +6580,7 @@
DRM DRIVER FOR MGA G200 GRAPHICS CHIPS
M: Dave Airlie <airlied@redhat.com>
R: Thomas Zimmermann <tzimmermann@suse.de>
+R: Jocelyn Falempe <jfalempe@redhat.com>
L: dri-devel@lists.freedesktop.org
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -6946,6 +6980,13 @@
F: drivers/gpu/drm/lima/
F: include/uapi/drm/lima_drm.h
+DRM DRIVERS FOR LOONGSON
+M: Sui Jingfeng <suijingfeng@loongson.cn>
+L: dri-devel@lists.freedesktop.org
+S: Supported
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/loongson/
+
DRM DRIVERS FOR MEDIATEK
M: Chun-Kuang Hu <chunkuang.hu@kernel.org>
M: Philipp Zabel <p.zabel@pengutronix.de>
@@ -7015,7 +7056,7 @@
DRM DRIVERS FOR TI KEYSTONE
M: Jyri Sarha <jyri.sarha@iki.fi>
-M: Tomi Valkeinen <tomba@kernel.org>
+M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -7026,16 +7067,18 @@
DRM DRIVERS FOR TI LCDC
M: Jyri Sarha <jyri.sarha@iki.fi>
-R: Tomi Valkeinen <tomba@kernel.org>
+M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/tilcdc/
F: drivers/gpu/drm/tilcdc/
DRM DRIVERS FOR TI OMAP
-M: Tomi Valkeinen <tomba@kernel.org>
+M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
L: dri-devel@lists.freedesktop.org
S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ti/
F: drivers/gpu/drm/omapdrm/
@@ -7593,6 +7636,13 @@
S: Supported
F: drivers/mmc/host/cqhci*
+EMS CPC-PCI CAN DRIVER
+M: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
+M: support@ems-wuensche.com
+L: linux-can@vger.kernel.org
+S: Maintained
+F: drivers/net/can/sja1000/ems_pci.c
+
EMULEX 10Gbps iSCSI - OneConnect DRIVER
M: Ketan Mukadam <ketan.mukadam@broadcom.com>
L: linux-scsi@vger.kernel.org
@@ -7732,6 +7782,7 @@
F: include/linux/of_net.h
F: include/linux/phy.h
F: include/linux/phy_fixed.h
+F: include/linux/phylib_stubs.h
F: include/linux/platform_data/mdio-bcm-unimac.h
F: include/linux/platform_data/mdio-gpio.h
F: include/trace/events/mdio.h
@@ -8351,7 +8402,6 @@
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/freescale/fs_enet/
-F: include/linux/fs_enet_pd.h
FREESCALE SOC SOUND DRIVERS
M: Shengjiu Wang <shengjiu.wang@gmail.com>
@@ -8402,13 +8452,6 @@
F: include/linux/freezer.h
F: kernel/freezer.c
-FRONTSWAP API
-M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-L: linux-kernel@vger.kernel.org
-S: Maintained
-F: include/linux/frontswap.h
-F: mm/frontswap.c
-
FS-CACHE: LOCAL CACHING FOR NETWORK FILESYSTEMS
M: David Howells <dhowells@redhat.com>
L: linux-cachefs@redhat.com (moderated for non-subscribers)
@@ -8673,6 +8716,13 @@
F: drivers/base/power/domain*.c
F: include/linux/pm_domain.h
+GENERIC PM DOMAIN PROVIDERS
+M: Ulf Hansson <ulf.hansson@linaro.org>
+L: linux-pm@vger.kernel.org
+S: Supported
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git
+F: drivers/genpd/
+
GENERIC RESISTIVE TOUCHSCREEN ADC DRIVER
M: Eugen Hristev <eugen.hristev@microchip.com>
L: linux-input@vger.kernel.org
@@ -8769,6 +8819,15 @@
F: Documentation/networking/device_drivers/ethernet/google/gve.rst
F: drivers/net/ethernet/google
+GOOGLE FIRMWARE DRIVERS
+M: Tzung-Bi Shih <tzungbi@kernel.org>
+R: Brian Norris <briannorris@chromium.org>
+R: Julius Werner <jwerner@chromium.org>
+L: chrome-platform@lists.linux.dev
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
+F: drivers/firmware/google/
+
GPD POCKET FAN DRIVER
M: Hans de Goede <hdegoede@redhat.com>
L: platform-driver-x86@vger.kernel.org
@@ -8812,6 +8871,7 @@
S: Maintained
F: drivers/gpio/gpio-regmap.c
F: include/linux/gpio/regmap.h
+K: (devm_)?gpio_regmap_(un)?register
GPIO SUBSYSTEM
M: Linus Walleij <linus.walleij@linaro.org>
@@ -9305,7 +9365,7 @@
F: drivers/crypto/hisilicon/hpre/hpre_main.c
HISILICON HNS3 PMU DRIVER
-M: Guangbin Huang <huangguangbin2@huawei.com>
+M: Jijie Shao <shaojijie@huawei.com>
S: Supported
F: Documentation/admin-guide/perf/hns3-pmu.rst
F: drivers/perf/hisilicon/hns3_pmu.c
@@ -9318,6 +9378,13 @@
F: Documentation/devicetree/bindings/i2c/hisilicon,ascend910-i2c.yaml
F: drivers/i2c/busses/i2c-hisi.c
+HISILICON KUNPENG SOC HCCS DRIVER
+M: Huisong Li <lihuisong@huawei.com>
+S: Maintained
+F: Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
+F: drivers/soc/hisilicon/kunpeng_hccs.c
+F: drivers/soc/hisilicon/kunpeng_hccs.h
+
HISILICON LPC BUS DRIVER
M: Jay Fang <f.fangjian@huawei.com>
S: Maintained
@@ -9343,7 +9410,7 @@
F: drivers/net/ethernet/hisilicon/
HISILICON PMU DRIVER
-M: Shaokun Zhang <zhangshaokun@hisilicon.com>
+M: Yicong Yang <yangyicong@hisilicon.com>
M: Jonathan Cameron <jonathan.cameron@huawei.com>
S: Supported
W: http://www.hisilicon.com
@@ -9375,7 +9442,6 @@
F: include/linux/hisi_acc_qm.h
HISILICON ROCE DRIVER
-M: Haoyue Xu <xuhaoyue1@hisilicon.com>
M: Junxian Huang <huangjunxian6@hisilicon.com>
L: linux-rdma@vger.kernel.org
S: Maintained
@@ -9464,6 +9530,12 @@
W: http://w1.fi/hostap-driver.html
F: drivers/net/wireless/intersil/hostap/
+HP BIOSCFG DRIVER
+M: Jorge Lopez <jorge.lopez2@hp.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/hp/hp-bioscfg/
+
HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
L: platform-driver-x86@vger.kernel.org
S: Orphan
@@ -9495,6 +9567,12 @@
W: http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/hpfs/index-e.cgi
F: fs/hpfs/
+HS3001 Hardware Temperature and Humidity Sensor
+M: Andre Werner <andre.werner@systec-electronic.com>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: drivers/hwmon/hs3001.c
+
HSI SUBSYSTEM
M: Sebastian Reichel <sre@kernel.org>
S: Maintained
@@ -9598,7 +9676,7 @@
F: arch/x86/kernel/cpu/hygon.c
HYNIX HI556 SENSOR DRIVER
-M: Shawn Tu <shawnx.tu@intel.com>
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
@@ -9611,7 +9689,7 @@
F: drivers/media/i2c/hi846.c
HYNIX HI847 SENSOR DRIVER
-M: Shawn Tu <shawnx.tu@intel.com>
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/i2c/hi847.c
@@ -9682,6 +9760,14 @@
S: Maintained
F: drivers/i2c/i2c-core-acpi.c
+I2C ADDRESS TRANSLATOR (ATR)
+M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+R: Luca Ceresoli <luca.ceresoli@bootlin.com>
+L: linux-i2c@vger.kernel.org
+S: Maintained
+F: drivers/i2c/i2c-atr.c
+F: include/linux/i2c-atr.h
+
I2C CONTROLLER DRIVER FOR NVIDIA GPU
M: Ajay Gupta <ajayg@nvidia.com>
L: linux-i2c@vger.kernel.org
@@ -10738,6 +10824,7 @@
M: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
L: platform-driver-x86@vger.kernel.org
S: Maintained
+F: Documentation/ABI/testing/debugfs-tpmi
F: drivers/platform/x86/intel/tpmi.c
F: include/linux/intel_tpmi.h
@@ -10922,7 +11009,6 @@
F: include/trace/events/io_uring.h
F: include/uapi/linux/io_uring.h
F: io_uring/
-F: tools/io_uring/
IPMI SUBSYSTEM
M: Corey Minyard <minyard@acm.org>
@@ -11296,6 +11382,7 @@
F: scripts/mk*
F: scripts/mod/
F: scripts/package/
+F: usr/
KERNEL HARDENING (not covered by other areas)
M: Kees Cook <keescook@chromium.org>
@@ -11384,6 +11471,8 @@
F: Documentation/dev-tools/kunit/
F: include/kunit/
F: lib/kunit/
+F: rust/kernel/kunit.rs
+F: scripts/rustdoc_test_*
F: tools/testing/kunit/
KERNEL USERMODE HELPER
@@ -12243,8 +12332,8 @@
L: loongarch@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
-F: Documentation/loongarch/
-F: Documentation/translations/zh_CN/loongarch/
+F: Documentation/arch/loongarch/
+F: Documentation/translations/zh_CN/arch/loongarch/
F: arch/loongarch/
F: drivers/*/*loongarch*
@@ -12270,6 +12359,16 @@
F: drivers/clk/clk-loongson2.c
F: include/dt-bindings/clock/loongson,ls2k-clk.h
+LOONGSON SPI DRIVER
+M: Yinbo Zhu <zhuyinbo@loongson.cn>
+L: linux-spi@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml
+F: drivers/spi/spi-loongson-core.c
+F: drivers/spi/spi-loongson-pci.c
+F: drivers/spi/spi-loongson-plat.c
+F: drivers/spi/spi-loongson.h
+
LOONGSON-2 SOC SERIES GUTS DRIVER
M: Yinbo Zhu <zhuyinbo@loongson.cn>
L: loongarch@lists.linux.dev
@@ -12277,6 +12376,13 @@
F: Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml
F: drivers/soc/loongson/loongson2_guts.c
+LOONGSON-2 SOC SERIES PM DRIVER
+M: Yinbo Zhu <zhuyinbo@loongson.cn>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
+F: drivers/soc/loongson/loongson2_pm.c
+
LOONGSON-2 SOC SERIES PINCTRL DRIVER
M: zhanghongchen <zhanghongchen@loongson.cn>
M: Yinbo Zhu <zhuyinbo@loongson.cn>
@@ -12285,6 +12391,14 @@
F: Documentation/devicetree/bindings/pinctrl/loongson,ls2k-pinctrl.yaml
F: drivers/pinctrl/pinctrl-loongson2.c
+LOONGSON-2 SOC SERIES THERMAL DRIVER
+M: zhanghongchen <zhanghongchen@loongson.cn>
+M: Yinbo Zhu <zhuyinbo@loongson.cn>
+L: linux-pm@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
+F: drivers/thermal/loongson2_thermal.c
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash <sathya.prakash@broadcom.com>
M: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
@@ -12480,6 +12594,7 @@
MAPLE TREE
M: Liam R. Howlett <Liam.Howlett@oracle.com>
+L: maple-tree@lists.infradead.org
L: linux-mm@kvack.org
S: Supported
F: Documentation/core-api/maple_tree.rst
@@ -12825,7 +12940,7 @@
MAXIM MUIC CHARGER DRIVERS FOR EXYNOS BASED BOARDS
M: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
L: linux-pm@vger.kernel.org
-S: Supported
+S: Maintained
B: mailto:linux-samsung-soc@vger.kernel.org
F: Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml
F: Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml
@@ -12836,7 +12951,7 @@
M: Chanwoo Choi <cw00.choi@samsung.com>
M: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
L: linux-kernel@vger.kernel.org
-S: Supported
+S: Maintained
B: mailto:linux-samsung-soc@vger.kernel.org
F: Documentation/devicetree/bindings/*/maxim,max14577.yaml
F: Documentation/devicetree/bindings/*/maxim,max77686.yaml
@@ -13004,17 +13119,21 @@
F: include/linux/imx-media.h
F: include/media/imx.h
-MEDIA DRIVERS FOR FREESCALE IMX7
+MEDIA DRIVERS FOR FREESCALE IMX7/8
M: Rui Miguel Silva <rmfrfs@gmail.com>
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+M: Martin Kepplinger <martin.kepplinger@puri.sm>
+R: Purism Kernel Team <kernel@puri.sm>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
F: Documentation/admin-guide/media/imx7.rst
F: Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml
F: Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+F: Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
F: drivers/media/platform/nxp/imx-mipi-csis.c
F: drivers/media/platform/nxp/imx7-media-csi.c
+F: drivers/media/platform/nxp/imx8mq-mipi-csi2.c
MEDIA DRIVERS FOR HELENE
M: Abylay Ospan <aospan@netup.ru>
@@ -13246,6 +13365,7 @@
S: Supported
F: Documentation/devicetree/bindings/iommu/mediatek*
F: drivers/iommu/mtk_iommu*
+F: include/dt-bindings/memory/mediatek,mt*-port.h
F: include/dt-bindings/memory/mt*-port.h
MEDIATEK JPEG DRIVER
@@ -13623,6 +13743,7 @@
F: include/linux/mm.h
F: include/linux/mmzone.h
F: include/linux/pagewalk.h
+F: include/linux/rmap.h
F: include/trace/events/ksm.h
F: mm/
F: tools/mm/
@@ -13786,7 +13907,7 @@
F: drivers/spi/spi-at91-usart.c
MICROCHIP AUDIO ASOC DRIVERS
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/sound/atmel*
@@ -13809,7 +13930,7 @@
F: drivers/crypto/atmel-ecc.*
MICROCHIP EIC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
@@ -13882,7 +14003,7 @@
F: include/video/atmel_lcdc.h
MICROCHIP MCP16502 PMIC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
@@ -13909,7 +14030,7 @@
F: drivers/mtd/nand/raw/atmel/*
MICROCHIP OTPC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
@@ -13917,12 +14038,14 @@
F: include/dt-bindings/nvmem/microchip,sama7g5-otpc.h
MICROCHIP PCI1XXXX GP DRIVER
+M: Vaibhaav Ram T.L <vaibhaavram.tl@microchip.com>
M: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com>
L: linux-gpio@vger.kernel.org
S: Supported
F: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c
F: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.h
F: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c
+F: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c
MICROCHIP PCI1XXXX I2C DRIVER
M: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>
@@ -13948,7 +14071,7 @@
F: drivers/fpga/microchip-spi.c
MICROCHIP PWM DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-pwm@vger.kernel.org
S: Supported
@@ -13964,7 +14087,7 @@
F: include/dt-bindings/iio/adc/at91-sama5d2_adc.h
MICROCHIP SAMA5D2-COMPATIBLE SHUTDOWN CONTROLLER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
S: Supported
F: Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml
F: drivers/power/reset/at91-sama5d2_shdwc.c
@@ -13981,7 +14104,7 @@
F: drivers/spi/spi-atmel.*
MICROCHIP SSC DRIVER
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -14010,7 +14133,7 @@
MICROCHIP WILC1000 WIFI DRIVER
M: Ajay Singh <ajay.kathat@microchip.com>
-M: Claudiu Beznea <claudiu.beznea@microchip.com>
+M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
L: linux-wireless@vger.kernel.org
S: Supported
F: drivers/net/wireless/microchip/wilc1000/
@@ -14168,7 +14291,7 @@
Q: https://patchwork.kernel.org/project/linux-mips/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
F: Documentation/devicetree/bindings/mips/
-F: Documentation/mips/
+F: Documentation/arch/mips/
F: arch/mips/
F: drivers/platform/mips/
F: include/dt-bindings/mips/
@@ -14639,7 +14762,7 @@
F: include/linux/mfd/ntxec.h
NETRONOME ETHERNET DRIVERS
-M: Simon Horman <simon.horman@corigine.com>
+M: Louis Peens <louis.peens@corigine.com>
R: Jakub Kicinski <kuba@kernel.org>
L: oss-drivers@corigine.com
S: Maintained
@@ -14802,6 +14925,16 @@
F: net/netfilter/xt_SECMARK.c
F: net/netlabel/
+NETWORKING [MACSEC]
+M: Sabrina Dubroca <sd@queasysnail.net>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/net/macsec.c
+F: include/net/macsec.h
+F: include/uapi/linux/if_macsec.h
+K: macsec
+K: \bmdo_
+
NETWORKING [MPTCP]
M: Matthieu Baerts <matthieu.baerts@tessares.net>
M: Mat Martineau <martineau@kernel.org>
@@ -14824,7 +14957,6 @@
M: Eric Dumazet <edumazet@google.com>
L: netdev@vger.kernel.org
S: Maintained
-F: include/linux/net_mm.h
F: include/linux/tcp.h
F: include/net/tcp.h
F: include/trace/events/tcp.h
@@ -14987,6 +15119,7 @@
NOLIBC HEADER FILE
M: Willy Tarreau <w@1wt.eu>
+M: Thomas Weißschuh <linux@weissschuh.net>
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git
F: tools/include/nolibc/
@@ -15513,6 +15646,7 @@
W: http://linux.omap.com/
Q: http://patchwork.kernel.org/project/linux-omap/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
+F: Documentation/devicetree/bindings/arm/ti/omap.yaml
F: arch/arm/configs/omap2plus_defconfig
F: arch/arm/mach-omap2/
F: drivers/bus/ti-sysc.c
@@ -15549,7 +15683,7 @@
F: fs/omfs/
OMNIVISION OG01A1B SENSOR DRIVER
-M: Shawn Tu <shawnx.tu@intel.com>
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/i2c/og01a1b.c
@@ -15562,9 +15696,8 @@
F: drivers/media/i2c/ov01a10.c
OMNIVISION OV02A10 SENSOR DRIVER
-M: Dongchun Zhu <dongchun.zhu@mediatek.com>
L: linux-media@vger.kernel.org
-S: Maintained
+S: Orphan
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
F: drivers/media/i2c/ov02a10.c
@@ -15599,6 +15732,7 @@
OMNIVISION OV2680 SENSOR DRIVER
M: Rui Miguel Silva <rmfrfs@gmail.com>
+M: Hans de Goede <hansg@kernel.org>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
@@ -15615,7 +15749,7 @@
OMNIVISION OV2740 SENSOR DRIVER
M: Tianshu Qiu <tian.shu.qiu@intel.com>
-R: Shawn Tu <shawnx.tu@intel.com>
+R: Sakari Ailus <sakari.ailus@linux.intel.com>
R: Bingbu Cao <bingbu.cao@intel.com>
L: linux-media@vger.kernel.org
S: Maintained
@@ -15647,7 +15781,7 @@
F: drivers/media/i2c/ov5647.c
OMNIVISION OV5670 SENSOR DRIVER
-M: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
@@ -15655,7 +15789,7 @@
F: drivers/media/i2c/ov5670.c
OMNIVISION OV5675 SENSOR DRIVER
-M: Shawn Tu <shawnx.tu@intel.com>
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
S: Maintained
T: git git://linuxtv.org/media_tree.git
@@ -15694,9 +15828,8 @@
F: include/media/i2c/ov772x.h
OMNIVISION OV7740 SENSOR DRIVER
-M: Wenyou Yang <wenyou.yang@microchip.com>
L: linux-media@vger.kernel.org
-S: Maintained
+S: Orphan
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
F: drivers/media/i2c/ov7740.c
@@ -16001,7 +16134,7 @@
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/page_pool.rst
-F: include/net/page_pool.h
+F: include/net/page_pool/
F: include/trace/events/page_pool.h
F: net/core/page_pool.c
@@ -16293,6 +16426,7 @@
PCI DRIVER FOR SYNOPSYS DESIGNWARE
M: Jingoo Han <jingoohan1@gmail.com>
M: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
L: linux-pci@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
@@ -17029,7 +17163,7 @@
S: Maintained
W: http://wiki.enneenne.com/index.php/LinuxPPS_support
F: Documentation/ABI/testing/sysfs-pps
-F: Documentation/devicetree/bindings/pps/pps-gpio.txt
+F: Documentation/devicetree/bindings/pps/pps-gpio.yaml
F: Documentation/driver-api/pps.rst
F: drivers/pps/
F: include/linux/pps*.h
@@ -17045,15 +17179,16 @@
PRESSURE STALL INFORMATION (PSI)
M: Johannes Weiner <hannes@cmpxchg.org>
M: Suren Baghdasaryan <surenb@google.com>
+R: Peter Ziljstra <peterz@infradead.org>
S: Maintained
F: include/linux/psi*
F: kernel/sched/psi.c
PRINTK
M: Petr Mladek <pmladek@suse.com>
-M: Sergey Senozhatsky <senozhatsky@chromium.org>
R: Steven Rostedt <rostedt@goodmis.org>
R: John Ogness <john.ogness@linutronix.de>
+R: Sergey Senozhatsky <senozhatsky@chromium.org>
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git
F: include/linux/printk.h
@@ -17152,6 +17287,13 @@
F: include/linux/ptp_cl*
K: (?:\b|_)ptp(?:\b|_)
+PTP MOCKUP CLOCK SUPPORT
+M: Vladimir Oltean <vladimir.oltean@nxp.com>
+L: netdev@vger.kernel.org
+S: Maintained
+F: drivers/ptp/ptp_mock.c
+F: include/linux/ptp_mock.h
+
PTP VIRTUAL CLOCK SUPPORT
M: Yangbo Lu <yangbo.lu@nxp.com>
L: netdev@vger.kernel.org
@@ -17526,7 +17668,7 @@
L: linux-arm-msm@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml
-F: drivers/soc/qcom/cpr.c
+F: drivers/genpd/qcom/cpr.c
QUALCOMM CPUFREQ DRIVER MSM8996/APQ8096
M: Ilia Lin <ilia.lin@kernel.org>
@@ -18010,7 +18152,7 @@
REISERFS FILE SYSTEM
L: reiserfs-devel@vger.kernel.org
-S: Supported
+S: Obsolete
F: fs/reiserfs/
REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
@@ -18508,17 +18650,14 @@
L: linux-wireless@vger.kernel.org
S: Orphan
W: https://wireless.wiki.kernel.org/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
F: drivers/net/wireless/realtek/rtl818x/rtl8180/
RTL8187 WIRELESS DRIVER
-M: Herton Ronaldo Krzesinski <herton@canonical.com>
-M: Hin-Tak Leung <htl10@users.sourceforge.net>
+M: Hin-Tak Leung <hintak.leung@gmail.com>
M: Larry Finger <Larry.Finger@lwfinger.net>
L: linux-wireless@vger.kernel.org
S: Maintained
W: https://wireless.wiki.kernel.org/
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
F: drivers/net/wireless/realtek/rtl818x/rtl8187/
RTL8XXXU WIRELESS DRIVER (rtl8xxxu)
@@ -18554,6 +18693,8 @@
R: Gary Guo <gary@garyguo.net>
R: Björn Roy Baron <bjorn3_gh@protonmail.com>
R: Benno Lossin <benno.lossin@proton.me>
+R: Andreas Hindborg <a.hindborg@samsung.com>
+R: Alice Ryhl <aliceryhl@google.com>
L: rust-for-linux@vger.kernel.org
S: Supported
W: https://github.com/Rust-for-Linux/linux
@@ -18595,7 +18736,7 @@
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git
F: Documentation/driver-api/s390-drivers.rst
-F: Documentation/s390/
+F: Documentation/arch/s390/
F: arch/s390/
F: drivers/s390/
F: drivers/watchdog/diag288_wdt.c
@@ -18656,7 +18797,7 @@
M: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
L: linux-s390@vger.kernel.org
S: Supported
-F: Documentation/s390/pci.rst
+F: Documentation/arch/s390/pci.rst
F: arch/s390/pci/
F: drivers/pci/hotplug/s390_pci_hpc.c
@@ -18673,7 +18814,7 @@
M: Jason Herne <jjherne@linux.ibm.com>
L: linux-s390@vger.kernel.org
S: Supported
-F: Documentation/s390/vfio-ap*
+F: Documentation/arch/s390/vfio-ap*
F: drivers/s390/crypto/vfio_ap*
S390 VFIO-CCW DRIVER
@@ -18683,7 +18824,7 @@
L: linux-s390@vger.kernel.org
L: kvm@vger.kernel.org
S: Supported
-F: Documentation/s390/vfio-ccw.rst
+F: Documentation/arch/s390/vfio-ccw.rst
F: drivers/s390/cio/vfio_ccw*
F: include/uapi/linux/vfio_ccw.h
@@ -18789,7 +18930,7 @@
M: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
L: linux-kernel@vger.kernel.org
L: linux-samsung-soc@vger.kernel.org
-S: Supported
+S: Maintained
B: mailto:linux-samsung-soc@vger.kernel.org
F: Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml
F: Documentation/devicetree/bindings/mfd/samsung,s2m*.yaml
@@ -18861,7 +19002,7 @@
M: Chanwoo Choi <cw00.choi@samsung.com>
R: Alim Akhtar <alim.akhtar@samsung.com>
L: linux-samsung-soc@vger.kernel.org
-S: Supported
+S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/snawrocki/clk.git
F: Documentation/devicetree/bindings/clock/samsung,*.yaml
@@ -19225,13 +19366,6 @@
F: drivers/tty/serdev/
F: include/linux/serdev.h
-SERIAL DRIVERS
-M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-L: linux-serial@vger.kernel.org
-S: Maintained
-F: Documentation/devicetree/bindings/serial/
-F: drivers/tty/serial/
-
SERIAL IR RECEIVER
M: Sean Young <sean@mess.org>
L: linux-media@vger.kernel.org
@@ -19283,7 +19417,6 @@
SGI XP/XPC/XPNET DRIVER
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/
@@ -19402,6 +19535,32 @@
F: drivers/media/usb/siano/
F: drivers/media/usb/siano/
+SIEMENS IPC LED DRIVERS
+M: Gerd Haeussler <gerd.haeussler.ext@siemens.com>
+M: Xing Tong Wu <xingtong.wu@siemens.com>
+M: Tobias Schaffner <tobias.schaffner@siemens.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+F: drivers/leds/simple/
+
+SIEMENS IPC PLATFORM DRIVERS
+M: Gerd Haeussler <gerd.haeussler.ext@siemens.com>
+M: Xing Tong Wu <xingtong.wu@siemens.com>
+M: Tobias Schaffner <tobias.schaffner@siemens.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/siemens/
+F: include/linux/platform_data/x86/simatic-ipc-base.h
+F: include/linux/platform_data/x86/simatic-ipc.h
+
+SIEMENS IPC WATCHDOG DRIVERS
+M: Gerd Haeussler <gerd.haeussler.ext@siemens.com>
+M: Xing Tong Wu <xingtong.wu@siemens.com>
+M: Tobias Schaffner <tobias.schaffner@siemens.com>
+L: linux-watchdog@vger.kernel.org
+S: Maintained
+F: drivers/watchdog/simatic-ipc-wdt.c
+
SIFIVE DRIVERS
M: Palmer Dabbelt <palmer@dabbelt.com>
M: Paul Walmsley <paul.walmsley@sifive.com>
@@ -19594,13 +19753,6 @@
S: Odd Fixes
F: drivers/net/ethernet/smsc/smc91x.*
-SMM665 HARDWARE MONITOR DRIVER
-M: Guenter Roeck <linux@roeck-us.net>
-L: linux-hwmon@vger.kernel.org
-S: Maintained
-F: Documentation/hwmon/smm665.rst
-F: drivers/hwmon/smm665.c
-
SMSC EMC2103 HARDWARE MONITOR DRIVER
M: Steve Glendinning <steve.glendinning@shawell.net>
L: linux-hwmon@vger.kernel.org
@@ -20277,12 +20429,31 @@
F: Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
F: drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+STARFIVE JH7110 DPHY RX DRIVER
+M: Jack Zhu <jack.zhu@starfivetech.com>
+M: Changhuang Liang <changhuang.liang@starfivetech.com>
+S: Supported
+F: Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml
+F: drivers/phy/starfive/phy-jh7110-dphy-rx.c
+
STARFIVE JH7110 MMC/SD/SDIO DRIVER
M: William Qiu <william.qiu@starfivetech.com>
S: Supported
F: Documentation/devicetree/bindings/mmc/starfive*
F: drivers/mmc/host/dw_mmc-starfive.c
+STARFIVE JH7110 PLL CLOCK DRIVER
+M: Xingyu Wu <xingyu.wu@starfivetech.com>
+S: Supported
+F: Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml
+F: drivers/clk/starfive/clk-starfive-jh7110-pll.c
+
+STARFIVE JH7110 SYSCON
+M: William Qiu <william.qiu@starfivetech.com>
+M: Xingyu Wu <xingyu.wu@starfivetech.com>
+S: Supported
+F: Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
+
STARFIVE JH7110 TDM DRIVER
M: Walker Chen <walker.chen@starfivetech.com>
S: Maintained
@@ -20325,13 +20496,14 @@
M: Walker Chen <walker.chen@starfivetech.com>
S: Supported
F: Documentation/devicetree/bindings/power/starfive*
-F: drivers/soc/starfive/jh71xx_pmu.c
+F: drivers/genpd/starfive/jh71xx-pmu.c
F: include/dt-bindings/power/starfive,jh7110-pmu.h
STARFIVE SOC DRIVERS
M: Conor Dooley <conor@kernel.org>
S: Maintained
T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
+F: Documentation/devicetree/bindings/soc/starfive/
F: drivers/soc/starfive/
STARFIVE TRNG DRIVER
@@ -20347,6 +20519,14 @@
F: Documentation/devicetree/bindings/watchdog/starfive*
F: drivers/watchdog/starfive-wdt.c
+STARFIVE JH71X0 PCIE AND USB PHY DRIVER
+M: Minda Chen <minda.chen@starfivetech.com>
+S: Supported
+F: Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml
+F: Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
+F: drivers/phy/starfive/phy-jh7110-pcie.c
+F: drivers/phy/starfive/phy-jh7110-usb.c
+
STATIC BRANCH/CALL
M: Peter Zijlstra <peterz@infradead.org>
M: Josh Poimboeuf <jpoimboe@kernel.org>
@@ -21060,6 +21240,39 @@
F: Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
F: sound/soc/ti/
+TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS
+M: Shenghao Ding <shenghao-ding@ti.com>
+M: Kevin Lu <kevin-lu@ti.com>
+M: Baojun Xu <x1077012@ti.com>
+L: alsa-devel@alsa-project.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/sound/tas2552.txt
+F: Documentation/devicetree/bindings/sound/tas2562.yaml
+F: Documentation/devicetree/bindings/sound/tas2770.yaml
+F: Documentation/devicetree/bindings/sound/tas27xx.yaml
+F: Documentation/devicetree/bindings/sound/ti,pcm1681.txt
+F: Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml
+F: Documentation/devicetree/bindings/sound/ti,tlv320*.yaml
+F: Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
+F: Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
+F: Documentation/devicetree/bindings/sound/tpa6130a2.txt
+F: include/sound/tas2*.h
+F: include/sound/tlv320*.h
+F: include/sound/tpa6130a2-plat.h
+F: sound/pci/hda/tas2781_hda_i2c.c
+F: sound/soc/codecs/pcm1681.c
+F: sound/soc/codecs/pcm1789*.*
+F: sound/soc/codecs/pcm179x*.*
+F: sound/soc/codecs/pcm186x*.*
+F: sound/soc/codecs/pcm3008.*
+F: sound/soc/codecs/pcm3060*.*
+F: sound/soc/codecs/pcm3168a*.*
+F: sound/soc/codecs/pcm5102a.c
+F: sound/soc/codecs/pcm512x*.*
+F: sound/soc/codecs/tas2*.*
+F: sound/soc/codecs/tlv320*.*
+F: sound/soc/codecs/tpa6130a2.*
+
TEXAS INSTRUMENTS DMA DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: dmaengine@vger.kernel.org
@@ -21108,7 +21321,7 @@
F: drivers/irqchip/irq-ti-sci-intr.c
F: drivers/reset/reset-ti-sci.c
F: drivers/soc/ti/ti_sci_inta_msi.c
-F: drivers/soc/ti/ti_sci_pm_domains.c
+F: drivers/genpd/ti/ti_sci_pm_domains.c
F: include/dt-bindings/soc/ti,sci_pm_domain.h
F: include/linux/soc/ti/ti_sci_inta_msi.h
F: include/linux/soc/ti/ti_sci_protocol.h
@@ -21335,6 +21548,14 @@
F: drivers/mmc/host/tifm_sd.c
F: include/linux/tifm.h
+TI FPD-LINK DRIVERS
+M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/ti,ds90*
+F: drivers/media/i2c/ds90*
+F: include/media/i2c/ds90*
+
TI KEYSTONE MULTICORE NAVIGATOR DRIVERS
M: Nishanth Menon <nm@ti.com>
M: Santosh Shilimkar <ssantosh@kernel.org>
@@ -21342,6 +21563,7 @@
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
+F: drivers/genpd/ti/omap_prm.c
F: drivers/soc/ti/*
TI LM49xxx FAMILY ASoC CODEC DRIVERS
@@ -21584,6 +21806,20 @@
F: Documentation/hwmon/tps546d24.rst
F: drivers/hwmon/pmbus/tps546d24.c
+TQ SYSTEMS BOARD & DRIVER SUPPORT
+L: linux@ew.tq-group.com
+S: Supported
+W: https://www.tq-group.com/en/products/tq-embedded/
+F: arch/arm/boot/dts/imx*mba*.dts*
+F: arch/arm/boot/dts/imx*tqma*.dts*
+F: arch/arm/boot/dts/mba*.dtsi
+F: arch/arm64/boot/dts/freescale/imx*mba*.dts*
+F: arch/arm64/boot/dts/freescale/imx*tqma*.dts*
+F: arch/arm64/boot/dts/freescale/mba*.dtsi
+F: drivers/gpio/gpio-tqmx86.c
+F: drivers/mfd/tqmx86.c
+F: drivers/watchdog/tqmx86_wdt.c
+
TRACING
M: Steven Rostedt <rostedt@goodmis.org>
M: Masami Hiramatsu <mhiramat@kernel.org>
@@ -21629,27 +21865,22 @@
F: kernel/trace/trace_sched_wakeup.c
TRADITIONAL CHINESE DOCUMENTATION
-M: Hu Haowen <src.res@email.cn>
-L: linux-doc-tw-discuss@lists.sourceforge.net (moderated for non-subscribers)
+M: Hu Haowen <src.res.211@gmail.com>
S: Maintained
W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
-TTY LAYER
+TTY LAYER AND SERIAL DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
L: linux-kernel@vger.kernel.org
L: linux-serial@vger.kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
+F: Documentation/devicetree/bindings/serial/
F: Documentation/driver-api/serial/
F: drivers/tty/
-F: drivers/tty/serial/serial_base.h
-F: drivers/tty/serial/serial_base_bus.c
-F: drivers/tty/serial/serial_core.c
-F: drivers/tty/serial/serial_ctrl.c
-F: drivers/tty/serial/serial_port.c
F: include/linux/selection.h
F: include/linux/serial.h
F: include/linux/serial_core.h
@@ -21798,7 +22029,7 @@
F: fs/ufs/
UHID USERSPACE HID IO DRIVER
-M: David Rheinsberg <david.rheinsberg@gmail.com>
+M: David Rheinsberg <david@readahead.eu>
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/uhid.c
@@ -22283,6 +22514,39 @@
S: Maintained
F: drivers/clk/ux500/
+V4L2 ASYNC AND FWNODE FRAMEWORKS
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: drivers/media/v4l2-core/v4l2-async.c
+F: drivers/media/v4l2-core/v4l2-fwnode.c
+F: include/media/v4l2-async.h
+F: include/media/v4l2-fwnode.h
+
+V4L2 LENS DRIVERS
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/ak*
+F: drivers/media/i2c/dw*
+F: drivers/media/i2c/lm*
+
+V4L2 CAMERA SENSOR DRIVERS
+M: Sakari Ailus <sakari.ailus@linux.intel.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/driver-api/media/camera-sensor.rst
+F: Documentation/driver-api/media/tx-rx.rst
+F: drivers/media/i2c/ar*
+F: drivers/media/i2c/hi*
+F: drivers/media/i2c/imx*
+F: drivers/media/i2c/mt*
+F: drivers/media/i2c/og*
+F: drivers/media/i2c/ov*
+F: drivers/media/i2c/s5*
+F: drivers/media/i2c/st-vgxy61.c
+
VF610 NAND DRIVER
M: Stefan Agner <stefan@agner.ch>
L: linux-mtd@lists.infradead.org
@@ -22353,6 +22617,13 @@
P: Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst
F: drivers/vfio/pci/*/
+VFIO PDS PCI DRIVER
+M: Brett Creeley <brett.creeley@amd.com>
+L: kvm@vger.kernel.org
+S: Maintained
+F: Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst
+F: drivers/vfio/pci/pds/
+
VFIO PLATFORM DRIVER
M: Eric Auger <eric.auger@redhat.com>
L: kvm@vger.kernel.org
@@ -22476,7 +22747,6 @@
S: Maintained
F: drivers/block/virtio_blk.c
F: drivers/scsi/virtio_scsi.c
-F: drivers/vhost/scsi.c
F: include/uapi/linux/virtio_blk.h
F: include/uapi/linux/virtio_scsi.h
@@ -22575,6 +22845,16 @@
F: include/uapi/linux/vhost.h
F: kernel/vhost_task.c
+VIRTIO HOST (VHOST-SCSI)
+M: "Michael S. Tsirkin" <mst@redhat.com>
+M: Jason Wang <jasowang@redhat.com>
+M: Mike Christie <michael.christie@oracle.com>
+R: Paolo Bonzini <pbonzini@redhat.com>
+R: Stefan Hajnoczi <stefanha@redhat.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/vhost/scsi.c
+
VIRTIO I2C DRIVER
M: Conghui Chen <conghui.chen@intel.com>
M: Viresh Kumar <viresh.kumar@linaro.org>
@@ -22816,9 +23096,9 @@
VSPRINTF
M: Petr Mladek <pmladek@suse.com>
M: Steven Rostedt <rostedt@goodmis.org>
-M: Sergey Senozhatsky <senozhatsky@chromium.org>
R: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
R: Rasmus Villemoes <linux@rasmusvillemoes.dk>
+R: Sergey Senozhatsky <senozhatsky@chromium.org>
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git
F: Documentation/core-api/printk-formats.rst
@@ -22892,6 +23172,7 @@
W: https://www.net-swift.com
F: Documentation/networking/device_drivers/ethernet/wangxun/*
F: drivers/net/ethernet/wangxun/
+F: drivers/net/pcs/pcs-xpcs-wx.c
WATCHDOG DEVICE DRIVERS
M: Wim Van Sebroeck <wim@linux-watchdog.org>
@@ -22920,7 +23201,7 @@
F: drivers/rtc/rtc-sd3078.c
WIIMOTE HID DRIVER
-M: David Rheinsberg <david.rheinsberg@gmail.com>
+M: David Rheinsberg <david@readahead.eu>
L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/hid-wiimote*
@@ -22966,8 +23247,10 @@
F: drivers/net/wireless/legacy/wl3501*
WMI BINARY MOF DRIVER
-L: platform-drivers-x86@vger.kernel.org
-S: Orphan
+M: Armin Wolf <W_Armin@gmx.de>
+R: Thomas Weißschuh <linux@weissschuh.net>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
F: Documentation/ABI/stable/sysfs-platform-wmi-bmof
F: Documentation/wmi/devices/wmi-bmof.rst
F: drivers/platform/x86/wmi-bmof.c
@@ -23142,7 +23425,8 @@
X86 PLATFORM UV HPE SUPERDOME FLEX
M: Steve Wahl <steve.wahl@hpe.com>
-R: Mike Travis <mike.travis@hpe.com>
+R: Justin Ernst <justin.ernst@hpe.com>
+R: Kyle Meyer <kyle.meyer@hpe.com>
R: Dimitri Sivanich <dimitri.sivanich@hpe.com>
R: Russ Anderson <russ.anderson@hpe.com>
S: Supported
@@ -23329,12 +23613,14 @@
F: include/xen/swiotlb-xen.h
XFS FILESYSTEM
-M: Darrick J. Wong <djwong@kernel.org>
+M: Chandan Babu R <chandan.babu@oracle.com>
+R: Darrick J. Wong <djwong@kernel.org>
L: linux-xfs@vger.kernel.org
S: Supported
W: http://xfs.org/
C: irc://irc.oftc.net/xfs
T: git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git
+P: Documentation/filesystems/xfs-maintainer-entry-profile.rst
F: Documentation/ABI/testing/sysfs-fs-xfs
F: Documentation/admin-guide/xfs.rst
F: Documentation/filesystems/xfs-delayed-logging-design.rst
diff --git a/Makefile b/Makefile
index 6bbf9db..73f23fa 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
VERSION = 6
PATCHLEVEL = 5
SUBLEVEL = 0
-EXTRAVERSION = -rc5
+EXTRAVERSION =
NAME = Hurr durr I'ma ninja sloth
# *DOCUMENTATION*
@@ -280,8 +280,8 @@
# Installation targets should not require compiler. Unfortunately, vdso_install
# is an exception where build artifacts may be updated. This must be fixed.
no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
- headers_install modules_install kernelrelease image_name
-no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
+ headers_install modules_install modules_sign kernelrelease image_name
+no-sync-config-targets := $(no-dot-config-targets) %install modules_sign kernelrelease \
image_name
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.rsi %.s %.symtypes %/
@@ -467,6 +467,7 @@
-Dclippy::let_unit_value -Dclippy::mut_mut \
-Dclippy::needless_bitwise_bool \
-Dclippy::needless_continue \
+ -Dclippy::no_mangle_with_rust_abi \
-Wclippy::dbg_macro
KBUILD_HOSTCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
@@ -509,7 +510,6 @@
YACC = bison
AWK = awk
INSTALLKERNEL := installkernel
-DEPMOD = depmod
PERL = perl
PYTHON3 = python3
CHECK = sparse
@@ -563,14 +563,6 @@
KBUILD_CFLAGS += -fno-common
KBUILD_CFLAGS += -fno-PIE
KBUILD_CFLAGS += -fno-strict-aliasing
-KBUILD_CFLAGS += -Wall
-KBUILD_CFLAGS += -Wundef
-KBUILD_CFLAGS += -Werror=implicit-function-declaration
-KBUILD_CFLAGS += -Werror=implicit-int
-KBUILD_CFLAGS += -Werror=return-type
-KBUILD_CFLAGS += -Werror=strict-prototypes
-KBUILD_CFLAGS += -Wno-format-security
-KBUILD_CFLAGS += -Wno-trigraphs
KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_RUSTFLAGS := $(rust_common_flags) \
@@ -823,10 +815,6 @@
endif # need-config
KBUILD_CFLAGS += -fno-delete-null-pointer-checks
-KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
-KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
-KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
-KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
KBUILD_CFLAGS += -O2
@@ -857,40 +845,15 @@
KBUILD_CFLAGS += -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining
endif
-ifneq ($(CONFIG_FRAME_WARN),0)
-KBUILD_CFLAGS += -Wframe-larger-than=$(CONFIG_FRAME_WARN)
-endif
-
stackp-flags-y := -fno-stack-protector
stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector
stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong
KBUILD_CFLAGS += $(stackp-flags-y)
-KBUILD_CPPFLAGS-$(CONFIG_WERROR) += -Werror
-KBUILD_CPPFLAGS += $(KBUILD_CPPFLAGS-y)
-KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
-
KBUILD_RUSTFLAGS-$(CONFIG_WERROR) += -Dwarnings
KBUILD_RUSTFLAGS += $(KBUILD_RUSTFLAGS-y)
-ifdef CONFIG_CC_IS_CLANG
-# The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable.
-KBUILD_CFLAGS += -Wno-gnu
-else
-
-# gcc inanely warns about local variables called 'main'
-KBUILD_CFLAGS += -Wno-main
-endif
-
-# These warnings generated too much noise in a regular build.
-# Use make W=1 to enable them (see scripts/Makefile.extrawarn)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
-
-# These result in bogus false positives
-KBUILD_CFLAGS += $(call cc-disable-warning, dangling-pointer)
-
ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
KBUILD_RUSTFLAGS += -Cforce-frame-pointers=y
@@ -1025,51 +988,12 @@
# arch Makefile may override CC so keep this after arch Makefile is included
NOSTDINC_FLAGS += -nostdinc
-# Variable Length Arrays (VLAs) should not be used anywhere in the kernel
-KBUILD_CFLAGS += -Wvla
-
-# disable pointer signed / unsigned warnings in gcc 4.0
-KBUILD_CFLAGS += -Wno-pointer-sign
-
-# In order to make sure new function cast mismatches are not introduced
-# in the kernel (to avoid tripping CFI checking), the kernel should be
-# globally built with -Wcast-function-type.
-KBUILD_CFLAGS += $(call cc-option, -Wcast-function-type)
-
# To gain proper coverage for CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE,
# the kernel uses only C99 flexible arrays for dynamically sized trailing
# arrays. Enforce this for everything that may examine structure sizes and
# perform bounds checking.
KBUILD_CFLAGS += $(call cc-option, -fstrict-flex-arrays=3)
-# disable stringop warnings in gcc 8+
-KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
-
-# We'll want to enable this eventually, but it's not going away for 5.7 at least
-KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
-
-# Another good warning that we'll want to enable eventually
-KBUILD_CFLAGS += $(call cc-disable-warning, restrict)
-
-# Enabled with W=2, disabled by default as noisy
-ifdef CONFIG_CC_IS_GCC
-KBUILD_CFLAGS += -Wno-maybe-uninitialized
-endif
-
-# The allocators already balk at large sizes, so silence the compiler
-# warnings for bounds checks involving those possible values. While
-# -Wno-alloc-size-larger-than would normally be used here, earlier versions
-# of gcc (<9.1) weirdly don't handle the option correctly when _other_
-# warnings are produced (?!). Using -Walloc-size-larger-than=SIZE_MAX
-# doesn't work (as it is documented to), silently resolving to "0" prior to
-# version 9.1 (and producing an error more recently). Numeric values larger
-# than PTRDIFF_MAX also don't work prior to version 9.1, which are silently
-# ignored, continuing to default to PTRDIFF_MAX. So, left with no other
-# choice, we must perform a versioned check to disable this warning.
-# https://lore.kernel.org/lkml/20210824115859.187f272f@canb.auug.org.au
-KBUILD_CFLAGS-$(call gcc-min-version, 90100) += -Wno-alloc-size-larger-than
-KBUILD_CFLAGS += $(KBUILD_CFLAGS-y) $(CONFIG_CC_IMPLICIT_FALLTHROUGH)
-
# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += -fno-strict-overflow
@@ -1081,15 +1005,6 @@
KBUILD_CFLAGS += -fconserve-stack
endif
-# Prohibit date/time macros, which would make the build non-deterministic
-KBUILD_CFLAGS += -Werror=date-time
-
-# enforce correct pointer usage
-KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
-
-# Require designated initializers for all marked structures
-KBUILD_CFLAGS += $(call cc-option,-Werror=designated-init)
-
# change __FILE__ to the relative path from the srctree
KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
@@ -1289,7 +1204,7 @@
# All the preparing..
prepare: prepare0
ifdef CONFIG_RUST
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh -v
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
$(Q)$(MAKE) $(build)=rust
endif
@@ -1547,44 +1462,8 @@
modules_prepare: prepare
$(Q)$(MAKE) $(build)=scripts scripts/module.lds
-export modules_sign_only :=
-
-ifeq ($(CONFIG_MODULE_SIG),y)
-PHONY += modules_sign
-modules_sign: modules_install
- @:
-
-# modules_sign is a subset of modules_install.
-# 'make modules_install modules_sign' is equivalent to 'make modules_install'.
-ifeq ($(filter modules_install,$(MAKECMDGOALS)),)
-modules_sign_only := y
-endif
-endif
-
endif # CONFIG_MODULES
-modinst_pre :=
-ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
-modinst_pre := __modinst_pre
-endif
-
-modules_install: $(modinst_pre)
-PHONY += __modinst_pre
-__modinst_pre:
- @rm -rf $(MODLIB)/kernel
- @rm -f $(MODLIB)/source
- @mkdir -p $(MODLIB)
-ifdef CONFIG_MODULES
- @ln -s $(abspath $(srctree)) $(MODLIB)/source
- @if [ ! $(objtree) -ef $(MODLIB)/build ]; then \
- rm -f $(MODLIB)/build ; \
- ln -s $(CURDIR) $(MODLIB)/build ; \
- fi
- @sed 's:^\(.*\)\.o$$:kernel/\1.ko:' modules.order > $(MODLIB)/modules.order
-endif
- @cp -f modules.builtin $(MODLIB)/
- @cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
-
###
# Cleaning is done on three levels.
# make clean Delete most generated files
@@ -1593,7 +1472,7 @@
# make distclean Remove editor backup files, patch leftover files and the like
# Directories & files removed with 'make clean'
-CLEAN_FILES += include/ksym vmlinux.symvers modules-only.symvers \
+CLEAN_FILES += vmlinux.symvers modules-only.symvers \
modules.builtin modules.builtin.modinfo modules.nsdeps \
compile_commands.json .thinlto-cache rust/test rust/doc \
rust-project.json .vmlinux.objs .vmlinux.export.c
@@ -1607,7 +1486,7 @@
certs/signing_key.pem \
certs/x509.genkey \
vmlinux-gdb.py \
- *.spec rpmbuild \
+ kernel.spec rpmbuild \
rust/libmacros.so
# clean - Delete most, but leave enough to build external modules
@@ -1674,7 +1553,6 @@
@echo ' mrproper - Remove all generated files + config + various backup files'
@echo ' distclean - mrproper + remove editor backup and patch files'
@echo ''
- @echo 'Configuration targets:'
@$(MAKE) -f $(srctree)/scripts/kconfig/Makefile help
@echo ''
@echo 'Other generic targets:'
@@ -1825,7 +1703,7 @@
# "Is Rust available?" target
PHONY += rustavailable
rustavailable:
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh -v && echo "Rust is available!"
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh && echo "Rust is available!"
# Documentation target
#
@@ -1859,11 +1737,6 @@
rustfmtcheck: rustfmt_flags = --check
rustfmtcheck: rustfmt
-# IDE support targets
-PHONY += rust-analyzer
-rust-analyzer:
- $(Q)$(MAKE) $(build)=rust $@
-
# Misc
# ---------------------------------------------------------------------------
@@ -1924,21 +1797,42 @@
@echo ' modules - default target, build the module(s)'
@echo ' modules_install - install the module'
@echo ' clean - remove generated files in module directory only'
+ @echo ' rust-analyzer - generate rust-project.json rust-analyzer support file'
@echo ''
+ifndef CONFIG_MODULES
+modules modules_install: __external_modules_error
__external_modules_error:
@echo >&2 '***'
@echo >&2 '*** The present kernel disabled CONFIG_MODULES.'
@echo >&2 '*** You cannot build or install external modules.'
@echo >&2 '***'
@false
+endif
endif # KBUILD_EXTMOD
# ---------------------------------------------------------------------------
# Modules
-PHONY += modules modules_install modules_prepare
+PHONY += modules modules_install modules_sign modules_prepare
+
+modules_install:
+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst \
+ sign-only=$(if $(filter modules_install,$(MAKECMDGOALS)),,y)
+
+ifeq ($(CONFIG_MODULE_SIG),y)
+# modules_sign is a subset of modules_install.
+# 'make modules_install modules_sign' is equivalent to 'make modules_install'.
+modules_sign: modules_install
+ @:
+else
+modules_sign:
+ @echo >&2 '***'
+ @echo >&2 '*** CONFIG_MODULE_SIG is disabled. You cannot sign modules.'
+ @echo >&2 '***'
+ @false
+endif
ifdef CONFIG_MODULES
@@ -1956,22 +1850,9 @@
modules_check: $(MODORDER)
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh $<
-quiet_cmd_depmod = DEPMOD $(MODLIB)
- cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
- $(KERNELRELEASE)
-
-modules_install:
- $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
- $(call cmd,depmod)
-
else # CONFIG_MODULES
-# Modules not configured
-# ---------------------------------------------------------------------------
-
-PHONY += __external_modules_error
-
-modules modules_install: __external_modules_error
+modules:
@:
KBUILD_MODULES :=
@@ -2065,6 +1946,11 @@
tags TAGS cscope gtags: FORCE
$(call cmd,tags)
+# IDE support targets
+PHONY += rust-analyzer
+rust-analyzer:
+ $(Q)$(MAKE) $(build)=rust $@
+
# Script to generate missing namespace dependencies
# ---------------------------------------------------------------------------
@@ -2145,6 +2031,10 @@
image_name:
@echo $(KBUILD_IMAGE)
+PHONY += run-command
+run-command:
+ $(Q)$(KBUILD_RUN_COMMAND)
+
quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard $(rm-files)))
cmd_rmfiles = rm -rf $(rm-files)
diff --git a/arch/Kconfig b/arch/Kconfig
index aff2746..12d5149 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -11,19 +11,6 @@
menu "General architecture-dependent options"
-config CRASH_CORE
- bool
-
-config KEXEC_CORE
- select CRASH_CORE
- bool
-
-config KEXEC_ELF
- bool
-
-config HAVE_IMA_KEXEC
- bool
-
config ARCH_HAS_SUBPAGE_FAULTS
bool
help
@@ -34,6 +21,9 @@
config HOTPLUG_SMT
bool
+config SMT_NUM_THREADS_DYNAMIC
+ bool
+
# Selected by HOTPLUG_CORE_SYNC_DEAD or HOTPLUG_CORE_SYNC_FULL
config HOTPLUG_CORE_SYNC
bool
@@ -745,7 +735,9 @@
depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
depends on ARCH_SUPPORTS_LTO_CLANG
depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT
- depends on !KASAN || KASAN_HW_TAGS
+ # https://github.com/ClangBuiltLinux/linux/issues/1721
+ depends on (!KASAN || KASAN_HW_TAGS || CLANG_VERSION >= 170000) || !DEBUG_INFO
+ depends on (!KCOV || CLANG_VERSION >= 170000) || !DEBUG_INFO
depends on !GCOV_KERNEL
help
The compiler and Kconfig options support building with Clang's
@@ -939,6 +931,14 @@
config ARCH_WANT_HUGE_PMD_SHARE
bool
+# Archs that want to use pmd_mkwrite on kernel memory need it defined even
+# if there are no userspace memory management features that use it
+config ARCH_WANT_KERNEL_PMD_MKWRITE
+ bool
+
+config ARCH_WANT_PMD_MKWRITE
+ def_bool TRANSPARENT_HUGEPAGE || ARCH_WANT_KERNEL_PMD_MKWRITE
+
config HAVE_ARCH_SOFT_DIRTY
bool
diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index dd31e97..396caec 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch/alpha/include/asm/Kbuild
@@ -3,6 +3,5 @@
generated-y += syscall_table.h
generic-y += agp.h
generic-y += asm-offsets.h
-generic-y += export.h
generic-y += kvm_para.h
generic-y += mcs_spinlock.h
diff --git a/arch/alpha/include/asm/cacheflush.h b/arch/alpha/include/asm/cacheflush.h
index 9945ff4..36a7e92 100644
--- a/arch/alpha/include/asm/cacheflush.h
+++ b/arch/alpha/include/asm/cacheflush.h
@@ -53,9 +53,16 @@ extern void flush_icache_user_page(struct vm_area_struct *vma,
#define flush_icache_user_page flush_icache_user_page
#endif /* CONFIG_SMP */
-/* This is used only in __do_fault and do_swap_page. */
-#define flush_icache_page(vma, page) \
- flush_icache_user_page((vma), (page), 0, 0)
+/*
+ * Both implementations of flush_icache_user_page flush the entire
+ * address space, so one call, no matter how many pages.
+ */
+static inline void flush_icache_pages(struct vm_area_struct *vma,
+ struct page *page, unsigned int nr)
+{
+ flush_icache_user_page(vma, page, 0, 0);
+}
+#define flush_icache_pages flush_icache_pages
#include <asm-generic/cacheflush.h>
diff --git a/arch/alpha/include/asm/pci.h b/arch/alpha/include/asm/pci.h
index 6312656..6c04fcb 100644
--- a/arch/alpha/include/asm/pci.h
+++ b/arch/alpha/include/asm/pci.h
@@ -88,7 +88,4 @@ extern void pci_adjust_legacy_attr(struct pci_bus *bus,
enum pci_mmap_state mmap_type);
#define HAVE_PCI_LEGACY 1
-extern int pci_create_resource_files(struct pci_dev *dev);
-extern void pci_remove_resource_files(struct pci_dev *dev);
-
#endif /* __ALPHA_PCI_H */
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index ba43cb8..635f0a5 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -26,7 +26,6 @@ struct vm_area_struct;
* hook is made available.
*/
#define set_pte(pteptr, pteval) ((*(pteptr)) = (pteval))
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
/* PMD_SHIFT determines the size of the area a second-level page table can map */
#define PMD_SHIFT (PAGE_SHIFT + (PAGE_SHIFT-3))
@@ -189,7 +188,8 @@ extern unsigned long __zero_page(void);
* and a page entry and page directory to the page they refer to.
*/
#define page_to_pa(page) (page_to_pfn(page) << PAGE_SHIFT)
-#define pte_pfn(pte) (pte_val(pte) >> 32)
+#define PFN_PTE_SHIFT 32
+#define pte_pfn(pte) (pte_val(pte) >> PFN_PTE_SHIFT)
#define pte_page(pte) pfn_to_page(pte_pfn(pte))
#define mk_pte(page, pgprot) \
@@ -256,7 +256,7 @@ extern inline int pte_young(pte_t pte) { return pte_val(pte) & _PAGE_ACCESSED;
extern inline pte_t pte_wrprotect(pte_t pte) { pte_val(pte) |= _PAGE_FOW; return pte; }
extern inline pte_t pte_mkclean(pte_t pte) { pte_val(pte) &= ~(__DIRTY_BITS); return pte; }
extern inline pte_t pte_mkold(pte_t pte) { pte_val(pte) &= ~(__ACCESS_BITS); return pte; }
-extern inline pte_t pte_mkwrite(pte_t pte) { pte_val(pte) &= ~_PAGE_FOW; return pte; }
+extern inline pte_t pte_mkwrite_novma(pte_t pte){ pte_val(pte) &= ~_PAGE_FOW; return pte; }
extern inline pte_t pte_mkdirty(pte_t pte) { pte_val(pte) |= __DIRTY_BITS; return pte; }
extern inline pte_t pte_mkyoung(pte_t pte) { pte_val(pte) |= __ACCESS_BITS; return pte; }
@@ -303,6 +303,12 @@ extern inline void update_mmu_cache(struct vm_area_struct * vma,
{
}
+static inline void update_mmu_cache_range(struct vm_fault *vmf,
+ struct vm_area_struct *vma, unsigned long address,
+ pte_t *ptep, unsigned int nr)
+{
+}
+
/*
* Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
* are !pte_none() && !pte_present().
diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
index 714abe4..55bb1c0 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -47,12 +47,6 @@ unsigned long __get_wchan(struct task_struct *p);
#define ARCH_HAS_PREFETCH
#define ARCH_HAS_PREFETCHW
-#define ARCH_HAS_SPINLOCK_PREFETCH
-
-#ifndef CONFIG_SMP
-/* Nothing to prefetch. */
-#define spin_lock_prefetch(lock) do { } while (0)
-#endif
extern inline void prefetch(const void *ptr)
{
@@ -64,11 +58,4 @@ extern inline void prefetchw(const void *ptr)
__builtin_prefetch(ptr, 1, 3);
}
-#ifdef CONFIG_SMP
-extern inline void spin_lock_prefetch(const void *ptr)
-{
- __builtin_prefetch(ptr, 1, 3);
-}
-#endif
-
#endif /* __ASM_ALPHA_PROCESSOR_H */
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index d98701e..5db88b6 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -97,7 +97,7 @@ struct osf_dirent {
unsigned int d_ino;
unsigned short d_reclen;
unsigned short d_namlen;
- char d_name[1];
+ char d_name[];
};
struct osf_dirent_callback {
diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index b650ff1..c80258e 100644
--- a/arch/alpha/kernel/setup.c
+++ b/arch/alpha/kernel/setup.c
@@ -385,8 +385,7 @@ setup_memory(void *kernel_end)
#endif /* CONFIG_BLK_DEV_INITRD */
}
-int __init
-page_is_ram(unsigned long pfn)
+int page_is_ram(unsigned long pfn)
{
struct memclust_struct * cluster;
struct memdesc_struct * memdesc;
@@ -422,7 +421,7 @@ register_cpus(void)
arch_initcall(register_cpus);
#ifdef CONFIG_MAGIC_SYSRQ
-static void sysrq_reboot_handler(int unused)
+static void sysrq_reboot_handler(u8 unused)
{
machine_halt();
}
diff --git a/arch/alpha/kernel/srmcons.c b/arch/alpha/kernel/srmcons.c
index 6dc952b..d6139db 100644
--- a/arch/alpha/kernel/srmcons.c
+++ b/arch/alpha/kernel/srmcons.c
@@ -129,9 +129,8 @@ srmcons_do_write(struct tty_port *port, const char *buf, int count)
return count;
}
-static int
-srmcons_write(struct tty_struct *tty,
- const unsigned char *buf, int count)
+static ssize_t
+srmcons_write(struct tty_struct *tty, const u8 *buf, size_t count)
{
unsigned long flags;
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index 1f13995..ad37569 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -491,3 +491,4 @@
559 common futex_waitv sys_futex_waitv
560 common set_mempolicy_home_node sys_ni_syscall
561 common cachestat sys_cachestat
+562 common fchmodat2 sys_fchmodat2
diff --git a/arch/alpha/lib/callback_srm.S b/arch/alpha/lib/callback_srm.S
index b13c4a2..36b63f2 100644
--- a/arch/alpha/lib/callback_srm.S
+++ b/arch/alpha/lib/callback_srm.S
@@ -3,8 +3,8 @@
* arch/alpha/lib/callback_srm.S
*/
+#include <linux/export.h>
#include <asm/console.h>
-#include <asm/export.h>
.text
#define HWRPB_CRB_OFFSET 0xc0
diff --git a/arch/alpha/lib/clear_page.S b/arch/alpha/lib/clear_page.S
index ce02de7..af70ee3 100644
--- a/arch/alpha/lib/clear_page.S
+++ b/arch/alpha/lib/clear_page.S
@@ -4,7 +4,7 @@
*
* Zero an entire page.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 4
.global clear_page
diff --git a/arch/alpha/lib/clear_user.S b/arch/alpha/lib/clear_user.S
index db6c6ca4..848eb60 100644
--- a/arch/alpha/lib/clear_user.S
+++ b/arch/alpha/lib/clear_user.S
@@ -10,7 +10,7 @@
* a successful copy). There is also some rather minor exception setup
* stuff.
*/
-#include <asm/export.h>
+#include <linux/export.h>
/* Allow an exception for an insn; exit if we get one. */
#define EX(x,y...) \
diff --git a/arch/alpha/lib/copy_page.S b/arch/alpha/lib/copy_page.S
index 5439a30..1c444fd 100644
--- a/arch/alpha/lib/copy_page.S
+++ b/arch/alpha/lib/copy_page.S
@@ -4,7 +4,7 @@
*
* Copy an entire page.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 4
.global copy_page
diff --git a/arch/alpha/lib/copy_user.S b/arch/alpha/lib/copy_user.S
index 32ab034..ef18faa 100644
--- a/arch/alpha/lib/copy_user.S
+++ b/arch/alpha/lib/copy_user.S
@@ -12,7 +12,7 @@
* exception setup stuff..
*/
-#include <asm/export.h>
+#include <linux/export.h>
/* Allow an exception for an insn; exit if we get one. */
#define EXI(x,y...) \
diff --git a/arch/alpha/lib/csum_ipv6_magic.S b/arch/alpha/lib/csum_ipv6_magic.S
index c7b213a..273c426 100644
--- a/arch/alpha/lib/csum_ipv6_magic.S
+++ b/arch/alpha/lib/csum_ipv6_magic.S
@@ -13,7 +13,7 @@
* added by Ivan Kokshaysky <ink@jurassic.park.msu.ru>
*/
-#include <asm/export.h>
+#include <linux/export.h>
.globl csum_ipv6_magic
.align 4
.ent csum_ipv6_magic
diff --git a/arch/alpha/lib/divide.S b/arch/alpha/lib/divide.S
index 2b60eb4..db01840 100644
--- a/arch/alpha/lib/divide.S
+++ b/arch/alpha/lib/divide.S
@@ -46,7 +46,7 @@
* $28 - compare status
*/
-#include <asm/export.h>
+#include <linux/export.h>
#define halt .long 0
/*
diff --git a/arch/alpha/lib/ev6-clear_page.S b/arch/alpha/lib/ev6-clear_page.S
index 325864c..a534d9f 100644
--- a/arch/alpha/lib/ev6-clear_page.S
+++ b/arch/alpha/lib/ev6-clear_page.S
@@ -4,7 +4,7 @@
*
* Zero an entire page.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 4
.global clear_page
diff --git a/arch/alpha/lib/ev6-clear_user.S b/arch/alpha/lib/ev6-clear_user.S
index 7e644f8..af776cc 100644
--- a/arch/alpha/lib/ev6-clear_user.S
+++ b/arch/alpha/lib/ev6-clear_user.S
@@ -29,7 +29,7 @@
* want to leave a hole (and we also want to avoid repeating lots of work)
*/
-#include <asm/export.h>
+#include <linux/export.h>
/* Allow an exception for an insn; exit if we get one. */
#define EX(x,y...) \
99: x,##y; \
diff --git a/arch/alpha/lib/ev6-copy_page.S b/arch/alpha/lib/ev6-copy_page.S
index fd7212c..36be511 100644
--- a/arch/alpha/lib/ev6-copy_page.S
+++ b/arch/alpha/lib/ev6-copy_page.S
@@ -57,7 +57,7 @@
destination pages are in the dcache, but it is my guess that this is
less important than the dcache miss case. */
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 4
.global copy_page
diff --git a/arch/alpha/lib/ev6-copy_user.S b/arch/alpha/lib/ev6-copy_user.S
index f3e4337..b9b1971 100644
--- a/arch/alpha/lib/ev6-copy_user.S
+++ b/arch/alpha/lib/ev6-copy_user.S
@@ -23,7 +23,7 @@
* L - lower subcluster; L0 - subcluster L0; L1 - subcluster L1
*/
-#include <asm/export.h>
+#include <linux/export.h>
/* Allow an exception for an insn; exit if we get one. */
#define EXI(x,y...) \
99: x,##y; \
diff --git a/arch/alpha/lib/ev6-csum_ipv6_magic.S b/arch/alpha/lib/ev6-csum_ipv6_magic.S
index 9a73f907..2ee548b 100644
--- a/arch/alpha/lib/ev6-csum_ipv6_magic.S
+++ b/arch/alpha/lib/ev6-csum_ipv6_magic.S
@@ -53,7 +53,7 @@
* may cause additional delay in rare cases (load-load replay traps).
*/
-#include <asm/export.h>
+#include <linux/export.h>
.globl csum_ipv6_magic
.align 4
.ent csum_ipv6_magic
diff --git a/arch/alpha/lib/ev6-divide.S b/arch/alpha/lib/ev6-divide.S
index 137ff1a..b73a6d2 100644
--- a/arch/alpha/lib/ev6-divide.S
+++ b/arch/alpha/lib/ev6-divide.S
@@ -56,7 +56,7 @@
* Try not to change the actual algorithm if possible for consistency.
*/
-#include <asm/export.h>
+#include <linux/export.h>
#define halt .long 0
/*
diff --git a/arch/alpha/lib/ev6-memchr.S b/arch/alpha/lib/ev6-memchr.S
index 56bf9e1..f75ba43 100644
--- a/arch/alpha/lib/ev6-memchr.S
+++ b/arch/alpha/lib/ev6-memchr.S
@@ -28,7 +28,7 @@
* L - lower subcluster; L0 - subcluster L0; L1 - subcluster L1
* Try not to change the actual algorithm if possible for consistency.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noreorder
.set noat
diff --git a/arch/alpha/lib/ev6-memcpy.S b/arch/alpha/lib/ev6-memcpy.S
index ffbd056..3ef43c2 100644
--- a/arch/alpha/lib/ev6-memcpy.S
+++ b/arch/alpha/lib/ev6-memcpy.S
@@ -20,7 +20,7 @@
* Temp usage notes:
* $1,$2, - scratch
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noreorder
.set noat
diff --git a/arch/alpha/lib/ev6-memset.S b/arch/alpha/lib/ev6-memset.S
index 1cfcfbb..89d7809 100644
--- a/arch/alpha/lib/ev6-memset.S
+++ b/arch/alpha/lib/ev6-memset.S
@@ -27,7 +27,7 @@
* as fixes will need to be made in multiple places. The performance gain
* is worth it.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noat
.set noreorder
.text
diff --git a/arch/alpha/lib/ev67-strcat.S b/arch/alpha/lib/ev67-strcat.S
index ec3096a..f8c7305 100644
--- a/arch/alpha/lib/ev67-strcat.S
+++ b/arch/alpha/lib/ev67-strcat.S
@@ -20,7 +20,7 @@
* string once.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 4
diff --git a/arch/alpha/lib/ev67-strchr.S b/arch/alpha/lib/ev67-strchr.S
index fbf89e0..97a7cb4 100644
--- a/arch/alpha/lib/ev67-strchr.S
+++ b/arch/alpha/lib/ev67-strchr.S
@@ -16,7 +16,7 @@
* L - lower subcluster; L0 - subcluster L0; L1 - subcluster L1
* Try not to change the actual algorithm if possible for consistency.
*/
-#include <asm/export.h>
+#include <linux/export.h>
#include <asm/regdef.h>
.set noreorder
diff --git a/arch/alpha/lib/ev67-strlen.S b/arch/alpha/lib/ev67-strlen.S
index b73106f..3d90788 100644
--- a/arch/alpha/lib/ev67-strlen.S
+++ b/arch/alpha/lib/ev67-strlen.S
@@ -18,7 +18,7 @@
* U - upper subcluster; U0 - subcluster U0; U1 - subcluster U1
* L - lower subcluster; L0 - subcluster L0; L1 - subcluster L1
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noreorder
.set noat
diff --git a/arch/alpha/lib/ev67-strncat.S b/arch/alpha/lib/ev67-strncat.S
index ceb0ca5..8f31323 100644
--- a/arch/alpha/lib/ev67-strncat.S
+++ b/arch/alpha/lib/ev67-strncat.S
@@ -21,7 +21,7 @@
* Try not to change the actual algorithm if possible for consistency.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 4
diff --git a/arch/alpha/lib/ev67-strrchr.S b/arch/alpha/lib/ev67-strrchr.S
index 7f80e39..ae7355f 100644
--- a/arch/alpha/lib/ev67-strrchr.S
+++ b/arch/alpha/lib/ev67-strrchr.S
@@ -19,7 +19,7 @@
* L - lower subcluster; L0 - subcluster L0; L1 - subcluster L1
*/
-#include <asm/export.h>
+#include <linux/export.h>
#include <asm/regdef.h>
.set noreorder
diff --git a/arch/alpha/lib/memchr.S b/arch/alpha/lib/memchr.S
index c13d3ec..45366e3 100644
--- a/arch/alpha/lib/memchr.S
+++ b/arch/alpha/lib/memchr.S
@@ -31,7 +31,7 @@
- only minimum number of quadwords may be accessed
- the third argument is an unsigned long
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noreorder
.set noat
diff --git a/arch/alpha/lib/memmove.S b/arch/alpha/lib/memmove.S
index 42d1922..3a27689 100644
--- a/arch/alpha/lib/memmove.S
+++ b/arch/alpha/lib/memmove.S
@@ -7,7 +7,7 @@
* This is hand-massaged output from the original memcpy.c. We defer to
* memcpy whenever possible; the backwards copy loops are not unrolled.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noat
.set noreorder
.text
diff --git a/arch/alpha/lib/memset.S b/arch/alpha/lib/memset.S
index 00393e3..9075d69 100644
--- a/arch/alpha/lib/memset.S
+++ b/arch/alpha/lib/memset.S
@@ -14,7 +14,7 @@
* The scheduling comments are according to the EV5 documentation (and done by
* hand, so they might well be incorrect, please do tell me about it..)
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noat
.set noreorder
.text
diff --git a/arch/alpha/lib/strcat.S b/arch/alpha/lib/strcat.S
index 055877d..62b90eb 100644
--- a/arch/alpha/lib/strcat.S
+++ b/arch/alpha/lib/strcat.S
@@ -5,7 +5,7 @@
*
* Append a null-terminated string from SRC to DST.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
diff --git a/arch/alpha/lib/strchr.S b/arch/alpha/lib/strchr.S
index 17871dd..68c54ff 100644
--- a/arch/alpha/lib/strchr.S
+++ b/arch/alpha/lib/strchr.S
@@ -6,7 +6,7 @@
* Return the address of a given character within a null-terminated
* string, or null if it is not found.
*/
-#include <asm/export.h>
+#include <linux/export.h>
#include <asm/regdef.h>
.set noreorder
diff --git a/arch/alpha/lib/strcpy.S b/arch/alpha/lib/strcpy.S
index cb74ad2..d8773ba 100644
--- a/arch/alpha/lib/strcpy.S
+++ b/arch/alpha/lib/strcpy.S
@@ -6,7 +6,7 @@
* Copy a null-terminated string from SRC to DST. Return a pointer
* to the null-terminator in the source.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 3
diff --git a/arch/alpha/lib/strlen.S b/arch/alpha/lib/strlen.S
index dd882fe..4fc6a6f 100644
--- a/arch/alpha/lib/strlen.S
+++ b/arch/alpha/lib/strlen.S
@@ -12,7 +12,7 @@
* do this instead of the 9 instructions that
* binary search needs).
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noreorder
.set noat
diff --git a/arch/alpha/lib/strncat.S b/arch/alpha/lib/strncat.S
index 522fee3..a913a7c 100644
--- a/arch/alpha/lib/strncat.S
+++ b/arch/alpha/lib/strncat.S
@@ -10,7 +10,7 @@
* past count, whereas libc may write to count+1. This follows the generic
* implementation in lib/string.c and is, IMHO, more sensible.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.text
.align 3
diff --git a/arch/alpha/lib/strncpy.S b/arch/alpha/lib/strncpy.S
index cc57fad..cb90cf0 100644
--- a/arch/alpha/lib/strncpy.S
+++ b/arch/alpha/lib/strncpy.S
@@ -11,7 +11,7 @@
* version has cropped that bit o' nastiness as well as assuming that
* __stxncpy is in range of a branch.
*/
-#include <asm/export.h>
+#include <linux/export.h>
.set noat
.set noreorder
diff --git a/arch/alpha/lib/strrchr.S b/arch/alpha/lib/strrchr.S
index 7650ba9..dd8e073 100644
--- a/arch/alpha/lib/strrchr.S
+++ b/arch/alpha/lib/strrchr.S
@@ -6,7 +6,7 @@
* Return the address of the last occurrence of a given character
* within a null-terminated string, or null if it is not found.
*/
-#include <asm/export.h>
+#include <linux/export.h>
#include <asm/regdef.h>
.set noreorder
diff --git a/arch/alpha/lib/udiv-qrnnd.S b/arch/alpha/lib/udiv-qrnnd.S
index b887aa5..96f0591 100644
--- a/arch/alpha/lib/udiv-qrnnd.S
+++ b/arch/alpha/lib/udiv-qrnnd.S
@@ -25,7 +25,7 @@
# along with GCC; see the file COPYING. If not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
# MA 02111-1307, USA.
-#include <asm/export.h>
+#include <linux/export.h>
.set noreorder
.set noat
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 96cf872..3162db5 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -26,6 +26,9 @@
select GENERIC_PENDING_IRQ if SMP
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
+ select GENERIC_IOREMAP
+ select GENERIC_STRNCPY_FROM_USER if MMU
+ select GENERIC_STRNLEN_USER if MMU
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARC_MMU_V4
@@ -490,11 +493,11 @@
kernel-user gutter)
config ARC_CURR_IN_REG
- bool "Dedicate Register r25 for current_task pointer"
+ bool "cache current task pointer in gp"
default y
help
- This reserved Register R25 to point to Current Task in
- kernel mode. This saves memory access for each such access
+ This reserves gp register to point to Current Task in
+ kernel mode eliding memory access for each access
config ARC_EMUL_UNALIGNED
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 329400a..2390dd0 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -28,14 +28,14 @@
endif
endif
-
ifdef CONFIG_ARC_CURR_IN_REG
# For a global register definition, make sure it gets passed to every file
# We had a customer reported bug where some code built in kernel was NOT using
-# any kernel headers, and missing the r25 global register
+# any kernel headers, and missing the global register
# Can't do unconditionally because of recursive include issues
# due to <linux/thread_info.h>
LINUXINCLUDE += -include $(srctree)/arch/arc/include/asm/current.h
+cflags-y += -ffixed-gp
endif
cflags-y += -fsection-anchors
@@ -67,7 +67,7 @@
# small data is default for elf32 tool-chain. If not usable, disable it
# This also allows repurposing GP as scratch reg to gcc reg allocator
disable_small_data := y
-cflags-$(disable_small_data) += -mno-sdata -fcall-used-gp
+cflags-$(disable_small_data) += -mno-sdata
cflags-$(CONFIG_CPU_BIG_ENDIAN) += -mbig-endian
ldflags-$(CONFIG_CPU_BIG_ENDIAN) += -EB
diff --git a/arch/arc/configs/axs101_defconfig b/arch/arc/configs/axs101_defconfig
index 8176416..89720d6 100644
--- a/arch/arc/configs/axs101_defconfig
+++ b/arch/arc/configs/axs101_defconfig
@@ -9,7 +9,7 @@
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
diff --git a/arch/arc/configs/axs103_defconfig b/arch/arc/configs/axs103_defconfig
index d518127..73ec01e 100644
--- a/arch/arc/configs/axs103_defconfig
+++ b/arch/arc/configs/axs103_defconfig
@@ -9,7 +9,7 @@
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
diff --git a/arch/arc/configs/axs103_smp_defconfig b/arch/arc/configs/axs103_smp_defconfig
index 07c8928..4da0f62 100644
--- a/arch/arc/configs/axs103_smp_defconfig
+++ b/arch/arc/configs/axs103_smp_defconfig
@@ -9,7 +9,7 @@
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/haps_hs_smp_defconfig b/arch/arc/configs/haps_hs_smp_defconfig
index 61107e8..6fc98c1 100644
--- a/arch/arc/configs/haps_hs_smp_defconfig
+++ b/arch/arc/configs/haps_hs_smp_defconfig
@@ -11,7 +11,7 @@
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
index 4ee2a15..9e79154 100644
--- a/arch/arc/configs/hsdk_defconfig
+++ b/arch/arc/configs/hsdk_defconfig
@@ -9,7 +9,7 @@
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_RAM=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/nsim_700_defconfig b/arch/arc/configs/nsim_700_defconfig
index 3e98297..51092c3 100644
--- a/arch/arc/configs/nsim_700_defconfig
+++ b/arch/arc/configs/nsim_700_defconfig
@@ -12,7 +12,7 @@
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/nsimosci_defconfig b/arch/arc/configs/nsimosci_defconfig
index 502c87f..70c17bc 100644
--- a/arch/arc/configs/nsimosci_defconfig
+++ b/arch/arc/configs/nsimosci_defconfig
@@ -11,7 +11,7 @@
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/nsimosci_hs_defconfig b/arch/arc/configs/nsimosci_hs_defconfig
index f721cc3..59a3b66 100644
--- a/arch/arc/configs/nsimosci_hs_defconfig
+++ b/arch/arc/configs/nsimosci_hs_defconfig
@@ -11,7 +11,7 @@
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/arc/configs/tb10x_defconfig b/arch/arc/configs/tb10x_defconfig
index 941bbad..1a68e4b 100644
--- a/arch/arc/configs/tb10x_defconfig
+++ b/arch/arc/configs/tb10x_defconfig
@@ -16,7 +16,7 @@
# CONFIG_RD_GZIP is not set
CONFIG_KALLSYMS_ALL=y
# CONFIG_AIO is not set
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
# CONFIG_COMPAT_BRK is not set
CONFIG_ISA_ARCOMPACT=y
CONFIG_MODULES=y
diff --git a/arch/arc/configs/vdk_hs38_defconfig b/arch/arc/configs/vdk_hs38_defconfig
index d3ef189..50c3439 100644
--- a/arch/arc/configs/vdk_hs38_defconfig
+++ b/arch/arc/configs/vdk_hs38_defconfig
@@ -4,7 +4,7 @@
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig b/arch/arc/configs/vdk_hs38_smp_defconfig
index 944b347..6d9e1d9 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -4,7 +4,7 @@
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h
index 2162023..4b13f60 100644
--- a/arch/arc/include/asm/arcregs.h
+++ b/arch/arc/include/asm/arcregs.h
@@ -23,7 +23,7 @@
#define ARC_REG_ICCM_BUILD 0x78 /* ICCM size (common) */
#define ARC_REG_XY_MEM_BCR 0x79
#define ARC_REG_MAC_BCR 0x7a
-#define ARC_REG_MUL_BCR 0x7b
+#define ARC_REG_MPY_BCR 0x7b
#define ARC_REG_SWAP_BCR 0x7c
#define ARC_REG_NORM_BCR 0x7d
#define ARC_REG_MIXMAX_BCR 0x7e
@@ -177,7 +177,7 @@ struct bcr_isa_arcv2 {
#endif
};
-struct bcr_uarch_build_arcv2 {
+struct bcr_uarch_build {
#ifdef CONFIG_CPU_BIG_ENDIAN
unsigned int pad:8, prod:8, maj:8, min:8;
#else
@@ -185,6 +185,59 @@ struct bcr_uarch_build_arcv2 {
#endif
};
+struct bcr_mmu_3 {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned int ver:8, ways:4, sets:4, res:3, sasid:1, pg_sz:4,
+ u_itlb:4, u_dtlb:4;
+#else
+ unsigned int u_dtlb:4, u_itlb:4, pg_sz:4, sasid:1, res:3, sets:4,
+ ways:4, ver:8;
+#endif
+};
+
+struct bcr_mmu_4 {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned int ver:8, sasid:1, sz1:4, sz0:4, res:2, pae:1,
+ n_ways:2, n_entry:2, n_super:2, u_itlb:3, u_dtlb:3;
+#else
+ /* DTLB ITLB JES JE JA */
+ unsigned int u_dtlb:3, u_itlb:3, n_super:2, n_entry:2, n_ways:2,
+ pae:1, res:2, sz0:4, sz1:4, sasid:1, ver:8;
+#endif
+};
+
+struct bcr_cache {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned int pad:12, line_len:4, sz:4, config:4, ver:8;
+#else
+ unsigned int ver:8, config:4, sz:4, line_len:4, pad:12;
+#endif
+};
+
+struct bcr_slc_cfg {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned int pad:24, way:2, lsz:2, sz:4;
+#else
+ unsigned int sz:4, lsz:2, way:2, pad:24;
+#endif
+};
+
+struct bcr_clust_cfg {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned int pad:7, c:1, num_entries:8, num_cores:8, ver:8;
+#else
+ unsigned int ver:8, num_cores:8, num_entries:8, c:1, pad:7;
+#endif
+};
+
+struct bcr_volatile {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned int start:4, limit:4, pad:22, order:1, disable:1;
+#else
+ unsigned int disable:1, order:1, pad:22, limit:4, start:4;
+#endif
+};
+
struct bcr_mpy {
#ifdef CONFIG_CPU_BIG_ENDIAN
unsigned int pad:8, x1616:8, dsp:4, cycles:2, type:2, ver:8;
@@ -302,48 +355,6 @@ struct bcr_generic {
#endif
};
-/*
- *******************************************************************
- * Generic structures to hold build configuration used at runtime
- */
-
-struct cpuinfo_arc_mmu {
- unsigned int ver:4, pg_sz_k:8, s_pg_sz_m:8, pad:10, sasid:1, pae:1;
- unsigned int sets:12, ways:4, u_dtlb:8, u_itlb:8;
-};
-
-struct cpuinfo_arc_cache {
- unsigned int sz_k:14, line_len:8, assoc:4, alias:1, vipt:1, pad:4;
-};
-
-struct cpuinfo_arc_bpu {
- unsigned int ver, full, num_cache, num_pred, ret_stk;
-};
-
-struct cpuinfo_arc_ccm {
- unsigned int base_addr, sz;
-};
-
-struct cpuinfo_arc {
- struct cpuinfo_arc_cache icache, dcache, slc;
- struct cpuinfo_arc_mmu mmu;
- struct cpuinfo_arc_bpu bpu;
- struct bcr_identity core;
- struct bcr_isa_arcv2 isa;
- const char *release, *name;
- unsigned int vec_base;
- struct cpuinfo_arc_ccm iccm, dccm;
- struct {
- unsigned int swap:1, norm:1, minmax:1, barrel:1, crc:1, swape:1, pad1:2,
- fpu_sp:1, fpu_dp:1, dual:1, dual_enb:1, pad2:4,
- ap_num:4, ap_full:1, smart:1, rtt:1, pad3:1,
- timer0:1, timer1:1, rtc:1, gfrc:1, pad4:4;
- } extn;
- struct bcr_mpy extn_mpy;
-};
-
-extern struct cpuinfo_arc cpuinfo_arc700[];
-
static inline int is_isa_arcv2(void)
{
return IS_ENABLED(CONFIG_ISA_ARCV2);
diff --git a/arch/arc/include/asm/atomic-llsc.h b/arch/arc/include/asm/atomic-llsc.h
index 1b0ffae..5258cb8 100644
--- a/arch/arc/include/asm/atomic-llsc.h
+++ b/arch/arc/include/asm/atomic-llsc.h
@@ -18,7 +18,7 @@ static inline void arch_atomic_##op(int i, atomic_t *v) \
: [val] "=&r" (val) /* Early clobber to prevent reg reuse */ \
: [ctr] "r" (&v->counter), /* Not "m": llock only supports reg direct addr mode */ \
[i] "ir" (i) \
- : "cc"); \
+ : "cc", "memory"); \
} \
#define ATOMIC_OP_RETURN(op, asm_op) \
@@ -34,7 +34,7 @@ static inline int arch_atomic_##op##_return_relaxed(int i, atomic_t *v) \
: [val] "=&r" (val) \
: [ctr] "r" (&v->counter), \
[i] "ir" (i) \
- : "cc"); \
+ : "cc", "memory"); \
\
return val; \
}
@@ -56,7 +56,7 @@ static inline int arch_atomic_fetch_##op##_relaxed(int i, atomic_t *v) \
[orig] "=&r" (orig) \
: [ctr] "r" (&v->counter), \
[i] "ir" (i) \
- : "cc"); \
+ : "cc", "memory"); \
\
return orig; \
}
diff --git a/arch/arc/include/asm/atomic64-arcv2.h b/arch/arc/include/asm/atomic64-arcv2.h
index 6b6db98..9b5791b 100644
--- a/arch/arc/include/asm/atomic64-arcv2.h
+++ b/arch/arc/include/asm/atomic64-arcv2.h
@@ -60,7 +60,7 @@ static inline void arch_atomic64_##op(s64 a, atomic64_t *v) \
" bnz 1b \n" \
: "=&r"(val) \
: "r"(&v->counter), "ir"(a) \
- : "cc"); \
+ : "cc", "memory"); \
} \
#define ATOMIC64_OP_RETURN(op, op1, op2) \
@@ -77,7 +77,7 @@ static inline s64 arch_atomic64_##op##_return_relaxed(s64 a, atomic64_t *v) \
" bnz 1b \n" \
: [val] "=&r"(val) \
: "r"(&v->counter), "ir"(a) \
- : "cc"); /* memory clobber comes from smp_mb() */ \
+ : "cc", "memory"); \
\
return val; \
}
@@ -99,7 +99,7 @@ static inline s64 arch_atomic64_fetch_##op##_relaxed(s64 a, atomic64_t *v) \
" bnz 1b \n" \
: "=&r"(orig), "=&r"(val) \
: "r"(&v->counter), "ir"(a) \
- : "cc"); /* memory clobber comes from smp_mb() */ \
+ : "cc", "memory"); \
\
return orig; \
}
diff --git a/arch/arc/include/asm/cacheflush.h b/arch/arc/include/asm/cacheflush.h
index e201b4b..bd5b1a9 100644
--- a/arch/arc/include/asm/cacheflush.h
+++ b/arch/arc/include/asm/cacheflush.h
@@ -18,24 +18,18 @@
#include <linux/mm.h>
#include <asm/shmparam.h>
-/*
- * Semantically we need this because icache doesn't snoop dcache/dma.
- * However ARC Cache flush requires paddr as well as vaddr, latter not available
- * in the flush_icache_page() API. So we no-op it but do the equivalent work
- * in update_mmu_cache()
- */
-#define flush_icache_page(vma, page)
-
void flush_cache_all(void);
void flush_icache_range(unsigned long kstart, unsigned long kend);
void __sync_icache_dcache(phys_addr_t paddr, unsigned long vaddr, int len);
-void __inv_icache_page(phys_addr_t paddr, unsigned long vaddr);
-void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr);
+void __inv_icache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr);
+void __flush_dcache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr);
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
void flush_dcache_page(struct page *page);
+void flush_dcache_folio(struct folio *folio);
+#define flush_dcache_folio flush_dcache_folio
void dma_cache_wback_inv(phys_addr_t start, unsigned long sz);
void dma_cache_inv(phys_addr_t start, unsigned long sz);
diff --git a/arch/arc/include/asm/current.h b/arch/arc/include/asm/current.h
index 9b9bdd3..06be89f 100644
--- a/arch/arc/include/asm/current.h
+++ b/arch/arc/include/asm/current.h
@@ -13,7 +13,7 @@
#ifdef CONFIG_ARC_CURR_IN_REG
-register struct task_struct *curr_arc asm("r25");
+register struct task_struct *curr_arc asm("gp");
#define current (curr_arc)
#else
diff --git a/arch/arc/include/asm/dwarf.h b/arch/arc/include/asm/dwarf.h
index 5f4de05b..a0d5ebe 100644
--- a/arch/arc/include/asm/dwarf.h
+++ b/arch/arc/include/asm/dwarf.h
@@ -10,23 +10,31 @@
#ifdef ARC_DW2_UNWIND_AS_CFI
-#define CFI_STARTPROC .cfi_startproc
-#define CFI_ENDPROC .cfi_endproc
-#define CFI_DEF_CFA .cfi_def_cfa
-#define CFI_REGISTER .cfi_register
-#define CFI_REL_OFFSET .cfi_rel_offset
-#define CFI_UNDEFINED .cfi_undefined
+#define CFI_STARTPROC .cfi_startproc
+#define CFI_ENDPROC .cfi_endproc
+#define CFI_DEF_CFA .cfi_def_cfa
+#define CFI_DEF_CFA_OFFSET .cfi_def_cfa_offset
+#define CFI_DEF_CFA_REGISTER .cfi_def_cfa_register
+#define CFI_OFFSET .cfi_offset
+#define CFI_REL_OFFSET .cfi_rel_offset
+#define CFI_REGISTER .cfi_register
+#define CFI_RESTORE .cfi_restore
+#define CFI_UNDEFINED .cfi_undefined
#else
#define CFI_IGNORE #
-#define CFI_STARTPROC CFI_IGNORE
-#define CFI_ENDPROC CFI_IGNORE
-#define CFI_DEF_CFA CFI_IGNORE
-#define CFI_REGISTER CFI_IGNORE
-#define CFI_REL_OFFSET CFI_IGNORE
-#define CFI_UNDEFINED CFI_IGNORE
+#define CFI_STARTPROC CFI_IGNORE
+#define CFI_ENDPROC CFI_IGNORE
+#define CFI_DEF_CFA CFI_IGNORE
+#define CFI_DEF_CFA_OFFSET CFI_IGNORE
+#define CFI_DEF_CFA_REGISTER CFI_IGNORE
+#define CFI_OFFSET CFI_IGNORE
+#define CFI_REL_OFFSET CFI_IGNORE
+#define CFI_REGISTER CFI_IGNORE
+#define CFI_RESTORE CFI_IGNORE
+#define CFI_UNDEFINED CFI_IGNORE
#endif /* !ARC_DW2_UNWIND_AS_CFI */
diff --git a/arch/arc/include/asm/entry-arcv2.h b/arch/arc/include/asm/entry-arcv2.h
index 0ff4c06..4d13320 100644
--- a/arch/arc/include/asm/entry-arcv2.h
+++ b/arch/arc/include/asm/entry-arcv2.h
@@ -18,7 +18,6 @@
* | orig_r0 |
* | event/ECR |
* | bta |
- * | user_r25 |
* | gp |
* | fp |
* | sp |
@@ -49,14 +48,18 @@
/*------------------------------------------------------------------------*/
.macro INTERRUPT_PROLOGUE
- ; (A) Before jumping to Interrupt Vector, hardware micro-ops did following:
+ ; Before jumping to Interrupt Vector, hardware micro-ops did following:
; 1. SP auto-switched to kernel mode stack
; 2. STATUS32.Z flag set if in U mode at time of interrupt (U:1,K:0)
; 3. Auto save: (mandatory) Push PC and STAT32 on stack
; hardware does even if CONFIG_ARC_IRQ_NO_AUTOSAVE
- ; 4. Auto save: (optional) r0-r11, blink, LPE,LPS,LPC, JLI,LDI,EI
+ ; 4a. Auto save: (optional) r0-r11, blink, LPE,LPS,LPC, JLI,LDI,EI
;
- ; (B) Manually saved some regs: r12,r25,r30, sp,fp,gp, ACCL pair
+ ; Now
+ ; 4b. If Auto-save (optional) not enabled in hw, manually save them
+ ; 5. Manually save: r12,r30, sp,fp,gp, ACCL pair
+ ;
+ ; At the end, SP points to pt_regs
#ifdef CONFIG_ARC_IRQ_NO_AUTOSAVE
; carve pt_regs on stack (case #3), PC/STAT32 already on stack
@@ -72,15 +75,16 @@
.endm
/*------------------------------------------------------------------------*/
-.macro EXCEPTION_PROLOGUE
+.macro EXCEPTION_PROLOGUE_KEEP_AE
- ; (A) Before jumping to Exception Vector, hardware micro-ops did following:
+ ; Before jumping to Exception Vector, hardware micro-ops did following:
; 1. SP auto-switched to kernel mode stack
; 2. STATUS32.Z flag set if in U mode at time of exception (U:1,K:0)
;
- ; (B) Manually save the complete reg file below
+ ; Now manually save rest of reg file
+ ; At the end, SP points to pt_regs
- sub sp, sp, SZ_PT_REGS ; carve pt_regs
+ sub sp, sp, SZ_PT_REGS ; carve space for pt_regs
; _HARD saves r10 clobbered by _SOFT as scratch hence comes first
@@ -100,6 +104,16 @@
; OUTPUT: r10 has ECR expected by EV_Trap
.endm
+.macro EXCEPTION_PROLOGUE
+
+ EXCEPTION_PROLOGUE_KEEP_AE ; return ECR in r10
+
+ lr r0, [efa]
+ mov r1, sp
+
+ FAKE_RET_FROM_EXCPN ; clobbers r9
+.endm
+
/*------------------------------------------------------------------------
* This macro saves the registers manually which would normally be autosaved
* by hardware on taken interrupts. It is used by
@@ -135,10 +149,10 @@
*/
.macro __SAVE_REGFILE_SOFT
- ST2 gp, fp, PT_r26 ; gp (r26), fp (r27)
-
- st r12, [sp, PT_sp + 4]
- st r30, [sp, PT_sp + 8]
+ st fp, [sp, PT_fp] ; r27
+ st r30, [sp, PT_r30]
+ st r12, [sp, PT_r12]
+ st r26, [sp, PT_r26] ; gp
; Saving pt_regs->sp correctly requires some extra work due to the way
; Auto stack switch works
@@ -153,30 +167,30 @@
; ISA requires ADD.nz to have same dest and src reg operands
mov.nz r10, sp
- add.nz r10, r10, SZ_PT_REGS ; K mode SP
+ add2.nz r10, r10, SZ_PT_REGS/4 ; K mode SP
st r10, [sp, PT_sp] ; SP (pt_regs->sp)
-#ifdef CONFIG_ARC_CURR_IN_REG
- st r25, [sp, PT_user_r25]
- GET_CURR_TASK_ON_CPU r25
-#endif
-
#ifdef CONFIG_ARC_HAS_ACCL_REGS
ST2 r58, r59, PT_r58
#endif
/* clobbers r10, r11 registers pair */
DSP_SAVE_REGFILE_IRQ
+
+#ifdef CONFIG_ARC_CURR_IN_REG
+ GET_CURR_TASK_ON_CPU gp
+#endif
+
.endm
/*------------------------------------------------------------------------*/
.macro __RESTORE_REGFILE_SOFT
- LD2 gp, fp, PT_r26 ; gp (r26), fp (r27)
-
- ld r12, [sp, PT_r12]
+ ld fp, [sp, PT_fp]
ld r30, [sp, PT_r30]
+ ld r12, [sp, PT_r12]
+ ld r26, [sp, PT_r26]
; Restore SP (into AUX_USER_SP) only if returning to U mode
; - for K mode, it will be implicitly restored as stack is unwound
@@ -188,10 +202,6 @@
sr r10, [AUX_USER_SP]
1:
-#ifdef CONFIG_ARC_CURR_IN_REG
- ld r25, [sp, PT_user_r25]
-#endif
-
/* clobbers r10, r11 registers pair */
DSP_RESTORE_REGFILE_IRQ
@@ -249,7 +259,7 @@
btst r0, STATUS_U_BIT ; Z flag set if K, used in restoring SP
- ld r10, [sp, PT_event + 4]
+ ld r10, [sp, PT_bta]
sr r10, [erbta]
LD2 r10, r11, PT_ret
@@ -264,8 +274,8 @@
.macro FAKE_RET_FROM_EXCPN
lr r9, [status32]
- bic r9, r9, STATUS_AE_MASK
- or r9, r9, STATUS_IE_MASK
+ bclr r9, r9, STATUS_AE_BIT
+ bset r9, r9, STATUS_IE_BIT
kflag r9
.endm
diff --git a/arch/arc/include/asm/entry-compact.h b/arch/arc/include/asm/entry-compact.h
index 67ff06e..a0e760e 100644
--- a/arch/arc/include/asm/entry-compact.h
+++ b/arch/arc/include/asm/entry-compact.h
@@ -140,7 +140,7 @@
*
* After this it is safe to call the "C" handlers
*-------------------------------------------------------------*/
-.macro EXCEPTION_PROLOGUE
+.macro EXCEPTION_PROLOGUE_KEEP_AE
/* Need at least 1 reg to code the early exception prologue */
PROLOG_FREEUP_REG r9, @ex_saved_reg1
@@ -151,14 +151,6 @@
/* ARC700 doesn't provide auto-stack switching */
SWITCH_TO_KERNEL_STK
-#ifdef CONFIG_ARC_CURR_IN_REG
- /* Treat r25 as scratch reg (save on stack) and load with "current" */
- PUSH r25
- GET_CURR_TASK_ON_CPU r25
-#else
- sub sp, sp, 4
-#endif
-
st.a r0, [sp, -8] /* orig_r0 needed for syscall (skip ECR slot) */
sub sp, sp, 4 /* skip pt_regs->sp, already saved above */
@@ -178,7 +170,23 @@
PUSHAX erbta
lr r10, [ecr]
- st r10, [sp, PT_event] /* EV_Trap expects r10 to have ECR */
+ st r10, [sp, PT_event]
+
+#ifdef CONFIG_ARC_CURR_IN_REG
+ /* gp already saved on stack: now load with "current" */
+ GET_CURR_TASK_ON_CPU gp
+#endif
+ ; OUTPUT: r10 has ECR expected by EV_Trap
+.endm
+
+.macro EXCEPTION_PROLOGUE
+
+ EXCEPTION_PROLOGUE_KEEP_AE ; return ECR in r10
+
+ lr r0, [efa]
+ mov r1, sp
+
+ FAKE_RET_FROM_EXCPN ; clobbers r9
.endm
/*--------------------------------------------------------------
@@ -208,11 +216,8 @@
POP gp
RESTORE_R12_TO_R0
-#ifdef CONFIG_ARC_CURR_IN_REG
- ld r25, [sp, 12]
-#endif
ld sp, [sp] /* restore original sp */
- /* orig_r0, ECR, user_r25 skipped automatically */
+ /* orig_r0, ECR skipped automatically */
.endm
/* Dummy ECR values for Interrupts */
@@ -229,13 +234,6 @@
SWITCH_TO_KERNEL_STK
-#ifdef CONFIG_ARC_CURR_IN_REG
- /* Treat r25 as scratch reg (save on stack) and load with "current" */
- PUSH r25
- GET_CURR_TASK_ON_CPU r25
-#else
- sub sp, sp, 4
-#endif
PUSH 0x003\LVL\()abcd /* Dummy ECR */
sub sp, sp, 8 /* skip orig_r0 (not needed)
@@ -255,6 +253,10 @@
PUSHAX lp_start
PUSHAX bta_l\LVL\()
+#ifdef CONFIG_ARC_CURR_IN_REG
+ /* gp already saved on stack: now load with "current" */
+ GET_CURR_TASK_ON_CPU gp
+#endif
.endm
/*--------------------------------------------------------------
@@ -282,11 +284,7 @@
POP gp
RESTORE_R12_TO_R0
-#ifdef CONFIG_ARC_CURR_IN_REG
- ld r25, [sp, 12]
-#endif
- ld sp, [sp] /* restore original sp */
- /* orig_r0, ECR, user_r25 skipped automatically */
+ ld sp, [sp] /* restore original sp; orig_r0, ECR skipped implicitly */
.endm
/* Get thread_info of "current" tsk */
diff --git a/arch/arc/include/asm/entry.h b/arch/arc/include/asm/entry.h
index fcdd59d..49c2e09 100644
--- a/arch/arc/include/asm/entry.h
+++ b/arch/arc/include/asm/entry.h
@@ -13,6 +13,8 @@
#include <asm/processor.h> /* For VMALLOC_START */
#include <asm/mmu.h>
+#ifdef __ASSEMBLY__
+
#ifdef CONFIG_ISA_ARCOMPACT
#include <asm/entry-compact.h> /* ISA specific bits */
#else
@@ -89,7 +91,7 @@
* Helpers to save/restore callee-saved regs:
* used by several macros below
*-------------------------------------------------------------*/
-.macro SAVE_R13_TO_R24
+.macro SAVE_R13_TO_R25
PUSH r13
PUSH r14
PUSH r15
@@ -102,9 +104,11 @@
PUSH r22
PUSH r23
PUSH r24
+ PUSH r25
.endm
-.macro RESTORE_R24_TO_R13
+.macro RESTORE_R25_TO_R13
+ POP r25
POP r24
POP r23
POP r22
@@ -119,81 +123,31 @@
POP r13
.endm
-/*--------------------------------------------------------------
- * Collect User Mode callee regs as struct callee_regs - needed by
- * fork/do_signal/unaligned-access-emulation.
- * (By default only scratch regs are saved on entry to kernel)
- *
- * Special handling for r25 if used for caching Task Pointer.
- * It would have been saved in task->thread.user_r25 already, but to keep
- * the interface same it is copied into regular r25 placeholder in
- * struct callee_regs.
- *-------------------------------------------------------------*/
+/*
+ * save user mode callee regs as struct callee_regs
+ * - needed by fork/do_signal/unaligned-access-emulation.
+ */
.macro SAVE_CALLEE_SAVED_USER
-
- mov r12, sp ; save SP as ref to pt_regs
- SAVE_R13_TO_R24
-
-#ifdef CONFIG_ARC_CURR_IN_REG
- ; Retrieve orig r25 and save it with rest of callee_regs
- ld r12, [r12, PT_user_r25]
- PUSH r12
-#else
- PUSH r25
-#endif
-
+ SAVE_R13_TO_R25
.endm
-/*--------------------------------------------------------------
- * Save kernel Mode callee regs at the time of Contect Switch.
- *
- * Special handling for r25 if used for caching Task Pointer.
- * Kernel simply skips saving it since it will be loaded with
- * incoming task pointer anyways
- *-------------------------------------------------------------*/
-.macro SAVE_CALLEE_SAVED_KERNEL
-
- SAVE_R13_TO_R24
-
-#ifdef CONFIG_ARC_CURR_IN_REG
- sub sp, sp, 4
-#else
- PUSH r25
-#endif
-.endm
-
-/*--------------------------------------------------------------
- * Opposite of SAVE_CALLEE_SAVED_KERNEL
- *-------------------------------------------------------------*/
-.macro RESTORE_CALLEE_SAVED_KERNEL
-
-#ifdef CONFIG_ARC_CURR_IN_REG
- add sp, sp, 4 /* skip usual r25 placeholder */
-#else
- POP r25
-#endif
- RESTORE_R24_TO_R13
-.endm
-
-/*--------------------------------------------------------------
- * Opposite of SAVE_CALLEE_SAVED_USER
- *
- * ptrace tracer or unaligned-access fixup might have changed a user mode
- * callee reg which is saved back to usual r25 storage location
- *-------------------------------------------------------------*/
+/*
+ * restore user mode callee regs as struct callee_regs
+ * - could have been changed by ptrace tracer or unaligned-access fixup
+ */
.macro RESTORE_CALLEE_SAVED_USER
+ RESTORE_R25_TO_R13
+.endm
-#ifdef CONFIG_ARC_CURR_IN_REG
- POP r12
-#else
- POP r25
-#endif
- RESTORE_R24_TO_R13
+/*
+ * save/restore kernel mode callee regs at the time of context switch
+ */
+.macro SAVE_CALLEE_SAVED_KERNEL
+ SAVE_R13_TO_R25
+.endm
- ; SP is back to start of pt_regs
-#ifdef CONFIG_ARC_CURR_IN_REG
- st r12, [sp, PT_user_r25]
-#endif
+.macro RESTORE_CALLEE_SAVED_KERNEL
+ RESTORE_R25_TO_R13
.endm
/*--------------------------------------------------------------
@@ -229,10 +183,10 @@
#ifdef CONFIG_SMP
-/*-------------------------------------------------
+/*
* Retrieve the current running task on this CPU
- * 1. Determine curr CPU id.
- * 2. Use it to index into _current_task[ ]
+ * - loads it from backing _current_task[] (and can't use the
+ * caching reg for current task
*/
.macro GET_CURR_TASK_ON_CPU reg
GET_CPU_ID \reg
@@ -254,7 +208,7 @@
add2 \tmp, @_current_task, \tmp
st \tsk, [\tmp]
#ifdef CONFIG_ARC_CURR_IN_REG
- mov r25, \tsk
+ mov gp, \tsk
#endif
.endm
@@ -269,21 +223,20 @@
.macro SET_CURR_TASK_ON_CPU tsk, tmp
st \tsk, [@_current_task]
#ifdef CONFIG_ARC_CURR_IN_REG
- mov r25, \tsk
+ mov gp, \tsk
#endif
.endm
#endif /* SMP / UNI */
-/* ------------------------------------------------------------------
+/*
* Get the ptr to some field of Current Task at @off in task struct
- * -Uses r25 for Current task ptr if that is enabled
+ * - Uses current task cached in reg if enabled
*/
-
#ifdef CONFIG_ARC_CURR_IN_REG
.macro GET_CURR_TASK_FIELD_PTR off, reg
- add \reg, r25, \off
+ add \reg, gp, \off
.endm
#else
@@ -295,4 +248,23 @@
#endif /* CONFIG_ARC_CURR_IN_REG */
+#else /* !__ASSEMBLY__ */
+
+extern void do_signal(struct pt_regs *);
+extern void do_notify_resume(struct pt_regs *);
+extern int do_privilege_fault(unsigned long, struct pt_regs *);
+extern int do_extension_fault(unsigned long, struct pt_regs *);
+extern int insterror_is_error(unsigned long, struct pt_regs *);
+extern int do_memory_error(unsigned long, struct pt_regs *);
+extern int trap_is_brkpt(unsigned long, struct pt_regs *);
+extern int do_misaligned_error(unsigned long, struct pt_regs *);
+extern int do_trap5_error(unsigned long, struct pt_regs *);
+extern int do_misaligned_access(unsigned long, struct pt_regs *, struct callee_regs *);
+extern void do_machine_check_fault(unsigned long, struct pt_regs *);
+extern void do_non_swi_trap(unsigned long, struct pt_regs *);
+extern void do_insterror_or_kprobe(unsigned long, struct pt_regs *);
+extern void do_page_fault(unsigned long, struct pt_regs *);
+
+#endif
+
#endif /* __ASM_ARC_ENTRY_H */
diff --git a/arch/arc/include/asm/hugepage.h b/arch/arc/include/asm/hugepage.h
index 5001b79..ef8d416 100644
--- a/arch/arc/include/asm/hugepage.h
+++ b/arch/arc/include/asm/hugepage.h
@@ -21,7 +21,7 @@ static inline pmd_t pte_pmd(pte_t pte)
}
#define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd)))
-#define pmd_mkwrite(pmd) pte_pmd(pte_mkwrite(pmd_pte(pmd)))
+#define pmd_mkwrite_novma(pmd) pte_pmd(pte_mkwrite_novma(pmd_pte(pmd)))
#define pmd_mkdirty(pmd) pte_pmd(pte_mkdirty(pmd_pte(pmd)))
#define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
#define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd)))
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 8034738..4fdb735 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -21,8 +21,9 @@
#endif
extern void __iomem *ioremap(phys_addr_t paddr, unsigned long size);
-extern void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size,
- unsigned long flags);
+#define ioremap ioremap
+#define ioremap_prot ioremap_prot
+#define iounmap iounmap
static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
{
return (void __iomem *)port;
@@ -32,8 +33,6 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const volatile void __iomem *addr);
-
/*
* io{read,write}{16,32}be() macros
*/
diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h
index 0309cb4..c574712 100644
--- a/arch/arc/include/asm/irq.h
+++ b/arch/arc/include/asm/irq.h
@@ -25,5 +25,6 @@
#include <asm-generic/irq.h>
extern void arc_init_IRQ(void);
+extern void arch_do_IRQ(unsigned int, struct pt_regs *);
#endif
diff --git a/arch/arc/include/asm/mmu.h b/arch/arc/include/asm/mmu.h
index ca427c3..9febf5b 100644
--- a/arch/arc/include/asm/mmu.h
+++ b/arch/arc/include/asm/mmu.h
@@ -14,6 +14,8 @@ typedef struct {
unsigned long asid[NR_CPUS]; /* 8 bit MMU PID + Generation cycle */
} mm_context_t;
+extern void do_tlb_overlap_fault(unsigned long, unsigned long, struct pt_regs *);
+
#endif
#include <asm/mmu-arcv2.h>
diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h
index e43fe27..02b53ad 100644
--- a/arch/arc/include/asm/page.h
+++ b/arch/arc/include/asm/page.h
@@ -108,7 +108,7 @@ extern int pfn_valid(unsigned long pfn);
#else /* CONFIG_HIGHMEM */
-#define ARCH_PFN_OFFSET virt_to_pfn(CONFIG_LINUX_RAM_BASE)
+#define ARCH_PFN_OFFSET virt_to_pfn((void *)CONFIG_LINUX_RAM_BASE)
#endif /* CONFIG_HIGHMEM */
diff --git a/arch/arc/include/asm/pgtable-bits-arcv2.h b/arch/arc/include/asm/pgtable-bits-arcv2.h
index 6e9f8ca..f3eea3f 100644
--- a/arch/arc/include/asm/pgtable-bits-arcv2.h
+++ b/arch/arc/include/asm/pgtable-bits-arcv2.h
@@ -87,7 +87,7 @@
PTE_BIT_FUNC(mknotpresent, &= ~(_PAGE_PRESENT));
PTE_BIT_FUNC(wrprotect, &= ~(_PAGE_WRITE));
-PTE_BIT_FUNC(mkwrite, |= (_PAGE_WRITE));
+PTE_BIT_FUNC(mkwrite_novma, |= (_PAGE_WRITE));
PTE_BIT_FUNC(mkclean, &= ~(_PAGE_DIRTY));
PTE_BIT_FUNC(mkdirty, |= (_PAGE_DIRTY));
PTE_BIT_FUNC(mkold, &= ~(_PAGE_ACCESSED));
@@ -100,14 +100,12 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
return __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot));
}
-static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pteval)
-{
- set_pte(ptep, pteval);
-}
+struct vm_fault;
+void update_mmu_cache_range(struct vm_fault *vmf, struct vm_area_struct *vma,
+ unsigned long address, pte_t *ptep, unsigned int nr);
-void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
- pte_t *ptep);
+#define update_mmu_cache(vma, addr, ptep) \
+ update_mmu_cache_range(NULL, vma, addr, ptep, 1)
/*
* Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
diff --git a/arch/arc/include/asm/pgtable-levels.h b/arch/arc/include/asm/pgtable-levels.h
index ef68758..fc417c7 100644
--- a/arch/arc/include/asm/pgtable-levels.h
+++ b/arch/arc/include/asm/pgtable-levels.h
@@ -169,6 +169,7 @@
#define pte_ERROR(e) \
pr_crit("%s:%d: bad pte %08lx.\n", __FILE__, __LINE__, pte_val(e))
+#define PFN_PTE_SHIFT PAGE_SHIFT
#define pte_none(x) (!pte_val(x))
#define pte_present(x) (pte_val(x) & _PAGE_PRESENT)
#define pte_clear(mm,addr,ptep) set_pte_at(mm, addr, ptep, __pte(0))
diff --git a/arch/arc/include/asm/processor.h b/arch/arc/include/asm/processor.h
index fb844fc..d606658 100644
--- a/arch/arc/include/asm/processor.h
+++ b/arch/arc/include/asm/processor.h
@@ -22,7 +22,6 @@
* struct thread_info
*/
struct thread_struct {
- unsigned long ksp; /* kernel mode stack pointer */
unsigned long callee_reg; /* pointer to callee regs */
unsigned long fault_address; /* dbls as brkpt holder as well */
#ifdef CONFIG_ARC_DSP_SAVE_RESTORE_REGS
@@ -33,9 +32,7 @@ struct thread_struct {
#endif
};
-#define INIT_THREAD { \
- .ksp = sizeof(init_stack) + (unsigned long) init_stack, \
-}
+#define INIT_THREAD { }
/* Forward declaration, a strange C thing */
struct task_struct;
@@ -56,7 +53,7 @@ struct task_struct;
* Where about of Task's sp, fp, blink when it was last seen in kernel mode.
* Look in process.c for details of kernel stack layout
*/
-#define TSK_K_ESP(tsk) (tsk->thread.ksp)
+#define TSK_K_ESP(tsk) (task_thread_info(tsk)->ksp)
#define TSK_K_REG(tsk, off) (*((unsigned long *)(TSK_K_ESP(tsk) + \
sizeof(struct callee_regs) + off)))
diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 5869a74..4a2b30f 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -12,6 +12,17 @@
#ifndef __ASSEMBLY__
+typedef union {
+ struct {
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ unsigned long state:8, vec:8, cause:8, param:8;
+#else
+ unsigned long param:8, cause:8, vec:8, state:8;
+#endif
+ };
+ unsigned long full;
+} ecr_reg;
+
/* THE pt_regs: Defines how regs are saved during entry into kernel */
#ifdef CONFIG_ISA_ARCOMPACT
@@ -40,23 +51,10 @@ struct pt_regs {
* Last word used by Linux for extra state mgmt (syscall-restart)
* For interrupts, use artificial ECR values to note current prio-level
*/
- union {
- struct {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned long state:8, ecr_vec:8,
- ecr_cause:8, ecr_param:8;
-#else
- unsigned long ecr_param:8, ecr_cause:8,
- ecr_vec:8, state:8;
-#endif
- };
- unsigned long event;
- };
-
- unsigned long user_r25;
+ ecr_reg ecr;
};
-#define MAX_REG_OFFSET offsetof(struct pt_regs, user_r25)
+#define MAX_REG_OFFSET offsetof(struct pt_regs, ecr)
#else
@@ -64,28 +62,14 @@ struct pt_regs {
unsigned long orig_r0;
- union {
- struct {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned long state:8, ecr_vec:8,
- ecr_cause:8, ecr_param:8;
-#else
- unsigned long ecr_param:8, ecr_cause:8,
- ecr_vec:8, state:8;
-#endif
- };
- unsigned long event;
- };
+ ecr_reg ecr; /* Exception Cause Reg */
- unsigned long bta; /* bta_l1, bta_l2, erbta */
+ unsigned long bta; /* erbta */
- unsigned long user_r25;
-
- unsigned long r26; /* gp */
unsigned long fp;
- unsigned long sp; /* user/kernel sp depending on where we came from */
-
- unsigned long r12, r30;
+ unsigned long r30;
+ unsigned long r12;
+ unsigned long r26; /* gp */
#ifdef CONFIG_ARC_HAS_ACCL_REGS
unsigned long r58, r59; /* ACCL/ACCH used by FPU / DSP MPY */
@@ -94,6 +78,8 @@ struct pt_regs {
unsigned long DSP_CTRL;
#endif
+ unsigned long sp; /* user/kernel sp depending on entry */
+
/*------- Below list auto saved by h/w -----------*/
unsigned long r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11;
@@ -134,13 +120,13 @@ struct callee_regs {
/* return 1 if PC in delay slot */
#define delay_mode(regs) ((regs->status32 & STATUS_DE_MASK) == STATUS_DE_MASK)
-#define in_syscall(regs) ((regs->ecr_vec == ECR_V_TRAP) && !regs->ecr_param)
-#define in_brkpt_trap(regs) ((regs->ecr_vec == ECR_V_TRAP) && regs->ecr_param)
+#define in_syscall(regs) ((regs->ecr.vec == ECR_V_TRAP) && !regs->ecr.param)
+#define in_brkpt_trap(regs) ((regs->ecr.vec == ECR_V_TRAP) && regs->ecr.param)
#define STATE_SCALL_RESTARTED 0x01
-#define syscall_wont_restart(reg) (reg->state |= STATE_SCALL_RESTARTED)
-#define syscall_restartable(reg) !(reg->state & STATE_SCALL_RESTARTED)
+#define syscall_wont_restart(regs) (regs->ecr.state |= STATE_SCALL_RESTARTED)
+#define syscall_restartable(regs) !(regs->ecr.state & STATE_SCALL_RESTARTED)
#define current_pt_regs() \
({ \
@@ -181,6 +167,9 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
return *(unsigned long *)((unsigned long)regs + offset);
}
+extern int syscall_trace_entry(struct pt_regs *);
+extern void syscall_trace_exit(struct pt_regs *);
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PTRACE_H */
diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index 028a8cf..1c6db59 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -35,11 +35,11 @@ long __init arc_get_mem_sz(void);
#define IS_AVAIL3(v, v2, s) IS_AVAIL1(v, s), IS_AVAIL1(v, IS_DISABLED_RUN(v2))
extern void arc_mmu_init(void);
-extern char *arc_mmu_mumbojumbo(int cpu_id, char *buf, int len);
-extern void read_decode_mmu_bcr(void);
+extern int arc_mmu_mumbojumbo(int cpu_id, char *buf, int len);
extern void arc_cache_init(void);
-extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len);
-extern void read_decode_cache_bcr(void);
+extern int arc_cache_mumbojumbo(int cpu_id, char *buf, int len);
+
+extern void __init handle_uboot_args(void);
#endif /* __ASMARC_SETUP_H */
diff --git a/arch/arc/include/asm/smp.h b/arch/arc/include/asm/smp.h
index d856491..e0913f5 100644
--- a/arch/arc/include/asm/smp.h
+++ b/arch/arc/include/asm/smp.h
@@ -29,6 +29,8 @@ extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
extern void __init smp_init_cpus(void);
extern void first_lines_of_secondary(void);
extern const char *arc_platform_smp_cpuinfo(void);
+extern void arc_platform_smp_wait_to_boot(int);
+extern void start_kernel_secondary(void);
/*
* API expected BY platform smp code (FROM arch smp code)
diff --git a/arch/arc/include/asm/thread_info.h b/arch/arc/include/asm/thread_info.h
index 6ba7fe4..4c530cf 100644
--- a/arch/arc/include/asm/thread_info.h
+++ b/arch/arc/include/asm/thread_info.h
@@ -37,16 +37,16 @@
*/
struct thread_info {
unsigned long flags; /* low level flags */
+ unsigned long ksp; /* kernel mode stack top in __switch_to */
int preempt_count; /* 0 => preemptable, <0 => BUG */
- struct task_struct *task; /* main task structure */
- __u32 cpu; /* current CPU */
+ int cpu; /* current CPU */
unsigned long thr_ptr; /* TLS ptr */
+ struct task_struct *task; /* main task structure */
};
/*
- * macros/functions for gaining access to the thread information structure
- *
- * preempt_count needs to be 1 initially, until the scheduler is functional.
+ * initilaize thread_info for any @tsk
+ * - this is not related to init_task per se
*/
#define INIT_THREAD_INFO(tsk) \
{ \
diff --git a/arch/arc/include/asm/uaccess.h b/arch/arc/include/asm/uaccess.h
index 9971247..1e8809e 100644
--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -146,8 +146,9 @@ raw_copy_from_user(void *to, const void __user *from, unsigned long n)
if (n == 0)
return 0;
- /* unaligned */
- if (((unsigned long)to & 0x3) || ((unsigned long)from & 0x3)) {
+ /* fallback for unaligned access when hardware doesn't support */
+ if (!IS_ENABLED(CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS) &&
+ (((unsigned long)to & 0x3) || ((unsigned long)from & 0x3))) {
unsigned char tmp;
@@ -373,8 +374,9 @@ raw_copy_to_user(void __user *to, const void *from, unsigned long n)
if (n == 0)
return 0;
- /* unaligned */
- if (((unsigned long)to & 0x3) || ((unsigned long)from & 0x3)) {
+ /* fallback for unaligned access when hardware doesn't support */
+ if (!IS_ENABLED(CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS) &&
+ (((unsigned long)to & 0x3) || ((unsigned long)from & 0x3))) {
unsigned char tmp;
@@ -584,7 +586,7 @@ raw_copy_to_user(void __user *to, const void *from, unsigned long n)
return res;
}
-static inline unsigned long __arc_clear_user(void __user *to, unsigned long n)
+static inline unsigned long __clear_user(void __user *to, unsigned long n)
{
long res = n;
unsigned char *d_char = to;
@@ -626,17 +628,10 @@ static inline unsigned long __arc_clear_user(void __user *to, unsigned long n)
return res;
}
-#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
-
#define INLINE_COPY_TO_USER
#define INLINE_COPY_FROM_USER
-#define __clear_user(d, n) __arc_clear_user(d, n)
-#else
-extern unsigned long arc_clear_user_noinline(void __user *to,
- unsigned long n);
-#define __clear_user(d, n) arc_clear_user_noinline(d, n)
-#endif
+#define __clear_user __clear_user
#include <asm-generic/uaccess.h>
diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
index 0723d88..95fbf93 100644
--- a/arch/arc/kernel/Makefile
+++ b/arch/arc/kernel/Makefile
@@ -5,6 +5,8 @@
obj-y := head.o arcksyms.o setup.o irq.o reset.o ptrace.o process.o devtree.o
obj-y += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o
+obj-y += ctx_sw_asm.o
+
obj-$(CONFIG_ISA_ARCOMPACT) += entry-compact.o intc-compact.o
obj-$(CONFIG_ISA_ARCV2) += entry-arcv2.o intc-arcv2.o
@@ -24,11 +26,4 @@
CFLAGS_fpu.o += -mdpfp
endif
-ifdef CONFIG_ARC_DW2_UNWIND
-CFLAGS_ctx_sw.o += -fno-omit-frame-pointer
-obj-y += ctx_sw.o
-else
-obj-y += ctx_sw_asm.o
-endif
-
extra-y := vmlinux.lds
diff --git a/arch/arc/kernel/asm-offsets.c b/arch/arc/kernel/asm-offsets.c
index 0e88403..f77deb7 100644
--- a/arch/arc/kernel/asm-offsets.c
+++ b/arch/arc/kernel/asm-offsets.c
@@ -20,13 +20,13 @@ int main(void)
BLANK();
- DEFINE(THREAD_KSP, offsetof(struct thread_struct, ksp));
DEFINE(THREAD_CALLEE_REG, offsetof(struct thread_struct, callee_reg));
DEFINE(THREAD_FAULT_ADDR,
offsetof(struct thread_struct, fault_address));
BLANK();
+ DEFINE(THREAD_INFO_KSP, offsetof(struct thread_info, ksp));
DEFINE(THREAD_INFO_FLAGS, offsetof(struct thread_info, flags));
DEFINE(THREAD_INFO_PREEMPT_COUNT,
offsetof(struct thread_info, preempt_count));
@@ -46,7 +46,8 @@ int main(void)
BLANK();
DEFINE(PT_status32, offsetof(struct pt_regs, status32));
- DEFINE(PT_event, offsetof(struct pt_regs, event));
+ DEFINE(PT_event, offsetof(struct pt_regs, ecr));
+ DEFINE(PT_bta, offsetof(struct pt_regs, bta));
DEFINE(PT_sp, offsetof(struct pt_regs, sp));
DEFINE(PT_r0, offsetof(struct pt_regs, r0));
DEFINE(PT_r1, offsetof(struct pt_regs, r1));
@@ -61,13 +62,9 @@ int main(void)
DEFINE(PT_r26, offsetof(struct pt_regs, r26));
DEFINE(PT_ret, offsetof(struct pt_regs, ret));
DEFINE(PT_blink, offsetof(struct pt_regs, blink));
+ OFFSET(PT_fp, pt_regs, fp);
DEFINE(PT_lpe, offsetof(struct pt_regs, lp_end));
DEFINE(PT_lpc, offsetof(struct pt_regs, lp_count));
- DEFINE(PT_user_r25, offsetof(struct pt_regs, user_r25));
-
- DEFINE(SZ_CALLEE_REGS, sizeof(struct callee_regs));
- DEFINE(SZ_PT_REGS, sizeof(struct pt_regs));
-
#ifdef CONFIG_ISA_ARCV2
OFFSET(PT_r12, pt_regs, r12);
OFFSET(PT_r30, pt_regs, r30);
@@ -80,5 +77,8 @@ int main(void)
OFFSET(PT_DSP_CTRL, pt_regs, DSP_CTRL);
#endif
+ DEFINE(SZ_CALLEE_REGS, sizeof(struct callee_regs));
+ DEFINE(SZ_PT_REGS, sizeof(struct pt_regs));
+
return 0;
}
diff --git a/arch/arc/kernel/ctx_sw.c b/arch/arc/kernel/ctx_sw.c
deleted file mode 100644
index 1a76f2d..0000000
--- a/arch/arc/kernel/ctx_sw.c
+++ /dev/null
@@ -1,112 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
- *
- * Vineetg: Aug 2009
- * -"C" version of lowest level context switch asm macro called by schedular
- * gcc doesn't generate the dward CFI info for hand written asm, hence can't
- * backtrace out of it (e.g. tasks sleeping in kernel).
- * So we cheat a bit by writing almost similar code in inline-asm.
- * -This is a hacky way of doing things, but there is no other simple way.
- * I don't want/intend to extend unwinding code to understand raw asm
- */
-
-#include <asm/asm-offsets.h>
-#include <linux/sched.h>
-#include <linux/sched/debug.h>
-
-#define KSP_WORD_OFF ((TASK_THREAD + THREAD_KSP) / 4)
-
-struct task_struct *__sched
-__switch_to(struct task_struct *prev_task, struct task_struct *next_task)
-{
- unsigned int tmp;
- unsigned int prev = (unsigned int)prev_task;
- unsigned int next = (unsigned int)next_task;
-
- __asm__ __volatile__(
- /* FP/BLINK save generated by gcc (standard function prologue */
- "st.a r13, [sp, -4] \n\t"
- "st.a r14, [sp, -4] \n\t"
- "st.a r15, [sp, -4] \n\t"
- "st.a r16, [sp, -4] \n\t"
- "st.a r17, [sp, -4] \n\t"
- "st.a r18, [sp, -4] \n\t"
- "st.a r19, [sp, -4] \n\t"
- "st.a r20, [sp, -4] \n\t"
- "st.a r21, [sp, -4] \n\t"
- "st.a r22, [sp, -4] \n\t"
- "st.a r23, [sp, -4] \n\t"
- "st.a r24, [sp, -4] \n\t"
-#ifndef CONFIG_ARC_CURR_IN_REG
- "st.a r25, [sp, -4] \n\t"
-#else
- "sub sp, sp, 4 \n\t" /* usual r25 placeholder */
-#endif
-
- /* set ksp of outgoing task in tsk->thread.ksp */
-#if KSP_WORD_OFF <= 255
- "st.as sp, [%3, %1] \n\t"
-#else
- /*
- * Workaround for NR_CPUS=4k
- * %1 is bigger than 255 (S9 offset for st.as)
- */
- "add2 r24, %3, %1 \n\t"
- "st sp, [r24] \n\t"
-#endif
-
- /*
- * setup _current_task with incoming tsk.
- * optionally, set r25 to that as well
- * For SMP extra work to get to &_current_task[cpu]
- * (open coded SET_CURR_TASK_ON_CPU)
- */
-#ifndef CONFIG_SMP
- "st %2, [@_current_task] \n\t"
-#else
- "lr r24, [identity] \n\t"
- "lsr r24, r24, 8 \n\t"
- "bmsk r24, r24, 7 \n\t"
- "add2 r24, @_current_task, r24 \n\t"
- "st %2, [r24] \n\t"
-#endif
-#ifdef CONFIG_ARC_CURR_IN_REG
- "mov r25, %2 \n\t"
-#endif
-
- /* get ksp of incoming task from tsk->thread.ksp */
- "ld.as sp, [%2, %1] \n\t"
-
- /* start loading it's CALLEE reg file */
-
-#ifndef CONFIG_ARC_CURR_IN_REG
- "ld.ab r25, [sp, 4] \n\t"
-#else
- "add sp, sp, 4 \n\t"
-#endif
- "ld.ab r24, [sp, 4] \n\t"
- "ld.ab r23, [sp, 4] \n\t"
- "ld.ab r22, [sp, 4] \n\t"
- "ld.ab r21, [sp, 4] \n\t"
- "ld.ab r20, [sp, 4] \n\t"
- "ld.ab r19, [sp, 4] \n\t"
- "ld.ab r18, [sp, 4] \n\t"
- "ld.ab r17, [sp, 4] \n\t"
- "ld.ab r16, [sp, 4] \n\t"
- "ld.ab r15, [sp, 4] \n\t"
- "ld.ab r14, [sp, 4] \n\t"
- "ld.ab r13, [sp, 4] \n\t"
-
- /* last (ret value) = prev : although for ARC it mov r0, r0 */
- "mov %0, %3 \n\t"
-
- /* FP/BLINK restore generated by gcc (standard func epilogue */
-
- : "=r"(tmp)
- : "n"(KSP_WORD_OFF), "r"(next), "r"(prev)
- : "blink"
- );
-
- return (struct task_struct *)tmp;
-}
diff --git a/arch/arc/kernel/ctx_sw_asm.S b/arch/arc/kernel/ctx_sw_asm.S
index 02c4614..48e1f21 100644
--- a/arch/arc/kernel/ctx_sw_asm.S
+++ b/arch/arc/kernel/ctx_sw_asm.S
@@ -11,50 +11,54 @@
#include <asm/entry.h> /* For the SAVE_* macros */
#include <asm/asm-offsets.h>
-#define KSP_WORD_OFF ((TASK_THREAD + THREAD_KSP) / 4)
-
-;################### Low Level Context Switch ##########################
+; IN
+; - r0: prev task (also current)
+; - r1: next task
+; OUT
+; - r0: prev task (so r0 not touched)
.section .sched.text,"ax",@progbits
- .align 4
- .global __switch_to
- .type __switch_to, @function
-__switch_to:
- CFI_STARTPROC
+ENTRY_CFI(__switch_to)
- /* Save regs on kernel mode stack of task */
- st.a blink, [sp, -4]
- st.a fp, [sp, -4]
+ /* save kernel stack frame regs of @prev task */
+ push blink
+ CFI_DEF_CFA_OFFSET 4
+ CFI_OFFSET r31, -4
+
+ push fp
+ CFI_DEF_CFA_OFFSET 8
+ CFI_OFFSET r27, -8
+
+ mov fp, sp
+ CFI_DEF_CFA_REGISTER r27
+
+ /* kernel mode callee regs of @prev */
SAVE_CALLEE_SAVED_KERNEL
- /* Save the now KSP in task->thread.ksp */
-#if KSP_WORD_OFF <= 255
- st.as sp, [r0, KSP_WORD_OFF]
-#else
- /* Workaround for NR_CPUS=4k as ST.as can only take s9 offset */
- add2 r24, r0, KSP_WORD_OFF
- st sp, [r24]
-#endif
/*
- * Return last task in r0 (return reg)
- * On ARC, Return reg = First Arg reg = r0.
- * Since we already have last task in r0,
- * don't need to do anything special to return it
- */
-
- /*
- * switch to new task, contained in r1
- * Temp reg r3 is required to get the ptr to store val
+ * save final SP to @prev->thread_info.ksp
+ * @prev is "current" so thread_info derived from SP
*/
- SET_CURR_TASK_ON_CPU r1, r3
+ GET_CURR_THR_INFO_FROM_SP r10
+ st sp, [r10, THREAD_INFO_KSP]
- /* reload SP with kernel mode stack pointer in task->thread.ksp */
- ld.as sp, [r1, (TASK_THREAD + THREAD_KSP)/4]
+ /* update @next in _current_task[] and GP register caching it */
+ SET_CURR_TASK_ON_CPU r1, r10
- /* restore the registers */
+ /* load SP from @next->thread_info.ksp */
+ ld r10, [r1, TASK_THREAD_INFO]
+ ld sp, [r10, THREAD_INFO_KSP]
+
+ /* restore callee regs, stack frame regs of @next */
RESTORE_CALLEE_SAVED_KERNEL
- ld.ab fp, [sp, 4]
- ld.ab blink, [sp, 4]
- j [blink]
+ pop fp
+ CFI_RESTORE r27
+ CFI_DEF_CFA r28, 4
+
+ pop blink
+ CFI_RESTORE r31
+ CFI_DEF_CFA_OFFSET 0
+
+ j [blink]
END_CFI(__switch_to)
diff --git a/arch/arc/kernel/devtree.c b/arch/arc/kernel/devtree.c
index 721d465..4c9e614 100644
--- a/arch/arc/kernel/devtree.c
+++ b/arch/arc/kernel/devtree.c
@@ -12,6 +12,7 @@
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <asm/mach_desc.h>
+#include <asm/serial.h>
#ifdef CONFIG_SERIAL_EARLYCON
diff --git a/arch/arc/kernel/entry-arcv2.S b/arch/arc/kernel/entry-arcv2.S
index a7e6a21..2e49c81 100644
--- a/arch/arc/kernel/entry-arcv2.S
+++ b/arch/arc/kernel/entry-arcv2.S
@@ -125,11 +125,6 @@
EXCEPTION_PROLOGUE
- lr r0, [efa]
- mov r1, sp
-
- FAKE_RET_FROM_EXCPN
-
bl do_memory_error
b ret_from_exception
END(mem_service)
@@ -138,11 +133,6 @@
EXCEPTION_PROLOGUE
- lr r0, [efa] ; Faulting Data address
- mov r1, sp
-
- FAKE_RET_FROM_EXCPN
-
SAVE_CALLEE_SAVED_USER
mov r2, sp ; callee_regs
@@ -163,11 +153,6 @@
EXCEPTION_PROLOGUE
- lr r0, [efa] ; Faulting Data address
- mov r1, sp ; pt_regs
-
- FAKE_RET_FROM_EXCPN
-
mov blink, ret_from_exception
b do_page_fault
diff --git a/arch/arc/kernel/entry-compact.S b/arch/arc/kernel/entry-compact.S
index 5cb0cd7..774c03c 100644
--- a/arch/arc/kernel/entry-compact.S
+++ b/arch/arc/kernel/entry-compact.S
@@ -254,18 +254,7 @@
ENTRY(EV_TLBProtV)
- EXCEPTION_PROLOGUE
-
- mov r2, r10 ; ECR set into r10 already
- lr r0, [efa] ; Faulting Data address (not part of pt_regs saved above)
-
- ; Exception auto-disables further Intr/exceptions.
- ; Re-enable them by pretending to return from exception
- ; (so rest of handler executes in pure K mode)
-
- FAKE_RET_FROM_EXCPN
-
- mov r1, sp ; Handle to pt_regs
+ EXCEPTION_PROLOGUE ; ECR returned in r10
;------ (5) Type of Protection Violation? ----------
;
@@ -273,8 +262,7 @@
; -Access Violation : 00_23_(00|01|02|03)_00
; x r w r+w
; -Unaligned Access : 00_23_04_00
- ;
- bbit1 r2, ECR_C_BIT_PROTV_MISALIG_DATA, 4f
+ bbit1 r10, ECR_C_BIT_PROTV_MISALIG_DATA, 4f
;========= (6a) Access Violation Processing ========
bl do_page_fault
@@ -303,9 +291,6 @@
ENTRY(call_do_page_fault)
EXCEPTION_PROLOGUE
- lr r0, [efa] ; Faulting Data address
- mov r1, sp
- FAKE_RET_FROM_EXCPN
mov blink, ret_from_exception
b do_page_fault
diff --git a/arch/arc/kernel/entry.S b/arch/arc/kernel/entry.S
index 54e91df..089f668 100644
--- a/arch/arc/kernel/entry.S
+++ b/arch/arc/kernel/entry.S
@@ -80,11 +80,6 @@
EXCEPTION_PROLOGUE
- lr r0, [efa]
- mov r1, sp
-
- FAKE_RET_FROM_EXCPN
-
bl do_insterror_or_kprobe
b ret_from_exception
END(instr_service)
@@ -95,16 +90,15 @@
ENTRY(EV_MachineCheck)
- EXCEPTION_PROLOGUE
+ EXCEPTION_PROLOGUE_KEEP_AE ; ECR returned in r10
- lr r2, [ecr]
lr r0, [efa]
mov r1, sp
; MC excpetions disable MMU
ARC_MMU_REENABLE r3
- lsr r3, r2, 8
+ lsr r3, r10, 8
bmsk r3, r3, 7
brne r3, ECR_C_MCHK_DUP_TLB, 1f
@@ -129,11 +123,6 @@
EXCEPTION_PROLOGUE
- lr r0, [efa]
- mov r1, sp
-
- FAKE_RET_FROM_EXCPN
-
bl do_privilege_fault
b ret_from_exception
END(EV_PrivilegeV)
@@ -145,11 +134,6 @@
EXCEPTION_PROLOGUE
- lr r0, [efa]
- mov r1, sp
-
- FAKE_RET_FROM_EXCPN
-
bl do_extension_fault
b ret_from_exception
END(EV_Extension)
@@ -160,20 +144,19 @@
; syscall Tracing
; ---------------------------------------------
tracesys:
- ; save EFA in case tracer wants the PC of traced task
- ; using ERET won't work since next-PC has already committed
+ ; safekeep EFA (r12) if syscall tracer wanted PC
+ ; for traps, ERET is pre-commit so points to next-PC
GET_CURR_TASK_FIELD_PTR TASK_THREAD, r11
st r12, [r11, THREAD_FAULT_ADDR] ; thread.fault_address
- ; PRE Sys Call Ptrace hook
- mov r0, sp ; pt_regs needed
- bl @syscall_trace_entry
+ ; PRE syscall trace hook
+ mov r0, sp ; pt_regs
+ bl @syscall_trace_enter
; Tracing code now returns the syscall num (orig or modif)
mov r8, r0
; Do the Sys Call as we normally would.
- ; Validate the Sys Call number
cmp r8, NR_syscalls - 1
mov.hi r0, -ENOSYS
bhi tracesys_exit
@@ -190,37 +173,36 @@
ld r6, [sp, PT_r6]
ld r7, [sp, PT_r7]
ld.as r9, [sys_call_table, r8]
- jl [r9] ; Entry into Sys Call Handler
+ jl [r9]
tracesys_exit:
- st r0, [sp, PT_r0] ; sys call return value in pt_regs
+ st r0, [sp, PT_r0]
- ;POST Sys Call Ptrace Hook
+ ; POST syscall trace hook
mov r0, sp ; pt_regs needed
bl @syscall_trace_exit
- b ret_from_exception ; NOT ret_from_system_call at is saves r0 which
- ; we'd done before calling post hook above
+
+ ; don't call ret_from_system_call as it saves r0, already done above
+ b ret_from_exception
; ---------------------------------------------
; Breakpoint TRAP
; ---------------------------------------------
trap_with_param:
mov r0, r12 ; EFA in case ptracer/gdb wants stop_pc
- mov r1, sp
+ mov r1, sp ; pt_regs
- ; Save callee regs in case gdb wants to have a look
- ; SP will grow up by size of CALLEE Reg-File
- ; NOTE: clobbers r12
+ ; save callee regs in case tracer/gdb wants to peek
SAVE_CALLEE_SAVED_USER
- ; save location of saved Callee Regs @ thread_struct->pc
+ ; safekeep ref to callee regs
GET_CURR_TASK_FIELD_PTR TASK_THREAD, r10
st sp, [r10, THREAD_CALLEE_REG]
- ; Call the trap handler
+ ; call the non syscall trap handler
bl do_non_swi_trap
- ; unwind stack to discard Callee saved Regs
+ ; unwind stack to discard callee regs
DISCARD_CALLEE_SAVED_USER
b ret_from_exception
@@ -232,37 +214,33 @@
ENTRY(EV_Trap)
- EXCEPTION_PROLOGUE
+ EXCEPTION_PROLOGUE_KEEP_AE
lr r12, [efa]
FAKE_RET_FROM_EXCPN
- ;============ TRAP 1 :breakpoints
- ; Check ECR for trap with arg (PROLOGUE ensures r10 has ECR)
+ ;============ TRAP N : breakpoints, kprobes etc
bmsk.f 0, r10, 7
bnz trap_with_param
- ;============ TRAP (no param): syscall top level
+ ;============ TRAP 0 (no param): syscall
- ; If syscall tracing ongoing, invoke pre-post-hooks
+ ; syscall tracing ongoing, invoke pre-post-hooks around syscall
GET_CURR_THR_INFO_FLAGS r10
and.f 0, r10, _TIF_SYSCALL_WORK
bnz tracesys ; this never comes back
;============ Normal syscall case
- ; syscall num shd not exceed the total system calls avail
cmp r8, NR_syscalls - 1
mov.hi r0, -ENOSYS
bhi .Lret_from_system_call
- ; Offset into the syscall_table and call handler
ld.as r9,[sys_call_table, r8]
- jl [r9] ; Entry into Sys Call Handler
+ jl [r9]
.Lret_from_system_call:
-
st r0, [sp, PT_r0] ; sys call return value in pt_regs
; fall through to ret_from_exception
@@ -318,7 +296,7 @@
; tracer might call PEEKUSR(CALLEE reg)
;
; NOTE: SP will grow up by size of CALLEE Reg-File
- SAVE_CALLEE_SAVED_USER ; clobbers r12
+ SAVE_CALLEE_SAVED_USER
; save location of saved Callee Regs @ thread_struct->callee
GET_CURR_TASK_FIELD_PTR TASK_THREAD, r10
diff --git a/arch/arc/kernel/intc-arcv2.c b/arch/arc/kernel/intc-arcv2.c
index 5cda19d..6788987 100644
--- a/arch/arc/kernel/intc-arcv2.c
+++ b/arch/arc/kernel/intc-arcv2.c
@@ -108,7 +108,7 @@ static void arcv2_irq_unmask(struct irq_data *data)
write_aux_reg(AUX_IRQ_ENABLE, 1);
}
-void arcv2_irq_enable(struct irq_data *data)
+static void arcv2_irq_enable(struct irq_data *data)
{
/* set default priority */
write_aux_reg(AUX_IRQ_SELECT, data->hwirq);
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 345a000..4f2b595 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -175,7 +175,7 @@ void kgdb_trap(struct pt_regs *regs)
* with trap_s 4 (compiled) breakpoints, continuation needs to
* start after the breakpoint.
*/
- if (regs->ecr_param == 3)
+ if (regs->ecr.param == 3)
instruction_pointer(regs) -= BREAK_INSTR_SIZE;
kgdb_handle_exception(1, SIGTRAP, 0, regs);
diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c
index f9fdb55..55373ca 100644
--- a/arch/arc/kernel/mcip.c
+++ b/arch/arc/kernel/mcip.c
@@ -165,8 +165,6 @@ static void mcip_probe_n_setup(void)
IS_AVAIL1(mp.idu, "IDU "),
IS_AVAIL1(mp.dbg, "DEBUG "),
IS_AVAIL1(mp.gfrc, "GFRC"));
-
- cpuinfo_arc700[0].extn.gfrc = mp.gfrc;
}
struct plat_smp_ops plat_smp_ops = {
diff --git a/arch/arc/kernel/process.c b/arch/arc/kernel/process.c
index 980b71d..186ceab 100644
--- a/arch/arc/kernel/process.c
+++ b/arch/arc/kernel/process.c
@@ -141,7 +141,7 @@ asmlinkage void ret_from_fork(void);
* | unused |
* | |
* ------------------
- * | r25 | <==== top of Stack (thread.ksp)
+ * | r25 | <==== top of Stack (thread_info.ksp)
* ~ ~
* | --to-- | (CALLEE Regs of kernel mode)
* | r13 |
@@ -162,7 +162,6 @@ asmlinkage void ret_from_fork(void);
* | SP |
* | orig_r0 |
* | event/ECR |
- * | user_r25 |
* ------------------ <===== END of PAGE
*/
int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
@@ -182,14 +181,14 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
c_callee = ((struct callee_regs *)childksp) - 1;
/*
- * __switch_to() uses thread.ksp to start unwinding stack
+ * __switch_to() uses thread_info.ksp to start unwinding stack
* For kernel threads we don't need to create callee regs, the
* stack layout nevertheless needs to remain the same.
* Also, since __switch_to anyways unwinds callee regs, we use
* this to populate kernel thread entry-pt/args into callee regs,
* so that ret_from_kernel_thread() becomes simpler.
*/
- p->thread.ksp = (unsigned long)c_callee; /* THREAD_KSP */
+ task_thread_info(p)->ksp = (unsigned long)c_callee; /* THREAD_INFO_KSP */
/* __switch_to expects FP(0), BLINK(return addr) at top */
childksp[0] = 0; /* fp */
@@ -243,16 +242,6 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
*/
c_callee->r25 = task_thread_info(p)->thr_ptr;
-#ifdef CONFIG_ARC_CURR_IN_REG
- /*
- * setup usermode thread pointer #2:
- * however for this special use of r25 in kernel, __switch_to() sets
- * r25 for kernel needs and only in the final return path is usermode
- * r25 setup, from pt_regs->user_r25. So set that up as well
- */
- c_regs->user_r25 = c_callee->r25;
-#endif
-
return 0;
}
diff --git a/arch/arc/kernel/ptrace.c b/arch/arc/kernel/ptrace.c
index 2abdcd9..e0c233c 100644
--- a/arch/arc/kernel/ptrace.c
+++ b/arch/arc/kernel/ptrace.c
@@ -46,8 +46,7 @@ static const struct pt_regs_offset regoffset_table[] = {
REG_OFFSET_NAME(r0),
REG_OFFSET_NAME(sp),
REG_OFFSET_NAME(orig_r0),
- REG_OFFSET_NAME(event),
- REG_OFFSET_NAME(user_r25),
+ REG_OFFSET_NAME(ecr),
REG_OFFSET_END,
};
@@ -55,9 +54,8 @@ static const struct pt_regs_offset regoffset_table[] = {
static const struct pt_regs_offset regoffset_table[] = {
REG_OFFSET_NAME(orig_r0),
- REG_OFFSET_NAME(event),
+ REG_OFFSET_NAME(ecr),
REG_OFFSET_NAME(bta),
- REG_OFFSET_NAME(user_r25),
REG_OFFSET_NAME(r26),
REG_OFFSET_NAME(fp),
REG_OFFSET_NAME(sp),
@@ -341,7 +339,7 @@ long arch_ptrace(struct task_struct *child, long request,
return ret;
}
-asmlinkage int syscall_trace_entry(struct pt_regs *regs)
+asmlinkage int syscall_trace_enter(struct pt_regs *regs)
{
if (test_thread_flag(TIF_SYSCALL_TRACE))
if (ptrace_report_syscall_entry(regs))
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 41f07b3..4dcf858 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -29,6 +29,7 @@
#include <asm/mach_desc.h>
#include <asm/smp.h>
#include <asm/dsp-impl.h>
+#include <soc/arc/mcip.h>
#define FIX_PTR(x) __asm__ __volatile__(";" : "+r"(x))
@@ -43,19 +44,22 @@ const struct machine_desc *machine_desc;
struct task_struct *_current_task[NR_CPUS]; /* For stack switching */
-struct cpuinfo_arc cpuinfo_arc700[NR_CPUS];
+struct cpuinfo_arc {
+ int arcver;
+ unsigned int t0:1, t1:1;
+ struct {
+ unsigned long base;
+ unsigned int sz;
+ } iccm, dccm;
+};
-static const struct id_to_str arc_legacy_rel[] = {
+#ifdef CONFIG_ISA_ARCV2
+
+static const struct id_to_str arc_hs_rel[] = {
/* ID.ARCVER, Release */
-#ifdef CONFIG_ISA_ARCOMPACT
- { 0x34, "R4.10"},
- { 0x35, "R4.11"},
-#else
{ 0x51, "R2.0" },
{ 0x52, "R2.1" },
{ 0x53, "R3.0" },
-#endif
- { 0x00, NULL }
};
static const struct id_to_str arc_hs_ver54_rel[] = {
@@ -66,324 +70,297 @@ static const struct id_to_str arc_hs_ver54_rel[] = {
{ 3, "R4.00a"},
{ 0xFF, NULL }
};
+#endif
-static void read_decode_ccm_bcr(struct cpuinfo_arc *cpu)
+static int
+arcompact_mumbojumbo(int c, struct cpuinfo_arc *info, char *buf, int len)
{
- if (is_isa_arcompact()) {
- struct bcr_iccm_arcompact iccm;
- struct bcr_dccm_arcompact dccm;
+ int n = 0;
+#ifdef CONFIG_ISA_ARCOMPACT
+ char *cpu_nm, *isa_nm = "ARCompact";
+ struct bcr_fp_arcompact fpu_sp, fpu_dp;
+ int atomic = 0, be, present;
+ int bpu_full, bpu_cache, bpu_pred;
+ struct bcr_bpu_arcompact bpu;
+ struct bcr_iccm_arcompact iccm;
+ struct bcr_dccm_arcompact dccm;
+ struct bcr_generic isa;
- READ_BCR(ARC_REG_ICCM_BUILD, iccm);
- if (iccm.ver) {
- cpu->iccm.sz = 4096 << iccm.sz; /* 8K to 512K */
- cpu->iccm.base_addr = iccm.base << 16;
- }
+ READ_BCR(ARC_REG_ISA_CFG_BCR, isa);
- READ_BCR(ARC_REG_DCCM_BUILD, dccm);
- if (dccm.ver) {
- unsigned long base;
- cpu->dccm.sz = 2048 << dccm.sz; /* 2K to 256K */
-
- base = read_aux_reg(ARC_REG_DCCM_BASE_BUILD);
- cpu->dccm.base_addr = base & ~0xF;
- }
- } else {
- struct bcr_iccm_arcv2 iccm;
- struct bcr_dccm_arcv2 dccm;
- unsigned long region;
-
- READ_BCR(ARC_REG_ICCM_BUILD, iccm);
- if (iccm.ver) {
- cpu->iccm.sz = 256 << iccm.sz00; /* 512B to 16M */
- if (iccm.sz00 == 0xF && iccm.sz01 > 0)
- cpu->iccm.sz <<= iccm.sz01;
-
- region = read_aux_reg(ARC_REG_AUX_ICCM);
- cpu->iccm.base_addr = region & 0xF0000000;
- }
-
- READ_BCR(ARC_REG_DCCM_BUILD, dccm);
- if (dccm.ver) {
- cpu->dccm.sz = 256 << dccm.sz0;
- if (dccm.sz0 == 0xF && dccm.sz1 > 0)
- cpu->dccm.sz <<= dccm.sz1;
-
- region = read_aux_reg(ARC_REG_AUX_DCCM);
- cpu->dccm.base_addr = region & 0xF0000000;
- }
+ if (!isa.ver) /* ISA BCR absent, use Kconfig info */
+ atomic = IS_ENABLED(CONFIG_ARC_HAS_LLSC);
+ else {
+ /* ARC700_BUILD only has 2 bits of isa info */
+ atomic = isa.info & 1;
}
+
+ be = IS_ENABLED(CONFIG_CPU_BIG_ENDIAN);
+
+ if (info->arcver < 0x34)
+ cpu_nm = "ARC750";
+ else
+ cpu_nm = "ARC770";
+
+ n += scnprintf(buf + n, len - n, "processor [%d]\t: %s (%s ISA) %s%s%s\n",
+ c, cpu_nm, isa_nm,
+ IS_AVAIL2(atomic, "atomic ", CONFIG_ARC_HAS_LLSC),
+ IS_AVAIL1(be, "[Big-Endian]"));
+
+ READ_BCR(ARC_REG_FP_BCR, fpu_sp);
+ READ_BCR(ARC_REG_DPFP_BCR, fpu_dp);
+
+ if (fpu_sp.ver | fpu_dp.ver)
+ n += scnprintf(buf + n, len - n, "FPU\t\t: %s%s\n",
+ IS_AVAIL1(fpu_sp.ver, "SP "),
+ IS_AVAIL1(fpu_dp.ver, "DP "));
+
+ READ_BCR(ARC_REG_BPU_BCR, bpu);
+ bpu_full = bpu.fam ? 1 : 0;
+ bpu_cache = 256 << (bpu.ent - 1);
+ bpu_pred = 256 << (bpu.ent - 1);
+
+ n += scnprintf(buf + n, len - n,
+ "BPU\t\t: %s%s match, cache:%d, Predict Table:%d\n",
+ IS_AVAIL1(bpu_full, "full"),
+ IS_AVAIL1(!bpu_full, "partial"),
+ bpu_cache, bpu_pred);
+
+ READ_BCR(ARC_REG_ICCM_BUILD, iccm);
+ if (iccm.ver) {
+ info->iccm.sz = 4096 << iccm.sz; /* 8K to 512K */
+ info->iccm.base = iccm.base << 16;
+ }
+
+ READ_BCR(ARC_REG_DCCM_BUILD, dccm);
+ if (dccm.ver) {
+ unsigned long base;
+ info->dccm.sz = 2048 << dccm.sz; /* 2K to 256K */
+
+ base = read_aux_reg(ARC_REG_DCCM_BASE_BUILD);
+ info->dccm.base = base & ~0xF;
+ }
+
+ /* ARCompact ISA specific sanity checks */
+ present = fpu_dp.ver; /* SP has no arch visible regs */
+ CHK_OPT_STRICT(CONFIG_ARC_FPU_SAVE_RESTORE, present);
+#endif
+ return n;
+
}
-static void decode_arc_core(struct cpuinfo_arc *cpu)
+static int arcv2_mumbojumbo(int c, struct cpuinfo_arc *info, char *buf, int len)
{
- struct bcr_uarch_build_arcv2 uarch;
- const struct id_to_str *tbl;
-
- if (cpu->core.family < 0x54) { /* includes arc700 */
-
- for (tbl = &arc_legacy_rel[0]; tbl->id != 0; tbl++) {
- if (cpu->core.family == tbl->id) {
- cpu->release = tbl->str;
- break;
- }
- }
-
- if (is_isa_arcompact())
- cpu->name = "ARC700";
- else if (tbl->str)
- cpu->name = "HS38";
- else
- cpu->name = cpu->release = "Unknown";
-
- return;
- }
+ int n = 0;
+#ifdef CONFIG_ISA_ARCV2
+ const char *release, *cpu_nm, *isa_nm = "ARCv2";
+ int dual_issue = 0, dual_enb = 0, mpy_opt, present;
+ int bpu_full, bpu_cache, bpu_pred, bpu_ret_stk;
+ char mpy_nm[16], lpb_nm[32];
+ struct bcr_isa_arcv2 isa;
+ struct bcr_mpy mpy;
+ struct bcr_fp_arcv2 fpu;
+ struct bcr_bpu_arcv2 bpu;
+ struct bcr_lpb lpb;
+ struct bcr_iccm_arcv2 iccm;
+ struct bcr_dccm_arcv2 dccm;
+ struct bcr_erp erp;
/*
* Initial HS cores bumped AUX IDENTITY.ARCVER for each release until
* ARCVER 0x54 which introduced AUX MICRO_ARCH_BUILD and subsequent
* releases only update it.
*/
- READ_BCR(ARC_REG_MICRO_ARCH_BCR, uarch);
- if (uarch.prod == 4) {
- cpu->name = "HS48";
- cpu->extn.dual = 1;
+ cpu_nm = "HS38";
+ if (info->arcver > 0x50 && info->arcver <= 0x53) {
+ release = arc_hs_rel[info->arcver - 0x51].str;
} else {
- cpu->name = "HS38";
- }
+ const struct id_to_str *tbl;
+ struct bcr_uarch_build uarch;
- for (tbl = &arc_hs_ver54_rel[0]; tbl->id != 0xFF; tbl++) {
- if (uarch.maj == tbl->id) {
- cpu->release = tbl->str;
- break;
+ READ_BCR(ARC_REG_MICRO_ARCH_BCR, uarch);
+
+ for (tbl = &arc_hs_ver54_rel[0]; tbl->id != 0xFF; tbl++) {
+ if (uarch.maj == tbl->id) {
+ release = tbl->str;
+ break;
+ }
}
- }
-}
-
-static void read_arc_build_cfg_regs(void)
-{
- struct bcr_timer timer;
- struct bcr_generic bcr;
- struct cpuinfo_arc *cpu = &cpuinfo_arc700[smp_processor_id()];
- struct bcr_isa_arcv2 isa;
- struct bcr_actionpoint ap;
-
- FIX_PTR(cpu);
-
- READ_BCR(AUX_IDENTITY, cpu->core);
- decode_arc_core(cpu);
-
- READ_BCR(ARC_REG_TIMERS_BCR, timer);
- cpu->extn.timer0 = timer.t0;
- cpu->extn.timer1 = timer.t1;
- cpu->extn.rtc = timer.rtc;
-
- cpu->vec_base = read_aux_reg(AUX_INTR_VEC_BASE);
-
- READ_BCR(ARC_REG_MUL_BCR, cpu->extn_mpy);
-
- /* Read CCM BCRs for boot reporting even if not enabled in Kconfig */
- read_decode_ccm_bcr(cpu);
-
- read_decode_mmu_bcr();
- read_decode_cache_bcr();
-
- if (is_isa_arcompact()) {
- struct bcr_fp_arcompact sp, dp;
- struct bcr_bpu_arcompact bpu;
-
- READ_BCR(ARC_REG_FP_BCR, sp);
- READ_BCR(ARC_REG_DPFP_BCR, dp);
- cpu->extn.fpu_sp = sp.ver ? 1 : 0;
- cpu->extn.fpu_dp = dp.ver ? 1 : 0;
-
- READ_BCR(ARC_REG_BPU_BCR, bpu);
- cpu->bpu.ver = bpu.ver;
- cpu->bpu.full = bpu.fam ? 1 : 0;
- if (bpu.ent) {
- cpu->bpu.num_cache = 256 << (bpu.ent - 1);
- cpu->bpu.num_pred = 256 << (bpu.ent - 1);
- }
- } else {
- struct bcr_fp_arcv2 spdp;
- struct bcr_bpu_arcv2 bpu;
-
- READ_BCR(ARC_REG_FP_V2_BCR, spdp);
- cpu->extn.fpu_sp = spdp.sp ? 1 : 0;
- cpu->extn.fpu_dp = spdp.dp ? 1 : 0;
-
- READ_BCR(ARC_REG_BPU_BCR, bpu);
- cpu->bpu.ver = bpu.ver;
- cpu->bpu.full = bpu.ft;
- cpu->bpu.num_cache = 256 << bpu.bce;
- cpu->bpu.num_pred = 2048 << bpu.pte;
- cpu->bpu.ret_stk = 4 << bpu.rse;
-
- /* if dual issue hardware, is it enabled ? */
- if (cpu->extn.dual) {
+ if (uarch.prod == 4) {
unsigned int exec_ctrl;
+ cpu_nm = "HS48";
+ dual_issue = 1;
+ /* if dual issue hardware, is it enabled ? */
READ_BCR(AUX_EXEC_CTRL, exec_ctrl);
- cpu->extn.dual_enb = !(exec_ctrl & 1);
+ dual_enb = !(exec_ctrl & 1);
}
}
- READ_BCR(ARC_REG_AP_BCR, ap);
- if (ap.ver) {
- cpu->extn.ap_num = 2 << ap.num;
- cpu->extn.ap_full = !ap.min;
- }
-
- READ_BCR(ARC_REG_SMART_BCR, bcr);
- cpu->extn.smart = bcr.ver ? 1 : 0;
-
- READ_BCR(ARC_REG_RTT_BCR, bcr);
- cpu->extn.rtt = bcr.ver ? 1 : 0;
-
READ_BCR(ARC_REG_ISA_CFG_BCR, isa);
- /* some hacks for lack of feature BCR info in old ARC700 cores */
- if (is_isa_arcompact()) {
- if (!isa.ver) /* ISA BCR absent, use Kconfig info */
- cpu->isa.atomic = IS_ENABLED(CONFIG_ARC_HAS_LLSC);
- else {
- /* ARC700_BUILD only has 2 bits of isa info */
- struct bcr_generic bcr = *(struct bcr_generic *)&isa;
- cpu->isa.atomic = bcr.info & 1;
- }
+ n += scnprintf(buf + n, len - n, "processor [%d]\t: %s %s (%s ISA) %s%s%s\n",
+ c, cpu_nm, release, isa_nm,
+ IS_AVAIL1(isa.be, "[Big-Endian]"),
+ IS_AVAIL3(dual_issue, dual_enb, " Dual-Issue "));
- cpu->isa.be = IS_ENABLED(CONFIG_CPU_BIG_ENDIAN);
+ READ_BCR(ARC_REG_MPY_BCR, mpy);
+ mpy_opt = 2; /* stock MPY/MPYH */
+ if (mpy.dsp) /* OPT 7-9 */
+ mpy_opt = mpy.dsp + 6;
- /* there's no direct way to distinguish 750 vs. 770 */
- if (unlikely(cpu->core.family < 0x34 || cpu->mmu.ver < 3))
- cpu->name = "ARC750";
- } else {
- cpu->isa = isa;
+ scnprintf(mpy_nm, 16, "mpy[opt %d] ", mpy_opt);
+
+ READ_BCR(ARC_REG_FP_V2_BCR, fpu);
+
+ n += scnprintf(buf + n, len - n, "ISA Extn\t: %s%s%s%s%s%s%s%s%s%s%s\n",
+ IS_AVAIL2(isa.atomic, "atomic ", CONFIG_ARC_HAS_LLSC),
+ IS_AVAIL2(isa.ldd, "ll64 ", CONFIG_ARC_HAS_LL64),
+ IS_AVAIL2(isa.unalign, "unalign ", CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS),
+ IS_AVAIL1(mpy.ver, mpy_nm),
+ IS_AVAIL1(isa.div_rem, "div_rem "),
+ IS_AVAIL1((fpu.sp | fpu.dp), " FPU:"),
+ IS_AVAIL1(fpu.sp, " sp"),
+ IS_AVAIL1(fpu.dp, " dp"));
+
+ READ_BCR(ARC_REG_BPU_BCR, bpu);
+ bpu_full = bpu.ft;
+ bpu_cache = 256 << bpu.bce;
+ bpu_pred = 2048 << bpu.pte;
+ bpu_ret_stk = 4 << bpu.rse;
+
+ READ_BCR(ARC_REG_LPB_BUILD, lpb);
+ if (lpb.ver) {
+ unsigned int ctl;
+ ctl = read_aux_reg(ARC_REG_LPB_CTRL);
+
+ scnprintf(lpb_nm, sizeof(lpb_nm), " Loop Buffer:%d %s",
+ lpb.entries, IS_DISABLED_RUN(!ctl));
}
-}
-
-static char *arc_cpu_mumbojumbo(int cpu_id, char *buf, int len)
-{
- struct cpuinfo_arc *cpu = &cpuinfo_arc700[cpu_id];
- struct bcr_identity *core = &cpu->core;
- char mpy_opt[16];
- int n = 0;
-
- FIX_PTR(cpu);
n += scnprintf(buf + n, len - n,
- "\nIDENTITY\t: ARCVER [%#02x] ARCNUM [%#02x] CHIPID [%#4x]\n",
- core->family, core->cpu_id, core->chip_id);
+ "BPU\t\t: %s%s match, cache:%d, Predict Table:%d Return stk: %d%s\n",
+ IS_AVAIL1(bpu_full, "full"),
+ IS_AVAIL1(!bpu_full, "partial"),
+ bpu_cache, bpu_pred, bpu_ret_stk,
+ lpb_nm);
- n += scnprintf(buf + n, len - n, "processor [%d]\t: %s %s (%s ISA) %s%s%s\n",
- cpu_id, cpu->name, cpu->release,
- is_isa_arcompact() ? "ARCompact" : "ARCv2",
- IS_AVAIL1(cpu->isa.be, "[Big-Endian]"),
- IS_AVAIL3(cpu->extn.dual, cpu->extn.dual_enb, " Dual-Issue "));
-
- n += scnprintf(buf + n, len - n, "Timers\t\t: %s%s%s%s%s%s\nISA Extn\t: ",
- IS_AVAIL1(cpu->extn.timer0, "Timer0 "),
- IS_AVAIL1(cpu->extn.timer1, "Timer1 "),
- IS_AVAIL2(cpu->extn.rtc, "RTC [UP 64-bit] ", CONFIG_ARC_TIMERS_64BIT),
- IS_AVAIL2(cpu->extn.gfrc, "GFRC [SMP 64-bit] ", CONFIG_ARC_TIMERS_64BIT));
-
- if (cpu->extn_mpy.ver) {
- if (is_isa_arcompact()) {
- scnprintf(mpy_opt, 16, "mpy");
- } else {
-
- int opt = 2; /* stock MPY/MPYH */
-
- if (cpu->extn_mpy.dsp) /* OPT 7-9 */
- opt = cpu->extn_mpy.dsp + 6;
-
- scnprintf(mpy_opt, 16, "mpy[opt %d] ", opt);
- }
+ READ_BCR(ARC_REG_ICCM_BUILD, iccm);
+ if (iccm.ver) {
+ unsigned long base;
+ info->iccm.sz = 256 << iccm.sz00; /* 512B to 16M */
+ if (iccm.sz00 == 0xF && iccm.sz01 > 0)
+ info->iccm.sz <<= iccm.sz01;
+ base = read_aux_reg(ARC_REG_AUX_ICCM);
+ info->iccm.base = base & 0xF0000000;
}
- n += scnprintf(buf + n, len - n, "%s%s%s%s%s%s%s%s\n",
- IS_AVAIL2(cpu->isa.atomic, "atomic ", CONFIG_ARC_HAS_LLSC),
- IS_AVAIL2(cpu->isa.ldd, "ll64 ", CONFIG_ARC_HAS_LL64),
- IS_AVAIL2(cpu->isa.unalign, "unalign ", CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS),
- IS_AVAIL1(cpu->extn_mpy.ver, mpy_opt),
- IS_AVAIL1(cpu->isa.div_rem, "div_rem "));
-
- if (cpu->bpu.ver) {
- n += scnprintf(buf + n, len - n,
- "BPU\t\t: %s%s match, cache:%d, Predict Table:%d Return stk: %d",
- IS_AVAIL1(cpu->bpu.full, "full"),
- IS_AVAIL1(!cpu->bpu.full, "partial"),
- cpu->bpu.num_cache, cpu->bpu.num_pred, cpu->bpu.ret_stk);
-
- if (is_isa_arcv2()) {
- struct bcr_lpb lpb;
-
- READ_BCR(ARC_REG_LPB_BUILD, lpb);
- if (lpb.ver) {
- unsigned int ctl;
- ctl = read_aux_reg(ARC_REG_LPB_CTRL);
-
- n += scnprintf(buf + n, len - n, " Loop Buffer:%d %s",
- lpb.entries,
- IS_DISABLED_RUN(!ctl));
- }
- }
- n += scnprintf(buf + n, len - n, "\n");
+ READ_BCR(ARC_REG_DCCM_BUILD, dccm);
+ if (dccm.ver) {
+ unsigned long base;
+ info->dccm.sz = 256 << dccm.sz0;
+ if (dccm.sz0 == 0xF && dccm.sz1 > 0)
+ info->dccm.sz <<= dccm.sz1;
+ base = read_aux_reg(ARC_REG_AUX_DCCM);
+ info->dccm.base = base & 0xF0000000;
}
- return buf;
-}
-
-static char *arc_extn_mumbojumbo(int cpu_id, char *buf, int len)
-{
- int n = 0;
- struct cpuinfo_arc *cpu = &cpuinfo_arc700[cpu_id];
-
- FIX_PTR(cpu);
-
- n += scnprintf(buf + n, len - n, "Vector Table\t: %#x\n", cpu->vec_base);
-
- if (cpu->extn.fpu_sp || cpu->extn.fpu_dp)
- n += scnprintf(buf + n, len - n, "FPU\t\t: %s%s\n",
- IS_AVAIL1(cpu->extn.fpu_sp, "SP "),
- IS_AVAIL1(cpu->extn.fpu_dp, "DP "));
-
- if (cpu->extn.ap_num | cpu->extn.smart | cpu->extn.rtt) {
- n += scnprintf(buf + n, len - n, "DEBUG\t\t: %s%s",
- IS_AVAIL1(cpu->extn.smart, "smaRT "),
- IS_AVAIL1(cpu->extn.rtt, "RTT "));
- if (cpu->extn.ap_num) {
- n += scnprintf(buf + n, len - n, "ActionPoint %d/%s",
- cpu->extn.ap_num,
- cpu->extn.ap_full ? "full":"min");
- }
- n += scnprintf(buf + n, len - n, "\n");
- }
-
- if (cpu->dccm.sz || cpu->iccm.sz)
- n += scnprintf(buf + n, len - n, "Extn [CCM]\t: DCCM @ %x, %d KB / ICCM: @ %x, %d KB\n",
- cpu->dccm.base_addr, TO_KB(cpu->dccm.sz),
- cpu->iccm.base_addr, TO_KB(cpu->iccm.sz));
-
- if (is_isa_arcv2()) {
-
- /* Error Protection: ECC/Parity */
- struct bcr_erp erp;
- READ_BCR(ARC_REG_ERP_BUILD, erp);
-
- if (erp.ver) {
- struct ctl_erp ctl;
- READ_BCR(ARC_REG_ERP_CTRL, ctl);
-
- /* inverted bits: 0 means enabled */
- n += scnprintf(buf + n, len - n, "Extn [ECC]\t: %s%s%s%s%s%s\n",
+ /* Error Protection: ECC/Parity */
+ READ_BCR(ARC_REG_ERP_BUILD, erp);
+ if (erp.ver) {
+ struct ctl_erp ctl;
+ READ_BCR(ARC_REG_ERP_CTRL, ctl);
+ /* inverted bits: 0 means enabled */
+ n += scnprintf(buf + n, len - n, "Extn [ECC]\t: %s%s%s%s%s%s\n",
IS_AVAIL3(erp.ic, !ctl.dpi, "IC "),
IS_AVAIL3(erp.dc, !ctl.dpd, "DC "),
IS_AVAIL3(erp.mmu, !ctl.mpd, "MMU "));
- }
}
+ /* ARCv2 ISA specific sanity checks */
+ present = fpu.sp | fpu.dp | mpy.dsp; /* DSP and/or FPU */
+ CHK_OPT_STRICT(CONFIG_ARC_HAS_ACCL_REGS, present);
+
+ dsp_config_check();
+#endif
+ return n;
+}
+
+static char *arc_cpu_mumbojumbo(int c, struct cpuinfo_arc *info, char *buf, int len)
+{
+ struct bcr_identity ident;
+ struct bcr_timer timer;
+ struct bcr_generic bcr;
+ struct mcip_bcr mp;
+ struct bcr_actionpoint ap;
+ unsigned long vec_base;
+ int ap_num, ap_full, smart, rtt, n;
+
+ memset(info, 0, sizeof(struct cpuinfo_arc));
+
+ READ_BCR(AUX_IDENTITY, ident);
+ info->arcver = ident.family;
+
+ n = scnprintf(buf, len,
+ "\nIDENTITY\t: ARCVER [%#02x] ARCNUM [%#02x] CHIPID [%#4x]\n",
+ ident.family, ident.cpu_id, ident.chip_id);
+
+ if (is_isa_arcompact()) {
+ n += arcompact_mumbojumbo(c, info, buf + n, len - n);
+ } else if (is_isa_arcv2()){
+ n += arcv2_mumbojumbo(c, info, buf + n, len - n);
+ }
+
+ n += arc_mmu_mumbojumbo(c, buf + n, len - n);
+ n += arc_cache_mumbojumbo(c, buf + n, len - n);
+
+ READ_BCR(ARC_REG_TIMERS_BCR, timer);
+ info->t0 = timer.t0;
+ info->t1 = timer.t1;
+
+ READ_BCR(ARC_REG_MCIP_BCR, mp);
+ vec_base = read_aux_reg(AUX_INTR_VEC_BASE);
+
+ n += scnprintf(buf + n, len - n,
+ "Timers\t\t: %s%s%s%s%s%s\nVector Table\t: %#lx\n",
+ IS_AVAIL1(timer.t0, "Timer0 "),
+ IS_AVAIL1(timer.t1, "Timer1 "),
+ IS_AVAIL2(timer.rtc, "RTC [UP 64-bit] ", CONFIG_ARC_TIMERS_64BIT),
+ IS_AVAIL2(mp.gfrc, "GFRC [SMP 64-bit] ", CONFIG_ARC_TIMERS_64BIT),
+ vec_base);
+
+ READ_BCR(ARC_REG_AP_BCR, ap);
+ if (ap.ver) {
+ ap_num = 2 << ap.num;
+ ap_full = !ap.min;
+ }
+
+ READ_BCR(ARC_REG_SMART_BCR, bcr);
+ smart = bcr.ver ? 1 : 0;
+
+ READ_BCR(ARC_REG_RTT_BCR, bcr);
+ rtt = bcr.ver ? 1 : 0;
+
+ if (ap.ver | smart | rtt) {
+ n += scnprintf(buf + n, len - n, "DEBUG\t\t: %s%s",
+ IS_AVAIL1(smart, "smaRT "),
+ IS_AVAIL1(rtt, "RTT "));
+ if (ap.ver) {
+ n += scnprintf(buf + n, len - n, "ActionPoint %d/%s",
+ ap_num,
+ ap_full ? "full":"min");
+ }
+ n += scnprintf(buf + n, len - n, "\n");
+ }
+
+ if (info->dccm.sz || info->iccm.sz)
+ n += scnprintf(buf + n, len - n,
+ "Extn [CCM]\t: DCCM @ %lx, %d KB / ICCM: @ %lx, %d KB\n",
+ info->dccm.base, TO_KB(info->dccm.sz),
+ info->iccm.base, TO_KB(info->iccm.sz));
+
return buf;
}
@@ -401,15 +378,15 @@ void chk_opt_weak(char *opt_name, bool hw_exists, bool opt_ena)
panic("Disable %s, hardware NOT present\n", opt_name);
}
-static void arc_chk_core_config(void)
+/*
+ * ISA agnostic sanity checks
+ */
+static void arc_chk_core_config(struct cpuinfo_arc *info)
{
- struct cpuinfo_arc *cpu = &cpuinfo_arc700[smp_processor_id()];
- int present = 0;
-
- if (!cpu->extn.timer0)
+ if (!info->t0)
panic("Timer0 is not present!\n");
- if (!cpu->extn.timer1)
+ if (!info->t1)
panic("Timer1 is not present!\n");
#ifdef CONFIG_ARC_HAS_DCCM
@@ -417,35 +394,17 @@ static void arc_chk_core_config(void)
* DCCM can be arbit placed in hardware.
* Make sure it's placement/sz matches what Linux is built with
*/
- if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr)
+ if ((unsigned int)__arc_dccm_base != info->dccm.base)
panic("Linux built with incorrect DCCM Base address\n");
- if (CONFIG_ARC_DCCM_SZ * SZ_1K != cpu->dccm.sz)
+ if (CONFIG_ARC_DCCM_SZ * SZ_1K != info->dccm.sz)
panic("Linux built with incorrect DCCM Size\n");
#endif
#ifdef CONFIG_ARC_HAS_ICCM
- if (CONFIG_ARC_ICCM_SZ * SZ_1K != cpu->iccm.sz)
+ if (CONFIG_ARC_ICCM_SZ * SZ_1K != info->iccm.sz)
panic("Linux built with incorrect ICCM Size\n");
#endif
-
- /*
- * FP hardware/software config sanity
- * -If hardware present, kernel needs to save/restore FPU state
- * -If not, it will crash trying to save/restore the non-existant regs
- */
-
- if (is_isa_arcompact()) {
- /* only DPDP checked since SP has no arch visible regs */
- present = cpu->extn.fpu_dp;
- CHK_OPT_STRICT(CONFIG_ARC_FPU_SAVE_RESTORE, present);
- } else {
- /* Accumulator Low:High pair (r58:59) present if DSP MPY or FPU */
- present = cpu->extn_mpy.dsp | cpu->extn.fpu_sp | cpu->extn.fpu_dp;
- CHK_OPT_STRICT(CONFIG_ARC_HAS_ACCL_REGS, present);
-
- dsp_config_check();
- }
}
/*
@@ -456,21 +415,19 @@ static void arc_chk_core_config(void)
void setup_processor(void)
{
+ struct cpuinfo_arc info;
+ int c = smp_processor_id();
char str[512];
- int cpu_id = smp_processor_id();
- read_arc_build_cfg_regs();
+ pr_info("%s", arc_cpu_mumbojumbo(c, &info, str, sizeof(str)));
+ pr_info("%s", arc_platform_smp_cpuinfo());
+
+ arc_chk_core_config(&info);
+
arc_init_IRQ();
-
- pr_info("%s", arc_cpu_mumbojumbo(cpu_id, str, sizeof(str)));
-
arc_mmu_init();
arc_cache_init();
- pr_info("%s", arc_extn_mumbojumbo(cpu_id, str, sizeof(str)));
- pr_info("%s", arc_platform_smp_cpuinfo());
-
- arc_chk_core_config();
}
static inline bool uboot_arg_invalid(unsigned long addr)
@@ -617,6 +574,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
char *str;
int cpu_id = ptr_to_cpu(v);
struct device *cpu_dev = get_cpu_device(cpu_id);
+ struct cpuinfo_arc info;
struct clk *cpu_clk;
unsigned long freq = 0;
@@ -629,7 +587,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (!str)
goto done;
- seq_printf(m, arc_cpu_mumbojumbo(cpu_id, str, PAGE_SIZE));
+ seq_printf(m, arc_cpu_mumbojumbo(cpu_id, &info, str, PAGE_SIZE));
cpu_clk = clk_get(cpu_dev, NULL);
if (IS_ERR(cpu_clk)) {
@@ -646,9 +604,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
loops_per_jiffy / (500000 / HZ),
(loops_per_jiffy / (5000 / HZ)) % 100);
- seq_printf(m, arc_mmu_mumbojumbo(cpu_id, str, PAGE_SIZE));
- seq_printf(m, arc_cache_mumbojumbo(cpu_id, str, PAGE_SIZE));
- seq_printf(m, arc_extn_mumbojumbo(cpu_id, str, PAGE_SIZE));
seq_printf(m, arc_platform_smp_cpuinfo());
free_page((unsigned long)str);
diff --git a/arch/arc/kernel/signal.c b/arch/arc/kernel/signal.c
index 3c1590c..0b3bb52 100644
--- a/arch/arc/kernel/signal.c
+++ b/arch/arc/kernel/signal.c
@@ -53,6 +53,7 @@
#include <linux/sched/task_stack.h>
#include <asm/ucontext.h>
+#include <asm/entry.h>
struct rt_sigframe {
struct siginfo info;
diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
index 409cfa4..8d9b188 100644
--- a/arch/arc/kernel/smp.c
+++ b/arch/arc/kernel/smp.c
@@ -23,9 +23,10 @@
#include <linux/export.h>
#include <linux/of_fdt.h>
-#include <asm/processor.h>
-#include <asm/setup.h>
#include <asm/mach_desc.h>
+#include <asm/setup.h>
+#include <asm/smp.h>
+#include <asm/processor.h>
#ifndef CONFIG_ARC_HAS_LLSC
arch_spinlock_t smp_atomic_ops_lock = __ARCH_SPIN_LOCK_UNLOCKED;
@@ -351,7 +352,7 @@ static inline int __do_IPI(unsigned long msg)
* arch-common ISR to handle for inter-processor interrupts
* Has hooks for platform specific IPI
*/
-irqreturn_t do_IPI(int irq, void *dev_id)
+static irqreturn_t do_IPI(int irq, void *dev_id)
{
unsigned long pending;
unsigned long __maybe_unused copy;
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index 5372dc0..ea99c06 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -29,6 +29,7 @@
#include <asm/arcregs.h>
#include <asm/unwind.h>
+#include <asm/stacktrace.h>
#include <asm/switch_to.h>
/*-------------------------------------------------------------------------
diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 6b83e3f..9b9570b 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -16,6 +16,7 @@
#include <linux/ptrace.h>
#include <linux/kprobes.h>
#include <linux/kgdb.h>
+#include <asm/entry.h>
#include <asm/setup.h>
#include <asm/unaligned.h>
#include <asm/kprobes.h>
@@ -109,9 +110,7 @@ void do_machine_check_fault(unsigned long address, struct pt_regs *regs)
*/
void do_non_swi_trap(unsigned long address, struct pt_regs *regs)
{
- unsigned int param = regs->ecr_param;
-
- switch (param) {
+ switch (regs->ecr.param) {
case 1:
trap_is_brkpt(address, regs);
break;
diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index 7654c2e..d5b3ed2 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -115,8 +115,8 @@ static void show_ecr_verbose(struct pt_regs *regs)
/* For Data fault, this is data address not instruction addr */
address = current->thread.fault_address;
- vec = regs->ecr_vec;
- cause_code = regs->ecr_cause;
+ vec = regs->ecr.vec;
+ cause_code = regs->ecr.cause;
/* For DTLB Miss or ProtV, display the memory involved too */
if (vec == ECR_V_DTLB_MISS) {
@@ -154,7 +154,7 @@ static void show_ecr_verbose(struct pt_regs *regs)
pr_cont("Misaligned r/w from 0x%08lx\n", address);
#endif
} else if (vec == ECR_V_TRAP) {
- if (regs->ecr_param == 5)
+ if (regs->ecr.param == 5)
pr_cont("gcc generated __builtin_trap\n");
} else {
pr_cont("Check Programmer's Manual\n");
@@ -184,9 +184,10 @@ void show_regs(struct pt_regs *regs)
if (user_mode(regs))
show_faulting_vma(regs->ret); /* faulting code, not data */
- pr_info("ECR: 0x%08lx EFA: 0x%08lx ERET: 0x%08lx\nSTAT: 0x%08lx",
- regs->event, current->thread.fault_address, regs->ret,
- regs->status32);
+ pr_info("ECR: 0x%08lx EFA: 0x%08lx ERET: 0x%08lx\n",
+ regs->ecr.full, current->thread.fault_address, regs->ret);
+
+ pr_info("STAT32: 0x%08lx", regs->status32);
#define STS_BIT(r, bit) r->status32 & STATUS_##bit##_MASK ? #bit" " : ""
diff --git a/arch/arc/lib/memset-archs.S b/arch/arc/lib/memset-archs.S
index d2e09fe..d0a5cec 100644
--- a/arch/arc/lib/memset-archs.S
+++ b/arch/arc/lib/memset-archs.S
@@ -36,12 +36,13 @@
#endif
ENTRY_CFI(memset)
- PREFETCHW_INSTR r0, 0 ; Prefetch the first write location
mov.f 0, r2
;;; if size is zero
jz.d [blink]
mov r3, r0 ; don't clobber ret val
+ PREFETCHW_INSTR r0, 0 ; Prefetch the first write location
+
;;; if length < 8
brls.d.nt r2, 8, .Lsmallchunk
mov.f lp_count,r2
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 55c6de13..f7e05c1 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -28,6 +28,10 @@ int slc_enable = 1, ioc_enable = 1;
unsigned long perip_base = ARC_UNCACHED_ADDR_SPACE; /* legacy value for boot */
unsigned long perip_end = 0xFFFFFFFF; /* legacy value */
+static struct cpuinfo_arc_cache {
+ unsigned int sz_k, line_len, colors;
+} ic_info, dc_info, slc_info;
+
void (*_cache_line_loop_ic_fn)(phys_addr_t paddr, unsigned long vaddr,
unsigned long sz, const int op, const int full_page);
@@ -35,78 +39,24 @@ void (*__dma_cache_wback_inv)(phys_addr_t start, unsigned long sz);
void (*__dma_cache_inv)(phys_addr_t start, unsigned long sz);
void (*__dma_cache_wback)(phys_addr_t start, unsigned long sz);
-char *arc_cache_mumbojumbo(int c, char *buf, int len)
+static int read_decode_cache_bcr_arcv2(int c, char *buf, int len)
{
- int n = 0;
- struct cpuinfo_arc_cache *p;
-
-#define PR_CACHE(p, cfg, str) \
- if (!(p)->line_len) \
- n += scnprintf(buf + n, len - n, str"\t\t: N/A\n"); \
- else \
- n += scnprintf(buf + n, len - n, \
- str"\t\t: %uK, %dway/set, %uB Line, %s%s%s\n", \
- (p)->sz_k, (p)->assoc, (p)->line_len, \
- (p)->vipt ? "VIPT" : "PIPT", \
- (p)->alias ? " aliasing" : "", \
- IS_USED_CFG(cfg));
-
- PR_CACHE(&cpuinfo_arc700[c].icache, CONFIG_ARC_HAS_ICACHE, "I-Cache");
- PR_CACHE(&cpuinfo_arc700[c].dcache, CONFIG_ARC_HAS_DCACHE, "D-Cache");
-
- p = &cpuinfo_arc700[c].slc;
- if (p->line_len)
- n += scnprintf(buf + n, len - n,
- "SLC\t\t: %uK, %uB Line%s\n",
- p->sz_k, p->line_len, IS_USED_RUN(slc_enable));
-
- n += scnprintf(buf + n, len - n, "Peripherals\t: %#lx%s%s\n",
- perip_base,
- IS_AVAIL3(ioc_exists, ioc_enable, ", IO-Coherency (per-device) "));
-
- return buf;
-}
-
-/*
- * Read the Cache Build Confuration Registers, Decode them and save into
- * the cpuinfo structure for later use.
- * No Validation done here, simply read/convert the BCRs
- */
-static void read_decode_cache_bcr_arcv2(int cpu)
-{
- struct cpuinfo_arc_cache *p_slc = &cpuinfo_arc700[cpu].slc;
+ struct cpuinfo_arc_cache *p_slc = &slc_info;
+ struct bcr_identity ident;
struct bcr_generic sbcr;
-
- struct bcr_slc_cfg {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned int pad:24, way:2, lsz:2, sz:4;
-#else
- unsigned int sz:4, lsz:2, way:2, pad:24;
-#endif
- } slc_cfg;
-
- struct bcr_clust_cfg {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned int pad:7, c:1, num_entries:8, num_cores:8, ver:8;
-#else
- unsigned int ver:8, num_cores:8, num_entries:8, c:1, pad:7;
-#endif
- } cbcr;
-
- struct bcr_volatile {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned int start:4, limit:4, pad:22, order:1, disable:1;
-#else
- unsigned int disable:1, order:1, pad:22, limit:4, start:4;
-#endif
- } vol;
-
+ struct bcr_clust_cfg cbcr;
+ struct bcr_volatile vol;
+ int n = 0;
READ_BCR(ARC_REG_SLC_BCR, sbcr);
if (sbcr.ver) {
+ struct bcr_slc_cfg slc_cfg;
READ_BCR(ARC_REG_SLC_CFG, slc_cfg);
p_slc->sz_k = 128 << slc_cfg.sz;
l2_line_sz = p_slc->line_len = (slc_cfg.lsz == 0) ? 128 : 64;
+ n += scnprintf(buf + n, len - n,
+ "SLC\t\t: %uK, %uB Line%s\n",
+ p_slc->sz_k, p_slc->line_len, IS_USED_RUN(slc_enable));
}
READ_BCR(ARC_REG_CLUSTER_BCR, cbcr);
@@ -129,70 +79,83 @@ static void read_decode_cache_bcr_arcv2(int cpu)
ioc_enable = 0;
}
+ READ_BCR(AUX_IDENTITY, ident);
+
/* HS 2.0 didn't have AUX_VOL */
- if (cpuinfo_arc700[cpu].core.family > 0x51) {
+ if (ident.family > 0x51) {
READ_BCR(AUX_VOL, vol);
perip_base = vol.start << 28;
/* HS 3.0 has limit and strict-ordering fields */
- if (cpuinfo_arc700[cpu].core.family > 0x52)
+ if (ident.family > 0x52)
perip_end = (vol.limit << 28) - 1;
}
+
+ n += scnprintf(buf + n, len - n, "Peripherals\t: %#lx%s%s\n",
+ perip_base,
+ IS_AVAIL3(ioc_exists, ioc_enable, ", IO-Coherency (per-device) "));
+
+ return n;
}
-void read_decode_cache_bcr(void)
+int arc_cache_mumbojumbo(int c, char *buf, int len)
{
- struct cpuinfo_arc_cache *p_ic, *p_dc;
- unsigned int cpu = smp_processor_id();
- struct bcr_cache {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned int pad:12, line_len:4, sz:4, config:4, ver:8;
-#else
- unsigned int ver:8, config:4, sz:4, line_len:4, pad:12;
-#endif
- } ibcr, dbcr;
+ struct cpuinfo_arc_cache *p_ic = &ic_info, *p_dc = &dc_info;
+ struct bcr_cache ibcr, dbcr;
+ int vipt, assoc;
+ int n = 0;
- p_ic = &cpuinfo_arc700[cpu].icache;
READ_BCR(ARC_REG_IC_BCR, ibcr);
-
if (!ibcr.ver)
goto dc_chk;
- if (ibcr.ver <= 3) {
+ if (is_isa_arcompact() && (ibcr.ver <= 3)) {
BUG_ON(ibcr.config != 3);
- p_ic->assoc = 2; /* Fixed to 2w set assoc */
- } else if (ibcr.ver >= 4) {
- p_ic->assoc = 1 << ibcr.config; /* 1,2,4,8 */
+ assoc = 2; /* Fixed to 2w set assoc */
+ } else if (is_isa_arcv2() && (ibcr.ver >= 4)) {
+ assoc = 1 << ibcr.config; /* 1,2,4,8 */
}
p_ic->line_len = 8 << ibcr.line_len;
p_ic->sz_k = 1 << (ibcr.sz - 1);
- p_ic->vipt = 1;
- p_ic->alias = p_ic->sz_k/p_ic->assoc/TO_KB(PAGE_SIZE) > 1;
+ p_ic->colors = p_ic->sz_k/assoc/TO_KB(PAGE_SIZE);
+
+ n += scnprintf(buf + n, len - n,
+ "I-Cache\t\t: %uK, %dway/set, %uB Line, VIPT%s%s\n",
+ p_ic->sz_k, assoc, p_ic->line_len,
+ p_ic->colors > 1 ? " aliasing" : "",
+ IS_USED_CFG(CONFIG_ARC_HAS_ICACHE));
dc_chk:
- p_dc = &cpuinfo_arc700[cpu].dcache;
READ_BCR(ARC_REG_DC_BCR, dbcr);
-
if (!dbcr.ver)
goto slc_chk;
- if (dbcr.ver <= 3) {
+ if (is_isa_arcompact() && (dbcr.ver <= 3)) {
BUG_ON(dbcr.config != 2);
- p_dc->assoc = 4; /* Fixed to 4w set assoc */
- p_dc->vipt = 1;
- p_dc->alias = p_dc->sz_k/p_dc->assoc/TO_KB(PAGE_SIZE) > 1;
- } else if (dbcr.ver >= 4) {
- p_dc->assoc = 1 << dbcr.config; /* 1,2,4,8 */
- p_dc->vipt = 0;
- p_dc->alias = 0; /* PIPT so can't VIPT alias */
+ vipt = 1;
+ assoc = 4; /* Fixed to 4w set assoc */
+ p_dc->colors = p_dc->sz_k/assoc/TO_KB(PAGE_SIZE);
+ } else if (is_isa_arcv2() && (dbcr.ver >= 4)) {
+ vipt = 0;
+ assoc = 1 << dbcr.config; /* 1,2,4,8 */
+ p_dc->colors = 1; /* PIPT so can't VIPT alias */
}
p_dc->line_len = 16 << dbcr.line_len;
p_dc->sz_k = 1 << (dbcr.sz - 1);
+ n += scnprintf(buf + n, len - n,
+ "D-Cache\t\t: %uK, %dway/set, %uB Line, %s%s%s\n",
+ p_dc->sz_k, assoc, p_dc->line_len,
+ vipt ? "VIPT" : "PIPT",
+ p_dc->colors > 1 ? " aliasing" : "",
+ IS_USED_CFG(CONFIG_ARC_HAS_DCACHE));
+
slc_chk:
if (is_isa_arcv2())
- read_decode_cache_bcr_arcv2(cpu);
+ n += read_decode_cache_bcr_arcv2(c, buf + n, len - n);
+
+ return n;
}
/*
@@ -581,7 +544,7 @@ static void __ic_line_inv_vaddr(phys_addr_t paddr, unsigned long vaddr,
#endif /* CONFIG_ARC_HAS_ICACHE */
-noinline void slc_op_rgn(phys_addr_t paddr, unsigned long sz, const int op)
+static noinline void slc_op_rgn(phys_addr_t paddr, unsigned long sz, const int op)
{
#ifdef CONFIG_ISA_ARCV2
/*
@@ -644,7 +607,7 @@ noinline void slc_op_rgn(phys_addr_t paddr, unsigned long sz, const int op)
#endif
}
-noinline void slc_op_line(phys_addr_t paddr, unsigned long sz, const int op)
+static __maybe_unused noinline void slc_op_line(phys_addr_t paddr, unsigned long sz, const int op)
{
#ifdef CONFIG_ISA_ARCV2
/*
@@ -752,17 +715,17 @@ static inline void arc_slc_enable(void)
* There's a corollary case, where kernel READs from a userspace mapped page.
* If the U-mapping is not congruent to K-mapping, former needs flushing.
*/
-void flush_dcache_page(struct page *page)
+void flush_dcache_folio(struct folio *folio)
{
struct address_space *mapping;
if (!cache_is_vipt_aliasing()) {
- clear_bit(PG_dc_clean, &page->flags);
+ clear_bit(PG_dc_clean, &folio->flags);
return;
}
/* don't handle anon pages here */
- mapping = page_mapping_file(page);
+ mapping = folio_flush_mapping(folio);
if (!mapping)
return;
@@ -771,17 +734,27 @@ void flush_dcache_page(struct page *page)
* Make a note that K-mapping is dirty
*/
if (!mapping_mapped(mapping)) {
- clear_bit(PG_dc_clean, &page->flags);
- } else if (page_mapcount(page)) {
-
+ clear_bit(PG_dc_clean, &folio->flags);
+ } else if (folio_mapped(folio)) {
/* kernel reading from page with U-mapping */
- phys_addr_t paddr = (unsigned long)page_address(page);
- unsigned long vaddr = page->index << PAGE_SHIFT;
+ phys_addr_t paddr = (unsigned long)folio_address(folio);
+ unsigned long vaddr = folio_pos(folio);
+ /*
+ * vaddr is not actually the virtual address, but is
+ * congruent to every user mapping.
+ */
if (addr_not_cache_congruent(paddr, vaddr))
- __flush_dcache_page(paddr, vaddr);
+ __flush_dcache_pages(paddr, vaddr,
+ folio_nr_pages(folio));
}
}
+EXPORT_SYMBOL(flush_dcache_folio);
+
+void flush_dcache_page(struct page *page)
+{
+ return flush_dcache_folio(page_folio(page));
+}
EXPORT_SYMBOL(flush_dcache_page);
/*
@@ -921,18 +894,18 @@ void __sync_icache_dcache(phys_addr_t paddr, unsigned long vaddr, int len)
}
/* wrapper to compile time eliminate alignment checks in flush loop */
-void __inv_icache_page(phys_addr_t paddr, unsigned long vaddr)
+void __inv_icache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr)
{
- __ic_line_inv_vaddr(paddr, vaddr, PAGE_SIZE);
+ __ic_line_inv_vaddr(paddr, vaddr, nr * PAGE_SIZE);
}
/*
* wrapper to clearout kernel or userspace mappings of a page
* For kernel mappings @vaddr == @paddr
*/
-void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr)
+void __flush_dcache_pages(phys_addr_t paddr, unsigned long vaddr, unsigned nr)
{
- __dc_line_op(paddr, vaddr & PAGE_MASK, PAGE_SIZE, OP_FLUSH_N_INV);
+ __dc_line_op(paddr, vaddr & PAGE_MASK, nr * PAGE_SIZE, OP_FLUSH_N_INV);
}
noinline void flush_cache_all(void)
@@ -962,10 +935,10 @@ void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
u_vaddr &= PAGE_MASK;
- __flush_dcache_page(paddr, u_vaddr);
+ __flush_dcache_pages(paddr, u_vaddr, 1);
if (vma->vm_flags & VM_EXEC)
- __inv_icache_page(paddr, u_vaddr);
+ __inv_icache_pages(paddr, u_vaddr, 1);
}
void flush_cache_range(struct vm_area_struct *vma, unsigned long start,
@@ -978,9 +951,9 @@ void flush_anon_page(struct vm_area_struct *vma, struct page *page,
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
- __flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
- __flush_dcache_page((phys_addr_t)page_address(page),
- (phys_addr_t)page_address(page));
+ __flush_dcache_pages((phys_addr_t)page_address(page), u_vaddr, 1);
+ __flush_dcache_pages((phys_addr_t)page_address(page),
+ (phys_addr_t)page_address(page), 1);
}
@@ -989,6 +962,8 @@ void flush_anon_page(struct vm_area_struct *vma, struct page *page,
void copy_user_highpage(struct page *to, struct page *from,
unsigned long u_vaddr, struct vm_area_struct *vma)
{
+ struct folio *src = page_folio(from);
+ struct folio *dst = page_folio(to);
void *kfrom = kmap_atomic(from);
void *kto = kmap_atomic(to);
int clean_src_k_mappings = 0;
@@ -1005,7 +980,7 @@ void copy_user_highpage(struct page *to, struct page *from,
* addr_not_cache_congruent() is 0
*/
if (page_mapcount(from) && addr_not_cache_congruent(kfrom, u_vaddr)) {
- __flush_dcache_page((unsigned long)kfrom, u_vaddr);
+ __flush_dcache_pages((unsigned long)kfrom, u_vaddr, 1);
clean_src_k_mappings = 1;
}
@@ -1019,17 +994,17 @@ void copy_user_highpage(struct page *to, struct page *from,
* non copied user pages (e.g. read faults which wire in pagecache page
* directly).
*/
- clear_bit(PG_dc_clean, &to->flags);
+ clear_bit(PG_dc_clean, &dst->flags);
/*
* if SRC was already usermapped and non-congruent to kernel mapping
* sync the kernel mapping back to physical page
*/
if (clean_src_k_mappings) {
- __flush_dcache_page((unsigned long)kfrom, (unsigned long)kfrom);
- set_bit(PG_dc_clean, &from->flags);
+ __flush_dcache_pages((unsigned long)kfrom,
+ (unsigned long)kfrom, 1);
} else {
- clear_bit(PG_dc_clean, &from->flags);
+ clear_bit(PG_dc_clean, &src->flags);
}
kunmap_atomic(kto);
@@ -1038,8 +1013,9 @@ void copy_user_highpage(struct page *to, struct page *from,
void clear_user_page(void *to, unsigned long u_vaddr, struct page *page)
{
+ struct folio *folio = page_folio(page);
clear_page(to);
- clear_bit(PG_dc_clean, &page->flags);
+ clear_bit(PG_dc_clean, &folio->flags);
}
EXPORT_SYMBOL(clear_user_page);
@@ -1069,7 +1045,7 @@ SYSCALL_DEFINE3(cacheflush, uint32_t, start, uint32_t, sz, uint32_t, flags)
* 3. All Caches need to be disabled when setting up IOC to elide any in-flight
* Coherency transactions
*/
-noinline void __init arc_ioc_setup(void)
+static noinline void __init arc_ioc_setup(void)
{
unsigned int ioc_base, mem_sz;
@@ -1131,12 +1107,10 @@ noinline void __init arc_ioc_setup(void)
* one core suffices for all
* - IOC setup / dma callbacks only need to be done once
*/
-void __init arc_cache_init_master(void)
+static noinline void __init arc_cache_init_master(void)
{
- unsigned int __maybe_unused cpu = smp_processor_id();
-
if (IS_ENABLED(CONFIG_ARC_HAS_ICACHE)) {
- struct cpuinfo_arc_cache *ic = &cpuinfo_arc700[cpu].icache;
+ struct cpuinfo_arc_cache *ic = &ic_info;
if (!ic->line_len)
panic("cache support enabled but non-existent cache\n");
@@ -1149,14 +1123,14 @@ void __init arc_cache_init_master(void)
* In MMU v4 (HS38x) the aliasing icache config uses IVIL/PTAG
* pair to provide vaddr/paddr respectively, just as in MMU v3
*/
- if (is_isa_arcv2() && ic->alias)
+ if (is_isa_arcv2() && ic->colors > 1)
_cache_line_loop_ic_fn = __cache_line_loop_v3;
else
_cache_line_loop_ic_fn = __cache_line_loop;
}
if (IS_ENABLED(CONFIG_ARC_HAS_DCACHE)) {
- struct cpuinfo_arc_cache *dc = &cpuinfo_arc700[cpu].dcache;
+ struct cpuinfo_arc_cache *dc = &dc_info;
if (!dc->line_len)
panic("cache support enabled but non-existent cache\n");
@@ -1168,14 +1142,13 @@ void __init arc_cache_init_master(void)
/* check for D-Cache aliasing on ARCompact: ARCv2 has PIPT */
if (is_isa_arcompact()) {
int handled = IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
- int num_colors = dc->sz_k/dc->assoc/TO_KB(PAGE_SIZE);
- if (dc->alias) {
+ if (dc->colors > 1) {
if (!handled)
panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
- if (CACHE_COLORS_NUM != num_colors)
+ if (CACHE_COLORS_NUM != dc->colors)
panic("CACHE_COLORS_NUM not optimized for config\n");
- } else if (!dc->alias && handled) {
+ } else if (handled && dc->colors == 1) {
panic("Disable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
}
}
@@ -1218,9 +1191,6 @@ void __init arc_cache_init_master(void)
void __ref arc_cache_init(void)
{
unsigned int __maybe_unused cpu = smp_processor_id();
- char str[256];
-
- pr_info("%s", arc_cache_mumbojumbo(0, str, sizeof(str)));
if (!cpu)
arc_cache_init_master();
diff --git a/arch/arc/mm/extable.c b/arch/arc/mm/extable.c
index 4e14c42..88fa3a4 100644
--- a/arch/arc/mm/extable.c
+++ b/arch/arc/mm/extable.c
@@ -22,14 +22,3 @@ int fixup_exception(struct pt_regs *regs)
return 0;
}
-
-#ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-
-unsigned long arc_clear_user_noinline(void __user *to,
- unsigned long n)
-{
- return __arc_clear_user(to, n);
-}
-EXPORT_SYMBOL(arc_clear_user_noinline);
-
-#endif
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index f59e722..95119a5 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -13,6 +13,7 @@
#include <linux/kdebug.h>
#include <linux/perf_event.h>
#include <linux/mm_types.h>
+#include <asm/entry.h>
#include <asm/mmu.h>
/*
@@ -99,10 +100,10 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)
if (faulthandler_disabled() || !mm)
goto no_context;
- if (regs->ecr_cause & ECR_C_PROTV_STORE) /* ST/EX */
+ if (regs->ecr.cause & ECR_C_PROTV_STORE) /* ST/EX */
write = 1;
- else if ((regs->ecr_vec == ECR_V_PROTV) &&
- (regs->ecr_cause == ECR_C_PROTV_INST_FETCH))
+ else if ((regs->ecr.vec == ECR_V_PROTV) &&
+ (regs->ecr.cause == ECR_C_PROTV_INST_FETCH))
exec = 1;
flags = FAULT_FLAG_DEFAULT;
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 9f64d72..6a71b23 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -15,6 +15,7 @@
#include <linux/highmem.h>
#include <asm/page.h>
#include <asm/sections.h>
+#include <asm/setup.h>
#include <asm/arcregs.h>
pgd_t swapper_pg_dir[PTRS_PER_PGD] __aligned(PAGE_SIZE);
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 712c231..b07004d 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -8,7 +8,6 @@
#include <linux/module.h>
#include <linux/io.h>
#include <linux/mm.h>
-#include <linux/slab.h>
#include <linux/cache.h>
static inline bool arc_uncached_addr_space(phys_addr_t paddr)
@@ -25,13 +24,6 @@ static inline bool arc_uncached_addr_space(phys_addr_t paddr)
void __iomem *ioremap(phys_addr_t paddr, unsigned long size)
{
- phys_addr_t end;
-
- /* Don't allow wraparound or zero size */
- end = paddr + size - 1;
- if (!size || (end < paddr))
- return NULL;
-
/*
* If the region is h/w uncached, MMU mapping can be elided as optim
* The cast to u32 is fine as this region can only be inside 4GB
@@ -51,55 +43,22 @@ EXPORT_SYMBOL(ioremap);
* ARC hardware uncached region, this one still goes thru the MMU as caller
* might need finer access control (R/W/X)
*/
-void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size,
+void __iomem *ioremap_prot(phys_addr_t paddr, size_t size,
unsigned long flags)
{
- unsigned int off;
- unsigned long vaddr;
- struct vm_struct *area;
- phys_addr_t end;
pgprot_t prot = __pgprot(flags);
- /* Don't allow wraparound, zero size */
- end = paddr + size - 1;
- if ((!size) || (end < paddr))
- return NULL;
-
- /* An early platform driver might end up here */
- if (!slab_is_available())
- return NULL;
-
/* force uncached */
- prot = pgprot_noncached(prot);
-
- /* Mappings have to be page-aligned */
- off = paddr & ~PAGE_MASK;
- paddr &= PAGE_MASK_PHYS;
- size = PAGE_ALIGN(end + 1) - paddr;
-
- /*
- * Ok, go for it..
- */
- area = get_vm_area(size, VM_IOREMAP);
- if (!area)
- return NULL;
- area->phys_addr = paddr;
- vaddr = (unsigned long)area->addr;
- if (ioremap_page_range(vaddr, vaddr + size, paddr, prot)) {
- vunmap((void __force *)vaddr);
- return NULL;
- }
- return (void __iomem *)(off + (char __iomem *)vaddr);
+ return generic_ioremap_prot(paddr, size, pgprot_noncached(prot));
}
EXPORT_SYMBOL(ioremap_prot);
-
-void iounmap(const volatile void __iomem *addr)
+void iounmap(volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
return;
- vfree((void *)(PAGE_MASK & (unsigned long __force)addr));
+ generic_iounmap(addr);
}
EXPORT_SYMBOL(iounmap);
diff --git a/arch/arc/mm/tlb.c b/arch/arc/mm/tlb.c
index 5f71445..e536b2d 100644
--- a/arch/arc/mm/tlb.c
+++ b/arch/arc/mm/tlb.c
@@ -18,7 +18,9 @@
/* A copy of the ASID from the PID reg is kept in asid_cache */
DEFINE_PER_CPU(unsigned int, asid_cache) = MM_CTXT_FIRST_CYCLE;
-static int __read_mostly pae_exists;
+static struct cpuinfo_arc_mmu {
+ unsigned int ver, pg_sz_k, s_pg_sz_m, pae, sets, ways;
+} mmuinfo;
/*
* Utility Routine to erase a J-TLB entry
@@ -131,7 +133,7 @@ static void tlb_entry_insert(unsigned int pd0, phys_addr_t pd1)
noinline void local_flush_tlb_all(void)
{
- struct cpuinfo_arc_mmu *mmu = &cpuinfo_arc700[smp_processor_id()].mmu;
+ struct cpuinfo_arc_mmu *mmu = &mmuinfo;
unsigned long flags;
unsigned int entry;
int num_tlb = mmu->sets * mmu->ways;
@@ -389,7 +391,7 @@ void flush_tlb_kernel_range(unsigned long start, unsigned long end)
/*
* Routine to create a TLB entry
*/
-void create_tlb(struct vm_area_struct *vma, unsigned long vaddr, pte_t *ptep)
+static void create_tlb(struct vm_area_struct *vma, unsigned long vaddr, pte_t *ptep)
{
unsigned long flags;
unsigned int asid_or_sasid, rwx;
@@ -467,8 +469,8 @@ void create_tlb(struct vm_area_struct *vma, unsigned long vaddr, pte_t *ptep)
* Note that flush (when done) involves both WBACK - so physical page is
* in sync as well as INV - so any non-congruent aliases don't remain
*/
-void update_mmu_cache(struct vm_area_struct *vma, unsigned long vaddr_unaligned,
- pte_t *ptep)
+void update_mmu_cache_range(struct vm_fault *vmf, struct vm_area_struct *vma,
+ unsigned long vaddr_unaligned, pte_t *ptep, unsigned int nr)
{
unsigned long vaddr = vaddr_unaligned & PAGE_MASK;
phys_addr_t paddr = pte_val(*ptep) & PAGE_MASK_PHYS;
@@ -491,15 +493,19 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long vaddr_unaligned,
*/
if ((vma->vm_flags & VM_EXEC) ||
addr_not_cache_congruent(paddr, vaddr)) {
-
- int dirty = !test_and_set_bit(PG_dc_clean, &page->flags);
+ struct folio *folio = page_folio(page);
+ int dirty = !test_and_set_bit(PG_dc_clean, &folio->flags);
if (dirty) {
+ unsigned long offset = offset_in_folio(folio, paddr);
+ nr = folio_nr_pages(folio);
+ paddr -= offset;
+ vaddr -= offset;
/* wback + inv dcache lines (K-mapping) */
- __flush_dcache_page(paddr, paddr);
+ __flush_dcache_pages(paddr, paddr, nr);
/* invalidate any existing icache lines (U-mapping) */
if (vma->vm_flags & VM_EXEC)
- __inv_icache_page(paddr, vaddr);
+ __inv_icache_pages(paddr, vaddr, nr);
}
}
}
@@ -531,7 +537,7 @@ void update_mmu_cache_pmd(struct vm_area_struct *vma, unsigned long addr,
pmd_t *pmd)
{
pte_t pte = __pte(pmd_val(*pmd));
- update_mmu_cache(vma, addr, &pte);
+ update_mmu_cache_range(NULL, vma, addr, &pte, HPAGE_PMD_NR);
}
void local_flush_pmd_tlb_range(struct vm_area_struct *vma, unsigned long start,
@@ -560,89 +566,64 @@ void local_flush_pmd_tlb_range(struct vm_area_struct *vma, unsigned long start,
* the cpuinfo structure for later use.
* No Validation is done here, simply read/convert the BCRs
*/
-void read_decode_mmu_bcr(void)
+int arc_mmu_mumbojumbo(int c, char *buf, int len)
{
- struct cpuinfo_arc_mmu *mmu = &cpuinfo_arc700[smp_processor_id()].mmu;
- unsigned int tmp;
- struct bcr_mmu_3 {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned int ver:8, ways:4, sets:4, res:3, sasid:1, pg_sz:4,
- u_itlb:4, u_dtlb:4;
-#else
- unsigned int u_dtlb:4, u_itlb:4, pg_sz:4, sasid:1, res:3, sets:4,
- ways:4, ver:8;
-#endif
- } *mmu3;
+ struct cpuinfo_arc_mmu *mmu = &mmuinfo;
+ unsigned int bcr, u_dtlb, u_itlb, sasid;
+ struct bcr_mmu_3 *mmu3;
+ struct bcr_mmu_4 *mmu4;
+ char super_pg[64] = "";
+ int n = 0;
- struct bcr_mmu_4 {
-#ifdef CONFIG_CPU_BIG_ENDIAN
- unsigned int ver:8, sasid:1, sz1:4, sz0:4, res:2, pae:1,
- n_ways:2, n_entry:2, n_super:2, u_itlb:3, u_dtlb:3;
-#else
- /* DTLB ITLB JES JE JA */
- unsigned int u_dtlb:3, u_itlb:3, n_super:2, n_entry:2, n_ways:2,
- pae:1, res:2, sz0:4, sz1:4, sasid:1, ver:8;
-#endif
- } *mmu4;
-
- tmp = read_aux_reg(ARC_REG_MMU_BCR);
- mmu->ver = (tmp >> 24);
+ bcr = read_aux_reg(ARC_REG_MMU_BCR);
+ mmu->ver = (bcr >> 24);
if (is_isa_arcompact() && mmu->ver == 3) {
- mmu3 = (struct bcr_mmu_3 *)&tmp;
+ mmu3 = (struct bcr_mmu_3 *)&bcr;
mmu->pg_sz_k = 1 << (mmu3->pg_sz - 1);
mmu->sets = 1 << mmu3->sets;
mmu->ways = 1 << mmu3->ways;
- mmu->u_dtlb = mmu3->u_dtlb;
- mmu->u_itlb = mmu3->u_itlb;
- mmu->sasid = mmu3->sasid;
+ u_dtlb = mmu3->u_dtlb;
+ u_itlb = mmu3->u_itlb;
+ sasid = mmu3->sasid;
} else {
- mmu4 = (struct bcr_mmu_4 *)&tmp;
+ mmu4 = (struct bcr_mmu_4 *)&bcr;
mmu->pg_sz_k = 1 << (mmu4->sz0 - 1);
mmu->s_pg_sz_m = 1 << (mmu4->sz1 - 11);
mmu->sets = 64 << mmu4->n_entry;
mmu->ways = mmu4->n_ways * 2;
- mmu->u_dtlb = mmu4->u_dtlb * 4;
- mmu->u_itlb = mmu4->u_itlb * 4;
- mmu->sasid = mmu4->sasid;
- pae_exists = mmu->pae = mmu4->pae;
+ u_dtlb = mmu4->u_dtlb * 4;
+ u_itlb = mmu4->u_itlb * 4;
+ sasid = mmu4->sasid;
+ mmu->pae = mmu4->pae;
}
-}
-char *arc_mmu_mumbojumbo(int cpu_id, char *buf, int len)
-{
- int n = 0;
- struct cpuinfo_arc_mmu *p_mmu = &cpuinfo_arc700[cpu_id].mmu;
- char super_pg[64] = "";
-
- if (p_mmu->s_pg_sz_m)
- scnprintf(super_pg, 64, "%dM Super Page %s",
- p_mmu->s_pg_sz_m,
- IS_USED_CFG(CONFIG_TRANSPARENT_HUGEPAGE));
+ if (mmu->s_pg_sz_m)
+ scnprintf(super_pg, 64, "/%dM%s",
+ mmu->s_pg_sz_m,
+ IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) ? " (THP enabled)":"");
n += scnprintf(buf + n, len - n,
- "MMU [v%x]\t: %dk PAGE, %s, swalk %d lvl, JTLB %d (%dx%d), uDTLB %d, uITLB %d%s%s\n",
- p_mmu->ver, p_mmu->pg_sz_k, super_pg, CONFIG_PGTABLE_LEVELS,
- p_mmu->sets * p_mmu->ways, p_mmu->sets, p_mmu->ways,
- p_mmu->u_dtlb, p_mmu->u_itlb,
- IS_AVAIL2(p_mmu->pae, ", PAE40 ", CONFIG_ARC_HAS_PAE40));
+ "MMU [v%x]\t: %dk%s, swalk %d lvl, JTLB %dx%d, uDTLB %d, uITLB %d%s%s%s\n",
+ mmu->ver, mmu->pg_sz_k, super_pg, CONFIG_PGTABLE_LEVELS,
+ mmu->sets, mmu->ways,
+ u_dtlb, u_itlb,
+ IS_AVAIL1(sasid, ", SASID"),
+ IS_AVAIL2(mmu->pae, ", PAE40 ", CONFIG_ARC_HAS_PAE40));
- return buf;
+ return n;
}
int pae40_exist_but_not_enab(void)
{
- return pae_exists && !is_pae40_enabled();
+ return mmuinfo.pae && !is_pae40_enabled();
}
void arc_mmu_init(void)
{
- struct cpuinfo_arc_mmu *mmu = &cpuinfo_arc700[smp_processor_id()].mmu;
- char str[256];
+ struct cpuinfo_arc_mmu *mmu = &mmuinfo;
int compat = 0;
- pr_info("%s", arc_mmu_mumbojumbo(0, str, sizeof(str)));
-
/*
* Can't be done in processor.h due to header include dependencies
*/
@@ -719,7 +700,7 @@ volatile int dup_pd_silent; /* Be silent abt it or complain (default) */
void do_tlb_overlap_fault(unsigned long cause, unsigned long address,
struct pt_regs *regs)
{
- struct cpuinfo_arc_mmu *mmu = &cpuinfo_arc700[smp_processor_id()].mmu;
+ struct cpuinfo_arc_mmu *mmu = &mmuinfo;
unsigned long flags;
int set, n_ways = mmu->ways;
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index b821df7..1feb990 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -6,7 +6,6 @@
*/
#include <linux/of_fdt.h>
-#include <linux/of_platform.h>
#include <linux/libfdt.h>
#include <asm/asm-offsets.h>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7a27550..9557808 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -250,7 +250,7 @@
bool
config ARM_PATCH_PHYS_VIRT
- bool "Patch physical to virtual translations at runtime" if EMBEDDED
+ bool "Patch physical to virtual translations at runtime" if !ARCH_MULTIPLATFORM
default y
depends on MMU
help
@@ -1645,20 +1645,8 @@
copied, saving some precious ROM space. A possible drawback is a
slightly longer boot delay.
-config KEXEC
- bool "Kexec system call (EXPERIMENTAL)"
- depends on (!SMP || PM_SLEEP_SMP)
- depends on MMU
- select KEXEC_CORE
- help
- kexec is a system call that implements the ability to shutdown your
- current kernel, and to start another kernel. It is like a reboot
- but it is independent of the system firmware. And like a reboot
- you can start any kernel with it, not just Linux.
-
- It is an ongoing process to be certain the hardware in a machine
- is properly shutdown, so do not be surprised if this code does not
- initially work for you.
+config ARCH_SUPPORTS_KEXEC
+ def_bool (!SMP || PM_SLEEP_SMP) && MMU
config ATAGS_PROC
bool "Export atags in procfs"
@@ -1668,17 +1656,8 @@
Should the atags used to boot the kernel be exported in an "atags"
file in procfs. Useful with kexec.
-config CRASH_DUMP
- bool "Build kdump crash kernel (EXPERIMENTAL)"
- help
- Generate crash dump after being started by kexec. This should
- be normally only set in special crash dump kernels which are
- loaded in the main kernel with kexec-tools into a specially
- reserved region and then later executed after a crash by
- kdump/kexec. The crash dump kernel must be compiled to a
- memory address not used by the main kernel
-
- For more details see Documentation/admin-guide/kdump/kdump.rst
+config ARCH_SUPPORTS_CRASH_DUMP
+ def_bool y
config AUTO_ZRELADDR
bool "Auto calculation of the decompressed kernel image address" if !ARCH_MULTIPLATFORM
diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
index 589a1ce..eebb5a0 100644
--- a/arch/arm/boot/dts/allwinner/Makefile
+++ b/arch/arm/boot/dts/allwinner/Makefile
@@ -179,6 +179,25 @@
sun7i-a20-pcduino3-nano.dtb \
sun7i-a20-wexler-tab7200.dtb \
sun7i-a20-wits-pro-a20-dkt.dtb
+
+# Enables support for device-tree overlays for all pis
+DTC_FLAGS_sun8i-h3-orangepi-lite := -@
+DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
+DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
+DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
+DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
+DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
+DTC_FLAGS_sun8i-h3-orangepi-one := -@
+DTC_FLAGS_sun8i-h3-orangepi-plus := -@
+DTC_FLAGS_sun8i-h3-orangepi-2 := -@
+DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
+DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
+DTC_FLAGS_sun8i-h3-zeropi := -@
+DTC_FLAGS_sun8i-h3-nanopi-neo := -@
+DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
+DTC_FLAGS_sun8i-h3-orangepi-pc := -@
+DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
+DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a23-evb.dtb \
sun8i-a23-gt90h-v4.dtb \
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts b/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
index 94e24b5..8b3a753 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
// Copyright (C) 2022 Arm Ltd.
#include <dt-bindings/interrupt-controller/irq.h>
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
index 804aa19..c718130 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
// Copyright (C) 2022 Arm Ltd.
#define SOC_PERIPHERAL_IRQ(nr) GIC_SPI nr
diff --git a/arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi b/arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi
index e9bc749..a415c4a 100644
--- a/arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi
+++ b/arch/arm/boot/dts/allwinner/sunxi-d1s-t113-mangopi-mq-r.dtsi
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
// Copyright (C) 2022 Arm Ltd.
/*
* Common peripherals and configurations for MangoPi MQ-R boards.
diff --git a/arch/arm/boot/dts/arm/integratorap.dts b/arch/arm/boot/dts/arm/integratorap.dts
index 5b52d75..d9927d3 100644
--- a/arch/arm/boot/dts/arm/integratorap.dts
+++ b/arch/arm/boot/dts/arm/integratorap.dts
@@ -158,7 +158,7 @@ pic: pic@14000000 {
valid-mask = <0x003fffff>;
};
- pci: pciv3@62000000 {
+ pci: pci@62000000 {
compatible = "arm,integrator-ap-pci", "v3,v360epc-pci";
device_type = "pci";
#interrupt-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index c689843..23cbc72 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -26,6 +26,7 @@
aspeed-bmc-facebook-wedge400.dtb \
aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-facebook-yosemitev2.dtb \
+ aspeed-bmc-facebook-yosemite4.dtb \
aspeed-bmc-ibm-bonnell.dtb \
aspeed-bmc-ibm-everest.dtb \
aspeed-bmc-ibm-rainier.dtb \
@@ -53,6 +54,7 @@
aspeed-bmc-quanta-q71l.dtb \
aspeed-bmc-quanta-s6q.dtb \
aspeed-bmc-supermicro-x11spi.dtb \
+ aspeed-bmc-inventec-starscream.dtb \
aspeed-bmc-inventec-transformers.dtb \
aspeed-bmc-tyan-s7106.dtb \
aspeed-bmc-tyan-s8036.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
index 1e0e884..0715cb9 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ampere-mtmitchell.dts
@@ -4,12 +4,18 @@
/dts-v1/;
#include "aspeed-g6.dtsi"
+#include <dt-bindings/i2c/i2c.h>
#include <dt-bindings/gpio/aspeed-gpio.h>
/ {
model = "Ampere Mt.Mitchell BMC";
compatible = "ampere,mtmitchell-bmc", "aspeed,ast2600";
+ aliases {
+ serial7 = &uart8;
+ serial8 = &uart9;
+ };
+
chosen {
stdout-path = &uart5;
};
@@ -61,174 +67,192 @@ gpioI5mux: mux-controller {
adc0mux: adc0mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 0>;
+ io-channels = <&adc_i2c_0 0>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc1mux: adc1mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 1>;
+ io-channels = <&adc_i2c_0 1>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc2mux: adc2mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 2>;
+ io-channels = <&adc_i2c_0 2>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc3mux: adc3mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 3>;
+ io-channels = <&adc_i2c_0 3>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc4mux: adc4mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 4>;
+ io-channels = <&adc_i2c_0 4>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc5mux: adc5mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 5>;
+ io-channels = <&adc_i2c_0 5>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc6mux: adc6mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 6>;
+ io-channels = <&adc_i2c_0 6>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc7mux: adc7mux {
compatible = "io-channel-mux";
- io-channels = <&adc0 7>;
+ io-channels = <&adc_i2c_0 7>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc8mux: adc8mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 0>;
+ io-channels = <&adc_i2c_0 8>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc9mux: adc9mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 1>;
+ io-channels = <&adc_i2c_0 9>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc10mux: adc10mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 2>;
+ io-channels = <&adc_i2c_0 10>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc11mux: adc11mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 3>;
+ io-channels = <&adc_i2c_0 11>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc12mux: adc12mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 4>;
+ io-channels = <&adc_i2c_0 12>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc13mux: adc13mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 5>;
+ io-channels = <&adc_i2c_0 13>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc14mux: adc14mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 6>;
+ io-channels = <&adc_i2c_0 14>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
adc15mux: adc15mux {
compatible = "io-channel-mux";
- io-channels = <&adc1 7>;
+ io-channels = <&adc_i2c_0 15>;
#io-channel-cells = <1>;
io-channel-names = "parent";
mux-controls = <&gpioI5mux>;
+ settle-time-us = <10000>;
channels = "s0", "s1";
};
iio-hwmon {
compatible = "iio-hwmon";
- io-channels = <&adc0mux 0>, <&adc0mux 1>,
- <&adc1mux 0>, <&adc1mux 1>,
- <&adc2mux 0>, <&adc2mux 1>,
- <&adc3mux 0>, <&adc3mux 1>,
- <&adc4mux 0>, <&adc4mux 1>,
- <&adc5mux 0>, <&adc5mux 1>,
- <&adc6mux 0>, <&adc6mux 1>,
- <&adc7mux 0>, <&adc7mux 1>,
- <&adc8mux 0>, <&adc8mux 1>,
- <&adc9mux 0>, <&adc9mux 1>,
- <&adc10mux 0>, <&adc10mux 1>,
- <&adc11mux 0>, <&adc11mux 1>,
- <&adc12mux 0>, <&adc12mux 1>,
- <&adc13mux 0>, <&adc13mux 1>,
- <&adc14mux 0>, <&adc14mux 1>,
- <&adc15mux 0>, <&adc15mux 1>,
- <&adc_i2c 0>, <&adc_i2c 1>,
- <&adc_i2c 2>, <&adc_i2c 3>,
- <&adc_i2c 4>, <&adc_i2c 5>,
- <&adc_i2c 6>, <&adc_i2c 7>,
- <&adc_i2c 8>, <&adc_i2c 9>,
- <&adc_i2c 10>, <&adc_i2c 11>,
- <&adc_i2c 12>, <&adc_i2c 13>,
- <&adc_i2c 14>, <&adc_i2c 15>;
+ io-channels = <&adc0mux 0>, <&adc0mux 1>,
+ <&adc1mux 0>, <&adc1mux 1>,
+ <&adc2mux 0>, <&adc2mux 1>,
+ <&adc3mux 0>, <&adc3mux 1>,
+ <&adc4mux 0>, <&adc4mux 1>,
+ <&adc5mux 0>, <&adc5mux 1>,
+ <&adc6mux 0>, <&adc6mux 1>,
+ <&adc7mux 0>, <&adc7mux 1>,
+ <&adc8mux 0>, <&adc8mux 1>,
+ <&adc9mux 0>, <&adc9mux 1>,
+ <&adc10mux 0>, <&adc10mux 1>,
+ <&adc11mux 0>, <&adc11mux 1>,
+ <&adc12mux 0>, <&adc12mux 1>,
+ <&adc13mux 0>, <&adc13mux 1>,
+ <&adc14mux 0>, <&adc14mux 1>,
+ <&adc15mux 0>, <&adc15mux 1>,
+ <&adc_i2c_1 0>, <&adc_i2c_1 1>,
+ <&adc_i2c_1 2>, <&adc_i2c_1 3>,
+ <&adc_i2c_1 4>, <&adc_i2c_1 5>,
+ <&adc_i2c_1 6>, <&adc_i2c_1 7>,
+ <&adc_i2c_1 8>, <&adc_i2c_1 9>,
+ <&adc_i2c_1 10>, <&adc_i2c_1 11>,
+ <&adc_i2c_1 12>, <&adc_i2c_1 13>,
+ <&adc_i2c_1 14>, <&adc_i2c_1 15>,
+ <&adc0 0>, <&adc0 1>,
+ <&adc0 2>;
};
};
@@ -307,6 +331,14 @@ &uart4 {
status = "okay";
};
+&uart8 {
+ status = "okay";
+};
+
+&uart9 {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
@@ -336,12 +368,27 @@ psu@59 {
&i2c3 {
status = "okay";
+ bus-frequency = <1000000>;
+ multi-master;
+ mctp-controller;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
};
&i2c4 {
status = "okay";
- adc_i2c: adc@16 {
+ adc_i2c_0: adc@14 {
+ compatible = "lltc,ltc2497";
+ reg = <0x14>;
+ vref-supply = <&voltage_mon_reg>;
+ #io-channel-cells = <1>;
+ };
+
+ adc_i2c_1: adc@16 {
compatible = "lltc,ltc2497";
reg = <0x16>;
vref-supply = <&voltage_mon_reg>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-bytedance-g220a.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-bytedance-g220a.dts
index f75cad4..3f03a19 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-bytedance-g220a.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-bytedance-g220a.dts
@@ -424,7 +424,7 @@ &i2c2 {
&i2c3 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -471,7 +471,7 @@ &i2c5 {
&i2c6 {
status = "okay";
- i2c-switch@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9548";
reg = <0x72>;
#address-cells = <1>;
@@ -524,7 +524,7 @@ channel_6_7: i2c@7 {
};
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -533,7 +533,7 @@ channel_6_8: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -569,7 +569,7 @@ channel_6_9: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -605,7 +605,7 @@ channel_6_10: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -640,7 +640,7 @@ channel_6_11: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -808,7 +808,7 @@ &i2c9 {
&i2c10 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -838,7 +838,7 @@ channel_10_3: i2c@3 {
};
};
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cloudripper.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cloudripper.dts
index 5cd0600..d49328f 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cloudripper.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cloudripper.dts
@@ -132,7 +132,7 @@ &i2c1 {
* PCA9548 (1-0070) provides 8 channels connecting to SMB (Switch
* Main Board).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -194,7 +194,7 @@ &i2c2 {
* PCA9548 (2-0070) provides 8 channels connecting to SCM (System
* Controller Module).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -256,7 +256,7 @@ &i2c3 {
* PCA9548 (3-0070) provides 8 channels connecting to SMB (Switch
* Main Board).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -423,7 +423,7 @@ &i2c8 {
* PCA9548 (8-0070) provides 8 channels connecting to PDB (Power
* Delivery Board).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -486,7 +486,7 @@ &i2c15 {
* PCA9548 (15-0076) provides 8 channels connecting to FCM (Fan
* Controller Module).
*/
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cmm.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cmm.dts
index 90a3f48..2415386 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cmm.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-cmm.dts
@@ -328,7 +328,7 @@ &i2c0 {
&i2c1 {
status = "okay";
- i2c-switch@77 {
+ i2c-mux@77 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -341,7 +341,7 @@ imux16: i2c@0 {
#size-cells = <0>;
reg = <0>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -390,7 +390,7 @@ imux111: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -446,7 +446,7 @@ imux17: i2c@1 {
#size-cells = <0>;
reg = <1>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -495,7 +495,7 @@ imux127: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -551,7 +551,7 @@ imux18: i2c@2 {
#size-cells = <0>;
reg = <2>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -600,7 +600,7 @@ imux47: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -656,7 +656,7 @@ imux19: i2c@3 {
#size-cells = <0>;
reg = <3>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -705,7 +705,7 @@ imux63: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -761,7 +761,7 @@ imux20: i2c@4 {
#size-cells = <0>;
reg = <4>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -810,7 +810,7 @@ imux79: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -866,7 +866,7 @@ imux21: i2c@5 {
#size-cells = <0>;
reg = <5>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -915,7 +915,7 @@ imux95: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -971,7 +971,7 @@ imux22: i2c@6 {
#size-cells = <0>;
reg = <6>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1020,7 +1020,7 @@ imux143: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1076,7 +1076,7 @@ imux23: i2c@7 {
#size-cells = <0>;
reg = <7>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1125,7 +1125,7 @@ imux159: i2c@7 {
};
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1183,7 +1183,7 @@ imux167: i2c@7 {
&i2c2 {
status = "okay";
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1281,7 +1281,7 @@ &i2c7 {
&i2c8 {
status = "okay";
- i2c-switch@77 {
+ i2c-mux@77 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1294,7 +1294,7 @@ imux32: i2c@0 {
#size-cells = <0>;
reg = <0>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1350,7 +1350,7 @@ imux33: i2c@1 {
#size-cells = <0>;
reg = <1>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1406,7 +1406,7 @@ imux34: i2c@2 {
#size-cells = <0>;
reg = <2>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1462,7 +1462,7 @@ imux35: i2c@3 {
#size-cells = <0>;
reg = <3>;
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-elbert.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-elbert.dts
index b5cd4c7..74f3c67 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-elbert.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-elbert.dts
@@ -65,7 +65,7 @@ &kcs3 {
};
&i2c2 {
- i2c-switch@75 {
+ i2c-mux@75 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -123,7 +123,7 @@ imux23: i2c@7 {
};
&i2c5 {
- i2c-switch@75 {
+ i2c-mux@75 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts
index 6b319f3..f23c26a 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts
@@ -233,7 +233,7 @@ &i2c2 {
* PCA9548 (2-0070) provides 8 channels connecting to SCM (System
* Controller Module).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -303,7 +303,7 @@ &i2c8 {
* PCA9548 (8-0070) provides 8 channels connecting to SMB (Switch
* Main Board).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -315,7 +315,7 @@ imux24: i2c@0 {
#size-cells = <0>;
reg = <0>;
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -481,7 +481,7 @@ imux25: i2c@1 {
#size-cells = <0>;
reg = <1>;
- i2c-switch@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -544,7 +544,7 @@ imux26: i2c@2 {
#size-cells = <0>;
reg = <2>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -615,7 +615,7 @@ imux27: i2c@3 {
#size-cells = <0>;
reg = <3>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -715,7 +715,7 @@ &i2c11 {
* PCA9548 (11-0077) provides 8 channels connecting to SMB (Switch
* Main Board).
*/
- i2c-switch@77 {
+ i2c-mux@77 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -727,7 +727,7 @@ imux40: i2c@0 {
#size-cells = <0>;
reg = <0>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -790,7 +790,7 @@ imux41: i2c@1 {
#size-cells = <0>;
reg = <1>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -853,7 +853,7 @@ imux42: i2c@2 {
#size-cells = <0>;
reg = <2>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -916,7 +916,7 @@ imux43: i2c@3 {
#size-cells = <0>;
reg = <3>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -979,7 +979,7 @@ imux44: i2c@4 {
#size-cells = <0>;
reg = <4>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1042,7 +1042,7 @@ imux45: i2c@5 {
#size-cells = <0>;
reg = <5>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1105,7 +1105,7 @@ imux46: i2c@6 {
#size-cells = <0>;
reg = <6>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1168,7 +1168,7 @@ imux47: i2c@7 {
#size-cells = <0>;
reg = <7>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minipack.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minipack.dts
index 230d16c..aafd104 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minipack.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-minipack.dts
@@ -344,7 +344,7 @@ &i2c2 {
* I2C Switch 2-0070 is connecting to SCM (System Controller
* Module).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -425,7 +425,7 @@ &i2c7 {
&i2c8 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -441,7 +441,7 @@ imux24: i2c@0 {
#size-cells = <0>;
reg = <0>;
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -507,7 +507,7 @@ imux25: i2c@1 {
#size-cells = <0>;
reg = <1>;
- i2c-switch@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -573,7 +573,7 @@ imux26: i2c@2 {
#size-cells = <0>;
reg = <2>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -639,7 +639,7 @@ imux27: i2c@3 {
#size-cells = <0>;
reg = <3>;
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -729,7 +729,7 @@ &i2c9 {
* I2C Switch 9-0070 is connecting to MAC/PHY EEPROMs on SMB
* (Switch Main Board).
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -793,7 +793,7 @@ &i2c10 {
&i2c11 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -809,7 +809,7 @@ imux40: i2c@0 {
#size-cells = <0>;
reg = <0>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -875,7 +875,7 @@ imux41: i2c@1 {
#size-cells = <0>;
reg = <1>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -941,7 +941,7 @@ imux42: i2c@2 {
#size-cells = <0>;
reg = <2>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1007,7 +1007,7 @@ imux43: i2c@3 {
#size-cells = <0>;
reg = <3>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1073,7 +1073,7 @@ imux44: i2c@4 {
#size-cells = <0>;
reg = <4>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1139,7 +1139,7 @@ imux45: i2c@5 {
#size-cells = <0>;
reg = <5>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1205,7 +1205,7 @@ imux46: i2c@6 {
#size-cells = <0>;
reg = <6>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -1271,7 +1271,7 @@ imux47: i2c@7 {
#size-cells = <0>;
reg = <7>;
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-tiogapass.dts
index b6b1635..704ee68 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-tiogapass.dts
@@ -211,7 +211,7 @@ &i2c0 {
&i2c1 {
status = "okay";
//X24 Riser
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9544";
#address-cells = <1>;
#size-cells = <0>;
@@ -243,7 +243,7 @@ eeprom@50 {
pagesize = <32>;
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9546";
#address-cells = <1>;
#size-cells = <0>;
@@ -303,7 +303,7 @@ eeprom@50 {
pagesize = <32>;
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9546";
#address-cells = <1>;
#size-cells = <0>;
@@ -363,7 +363,7 @@ eeprom@50 {
pagesize = <32>;
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9546";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge100.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge100.dts
index 584efa5..97cd11c 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge100.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge100.dts
@@ -44,7 +44,7 @@ flash1@0 {
};
&i2c7 {
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge400.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge400.dts
index ed30594..a677c82 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge400.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-wedge400.dts
@@ -59,7 +59,8 @@ chosen {
ast-adc-hwmon {
compatible = "iio-hwmon";
- io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>;
+ io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>,
+ <&adc 5>, <&adc 6>, <&adc 7>, <&adc 8>;
};
/*
@@ -138,7 +139,7 @@ &i2c1 {
&i2c2 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -218,7 +219,7 @@ &i2c7 {
&i2c8 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -287,7 +288,7 @@ &i2c10 {
&i2c11 {
status = "okay";
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -366,6 +367,7 @@ &uhci {
};
&sdhci1 {
+ max-frequency = <25000000>;
/*
* DMA mode needs to be disabled to avoid conflicts with UHCI
* Controller in AST2500 SoC.
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yamp.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yamp.dts
index 5e61058..98fe0d6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yamp.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yamp.dts
@@ -57,7 +57,7 @@ &i2c1 {
&i2c2 {
status = "okay";
- i2c-switch@75 {
+ i2c-mux@75 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
new file mode 100644
index 0000000..64075cc
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -0,0 +1,624 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2022 Facebook Inc.
+
+/dts-v1/;
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/leds/leds-pca955x.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/ {
+ model = "Facebook Yosemite 4 BMC";
+ compatible = "facebook,yosemite4-bmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ serial5 = &uart6;
+ serial6 = &uart7;
+ serial7 = &uart8;
+ serial8 = &uart9;
+ };
+
+ chosen {
+ stdout-path = "serial4:57600n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+ <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+ <&adc1 0>, <&adc1 1>;
+ };
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&uart6 {
+ status = "okay";
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&uart8 {
+ status = "okay";
+};
+
+&uart9 {
+ status = "okay";
+};
+
+&wdt1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdtrst1_default>;
+ aspeed,reset-type = "soc";
+ aspeed,external-signal;
+ aspeed,ext-push-pull;
+ aspeed,ext-active-high;
+ aspeed,ext-pulse-duration = <256>;
+};
+
+&mac2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii3_default>;
+ use-ncsi;
+ mlx,multi-host;
+};
+
+&mac3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii4_default>;
+ use-ncsi;
+ mlx,multi-host;
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-64.dtsi"
+ };
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc2";
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c2 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c3 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c4 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c5 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c6 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+ mctp-controller;
+ bus-frequency = <400000>;
+ multi-master;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ power-sensor@40 {
+ compatible = "adi,adm1278";
+ reg = <0x40>;
+ };
+};
+
+&i2c8 {
+ status = "okay";
+ bus-frequency = <400000>;
+ i2c-mux@70 {
+ compatible = "nxp,pca9544";
+ idle-state = <0>;
+ i2c-mux-idle-disconnect;
+ reg = <0x70>;
+ };
+};
+
+&i2c9 {
+ status = "okay";
+ bus-frequency = <400000>;
+ i2c-mux@71 {
+ compatible = "nxp,pca9544";
+ idle-state = <0>;
+ i2c-mux-idle-disconnect;
+ reg = <0x71>;
+ };
+};
+
+&i2c10 {
+ status = "okay";
+ bus-frequency = <400000>;
+};
+
+&i2c11 {
+ status = "okay";
+ power-sensor@10 {
+ compatible = "adi, adm1272";
+ reg = <0x10>;
+ };
+
+ power-sensor@12 {
+ compatible = "adi, adm1272";
+ reg = <0x12>;
+ };
+
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ temperature-sensor@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+
+ temperature-sensor@4a {
+ compatible = "ti,tmp75";
+ reg = <0x4a>;
+ };
+
+ temperature-sensor@4b {
+ compatible = "ti,tmp75";
+ reg = <0x4b>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c256";
+ reg = <0x54>;
+ };
+};
+
+&i2c12 {
+ status = "okay";
+ bus-frequency = <400000>;
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ rtc@6f {
+ compatible = "nuvoton,nct3018y";
+ reg = <0x6f>;
+ };
+};
+
+&i2c13 {
+ status = "okay";
+ bus-frequency = <400000>;
+};
+
+&i2c14 {
+ status = "okay";
+ bus-frequency = <400000>;
+ adc@1d {
+ compatible = "ti,adc128d818";
+ reg = <0x1d>;
+ ti,mode = /bits/ 8 <2>;
+ };
+
+ adc@35 {
+ compatible = "ti,adc128d818";
+ reg = <0x35>;
+ ti,mode = /bits/ 8 <2>;
+ };
+
+ adc@37 {
+ compatible = "ti,adc128d818";
+ reg = <0x37>;
+ ti,mode = /bits/ 8 <2>;
+ };
+
+ power-sensor@40 {
+ compatible = "ti,ina230";
+ reg = <0x40>;
+ };
+
+ power-sensor@41 {
+ compatible = "ti,ina230";
+ reg = <0x41>;
+ };
+
+ power-sensor@42 {
+ compatible = "ti,ina230";
+ reg = <0x42>;
+ };
+
+ power-sensor@43 {
+ compatible = "ti,ina230";
+ reg = <0x43>;
+ };
+
+ power-sensor@44 {
+ compatible = "ti,ina230";
+ reg = <0x44>;
+ };
+
+ temperature-sensor@4e {
+ compatible = "ti,tmp75";
+ reg = <0x4e>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp75";
+ reg = <0x4f>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ i2c-mux@71 {
+ compatible = "nxp,pca9846";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ idle-state = <0>;
+ i2c-mux-idle-disconnect;
+ reg = <0x71>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <2>;
+ };
+
+ pwm@20{
+ compatible = "max31790";
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ gpio@22{
+ compatible = "ti,tca6424";
+ reg = <0x22>;
+ };
+
+ pwm@23{
+ compatible = "max31790";
+ reg = <0x23>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ adc@33 {
+ compatible = "maxim,max11615";
+ reg = <0x33>;
+ };
+
+ eeprom@52 {
+ compatible = "atmel,24c128";
+ reg = <0x52>;
+ };
+
+ gpio@61 {
+ compatible = "nxp,pca9552";
+ reg = <0x61>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <2>;
+ };
+
+ pwm@20{
+ compatible = "max31790";
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ gpio@22{
+ compatible = "ti,tca6424";
+ reg = <0x22>;
+ };
+
+ pwm@23{
+ compatible = "max31790";
+ reg = <0x23>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ adc@33 {
+ compatible = "maxim,max11615";
+ reg = <0x33>;
+ };
+
+ eeprom@52 {
+ compatible = "atmel,24c128";
+ reg = <0x52>;
+ };
+
+ gpio@61 {
+ compatible = "nxp,pca9552";
+ reg = <0x61>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+
+ i2c-mux@73 {
+ compatible = "nxp,pca9544";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ idle-state = <0>;
+ i2c-mux-idle-disconnect;
+ reg = <0x73>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+ };
+ };
+};
+
+&i2c15 {
+ status = "okay";
+ mctp-controller;
+ multi-master;
+ bus-frequency = <400000>;
+
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ i2c-mux@72 {
+ compatible = "nxp,pca9544";
+ idle-state = <0>;
+ i2c-mux-idle-disconnect;
+ reg = <0x72>;
+ };
+};
+
+&adc0 {
+ ref_voltage = <2500>;
+ status = "okay";
+ pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+ &pinctrl_adc2_default &pinctrl_adc3_default
+ &pinctrl_adc4_default &pinctrl_adc5_default
+ &pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+ ref_voltage = <2500>;
+ status = "okay";
+ pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default>;
+};
+
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&uhci {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts
index 81902cb..d47ce4e 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-bonnell.dts
@@ -12,38 +12,11 @@ / {
compatible = "ibm,bonnell-bmc", "aspeed,ast2600";
aliases {
- i2c100 = &cfam0_i2c0;
- i2c101 = &cfam0_i2c1;
- i2c110 = &cfam0_i2c10;
- i2c111 = &cfam0_i2c11;
- i2c112 = &cfam0_i2c12;
- i2c113 = &cfam0_i2c13;
- i2c114 = &cfam0_i2c14;
- i2c115 = &cfam0_i2c15;
- i2c202 = &cfam1_i2c2;
- i2c203 = &cfam1_i2c3;
- i2c210 = &cfam1_i2c10;
- i2c211 = &cfam1_i2c11;
- i2c214 = &cfam1_i2c14;
- i2c215 = &cfam1_i2c15;
- i2c216 = &cfam1_i2c16;
- i2c217 = &cfam1_i2c17;
-
serial4 = &uart5;
i2c16 = &i2c11mux0chn0;
i2c17 = &i2c11mux0chn1;
i2c18 = &i2c11mux0chn2;
i2c19 = &i2c11mux0chn3;
-
- spi10 = &cfam0_spi0;
- spi11 = &cfam0_spi1;
- spi12 = &cfam0_spi2;
- spi13 = &cfam0_spi3;
- spi20 = &cfam1_spi0;
- spi21 = &cfam1_spi1;
- spi22 = &cfam1_spi2;
- spi23 = &cfam1_spi3;
-
};
chosen {
@@ -197,313 +170,6 @@ &emmc {
clk-phase-mmc-hs200 = <180>, <180>;
};
-&fsim0 {
- status = "okay";
-
- #address-cells = <2>;
- #size-cells = <0>;
-
- cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_HIGH>;
-
- cfam@0,0 {
- reg = <0 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <0>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam0_i2c0: i2c-bus@0 {
- reg = <0>; /* OMI01 */
- };
-
- cfam0_i2c1: i2c-bus@1 {
- reg = <1>; /* OMI23 */
- };
-
- cfam0_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam0_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam0_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam0_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam0_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam0_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam0_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ0: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub0: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
- };
- };
-};
-
-&fsi_hub0 {
- cfam@1,0 {
- reg = <1 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <1>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam1_i2c2: i2c-bus@2 {
- reg = <2>; /* OMI45 */
- };
-
- cfam1_i2c3: i2c-bus@3 {
- reg = <3>; /* OMI67 */
- };
-
- cfam1_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam1_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam1_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam1_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam1_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam1_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam1_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ1: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub1: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-};
-
&ibt {
status = "okay";
};
@@ -913,3 +579,33 @@ &kcs3 {
aspeed,lpc-io-reg = <0xca2>;
aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
};
+
+#include "ibm-power10-dual.dtsi"
+
+&cfam0_i2c10 {
+ eeprom@50 {
+ compatible = "atmel,at30tse004a";
+ reg = <0x50>;
+ };
+};
+
+&cfam0_i2c11 {
+ eeprom@50 {
+ compatible = "atmel,at30tse004a";
+ reg = <0x50>;
+ };
+};
+
+&cfam0_i2c12 {
+ eeprom@50 {
+ compatible = "atmel,at30tse004a";
+ reg = <0x50>;
+ };
+};
+
+&cfam0_i2c13 {
+ eeprom@50 {
+ compatible = "atmel,at30tse004a";
+ reg = <0x50>;
+ };
+};
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts
index c6f8f20..214b2e6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-everest.dts
@@ -12,38 +12,6 @@ / {
compatible = "ibm,everest-bmc", "aspeed,ast2600";
aliases {
- i2c100 = &cfam0_i2c0;
- i2c101 = &cfam0_i2c1;
- i2c110 = &cfam0_i2c10;
- i2c111 = &cfam0_i2c11;
- i2c112 = &cfam0_i2c12;
- i2c113 = &cfam0_i2c13;
- i2c114 = &cfam0_i2c14;
- i2c115 = &cfam0_i2c15;
- i2c202 = &cfam1_i2c2;
- i2c203 = &cfam1_i2c3;
- i2c210 = &cfam1_i2c10;
- i2c211 = &cfam1_i2c11;
- i2c214 = &cfam1_i2c14;
- i2c215 = &cfam1_i2c15;
- i2c216 = &cfam1_i2c16;
- i2c217 = &cfam1_i2c17;
- i2c300 = &cfam2_i2c0;
- i2c301 = &cfam2_i2c1;
- i2c310 = &cfam2_i2c10;
- i2c311 = &cfam2_i2c11;
- i2c312 = &cfam2_i2c12;
- i2c313 = &cfam2_i2c13;
- i2c314 = &cfam2_i2c14;
- i2c315 = &cfam2_i2c15;
- i2c402 = &cfam3_i2c2;
- i2c403 = &cfam3_i2c3;
- i2c410 = &cfam3_i2c10;
- i2c411 = &cfam3_i2c11;
- i2c414 = &cfam3_i2c14;
- i2c415 = &cfam3_i2c15;
- i2c416 = &cfam3_i2c16;
- i2c417 = &cfam3_i2c17;
i2c500 = &cfam4_i2c0;
i2c501 = &cfam4_i2c1;
i2c510 = &cfam4_i2c10;
@@ -113,22 +81,72 @@ aliases {
serial4 = &uart5;
- spi10 = &cfam0_spi0;
- spi11 = &cfam0_spi1;
- spi12 = &cfam0_spi2;
- spi13 = &cfam0_spi3;
- spi20 = &cfam1_spi0;
- spi21 = &cfam1_spi1;
- spi22 = &cfam1_spi2;
- spi23 = &cfam1_spi3;
- spi30 = &cfam2_spi0;
- spi31 = &cfam2_spi1;
- spi32 = &cfam2_spi2;
- spi33 = &cfam2_spi3;
- spi40 = &cfam3_spi0;
- spi41 = &cfam3_spi1;
- spi42 = &cfam3_spi2;
- spi43 = &cfam3_spi3;
+ sbefifo500 = &sbefifo500;
+ sbefifo501 = &sbefifo501;
+ sbefifo510 = &sbefifo510;
+ sbefifo511 = &sbefifo511;
+ sbefifo512 = &sbefifo512;
+ sbefifo513 = &sbefifo513;
+ sbefifo514 = &sbefifo514;
+ sbefifo515 = &sbefifo515;
+ sbefifo602 = &sbefifo602;
+ sbefifo603 = &sbefifo603;
+ sbefifo610 = &sbefifo610;
+ sbefifo611 = &sbefifo611;
+ sbefifo614 = &sbefifo614;
+ sbefifo615 = &sbefifo615;
+ sbefifo616 = &sbefifo616;
+ sbefifo617 = &sbefifo617;
+ sbefifo700 = &sbefifo700;
+ sbefifo701 = &sbefifo701;
+ sbefifo710 = &sbefifo710;
+ sbefifo711 = &sbefifo711;
+ sbefifo712 = &sbefifo712;
+ sbefifo713 = &sbefifo713;
+ sbefifo714 = &sbefifo714;
+ sbefifo715 = &sbefifo715;
+ sbefifo802 = &sbefifo802;
+ sbefifo803 = &sbefifo803;
+ sbefifo810 = &sbefifo810;
+ sbefifo811 = &sbefifo811;
+ sbefifo814 = &sbefifo814;
+ sbefifo815 = &sbefifo815;
+ sbefifo816 = &sbefifo816;
+ sbefifo817 = &sbefifo817;
+
+ scom500 = &scom500;
+ scom501 = &scom501;
+ scom510 = &scom510;
+ scom511 = &scom511;
+ scom512 = &scom512;
+ scom513 = &scom513;
+ scom514 = &scom514;
+ scom515 = &scom515;
+ scom602 = &scom602;
+ scom603 = &scom603;
+ scom610 = &scom610;
+ scom611 = &scom611;
+ scom614 = &scom614;
+ scom615 = &scom615;
+ scom616 = &scom616;
+ scom617 = &scom617;
+ scom700 = &scom700;
+ scom701 = &scom701;
+ scom710 = &scom710;
+ scom711 = &scom711;
+ scom712 = &scom712;
+ scom713 = &scom713;
+ scom714 = &scom714;
+ scom715 = &scom715;
+ scom802 = &scom802;
+ scom803 = &scom803;
+ scom810 = &scom810;
+ scom811 = &scom811;
+ scom814 = &scom814;
+ scom815 = &scom815;
+ scom816 = &scom816;
+ scom817 = &scom817;
+
spi50 = &cfam4_spi0;
spi51 = &cfam4_spi1;
spi52 = &cfam4_spi2;
@@ -399,7 +417,7 @@ pca2: pca9552@65 {
"expander-cable-card5";
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -544,7 +562,7 @@ pca3: pca9552@66 {
"expander-cable-card11";
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -701,7 +719,7 @@ led@1 {
&i2c6 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -1792,7 +1810,7 @@ eeprom@50 {
reg = <0x50>;
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -1929,7 +1947,7 @@ ibm-panel@62 {
reg = <(0x62 | I2C_OWN_SLAVE_ADDRESS)>;
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -2188,7 +2206,7 @@ pca0: pca9552@61 {
};
};
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -2241,7 +2259,7 @@ eeprom@50 {
&i2c15 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -2293,7 +2311,7 @@ eeprom@53 {
};
};
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -2345,7 +2363,7 @@ eeprom@53 {
};
};
- i2c-switch@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9546";
reg = <0x72>;
#address-cells = <1>;
@@ -2413,1244 +2431,6 @@ &emmc {
clk-phase-mmc-hs200 = <210>, <228>;
};
-&fsim0 {
- status = "okay";
-
- #address-cells = <2>;
- #size-cells = <0>;
-
- /*
- * CFAM Reset is supposed to be active low but pass1 hardware is wired
- * active high.
- */
- cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_HIGH>;
-
- cfam@0,0 { /* DCM0_C0 */
- reg = <0 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <0>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam0_i2c0: i2c-bus@0 {
- reg = <0>; /* OMI01 */
- };
-
- cfam0_i2c1: i2c-bus@1 {
- reg = <1>; /* OMI23 */
- };
-
- cfam0_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam0_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam0_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam0_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam0_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam0_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam0_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ0: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub0: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
- };
- };
-};
-
-&fsi_hub0 {
- cfam@1,0 { /* DCM0_C1 */
- reg = <1 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <1>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam1_i2c2: i2c-bus@2 {
- reg = <2>; /* OMI45 */
- };
-
- cfam1_i2c3: i2c-bus@3 {
- reg = <3>; /* OMI67 */
- };
-
- cfam1_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam1_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam1_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam1_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam1_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam1_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam1_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ1: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub1: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@2,0 { /* DCM1_C0 */
- reg = <2 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <2>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam2_i2c0: i2c-bus@0 {
- reg = <0>; /* OM01 */
- };
-
- cfam2_i2c1: i2c-bus@1 {
- reg = <1>; /* OM23 */
- };
-
- cfam2_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam2_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam2_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam2_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam2_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam2_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam2_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam2_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam2_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam2_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ2: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub2: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@3,0 { /* DCM1_C1 */
- reg = <3 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <3>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam3_i2c2: i2c-bus@2 {
- reg = <2>; /* OM45 */
- };
-
- cfam3_i2c3: i2c-bus@3 {
- reg = <3>; /* OM67 */
- };
-
- cfam3_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam3_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam3_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam3_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam3_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam3_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam3_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam3_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam3_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam3_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ3: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub3: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@4,0 { /* DCM2_C0 */
- reg = <4 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <4>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam4_i2c0: i2c-bus@0 {
- reg = <0>; /* OM01 */
- };
-
- cfam4_i2c1: i2c-bus@1 {
- reg = <1>; /* OM23 */
- };
-
- cfam4_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam4_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam4_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam4_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam4_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam4_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam4_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam4_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam4_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam4_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ4: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub4: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@5,0 { /* DCM2_C1 */
- reg = <5 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <5>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam5_i2c2: i2c-bus@2 {
- reg = <2>; /* OM45 */
- };
-
- cfam5_i2c3: i2c-bus@3 {
- reg = <3>; /* OM67 */
- };
-
- cfam5_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam5_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam5_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam5_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam5_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam5_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam5_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam5_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam5_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam5_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ5: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub5: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@6,0 { /* DCM3_C0 */
- reg = <6 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <6>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam6_i2c0: i2c-bus@0 {
- reg = <0>; /* OM01 */
- };
-
- cfam6_i2c1: i2c-bus@1 {
- reg = <1>; /* OM23 */
- };
-
- cfam6_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam6_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam6_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam6_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam6_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam6_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam6_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam6_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam6_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam6_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ6: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub6: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@7,0 { /* DCM3_C1 */
- reg = <7 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <7>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam7_i2c2: i2c-bus@2 {
- reg = <2>; /* OM45 */
- };
-
- cfam7_i2c3: i2c-bus@3 {
- reg = <3>; /* OM67 */
- };
-
- cfam7_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam7_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam7_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam7_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam7_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam7_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam7_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam7_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam7_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam7_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ7: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub7: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-};
-
-/* Legacy OCC numbering (to get rid of when userspace is fixed) */
-&fsi_occ0 {
- reg = <1>;
-};
-
-&fsi_occ1 {
- reg = <2>;
-};
-
-&fsi_occ2 {
- reg = <3>;
-};
-
-&fsi_occ3 {
- reg = <4>;
-};
-
-&fsi_occ4 {
- reg = <5>;
-};
-
-&fsi_occ5 {
- reg = <6>;
-};
-
-&fsi_occ6 {
- reg = <7>;
-};
-
-&fsi_occ7 {
- reg = <8>;
-};
-
&ibt {
status = "okay";
};
@@ -3721,3 +2501,1516 @@ &kcs3 {
aspeed,lpc-io-reg = <0xca2>;
aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
};
+
+#include "ibm-power10-quad.dtsi"
+
+&fsi_hub0 {
+ cfam@4,0 { /* DCM2_C0 */
+ reg = <4 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <4>;
+
+ scom@1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+ };
+
+ i2c@1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam4_i2c0: i2c-bus@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>; /* OM01 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom500: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo500: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c1: i2c-bus@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>; /* OM23 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom501: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo501: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c10: i2c-bus@a {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <10>; /* OP3A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom510: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo510: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c11: i2c-bus@b {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <11>; /* OP3B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom511: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo511: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c12: i2c-bus@c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <12>; /* OP4A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom512: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo512: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c13: i2c-bus@d {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <13>; /* OP4B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom513: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo513: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c14: i2c-bus@e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <14>; /* OP5A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom514: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo514: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam4_i2c15: i2c-bus@f {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <15>; /* OP5B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom515: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo515: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+ };
+
+ fsi2spi@1c00 {
+ compatible = "ibm,fsi2spi";
+ reg = <0x1c00 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam4_spi0: spi@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam4_spi1: spi@20 {
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam4_spi2: spi@40 {
+ reg = <0x40>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam4_spi3: spi@60 {
+ reg = <0x60>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+ };
+
+ sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fsi_occ4: occ {
+ compatible = "ibm,p10-occ";
+
+ occ-hwmon {
+ compatible = "ibm,p10-occ-hwmon";
+ ibm,no-poll-on-init;
+ };
+ };
+ };
+
+ fsi_hub4: hub@3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+ };
+ };
+
+ cfam@5,0 { /* DCM2_C1 */
+ reg = <5 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <5>;
+
+ scom@1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+ };
+
+ i2c@1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam5_i2c2: i2c-bus@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>; /* OM45 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom602: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo602: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c3: i2c-bus@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>; /* OM67 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom603: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo603: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c10: i2c-bus@a {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <10>; /* OP3A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom610: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo610: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c11: i2c-bus@b {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <11>; /* OP3B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom611: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo611: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c14: i2c-bus@e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <14>; /* OP5A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom614: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo614: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c15: i2c-bus@f {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <15>; /* OP5B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom615: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo615: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c16: i2c-bus@10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <16>; /* OP6A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom616: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo616: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam5_i2c17: i2c-bus@11 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <17>; /* OP6B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom617: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo617: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+ };
+
+ fsi2spi@1c00 {
+ compatible = "ibm,fsi2spi";
+ reg = <0x1c00 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam5_spi0: spi@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam5_spi1: spi@20 {
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam5_spi2: spi@40 {
+ reg = <0x40>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam5_spi3: spi@60 {
+ reg = <0x60>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+ };
+
+ sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fsi_occ5: occ {
+ compatible = "ibm,p10-occ";
+
+ occ-hwmon {
+ compatible = "ibm,p10-occ-hwmon";
+ ibm,no-poll-on-init;
+ };
+ };
+ };
+
+ fsi_hub5: hub@3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+ };
+ };
+
+ cfam@6,0 { /* DCM3_C0 */
+ reg = <6 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <6>;
+
+ scom@1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+ };
+
+ i2c@1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam6_i2c0: i2c-bus@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>; /* OM01 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom700: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo700: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c1: i2c-bus@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>; /* OM23 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom701: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo701: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c10: i2c-bus@a {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <10>; /* OP3A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom710: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo710: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c11: i2c-bus@b {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <11>; /* OP3B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom711: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo711: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c12: i2c-bus@c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <12>; /* OP4A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom712: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo712: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c13: i2c-bus@d {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <13>; /* OP4B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom713: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo713: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c14: i2c-bus@e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <14>; /* OP5A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom714: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo714: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam6_i2c15: i2c-bus@f {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <15>; /* OP5B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom715: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo715: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+ };
+
+ fsi2spi@1c00 {
+ compatible = "ibm,fsi2spi";
+ reg = <0x1c00 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam6_spi0: spi@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam6_spi1: spi@20 {
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam6_spi2: spi@40 {
+ reg = <0x40>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam6_spi3: spi@60 {
+ reg = <0x60>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+ };
+
+ sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fsi_occ6: occ {
+ compatible = "ibm,p10-occ";
+
+ occ-hwmon {
+ compatible = "ibm,p10-occ-hwmon";
+ ibm,no-poll-on-init;
+ };
+ };
+ };
+
+ fsi_hub6: hub@3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+ };
+ };
+
+ cfam@7,0 { /* DCM3_C1 */
+ reg = <7 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <7>;
+
+ scom@1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+ };
+
+ i2c@1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam7_i2c2: i2c-bus@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>; /* OM45 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom802: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo802: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c3: i2c-bus@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>; /* OM67 */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom803: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo803: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c10: i2c-bus@a {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <10>; /* OP3A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom810: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo810: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c11: i2c-bus@b {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <11>; /* OP3B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom811: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo811: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c14: i2c-bus@e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <14>; /* OP5A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom814: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo814: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c15: i2c-bus@f {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <15>; /* OP5B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom815: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo815: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c16: i2c-bus@10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <16>; /* OP6A */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom816: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo816: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+
+ cfam7_i2c17: i2c-bus@11 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <17>; /* OP6B */
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+
+ scom817: scom@1000 {
+ compatible = "ibm,i2cr-scom";
+ reg = <0x1000 0x400>;
+ };
+
+ sbefifo817: sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
+ };
+
+ fsi2spi@1c00 {
+ compatible = "ibm,fsi2spi";
+ reg = <0x1c00 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cfam7_spi0: spi@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam7_spi1: spi@20 {
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam7_spi2: spi@40 {
+ reg = <0x40>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+
+ cfam7_spi3: spi@60 {
+ reg = <0x60>;
+ compatible = "ibm,fsi2spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ at25,byte-len = <0x80000>;
+ at25,addr-mode = <4>;
+ at25,page-size = <256>;
+
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+ };
+
+ sbefifo@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fsi_occ7: occ {
+ compatible = "ibm,p10-occ";
+
+ occ-hwmon {
+ compatible = "ibm,p10-occ-hwmon";
+ ibm,no-poll-on-init;
+ };
+ };
+ };
+
+ fsi_hub7: hub@3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+ };
+ };
+};
+
+/* Legacy OCC numbering (to get rid of when userspace is fixed) */
+&fsi_occ4 {
+ reg = <5>;
+};
+
+&fsi_occ5 {
+ reg = <6>;
+};
+
+&fsi_occ6 {
+ reg = <7>;
+};
+
+&fsi_occ7 {
+ reg = <8>;
+};
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-rainier.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-rainier.dts
index 7162e65..5cb0094 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-rainier.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-rainier.dts
@@ -12,39 +12,6 @@ / {
compatible = "ibm,rainier-bmc", "aspeed,ast2600";
aliases {
- i2c100 = &cfam0_i2c0;
- i2c101 = &cfam0_i2c1;
- i2c110 = &cfam0_i2c10;
- i2c111 = &cfam0_i2c11;
- i2c112 = &cfam0_i2c12;
- i2c113 = &cfam0_i2c13;
- i2c114 = &cfam0_i2c14;
- i2c115 = &cfam0_i2c15;
- i2c202 = &cfam1_i2c2;
- i2c203 = &cfam1_i2c3;
- i2c210 = &cfam1_i2c10;
- i2c211 = &cfam1_i2c11;
- i2c214 = &cfam1_i2c14;
- i2c215 = &cfam1_i2c15;
- i2c216 = &cfam1_i2c16;
- i2c217 = &cfam1_i2c17;
- i2c300 = &cfam2_i2c0;
- i2c301 = &cfam2_i2c1;
- i2c310 = &cfam2_i2c10;
- i2c311 = &cfam2_i2c11;
- i2c312 = &cfam2_i2c12;
- i2c313 = &cfam2_i2c13;
- i2c314 = &cfam2_i2c14;
- i2c315 = &cfam2_i2c15;
- i2c402 = &cfam3_i2c2;
- i2c403 = &cfam3_i2c3;
- i2c410 = &cfam3_i2c10;
- i2c411 = &cfam3_i2c11;
- i2c414 = &cfam3_i2c14;
- i2c415 = &cfam3_i2c15;
- i2c416 = &cfam3_i2c16;
- i2c417 = &cfam3_i2c17;
-
serial4 = &uart5;
i2c16 = &i2c2mux0;
i2c17 = &i2c2mux1;
@@ -61,23 +28,6 @@ aliases {
i2c28 = &i2c6mux0chn3;
i2c29 = &i2c11mux0chn0;
i2c30 = &i2c11mux0chn1;
-
- spi10 = &cfam0_spi0;
- spi11 = &cfam0_spi1;
- spi12 = &cfam0_spi2;
- spi13 = &cfam0_spi3;
- spi20 = &cfam1_spi0;
- spi21 = &cfam1_spi1;
- spi22 = &cfam1_spi2;
- spi23 = &cfam1_spi3;
- spi30 = &cfam2_spi0;
- spi31 = &cfam2_spi1;
- spi32 = &cfam2_spi2;
- spi33 = &cfam2_spi3;
- spi40 = &cfam3_spi0;
- spi41 = &cfam3_spi1;
- spi42 = &cfam3_spi2;
- spi43 = &cfam3_spi3;
};
chosen {
@@ -301,632 +251,6 @@ &emmc {
clk-phase-mmc-hs200 = <180>, <180>;
};
-&fsim0 {
- status = "okay";
-
- #address-cells = <2>;
- #size-cells = <0>;
-
- /*
- * CFAM Reset is supposed to be active low but pass1 hardware is wired
- * active high.
- */
- cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_HIGH>;
-
- cfam@0,0 {
- reg = <0 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <0>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam0_i2c0: i2c-bus@0 {
- reg = <0>; /* OMI01 */
- };
-
- cfam0_i2c1: i2c-bus@1 {
- reg = <1>; /* OMI23 */
- };
-
- cfam0_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam0_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam0_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam0_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam0_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam0_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam0_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam0_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ0: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub0: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
- };
- };
-};
-
-&fsi_hub0 {
- cfam@1,0 {
- reg = <1 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <1>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam1_i2c2: i2c-bus@2 {
- reg = <2>; /* OMI45 */
- };
-
- cfam1_i2c3: i2c-bus@3 {
- reg = <3>; /* OMI67 */
- };
-
- cfam1_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam1_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam1_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam1_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam1_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam1_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam1_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam1_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ1: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub1: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@2,0 {
- reg = <2 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <2>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam2_i2c0: i2c-bus@0 {
- reg = <0>; /* OM01 */
- };
-
- cfam2_i2c1: i2c-bus@1 {
- reg = <1>; /* OM23 */
- };
-
- cfam2_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam2_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam2_i2c12: i2c-bus@c {
- reg = <12>; /* OP4A */
- };
-
- cfam2_i2c13: i2c-bus@d {
- reg = <13>; /* OP4B */
- };
-
- cfam2_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam2_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam2_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam2_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam2_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam2_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ2: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub2: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-
- cfam@3,0 {
- reg = <3 0>;
- #address-cells = <1>;
- #size-cells = <1>;
- chip-id = <3>;
-
- scom@1000 {
- compatible = "ibm,fsi2pib";
- reg = <0x1000 0x400>;
- };
-
- i2c@1800 {
- compatible = "ibm,fsi-i2c-master";
- reg = <0x1800 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam3_i2c2: i2c-bus@2 {
- reg = <2>; /* OM45 */
- };
-
- cfam3_i2c3: i2c-bus@3 {
- reg = <3>; /* OM67 */
- };
-
- cfam3_i2c10: i2c-bus@a {
- reg = <10>; /* OP3A */
- };
-
- cfam3_i2c11: i2c-bus@b {
- reg = <11>; /* OP3B */
- };
-
- cfam3_i2c14: i2c-bus@e {
- reg = <14>; /* OP5A */
- };
-
- cfam3_i2c15: i2c-bus@f {
- reg = <15>; /* OP5B */
- };
-
- cfam3_i2c16: i2c-bus@10 {
- reg = <16>; /* OP6A */
- };
-
- cfam3_i2c17: i2c-bus@11 {
- reg = <17>; /* OP6B */
- };
- };
-
- fsi2spi@1c00 {
- compatible = "ibm,fsi2spi";
- reg = <0x1c00 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cfam3_spi0: spi@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam3_spi1: spi@20 {
- reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam3_spi2: spi@40 {
- reg = <0x40>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
-
- cfam3_spi3: spi@60 {
- reg = <0x60>;
- compatible = "ibm,fsi2spi-restricted";
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@0 {
- at25,byte-len = <0x80000>;
- at25,addr-mode = <4>;
- at25,page-size = <256>;
-
- compatible = "atmel,at25";
- reg = <0>;
- spi-max-frequency = <1000000>;
- };
- };
- };
-
- sbefifo@2400 {
- compatible = "ibm,p9-sbefifo";
- reg = <0x2400 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- fsi_occ3: occ {
- compatible = "ibm,p10-occ";
-
- occ-hwmon {
- compatible = "ibm,p10-occ-hwmon";
- ibm,no-poll-on-init;
- };
- };
- };
-
- fsi_hub3: hub@3400 {
- compatible = "fsi-master-hub";
- reg = <0x3400 0x400>;
- #address-cells = <2>;
- #size-cells = <0>;
-
- no-scan-on-init;
- };
- };
-};
-
-/* Legacy OCC numbering (to get rid of when userspace is fixed) */
-&fsi_occ0 {
- reg = <1>;
-};
-
-&fsi_occ1 {
- reg = <2>;
-};
-
-&fsi_occ2 {
- reg = <3>;
-};
-
-&fsi_occ3 {
- reg = <4>;
-};
-
&ibt {
status = "okay";
};
@@ -1017,7 +341,7 @@ tmp275@4a {
reg = <0x4a>;
};
- pca9546@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -1099,7 +423,7 @@ tmp275@49 {
reg = <0x49>;
};
- pca9546@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -1201,7 +525,7 @@ tmp275@4b {
reg = <0x4b>;
};
- pca9546@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -2031,7 +1355,7 @@ tmp275@49 {
reg = <0x49>;
};
- pca9546@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -2092,11 +1416,6 @@ eeprom@51 {
&i2c12 {
status = "okay";
- tpm@2e {
- compatible = "nuvoton,npct75x";
- reg = <0x2e>;
- };
-
eeprom@50 {
compatible = "atmel,24c64";
reg = <0x50>;
@@ -2418,3 +1737,5 @@ &kcs3 {
aspeed,lpc-io-reg = <0xca2>;
aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
};
+
+#include "ibm-power10-quad.dtsi"
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-fp5280g2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-fp5280g2.dts
index 208b0f0..0dea014e 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-fp5280g2.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-fp5280g2.dts
@@ -348,7 +348,7 @@ tmp112@49 {
label = "outlet";
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -432,7 +432,7 @@ &i2c6 {
&i2c7 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-nf5280m6.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-nf5280m6.dts
index b3c1e3b..92b9b39 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-nf5280m6.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-inspur-nf5280m6.dts
@@ -215,7 +215,7 @@ tmp112@49 {
label = "outlet";
};
- pca9548@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
};
@@ -224,17 +224,17 @@ pca9548@70 {
&i2c3 {
status = "okay";
- pca9548@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
};
- pca9548@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
};
- pca9548@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9548";
reg = <0x72>;
};
@@ -248,7 +248,7 @@ &i2c4 {
&i2c5 {
status = "okay";
- pca9548@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
};
@@ -257,7 +257,7 @@ pca9548@70 {
&i2c6 {
status = "okay";
- pca9548@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
};
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-starscream.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-starscream.dts
new file mode 100644
index 0000000..ec82af9
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-starscream.dts
@@ -0,0 +1,389 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2023 Inventec Corp.
+
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include "aspeed-g6-pinctrl.dtsi"
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/gpio/aspeed-gpio.h>
+
+/ {
+ model = "STARSCREAM BMC";
+ compatible = "inventec,starscream-bmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ };
+
+ chosen {
+ stdout-path = &uart5;
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ video_engine_memory: video {
+ size = <0x04000000>;
+ alignment = <0x01000000>;
+ compatible = "shared-dma-pool";
+ reusable;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-uid {
+ label = "UID_LED";
+ gpios = <&gpio0 186 GPIO_ACTIVE_LOW>;
+ };
+
+ led-heartbeat {
+ label = "HB_LED";
+ gpios = <&gpio0 127 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&mdio0 {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
+&mac2 {
+ status = "okay";
+ pinctrl-names = "default";
+ phy-mode = "rmii";
+ pinctrl-0 = <&pinctrl_rmii3_default>;
+ use-ncsi;
+};
+
+&mac3 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii4_default>;
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-max-frequency = <50000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+#include "openbmc-flash-layout.dtsi"
+ };
+
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc2";
+ spi-max-frequency = <50000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi1_default>;
+
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bios";
+ spi-max-frequency = <50000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+};
+
+&vuart1 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&kcs3 {
+ aspeed,lpc-io-reg = <0xca2>;
+ status = "okay";
+};
+
+&uart_routing {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+&i2c1 {
+ status = "okay";
+};
+&i2c2 {
+ status = "okay";
+};
+&i2c3 {
+ status = "okay";
+};
+
+&i2c4 {
+ status = "okay";
+
+ // I2C EXPANDER
+ i2c-mux@71 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x71>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ // AMD SB-TSI CPU1
+ sbtsi@4c {
+ compatible = "amd,sbtsi";
+ reg = <0x4c>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ // AMD SB-TSI CPU2
+ sbtsi@48 {
+ compatible = "amd,sbtsi";
+ reg = <0x48>;
+ };
+ };
+ };
+};
+
+&i2c5 {
+ status = "okay";
+
+ // I2C EXPANDER U153
+ i2c-mux@70 {
+ compatible = "nxp,pca9546";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+
+ usb_hub: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ riser1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ riser2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&i2c6 {
+ status = "okay";
+
+ // Motherboard Temp_U89
+ temperature-sensor@4e {
+ compatible = "ti,tmp421";
+ reg = <0x4e>;
+ };
+
+ // RunBMC Temp_U6
+ temperature-sensor@49 {
+ compatible = "ti,tmp75";
+ reg = <0x49>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+ // I2C EXPANDER U40
+ i2c-mux@70 {
+ compatible = "nxp,pca9545";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&i2c8 {
+ status = "okay";
+ // FRU RunBMC
+ eeprom@51 {
+ compatible = "atmel,24c512";
+ reg = <0x51>;
+ pagesize = <128>;
+ };
+};
+
+&i2c9 {
+ status = "okay";
+};
+
+&i2c10 {
+ status = "okay";
+};
+
+&i2c11 {
+ status = "okay";
+};
+
+&i2c12 {
+ status = "okay";
+ // FRU SCM
+ eeprom@51 {
+ compatible = "atmel,24c512";
+ reg = <0x51>;
+ pagesize = <128>;
+ };
+
+ // SCM Temp_U17
+ temperature-sensor@4f {
+ compatible = "ti,tmp75";
+ reg = <0x4f>;
+ };
+};
+
+&gpio0 {
+ status = "okay";
+ gpio-line-names =
+ /*A0-A7*/ "","","","","","","","",
+ /*B0-B7*/ "alert-psu0-smb-r-n","bmc-ready","","assert-cpu0-prochot-r-n",
+ "","","","",
+ /*C0-C7*/ "","","","","","","","",
+ /*D0-D7*/ "","","","","","","","",
+ /*E0-E7*/ "","","","","","","","",
+ /*F0-F7*/ "","","","","reset-sgpio-r-n","","","",
+ /*G0-G7*/ "","","scm-jtag-mux-select","","","","","",
+ /*H0-H7*/ "","","","","reset-out","power-out","","",
+ /*I0-I7*/ "","","","","","","irq-bmc-cpu0-buf-nmi-n","",
+ /*J0-J7*/ "","","","","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "","","","","","","","",
+ /*M0-M7*/ "","","","","","","","",
+ /*N0-N7*/ "","","ncsi-ocp-clk-en-n","","","","","",
+ /*O0-O7*/ "","","","","","","cpu1-thermal-trip-n","",
+ /*P0-P7*/ "","","","","","","","",
+ /*Q0-Q7*/ "cpu0-prochot-n","","cpu1-prochot-n","","cpu0-pe-rst0","","","",
+ /*R0-R7*/ "","","","","","","","",
+ /*S0-S7*/ "","","","",
+ "","PCH_SLP_S4_BMC_N","cpu0-thermtrip-n","alert-psu1-smb-r-n",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "bios-recovery-buf-n","","assert-cpu1-prochot-r-n","",
+ "power-chassis-good","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","platform-type","","","",
+ /*Y0-Y7*/ "","","","","","","","",
+ /*Z0-Z7*/ "","cpld-power-break-n","","","","","","",
+ /*AA0-AA7*/ "","","","","","","","",
+ /*AB0-AB7*/ "","","","","","","","",
+ /*AC0-AC7*/ "","","","","","","","";
+};
+
+&sgpiom0 {
+ status = "okay";
+ ngpios = <64>;
+ bus-frequency = <1000000>;
+};
+
+&lpc_snoop {
+ status = "okay";
+ snoop-ports = <0x80>;
+};
+
+&emmc_controller {
+ status = "okay";
+};
+
+&emmc {
+ status = "okay";
+ non-removable;
+ max-frequency = <52000000>;
+ bus-width = <8>;
+};
+
+&video {
+ status = "okay";
+ memory-region = <&video_engine_memory>;
+};
+
+&vhub {
+ status = "okay";
+ aspeed,vhub-downstream-ports = <7>;
+ aspeed,vhub-generic-endpoints = <21>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb2ad_default>;
+};
+
+&rtc {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-transformers.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-transformers.dts
index caf6665..c713cb7 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-transformers.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-inventec-transformers.dts
@@ -193,14 +193,14 @@ &i2c10 {
// I2C EXPANDER
status = "okay";
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9544";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x71>;
};
- i2c-switch@73 {
+ i2c-mux@73 {
compatible = "nxp,pca9544";
#address-cells = <1>;
#size-cells = <0>;
@@ -212,7 +212,7 @@ &i2c11 {
// I2C EXPANDER
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9544";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr630.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr630.dts
index 8f543cc..ddbcbc6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr630.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr630.dts
@@ -208,7 +208,7 @@ &i2c6 {
* Slot 3
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9545";
reg = <0x70>;
#address-cells = <1>;
@@ -249,7 +249,7 @@ &i2c7 {
* Slot 2,
* Slot 3
*/
- i2c-switch@76 {
+ i2c-mux@76 {
compatible = "nxp,pca9546";
reg = <0x76>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr855xg2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr855xg2.dts
index bcc1820..6045b60b 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr855xg2.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-lenovo-hr855xg2.dts
@@ -175,7 +175,7 @@ &pinctrl_adc14_default
&i2c0 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9545";
reg = <0x70>;
#address-cells = <1>;
@@ -227,7 +227,7 @@ &i2c2 {
&i2c3 {
status = "okay";
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-opp-zaius.dts
index 0cb7b20..3d2d8db 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-opp-zaius.dts
@@ -231,7 +231,7 @@ ucd90160@64 {
&i2c1 {
status = "okay";
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
@@ -282,7 +282,7 @@ &i2c3 {
&i2c4 {
status = "okay";
- i2c-switch@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9546";
reg = <0x71>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-q71l.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-q71l.dts
index 9605e53..fed2791 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-q71l.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-q71l.dts
@@ -197,7 +197,7 @@ &i2c2 {
* Slot 6,
* Slot 7
*/
- i2c-switch@74 {
+ i2c-mux@74 {
compatible = "nxp,pca9546";
reg = <0x74>;
#address-cells = <1>;
@@ -238,7 +238,7 @@ i2c_pcie7: i2c@3 {
* SSD 1,
* SSD 2
*/
- i2c-switch@77 {
+ i2c-mux@77 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -325,7 +325,7 @@ &i2c7 {
* PSU3
* PSU2
*/
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-s6q.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-s6q.dts
index 46cbba6..983853e 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-s6q.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-quanta-s6q.dts
@@ -285,7 +285,7 @@ U35_PWR_ADC@4b {
reg = <0x4b>;
};
- i2c-switch@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9546";
reg = <0x70>;
#address-cells = <1>;
@@ -321,7 +321,7 @@ SMB_HOST_DB800_C_SCL: i2c@3 {
&i2c1 {
status = "okay";
- i2c-switch@59 {
+ i2c-mux@59 {
compatible = "nxp,pca9848";
reg = <0x59>;
#address-cells = <1>;
@@ -393,7 +393,7 @@ SMB_FB_SCL: i2c@7 {
#size-cells = <0>;
reg = <7>;
- i2c-switch@77 {
+ i2c-mux@77 {
compatible = "nxp,pca9546";
reg = <0x77>;
#address-cells = <1>;
@@ -490,7 +490,7 @@ &i2c5 {
&i2c6 {
status = "okay";
- i2c-switch@77 {
+ i2c-mux@77 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
@@ -556,7 +556,7 @@ U197_PCA9546_CH3: i2c@3 {
&i2c7 {
status = "okay";
- i2c-switch@75 {
+ i2c-mux@75 {
compatible = "nxp,pca9546";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-n110.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-n110.dts
index 2431926..44b9853 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-n110.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-n110.dts
@@ -88,16 +88,16 @@ gpio@27 {
&i2c13 {
/* SMB_PCIE2_STBY_LVC3 */
- mux-expa@73 {
- compatible = "nxp,pca9545";
- reg = <0x73>;
+ i2c-mux@71 {
+ compatible = "nxp,pca9543";
+ reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
i2c-mux-idle-disconnect;
};
- mux-sata@71 {
- compatible = "nxp,pca9543";
- reg = <0x71>;
+ i2c-mux@73 {
+ compatible = "nxp,pca9545";
+ reg = <0x73>;
#address-cells = <1>;
#size-cells = <0>;
i2c-mux-idle-disconnect;
@@ -106,7 +106,7 @@ mux-sata@71 {
&i2c2 {
/* SMB_PCIE_STBY_LVC3 */
- mux-expb@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9545";
reg = <0x71>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-rx20.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-rx20.dts
index ebbb68b..b8f0b08 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-rx20.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-rx20.dts
@@ -133,7 +133,7 @@ gpio@39 {
&i2c13 {
/* SMB_PCIE2_STBY_LVC3 */
- mux-expa@70 {
+ i2c-mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
#address-cells = <1>;
@@ -144,7 +144,7 @@ i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
- rsra-mux@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9548";
reg = <0x72>;
#address-cells = <1>;
@@ -165,7 +165,7 @@ at24@50 {
};
};
};
- mux-sata@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9543";
reg = <0x71>;
#address-cells = <1>;
@@ -176,7 +176,7 @@ mux-sata@71 {
&i2c2 {
/* SMB_PCIE_STBY_LVC3 */
- mux-expb@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
@@ -187,7 +187,7 @@ i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
- rsrb-mux@72 {
+ i2c-mux@72 {
compatible = "nxp,pca9548";
reg = <0x72>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-sx20.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-sx20.dts
index e36ee47..933ca83 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-sx20.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-vegman-sx20.dts
@@ -88,16 +88,16 @@ gpio@27 {
&i2c13 {
/* SMB_PCIE2_STBY_LVC3 */
- mux-expa@73 {
- compatible = "nxp,pca9545";
- reg = <0x73>;
+ i2c-mux@71 {
+ compatible = "nxp,pca9543";
+ reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
i2c-mux-idle-disconnect;
};
- mux-sata@71 {
- compatible = "nxp,pca9543";
- reg = <0x71>;
+ i2c-mux@73 {
+ compatible = "nxp,pca9545";
+ reg = <0x73>;
#address-cells = <1>;
#size-cells = <0>;
i2c-mux-idle-disconnect;
@@ -106,7 +106,7 @@ mux-sata@71 {
&i2c2 {
/* SMB_PCIE_STBY_LVC3 */
- mux-expb@71 {
+ i2c-mux@71 {
compatible = "nxp,pca9545";
reg = <0x71>;
#address-cells = <1>;
