iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'for-5.12/google' into for-linus

Browse Source 
- User experience improvements for hid-google from Nicolas Boichat
This commit is contained in:
Jiri Kosina 2021-02-23 11:33:13 +01:00
commit d6310078d9
4063 changed files with 139987 additions and 50184 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.mailmap
View File

@ -9,9 +9,6 @@
#
# Please keep this list dictionary sorted.
#
# This comment is parsed by git-shortlog:
# repo-abbrev: /pub/scm/linux/kernel/git/
#
Aaron Durbin <adurbin@google.com>
Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
@ -55,6 +52,8 @@ Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Björn Steinbrink <B.Steinbrink@gmx.de>
Björn Töpel <bjorn@kernel.org> <bjorn.topel@gmail.com>
Björn Töpel <bjorn@kernel.org> <bjorn.topel@intel.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>

24
CREDITS
View File

@ -710,6 +710,10 @@ S: Las Cuevas 2385 - Bo Guemes
S: Las Heras, Mendoza CP 5539
S: Argentina
N: Jay Cliburn
E: jcliburn@gmail.com
D: ATLX Ethernet drivers
N: Steven P. Cole
E: scole@lanl.gov
E: elenstev@mesatop.com
@ -1284,6 +1288,10 @@ D: Major kbuild rework during the 2.5 cycle
D: ISDN Maintainer
S: USA
N: Gerrit Renker
E: gerrit@erg.abdn.ac.uk
D: DCCP protocol support.
N: Philip Gladstone
E: philip@gladstonefamily.net
D: Kernel / timekeeping stuff
@ -2138,6 +2146,10 @@ E: seasons@falcon.sch.bme.hu
E: seasons@makosteszta.sote.hu
D: Original author of software suspend
N: Alexey Kuznetsov
E: kuznet@ms2.inr.ac.ru
D: Author and maintainer of large parts of the networking stack
N: Jaroslav Kysela
E: perex@perex.cz
W: https://www.perex.cz
@ -2696,6 +2708,10 @@ N: Wolfgang Muees
E: wolfgang@iksw-muees.de
D: Auerswald USB driver
N: Shrijeet Mukherjee
E: shrijeet@gmail.com
D: Network routing domains (VRF).
N: Paul Mundt
E: paul.mundt@gmail.com
D: SuperH maintainer
@ -4110,6 +4126,10 @@ S: B-1206 Jingmao Guojigongyu
S: 16 Baliqiao Nanjie, Beijing 101100
S: People's Repulic of China
N: Aviad Yehezkel
E: aviadye@nvidia.com
D: Kernel TLS implementation and offload support.
N: Victor Yodaiken
E: yodaiken@fsmlabs.com
D: RTLinux (RealTime Linux)
@ -4167,6 +4187,10 @@ S: 1507 145th Place SE #B5
S: Bellevue, Washington 98007
S: USA
N: Wensong Zhang
E: wensong@linux-vs.org
D: IP virtual server (IPVS).
N: Haojian Zhuang
E: haojian.zhuang@gmail.com
D: MMP support

21
Documentation/ABI/stable/sysfs-driver-dma-idxd
View File

@ -77,6 +77,13 @@ Contact: dmaengine@vger.kernel.org
Description: The operation capability bit mask specify the operation types
supported by the this device.
What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled
Date: Oct 27, 2020
KernelVersion: 5.11.0
Contact: dmaengine@vger.kernel.org
Description: To indicate if PASID (process address space identifier) is
enabled or not for this device.
What: /sys/bus/dsa/devices/dsa<m>/state
Date: Oct 25, 2019
KernelVersion: 5.6.0
@ -122,6 +129,13 @@ KernelVersion: 5.10.0
Contact: dmaengine@vger.kernel.org
Description: The last executed device administrative command's status/error.
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
Date: Oct 27, 2020
KernelVersion: 5.11.0
Contact: dmaengine@vger.kernel.org
Description: To indicate block on fault is allowed or not for the work queue
to support on demand paging.
What: /sys/bus/dsa/devices/wq<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
@ -190,6 +204,13 @@ Contact: dmaengine@vger.kernel.org
Description: The max batch size for this workqueue. Cannot exceed device
max batch size. Configurable parameter.
What: /sys/bus/dsa/devices/wq<m>.<n>/ats_disable
Date: Nov 13, 2020
KernelVersion: 5.11.0
Contact: dmaengine@vger.kernel.org
Description: Indicate whether ATS disable is turned on for the workqueue.
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0

4
Documentation/ABI/testing/sysfs-class-devlink
View File

@ -5,8 +5,8 @@ Description:
Provide a place in sysfs for the device link objects in the
kernel at any given time. The name of a device link directory,
denoted as ... above, is of the form <supplier>--<consumer>
where <supplier> is the supplier device name and <consumer> is
the consumer device name.
where <supplier> is the supplier bus:device name and <consumer>
is the consumer bus:device name.
What: /sys/class/devlink/.../auto_remove_on
Date: May 2020

5
Documentation/ABI/testing/sysfs-devices-consumer
View File

@ -4,5 +4,6 @@ Contact: Saravana Kannan <saravanak@google.com>
Description:
The /sys/devices/.../consumer:<consumer> are symlinks to device
links where this device is the supplier. <consumer> denotes the
name of the consumer in that device link. There can be zero or
more of these symlinks for a given device.
name of the consumer in that device link and is of the form
bus:device name. There can be zero or more of these symlinks
for a given device.

5
Documentation/ABI/testing/sysfs-devices-supplier
View File

@ -4,5 +4,6 @@ Contact: Saravana Kannan <saravanak@google.com>
Description:
The /sys/devices/.../supplier:<supplier> are symlinks to device
links where this device is the consumer. <supplier> denotes the
name of the supplier in that device link. There can be zero or
more of these symlinks for a given device.
name of the supplier in that device link and is of the form
bus:device name. There can be zero or more of these symlinks
for a given device.

3
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -264,7 +264,8 @@ Description: Discover CPUs in the same CPU frequency coordination domain
attribute is useful for user space DVFS controllers to get better
power/performance results for platforms using acpi-cpufreq.
This file is only present if the acpi-cpufreq driver is in use.
This file is only present if the acpi-cpufreq or the cppc-cpufreq
drivers are in use.
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}

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

@ -916,21 +916,25 @@ Date: September 2014
Contact: Subhash Jadavani <subhashj@codeaurora.org>
Description: This entry could be used to set or show the UFS device
runtime power management level. The current driver
implementation supports 6 levels with next target states:
implementation supports 7 levels with next target states:
== ====================================================
0 an UFS device will stay active, an UIC link will
0 UFS device will stay active, UIC link will
stay active
1 an UFS device will stay active, an UIC link will
1 UFS device will stay active, UIC link will
hibernate
2 an UFS device will moved to sleep, an UIC link will
2 UFS device will be moved to sleep, UIC link will
stay active
3 an UFS device will moved to sleep, an UIC link will
3 UFS device will be moved to sleep, UIC link will
hibernate
4 an UFS device will be powered off, an UIC link will
4 UFS device will be powered off, UIC link will
hibernate
5 an UFS device will be powered off, an UIC link will
5 UFS device will be powered off, UIC link will
be powered off
6 UFS device will be moved to deep sleep, UIC link
will be powered off. Note, deep sleep might not be
supported in which case this value will not be
accepted
== ====================================================
What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state
@ -954,21 +958,25 @@ Date: September 2014
Contact: Subhash Jadavani <subhashj@codeaurora.org>
Description: This entry could be used to set or show the UFS device
system power management level. The current driver
implementation supports 6 levels with next target states:
implementation supports 7 levels with next target states:
== ====================================================
0 an UFS device will stay active, an UIC link will
0 UFS device will stay active, UIC link will
stay active
1 an UFS device will stay active, an UIC link will
1 UFS device will stay active, UIC link will
hibernate
2 an UFS device will moved to sleep, an UIC link will
2 UFS device will be moved to sleep, UIC link will
stay active
3 an UFS device will moved to sleep, an UIC link will
3 UFS device will be moved to sleep, UIC link will
hibernate
4 an UFS device will be powered off, an UIC link will
4 UFS device will be powered off, UIC link will
hibernate
5 an UFS device will be powered off, an UIC link will
5 UFS device will be powered off, UIC link will
be powered off
6 UFS device will be moved to deep sleep, UIC link
will be powered off. Note, deep sleep might not be
supported in which case this value will not be
accepted
== ====================================================
What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state

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

@ -370,3 +370,10 @@ Date: April 2020
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Give a way to change iostat_period time. 3secs by default.
The new iostat trace gives stats gap given the period.
What: /sys/fs/f2fs/<disk>/max_io_bytes
Date: December 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: This gives a control to limit the bio size in f2fs.
Default is zero, which will follow underlying block layer limit,
whereas, if it has a certain bytes value, f2fs won't submit a
bio larger than that size.

8
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
View File

@ -473,7 +473,7 @@ read-side critical sections that follow the idle period (the oval near
the bottom of the diagram above).
Plumbing this into the full grace-period execution is described
`below <#Forcing%20Quiescent%20States>`__.
`below <Forcing Quiescent States_>`__.
CPU-Hotplug Interface
^^^^^^^^^^^^^^^^^^^^^
@ -494,7 +494,7 @@ mask to detect CPUs having gone offline since the beginning of this
grace period.
Plumbing this into the full grace-period execution is described
`below <#Forcing%20Quiescent%20States>`__.
`below <Forcing Quiescent States_>`__.
Forcing Quiescent States
^^^^^^^^^^^^^^^^^^^^^^^^
@ -532,7 +532,7 @@ from other CPUs.
| RCU. But this diagram is complex enough as it is, so simplicity |
| overrode accuracy. You can think of it as poetic license, or you can |
| think of it as misdirection that is resolved in the |
| `stitched-together diagram <#Putting%20It%20All%20Together>`__. |
| `stitched-together diagram <Putting It All Together_>`__. |
+-----------------------------------------------------------------------+
Grace-Period Cleanup
@ -596,7 +596,7 @@ maintain ordering. For example, if the callback function wakes up a task
that runs on some other CPU, proper ordering must in place in both the
callback function and the task being awakened. To see why this is
important, consider the top half of the `grace-period
cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be
cleanup`_ diagram. The callback might be
running on a CPU corresponding to the leftmost leaf ``rcu_node``
structure, and awaken a task that is to run on a CPU corresponding to
the rightmost leaf ``rcu_node`` structure, and the grace-period kernel

20
Documentation/RCU/Design/Requirements/Requirements.rst
View File

@ -45,7 +45,7 @@ requirements:
#. `Other RCU Flavors`_
#. `Possible Future Changes`_
This is followed by a `summary <#Summary>`__, however, the answers to
This is followed by a summary_, however, the answers to
each quick quiz immediately follows the quiz. Select the big white space
with your mouse to see the answer.
@ -1096,7 +1096,7 @@ memory barriers.
| case, voluntary context switch) within an RCU read-side critical |
| section. However, sleeping locks may be used within userspace RCU |
| read-side critical sections, and also within Linux-kernel sleepable |
| RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In |
| RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In |
| addition, the -rt patchset turns spinlocks into a sleeping locks so |
| that the corresponding critical sections can be preempted, which also |
| means that these sleeplockified spinlocks (but not other sleeping |
@ -1186,7 +1186,7 @@ non-preemptible (``CONFIG_PREEMPT=n``) kernels, and thus `tiny
RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__
was born. Josh Triplett has since taken over the small-memory banner
with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__
project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional
project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional
for those kernels not needing it.
The remaining performance requirements are, for the most part,
@ -1457,8 +1457,8 @@ will vary as the value of ``HZ`` varies, and can also be changed using
the relevant Kconfig options and kernel boot parameters. RCU currently
does not do much sanity checking of these parameters, so please use
caution when changing them. Note that these forward-progress measures
are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
RCU <#Tasks%20RCU>`__.
are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
RCU`_.
RCU takes the following steps in ``call_rcu()`` to encourage timely
invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has
@ -1477,8 +1477,8 @@ encouragement was provided:
Again, these are default values when running at ``HZ=1000``, and can be
overridden. Again, these forward-progress measures are provided only for
RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward
RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
RCU`_. Even for RCU, callback-invocation forward
progress for ``rcu_nocbs`` CPUs is much less well-developed, in part
because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke
``call_rcu()`` relatively infrequently. If workloads emerge that need
@ -1920,7 +1920,7 @@ Hotplug CPU
The Linux kernel supports CPU hotplug, which means that CPUs can come
and go. It is of course illegal to use any RCU API member from an
offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side
offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side
critical sections. This requirement was present from day one in
DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug
implementation is “interesting.”
@ -2177,7 +2177,7 @@ handles these states differently:
However, RCU must be reliably informed as to whether any given CPU is
currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that
CPU is executing in usermode, as discussed
`earlier <#Energy%20Efficiency>`__. It also requires that the
`earlier <Energy Efficiency_>`__. It also requires that the
scheduling-clock interrupt be enabled when RCU needs it to be:
#. If a CPU is either idle or executing in usermode, and RCU believes it
@ -2294,7 +2294,7 @@ Performance, Scalability, Response Time, and Reliability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expanding on the `earlier
discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by
discussion <Performance and Scalability_>`__, RCU is used heavily by
hot code paths in performance-critical portions of the Linux kernel's
networking, security, virtualization, and scheduling code paths. RCU
must therefore use efficient implementations, especially in its

4
Documentation/admin-guide/binfmt-misc.rst
View File

@ -23,7 +23,7 @@ Here is what the fields mean:
- ``name``
is an identifier string. A new /proc file will be created with this
``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
obvious reasons.
- ``type``
is the type of recognition. Give ``M`` for magic and ``E`` for extension.
@ -83,7 +83,7 @@ Here is what the fields mean:
``F`` - fix binary
The usual behaviour of binfmt_misc is to spawn the
binary lazily when the misc format file is invoked. However,
this doesn``t work very well in the face of mount namespaces and
this doesn't work very well in the face of mount namespaces and
changeroots, so the ``F`` mode opens the binary as soon as the
emulation is installed and uses the opened image to spawn the
emulator, meaning it is always available once installed,

2
Documentation/admin-guide/bootconfig.rst
View File

@ -154,7 +154,7 @@ get the boot configuration data.
Because of this "piggyback" method, there is no need to change or
update the boot loader and the kernel image itself as long as the boot
loader passes the correct initrd file size. If by any chance, the boot
loader passes a longer size, the kernel feils to find the bootconfig data.
loader passes a longer size, the kernel fails to find the bootconfig data.
To do this operation, Linux kernel provides "bootconfig" command under
tools/bootconfig, which allows admin to apply or delete the config file

12
Documentation/admin-guide/device-mapper/dm-integrity.rst
View File

@ -177,14 +177,20 @@ bitmap_flush_interval:number
The bitmap flush interval in milliseconds. The metadata buffers
are synchronized when this interval expires.
allow_discards
Allow block discard requests (a.k.a. TRIM) for the integrity device.
Discards are only allowed to devices using internal hash.
fix_padding
Use a smaller padding of the tag area that is more
space-efficient. If this option is not present, large padding is
used - that is for compatibility with older kernels.
allow_discards
Allow block discard requests (a.k.a. TRIM) for the integrity device.
Discards are only allowed to devices using internal hash.
legacy_recalculate
Allow recalculating of volumes with HMAC keys. This is disabled by
default for security reasons - an attacker could modify the volume,
set recalc_sector to zero, and the kernel would not detect the
modification.
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and
allow_discards can be changed when reloading the target (load an inactive

7
Documentation/admin-guide/device-mapper/verity.rst
View File

@ -134,7 +134,12 @@ root_hash_sig_key_desc <key_description>
the pkcs7 signature of the roothash. The pkcs7 signature is used to validate
the root hash during the creation of the device mapper block device.
Verification of roothash depends on the config DM_VERITY_VERIFY_ROOTHASH_SIG
being set in the kernel.
being set in the kernel. The signatures are checked against the builtin
trusted keyring by default, or the secondary trusted keyring if
DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING is set. The secondary
trusted keyring includes by default the builtin trusted keyring, and it can
also gain new certificates at run time if they are signed by a certificate
already in the secondary trusted keyring.
Theory of operation
===================

4
Documentation/admin-guide/kernel-parameters.rst
View File

@ -3,8 +3,8 @@
The kernel's command-line parameters
====================================
The following is a consolidated list of the kernel parameters as
implemented by the __setup(), core_param() and module_param() macros
The following is a consolidated list of the kernel parameters as implemented
by the __setup(), early_param(), core_param() and module_param() macros
and sorted into English Dictionary order (defined as ignoring all
punctuation and sorting digits before letters in a case insensitive
manner), and with descriptions where known.

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

@ -1385,7 +1385,7 @@
ftrace_filter=[function-list]
[FTRACE] Limit the functions traced by the function
tracer at boot up. function-list is a comma separated
tracer at boot up. function-list is a comma-separated
list of functions. This list can be changed at run
time by the set_ftrace_filter file in the debugfs
tracing directory.
@ -1399,13 +1399,13 @@
ftrace_graph_filter=[function-list]
[FTRACE] Limit the top level callers functions traced
by the function graph tracer at boot up.
function-list is a comma separated list of functions
function-list is a comma-separated list of functions
that can be changed at run time by the
set_graph_function file in the debugfs tracing directory.
ftrace_graph_notrace=[function-list]
[FTRACE] Do not trace from the functions specified in
function-list. This list is a comma separated list of
function-list. This list is a comma-separated list of
functions that can be changed at run time by the
set_graph_notrace file in the debugfs tracing directory.
@ -2254,6 +2254,16 @@
for all guests.
Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
kvm-arm.mode=
[KVM,ARM] Select one of KVM/arm64's modes of operation.
protected: nVHE-based mode with support for guests whose
state is kept private from the host.
Not valid if the kernel is running in EL2.
Defaults to VHE/nVHE based on hardware support and
the value of CONFIG_ARM64_VHE.
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
system registers
@ -2411,7 +2421,7 @@
when set.
Format: <int>
libata.force= [LIBATA] Force configurations. The format is comma
libata.force= [LIBATA] Force configurations. The format is comma-
separated list of "[ID:]VAL" where ID is
PORT[.DEVICE]. PORT and DEVICE are decimal numbers
matching port, link or device. Basically, it matches
@ -2948,7 +2958,7 @@
mtdset= [ARM]
ARM/S3C2412 JIVE boot control
See arch/arm/mach-s3c2412/mach-jive.c
See arch/arm/mach-s3c/mach-jive.c
mtouchusb.raw_coordinates=
[HW] Make the MicroTouch USB driver use raw coordinates
@ -5135,7 +5145,7 @@
stacktrace_filter=[function-list]
[FTRACE] Limit the functions that the stack tracer
will trace at boot up. function-list is a comma separated
will trace at boot up. function-list is a comma-separated
list of functions. This list can be changed at run
time by the stack_trace_filter file in the debugfs
tracing directory. Note, this enables stack tracing
@ -5338,7 +5348,7 @@
trace_event=[event-list]
[FTRACE] Set and start specified trace events in order
to facilitate early boot debugging. The event-list is a
comma separated list of trace events to enable. See
comma-separated list of trace events to enable. See
also Documentation/trace/events.rst
trace_options=[option-list]
@ -5962,6 +5972,10 @@
This option is obsoleted by the "nopv" option, which
has equivalent effect for XEN platform.
xen_no_vector_callback
[KNL,X86,XEN] Disable the vector callback for Xen
event channel interrupts.
xen_scrub_pages= [XEN]
Boolean option to control scrubbing pages before giving them back
to Xen, for use by other domains. Can be also changed at runtime

2
Documentation/admin-guide/mm/concepts.rst
View File

@ -184,7 +184,7 @@ pages either asynchronously or synchronously, depending on the state
of the system. When the system is not loaded, most of the memory is free
and allocation requests will be satisfied immediately from the free
pages supply. As the load increases, the amount of the free pages goes
down and when it reaches a certain threshold (high watermark), an
down and when it reaches a certain threshold (low watermark), an
allocation request will awaken the ``kswapd`` daemon. It will
asynchronously scan memory pages and either just free them if the data
they contain is available elsewhere, or evict to the backing storage

81
Documentation/admin-guide/perf-security.rst
View File

@ -84,11 +84,14 @@ capabilities then providing the process with CAP_PERFMON capability singly
is recommended as the preferred secure approach to resolve double access
denial logging related to usage of performance monitoring and observability.
Unprivileged processes using perf_events system call are also subject
for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose
outcome determines whether monitoring is permitted. So unprivileged
processes provided with CAP_SYS_PTRACE capability are effectively
permitted to pass the check.
Prior Linux v5.9 unprivileged processes using perf_events system call
are also subject for PTRACE_MODE_READ_REALCREDS ptrace access mode check
[7]_ , whose outcome determines whether monitoring is permitted.
So unprivileged processes provided with CAP_SYS_PTRACE capability are
effectively permitted to pass the check. Starting from Linux v5.9
CAP_SYS_PTRACE capability is not required and CAP_PERFMON is enough to
be provided for processes to make performance monitoring and observability
operations.
Other capabilities being granted to unprivileged processes can
effectively enable capturing of additional data required for later
@ -99,11 +102,11 @@ CAP_SYSLOG capability permits reading kernel space memory addresses from
Privileged Perf users groups
---------------------------------
Mechanisms of capabilities, privileged capability-dumb files [6]_ and
file system ACLs [10]_ can be used to create dedicated groups of
privileged Perf users who are permitted to execute performance monitoring
and observability without scope limits. The following steps can be
taken to create such groups of privileged Perf users.
Mechanisms of capabilities, privileged capability-dumb files [6]_,
file system ACLs [10]_ and sudo [15]_ utility can be used to create
dedicated groups of privileged Perf users who are permitted to execute
performance monitoring and observability without limits. The following
steps can be taken to create such groups of privileged Perf users.
1. Create perf_users group of privileged Perf users, assign perf_users
group to Perf tool executable and limit access to the executable for
@ -133,7 +136,7 @@ taken to create such groups of privileged Perf users.
# getcap perf
perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep
If the libcap installed doesn't yet support "cap_perfmon", use "38" instead,
If the libcap [16]_ installed doesn't yet support "cap_perfmon", use "38" instead,
i.e.:
::
@ -159,6 +162,60 @@ performance monitoring and observability by using functionality of the
configured Perf tool executable that, when executes, passes perf_events
subsystem scope checks.
In case Perf tool executable can't be assigned required capabilities (e.g.
file system is mounted with nosuid option or extended attributes are
not supported by the file system) then creation of the capabilities
privileged environment, naturally shell, is possible. The shell provides
inherent processes with CAP_PERFMON and other required capabilities so that
performance monitoring and observability operations are available in the
environment without limits. Access to the environment can be open via sudo
utility for members of perf_users group only. In order to create such
environment:
1. Create shell script that uses capsh utility [16]_ to assign CAP_PERFMON
and other required capabilities into ambient capability set of the shell
process, lock the process security bits after enabling SECBIT_NO_SETUID_FIXUP,
SECBIT_NOROOT and SECBIT_NO_CAP_AMBIENT_RAISE bits and then change
the process identity to sudo caller of the script who should essentially
be a member of perf_users group:
::
# ls -alh /usr/local/bin/perf.shell
-rwxr-xr-x. 1 root root 83 Oct 13 23:57 /usr/local/bin/perf.shell
# cat /usr/local/bin/perf.shell
exec /usr/sbin/capsh --iab=^cap_perfmon --secbits=239 --user=$SUDO_USER -- -l
2. Extend sudo policy at /etc/sudoers file with a rule for perf_users group:
::
# grep perf_users /etc/sudoers
%perf_users ALL=/usr/local/bin/perf.shell
3. Check that members of perf_users group have access to the privileged
shell and have CAP_PERFMON and other required capabilities enabled
in permitted, effective and ambient capability sets of an inherent process:
::
$ id
uid=1003(capsh_test) gid=1004(capsh_test) groups=1004(capsh_test),1000(perf_users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ sudo perf.shell
[sudo] password for capsh_test:
$ grep Cap /proc/self/status
CapInh: 0000004000000000
CapPrm: 0000004000000000
CapEff: 0000004000000000
CapBnd: 000000ffffffffff
CapAmb: 0000004000000000
$ capsh --decode=0000004000000000
0x0000004000000000=cap_perfmon
As a result, members of perf_users group have access to the privileged
environment where they can use tools employing performance monitoring APIs
governed by CAP_PERFMON Linux capability.
This specific access control management is only available to superuser
or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_
capabilities.
@ -264,3 +321,5 @@ Bibliography
.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_
.. [13] `<https://sites.google.com/site/fullycapable>`_
.. [14] `<http://man7.org/linux/man-pages/man8/auditd.8.html>`_
.. [15] `<https://man7.org/linux/man-pages/man8/sudo.8.html>`_
.. [16] `<https://git.kernel.org/pub/scm/libs/libcap/libcap.git/>`_

2
Documentation/admin-guide/sysctl/vm.rst
View File

@ -428,7 +428,7 @@ While most applications need less than a thousand maps, certain
programs, particularly malloc debuggers, may consume lots of them,
e.g., up to one or two maps per allocation.
The default value is 65536.
The default value is 65530.
memory_failure_early_kill:

12
Documentation/arm/memory.rst
View File

@ -45,9 +45,14 @@ fffe8000 fffeffff DTCM mapping area for platforms with
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
ffc00000 ffefffff Fixmap mapping region. Addresses provided
ffc80000 ffefffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
ffc00000 ffc7ffff Guard region
ff800000 ffbfffff Permanent, fixed read-only mapping of the
firmware provided DT blob
fee00000 feffffff Mapping of PCI I/O space. This is a static
mapping within the vmalloc space.
@ -72,6 +77,11 @@ MODULES_VADDR MODULES_END-1 Kernel module space
Kernel modules inserted via insmod are
placed here using dynamic mappings.
TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use.
The range from MODULES_VADDR to the top
of the memory is shadowed here with 1 bit
per byte of memory.
00001000 TASK_SIZE-1 User space mappings
Per-thread mappings are placed here via
the mmap() system call.

4
Documentation/arm/samsung-s3c24xx/gpio.rst
View File

@ -29,7 +29,7 @@ GPIOLIB
The following functions now either have a `s3c_` specific variant
or are merged into gpiolib. See the definitions in
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
arch/arm/mach-s3c/gpio-cfg.h:
- s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
- s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
@ -86,7 +86,7 @@ between the calls.
Headers
-------
See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list
See arch/arm/mach-s3c/regs-gpio-s3c24xx.h for the list
of GPIO pins, and the configuration values for them. This
is included by using #include <mach/regs-gpio.h>

22
Documentation/arm/samsung-s3c24xx/overview.rst
View File

@ -18,7 +18,7 @@ Introduction
versions.
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
included under the arch/arm/mach-s3c2416 directory. Note, while core
included under the arch/arm/mach-s3c directory. Note, while core
support for these SoCs is in, work on some of the extra peripherals
and extra interrupts is still ongoing.
@ -37,19 +37,11 @@ Configuration
Layout
------
The core support files are located in the platform code contained in
arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx.
This directory should be kept to items shared between the platform
code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code.
The core support files, register, kernel and paltform data are located in the
platform code contained in arch/arm/mach-s3c with headers in
arch/arm/mach-s3c/include
Each cpu has a directory with the support files for it, and the
machines that carry the device. For example S3C2410 is contained
in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440
Register, kernel and platform data definitions are held in the
arch/arm/mach-s3c2410 directory./include/mach
arch/arm/plat-s3c24xx:
arch/arm/mach-s3c:
Files in here are either common to all the s3c24xx family,
or are common to only some of them with names to indicate this
@ -134,7 +126,7 @@ Adding New Machines
should keep this in mind before altering items outside of their own
machine files.
Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
Machine definitions should be kept in arch/arm/mach-s3c,
and there are a number of examples that can be looked at.
Read the kernel patch submission policies as well as the
@ -293,7 +285,7 @@ Platform Data
}
Note, since the code is marked as __init, it should not be
exported outside arch/arm/mach-s3c2410/, or exported to
exported outside arch/arm/mach-s3c/, or exported to
modules via EXPORT_SYMBOL() and related functions.

6
Documentation/arm/samsung-s3c24xx/usb-host.rst
View File

@ -36,7 +36,7 @@ Board Support
-------------
The driver attaches to a platform device, which will need to be
added by the board specific support file in linux/arch/arm/mach-s3c2410,
added by the board specific support file in arch/arm/mach-s3c,
such as mach-bast.c or mach-smdk2410.c
The platform device's platform_data field is only needed if the
@ -51,9 +51,9 @@ Board Support
Platform Data
-------------
See arch/arm/mach-s3c2410/include/mach/usb-control.h for the
See include/linux/platform_data/usb-ohci-s3c2410.h for the
descriptions of the platform device data. An implementation
can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c .
can be found in arch/arm/mach-s3c/simtec-usb.c .
The `struct s3c2410_hcd_info` contains a pair of functions
that get called to enable over-current detection, and to

3
Documentation/arm/samsung/gpio.rst
View File

@ -37,5 +37,4 @@ implementation to configure pins as necessary.
The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
driver or machine to change gpio configuration.
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
on these functions.
See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions.

2
Documentation/arm64/memory.rst
View File

@ -97,7 +97,7 @@ hypervisor maps kernel pages in EL2 at a fixed (and potentially
random) offset from the linear mapping. See the kern_hyp_va macro and
kvm_update_va_mask function for more details. MMIO devices such as
GICv2 gets mapped next to the HYP idmap page, as do vectors when
ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs.
ARM64_SPECTRE_V3A is enabled for particular CPUs.
When using KVM with the Virtualization Host Extensions, no additional
mappings are created, since the host kernel runs directly in EL2.

1
Documentation/core-api/index.rst
View File

@ -53,7 +53,6 @@ How Linux keeps everything from happening at the same time. See
.. toctree::
:maxdepth: 1
atomic_ops
refcount-vs-atomic
irq/index
local_ops

247
Documentation/dev-tools/kasan.rst
View File

@ -4,13 +4,16 @@ The Kernel Address Sanitizer (KASAN)
Overview
--------
KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to
find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN
(similar to userspace ASan) and software tag-based KASAN (similar to userspace
HWASan).
KernelAddressSANitizer (KASAN) is a dynamic memory safety error detector
designed to find out-of-bound and use-after-free bugs. KASAN has three modes:
KASAN uses compile-time instrumentation to insert validity checks before every
memory access, and therefore requires a compiler version that supports that.
1. generic KASAN (similar to userspace ASan),
2. software tag-based KASAN (similar to userspace HWASan),
3. hardware tag-based KASAN (based on hardware memory tagging).
Software KASAN modes (1 and 2) use compile-time instrumentation to insert
validity checks before every memory access, and therefore require a compiler
version that supports that.
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
8.3.0 or later. Any supported Clang version is compatible, but detection of
@ -18,8 +21,8 @@ out-of-bounds accesses for global variables is only supported since Clang 11.
Tag-based KASAN is only supported in Clang.
Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
riscv architectures, and tag-based KASAN is supported only for arm64.
Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390
and riscv architectures, and tag-based KASAN modes are supported only for arm64.
Usage
-----
@ -28,30 +31,22 @@ To enable KASAN configure kernel with::
CONFIG_KASAN = y
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and
CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN),
CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN), and
CONFIG_KASAN_HW_TAGS (to enable hardware tag-based KASAN).
You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE.
Outline and inline are compiler instrumentation types. The former produces
smaller binary while the latter is 1.1 - 2 times faster.
For software modes, you also need to choose between CONFIG_KASAN_OUTLINE and
CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types.
The former produces smaller binary while the latter is 1.1 - 2 times faster.
Both KASAN modes work with both SLUB and SLAB memory allocators.
For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
Both software KASAN modes work with both SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only support SLUB.
For better error reports that include stack traces, enable CONFIG_STACKTRACE.
To augment reports with last allocation and freeing stack of the physical page,
it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
To disable instrumentation for specific files or directories, add a line
similar to the following to the respective kernel Makefile:
- For a single file (e.g. main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
Error reports
~~~~~~~~~~~~~
@ -136,22 +131,60 @@ freed (in case of a use-after-free bug report). Next comes a description of
the accessed slab object and information about the accessed memory page.
In the last section the report shows memory state around the accessed address.
Reading this part requires some understanding of how KASAN works.
Internally KASAN tracks memory state separately for each memory granule, which
is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
memory state section of the report shows the state of one of the memory
granules that surround the accessed address.
The state of each 8 aligned bytes of memory is encoded in one shadow byte.
Those 8 bytes can be accessible, partially accessible, freed or be a redzone.
We use the following encoding for each shadow byte: 0 means that all 8 bytes
of the corresponding memory region are accessible; number N (1 <= N <= 7) means
that the first N bytes are accessible, and other (8 - N) bytes are not;
any negative value indicates that the entire 8-byte word is inaccessible.
We use different negative values to distinguish between different kinds of
inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h).
For generic KASAN the size of each memory granule is 8. The state of each
granule is encoded in one shadow byte. Those 8 bytes can be accessible,
partially accessible, freed or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 0 means that all 8 bytes of the corresponding
memory region are accessible; number N (1 <= N <= 7) means that the first N
bytes are accessible, and other (8 - N) bytes are not; any negative value
indicates that the entire 8-byte word is inaccessible. KASAN uses different
negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible.
For tag-based KASAN this last report section shows the memory tags around the
accessed address (see Implementation details section).
accessed address (see `Implementation details`_ section).
Boot parameters
~~~~~~~~~~~~~~~
Hardware tag-based KASAN mode (see the section about different mode below) is
intended for use in production as a security mitigation. Therefore it supports
boot parameters that allow to disable KASAN competely or otherwise control
particular KASAN features.
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
traces collection (default: ``on`` for ``CONFIG_DEBUG_KERNEL=y``, otherwise
``off``).
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``).
For developers
~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some part of the kernel, and
therefore needs to be disabled. To disable instrumentation for specific files
or directories, add a line similar to the following to the respective kernel
Makefile:
- For a single file (e.g. main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
Implementation details
@ -160,10 +193,10 @@ Implementation details
Generic KASAN
~~~~~~~~~~~~~
From a high level, our approach to memory error detection is similar to that
of kmemcheck: use shadow memory to record whether each byte of memory is safe
to access, and use compile-time instrumentation to insert checks of shadow
memory on each memory access.
From a high level perspective, KASAN's approach to memory error detection is
similar to that of kmemcheck: use shadow memory to record whether each byte of
memory is safe to access, and use compile-time instrumentation to insert checks
of shadow memory on each memory access.
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
@ -194,20 +227,30 @@ Generic KASAN also reports the last 2 call stacks to creation of work that
potentially has access to an object. Call stacks for the following are shown:
call_rcu() and workqueue queuing.
Generic KASAN is the only mode that delays the reuse of freed object via
quarantine (see mm/kasan/quarantine.c for implementation).
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to
store a pointer tag in the top byte of kernel pointers. Like generic KASAN it
uses shadow memory to store memory tags associated with each 16-byte memory
Software tag-based KASAN requires software memory tagging support in the form
of HWASan-like compiler instrumentation (see HWASan documentation for details).
Software tag-based KASAN is currently only implemented for arm64 architecture.
Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
to store a pointer tag in the top byte of kernel pointers. Like generic KASAN
it uses shadow memory to store memory tags associated with each 16-byte memory
cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation tag-based KASAN generates a random tag, tags the
allocated memory with this tag, and embeds this tag into the returned pointer.
On each memory allocation software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds this tag into the returned
pointer.
Software tag-based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that tag of the memory that
is being accessed is equal to tag of the pointer that is used to access this
memory. In case of a tag mismatch tag-based KASAN prints a bug report.
memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
Software tag-based KASAN also has two instrumentation modes (outline, that
emits callbacks to check memory accesses; and inline, that performs the shadow
@ -216,9 +259,36 @@ simply printed from the function that performs the access check. With inline
instrumentation a brk instruction is emitted by the compiler, and a dedicated
brk handler is used to print bug reports.
A potential expansion of this mode is a hardware tag-based mode, which would
use hardware memory tagging support instead of compiler instrumentation and
manual shadow memory manipulation.
Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
reserved to tag freed memory regions.
Software tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Hardware tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Hardware tag-based KASAN is similar to the software mode in concept, but uses
hardware memory tagging support instead of compiler instrumentation and
shadow memory.
Hardware tag-based KASAN is currently only implemented for arm64 architecture
and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
Instruction Set Architecture, and Top Byte Ignore (TBI).
Special arm64 instructions are used to assign memory tags for each allocation.
Same tags are assigned to pointers to those allocations. On every memory
access, hardware makes sure that tag of the memory that is being accessed is
equal to tag of the pointer that is used to access this memory. In case of a
tag mismatch a fault is generated and a report is printed.
Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
reserved to tag freed memory regions.
Hardware tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
What memory accesses are sanitised by KASAN?
--------------------------------------------
@ -265,17 +335,17 @@ Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mappings
use different shadow pages, mappings would have to be aligned to
``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``.
``KASAN_GRANULE_SIZE * PAGE_SIZE``.
Instead, we share backing space across multiple mappings. We allocate
Instead, KASAN shares backing space across multiple mappings. It allocates
a backing page when a mapping in vmalloc space uses a particular page
of the shadow region. This page can be shared by other vmalloc
mappings later on.
We hook in to the vmap infrastructure to lazily clean up unused shadow
KASAN hooks into the vmap infrastructure to lazily clean up unused shadow
memory.
To avoid the difficulties around swapping mappings around, we expect
To avoid the difficulties around swapping mappings around, KASAN expects
that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.
@ -286,24 +356,31 @@ architectures that do not have a fixed module region.
CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE
--------------------------------------------------
``CONFIG_KASAN_KUNIT_TEST`` utilizes the KUnit Test Framework for testing.
This means each test focuses on a small unit of functionality and
there are a few ways these tests can be run.
KASAN tests consist on two parts:
Each test will print the KASAN report if an error is detected and then
print the number of the test and the status of the test:
1. Tests that are integrated with the KUnit Test Framework. Enabled with
``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
automatically in a few different ways, see the instructions below.
pass::
2. Tests that are currently incompatible with KUnit. Enabled with
``CONFIG_TEST_KASAN_MODULE`` and can only be run as a module. These tests can
only be verified manually, by loading the kernel module and inspecting the
kernel log for KASAN reports.
Each KUnit-compatible KASAN test prints a KASAN report if an error is detected.
Then the test prints its number and status.
When a test passes::
ok 28 - kmalloc_double_kzfree
or, if kmalloc failed::
When a test fails due to a failed ``kmalloc``::
# kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163
Expected ptr is not null, but is
not ok 4 - kmalloc_large_oob_right
or, if a KASAN report was expected, but not found::
When a test fails due to a missing KASAN report::
# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
Expected kasan_data->report_expected == kasan_data->report_found, but
@ -311,46 +388,38 @@ or, if a KASAN report was expected, but not found::
kasan_data->report_found == 0
not ok 28 - kmalloc_double_kzfree
All test statuses are tracked as they run and an overall status will
be printed at the end::
At the end the cumulative status of all KASAN tests is printed. On success::
ok 1 - kasan
or::
Or, if one of the tests failed::
not ok 1 - kasan
(1) Loadable Module
~~~~~~~~~~~~~~~~~~~~
There are a few ways to run KUnit-compatible KASAN tests.
1. Loadable module
~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` enabled, ``CONFIG_KASAN_KUNIT_TEST`` can be built as
a loadable module and run on any architecture that supports KASAN
using something like insmod or modprobe. The module is called ``test_kasan``.
a loadable module and run on any architecture that supports KASAN by loading
the module with insmod or modprobe. The module is called ``test_kasan``.
(2) Built-In
~~~~~~~~~~~~~
2. Built-In
~~~~~~~~~~~
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
on any architecture that supports KASAN. These and any other KUnit
tests enabled will run and print the results at boot as a late-init
call.
on any architecure that supports KASAN. These and any other KUnit tests enabled
will run and print the results at boot as a late-init call.
(3) Using kunit_tool
~~~~~~~~~~~~~~~~~~~~~
3. Using kunit_tool
~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, we can also
use kunit_tool to see the results of these along with other KUnit
tests in a more readable way. This will not print the KASAN reports
of tests that passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_ for more up-to-date
information on kunit_tool.
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it's also
possible use ``kunit_tool`` to see the results of these and other KUnit tests
in a more readable way. This will not print the KASAN reports of the tests that
passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
``CONFIG_TEST_KASAN_MODULE`` is a set of KASAN tests that could not be
converted to KUnit. These tests can be run only as a module with
``CONFIG_TEST_KASAN_MODULE`` built as a loadable module and
``CONFIG_KASAN`` built-in. The type of error expected and the
function being run is printed before the expression expected to give
an error. Then the error is printed, if found, and that test
should be interpreted to pass only if the error was the one expected
by the test.

57
Documentation/dev-tools/kunit/usage.rst
View File

@ -522,6 +522,63 @@ There's more boilerplate involved, but it can:
* E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256``
field and reuse ``cases``.
* be converted to a "parameterized test", see below.
Parameterized Testing
~~~~~~~~~~~~~~~~~~~~~
The table-driven testing pattern is common enough that KUnit has special
support for it.
Reusing the same ``cases`` array from above, we can write the test as a
"parameterized test" with the following.
.. code-block:: c
// This is copy-pasted from above.
struct sha1_test_case {
const char *str;
const char *sha1;
};
struct sha1_test_case cases[] = {
{
.str = "hello world",
.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
},
{
.str = "hello world!",
.sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169",
},
};
// Need a helper function to generate a name for each test case.
static void case_to_desc(const struct sha1_test_case *t, char *desc)
{
strcpy(desc, t->str);
}
// Creates `sha1_gen_params()` to iterate over `cases`.
KUNIT_ARRAY_PARAM(sha1, cases, case_to_desc);
// Looks no different from a normal test.
static void sha1_test(struct kunit *test)
{
// This function can just contain the body of the for-loop.
// The former `cases[i]` is accessible under test->param_value.
char out[40];
struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value);
sha1sum(test_param->str, out);
KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1,
"sha1sum(%s)", test_param->str);
}
// Instead of KUNIT_CASE, we use KUNIT_CASE_PARAM and pass in the
// function declared by KUNIT_ARRAY_PARAM.
static struct kunit_case sha1_test_cases[] = {
KUNIT_CASE_PARAM(sha1_test, sha1_gen_params),
{}
};
.. _kunit-on-non-uml:
KUnit on non-UML architectures

38
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml Normal file
View File

@ -0,0 +1,38 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4908.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM4908 device tree bindings
description:
Broadcom BCM4906 / BCM4908 / BCM49408 Wi-Fi/network SoCs with Brahma CPUs.
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: BCM4906 based boards
items:
- const: brcm,bcm4906
- const: brcm,bcm4908
- description: BCM4908 based boards
items:
- enum:
- asus,gt-ac5300
- const: brcm,bcm4908
- description: BCM49408 based boards
items:
- const: brcm,bcm49408
- const: brcm,bcm4908
additionalProperties: true
...

12
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
View File

@ -89,7 +89,10 @@ Required properties:
"fsl,imx8qm-clock"
"fsl,imx8qxp-clock"
followed by "fsl,scu-clk"
- #clock-cells: Should be 1. Contains the Clock ID value.
- #clock-cells: Should be either
2: Contains the Resource and Clock ID value.
or
1: Contains the Clock ID value. (DEPRECATED)
- clocks: List of clock specifiers, must contain an entry for
each required entry in clock-names
- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
@ -208,7 +211,7 @@ firmware {
clk: clk {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
#clock-cells = <1>;
#clock-cells = <2>;
};
iomuxc {
@ -263,8 +266,7 @@ serial@5a060000 {
...
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpuart0>;
clocks = <&clk IMX8QXP_UART0_CLK>,
<&clk IMX8QXP_UART0_IPG_CLK>;
clock-names = "per", "ipg";
clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
clock-names = "ipg";
power-domains = <&pd IMX_SC_R_UART_0>;
};

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

@ -33,16 +33,57 @@ properties:
items:
- enum:
- fsl,imx25-pdk
- karo,imx25-tx25
- const: fsl,imx25
- description: i.MX27 Product Development Kit
- description: i.MX25 Eukrea CPUIMX25 Boards
items:
- enum:
- eukrea,mbimxsd25-baseboard # Eukrea MBIMXSD25
- const: eukrea,cpuimx25
- const: fsl,imx25
- description: i.MX25 Eukrea MBIMXSD25 Boards
items:
- enum:
- eukrea,mbimxsd25-baseboard-cmo-qvga
- eukrea,mbimxsd25-baseboard-dvi-svga
- eukrea,mbimxsd25-baseboard-dvi-vga
- const: eukrea,mbimxsd25-baseboard
- const: eukrea,cpuimx25
- const: fsl,imx25
- description: i.MX27 based Boards
items:
- enum:
- armadeus,imx27-apf27 # APF27 SoM
- armadeus,imx27-apf27dev # APF27 SoM on APF27Dev board
- fsl,imx27-pdk
- const: fsl,imx27
- description: i.MX27 APF27 SoM Board
items:
- const: armadeus,imx27-apf27dev
- const: armadeus,imx27-apf27
- const: fsl,imx27
- description: i.MX27 Eukrea CPUIMX27 SoM Board
items:
- const: eukrea,mbimxsd27-baseboard
- const: eukrea,cpuimx27
- const: fsl,imx27
- description: i.MX27 Phytec pca100 Board
items:
- const: phytec,imx27-pca100-rdk
- const: phytec,imx27-pca100
- const: fsl,imx27
- description: i.MX27 Phytec pcm970 Board
items:
- const: phytec,imx27-pcm970
- const: phytec,imx27-pcm038
- const: fsl,imx27
- description: i.MX28 based Boards
items:
- enum:
@ -88,13 +129,33 @@ properties:
- kobo,aura
- const: fsl,imx50
- description: i.MX51 Babbage Board
- description: i.MX51 based Boards
items:
- enum:
- armadeus,imx51-apf51 # APF51 SoM
- armadeus,imx51-apf51dev # APF51 SoM on APF51Dev board
- armadeus,imx51-apf51 # Armadeus Systems APF51 module
- fsl,imx51-babbage
- technologic,imx51-ts4800
- zii,imx51-scu3-esb
- zii,imx51-scu2-mezz
- zii,imx51-rdu1
- const: fsl,imx51
- description: i.MX51 based Armadeus Systems APF51Dev Board
items:
- const: armadeus,imx51-apf51dev
- const: armadeus,imx51-apf51
- const: fsl,imx51
- description: i.MX51 based Digi ConnectCore CC(W)-MX51 JSK Board
items:
- const: digi,connectcore-ccxmx51-jsk
- const: digi,connectcore-ccxmx51-som
- const: fsl,imx51
- description: i.MX51 based Eukrea CPUIMX51 Board
items:
- const: eukrea,mbimxsd51
- const: eukrea,cpuimx51
- const: fsl,imx51
- description: i.MX53 based Boards
@ -104,36 +165,111 @@ properties:
- fsl,imx53-ard
- fsl,imx53-evk
- fsl,imx53-qsb
- fsl,imx53-qsrb # Freescale i.MX53 Quick Start-R Board
- fsl,imx53-smd
- ge,imx53-cpuvo # General Electric CS ONE
- inversepath,imx53-usbarmory # Inverse Path USB armory
- karo,tx53 # Ka-Ro electronics TX53 module
- kiebackpeter,imx53-ddc # K+P imx53 DDC
- kiebackpeter,imx53-hsc # K+P imx53 HSC
- menlo,m53menlo
- voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668
- const: fsl,imx53
- description: i.MX53 based Aries/DENX M53EVK Board
items:
- const: aries,imx53-m53evk
- const: denx,imx53-m53evk
- const: fsl,imx53
- description: i.MX53 based TQ MBa53 Board
items:
- const: tq,mba53
- const: tq,tqma53
- const: fsl,imx53
- description: i.MX6Q based Boards
items:
- enum:
- armadeus,imx6q-apf6 # APF6 (Quad/Dual) SoM
- armadeus,imx6q-apf6dev # APF6 (Quad/Dual) SoM on APF6Dev board
- auvidea,h100 # Auvidea H100
- boundary,imx6q-nitrogen6_max
- boundary,imx6q-nitrogen6_som2
- boundary,imx6q-nitrogen6x
- compulab,cm-fx6 # CompuLab CM-FX6
- dmo,imx6q-edmqmx6 # Data Modul eDM-QMX6 Board
- embest,imx6q-marsboard # Embest MarS Board i.MX6Dual
- emtrion,emcon-mx6 # emCON-MX6D or emCON-MX6Q SoM
- emtrion,emcon-mx6-avari # emCON-MX6D or emCON-MX6Q SoM on Avari Base
- engicam,imx6-icore # Engicam i.CoreM6 Starter Kit
- engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit
- fsl,imx6q-arm2
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
- karo,imx6q-tx6q # Ka-Ro electronics TX6Q Modules
- kiebackpeter,imx6q-tpc # K+P i.MX6 Quad TPC Board
- kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module
- kosagi,imx6q-novena # Kosagi Novena Dual/Quad
- logicpd,imx6q-logicpd
- lwn,display5 # Liebherr Display5 i.MX6 Quad Board
- lwn,mccmon6 # Liebherr Monitor6 i.MX6 Quad Board
- nutsboard,imx6q-pistachio # NutsBoard i.MX6 Quad Pistachio
- microsys,sbc6x # MicroSys sbc6x board
- poslab,imx6q-savageboard # Poslab SavageBoard Quad
- prt,prti6q # Protonic PRTI6Q board
- prt,prtwd2 # Protonic WD2 board
- rex,imx6q-rex-pro # Rex Pro i.MX6 Quad Board
- solidrun,cubox-i/q # SolidRun Cubox-i Dual/Quad
- solidrun,hummingboard/q
- solidrun,hummingboard2/q
- tbs,imx6q-tbs2910 # TBS2910 Matrix ARM mini PC
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
- technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi
- technologic,imx6q-ts4900
- technologic,imx6q-ts7970
- toradex,apalis_imx6q # Apalis iMX6 Module
- toradex,apalis_imx6q-eval # Apalis iMX6 Module on Apalis Evaluation Board
- toradex,apalis_imx6q-ixora # Apalis iMX6 Module on Ixora
- toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6 Module on Ixora V1.1
- toradex,apalis_imx6q # Apalis iMX6 Module
- udoo,imx6q-udoo # Udoo i.MX6 Quad Board
- uniwest,imx6q-evi # Uniwest Evi
- variscite,dt6customboard
- wand,imx6q-wandboard # Wandboard i.MX6 Quad Board
- zealz,imx6q-gk802 # Zealz GK802
- zii,imx6q-zii-rdu2 # ZII RDU2 Board
- const: fsl,imx6q
- description: i.MX6Q Advantech DMS-BA16 Boards
items:
- enum:
- advantech,imx6q-dms-ba16 # Advantech DMS-BA16
- ge,imx6q-b450v3 # General Electric B450v3
- ge,imx6q-b650v3 # General Electric B650v3
- ge,imx6q-b850v3 # General Electric B850v3
- const: advantech,imx6q-ba16
- const: fsl,imx6q
- description: i.MX6Q Armadeus APF6 Boards
items:
- const: armadeus,imx6q-apf6dev
- const: armadeus,imx6q-apf6
- const: fsl,imx6q
- description: i.MX6Q CompuLab Utilite Pro Board
items:
- const: compulab,utilite-pro
- const: compulab,cm-fx6
- const: fsl,imx6q
- description: i.MX6Q DFI FS700-M60-6QD Board
items:
- const: dfi,fs700-m60-6qd
- const: dfi,fs700e-m60
- const: fsl,imx6q
- description: i.MX6Q DHCOM Premium Developer Kit Board
items:
- const: dh,imx6q-dhcom-pdk2
- const: dh,imx6q-dhcom-som
- const: fsl,imx6q
- description: i.MX6Q Gateworks Ventana Boards
@ -172,11 +308,32 @@ properties:
- const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
- const: fsl,imx6q
- description: i.MX6Q Boards with Toradex Apalis iMX6Q/D Module
items:
- enum:
- toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board
- toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board
- const: toradex,apalis_imx6q
- const: fsl,imx6q
- description: i.MX6Q Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1
items:
- const: toradex,apalis_imx6q-ixora-v1.1
- const: toradex,apalis_imx6q-ixora
- const: toradex,apalis_imx6q
- const: fsl,imx6q
- description: i.MX6QP based Boards
items:
- enum:
- boundary,imx6qp-nitrogen6_max
- boundary,imx6qp-nitrogen6_som2
- fsl,imx6qp-sabreauto # i.MX6 Quad Plus SABRE Automotive Board
- fsl,imx6qp-sabresd # i.MX6 Quad Plus SABRE Smart Device Board
- karo,imx6qp-tx6qp # Ka-Ro electronics TX6QP-8037 Module
- prt,prtwd3 # Protonic WD3 board
- wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board
- zii,imx6qp-zii-rdu2 # ZII RDU2+ Board
- const: fsl,imx6qp
- description: i.MX6QP PHYTEC phyBOARD-Mira
@ -189,32 +346,59 @@ properties:
- description: i.MX6DL based Boards
items:
- enum:
- armadeus,imx6dl-apf6 # APF6 (Solo) SoM
- armadeus,imx6dl-apf6dev # APF6 (Solo) SoM on APF6Dev board
- abb,aristainetos-imx6dl-4 # aristainetos i.MX6 Dual Lite Board 4
- abb,aristainetos-imx6dl-7 # aristainetos i.MX6 Dual Lite Board 7
- abb,aristainetos2-imx6dl-4 # aristainetos2 i.MX6 Dual Lite Board 4
- abb,aristainetos2-imx6dl-7 # aristainetos2 i.MX6 Dual Lite Board 7
- alt,alti6p # Altesco I6P Board
- boundary,imx6dl-nit6xlite # Boundary Devices Nitrogen6 Lite
- boundary,imx6dl-nitrogen6x # Boundary Devices Nitrogen6x
- bticino,imx6dl-mamoj # BTicino i.MX6DL Mamoj
- eckelmann,imx6dl-ci4x10
- emtrion,emcon-mx6 # emCON-MX6S or emCON-MX6DL SoM
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- engicam,imx6-icore # Engicam i.CoreM6 Starter Kit
- engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabrelite # i.MX6 DualLite SABRE Lite Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
- karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules
- kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module
- poslab,imx6dl-savageboard # Poslab SavageBoard Dual
- prt,prtrvt # Protonic RVT board
- prt,prtvt7 # Protonic VT7 board
- rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board
- riot,imx6s-riotboard # RIoTboard i.MX6S
- solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite
- solidrun,hummingboard/dl
- solidrun,hummingboard2/dl # SolidRun HummingBoard2 Solo/DualLite
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
- technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- toradex,colibri_imx6dl # Colibri iMX6 Module
- toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1
- toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3
- toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6 Module V1.1 on Colibri Evaluation Board V3
- udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board
- vdl,lanmcu # Van der Laan LANMCU board
- wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board
- ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board
- ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board
- ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board
- ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board
- const: fsl,imx6dl
- description: i.MX6DL based Armadeus AFP6 Board
items:
- const: armadeus,imx6dl-apf6dev
- const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM
- const: fsl,imx6dl
- description: i.MX6DL based DFI FS700-M60-6DL Board
items:
- const: dfi,fs700-m60-6dl
- const: dfi,fs700e-m60
- const: fsl,imx6dl
- description: i.MX6DL Gateworks Ventana Boards
items:
- enum:
@ -250,12 +434,29 @@ properties:
- const: phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
- const: fsl,imx6dl
- description: i.MX6DL Toradex Colibri iMX6 Module on Colibri
Evaluation Board V3
items:
- const: toradex,colibri_imx6dl-eval-v3
- const: toradex,colibri_imx6dl # Colibri iMX6 Module
- const: fsl,imx6dl
- description: i.MX6DL Toradex Colibri iMX6 Module V1.1 on Colibri
Evaluation Board V3
items:
- const: toradex,colibri_imx6dl-v1_1-eval-v3
- const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1
- const: toradex,colibri_imx6dl-eval-v3
- const: toradex,colibri_imx6dl # Colibri iMX6 Module
- const: fsl,imx6dl
- description: i.MX6SL based Boards
items:
- enum:
- fsl,imx6sl-evk # i.MX6 SoloLite EVK Board
- kobo,tolino-shine2hd
- kobo,tolino-shine3
- revotics,imx6sl-warp # Revotics WaRP Board
- const: fsl,imx6sl
- description: i.MX6SLL based Boards
@ -268,17 +469,23 @@ properties:
- description: i.MX6SX based Boards
items:
- enum:
- boundary,imx6sx-nitrogen6sx
- fsl,imx6sx-sabreauto # i.MX6 SoloX Sabre Auto Board
- fsl,imx6sx-sdb # i.MX6 SoloX SDB Board
- fsl,imx6sx-sdb-reva # i.MX6 SoloX SDB Rev-A Board
- samtec,imx6sx-vining-2000 # Softing VIN|ING 2000 Board
- udoo,neobasic # UDOO Neo Basic Board
- udoo,neoextended # UDOO Neo Extended
- udoo,neofull # UDOO Neo Full
- const: fsl,imx6sx
- description: i.MX6UL based Boards
items:
- enum:
- armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM
- armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board
- engicam,imx6ul-geam # Engicam GEAM6UL Starter Kit
- engicam,imx6ul-isiot # Engicam Is.IoT MX6UL eMMC/NAND Starter kit
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- karo,imx6ul-tx6ul # Ka-Ro electronics TXUL-0010 Module
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- kontron,imx6ul-n6311-som # Kontron N6311 SOM
- technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf
@ -286,6 +493,26 @@ properties:
- technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi
- const: fsl,imx6ul
- description: i.MX6UL Armadeus Systems OPOS6UL SoM Board
items:
- const: armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board
- const: armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM
- const: fsl,imx6ul
- description: i.MX6UL Digi International ConnectCore 6UL Boards
items:
- enum:
- digi,ccimx6ulsbcexpress # Digi International ConnectCore 6UL SBC Express
- digi,ccimx6ulsbcpro # Digi International ConnectCore 6UL SBC Pro
- const: digi,ccimx6ulsom
- const: fsl,imx6ul
- description: i.MX6UL Grinn liteBoard
items:
- const: grinn,imx6ul-liteboard
- const: grinn,imx6ul-litesom
- const: fsl,imx6ul
- description: i.MX6UL PHYTEC phyBOARD-Segin
items:
- enum:
@ -317,8 +544,6 @@ properties:
- description: i.MX6ULL based Boards
items:
- enum:
- armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
- armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
- kontron,imx6ull-n6411-som # Kontron N6411 SOM
- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board
@ -326,6 +551,12 @@ properties:
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board
- const: fsl,imx6ull
- description: i.MX6ULL Armadeus Systems OPOS6ULDev Board
items:
- const: armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
- const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
- const: fsl,imx6ull
- description: i.MX6ULL PHYTEC phyBOARD-Segin
items:
- enum:
@ -351,17 +582,32 @@ properties:
- description: i.MX7S based Boards
items:
- enum:
- toradex,colibri-imx7s # Colibri iMX7 Solo Module
- toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board
- toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3
- tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM
- element14,imx7s-warp # Element14 Warp i.MX7 Board
- const: fsl,imx7s
- description: i.MX7S Boards with Toradex Colibri iMX7S Module
items:
- enum:
- toradex,colibri-imx7s-aster # Module on Aster Carrier Board
- toradex,colibri-imx7s-eval-v3 # Module on Colibri Evaluation Board V3
- const: toradex,colibri-imx7s
- const: fsl,imx7s
- description: TQ-Systems TQMa7S SoM on MBa7x board
items:
- const: tq,imx7s-mba7
- const: tq,imx7s-tqma7
- const: fsl,imx7s
- description: i.MX7D based Boards
items:
- enum:
- boundary,imx7d-nitrogen7
- compulab,cl-som-imx7 # CompuLab CL-SOM-iMX7
- fsl,imx7d-sdb # i.MX7 SabreSD Board
- fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board
- kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex Concentrator
- kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex Concentrator in manufacturing mode
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf
- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
@ -376,11 +622,16 @@ properties:
# Colibri Evaluation Board V3
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on
# Colibri Evaluation Board V3
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
- zii,imx7d-rmu2 # ZII RMU2 Board
- zii,imx7d-rpu2 # ZII RPU2 Board
- const: fsl,imx7d
- description: TQ-Systems TQMa7D SoM on MBa7x board
items:
- const: tq,imx7d-mba7
- const: tq,imx7d-tqma7
- const: fsl,imx7d
- description:
Compulab SBC-iMX7 is a single board computer based on the
Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with
@ -392,6 +643,22 @@ properties:
- const: compulab,cl-som-imx7
- const: fsl,imx7d
- description: i.MX7D Boards with Toradex Colibri i.MX7D Module
items:
- enum:
- toradex,colibri-imx7d-aster # Module on Aster Carrier Board
- toradex,colibri-imx7d-eval-v3 # Module on Colibri Evaluation Board V3
- const: toradex,colibri-imx7d
- const: fsl,imx7d
- description: i.MX7D Boards with Toradex Colibri i.MX7D eMMC Module
items:
- enum:
- toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc-eval-v3 # Module on Colibri Evaluation Board V3
- const: toradex,colibri-imx7d-emmc
- const: fsl,imx7d
- description: i.MX7ULP based Boards
items:
- enum:
@ -405,9 +672,16 @@ properties:
- beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
- fsl,imx8mm-evk # i.MX8MM EVK Board
- kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM
- variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module
- const: fsl,imx8mm
- description: Kontron BL i.MX8MM (N801X S) Board
items:
- const: kontron,imx8mm-n801x-s
- const: kontron,imx8mm-n801x-som
- const: fsl,imx8mm
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
@ -491,10 +765,26 @@ properties:
- fsl,vf600
- fsl,vf610
- fsl,vf610m4
- toradex,vf500-colibri_vf50 # Colibri VF50 Module
- toradex,vf500-colibri_vf50-on-eval # Colibri VF50 Module on Colibri Evaluation Board
- toradex,vf610-colibri_vf61 # Colibri VF61 Module
- toradex,vf610-colibri_vf61-on-eval # Colibri VF61 Module on Colibri Evaluation Board
- description: Toradex Colibri VF50 Module on Colibri Evaluation Board
items:
- const: toradex,vf500-colibri_vf50-on-eval
- const: toradex,vf500-colibri_vf50
- const: fsl,vf500
- description: VF610 based Boards
items:
- enum:
- lwn,bk4 # Liebherr BK4 controller
- phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board
- fsl,vf610-twr # VF610 Tower Board
- const: fsl,vf610
- description: Toradex Colibri VF61 Module on Colibri Evaluation Board
items:
- const: toradex,vf610-colibri_vf61-on-eval
- const: toradex,vf610-colibri_vf61
- const: fsl,vf610
- description: ZII's VF610 based Boards
items:
@ -515,6 +805,7 @@ properties:
- ebs-systart,oxalis
- fsl,ls1012a-rdb
- fsl,ls1012a-frdm
- fsl,ls1012a-frwy
- fsl,ls1012a-qds
- const: fsl,ls1012a
@ -613,6 +904,15 @@ properties:
- enum:
- fsl,lx2160a-qds
- fsl,lx2160a-rdb
- fsl,lx2162a-qds
- const: fsl,lx2160a
- description: SolidRun LX2160A based Boards
items:
- enum:
- solidrun,clearfog-cx
- solidrun,honeycomb
- const: solidrun,lx2160a-cex7
- const: fsl,lx2160a
- description: S32V234 based Boards

2
Documentation/devicetree/bindings/arm/idle-states.yaml
View File

@ -313,7 +313,7 @@ patternProperties:
wakeup-latency-us by this duration.
idle-state-name:
$ref: /schemas/types.yaml#definitions/string
$ref: /schemas/types.yaml#/definitions/string
description:
A string used as a descriptive name for the idle state.

4
Documentation/devicetree/bindings/arm/mediatek.yaml
View File

@ -84,6 +84,10 @@ properties:
- enum:
- mediatek,mt8135-evbp1
- const: mediatek,mt8135
- items:
- enum:
- mediatek,mt8167-pumpkin
- const: mediatek,mt8167
- description: Google Elm (Acer Chromebook R13)
items:
- const: google,elm-rev8

1
Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
View File

@ -23,6 +23,7 @@ properties:
enum:
- qcom,sc7180-llcc
- qcom,sdm845-llcc
- qcom,sm8150-llcc
reg:
items:

40
Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml Normal file
View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2020 thingy.jp.
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MStar/SigmaStar Armv7 SoC SMP control registers
maintainers:
- Daniel Palmer <daniel@thingy.jp>
description: |
MStar/SigmaStar's Armv7 SoCs that have more than one processor
have a region of registers that allow setting the boot address
and a magic number that allows secondary processors to leave
the loop they are parked in by the boot ROM.
properties:
compatible:
items:
- enum:
- sstar,ssd201-smpctrl # SSD201/SSD202D
- const: mstar,smpctrl
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
smpctrl@204000 {
compatible = "sstar,ssd201-smpctrl", "mstar,smpctrl";
reg = <0x204000 0x200>;
};

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

@ -20,6 +20,12 @@ properties:
- thingyjp,breadbee-crust # thingy.jp BreadBee Crust
- const: mstar,infinity
- description: infinity2m boards
items:
- enum:
- honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit
- const: mstar,infinity2m
- description: infinity3 boards
items:
- enum:

1
Documentation/devicetree/bindings/arm/renesas.yaml
View File

@ -245,6 +245,7 @@ properties:
- enum:
- renesas,r8a7795
- renesas,r8a7796
- renesas,r8a77961
- renesas,r8a77965
- description: R-Car M3-N (R8A77965)

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

@ -70,6 +70,24 @@ properties:
- const: elgin,rv1108-r1
- const: rockchip,rv1108
- description: Engicam PX30.Core C.TOUCH 2.0
items:
- const: engicam,px30-core-ctouch2
- const: engicam,px30-core
- const: rockchip,px30
- description: Engicam PX30.Core C.TOUCH 2.0 10.1" Open Frame
items:
- const: engicam,px30-core-ctouch2-of10
- const: engicam,px30-core
- const: rockchip,px30
- description: Engicam PX30.Core EDIMM2.2 Starter Kit
items:
- const: engicam,px30-core-edimm2.2
- const: engicam,px30-core
- const: rockchip,px30
- description: Firefly Firefly-RK3288
items:
- enum:
@ -381,6 +399,11 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
- description: Kobol Helios64
items:
- const: kobol,helios64
- const: rockchip,rk3399
- description: Mecer Xtreme Mini S6
items:
- const: mecer,xms6

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

@ -14,6 +14,19 @@ properties:
const: '/'
compatible:
oneOf:
- description: S3C2416 based boards
items:
- enum:
- samsung,smdk2416 # Samsung SMDK2416
- const: samsung,s3c2416
- description: S3C6410 based boards
items:
- enum:
- friendlyarm,mini6410 # FriendlyARM Mini6410
- samsung,smdk6410 # Samsung SMDK6410
- const: samsung,s3c6410
- description: S5PV210 based boards
items:
- enum:
@ -83,6 +96,14 @@ properties:
- const: samsung,exynos4412
- const: samsung,exynos4
- description: Samsung p4note family boards
items:
- enum:
- samsung,n8010 # Samsung GT-N8010/GT-N8013
- const: samsung,p4note
- const: samsung,exynos4412
- const: samsung,exynos4
- description: Exynos5250 based boards
items:
- enum:

4
Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
View File

@ -21,6 +21,10 @@ properties:
- st,stm32-power-config
- st,stm32-tamp
- const: syscon
- items:
- const: st,stm32-tamp
- const: syscon
- const: simple-mfd
reg:
maxItems: 1

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

@ -14,6 +14,20 @@ properties:
const: "/"
compatible:
oneOf:
- description: DH STM32MP1 SoM based Boards
items:
- enum:
- arrow,stm32mp157a-avenger96 # Avenger96
- dh,stm32mp153c-dhcom-drc02
- dh,stm32mp157c-dhcom-pdk2
- dh,stm32mp157c-dhcom-picoitx
- enum:
- dh,stm32mp153c-dhcom-som
- dh,stm32mp157a-dhcor-som
- dh,stm32mp157c-dhcom-som
- enum:
- st,stm32mp153
- st,stm32mp157
- items:
- enum:
- st,stm32f429i-disco
@ -39,8 +53,6 @@ properties:
- const: st,stm32h743
- items:
- enum:
- arrow,stm32mp157a-avenger96 # Avenger96
- lxa,stm32mp157c-mc1
- shiratech,stm32mp157a-iot-box # IoT Box
- shiratech,stm32mp157a-stinger96 # Stinger96
- st,stm32mp157c-ed1
@ -52,6 +64,13 @@ properties:
- const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
- description: Octavo OSD32MP15x System-in-Package based boards
items:
- enum:
- lxa,stm32mp157c-mc1 # Linux Automation MC-1
- const: oct,stm32mp15xx-osd32
- enum:
- st,stm32mp157
- description: Odyssey STM32MP1 SoM based Boards
items:
- enum:

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

@ -201,6 +201,19 @@ properties:
- const: dserve,dsrv9703c
- const: allwinner,sun4i-a10
- description: Elimo Engineering Impetus SoM
items:
- const: elimo,impetus
- const: sochip,s3
- const: allwinner,sun8i-v3
- description: Elimo Engineering Initium
items:
- const: elimo,initium
- const: elimo,impetus
- const: sochip,s3
- const: allwinner,sun8i-v3
- description: Empire Electronix D709 Tablet
items:
- const: empire-electronix,d709
@ -251,6 +264,16 @@ properties:
- const: friendlyarm,nanopi-neo-plus2
- const: allwinner,sun50i-h5
- description: FriendlyARM NanoPi R1
items:
- const: friendlyarm,nanopi-r1
- const: allwinner,sun8i-h3
- description: FriendlyARM ZeroPi
items:
- const: friendlyarm,zeropi
- const: allwinner,sun8i-h3
- description: Gemei G9 Tablet
items:
- const: gemei,g9

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

@ -71,6 +71,9 @@ properties:
- const: asus,tilapia
- const: asus,grouper
- const: nvidia,tegra30
- items:
- const: ouya,ouya
- const: nvidia,tegra30
- items:
- enum:
- nvidia,dalmore

25
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
View File

@ -18,8 +18,30 @@ clock-names. See ../../clock/clock-bindings.txt for details.
../../reset/reset.txt for details.
- reset-names: Must include the following entries:
- actmon
- operating-points-v2: See ../bindings/opp/opp.txt for details.
- interconnects: Should contain entries for memory clients sitting on
MC->EMC memory interconnect path.
- interconnect-names: Should include name of the interconnect path for each
interconnect entry. Consult TRM documentation for
information about available memory clients, see MEMORY
CONTROLLER section.
For each opp entry in 'operating-points-v2' table:
- opp-supported-hw: bitfield indicating SoC speedo ID mask
- opp-peak-kBps: peak bandwidth of the memory channel
Example:
dfs_opp_table: opp-table {
compatible = "operating-points-v2";
opp@12750000 {
opp-hz = /bits/ 64 <12750000>;
opp-supported-hw = <0x000F>;
opp-peak-kBps = <51000>;
};
...
};
actmon@6000c800 {
compatible = "nvidia,tegra124-actmon";
reg = <0x0 0x6000c800 0x0 0x400>;
@ -29,4 +51,7 @@ Example:
clock-names = "actmon", "emc";
resets = <&tegra_car 119>;
reset-names = "actmon";
operating-points-v2 = <&dfs_opp_table>;
interconnects = <&mc TEGRA124_MC_MPCORER &emc>;
interconnect-names = "cpu";
};

2
Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
View File

@ -34,7 +34,7 @@ properties:
description:
The SRAM that needs to be claimed to access the display engine
bus.
$ref: /schemas/types.yaml#definitions/phandle-array
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
ranges: true

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

@ -46,7 +46,7 @@ properties:
const: 1
syscon:
$ref: /schemas/types.yaml#definitions/phandle
$ref: /schemas/types.yaml#/definitions/phandle
description: Phandle to the Baikal-T1 System Controller DT node
interrupts:

44
Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt
View File

@ -1,44 +0,0 @@
NVIDIA Tegra ACONNECT Bus
The Tegra ACONNECT bus is an AXI switch which is used to connnect various
components inside the Audio Processing Engine (APE). All CPU accesses to
the APE subsystem go through the ACONNECT via an APB to AXI wrapper.
Required properties:
- compatible: Must be "nvidia,tegra210-aconnect".
- clocks: Must contain the entries for the APE clock (TEGRA210_CLK_APE),
and APE interface clock (TEGRA210_CLK_APB2APE).
- clock-names: Must contain the names "ape" and "apb2ape" for the corresponding
'clocks' entries.
- power-domains: Must contain a phandle that points to the audio powergate
(namely 'aud') for Tegra210.
- #address-cells: The number of cells used to represent physical base addresses
in the aconnect address space. Should be 1.
- #size-cells: The number of cells used to represent the size of an address
range in the aconnect address space. Should be 1.
- ranges: Mapping of the aconnect address space to the CPU address space.
All devices accessed via the ACONNNECT are described by child-nodes.
Example:
aconnect@702c0000 {
compatible = "nvidia,tegra210-aconnect";
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
clock-names = "ape", "apb2ape";
power-domains = <&pd_audio>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x702c0000 0x0 0x702c0000 0x00040000>;
child1 {
...
};
child2 {
...
};
};

82
Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml Normal file
View File

@ -0,0 +1,82 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/nvidia,tegra210-aconnect.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra ACONNECT Bus
description: |
The Tegra ACONNECT bus is an AXI switch which is used to connnect various
components inside the Audio Processing Engine (APE). All CPU accesses to
the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All
devices accessed via the ACONNNECT are described by child-nodes.
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
properties:
compatible:
oneOf:
- const: nvidia,tegra210-aconnect
- items:
- enum:
- nvidia,tegra186-aconnect
- nvidia,tegra194-aconnect
- const: nvidia,tegra210-aconnect
clocks:
items:
- description: Must contain the entry for APE clock
- description: Must contain the entry for APE interface clock
clock-names:
items:
- const: ape
- const: apb2ape
power-domains:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges: true
patternProperties:
"@[0-9a-f]+$":
type: object
required:
- compatible
- clocks
- clock-names
- power-domains
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
#include<dt-bindings/clock/tegra210-car.h>
aconnect@702c0000 {
compatible = "nvidia,tegra210-aconnect";
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
clock-names = "ape", "apb2ape";
power-domains = <&pd_audio>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x702c0000 0x702c0000 0x00040000>;
// Child device nodes follow ...
};
...

53
Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml Normal file
View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/adi,axi-clkgen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Binding for Analog Devices AXI clkgen pcore clock generator
maintainers:
- Lars-Peter Clausen <lars@metafoo.de>
- Michael Hennerich <michael.hennerich@analog.com>
description: |
The axi_clkgen IP core is a software programmable clock generator,
that can be synthesized on various FPGA platforms.
Link: https://wiki.analog.com/resources/fpga/docs/axi_clkgen
properties:
compatible:
enum:
- adi,axi-clkgen-2.00.a
clocks:
description:
Specifies the reference clock(s) from which the output frequency is
derived. This must either reference one clock if only the first clock
input is connected or two if both clock inputs are connected.
minItems: 1
maxItems: 2
'#clock-cells':
const: 0
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller@ff000000 {
compatible = "adi,axi-clkgen-2.00.a";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;
clocks = <&osc 1>;
};

25
Documentation/devicetree/bindings/clock/axi-clkgen.txt
View File

@ -1,25 +0,0 @@
Binding for the axi-clkgen clock generator
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
- #clock-cells : from common clock binding; Should always be set to 0.
- reg : Address and length of the axi-clkgen register set.
- clocks : Phandle and clock specifier for the parent clock(s). This must
either reference one clock if only the first clock input is connected or two
if both clock inputs are connected. For the later case the clock connected
to the first input must be specified first.
Optional properties:
- clock-output-names : From common clock binding.
Example:
clock@ff000000 {
compatible = "adi,axi-clkgen";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;
clocks = <&osc 1>;
};

54
Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml Normal file
View File

@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/canaan,k210-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Canaan Kendryte K210 Clock Device Tree Bindings
maintainers:
- Damien Le Moal <damien.lemoal@wdc.com>
description: |
Canaan Kendryte K210 SoC clocks driver bindings. The clock
controller node must be defined as a child node of the K210
system controller node.
See also:
- dt-bindings/clock/k210-clk.h
properties:
compatible:
const: canaan,k210-clk
clocks:
description:
Phandle of the SoC 26MHz fixed-rate oscillator clock.
'#clock-cells':
const: 1
required:
- compatible
- '#clock-cells'
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/k210-clk.h>
clocks {
in0: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <26000000>;
};
};
/* ... */
sysclk: clock-controller {
#clock-cells = <1>;
compatible = "canaan,k210-clk";
clocks = <&in0>;
};

55
Documentation/devicetree/bindings/clock/fsl,flexspi-clock.yaml Normal file
View File

@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/fsl,flexspi-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale FlexSPI clock driver for Layerscape SoCs
maintainers:
- Michael Walle <michael@walle.cc>
description:
The Freescale Layerscape SoCs have a special FlexSPI clock which is
derived from the platform PLL.
properties:
compatible:
enum:
- fsl,ls1028a-flexspi-clk
- fsl,lx2160a-flexspi-clk
reg:
maxItems: 1
clocks:
maxItems: 1
'#clock-cells':
const: 0
clock-output-names:
maxItems: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
examples:
- |
dcfg {
#address-cells = <1>;
#size-cells = <1>;
fspi_clk: clock-controller@900 {
compatible = "fsl,ls1028a-flexspi-clk";
reg = <0x900 0x4>;
#clock-cells = <0>;
clocks = <&parentclk>;
clock-output-names = "fspi_clk";
};
};

79
Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
View File

@ -21,27 +21,58 @@ description: |
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See the full list of clock IDs from:
include/dt-bindings/clock/imx8-clock.h
include/dt-bindings/clock/imx8-lpcg.h
properties:
compatible:
enum:
- fsl,imx8qxp-lpcg-adma
- fsl,imx8qxp-lpcg-conn
- fsl,imx8qxp-lpcg-dc
- fsl,imx8qxp-lpcg-dsp
- fsl,imx8qxp-lpcg-gpu
- fsl,imx8qxp-lpcg-hsio
- fsl,imx8qxp-lpcg-img
- fsl,imx8qxp-lpcg-lsio
- fsl,imx8qxp-lpcg-vpu
oneOf:
- const: fsl,imx8qxp-lpcg
- items:
- enum:
- fsl,imx8qm-lpcg
- const: fsl,imx8qxp-lpcg
- enum:
- fsl,imx8qxp-lpcg-adma
- fsl,imx8qxp-lpcg-conn
- fsl,imx8qxp-lpcg-dc
- fsl,imx8qxp-lpcg-dsp
- fsl,imx8qxp-lpcg-gpu
- fsl,imx8qxp-lpcg-hsio
- fsl,imx8qxp-lpcg-img
- fsl,imx8qxp-lpcg-lsio
- fsl,imx8qxp-lpcg-vpu
deprecated: true
reg:
maxItems: 1
'#clock-cells':
const: 1
clocks:
description: |
Input parent clocks phandle array for each clock
minItems: 1
maxItems: 8
clock-indices:
description: |
An integer array indicating the bit offset for each clock.
Refer to <include/dt-bindings/clock/imx8-lpcg.h> for the
supported LPCG clock indices.
minItems: 1
maxItems: 8
clock-output-names:
description: |
Shall be the corresponding names of the outputs.
NOTE this property must be specified in the same order
as the clock-indices property.
minItems: 1
maxItems: 8
power-domains:
maxItems: 1
required:
- compatible
- reg
@ -51,23 +82,33 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx8-clock.h>
#include <dt-bindings/clock/imx8-lpcg.h>
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
clock-controller@5b200000 {
compatible = "fsl,imx8qxp-lpcg-conn";
reg = <0x5b200000 0xb0000>;
sdhc0_lpcg: clock-controller@5b200000 {
compatible = "fsl,imx8qxp-lpcg";
reg = <0x5b200000 0x10000>;
#clock-cells = <1>;
clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>,
<&conn_ipg_clk>,
<&conn_axi_clk>;
clock-indices = <IMX_LPCG_CLK_0>,
<IMX_LPCG_CLK_4>,
<IMX_LPCG_CLK_5>;
clock-output-names = "sdhc0_lpcg_per_clk",
"sdhc0_lpcg_ipg_clk",
"sdhc0_lpcg_ahb_clk";
power-domains = <&pd IMX_SC_R_SDHC_0>;
};
mmc@5b010000 {
compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
reg = <0x5b010000 0x10000>;
clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
<&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>,
<&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>;
clocks = <&sdhc0_lpcg IMX_LPCG_CLK_4>,
<&sdhc0_lpcg IMX_LPCG_CLK_0>,
<&sdhc0_lpcg IMX_LPCG_CLK_5>;
clock-names = "ipg", "per", "ahb";
power-domains = <&pd IMX_SC_R_SDHC_0>;
};

58
Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,aoncc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Clock bindings for LPASS Always ON Clock Controller on SM8250 SoCs
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
description: |
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell.
See include/dt-bindings/clock/qcom,sm8250-lpass-aoncc.h for the full list
of Audio Clock controller clock IDs.
properties:
compatible:
const: qcom,sm8250-lpass-aon
reg:
maxItems: 1
'#clock-cells':
const: 1
clocks:
items:
- description: LPASS Core voting clock
- description: Glitch Free Mux register clock
clock-names:
items:
- const: core
- const: bus
required:
- compatible
- reg
- '#clock-cells'
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,sm8250-lpass-aoncc.h>
#include <dt-bindings/sound/qcom,q6afe.h>
clock-controller@3800000 {
#clock-cells = <1>;
compatible = "qcom,sm8250-lpass-aon";
reg = <0x03380000 0x40000>;
clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
<&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
clock-names = "core", "bus";
};

58
Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,audiocc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Clock bindings for LPASS Audio Clock Controller on SM8250 SoCs
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
description: |
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell.
See include/dt-bindings/clock/qcom,sm8250-lpass-audiocc.h for the full list
of Audio Clock controller clock IDs.
properties:
compatible:
const: qcom,sm8250-lpass-audiocc
reg:
maxItems: 1
'#clock-cells':
const: 1
clocks:
items:
- description: LPASS Core voting clock
- description: Glitch Free Mux register clock
clock-names:
items:
- const: core
- const: bus
required:
- compatible
- reg
- '#clock-cells'
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,sm8250-lpass-audiocc.h>
#include <dt-bindings/sound/qcom,q6afe.h>
clock-controller@3300000 {
#clock-cells = <1>;
compatible = "qcom,sm8250-lpass-audiocc";
reg = <0x03300000 0x30000>;
clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
<&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
clock-names = "core", "bus";
};

77
Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml Normal file
View File

@ -0,0 +1,77 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx55.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for SDX55
maintainers:
- Vinod Koul <vkoul@kernel.org>
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on SDX55
See also:
- dt-bindings/clock/qcom,gcc-sdx55.h
properties:
compatible:
const: qcom,gcc-sdx55
clocks:
items:
- description: Board XO source
- description: Sleep clock source
- description: PLL test clock source (Optional clock)
minItems: 2
maxItems: 3
clock-names:
items:
- const: bi_tcxo
- const: sleep_clk
- const: core_bi_pll_test_se # Optional clock
minItems: 2
maxItems: 3
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- clocks
- clock-names
- reg
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@100000 {
compatible = "qcom,gcc-sdx55";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&sleep_clk>, <&pll_test_clk>;
clock-names = "bi_tcxo", "sleep_clk", "core_bi_pll_test_se";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

2
Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
View File

@ -19,8 +19,10 @@ properties:
enum:
- qcom,sc7180-rpmh-clk
- qcom,sdm845-rpmh-clk
- qcom,sdx55-rpmh-clk
- qcom,sm8150-rpmh-clk
- qcom,sm8250-rpmh-clk
- qcom,sm8350-rpmh-clk
clocks:
maxItems: 1

73
Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml Normal file
View File

@ -0,0 +1,73 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sc7180-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Camera Clock & Reset Controller Binding for SC7180
maintainers:
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm camera clock control module which supports the clocks, resets and
power domains on SC7180.
See also:
- dt-bindings/clock/qcom,camcc-sc7180.h
properties:
compatible:
const: qcom,sc7180-camcc
clocks:
items:
- description: Board XO source
- description: Camera_ahb clock from GCC
- description: Camera XO clock from GCC
clock-names:
items:
- const: bi_tcxo
- const: iface
- const: xo
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@ad00000 {
compatible = "qcom,sc7180-camcc";
reg = <0x0ad00000 0x10000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_CAMERA_AHB_CLK>,
<&gcc GCC_CAMERA_XO_CLK>;
clock-names = "bi_tcxo", "iface", "xo";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

68
Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt
View File

@ -1,68 +0,0 @@
* Renesas R-Car USB 2.0 clock selector
This file provides information on what the device node for the R-Car USB 2.0
clock selector.
If you connect an external clock to the USB_EXTAL pin only, you should set
the clock rate to "usb_extal" node only.
If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module
is not needed because this is default setting. (Of course, you can set the
clock rates to both "usb_extal" and "usb_xtal" nodes.
Case 1: An external clock connects to R-Car SoC
+----------+ +--- R-Car ---------------------+
|External |---|USB_EXTAL ---> all usb channels|
|clock | |USB_XTAL |
+----------+ +-------------------------------+
In this case, we need this driver with "usb_extal" clock.
Case 2: An oscillator connects to R-Car SoC
+----------+ +--- R-Car ---------------------+
|Oscillator|---|USB_EXTAL -+-> all usb channels|
| |---|USB_XTAL --+ |
+----------+ +-------------------------------+
In this case, we don't need this selector.
Required properties:
- compatible: "renesas,r8a7795-rcar-usb2-clock-sel" if the device is a part of
an R8A7795 SoC.
"renesas,r8a7796-rcar-usb2-clock-sel" if the device if a part of
an R8A77960 SoC.
"renesas,r8a77961-rcar-usb2-clock-sel" if the device if a part of
an R8A77961 SoC.
"renesas,rcar-gen3-usb2-clock-sel" for a generic R-Car Gen3
compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
followed by the generic version.
- reg: offset and length of the USB 2.0 clock selector register block.
- clocks: A list of phandles and specifier pairs.
- clock-names: Name of the clocks.
- The functional clock of USB 2.0 host side must be "ehci_ohci"
- The functional clock of HS-USB side must be "hs-usb-if"
- The USB_EXTAL clock pin must be "usb_extal"
- The USB_XTAL clock pin must be "usb_xtal"
- #clock-cells: Must be 0
- power-domains: A phandle and symbolic PM domain specifier.
See power/renesas,rcar-sysc.yaml.
- resets: A list of phandles and specifier pairs.
- reset-names: Name of the resets.
- The reset of USB 2.0 host side must be "ehci_ohci"
- The reset of HS-USB side must be "hs-usb-if"
Example (R-Car H3):
usb2_clksel: clock-controller@e6590630 {
compatible = "renesas,r8a7795-rcar-usb2-clock-sel",
"renesas,rcar-gen3-usb2-clock-sel";
reg = <0 0xe6590630 0 0x02>;
clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
<&usb_extal>, <&usb_xtal>;
clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal";
#clock-cells = <0>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 703>, <&cpg 704>;
reset-names = "ehci_ohci", "hs-usb-if";
};

100
Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml Normal file
View File

@ -0,0 +1,100 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Renesas R-Car USB 2.0 clock selector
maintainers:
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
description: |
If you connect an external clock to the USB_EXTAL pin only, you should set
the clock rate to "usb_extal" node only.
If you connect an oscillator to both the USB_XTAL and USB_EXTAL, this module
is not needed because this is default setting. (Of course, you can set the
clock rates to both "usb_extal" and "usb_xtal" nodes.
Case 1: An external clock connects to R-Car SoC
+----------+ +--- R-Car ---------------------+
|External |---|USB_EXTAL ---> all usb channels|
|clock | |USB_XTAL |
+----------+ +-------------------------------+
In this case, we need this driver with "usb_extal" clock.
Case 2: An oscillator connects to R-Car SoC
+----------+ +--- R-Car ---------------------+
|Oscillator|---|USB_EXTAL -+-> all usb channels|
| |---|USB_XTAL --+ |
+----------+ +-------------------------------+
In this case, we don't need this selector.
properties:
compatible:
items:
- enum:
- renesas,r8a7795-rcar-usb2-clock-sel # R-Car H3
- renesas,r8a7796-rcar-usb2-clock-sel # R-Car M3-W
- renesas,r8a77961-rcar-usb2-clock-sel # R-Car M3-W+
- const: renesas,rcar-gen3-usb2-clock-sel
reg:
maxItems: 1
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: ehci_ohci
- const: hs-usb-if
- const: usb_extal
- const: usb_xtal
'#clock-cells':
const: 0
power-domains:
maxItems: 1
resets:
minItems: 2
maxItems: 2
reset-names:
items:
- const: ehci_ohci
- const: hs-usb-if
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- power-domains
- resets
- reset-names
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
#include <dt-bindings/power/r8a7795-sysc.h>
usb2_clksel: clock-controller@e6590630 {
compatible = "renesas,r8a7795-rcar-usb2-clock-sel",
"renesas,rcar-gen3-usb2-clock-sel";
reg = <0xe6590630 0x02>;
clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>,
<&usb_extal>, <&usb_xtal>;
clock-names = "ehci_ohci", "hs-usb-if", "usb_extal", "usb_xtal";
#clock-cells = <0>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 703>, <&cpg 704>;
reset-names = "ehci_ohci", "hs-usb-if";
};

60
Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml Normal file
View File

@ -0,0 +1,60 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 SiFive, Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/sifive/fu740-prci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SiFive FU740 Power Reset Clock Interrupt Controller (PRCI)
maintainers:
- Zong Li <zong.li@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
description:
On the FU740 family of SoCs, most system-wide clock and reset integration
is via the PRCI IP block.
The clock consumer should specify the desired clock via the clock ID
macros defined in include/dt-bindings/clock/sifive-fu740-prci.h.
These macros begin with PRCI_CLK_.
The hfclk and rtcclk nodes are required, and represent physical
crystals or resonators located on the PCB. These nodes should be present
underneath /, rather than /soc.
properties:
compatible:
const: sifive,fu740-c000-prci
reg:
maxItems: 1
clocks:
items:
- description: high frequency clock.
- description: RTL clock.
clock-names:
items:
- const: hfclk
- const: rtcclk
"#clock-cells":
const: 1
required:
- compatible
- reg
- clocks
- "#clock-cells"
additionalProperties: false
examples:
- |
prci: clock-controller@10000000 {
compatible = "sifive,fu740-c000-prci";
reg = <0x10000000 0x1000>;
clocks = <&hfclk>, <&rtcclk>;
#clock-cells = <1>;
};

32
Documentation/devicetree/bindings/connector/usb-connector.yaml
View File

@ -37,7 +37,7 @@ properties:
description: Size of the connector, should be specified in case of
non-fullsize 'usb-a-connector' or 'usb-b-connector' compatible
connectors.
$ref: /schemas/types.yaml#definitions/string
$ref: /schemas/types.yaml#/definitions/string
enum:
- mini
@ -67,7 +67,7 @@ properties:
power-role:
description: Determines the power role that the Type C connector will
support. "dual" refers to Dual Role Port (DRP).
$ref: /schemas/types.yaml#definitions/string
$ref: /schemas/types.yaml#/definitions/string
enum:
- source
@ -76,7 +76,7 @@ properties:
try-power-role:
description: Preferred power role.
$ref: /schemas/types.yaml#definitions/string
$ref: /schemas/types.yaml#/definitions/string
enum:
- source
@ -86,13 +86,31 @@ properties:
data-role:
description: Data role if Type C connector supports USB data. "dual" refers
Dual Role Device (DRD).
$ref: /schemas/types.yaml#definitions/string
$ref: /schemas/types.yaml#/definitions/string
enum:
- host
- device
- dual
typec-power-opmode:
description: Determines the power operation mode that the Type C connector
will support and will advertise through CC pins when it has no power
delivery support.
- "default" corresponds to default USB voltage and current defined by the
USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
operation respectively.
- "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB
Type-C Cable and Connector specification, when Power Delivery is not
supported.
allOf:
- $ref: /schemas/types.yaml#/definitions/string
enum:
- default
- 1.5A
- 3.0A
# The following are optional properties for "usb-c-connector" with power
# delivery support.
source-pdos:
@ -192,6 +210,12 @@ allOf:
type:
const: micro
anyOf:
- not:
required:
- typec-power-opmode
- new-source-frs-typec-current
additionalProperties: true
examples:

4
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
View File

@ -49,8 +49,8 @@ properties:
Video port for panel or connector.
required:
- port@0
- port@1
- port@0
- port@1
required:
- compatible

2
Documentation/devicetree/bindings/display/bridge/anx6345.yaml
View File

@ -26,11 +26,9 @@ properties:
description: GPIO connected to active low reset
dvdd12-supply:
maxItems: 1
description: Regulator for 1.2V digital core power.
dvdd25-supply:
maxItems: 1
description: Regulator for 2.5V digital core power.
ports:

4
Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
View File

@ -39,10 +39,10 @@ properties:
properties:
'#address-cells':
const: 1
const: 1
'#size-cells':
const: 0
const: 0
port@0:
type: object

2
Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
View File

@ -35,11 +35,9 @@ properties:
maxItems: 1
ovdd-supply:
maxItems: 1
description: I/O voltage
pwr18-supply:
maxItems: 1
description: core voltage
interrupts:

3
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
View File

@ -79,8 +79,7 @@ properties:
The GPIO used to control the power down line of this device.
maxItems: 1
power-supply:
maxItems: 1
power-supply: true
required:
- compatible

2
Documentation/devicetree/bindings/display/bridge/ps8640.yaml
View File

@ -35,11 +35,9 @@ properties:
description: GPIO connected to active low reset.
vdd12-supply:
maxItems: 1
description: Regulator for 1.2V digital core power.
vdd33-supply:
maxItems: 1
description: Regulator for 3.3V digital core power.
ports:

1
Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
View File

@ -60,7 +60,6 @@ properties:
description: GPIO controlling bridge enable
vdd-supply:
maxItems: 1
description: Power supply for the bridge
required:

1
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.yaml
View File

@ -74,7 +74,6 @@ properties:
description: Power down GPIO signal, pin name "/PDWN", active low.
vcc-supply:
maxItems: 1
description:
Power supply for the TTL output, TTL CLOCKOUT signal, LVDS input, PLL and
digital circuitry.

2
Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
View File

@ -28,11 +28,9 @@ properties:
description: i2c address of the bridge, 0x0f
vdd-supply:
maxItems: 1
description: 1.2V LVDS Power Supply
vddio-supply:
maxItems: 1
description: 1.8V IO Power Supply
stby-gpios:

4
Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
View File

@ -18,8 +18,8 @@ description: |
properties:
compatible:
items:
- const: intel,keembay-msscam
- const: syscon
- const: intel,keembay-msscam
- const: syscon
reg:
maxItems: 1

2
Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
View File

@ -32,7 +32,7 @@ required:
- power-supply
- reset-gpios
additionalProperties: false
unevaluatedProperties: false
examples:
- |

2
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
View File

@ -22,7 +22,7 @@ properties:
compatible:
items:
- enum:
- tianma,fhd-video
- tianma,fhd-video
- const: novatek,nt36672a
description: This indicates the panel manufacturer of the panel that is
in turn using the NT36672A panel driver. This compatible string

2
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
View File

@ -159,6 +159,8 @@ properties:
- innolux,g121x1-l03
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bge
# InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
- innolux,n125hce-gn1
# InnoLux 15.6" WXGA TFT LCD panel
- innolux,n156bge-l21
# Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel

68
Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
View File

@ -20,6 +20,10 @@ Required properties:
- reset-names: Must include the following entries:
- host1x
Each host1x client module having to perform DMA through the Memory Controller
should have the interconnect endpoints set to the Memory Client and External
Memory respectively.
The host1x top-level node defines a number of children, each representing one
of the following host1x client modules:
@ -36,6 +40,12 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- mpe
Optional properties:
- interconnects: Must contain entry for the MPE memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- vi: video input
Required properties:
@ -113,6 +123,12 @@ of the following host1x client modules:
Required properties:
- remote-endpoint: phandle to vi port 'endpoint' node.
Optional properties:
- interconnects: Must contain entry for the VI memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- epp: encoder pre-processor
Required properties:
@ -126,6 +142,12 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- epp
Optional properties:
- interconnects: Must contain entry for the EPP memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- isp: image signal processor
Required properties:
@ -139,6 +161,12 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- isp
Optional properties:
- interconnects: Must contain entry for the ISP memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- gr2d: 2D graphics engine
Required properties:
@ -152,6 +180,12 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- 2d
Optional properties:
- interconnects: Must contain entry for the GR2D memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- gr3d: 3D graphics engine
Required properties:
@ -170,6 +204,12 @@ of the following host1x client modules:
- 3d
- 3d2 (Only required on SoCs with two 3D clocks)
Optional properties:
- interconnects: Must contain entry for the GR3D memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- dc: display controller
Required properties:
@ -197,6 +237,10 @@ of the following host1x client modules:
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
- interconnects: Must contain entry for the DC memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
- hdmi: High Definition Multimedia Interface
@ -345,6 +389,12 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- vic
Optional properties:
- interconnects: Must contain entry for the VIC memory clients.
- interconnect-names: Must include name of the interconnect path for each
interconnect entry. Consult TRM documentation for information about
available memory clients, see MEMORY CONTROLLER section.
Example:
/ {
@ -498,6 +548,15 @@ Example:
resets = <&tegra_car 27>;
reset-names = "dc";
interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
<&mc TEGRA20_MC_DISPLAY0B &emc>,
<&mc TEGRA20_MC_DISPLAY0C &emc>,
<&mc TEGRA20_MC_DISPLAYHC &emc>;
interconnect-names = "wina",
"winb",
"winc",
"cursor";
rgb {
status = "disabled";
};
@ -513,6 +572,15 @@ Example:
resets = <&tegra_car 26>;
reset-names = "dc";
interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>,
<&mc TEGRA20_MC_DISPLAY0BB &emc>,
<&mc TEGRA20_MC_DISPLAY0CB &emc>,
<&mc TEGRA20_MC_DISPLAYHCB &emc>;
interconnect-names = "wina",
"winb",
"winc",
"cursor";
rgb {
status = "disabled";
};

1
Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
View File

@ -98,7 +98,6 @@ properties:
maxItems: 1
dmas:
maxItems: 4
items:
- description: Video layer, plane 0 (RGB or luma)
- description: Video layer, plane 1 (U/V or U)

5
Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
View File

@ -21,6 +21,7 @@ properties:
compatible:
oneOf:
- const: allwinner,sun50i-a64-dma
- const: allwinner,sun50i-a100-dma
- const: allwinner,sun50i-h6-dma
- items:
- const: allwinner,sun8i-r40-dma
@ -56,7 +57,9 @@ required:
if:
properties:
compatible:
const: allwinner,sun50i-h6-dma
enum:
- allwinner,sun50i-a100-dma
- allwinner,sun50i-h6-dma
then:
properties:

3
Documentation/devicetree/bindings/dma/atmel-xdma.txt
View File

@ -2,7 +2,8 @@
* XDMA Controller
Required properties:
- compatible: Should be "atmel,sama5d4-dma" or "microchip,sam9x60-dma".
- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or
"microchip,sama7g5-dma".
- reg: Should contain DMA registers location and length.
- interrupts: Should contain DMA interrupt.
- #dma-cells: Must be <1>, used to represent the number of integer cells in

4
Documentation/devicetree/bindings/dma/dma-common.yaml
View File

@ -38,12 +38,12 @@ properties:
maxItems: 255
dma-channels:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description:
Number of DMA channels supported by the controller.
dma-requests:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description:
Number of DMA request signals supported by the controller.

2
Documentation/devicetree/bindings/dma/dma-router.yaml
View File

@ -23,7 +23,7 @@ properties:
pattern: "^dma-router(@.*)?$"
dma-masters:
$ref: /schemas/types.yaml#definitions/phandle-array
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Array of phandles to the DMA controllers the router can direct
the signal to.

2
Documentation/devicetree/bindings/dma/ingenic,dma.yaml
View File

@ -48,7 +48,7 @@ properties:
ingenic,reserved-channels property.
ingenic,reserved-channels:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description: >
Bitmask of channels to reserve for devices that need a specific
channel. These channels will only be assigned when explicitely

1
Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
View File

@ -4,6 +4,7 @@ Required properties:
- compatible should contain:
* "mediatek,mt2712-uart-dma" for MT2712 compatible APDMA
* "mediatek,mt6577-uart-dma" for MT6577 and all of the above
* "mediatek,mt8516-uart-dma", "mediatek,mt6577" for MT8516 SoC
- reg: The base address of the APDMA register bank.

56
Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt
View File

@ -1,56 +0,0 @@
* NVIDIA Tegra Audio DMA (ADMA) controller
The Tegra Audio DMA controller that is used for transferring data
between system memory and the Audio Processing Engine (APE).
Required properties:
- compatible: Should contain one of the following:
- "nvidia,tegra210-adma": for Tegra210
- "nvidia,tegra186-adma": for Tegra186 and Tegra194
- reg: Should contain DMA registers location and length. This should be
a single entry that includes all of the per-channel registers in one
contiguous bank.
- interrupts: Should contain all of the per-channel DMA interrupts in
ascending order with respect to the DMA channel index.
- clocks: Must contain one entry for the ADMA module clock
(TEGRA210_CLK_D_AUDIO).
- clock-names: Must contain the name "d_audio" for the corresponding
'clocks' entry.
- #dma-cells : Must be 1. The first cell denotes the receive/transmit
request number and should be between 1 and the maximum number of
requests supported. This value corresponds to the RX/TX_REQUEST_SELECT
fields in the ADMA_CHn_CTRL register.
Example:
adma: dma@702e2000 {
compatible = "nvidia,tegra210-adma";
reg = <0x0 0x702e2000 0x0 0x2000>;
interrupt-parent = <&tegra_agic>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>;
clock-names = "d_audio";
#dma-cells = <1>;
};

99
Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml Normal file
View File

@ -0,0 +1,99 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/nvidia,tegra210-adma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra Audio DMA (ADMA) controller
description: |
The Tegra Audio DMA controller is used for transferring data
between system memory and the Audio Processing Engine (APE).
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
oneOf:
- enum:
- nvidia,tegra210-adma
- nvidia,tegra186-adma
- items:
- const: nvidia,tegra194-adma
- const: nvidia,tegra186-adma
reg:
maxItems: 1
interrupts:
description: |
Should contain all of the per-channel DMA interrupts in
ascending order with respect to the DMA channel index.
minItems: 1
maxItems: 32
clocks:
description: Must contain one entry for the ADMA module clock
maxItems: 1
clock-names:
const: d_audio
"#dma-cells":
description: |
The first cell denotes the receive/transmit request number and
should be between 1 and the maximum number of requests supported.
This value corresponds to the RX/TX_REQUEST_SELECT fields in the
ADMA_CHn_CTRL register.
const: 1
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include<dt-bindings/clock/tegra210-car.h>
dma-controller@702e2000 {
compatible = "nvidia,tegra210-adma";
reg = <0x702e2000 0x2000>;
interrupt-parent = <&tegra_agic>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>;
clock-names = "d_audio";
#dma-cells = <1>;
};
...

88
Documentation/devicetree/bindings/dma/qcom,gpi.yaml Normal file
View File

@ -0,0 +1,88 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies Inc GPI DMA controller
maintainers:
- Vinod Koul <vkoul@kernel.org>
description: |
QCOM GPI DMA controller provides DMA capabilities for
peripheral buses such as I2C, UART, and SPI.
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
enum:
- qcom,sdm845-gpi-dma
reg:
maxItems: 1
interrupts:
description:
Interrupt lines for each GPI instance
maxItems: 13
"#dma-cells":
const: 3
description: >
DMA clients must use the format described in dma.txt, giving a phandle
to the DMA controller plus the following 3 integer cells:
- channel: if set to 0xffffffff, any available channel will be allocated
for the client. Otherwise, the exact channel specified will be used.
- seid: serial id of the client as defined in the SoC documentation.
- client: type of the client as defined in dt-bindings/dma/qcom-gpi.h
iommus:
maxItems: 1
dma-channels:
maximum: 31
dma-channel-mask:
maxItems: 1
required:
- compatible
- reg
- interrupts
- "#dma-cells"
- iommus
- dma-channels
- dma-channel-mask
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/dma/qcom-gpi.h>
gpi_dma0: dma-controller@800000 {
compatible = "qcom,gpi-dma";
#dma-cells = <3>;
reg = <0x00800000 0x60000>;
iommus = <&apps_smmu 0x0016 0x0>;
dma-channels = <13>;
dma-channel-mask = <0xfa>;
interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 253 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 254 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 255 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
};
...

1
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
View File

@ -73,7 +73,6 @@ properties:
maxItems: 1
clock-names:
maxItems: 1
items:
- const: fck

10
Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
View File

@ -54,7 +54,7 @@ properties:
maximum: 16
dma-masters:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Number of DMA masters supported by the controller. In case if
not specified the driver will try to auto-detect this and
@ -63,7 +63,7 @@ properties:
maximum: 4
chan_allocation_order:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description: |
DMA channels allocation order specifier. Zero means ascending order
(first free allocated), while one - descending (last free allocated).
@ -71,7 +71,7 @@ properties:
enum: [0, 1]
chan_priority:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description: |
DMA channels priority order. Zero means ascending channels priority
so the very first channel has the highest priority. While 1 means
@ -80,7 +80,7 @@ properties:
enum: [0, 1]
block_size:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description: Maximum block size supported by the DMA controller.
enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095]
@ -139,7 +139,7 @@ properties:
default: 256
snps,dma-protection-control:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting
indicates the following features: bit 0 - privileged mode,

166
Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml Normal file
View File

@ -0,0 +1,166 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
maintainers:
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
mode channels of K3 UDMA-P.
BCDMA includes block copy channels and Split channels.
Block copy channels mainly used for memory to memory transfers, but with
optional triggers a block copy channel can service peripherals by accessing
directly to memory mapped registers or area.
Split channels can be used to service PSI-L based peripherals.
The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the
legacy peripheral.
PDMAs can be configured via BCDMA split channel's peer registers to match with
the configuration of the legacy peripheral.
allOf:
- $ref: /schemas/dma/dma-controller.yaml#
properties:
compatible:
const: ti,am64-dmss-bcdma
"#dma-cells":
const: 3
description: |
cell 1: type of the BCDMA channel to be used to service the peripheral:
0 - split channel
1 - block copy channel using global trigger 1
2 - block copy channel using global trigger 2
3 - block copy channel using local trigger
cell 2: parameter for the channel:
if cell 1 is 0 (split channel):
PSI-L thread ID of the remote (to BCDMA) end.
Valid ranges for thread ID depends on the data movement direction:
for source thread IDs (rx): 0 - 0x7fff
for destination thread IDs (tx): 0x8000 - 0xffff
Please refer to the device documentation for the PSI-L thread map and
also the PSI-L peripheral chapter for the correct thread ID.
if cell 1 is 1 or 2 (block copy channel using global trigger):
Unused, ignored
The trigger must be configured for the channel externally to BCDMA,
channels using global triggers should not be requested directly, but
via DMA event router.
if cell 1 is 3 (block copy channel using local trigger):
bchan number of the locally triggered channel
cell 3: ASEL value for the channel
reg:
maxItems: 5
reg-names:
items:
- const: gcfg
- const: bchanrt
- const: rchanrt
- const: tchanrt
- const: ringrt
msi-parent: true
ti,asel:
$ref: /schemas/types.yaml#/definitions/uint32
description: ASEL value for non slave channels
ti,sci-rm-range-bchan:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of BCDMA block-copy channel resource subtypes for resource
allocation for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
ti,sci-rm-range-tchan:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of BCDMA split tx channel resource subtypes for resource allocation
for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
ti,sci-rm-range-rchan:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of BCDMA split rx channel resource subtypes for resource allocation
for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
required:
- compatible
- "#dma-cells"
- reg
- reg-names
- msi-parent
- ti,sci
- ti,sci-dev-id
- ti,sci-rm-range-bchan
- ti,sci-rm-range-tchan
- ti,sci-rm-range-rchan
unevaluatedProperties: false
examples:
- |+
cbass_main {
#address-cells = <2>;
#size-cells = <2>;
main_dmss {
compatible = "simple-mfd";
#address-cells = <2>;
#size-cells = <2>;
dma-ranges;
ranges;
ti,sci-dev-id = <25>;
main_bcdma: dma-controller@485c0100 {
compatible = "ti,am64-dmss-bcdma";
reg = <0x0 0x485c0100 0x0 0x100>,
<0x0 0x4c000000 0x0 0x20000>,
<0x0 0x4a820000 0x0 0x20000>,
<0x0 0x4aa40000 0x0 0x20000>,
<0x0 0x4bc00000 0x0 0x100000>;
reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
msi-parent = <&inta_main_dmss>;
#dma-cells = <3>;
ti,sci = <&dmsc>;
ti,sci-dev-id = <26>;
ti,sci-rm-range-bchan = <0x20>; /* BLOCK_COPY_CHAN */
ti,sci-rm-range-rchan = <0x21>; /* SPLIT_TR_RX_CHAN */
ti,sci-rm-range-tchan = <0x22>; /* SPLIT_TR_TX_CHAN */
};
};
};

174
Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml Normal file
View File

@ -0,0 +1,174 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
maintainers:
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The Packet DMA (PKTDMA) is intended to perform similar functions as the packet
mode channels of K3 UDMA-P.
PKTDMA only includes Split channels to service PSI-L based peripherals.
The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the
legacy peripheral.
PDMAs can be configured via PKTDMA split channel's peer registers to match
with the configuration of the legacy peripheral.
allOf:
- $ref: /schemas/dma/dma-controller.yaml#
properties:
compatible:
const: ti,am64-dmss-pktdma
"#dma-cells":
const: 2
description: |
The first cell is the PSI-L thread ID of the remote (to PKTDMA) end.
Valid ranges for thread ID depends on the data movement direction:
for source thread IDs (rx): 0 - 0x7fff
for destination thread IDs (tx): 0x8000 - 0xffff
Please refer to the device documentation for the PSI-L thread map and also
the PSI-L peripheral chapter for the correct thread ID.
The second cell is the ASEL value for the channel
reg:
maxItems: 4
reg-names:
items:
- const: gcfg
- const: rchanrt
- const: tchanrt
- const: ringrt
msi-parent: true
ti,sci-rm-range-tchan:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of PKTDMA split tx channel resource subtypes for resource allocation
for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
ti,sci-rm-range-tflow:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of PKTDMA split tx flow resource subtypes for resource allocation
for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
ti,sci-rm-range-rchan:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of PKTDMA split rx channel resource subtypes for resource allocation
for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
ti,sci-rm-range-rflow:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Array of PKTDMA split rx flow resource subtypes for resource allocation
for this host
minItems: 1
# Should be enough
maxItems: 255
items:
maximum: 0x3f
required:
- compatible
- "#dma-cells"
- reg
- reg-names
- msi-parent
- ti,sci
- ti,sci-dev-id
- ti,sci-rm-range-tchan
- ti,sci-rm-range-tflow
- ti,sci-rm-range-rchan
- ti,sci-rm-range-rflow
unevaluatedProperties: false
examples:
- |+
cbass_main {
#address-cells = <2>;
#size-cells = <2>;
main_dmss {
compatible = "simple-mfd";
#address-cells = <2>;
#size-cells = <2>;
dma-ranges;
ranges;
ti,sci-dev-id = <25>;
main_pktdma: dma-controller@485c0000 {
compatible = "ti,am64-dmss-pktdma";
reg = <0x0 0x485c0000 0x0 0x100>,
<0x0 0x4a800000 0x0 0x20000>,
<0x0 0x4aa00000 0x0 0x40000>,
<0x0 0x4b800000 0x0 0x400000>;
reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
msi-parent = <&inta_main_dmss>;
#dma-cells = <2>;
ti,sci = <&dmsc>;
ti,sci-dev-id = <30>;
ti,sci-rm-range-tchan = <0x23>, /* UNMAPPED_TX_CHAN */
<0x24>, /* CPSW_TX_CHAN */
<0x25>, /* SAUL_TX_0_CHAN */
<0x26>, /* SAUL_TX_1_CHAN */
<0x27>, /* ICSSG_0_TX_CHAN */
<0x28>; /* ICSSG_1_TX_CHAN */
ti,sci-rm-range-tflow = <0x10>, /* RING_UNMAPPED_TX_CHAN */
<0x11>, /* RING_CPSW_TX_CHAN */
<0x12>, /* RING_SAUL_TX_0_CHAN */
<0x13>, /* RING_SAUL_TX_1_CHAN */
<0x14>, /* RING_ICSSG_0_TX_CHAN */
<0x15>; /* RING_ICSSG_1_TX_CHAN */
ti,sci-rm-range-rchan = <0x29>, /* UNMAPPED_RX_CHAN */
<0x2b>, /* CPSW_RX_CHAN */
<0x2d>, /* SAUL_RX_0_CHAN */
<0x2f>, /* SAUL_RX_1_CHAN */
<0x31>, /* SAUL_RX_2_CHAN */
<0x33>, /* SAUL_RX_3_CHAN */
<0x35>, /* ICSSG_0_RX_CHAN */
<0x37>; /* ICSSG_1_RX_CHAN */
ti,sci-rm-range-rflow = <0x2a>, /* FLOW_UNMAPPED_RX_CHAN */
<0x2c>, /* FLOW_CPSW_RX_CHAN */
<0x2e>, /* FLOW_SAUL_RX_0/1_CHAN */
<0x32>, /* FLOW_SAUL_RX_2/3_CHAN */
<0x36>, /* FLOW_ICSSG_0_RX_CHAN */
<0x38>; /* FLOW_ICSSG_1_RX_CHAN */
};
};
};

4
Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
View File

@ -1,4 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2019 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml#
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 NAVSS Unified DMA Device Tree Bindings
maintainers:
- Peter Ujfalusi <peter.ujfalusi@ti.com>
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The UDMA-P is intended to perform similar (but significantly upgraded)

4
Documentation/devicetree/bindings/eeprom/at24.yaml
View File

@ -131,7 +131,7 @@ properties:
default: 1
read-only:
$ref: /schemas/types.yaml#definitions/flag
$ref: /schemas/types.yaml#/definitions/flag
description:
Disables writes to the eeprom.
@ -141,7 +141,7 @@ properties:
Total eeprom size in bytes.
no-read-rollover:
$ref: /schemas/types.yaml#definitions/flag
$ref: /schemas/types.yaml#/definitions/flag
description:
Indicates that the multi-address eeprom does not automatically roll
over reads to the next slave address. Please consult the manual of

4
Documentation/devicetree/bindings/eeprom/at25.yaml
View File

@ -45,13 +45,13 @@ properties:
spi-max-frequency: true
pagesize:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072]
description:
Size of the eeprom page.
size:
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
description:
Total eeprom size in bytes.

1
Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
View File

@ -48,6 +48,7 @@ properties:
- nxp,pcal6416
- nxp,pcal6524
- nxp,pcal9535
- nxp,pcal9554b
- nxp,pcal9555a
- onnn,cat9554
- onnn,pca9654

2
Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
View File

@ -13,6 +13,7 @@ Required properties:
- gpio-controller : Marks the device node as a GPIO controller.
Optional properties:
- clocks : Input clock specifier. Refer to common clock bindings.
- interrupts : Interrupt mapping for GPIO IRQ.
- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
@ -29,6 +30,7 @@ Example:
gpio: gpio@40000000 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
clocks = <&clkc25>;
gpio-controller ;
interrupt-parent = <&microblaze_0_intc>;
interrupts = < 6 2 >;

35
Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
View File

@ -1,35 +0,0 @@
Mediatek MT7621 SoC GPIO controller bindings
The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
The registers of all the banks are interwoven inside one single IO range.
We load one GPIO controller instance per bank. Also the GPIO controller can receive
interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU
using GIC INT12.
Required properties for the top level node:
- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
second cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt. Should be 2. The first cell defines the interrupt number,
the second encodes the trigger flags encoded as described in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- compatible:
- "mediatek,mt7621-gpio" for Mediatek controllers
- reg : Physical base address and length of the controller's registers
- interrupt-parent : phandle of the parent interrupt controller.
- interrupts : Interrupt specifier for the controllers interrupt.
- interrupt-controller : Mark the device node as an interrupt controller.
- gpio-controller : Marks the device node as a GPIO controller.
Example:
gpio@600 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "mediatek,mt7621-gpio";
gpio-controller;
interrupt-controller;
reg = <0x600 0x100>;
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
};

72
Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.yaml Normal file
View File

@ -0,0 +1,72 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/mediatek,mt7621-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mediatek MT7621 SoC GPIO controller
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
description: |
The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
The registers of all the banks are interwoven inside one single IO range.
We load one GPIO controller instance per bank. Also the GPIO controller can receive
interrupts on any of the GPIOs, either edge or level. It then interrupts the CPU
using GIC INT12.
properties:
$nodename:
pattern: "^gpio@[0-9a-f]+$"
compatible:
const: mediatek,mt7621-gpio
reg:
maxItems: 1
"#gpio-cells":
const: 2
gpio-controller: true
gpio-ranges: true
interrupt-controller: true
"#interrupt-cells":
const: 2
interrupts:
maxItems: 1
required:
- compatible
- reg
- "#gpio-cells"
- gpio-controller
- gpio-ranges
- interrupt-controller
- "#interrupt-cells"
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/mips-gic.h>
gpio@600 {
compatible = "mediatek,mt7621-gpio";
reg = <0x600 0x100>;
#gpio-cells = <2>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 95>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
};
...

59
Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml Normal file
View File

@ -0,0 +1,59 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/mstar,msc313-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MStar/SigmaStar GPIO controller
maintainers:
- Daniel Palmer <daniel@thingy.jp>
properties:
$nodename:
pattern: "^gpio@[0-9a-f]+$"
compatible:
const: mstar,msc313-gpio
reg:
maxItems: 1
gpio-controller: true
"#gpio-cells":
const: 2
gpio-ranges: true
interrupt-controller: true
"#interrupt-cells":
const: 2
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
- interrupt-controller
- "#interrupt-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/msc313-gpio.h>
gpio: gpio@207800 {
compatible = "mstar,msc313e-gpio";
#gpio-cells = <2>;
reg = <0x207800 0x200>;
gpio-controller;
gpio-ranges = <&pinctrl 0 36 22>,
<&pinctrl 22 63 4>,
<&pinctrl 26 68 6>;
#interrupt-cells = <2>;
interrupt-controller;
interrupt-parent = <&intc_fiq>;
};

2
Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
View File

@ -32,7 +32,7 @@ properties:
PVT controller has 5 VM (voltage monitor) sensors.
vm-map defines CPU core to VM instance mapping. A
value of 0xff means that VM sensor is unused.
$ref: /schemas/types.yaml#definitions/uint8-array
$ref: /schemas/types.yaml#/definitions/uint8-array
maxItems: 5
clocks:

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