mirror of https://gitee.com/openkylin/linux.git
Merge branches 'rgrp-glock-sharing' and 'gfs2-revoke' from https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git
Merge the resource group glock sharing feature and the revoke accounting rework. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
This commit is contained in:
Andreas Gruenbacher
commit
803074ad77
24
CREDITS
24
CREDITS
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/>`_
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,75 @@ 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.
|
||||
|
||||
The things that can be controlled are:
|
||||
|
||||
1. Whether KASAN is enabled at all.
|
||||
2. Whether KASAN collects and saves alloc/free stacks.
|
||||
3. Whether KASAN panics on a detected bug or not.
|
||||
|
||||
The ``kasan.mode`` boot parameter allows to choose one of three main modes:
|
||||
|
||||
- ``kasan.mode=off`` - KASAN is disabled, no tag checks are performed
|
||||
- ``kasan.mode=prod`` - only essential production features are enabled
|
||||
- ``kasan.mode=full`` - all KASAN features are enabled
|
||||
|
||||
The chosen mode provides default control values for the features mentioned
|
||||
above. However it's also possible to override the default values by providing:
|
||||
|
||||
- ``kasan.stacktrace=off`` or ``=on`` - enable alloc/free stack collection
|
||||
(default: ``on`` for ``mode=full``,
|
||||
otherwise ``off``)
|
||||
- ``kasan.fault=report`` or ``=panic`` - only print KASAN report or also panic
|
||||
(default: ``report``)
|
||||
|
||||
If ``kasan.mode`` parameter is not provided, it defaults to ``full`` when
|
||||
``CONFIG_DEBUG_KERNEL`` is enabled, and to ``prod`` otherwise.
|
||||
|
||||
For developers
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Software KASAN modes use compiler instrumentation to insert validity checks.
|
||||
Such instrumentation might be incompatible with some part of the kernel, and
|
||||
therefore needs to be disabled. To disable instrumentation for specific files
|
||||
or directories, add a line similar to the following to the respective kernel
|
||||
Makefile:
|
||||
|
||||
- For a single file (e.g. main.o)::
|
||||
|
||||
KASAN_SANITIZE_main.o := n
|
||||
|
||||
- For all files in one directory::
|
||||
|
||||
KASAN_SANITIZE := n
|
||||
|
||||
|
||||
Implementation details
|
||||
|
|
@ -160,10 +208,10 @@ 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 +242,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 +274,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 +350,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 +371,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 +403,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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
};
|
||||
|
|
@ -29,18 +29,18 @@ properties:
|
|||
- const: fsl,imx8qxp-lpcg
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx8qm-lpcg
|
||||
- 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
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
...
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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,7 +86,7 @@ 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
|
||||
|
|
@ -105,7 +105,7 @@ properties:
|
|||
Type-C Cable and Connector specification, when Power Delivery is not
|
||||
supported.
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#definitions/string
|
||||
- $ref: /schemas/types.yaml#/definitions/string
|
||||
enum:
|
||||
- default
|
||||
- 1.5A
|
||||
|
|
|
|||
|
|
@ -49,8 +49,8 @@ properties:
|
|||
Video port for panel or connector.
|
||||
|
||||
required:
|
||||
- port@0
|
||||
- port@1
|
||||
- port@0
|
||||
- port@1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -39,10 +39,10 @@ properties:
|
|||
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
const: 0
|
||||
|
||||
port@0:
|
||||
type: object
|
||||
|
|
|
|||
|
|
@ -35,11 +35,9 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
ovdd-supply:
|
||||
maxItems: 1
|
||||
description: I/O voltage
|
||||
|
||||
pwr18-supply:
|
||||
maxItems: 1
|
||||
description: core voltage
|
||||
|
||||
interrupts:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -60,7 +60,6 @@ properties:
|
|||
description: GPIO controlling bridge enable
|
||||
|
||||
vdd-supply:
|
||||
maxItems: 1
|
||||
description: Power supply for the bridge
|
||||
|
||||
required:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ description: |
|
|||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: intel,keembay-msscam
|
||||
- const: syscon
|
||||
- const: intel,keembay-msscam
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ required:
|
|||
- power-supply
|
||||
- reset-gpios
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -73,7 +73,6 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
maxItems: 1
|
||||
items:
|
||||
- const: fck
|
||||
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
# 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#
|
||||
|
|
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
# 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#
|
||||
|
|
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The Packet DMA (PKTDMA) is intended to perform similar functions as the packet
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -29,12 +29,12 @@ properties:
|
|||
const: 0x70
|
||||
|
||||
sensirion,blocking-io:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
If set, the driver hold the i2c bus until measurement is finished.
|
||||
|
||||
sensirion,low-precision:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
If set, the sensor aquire data with low precision (not recommended).
|
||||
The driver aquire data with high precision by default.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ properties:
|
|||
Array of three(TMP513) or two(TMP512) n-Factor value for each remote
|
||||
temperature channel.
|
||||
See datasheet Table 11 for n-Factor range list and value interpretation.
|
||||
$ref: /schemas/types.yaml#definitions/uint32-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
items:
|
||||
|
|
|
|||
|
|
@ -17,8 +17,7 @@ properties:
|
|||
- lltc,ltc2496
|
||||
|
||||
vref-supply:
|
||||
description: phandle to an external regulator providing the reference voltage
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: Power supply for the reference voltage
|
||||
|
||||
reg:
|
||||
description: spi chipselect number according to the usual spi bindings
|
||||
|
|
|
|||
|
|
@ -22,8 +22,7 @@ properties:
|
|||
- ti,hdc2010
|
||||
- ti,hdc2080
|
||||
|
||||
vdd-supply:
|
||||
maxItems: 1
|
||||
vdd-supply: true
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ properties:
|
|||
default: 0x16
|
||||
|
||||
upisemi,continuous:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description: |
|
||||
This chip has two power modes: one-shot (chip takes one measurement and
|
||||
then shuts itself down) and continuous (chip takes continuous
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ properties:
|
|||
- finest
|
||||
|
||||
semtech,startup-sensor:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2, 3]
|
||||
default: 0
|
||||
description:
|
||||
|
|
@ -81,7 +81,7 @@ properties:
|
|||
compensation.
|
||||
|
||||
semtech,proxraw-strength:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 2, 4, 8]
|
||||
default: 2
|
||||
description:
|
||||
|
|
@ -89,7 +89,7 @@ properties:
|
|||
represent 1-1/N.
|
||||
|
||||
semtech,avg-pos-strength:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295]
|
||||
default: 16
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -31,8 +31,7 @@ properties:
|
|||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply:
|
||||
maxItems: 1
|
||||
vdd-supply: true
|
||||
|
||||
linux,keycodes:
|
||||
minItems: 1
|
||||
|
|
|
|||
|
|
@ -34,13 +34,13 @@ patternProperties:
|
|||
|
||||
linux,code:
|
||||
description: Key / Axis code to emit.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
linux,input-type:
|
||||
description:
|
||||
Specify event type this button/key generates. If not specified defaults to
|
||||
<1> == EV_KEY.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
default: 1
|
||||
|
||||
|
|
@ -56,12 +56,12 @@ patternProperties:
|
|||
|
||||
linux,input-value = <0xffffffff>; /* -1 */
|
||||
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
debounce-interval:
|
||||
description:
|
||||
Debouncing interval time in milliseconds. If not specified defaults to 5.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
default: 5
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ patternProperties:
|
|||
EV_ACT_ANY - both asserted and deasserted
|
||||
EV_ACT_ASSERTED - asserted
|
||||
EV_ACT_DEASSERTED - deasserted
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1, 2]
|
||||
|
||||
linux,can-disable:
|
||||
|
|
@ -118,7 +118,7 @@ then:
|
|||
poll-interval:
|
||||
description:
|
||||
Poll interval time in milliseconds
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- poll-interval
|
||||
|
|
|
|||
|
|
@ -55,8 +55,7 @@ properties:
|
|||
|
||||
wakeup-source: true
|
||||
|
||||
vcc-supply:
|
||||
maxItems: 1
|
||||
vcc-supply: true
|
||||
|
||||
gain:
|
||||
description: Allows setting the sensitivity in the range from 0 to 31.
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ properties:
|
|||
Specifies the list of CPU interrupt vectors to which the GIC may not
|
||||
route interrupts. This property is ignored if the CPU is started in EIC
|
||||
mode.
|
||||
$ref: /schemas/types.yaml#definitions/uint32-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 6
|
||||
uniqueItems: true
|
||||
|
|
@ -56,7 +56,7 @@ properties:
|
|||
It accepts two values: the 1st is the starting interrupt and the 2nd is
|
||||
the size of the reserved range. If not specified, the driver will
|
||||
allocate the last (2 * number of VPEs in the system).
|
||||
$ref: /schemas/types.yaml#definitions/uint32-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
items:
|
||||
- minimum: 0
|
||||
maximum: 254
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ properties:
|
|||
mapping is provided.
|
||||
|
||||
ti,irqs-reserved:
|
||||
$ref: /schemas/types.yaml#definitions/uint8
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: |
|
||||
Bitmask of host interrupts between 0 and 7 (corresponding to PRUSS INTC
|
||||
output interrupts 2 through 9) that are not connected to the Arm interrupt
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ properties:
|
|||
"limit" specifies the limit for translation
|
||||
|
||||
ti,unmapped-event-sources:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
Array of phandles to DMA controllers where the unmapped events originate.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ properties:
|
|||
The default brightness that should be applied to the LED by the operating
|
||||
system on start-up. The brightness should not exceed the brightness the
|
||||
LED can provide.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
max-brightness:
|
||||
description:
|
||||
|
|
@ -31,6 +31,6 @@ properties:
|
|||
on the brightness apart from what the driver says, as it could happen
|
||||
that a LED can be made so bright that it gets damaged or causes damage
|
||||
due to restrictions in a specific system, such as mounting conditions.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
additionalProperties: true
|
||||
|
|
|
|||
|
|
@ -27,21 +27,21 @@ properties:
|
|||
List of device current outputs the LED is connected to. The outputs are
|
||||
identified by the numbers that must be defined in the LED device binding
|
||||
documentation.
|
||||
$ref: /schemas/types.yaml#definitions/uint32-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
||||
function:
|
||||
description:
|
||||
LED function. Use one of the LED_FUNCTION_* prefixed definitions
|
||||
from the header include/dt-bindings/leds/common.h. If there is no
|
||||
matching LED_FUNCTION available, add a new one.
|
||||
$ref: /schemas/types.yaml#definitions/string
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
|
||||
color:
|
||||
description:
|
||||
Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from
|
||||
the header include/dt-bindings/leds/common.h. If there is no matching
|
||||
LED_COLOR_ID available, add a new one.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 9
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ properties:
|
|||
description:
|
||||
Integer to be used when more than one instance of the same function is
|
||||
needed, differing only with an ordinal number.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
label:
|
||||
description:
|
||||
|
|
@ -66,7 +66,7 @@ properties:
|
|||
produced where the LED momentarily turns off (or on). The "keep" setting
|
||||
will keep the LED at whatever its current state is, without producing a
|
||||
glitch.
|
||||
$ref: /schemas/types.yaml#definitions/string
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
enum:
|
||||
- on
|
||||
- off
|
||||
|
|
@ -77,7 +77,7 @@ properties:
|
|||
description:
|
||||
This parameter, if present, is a string defining the trigger assigned to
|
||||
the LED.
|
||||
$ref: /schemas/types.yaml#definitions/string
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
|
||||
enum:
|
||||
# LED will act as a back-light, controlled by the framebuffer system
|
||||
|
|
@ -109,7 +109,7 @@ properties:
|
|||
brightness and duration (in ms). The exact format is
|
||||
described in:
|
||||
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
|
||||
$ref: /schemas/types.yaml#definitions/uint32-matrix
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
items:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
|
@ -143,7 +143,7 @@ properties:
|
|||
the device tree and be referenced by a phandle and a set of phandle
|
||||
arguments. A length of arguments should be specified by the
|
||||
#trigger-source-cells property in the source node.
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
|
||||
# Required properties for flash LED child nodes:
|
||||
flash-max-microamp:
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ properties:
|
|||
description: I2C slave address
|
||||
|
||||
clock-mode:
|
||||
$ref: /schemas/types.yaml#definitions/uint8
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: |
|
||||
Input clock mode
|
||||
enum:
|
||||
|
|
@ -49,7 +49,7 @@ properties:
|
|||
GPIO attached to the chip's enable pin
|
||||
|
||||
pwr-sel:
|
||||
$ref: /schemas/types.yaml#definitions/uint8
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: |
|
||||
LP8501 specific property. Power selection for output channels.
|
||||
enum:
|
||||
|
|
@ -70,14 +70,14 @@ patternProperties:
|
|||
$ref: common.yaml#
|
||||
properties:
|
||||
led-cur:
|
||||
$ref: /schemas/types.yaml#definitions/uint8
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: |
|
||||
Current setting at each LED channel (mA x10, 0 if LED is not connected)
|
||||
minimum: 0
|
||||
maximum: 255
|
||||
|
||||
max-cur:
|
||||
$ref: /schemas/types.yaml#definitions/uint8
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: Maximun current at each LED channel.
|
||||
|
||||
reg:
|
||||
|
|
@ -97,7 +97,7 @@ patternProperties:
|
|||
- 8 # LED output D9
|
||||
|
||||
chan-name:
|
||||
$ref: /schemas/types.yaml#definitions/string
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description: name of channel
|
||||
|
||||
required:
|
||||
|
|
|
|||
|
|
@ -61,7 +61,6 @@ properties:
|
|||
- description: low-priority non-secure
|
||||
- description: high-priority non-secure
|
||||
- description: Secure
|
||||
maxItems: 3
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -44,6 +44,21 @@ properties:
|
|||
- const: per
|
||||
- const: ahb
|
||||
|
||||
interrupts:
|
||||
minItems: 1
|
||||
items:
|
||||
- description: BIT processor interrupt
|
||||
- description: JPEG unit interrupt
|
||||
|
||||
interrupt-names:
|
||||
minItems: 1
|
||||
items:
|
||||
- const: bit
|
||||
- const: jpeg
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
|
|
@ -59,6 +74,8 @@ required:
|
|||
- clocks
|
||||
- clock-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
|
|
@ -68,34 +85,17 @@ allOf:
|
|||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
items:
|
||||
- description: BIT processor interrupt
|
||||
- description: JPEG unit interrupt
|
||||
minItems: 2
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: bit
|
||||
- const: jpeg
|
||||
minItems: 2
|
||||
else:
|
||||
properties:
|
||||
interrupts:
|
||||
items:
|
||||
- description: BIT processor interrupt
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,imx6dl-vpu
|
||||
- fsl,imx6q-vpu
|
||||
then:
|
||||
properties:
|
||||
power-domains:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle pointing to the PU power domain
|
||||
maxItems: 1
|
||||
|
||||
power-domains: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
vpu: video-codec@63ff4000 {
|
||||
|
|
|
|||
|
|
@ -40,7 +40,6 @@ properties:
|
|||
|
||||
poc-supply:
|
||||
description: Regulator providing Power over Coax to the cameras
|
||||
maxItems: 1
|
||||
|
||||
enable-gpios:
|
||||
description: GPIO connected to the \#PWDN pin with inverted polarity
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2014--2020 Intel Corporation
|
||||
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/mipi-ccs.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
|
|
@ -26,11 +27,11 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mipi-ccs-1.1
|
||||
- const: mipi-ccs
|
||||
- const: mipi-ccs-1.1
|
||||
- const: mipi-ccs
|
||||
- items:
|
||||
- const: mipi-ccs-1.0
|
||||
- const: mipi-ccs
|
||||
- const: mipi-ccs-1.0
|
||||
- const: mipi-ccs
|
||||
- const: nokia,smia
|
||||
|
||||
reg:
|
||||
|
|
@ -38,15 +39,12 @@ properties:
|
|||
|
||||
vana-supply:
|
||||
description: Analogue voltage supply (VANA), sensor dependent.
|
||||
maxItems: 1
|
||||
|
||||
vcore-supply:
|
||||
description: Core voltage supply (VCore), sensor dependent.
|
||||
maxItems: 1
|
||||
|
||||
vio-supply:
|
||||
description: I/O voltage supply (VIO), sensor dependent.
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
description: External clock to the sensor.
|
||||
|
|
|
|||
|
|
@ -37,15 +37,12 @@ properties:
|
|||
|
||||
vdddo-supply:
|
||||
description: Chip digital IO regulator (1.8V).
|
||||
maxItems: 1
|
||||
|
||||
vdda-supply:
|
||||
description: Chip analog regulator (2.7V).
|
||||
maxItems: 1
|
||||
|
||||
vddd-supply:
|
||||
description: Chip digital core regulator (1.12V).
|
||||
maxItems: 1
|
||||
|
||||
flash-leds:
|
||||
description: See ../video-interfaces.txt
|
||||
|
|
|
|||
|
|
@ -33,15 +33,12 @@ properties:
|
|||
|
||||
vana-supply:
|
||||
description: Sensor 2.8 V analog supply.
|
||||
maxItems: 1
|
||||
|
||||
vdig-supply:
|
||||
description: Sensor 1.8 V digital core supply.
|
||||
maxItems: 1
|
||||
|
||||
vddl-supply:
|
||||
description: Sensor digital IO 1.2 V supply.
|
||||
maxItems: 1
|
||||
|
||||
port:
|
||||
type: object
|
||||
|
|
|
|||
|
|
@ -26,8 +26,7 @@ properties:
|
|||
|
||||
drive-open-drain: true
|
||||
|
||||
vdd-supply:
|
||||
maxItems: 1
|
||||
vdd-supply: true
|
||||
|
||||
pinctrl:
|
||||
type: object
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ properties:
|
|||
const: stmmaceth
|
||||
|
||||
syscon:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the device containing the EMAC or GMAC clock
|
||||
register
|
||||
|
|
@ -114,7 +114,7 @@ allOf:
|
|||
then:
|
||||
properties:
|
||||
allwinner,leds-active-low:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
EPHY LEDs are active low.
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ allOf:
|
|||
const: allwinner,sun8i-h3-mdio-mux
|
||||
|
||||
mdio-parent-bus:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to EMAC MDIO.
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ allOf:
|
|||
- const: timing-adjustment
|
||||
|
||||
amlogic,tx-delay-ns:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
The internal RGMII TX clock delay (provided by this driver) in
|
||||
nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ patternProperties:
|
|||
description:
|
||||
Describes the label associated with this port, which will become
|
||||
the netdev name
|
||||
$ref: /schemas/types.yaml#definitions/string
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
|
||||
link:
|
||||
description:
|
||||
|
|
@ -62,13 +62,13 @@ patternProperties:
|
|||
port is used as the outgoing port towards the phandle ports. The
|
||||
full routing information must be given, not just the one hop
|
||||
routes to neighbouring switches
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
|
||||
ethernet:
|
||||
description:
|
||||
Should be a phandle to a valid Ethernet device node. This host
|
||||
device is what the switch port is connected to
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
phy-handle: true
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ properties:
|
|||
local-mac-address:
|
||||
description:
|
||||
Specifies the MAC address that was assigned to the network device.
|
||||
$ref: /schemas/types.yaml#definitions/uint8-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
items:
|
||||
- minItems: 6
|
||||
maxItems: 6
|
||||
|
|
@ -27,20 +27,20 @@ properties:
|
|||
program; should be used in cases where the MAC address assigned
|
||||
to the device by the boot program is different from the
|
||||
local-mac-address property.
|
||||
$ref: /schemas/types.yaml#definitions/uint8-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
items:
|
||||
- minItems: 6
|
||||
maxItems: 6
|
||||
|
||||
max-frame-size:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Maximum transfer unit (IEEE defined MTU), rather than the
|
||||
maximum frame size (there\'s contradiction in the Devicetree
|
||||
Specification).
|
||||
|
||||
max-speed:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Specifies maximum speed in Mbit/s supported by the device.
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ properties:
|
|||
$ref: "#/properties/phy-connection-type"
|
||||
|
||||
phy-handle:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Specifies a reference to a node representing a PHY device.
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ properties:
|
|||
deprecated: true
|
||||
|
||||
rx-fifo-depth:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
The size of the controller\'s receive fifo in bytes. This is used
|
||||
for components that can have configurable receive fifo sizes,
|
||||
|
|
@ -129,12 +129,12 @@ properties:
|
|||
If this property is present then the MAC applies the RX delay.
|
||||
|
||||
sfp:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Specifies a reference to a node representing a SFP cage.
|
||||
|
||||
tx-fifo-depth:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
The size of the controller\'s transmit fifo in bytes. This
|
||||
is used for components that can have configurable fifo sizes.
|
||||
|
|
@ -150,7 +150,7 @@ properties:
|
|||
description:
|
||||
Specifies the PHY management type. If auto is set and fixed-link
|
||||
is not specified, it uses MDIO for management.
|
||||
$ref: /schemas/types.yaml#definitions/string
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
default: auto
|
||||
enum:
|
||||
- auto
|
||||
|
|
@ -198,17 +198,17 @@ properties:
|
|||
speed:
|
||||
description:
|
||||
Link speed.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [10, 100, 1000]
|
||||
|
||||
full-duplex:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Indicates that full-duplex is used. When absent, half
|
||||
duplex is assumed.
|
||||
|
||||
asym-pause:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Indicates that asym_pause should be enabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -78,57 +78,57 @@ properties:
|
|||
Maximum PHY supported speed in Mbits / seconds.
|
||||
|
||||
broken-turn-around:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
If set, indicates the PHY device does not correctly release
|
||||
the turn around line low at end of the control phase of the
|
||||
MDIO transaction.
|
||||
|
||||
enet-phy-lane-swap:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
If set, indicates the PHY will swap the TX/RX lanes to
|
||||
compensate for the board being designed with the lanes
|
||||
swapped.
|
||||
|
||||
eee-broken-100tx:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the corresponding energy efficient ethernet mode as
|
||||
broken and request the ethernet to stop advertising it.
|
||||
|
||||
eee-broken-1000t:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the corresponding energy efficient ethernet mode as
|
||||
broken and request the ethernet to stop advertising it.
|
||||
|
||||
eee-broken-10gt:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the corresponding energy efficient ethernet mode as
|
||||
broken and request the ethernet to stop advertising it.
|
||||
|
||||
eee-broken-1000kx:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the corresponding energy efficient ethernet mode as
|
||||
broken and request the ethernet to stop advertising it.
|
||||
|
||||
eee-broken-10gkx4:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the corresponding energy efficient ethernet mode as
|
||||
broken and request the ethernet to stop advertising it.
|
||||
|
||||
eee-broken-10gkr:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the corresponding energy efficient ethernet mode as
|
||||
broken and request the ethernet to stop advertising it.
|
||||
|
||||
phy-is-integrated:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
If set, indicates that the PHY is integrated into the same
|
||||
physical package as the Ethernet MAC. If needed, muxers
|
||||
|
|
@ -158,7 +158,7 @@ properties:
|
|||
this property is missing the delay will be skipped.
|
||||
|
||||
sfp:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Specifies a reference to a node representing a SFP cage.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ properties:
|
|||
phy-mode: true
|
||||
|
||||
pcs-handle:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
A reference to a node representing a PCS PHY device found on
|
||||
the internal MDIO bus.
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ patternProperties:
|
|||
The ID number for the device.
|
||||
|
||||
broken-turn-around:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
If set, indicates the MDIO device does not correctly release
|
||||
the turn around line low at end of the control phase of the
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ properties:
|
|||
- const: trans
|
||||
|
||||
mediatek,pericfg:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the device containing the PERICFG register range. This is used
|
||||
to control the MII mode.
|
||||
|
|
|
|||
|
|
@ -114,14 +114,13 @@ properties:
|
|||
validating firwmare used by the GSI.
|
||||
|
||||
modem-remoteproc:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
This defines the phandle to the remoteproc node representing
|
||||
the modem subsystem. This is requied so the IPA driver can
|
||||
receive and act on notifications of modem up/down events.
|
||||
|
||||
memory-region:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
maxItems: 1
|
||||
description:
|
||||
If present, a phandle for a reserved memory area that holds
|
||||
|
|
|
|||
|
|
@ -163,6 +163,7 @@ allOf:
|
|||
enum:
|
||||
- renesas,etheravb-r8a774a1
|
||||
- renesas,etheravb-r8a774b1
|
||||
- renesas,etheravb-r8a774e1
|
||||
- renesas,etheravb-r8a7795
|
||||
- renesas,etheravb-r8a7796
|
||||
- renesas,etheravb-r8a77961
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ properties:
|
|||
in a different mode than the PHY in order to function.
|
||||
|
||||
snps,axi-config:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
AXI BUS Mode parameters. Phandle to a node that can contain the
|
||||
following properties
|
||||
|
|
@ -141,7 +141,7 @@ properties:
|
|||
* snps,rb, rebuild INCRx Burst
|
||||
|
||||
snps,mtl-rx-config:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Multiple RX Queues parameters. Phandle to a node that can
|
||||
contain the following properties
|
||||
|
|
@ -161,10 +161,11 @@ properties:
|
|||
* snps,route-dcbcp, DCB Control Packets
|
||||
* snps,route-up, Untagged Packets
|
||||
* snps,route-multi-broad, Multicast & Broadcast Packets
|
||||
* snps,priority, RX queue priority (Range 0x0 to 0xF)
|
||||
* snps,priority, bitmask of the tagged frames priorities assigned to
|
||||
the queue
|
||||
|
||||
snps,mtl-tx-config:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Multiple TX Queues parameters. Phandle to a node that can
|
||||
contain the following properties
|
||||
|
|
@ -188,7 +189,10 @@ properties:
|
|||
* snps,idle_slope, unlock on WoL
|
||||
* snps,high_credit, max write outstanding req. limit
|
||||
* snps,low_credit, max read outstanding req. limit
|
||||
* snps,priority, TX queue priority (Range 0x0 to 0xF)
|
||||
* snps,priority, bitmask of the priorities assigned to the queue.
|
||||
When a PFC frame is received with priorities matching the bitmask,
|
||||
the queue is blocked from transmitting for the pause time specified
|
||||
in the PFC frame.
|
||||
|
||||
snps,reset-gpio:
|
||||
deprecated: true
|
||||
|
|
@ -198,7 +202,7 @@ properties:
|
|||
|
||||
snps,reset-active-low:
|
||||
deprecated: true
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Indicates that the PHY Reset is active low
|
||||
|
||||
|
|
@ -208,55 +212,55 @@ properties:
|
|||
Triplet of delays. The 1st cell is reset pre-delay in micro
|
||||
seconds. The 2nd cell is reset pulse in micro seconds. The 3rd
|
||||
cell is reset post-delay in micro seconds.
|
||||
$ref: /schemas/types.yaml#definitions/uint32-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
|
||||
snps,aal:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Use Address-Aligned Beats
|
||||
|
||||
snps,fixed-burst:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Program the DMA to use the fixed burst mode
|
||||
|
||||
snps,mixed-burst:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Program the DMA to use the mixed burst mode
|
||||
|
||||
snps,force_thresh_dma_mode:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Force DMA to use the threshold mode for both tx and rx
|
||||
|
||||
snps,force_sf_dma_mode:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Force DMA to use the Store and Forward mode for both tx and
|
||||
rx. This flag is ignored if force_thresh_dma_mode is set.
|
||||
|
||||
snps,en-tx-lpi-clockgating:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Enable gating of the MAC TX clock during TX low-power mode
|
||||
|
||||
snps,multicast-filter-bins:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Number of multicast filter hash bins supported by this device
|
||||
instance
|
||||
|
||||
snps,perfect-filter-entries:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Number of perfect filter entries supported by this device
|
||||
instance
|
||||
|
||||
snps,ps-speed:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Port selection speed that can be passed to the core when PCS
|
||||
is supported. For example, this is used in case of SGMII and
|
||||
|
|
@ -307,25 +311,25 @@ allOf:
|
|||
snps,pbl:
|
||||
description:
|
||||
Programmable Burst Length (tx and rx)
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [2, 4, 8]
|
||||
|
||||
snps,txpbl:
|
||||
description:
|
||||
Tx Programmable Burst Length. If set, DMA tx will use this
|
||||
value rather than snps,pbl.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [2, 4, 8]
|
||||
|
||||
snps,rxpbl:
|
||||
description:
|
||||
Rx Programmable Burst Length. If set, DMA rx will use this
|
||||
value rather than snps,pbl.
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [2, 4, 8]
|
||||
|
||||
snps,no-pbl-x8:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
|
||||
rev < 3.50, don\'t multiply the values by 4.
|
||||
|
|
@ -351,7 +355,7 @@ allOf:
|
|||
then:
|
||||
properties:
|
||||
snps,tso:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Enables the TSO feature otherwise it will be managed by
|
||||
MAC HW capability register.
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ properties:
|
|||
- const: ether # for others
|
||||
|
||||
socionext,syscon-phy-mode:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
A phandle to syscon with one argument that configures phy mode.
|
||||
The argument is the ID of MAC instance.
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ properties:
|
|||
pinctrl-names: true
|
||||
|
||||
syscon:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the system control device node which provides access to
|
||||
efuse IO range with MAC addresses
|
||||
|
|
|
|||
|
|
@ -47,31 +47,31 @@ properties:
|
|||
takes precedence.
|
||||
|
||||
tx-fifo-depth:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Transmitt FIFO depth see dt-bindings/net/ti-dp83867.h for values
|
||||
|
||||
rx-fifo-depth:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Receive FIFO depth see dt-bindings/net/ti-dp83867.h for values
|
||||
|
||||
ti,clk-output-sel:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h
|
||||
for applicable values. The CLK_OUT pin can also be disabled by this
|
||||
property. When omitted, the PHY's default will be left as is.
|
||||
|
||||
ti,rx-internal-delay:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h
|
||||
for applicable values. Required only if interface type is
|
||||
PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID.
|
||||
|
||||
ti,tx-internal-delay:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h
|
||||
for applicable values. Required only if interface type is
|
||||
|
|
@ -101,7 +101,7 @@ properties:
|
|||
|
||||
ti,fifo-depth:
|
||||
deprecated: true
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable
|
||||
values.
|
||||
|
|
|
|||
|
|
@ -44,22 +44,22 @@ properties:
|
|||
to a maximum value (70 ohms).
|
||||
|
||||
tx-fifo-depth:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Transmitt FIFO depth see dt-bindings/net/ti-dp83869.h for values
|
||||
|
||||
rx-fifo-depth:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Receive FIFO depth see dt-bindings/net/ti-dp83869.h for values
|
||||
|
||||
ti,clk-output-sel:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Muxing option for CLK_OUT pin see dt-bindings/net/ti-dp83869.h for values.
|
||||
|
||||
ti,op-mode:
|
||||
$ref: /schemas/types.yaml#definitions/uint32
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Operational mode for the PHY. If this is not set then the operational
|
||||
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
|
||||
|
|
|
|||
|
|
@ -119,12 +119,12 @@ properties:
|
|||
description: label associated with this port
|
||||
|
||||
ti,mac-only:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Specifies the port works in mac-only mode.
|
||||
|
||||
ti,syscon-efuse:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
Phandle to the system control device node which provides access
|
||||
to efuse IO range with MAC addresses
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ properties:
|
|||
- const: tcl2host-status-ring
|
||||
|
||||
qcom,rproc:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
DT entry of q6v5-wcss remoteproc driver.
|
||||
Phandle to a node that can contain the following properties
|
||||
|
|
|
|||
|
|
@ -44,13 +44,13 @@ properties:
|
|||
- const: refclk
|
||||
|
||||
syscon-phy-power:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
phandle/offset pair. Phandle to the system control module and
|
||||
register offset to power on/off the PHY.
|
||||
|
||||
ctrl-module:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
(deprecated) phandle of the control module used by PHY driver
|
||||
to power on the PHY. Use syscon-phy-power instead.
|
||||
|
|
|
|||
|
|
@ -83,11 +83,11 @@ patternProperties:
|
|||
SUSBSYS clocks.
|
||||
|
||||
mediatek,infracfg:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the device containing the INFRACFG register range.
|
||||
|
||||
mediatek,smi:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the device containing the SMI register range.
|
||||
|
||||
patternProperties:
|
||||
|
|
@ -131,11 +131,11 @@ patternProperties:
|
|||
SUSBSYS clocks.
|
||||
|
||||
mediatek,infracfg:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the device containing the INFRACFG register range.
|
||||
|
||||
mediatek,smi:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the device containing the SMI register range.
|
||||
|
||||
patternProperties:
|
||||
|
|
@ -179,11 +179,11 @@ patternProperties:
|
|||
SUSBSYS clocks.
|
||||
|
||||
mediatek,infracfg:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the device containing the INFRACFG register range.
|
||||
|
||||
mediatek,smi:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: phandle to the device containing the SMI register range.
|
||||
|
||||
required:
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ properties:
|
|||
of this binary blob is kept secret by CellWise. The only way to obtain
|
||||
it is to mail two batteries to a test facility of CellWise and receive
|
||||
back a test report with the binary blob.
|
||||
$ref: /schemas/types.yaml#definitions/uint8-array
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
minItems: 64
|
||||
maxItems: 64
|
||||
|
||||
|
|
|
|||
|
|
@ -42,6 +42,6 @@ select: true
|
|||
|
||||
properties:
|
||||
sleep:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
|
||||
additionalProperties: true
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue