Merge wireless into wireless-next

Resolve several conflicts, mostly between changes/fixes in
wireless and the locking rework in wireless-next. One of
the conflicts actually shows a bug in wireless that we'll
want to fix separately.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
This commit is contained in:
Johannes Berg 2023-10-05 22:57:34 +02:00 committed by Kalle Valo
commit 7d6904bf26
2222 changed files with 66244 additions and 37810 deletions

View File

@ -0,0 +1,61 @@
What: /sys/kernel/debug/qat_<device>_<BDF>/qat/fw_counters
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
Description: (RO) Read returns the number of requests sent to the FW and the number of responses
received from the FW for each Acceleration Engine
Reported firmware counters::
<N>: Number of requests sent from Acceleration Engine N to FW and responses
Acceleration Engine N received from FW
What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/config
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
Description: (RW) Read returns value of the Heartbeat update period.
Write to the file changes this period value.
This period should reflect planned polling interval of device
health status. High frequency Heartbeat monitoring wastes CPU cycles
but minimizes the customers system downtime. Also, if there are
large service requests that take some time to complete, high frequency
Heartbeat monitoring could result in false reports of unresponsiveness
and in those cases, period needs to be increased.
This parameter is effective only for c3xxx, c62x, dh895xcc devices.
4xxx has this value internally fixed to 200ms.
Default value is set to 500. Minimal allowed value is 200.
All values are expressed in milliseconds.
What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_failed
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
Description: (RO) Read returns the number of times the device became unresponsive.
Attribute returns value of the counter which is incremented when
status query results negative.
What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_sent
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
Description: (RO) Read returns the number of times the control process checked
if the device is responsive.
Attribute returns value of the counter which is incremented on
every status query.
What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/status
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
Description: (RO) Read returns the device health status.
Returns 0 when device is healthy or -1 when is unresponsive
or the query failed to send.
The driver does not monitor for Heartbeat. It is left for a user
to poll the status periodically.

View File

@ -556,6 +556,7 @@ Description: Control Symmetric Multi Threading (SMT)
================ =========================================
"on" SMT is enabled
"off" SMT is disabled
"<N>" SMT is enabled with N threads per core.
"forceoff" SMT is force disabled. Cannot be changed.
"notsupported" SMT is not supported by the CPU
"notimplemented" SMT runtime toggling is not

View File

@ -85,3 +85,21 @@ Description:
Possible values:
0: Not enforced
1: Enforced
What: /sys/bus/pci/devices/<BDF>/bootloader_version
Date: June 2023
KernelVersion: 6.4
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/bootloader_version
file reports the firmware version of the AMD AGESA
bootloader.
What: /sys/bus/pci/devices/<BDF>/tee_version
Date: June 2023
KernelVersion: 6.4
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/tee_version
file reports the firmware version of the AMD Trusted
Execution Environment (TEE).

View File

@ -1,4 +1,5 @@
What: /sys/bus/platform/devices/GGL0001:*/BINF.2
/sys/bus/platform/devices/GOOG0016:*/BINF.2
Date: May 2022
KernelVersion: 5.19
Description:
@ -10,6 +11,7 @@ Description:
== ===============================
What: /sys/bus/platform/devices/GGL0001:*/BINF.3
/sys/bus/platform/devices/GOOG0016:*/BINF.3
Date: May 2022
KernelVersion: 5.19
Description:
@ -23,6 +25,7 @@ Description:
== =====================================
What: /sys/bus/platform/devices/GGL0001:*/CHSW
/sys/bus/platform/devices/GOOG0016:*/CHSW
Date: May 2022
KernelVersion: 5.19
Description:
@ -38,6 +41,7 @@ Description:
==== ===========================================
What: /sys/bus/platform/devices/GGL0001:*/FMAP
/sys/bus/platform/devices/GOOG0016:*/FMAP
Date: May 2022
KernelVersion: 5.19
Description:
@ -45,6 +49,7 @@ Description:
processor firmware flashmap.
What: /sys/bus/platform/devices/GGL0001:*/FRID
/sys/bus/platform/devices/GOOG0016:*/FRID
Date: May 2022
KernelVersion: 5.19
Description:
@ -52,6 +57,7 @@ Description:
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/FWID
/sys/bus/platform/devices/GOOG0016:*/FWID
Date: May 2022
KernelVersion: 5.19
Description:
@ -59,6 +65,7 @@ Description:
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0
/sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.0
Date: May 2022
KernelVersion: 5.19
Description:
@ -73,6 +80,7 @@ Description:
=========== ==================================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1
/sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.1
Date: May 2022
KernelVersion: 5.19
Description:
@ -84,6 +92,7 @@ Description:
== =======================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2
/sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.2
Date: May 2022
KernelVersion: 5.19
Description:
@ -91,18 +100,21 @@ Description:
controller.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3
/sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns name of the GPIO controller.
What: /sys/bus/platform/devices/GGL0001:*/HWID
/sys/bus/platform/devices/GOOG0016:*/HWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns hardware ID for the Chromebook.
What: /sys/bus/platform/devices/GGL0001:*/MECK
/sys/bus/platform/devices/GOOG0016:*/MECK
Date: May 2022
KernelVersion: 5.19
Description:
@ -113,6 +125,7 @@ Description:
present, or if the firmware was unable to read the extended registers, this buffer size can be zero.
What: /sys/bus/platform/devices/GGL0001:*/VBNV.0
/sys/bus/platform/devices/GOOG0016:*/VBNV.0
Date: May 2022
KernelVersion: 5.19
Description:
@ -122,6 +135,7 @@ Description:
clock data).
What: /sys/bus/platform/devices/GGL0001:*/VBNV.1
/sys/bus/platform/devices/GOOG0016:*/VBNV.1
Date: May 2022
KernelVersion: 5.19
Description:
@ -129,9 +143,10 @@ Description:
storage block.
What: /sys/bus/platform/devices/GGL0001:*/VDAT
/sys/bus/platform/devices/GOOG0016:*/VDAT
Date: May 2022
KernelVersion: 5.19
Description:
Returns the verified boot data block shared between the
firmware verification step and the kernel verification step
(binary).
(hex dump).

View File

@ -0,0 +1,12 @@
What: /sys/devices/platform/.../power_on_reason
Date: June 2023
KernelVersion: 6.5
Contact: Kamel Bouhara <kamel.bouhara@bootlin.com>
Description: Shows system power on reason. The following strings/reasons can
be read (the list can be extended):
"regular power-up", "RTC wakeup", "watchdog timeout",
"software reset", "reset button action", "CPU clock failure",
"crystal oscillator failure", "brown-out reset",
"unknown reason".
The file is read only.

View File

@ -10,7 +10,7 @@ misuses of the RCU API, most notably using one of the rcu_dereference()
family to access an RCU-protected pointer without the proper protection.
When such misuse is detected, an lockdep-RCU splat is emitted.
The usual cause of a lockdep-RCU slat is someone accessing an
The usual cause of a lockdep-RCU splat is someone accessing an
RCU-protected data structure without either (1) being in the right kind of
RCU read-side critical section or (2) holding the right update-side lock.
This problem can therefore be serious: it might result in random memory

View File

@ -18,7 +18,16 @@ to solve following problem.
Without 'nulls', a typical RCU linked list managing objects which are
allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following
algorithms:
algorithms. Following examples assume 'obj' is a pointer to such
objects, which is having below type.
::
struct object {
struct hlist_node obj_node;
atomic_t refcnt;
unsigned int key;
};
1) Lookup algorithm
-------------------
@ -26,11 +35,13 @@ algorithms:
::
begin:
rcu_read_lock()
rcu_read_lock();
obj = lockless_lookup(key);
if (obj) {
if (!try_get_ref(obj)) // might fail for free objects
if (!try_get_ref(obj)) { // might fail for free objects
rcu_read_unlock();
goto begin;
}
/*
* Because a writer could delete object, and a writer could
* reuse these object before the RCU grace period, we
@ -54,7 +65,7 @@ but a version with an additional memory barrier (smp_rmb())
struct hlist_node *node, *next;
for (pos = rcu_dereference((head)->first);
pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
pos = rcu_dereference(next))
if (obj->key == key)
return obj;
@ -66,10 +77,10 @@ And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb()::
struct hlist_node *node;
for (pos = rcu_dereference((head)->first);
pos && ({ prefetch(pos->next); 1; }) &&
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
pos = rcu_dereference(pos->next))
if (obj->key == key)
return obj;
if (obj->key == key)
return obj;
return NULL;
Quoting Corey Minyard::
@ -86,7 +97,7 @@ Quoting Corey Minyard::
2) Insertion algorithm
----------------------
We need to make sure a reader cannot read the new 'obj->obj_next' value
We need to make sure a reader cannot read the new 'obj->obj_node.next' value
and previous value of 'obj->key'. Otherwise, an item could be deleted
from a chain, and inserted into another chain. If new chain was empty
before the move, 'next' pointer is NULL, and lockless reader can not
@ -129,8 +140,7 @@ very very fast (before the end of RCU grace period)
Avoiding extra smp_rmb()
========================
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
and extra _release() in insert function.
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup().
For example, if we choose to store the slot number as the 'nulls'
end-of-list marker for each slot of the hash table, we can detect
@ -142,6 +152,9 @@ the beginning. If the object was moved to the same chain,
then the reader doesn't care: It might occasionally
scan the list again without harm.
Note that using hlist_nulls means the type of 'obj_node' field of
'struct object' becomes 'struct hlist_nulls_node'.
1) lookup algorithm
-------------------
@ -151,7 +164,7 @@ scan the list again without harm.
head = &table[slot];
begin:
rcu_read_lock();
hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
hlist_nulls_for_each_entry_rcu(obj, node, head, obj_node) {
if (obj->key == key) {
if (!try_get_ref(obj)) { // might fail for free objects
rcu_read_unlock();
@ -182,6 +195,9 @@ scan the list again without harm.
2) Insert algorithm
-------------------
Same to the above one, but uses hlist_nulls_add_head_rcu() instead of
hlist_add_head_rcu().
::
/*

View File

@ -553,7 +553,7 @@
others).
ccw_timeout_log [S390]
See Documentation/s390/common_io.rst for details.
See Documentation/arch/s390/common_io.rst for details.
cgroup_disable= [KNL] Disable a particular controller or optional feature
Format: {name of the controller(s) or feature(s) to disable}
@ -598,7 +598,7 @@
Setting checkreqprot to 1 is deprecated.
cio_ignore= [S390]
See Documentation/s390/common_io.rst for details.
See Documentation/arch/s390/common_io.rst for details.
clearcpuid=X[,X...] [X86]
Disable CPUID feature X for the kernel. See
@ -2938,6 +2938,10 @@
locktorture.torture_type= [KNL]
Specify the locking implementation to test.
locktorture.writer_fifo= [KNL]
Run the write-side locktorture kthreads at
sched_set_fifo() real-time priority.
locktorture.verbose= [KNL]
Enable additional printk() statements.
@ -4949,6 +4953,15 @@
test until boot completes in order to avoid
interference.
rcuscale.kfree_by_call_rcu= [KNL]
In kernels built with CONFIG_RCU_LAZY=y, test
call_rcu() instead of kfree_rcu().
rcuscale.kfree_mult= [KNL]
Instead of allocating an object of size kfree_obj,
allocate one of kfree_mult * sizeof(kfree_obj).
Defaults to 1.
rcuscale.kfree_rcu_test= [KNL]
Set to measure performance of kfree_rcu() flooding.
@ -4974,6 +4987,12 @@
Number of loops doing rcuscale.kfree_alloc_num number
of allocations and frees.
rcuscale.minruntime= [KNL]
Set the minimum test run time in seconds. This
does not affect the data-collection interval,
but instead allows better measurement of things
like CPU consumption.
rcuscale.nreaders= [KNL]
Set number of RCU readers. The value -1 selects
N, where N is the number of CPUs. A value
@ -4988,7 +5007,7 @@
the same as for rcuscale.nreaders.
N, where N is the number of CPUs
rcuscale.perf_type= [KNL]
rcuscale.scale_type= [KNL]
Specify the RCU implementation to test.
rcuscale.shutdown= [KNL]
@ -5004,6 +5023,11 @@
in microseconds. The default of zero says
no holdoff.
rcuscale.writer_holdoff_jiffies= [KNL]
Additional write-side holdoff between grace
periods, but in jiffies. The default of zero
says no holdoff.
rcutorture.fqs_duration= [KNL]
Set duration of force_quiescent_state bursts
in microseconds.
@ -5285,6 +5309,13 @@
number avoids disturbing real-time workloads,
but lengthens grace periods.
rcupdate.rcu_task_lazy_lim= [KNL]
Number of callbacks on a given CPU that will
cancel laziness on that CPU. Use -1 to disable
cancellation of laziness, but be advised that
doing so increases the danger of OOM due to
callback flooding.
rcupdate.rcu_task_stall_info= [KNL]
Set initial timeout in jiffies for RCU task stall
informational messages, which give some indication
@ -5314,6 +5345,29 @@
A change in value does not take effect until
the beginning of the next grace period.
rcupdate.rcu_tasks_lazy_ms= [KNL]
Set timeout in milliseconds RCU Tasks asynchronous
callback batching for call_rcu_tasks().
A negative value will take the default. A value
of zero will disable batching. Batching is
always disabled for synchronize_rcu_tasks().
rcupdate.rcu_tasks_rude_lazy_ms= [KNL]
Set timeout in milliseconds RCU Tasks
Rude asynchronous callback batching for
call_rcu_tasks_rude(). A negative value
will take the default. A value of zero will
disable batching. Batching is always disabled
for synchronize_rcu_tasks_rude().
rcupdate.rcu_tasks_trace_lazy_ms= [KNL]
Set timeout in milliseconds RCU Tasks
Trace asynchronous callback batching for
call_rcu_tasks_trace(). A negative value
will take the default. A value of zero will
disable batching. Batching is always disabled
for synchronize_rcu_tasks_trace().
rcupdate.rcu_self_test= [KNL]
Run the RCU early boot self tests
@ -5522,6 +5576,10 @@
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
rootwait= [KNL] Maximum time (in seconds) to wait for root device
to show up before attempting to mount the root
filesystem.
rproc_mem=nn[KMG][@address]
[KNL,ARM,CMA] Remoteproc physical memory block.
Memory area to be used by remote processor image,
@ -6275,10 +6333,6 @@
-1: disable all critical trip points in all thermal zones
<degrees C>: override all critical trip points
thermal.nocrt= [HW,ACPI]
Set to disable actions on ACPI thermal zone
critical and hot trip points.
thermal.off= [HW,ACPI]
1: disable ACPI thermal control
@ -6340,6 +6394,13 @@
This will guarantee that all the other pcrs
are saved.
tpm_tis.interrupts= [HW,TPM]
Enable interrupts for the MMIO based physical layer
for the FIFO interface. By default it is set to false
(0). For more information about TPM hardware interfaces
defined by Trusted Computing Group (TCG) see
https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
tp_printk [FTRACE]
Have the tracepoints sent to printk as well as the
tracing ring buffer. This is useful for early boot up

View File

@ -63,6 +63,14 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
@ -109,14 +117,6 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
@ -198,6 +198,9 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A |
| | Hip09 SMMU PMCG | | |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+----------------+-----------------+-----------------+-----------------------------+

View File

@ -322,7 +322,7 @@ The regset data starts with struct user_za_header, containing:
VL is supported.
* The size and layout of the payload depends on the header fields. The
SME_PT_ZA_*() macros are provided to facilitate access to the data.
ZA_PT_ZA*() macros are provided to facilitate access to the data.
* In either case, for SETREGSET it is permissible to omit the payload, in which
case the vector length and flags are changed and PSTATE.ZA is set to 0

View File

@ -21,7 +21,7 @@ implementation.
parisc/index
../powerpc/index
../riscv/index
../s390/index
s390/index
sh/index
sparc/index
x86/index

View File

@ -116,7 +116,7 @@ Here are the installation steps in detail:
as a 3270, not a 3215.
5. Run the 3270 configuration script config3270. It is
distributed in this same directory, Documentation/s390, as
distributed in this same directory, Documentation/arch/s390, as
config3270.sh. Inspect the output script it produces,
/tmp/mkdev3270, and then run that script. This will create the
necessary character special device files and make the necessary
@ -125,7 +125,7 @@ Here are the installation steps in detail:
Then notify /sbin/init that /etc/inittab has changed, by issuing
the telinit command with the q operand::
cd Documentation/s390
cd Documentation/arch/s390
sh config3270.sh
sh /tmp/mkdev3270
telinit q

View File

@ -39,7 +39,7 @@ some of them are ESA/390 platform specific.
Note:
In order to write a driver for S/390, you also need to look into the interface
described in Documentation/s390/driver-model.rst.
described in Documentation/arch/s390/driver-model.rst.
Note for porting drivers from 2.4:

View File

@ -136,5 +136,5 @@ debugfs entries
The level of logging can be changed to be more or less verbose by piping to
/sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
documentation on the S/390 debug feature (Documentation/s390/s390dbf.rst)
documentation on the S/390 debug feature (Documentation/arch/s390/s390dbf.rst)
for details.

View File

@ -40,7 +40,7 @@ For example:
Change the level of logging to be more or less verbose by piping
a number between 0 and 6 to /sys/kernel/debug/s390dbf/pci_*/level. For
details, see the documentation on the S/390 debug feature at
Documentation/s390/s390dbf.rst.
Documentation/arch/s390/s390dbf.rst.
Sysfs entries
=============

View File

@ -440,6 +440,6 @@ Reference
1. ESA/s390 Principles of Operation manual (IBM Form. No. SA22-7832)
2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204)
3. https://en.wikipedia.org/wiki/Channel_I/O
4. Documentation/s390/cds.rst
4. Documentation/arch/s390/cds.rst
5. Documentation/driver-api/vfio.rst
6. Documentation/driver-api/vfio-mediated-device.rst

View File

@ -1417,7 +1417,7 @@ execution context provided by the EFI firmware.
The function prototype for the handover entry point looks like this::
efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp)
'handle' is the EFI image handle passed to the boot loader by the EFI
firmware, 'table' is the EFI system table - these are the first two

View File

@ -395,8 +395,8 @@ multi-instance state the following function is available:
* cpuhp_setup_state_multi(state, name, startup, teardown)
The @state argument is either a statically allocated state or one of the
constants for dynamically allocated states - CPUHP_PREPARE_DYN,
CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
constants for dynamically allocated states - CPUHP_BP_PREPARE_DYN,
CPUHP_AP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
which a dynamic state should be allocated.
The @name argument is used for sysfs output and for instrumentation. The
@ -588,7 +588,7 @@ notifications on online and offline operations::
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on offline operations::
state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
if (state < 0)
return state;
....
@ -597,7 +597,7 @@ for notifications on offline operations::
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on online operations without invoking the callbacks::
state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
state = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
if (state < 0)
return state;
....
@ -606,7 +606,7 @@ for notifications on online operations without invoking the callbacks::
Setup, use and teardown a dynamically allocated multi-instance state in the
ONLINE section for notifications on online and offline operation::
state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
state = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
if (state < 0)
return state;
....

View File

@ -67,10 +67,11 @@ Globals
kernel-policy
~~~~~~~~~~~~~
Defines if the kernel validation policy is per operation (``per-op``)
or for the entire family (``global``). New families should use ``per-op``
(default) to be able to narrow down the attributes accepted by a specific
command.
Defines whether the kernel validation policy is ``global`` i.e. the same for all
operations of the family, defined for each operation individually - ``per-op``,
or separately for each operation and operation type (do vs dump) - ``split``.
New families should use ``per-op`` (default) to be able to narrow down the
attributes accepted by a specific command.
checks
------

View File

@ -321,3 +321,15 @@ command line arguments:
- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or
saves to a file if a filename is specified.
- ``--filter``: Specifies filters on test attributes, for example, ``speed!=slow``.
Multiple filters can be used by wrapping input in quotes and separating filters
by commas. Example: ``--filter "speed>slow, module=example"``.
- ``--filter_action``: If set to ``skip``, filtered tests will be shown as skipped
in the output rather than showing no output.
- ``--list_tests``: If set, lists all tests that will be run.
- ``--list_tests_attr``: If set, lists all tests that will be run and all of their
attributes.

View File

@ -262,3 +262,169 @@ other code executed during boot, e.g.
# Reset coverage counters before running the test.
$ echo 0 > /sys/kernel/debug/gcov/reset
$ modprobe kunit-example-test
Test Attributes and Filtering
=============================
Test suites and cases can be marked with test attributes, such as speed of
test. These attributes will later be printed in test output and can be used to
filter test execution.
Marking Test Attributes
-----------------------
Tests are marked with an attribute by including a ``kunit_attributes`` object
in the test definition.
Test cases can be marked using the ``KUNIT_CASE_ATTR(test_name, attributes)``
macro to define the test case instead of ``KUNIT_CASE(test_name)``.
.. code-block:: c
static const struct kunit_attributes example_attr = {
.speed = KUNIT_VERY_SLOW,
};
static struct kunit_case example_test_cases[] = {
KUNIT_CASE_ATTR(example_test, example_attr),
};
.. note::
To mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``.
This is a helpful macro as the slow attribute is the most commonly used.
Test suites can be marked with an attribute by setting the "attr" field in the
suite definition.
.. code-block:: c
static const struct kunit_attributes example_attr = {
.speed = KUNIT_VERY_SLOW,
};
static struct kunit_suite example_test_suite = {
...,
.attr = example_attr,
};
.. note::
Not all attributes need to be set in a ``kunit_attributes`` object. Unset
attributes will remain uninitialized and act as though the attribute is set
to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset.
These unset attributes will not be reported and may act as a default value
for filtering purposes.
Reporting Attributes
--------------------
When a user runs tests, attributes will be present in the raw kernel output (in
KTAP format). Note that attributes will be hidden by default in kunit.py output
for all passing tests but the raw kernel output can be accessed using the
``--raw_output`` flag. This is an example of how test attributes for test cases
will be formatted in kernel output:
.. code-block:: none
# example_test.speed: slow
ok 1 example_test
This is an example of how test attributes for test suites will be formatted in
kernel output:
.. code-block:: none
KTAP version 2
# Subtest: example_suite
# module: kunit_example_test
1..3
...
ok 1 example_suite
Additionally, users can output a full attribute report of tests with their
attributes, using the command line flag ``--list_tests_attr``:
.. code-block:: bash
kunit.py run "example" --list_tests_attr
.. note::
This report can be accessed when running KUnit manually by passing in the
module_param ``kunit.action=list_attr``.
Filtering
---------
Users can filter tests using the ``--filter`` command line flag when running
tests. As an example:
.. code-block:: bash
kunit.py run --filter speed=slow
You can also use the following operations on filters: "<", ">", "<=", ">=",
"!=", and "=". Example:
.. code-block:: bash
kunit.py run --filter "speed>slow"
This example will run all tests with speeds faster than slow. Note that the
characters < and > are often interpreted by the shell, so they may need to be
quoted or escaped, as above.
Additionally, you can use multiple filters at once. Simply separate filters
using commas. Example:
.. code-block:: bash
kunit.py run --filter "speed>slow, module=kunit_example_test"
.. note::
You can use this filtering feature when running KUnit manually by passing
the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``.
Filtered tests will not run or show up in the test output. You can use the
``--filter_action=skip`` flag to skip filtered tests instead. These tests will be
shown in the test output in the test but will not run. To use this feature when
running KUnit manually, use the module param ``kunit.filter_action=skip``.
Rules of Filtering Procedure
----------------------------
Since both suites and test cases can have attributes, there may be conflicts
between attributes during filtering. The process of filtering follows these
rules:
- Filtering always operates at a per-test level.
- If a test has an attribute set, then the test's value is filtered on.
- Otherwise, the value falls back to the suite's value.
- If neither are set, the attribute has a global "default" value, which is used.
List of Current Attributes
--------------------------
``speed``
This attribute indicates the speed of a test's execution (how slow or fast the
test is).
This attribute is saved as an enum with the following categories: "normal",
"slow", or "very_slow". The assumed default speed for tests is "normal". This
indicates that the test takes a relatively trivial amount of time (less than
1 second), regardless of the machine it is running on. Any test slower than
this could be marked as "slow" or "very_slow".
The macro ``KUNIT_CASE_SLOW(test_name)`` can be easily used to set the speed
of a test case to "slow".
``module``
This attribute indicates the name of the module associated with the test.
This attribute is automatically saved as a string and is printed for each suite.
Tests can also be filtered using this attribute.

View File

@ -49,9 +49,14 @@ properties:
- arm,cortex-a77-pmu
- arm,cortex-a78-pmu
- arm,cortex-a510-pmu
- arm,cortex-a520-pmu
- arm,cortex-a710-pmu
- arm,cortex-a715-pmu
- arm,cortex-a720-pmu
- arm,cortex-x1-pmu
- arm,cortex-x2-pmu
- arm,cortex-x3-pmu
- arm,cortex-x4-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- arm,neoverse-n2-pmu

View File

@ -49,6 +49,7 @@ properties:
- description: Frequency domain 0 register region
- description: Frequency domain 1 register region
- description: Frequency domain 2 register region
- description: Frequency domain 3 register region
reg-names:
minItems: 1
@ -56,6 +57,7 @@ properties:
- const: freq-domain0
- const: freq-domain1
- const: freq-domain2
- const: freq-domain3
clocks:
items:
@ -69,7 +71,7 @@ properties:
interrupts:
minItems: 1
maxItems: 3
maxItems: 4
interrupt-names:
minItems: 1
@ -77,6 +79,7 @@ properties:
- const: dcvsh-irq-0
- const: dcvsh-irq-1
- const: dcvsh-irq-2
- const: dcvsh-irq-3
'#freq-domain-cells':
const: 1

View File

@ -1,132 +0,0 @@
TI CPUFreq and OPP bindings
================================
Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
families support different OPPs depending on the silicon variant in use.
The ti-cpufreq driver can use revision and an efuse value from the SoC to
provide the OPP framework with supported hardware information. This is
used to determine which OPPs from the operating-points-v2 table get enabled
when it is parsed by the OPP framework.
Required properties:
--------------------
In 'cpus' nodes:
- operating-points-v2: Phandle to the operating-points-v2 table to use.
In 'operating-points-v2' table:
- compatible: Should be
- 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx,
omap34xx, omap36xx and am3517 SoCs
- syscon: A phandle pointing to a syscon node representing the control module
register space of the SoC.
Optional properties:
--------------------
- "vdd-supply", "vbb-supply": to define two regulators for dra7xx
- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx
For each opp entry in 'operating-points-v2' table:
- opp-supported-hw: Two bitfields indicating:
1. Which revision of the SoC the OPP is supported by
2. Which eFuse bits indicate this OPP is available
A bitwise AND is performed against these values and if any bit
matches, the OPP gets enabled.
Example:
--------
/* From arch/arm/boot/dts/am33xx.dtsi */
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a8";
device_type = "cpu";
reg = <0>;
operating-points-v2 = <&cpu0_opp_table>;
clocks = <&dpll_mpu_ck>;
clock-names = "cpu";
clock-latency = <300000>; /* From omap-cpufreq driver */
};
};
/*
* cpu0 has different OPPs depending on SoC revision and some on revisions
* 0x2 and 0x4 have eFuse bits that indicate if they are available or not
*/
cpu0_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
/*
* The three following nodes are marked with opp-suspend
* because they can not be enabled simultaneously on a
* single SoC.
*/
opp50-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <950000 931000 969000>;
opp-supported-hw = <0x06 0x0010>;
opp-suspend;
};
opp100-275000000 {
opp-hz = /bits/ 64 <275000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0x00FF>;
opp-suspend;
};
opp100-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
opp100-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
opp100-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
opp120-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x01 0xFFFF>;
};
opp120-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1200000 1176000 1224000>;
opp-supported-hw = <0x06 0x0080>;
};
oppturbo-720000000 {
opp-hz = /bits/ 64 <720000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x01 0xFFFF>;
};
oppturbo-800000000 {
opp-hz = /bits/ 64 <800000000>;
opp-microvolt = <1260000 1234800 1285200>;
opp-supported-hw = <0x06 0x0100>;
};
oppnitro-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
};
};

View File

@ -20,6 +20,7 @@ properties:
- stericsson,ux500-hash
- st,stm32f456-hash
- st,stm32f756-hash
- st,stm32mp13-hash
reg:
maxItems: 1

View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/adi,ds4520-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: DS4520 I2C GPIO expander
maintainers:
- Okan Sahin <okan.sahin@analog.com>
properties:
compatible:
enum:
- adi,ds4520-gpio
reg:
maxItems: 1
gpio-controller: true
"#gpio-cells":
const: 2
ngpios:
minimum: 1
maximum: 9
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
- ngpios
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
gpio@50 {
compatible = "adi,ds4520-gpio";
reg = <0x50>;
ngpios = <9>;
gpio-controller;
#gpio-cells = <2>;
};
};

View File

@ -1,52 +0,0 @@
Broadcom Kona Family GPIO
=========================
This GPIO driver is used in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
The Broadcom GPIO Controller IP can be configured prior to synthesis to
support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
GPIO controller only supports edge, not level, triggering of interrupts.
Required properties
-------------------
- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller. There is one GPIO
interrupt per GPIO bank. The number of interrupts listed depends on the
number of GPIO banks on the SoC. The interrupts must be ordered by bank,
starting with bank 0. There is always a 1:1 mapping between banks and
IRQs.
- #gpio-cells: Should be <2>. The first cell is the pin number, the second
cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The
second cell is used to specify flags. The following subset of flags is
supported:
- trigger type (bits[1:0]):
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
3 = low-to-high or high-to-low edge triggered
Valid values are 1, 2, 3
See also .../devicetree/bindings/interrupt-controller/interrupts.txt.
- gpio-controller: Marks the device node as a GPIO controller.
- interrupt-controller: Marks the device node as an interrupt controller.
Example:
gpio: gpio@35003000 {
compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
reg = <0x35003000 0x800>;
interrupts =
<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
#interrupt-cells = <2>;
gpio-controller;
interrupt-controller;
};

View File

@ -0,0 +1,100 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/brcm,kona-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Kona family GPIO controller
description:
The Broadcom GPIO Controller IP can be configured prior to synthesis to
support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
GPIO controller only supports edge, not level, triggering of interrupts.
maintainers:
- Ray Jui <rjui@broadcom.com>
properties:
compatible:
items:
- enum:
- brcm,bcm11351-gpio
- brcm,bcm21664-gpio
- brcm,bcm23550-gpio
- const: brcm,kona-gpio
reg:
maxItems: 1
interrupts:
minItems: 4
maxItems: 6
description:
The interrupt outputs from the controller. There is one GPIO interrupt
per GPIO bank. The number of interrupts listed depends on the number of
GPIO banks on the SoC. The interrupts must be ordered by bank, starting
with bank 0. There is always a 1:1 mapping between banks and IRQs.
'#gpio-cells':
const: 2
'#interrupt-cells':
const: 2
gpio-controller: true
interrupt-controller: true
required:
- compatible
- reg
- interrupts
- '#gpio-cells'
- '#interrupt-cells'
- gpio-controller
- interrupt-controller
allOf:
- if:
properties:
compatible:
contains:
const: brcm,bcm11351-gpio
then:
properties:
interrupts:
minItems: 6
- if:
properties:
compatible:
contains:
enum:
- brcm,bcm21664-gpio
- brcm,bcm23550-gpio
then:
properties:
interrupts:
maxItems: 4
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
gpio@35003000 {
compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
reg = <0x35003000 0x800>;
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
#interrupt-cells = <2>;
gpio-controller;
interrupt-controller;
};
...

View File

@ -32,10 +32,12 @@ properties:
- fsl,imx6sx-gpio
- fsl,imx6ul-gpio
- fsl,imx7d-gpio
- fsl,imx8dxl-gpio
- fsl,imx8mm-gpio
- fsl,imx8mn-gpio
- fsl,imx8mp-gpio
- fsl,imx8mq-gpio
- fsl,imx8qm-gpio
- fsl,imx8qxp-gpio
- fsl,imxrt1050-gpio
- fsl,imxrt1170-gpio

View File

@ -66,6 +66,7 @@ properties:
- ti,tca6408
- ti,tca6416
- ti,tca6424
- ti,tca9538
- ti,tca9539
- ti,tca9554

View File

@ -61,6 +61,10 @@ patternProperties:
'#gpio-cells':
const: 2
gpio-line-names:
minItems: 1
maxItems: 32
ngpios:
default: 32
minimum: 1

View File

@ -28,6 +28,10 @@ properties:
gpio-controller: true
gpio-line-names:
minItems: 1
maxItems: 24
interrupt-controller: true
st,norequest-mask:

View File

@ -35,6 +35,7 @@ properties:
- amlogic,meson-sm1-gpio-intc
- amlogic,meson-a1-gpio-intc
- amlogic,meson-s4-gpio-intc
- amlogic,c3-gpio-intc
- const: amlogic,meson-gpio-intc
reg:

View File

@ -160,6 +160,12 @@ properties:
description:
The MIO bank number in which the command and data lines are configured.
iommus:
maxItems: 1
power-domains:
maxItems: 1
dependencies:
'#clock-cells': [ clock-output-names ]

View File

@ -269,7 +269,7 @@ properties:
post-power-on-delay-ms:
description:
It was invented for MMC pwrseq-simple which could be referred to
mmc-pwrseq-simple.txt. But now it\'s reused as a tunable delay
mmc-pwrseq-simple.yaml. But now it\'s reused as a tunable delay
waiting for I/O signalling and card power supply to be stable,
regardless of whether pwrseq-simple is used. Default to 10ms if
no available.

View File

@ -91,16 +91,6 @@ properties:
should switch dat1 pin to GPIO mode.
maxItems: 1
assigned-clocks:
description:
PLL of the source clock.
maxItems: 1
assigned-clock-parents:
description:
parent of source clock, used for HS400 mode to get 400Mhz source clock.
maxItems: 1
hs400-ds-delay:
$ref: /schemas/types.yaml#/definitions/uint32
description:

View File

@ -5,11 +5,13 @@ Documentation/devicetree/bindings/mmc/mmc.txt and the properties used by the
sdhci-of-at91 driver.
Required properties:
- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci".
- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci"
or "microchip,sam9x7-sdhci", "microchip,sam9x60-sdhci".
- clocks: Phandlers to the clocks.
- clock-names: Must be "hclock", "multclk", "baseclk" for
"atmel,sama5d2-sdhci".
Must be "hclock", "multclk" for "microchip,sam9x60-sdhci".
Must be "hclock", "multclk" for "microchip,sam9x7-sdhci".
Optional properties:
- assigned-clocks: The same with "multclk".

View File

@ -20,7 +20,7 @@ which is at a different MDIO base address in different switch families.
6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321,
6341, 6350, 6351, 6352
- "marvell,mv88e6190" : Switch has base address 0x00. Use with models:
6163, 6190, 6190X, 6191, 6290, 6390, 6390X
6190, 6190X, 6191, 6290, 6361, 6390, 6390X
- "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model:
6220, 6250

View File

@ -0,0 +1,45 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/ti,icss-iep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments ICSS Industrial Ethernet Peripheral (IEP) module
maintainers:
- Md Danish Anwar <danishanwar@ti.com>
properties:
compatible:
oneOf:
- items:
- enum:
- ti,am642-icss-iep
- ti,j721e-icss-iep
- const: ti,am654-icss-iep
- const: ti,am654-icss-iep
reg:
maxItems: 1
clocks:
maxItems: 1
description: phandle to the IEP source clock
required:
- compatible
- reg
- clocks
additionalProperties: false
examples:
- |
/* AM65x */
icssg0_iep0: iep@2e000 {
compatible = "ti,am654-icss-iep";
reg = <0x2e000 0x1000>;
clocks = <&icssg0_iepclk_mux>;
};

View File

@ -52,6 +52,14 @@ properties:
description:
phandle to MII_RT module's syscon regmap
ti,iep:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 2
items:
maxItems: 1
description:
phandle to IEP (Industrial Ethernet Peripheral) for ICSSG
interrupts:
maxItems: 2
description:
@ -155,6 +163,7 @@ examples:
"tx1-0", "tx1-1", "tx1-2", "tx1-3",
"rx0", "rx1";
ti,mii-g-rt = <&icssg2_mii_g_rt>;
ti,iep = <&icssg2_iep0>, <&icssg2_iep1>;
interrupt-parent = <&icssg2_intc>;
interrupts = <24 0 2>, <25 1 3>;
interrupt-names = "tx_ts0", "tx_ts1";

View File

@ -1,35 +0,0 @@
XILINX GMIITORGMII Converter Driver Device Tree Bindings
--------------------------------------------------------
The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
This core can be used in all three modes of operation(10/100/1000 Mb/s).
The Management Data Input/Output (MDIO) interface is used to configure the
Speed of operation. This core can switch dynamically between the three
Different speed modes by configuring the conveter register through mdio write.
This converter sits between the ethernet MAC and the external phy.
MAC <==> GMII2RGMII <==> RGMII_PHY
For more details about mdio please refer phy.txt file in the same directory.
Required properties:
- compatible : Should be "xlnx,gmii-to-rgmii-1.0"
- reg : The ID number for the phy, usually a small integer
- phy-handle : Should point to the external phy device.
See ethernet.txt file in the same directory.
Example:
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy: ethernet-phy@0 {
......
};
gmiitorgmii: gmiitorgmii@8 {
compatible = "xlnx,gmii-to-rgmii-1.0";
reg = <8>;
phy-handle = <&phy>;
};
};

View File

@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/xlnx,gmii-to-rgmii.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx GMII to RGMII Converter
maintainers:
- Harini Katakam <harini.katakam@amd.com>
description:
The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
This core can be used in all three modes of operation(10/100/1000 Mb/s).
The Management Data Input/Output (MDIO) interface is used to configure the
speed of operation. This core can switch dynamically between the three
different speed modes by configuring the converter register through mdio write.
The core cannot function without an external phy connected to it.
properties:
compatible:
const: xlnx,gmii-to-rgmii-1.0
reg:
minimum: 0
maximum: 31
description: The ID number for the phy.
phy-handle:
$ref: ethernet-controller.yaml#/properties/phy-handle
required:
- compatible
- reg
- phy-handle
unevaluatedProperties: false
examples:
- |
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy: ethernet-phy@0 {
reg = <0>;
};
gmiitorgmii@8 {
compatible = "xlnx,gmii-to-rgmii-1.0";
reg = <8>;
phy-handle = <&phy>;
};
};

View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/operating-points-v2-ti-cpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI CPU OPP (Operating Performance Points)
description:
TI SoCs, like those in the AM335x, AM437x, AM57xx, AM62x, and DRA7xx
families, the CPU frequencies subset and the voltage value of each
OPP vary based on the silicon variant used. The data sheet sections
corresponding to "Operating Performance Points" describe the frequency
and voltage values based on device type and speed bin information
blown in corresponding eFuse bits as referred to by the Technical
Reference Manual.
This document extends the operating-points-v2 binding by providing
the hardware description for the scheme mentioned above.
maintainers:
- Nishanth Menon <nm@ti.com>
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
const: operating-points-v2-ti-cpu
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
points to syscon node representing the control module
register space of the SoC.
opp-shared: true
patternProperties:
'^opp(-?[0-9]+)*$':
type: object
additionalProperties: false
properties:
clock-latency-ns: true
opp-hz: true
opp-microvolt: true
opp-supported-hw: true
opp-suspend: true
turbo-mode: true
required:
- opp-hz
- opp-supported-hw
required:
- compatible
- syscon
additionalProperties: false
examples:
- |
opp-table {
compatible = "operating-points-v2-ti-cpu";
syscon = <&scm_conf>;
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0020>;
opp-suspend;
};
opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x01 0xFFFF>;
};
opp-600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <1100000 1078000 1122000>;
opp-supported-hw = <0x06 0x0040>;
};
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <1325000 1298500 1351500>;
opp-supported-hw = <0x04 0x0200>;
};
};

View File

@ -56,7 +56,7 @@ patternProperties:
need to be configured and that is left for the implementation
specific binding.
minItems: 1
maxItems: 16
maxItems: 32
items:
maxItems: 1

View File

@ -0,0 +1,101 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/ti,omap-opp-supply.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments OMAP compatible OPP supply
description:
OMAP5, DRA7, and AM57 families of SoCs have Class 0 AVS eFuse
registers, which contain OPP-specific voltage information tailored
for the specific device. This binding provides the information
needed to describe such a hardware values and relate them to program
the primary regulator during an OPP transition.
Also, some supplies may have an associated vbb-supply, an Adaptive
Body Bias regulator, which must transition in a specific sequence
w.r.t the vdd-supply and clk when making an OPP transition. By
supplying two regulators to the device that will undergo OPP
transitions, we can use the multi-regulator support implemented by
the OPP core to describe both regulators the platform needs. The
OPP core binding Documentation/devicetree/bindings/opp/opp-v2.yaml
provides further information (refer to Example 4 Handling multiple
regulators).
maintainers:
- Nishanth Menon <nm@ti.com>
properties:
$nodename:
pattern: '^opp-supply(@[0-9a-f]+)?$'
compatible:
oneOf:
- description: Basic OPP supply controlling VDD and VBB
const: ti,omap-opp-supply
- description: OMAP5+ optimized voltages in efuse(Class 0) VDD along with
VBB.
const: ti,omap5-opp-supply
- description: OMAP5+ optimized voltages in efuse(class0) VDD but no VBB
const: ti,omap5-core-opp-supply
reg:
maxItems: 1
ti,absolute-max-voltage-uv:
$ref: /schemas/types.yaml#/definitions/uint32
description: Absolute maximum voltage for the OPP supply in micro-volts.
minimum: 750000
maximum: 1500000
ti,efuse-settings:
description: An array of u32 tuple items providing information about
optimized efuse configuration.
minItems: 1
$ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description: Reference voltage in micro-volts (OPP Voltage)
minimum: 750000
maximum: 1500000
multipleOf: 10000
- description: efuse offset where the optimized voltage is located
multipleOf: 4
maximum: 256
required:
- compatible
- ti,absolute-max-voltage-uv
allOf:
- if:
not:
properties:
compatible:
contains:
const: ti,omap-opp-supply
then:
required:
- reg
- ti,efuse-settings
additionalProperties: false
examples:
- |
opp-supply {
compatible = "ti,omap-opp-supply";
ti,absolute-max-voltage-uv = <1375000>;
};
- |
opp-supply@4a003b20 {
compatible = "ti,omap5-opp-supply";
reg = <0x4a003b20 0x8>;
ti,efuse-settings =
/* uV offset */
<1060000 0x0>,
<1160000 0x4>,
<1210000 0x8>;
ti,absolute-max-voltage-uv = <1500000>;
};

View File

@ -1,63 +0,0 @@
Texas Instruments OMAP compatible OPP supply description
OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
contain data that can be used to adjust voltages programmed for some of their
supplies for more efficient operation. This binding provides the information
needed to read these values and use them to program the main regulator during
an OPP transitions.
Also, some supplies may have an associated vbb-supply which is an Adaptive Body
Bias regulator which much be transitioned in a specific sequence with regards
to the vdd-supply and clk when making an OPP transition. By supplying two
regulators to the device that will undergo OPP transitions we can make use
of the multi regulator binding that is part of the OPP core described here [1]
to describe both regulators needed by the platform.
[1] Documentation/devicetree/bindings/opp/opp-v2.yaml
Required Properties for Device Node:
- vdd-supply: phandle to regulator controlling VDD supply
- vbb-supply: phandle to regulator controlling Body Bias supply
(Usually Adaptive Body Bias regulator)
Required Properties for opp-supply node:
- compatible: Should be one of:
"ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
"ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
along with VBB
"ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
but no VBB.
- reg: Address and length of the efuse register set for the device (mandatory
only for "ti,omap5-opp-supply")
- ti,efuse-settings: An array of u32 tuple items providing information about
optimized efuse configuration. Each item consists of the following:
volt: voltage in uV - reference voltage (OPP voltage)
efuse_offseet: efuse offset from reg where the optimized voltage is stored.
- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
Example:
/* Device Node (CPU) */
cpus {
cpu0: cpu@0 {
device_type = "cpu";
...
vdd-supply = <&vcc>;
vbb-supply = <&abb_mpu>;
};
};
/* OMAP OPP Supply with Class0 registers */
opp_supply_mpu: opp_supply@4a003b20 {
compatible = "ti,omap5-opp-supply";
reg = <0x4a003b20 0x8>;
ti,efuse-settings = <
/* uV offset */
1060000 0x0
1160000 0x4
1210000 0x8
>;
ti,absolute-max-voltage-uv = <1500000>;
};

View File

@ -28,75 +28,37 @@ properties:
the VSEL pin is assumed to be low.
type: boolean
inl1-supply:
description: Handle to the INL1 input supply (REG5-7)
inl2-supply:
description: Handle to the INL2 input supply (REG8-9)
inl3-supply:
description: Handle to the INL3 input supply (REG10-12)
vp1-supply:
description: Handle to the VP1 input supply (REG1)
vp2-supply:
description: Handle to the VP2 input supply (REG2)
vp3-supply:
description: Handle to the VP3 input supply (REG3)
vp4-supply:
description: Handle to the VP4 input supply (REG4)
regulators:
type: object
additionalProperties: false
properties:
REG1:
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
vp1-supply:
description: Handle to the VP1 input supply
REG2:
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
vp2-supply:
description: Handle to the VP2 input supply
REG3:
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
vp3-supply:
description: Handle to the VP3 input supply
REG4:
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
vp4-supply:
description: Handle to the VP4 input supply
patternProperties:
"^REG[5-7]$":
"^REG([1-9]|1[0-2])$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
inl1-supply:
description: Handle to the INL1 input supply
"^REG[8-9]$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
inl2-supply:
description: Handle to the INL2 input supply
"^REG1[0-2]$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
inl3-supply:
description: Handle to the INL3 input supply
additionalProperties: false
required:

View File

@ -0,0 +1,86 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2022 Analog Devices Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/adi,max77857.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices MAX77857 Buck-Boost Converter
maintainers:
- Ibrahim Tilki <Ibrahim.Tilki@analog.com>
- Okan Sahin <Okan.Sahin@analog.com>
description: Analog Devices MAX77857 Buck-Boost Converter
properties:
compatible:
enum:
- adi,max77831
- adi,max77857
- adi,max77859
- adi,max77859a
reg:
description: I2C address of the device
items:
- enum: [0x66, 0x67, 0x6E, 0x6F]
interrupts:
maxItems: 1
adi,switch-frequency-hz:
description: Switching frequency of the Buck-Boost converter in Hz.
items:
- enum: [1200000, 1500000, 1800000, 2100000]
adi,rtop-ohms:
description: Top feedback resistor value in ohms for external feedback.
minimum: 150000
maximum: 330000
adi,rbot-ohms:
description: Bottom feedback resistor value in ohms for external feedback.
dependencies:
adi,rtop-ohms: [ 'adi,rbot-ohms' ]
adi,rbot-ohms: [ 'adi,rtop-ohms' ]
required:
- compatible
- reg
allOf:
- $ref: regulator.yaml#
- if:
properties:
compatible:
contains:
enum:
- adi,max77831
then:
properties:
adi,switch-frequency-hz:
items:
enum: [1200000, 1500000, 1800000]
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
regulator@66 {
reg = <0x66>;
compatible = "adi,max77857";
interrupt-parent = <&gpio>;
interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
adi,rtop-ohms = <312000>;
adi,rbot-ohms = <12000>;
};
};

View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/awinic,aw37503.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Awinic AW37503 Voltage Regulator
maintainers:
- Alec Li <like@awinic.com>
description:
The AW37503 are dual voltage regulator, designed to support positive/negative
supply for driving TFT-LCD panels. It support software-configurable output
switching and monitoring. The output voltages can be programmed via an I2C
compatible interface.
properties:
compatible:
const: awinic,aw37503
reg:
maxItems: 1
patternProperties:
"^out[pn]$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
Properties for single regulator.
properties:
enable-gpios:
maxItems: 1
description:
GPIO specifier to enable the GPIO control (on/off) for regulator.
required:
- regulator-name
required:
- compatible
- reg
- outp
- outn
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
regulator@3e {
compatible = "awinic,aw37503";
reg = <0x3e>;
outp {
regulator-name = "outp";
regulator-boot-on;
regulator-always-on;
enable-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
};
outn {
regulator-name = "outn";
regulator-boot-on;
regulator-always-on;
enable-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
};
};
};
...

View File

@ -95,11 +95,6 @@ properties:
Properties for a single BUCK regulator
properties:
regulator-name:
pattern: "^BUCK([1-2])$"
description: |
BUCK2 present in DA9122, DA9220, DA9131, DA9132 only
regulator-initial-mode:
enum: [ 0, 1, 2, 3 ]
description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
@ -122,6 +117,23 @@ required:
- reg
- regulators
allOf:
- if:
properties:
compatible:
not:
contains:
enum:
- dlg,da9122
- dlg,da9131
- dlg,da9132
- dlg,da9220
then:
properties:
regulators:
properties:
buck2: false
additionalProperties: false
examples:

View File

@ -0,0 +1,132 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/dlg,slg51000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Dialog Semiconductor SLG51000 Voltage Regulator
maintainers:
- Eric Jeong <eric.jeong.opensource@diasemi.com>
- Support Opensource <support.opensource@diasemi.com>
properties:
compatible:
const: dlg,slg51000
reg:
maxItems: 1
interrupts:
maxItems: 1
dlg,cs-gpios:
maxItems: 1
description:
GPIO for chip select
vin3-supply:
description:
Input supply for ldo3, required if regulator is enabled
vin4-supply:
description:
Input supply for ldo4, required if regulator is enabled
vin5-supply:
description:
Input supply for ldo5, required if regulator is enabled
vin6-supply:
description:
Input supply for ldo6, required if regulator is enabled
vin7-supply:
description:
Input supply for ldo7, required if regulator is enabled
regulators:
type: object
additionalProperties: false
patternProperties:
"^ldo[1-7]$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
properties:
enable-gpios:
maxItems: 1
required:
- regulator-name
required:
- compatible
- reg
- regulators
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/regulator/dlg,da9121-regulator.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@75 {
compatible = "dlg,slg51000";
reg = <0x75>;
dlg,cs-gpios = <&tlmm 69 GPIO_ACTIVE_HIGH>;
vin5-supply = <&vreg_s1f_1p2>;
vin6-supply = <&vreg_s1f_1p2>;
regulators {
ldo1 {
regulator-name = "slg51000_b_ldo1";
regulator-min-microvolt = <2400000>;
regulator-max-microvolt = <3300000>;
};
ldo2 {
regulator-name = "slg51000_b_ldo2";
regulator-min-microvolt = <2400000>;
regulator-max-microvolt = <3300000>;
};
ldo3 {
regulator-name = "slg51000_b_ldo3";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3750000>;
};
ldo4 {
regulator-name = "slg51000_b_ldo4";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3750000>;
};
ldo5 {
regulator-name = "slg51000_b_ldo5";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1200000>;
};
ldo6 {
regulator-name = "slg51000_b_ldo6";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1200000>;
};
ldo7 {
regulator-name = "slg51000_b_ldo7";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3750000>;
};
};
};
};

View File

@ -29,10 +29,12 @@ properties:
patternProperties:
"^buck[1-4]$":
$ref: regulator.yaml#
unevaluatedProperties: false
type: object
"^ldo[1-4]$":
$ref: regulator.yaml#
unevaluatedProperties: false
type: object
additionalProperties: false

View File

@ -21,7 +21,6 @@ properties:
regulators:
type: object
$ref: regulator.yaml#
description: |
list of regulators provided by this controller, must be named
@ -39,11 +38,13 @@ properties:
ldortc:
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
patternProperties:
"^ldo[1-4]$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
"^buck[1-4]$":
type: object

View File

@ -68,18 +68,22 @@ properties:
"^sw([1-4]|[1-4][a-c]|[1-4][a-c][a-c])$":
$ref: regulator.yaml#
type: object
unevaluatedProperties: false
"^vgen[1-6]$":
$ref: regulator.yaml#
type: object
unevaluatedProperties: false
"^vldo[1-4]$":
$ref: regulator.yaml#
type: object
unevaluatedProperties: false
"^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$":
$ref: regulator.yaml#
type: object
unevaluatedProperties: false
additionalProperties: false

View File

@ -49,7 +49,7 @@ patternProperties:
".*-supply$":
description: Input supply phandle(s) for this node
"^((s|l|lvs)[0-9]*)|(s[1-2][a-b])|(ncp)|(mvs)|(usb-switch)|(hdmi-switch)$":
"^((s|l|lvs)[0-9]*|s[1-2][a-b]|ncp|mvs|usb-switch|hdmi-switch)$":
description: List of regulators and its properties
$ref: regulator.yaml#
unevaluatedProperties: false

View File

@ -53,6 +53,7 @@ description: |
For PMR735A, smps1 - smps3, ldo1 - ldo7
For PMX55, smps1 - smps7, ldo1 - ldo16
For PMX65, smps1 - smps8, ldo1 - ldo21
For PMX75, smps1 - smps10, ldo1 - ldo21
properties:
compatible:
@ -84,13 +85,14 @@ properties:
- qcom,pmr735a-rpmh-regulators
- qcom,pmx55-rpmh-regulators
- qcom,pmx65-rpmh-regulators
- qcom,pmx75-rpmh-regulators
qcom,pmic-id:
description: |
RPMh resource name suffix used for the regulators found
on this PMIC.
$ref: /schemas/types.yaml#/definitions/string
enum: [a, b, c, d, e, f, g, h, k]
enum: [a, b, c, d, e, f, g, h, i, j, k, l, m, n]
qcom,always-wait-for-ack:
description: |
@ -109,6 +111,7 @@ properties:
bob:
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description: BOB regulator node.
dependencies:
regulator-allow-set-load: [ regulator-allowed-modes ]
@ -117,6 +120,7 @@ patternProperties:
"^(smps|ldo|lvs|bob)[0-9]+$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description: smps/ldo regulator nodes(s).
dependencies:
regulator-allow-set-load: [ regulator-allowed-modes ]
@ -424,10 +428,28 @@ allOf:
vdd-l11-l13-supply: true
patternProperties:
"^vdd-l[1347]-supply$": true
"^vdd-l1[0245789]-supply$": true
"^vdd-l1[024579]-supply$": true
"^vdd-l2[01]-supply$": true
"^vdd-s[1-8]-supply$": true
- if:
properties:
compatible:
enum:
- qcom,pmx75-rpmh-regulators
then:
properties:
vdd-l2-l18-supply: true
vdd-l4-l16-supply: true
vdd-l5-l6-supply: true
vdd-l8-l9-supply: true
vdd-l11-l13-supply: true
vdd-l20-l21-supply: true
patternProperties:
"^vdd-l[137]-supply$": true
"^vdd-l1[024579]-supply$": true
"^vdd-s([1-9]|10)-supply$": true
unevaluatedProperties: false
examples:

View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. REFGEN Regulator
maintainers:
- Konrad Dybcio <konradybcio@kernel.org>
description:
The REFGEN (reference voltage generator) regulator provides reference
voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
allOf:
- $ref: regulator.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- qcom,sc7180-refgen-regulator
- qcom,sc8180x-refgen-regulator
- qcom,sm8150-refgen-regulator
- const: qcom,sdm845-refgen-regulator
- items:
- enum:
- qcom,sc7280-refgen-regulator
- qcom,sc8280xp-refgen-regulator
- qcom,sm6350-refgen-regulator
- qcom,sm6375-refgen-regulator
- qcom,sm8350-refgen-regulator
- const: qcom,sm8250-refgen-regulator
- enum:
- qcom,sdm845-refgen-regulator
- qcom,sm8250-refgen-regulator
reg:
maxItems: 1
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
regulator@162f000 {
compatible = "qcom,sm8250-refgen-regulator";
reg = <0x0162f000 0x84>;
};
...

View File

@ -110,6 +110,7 @@ patternProperties:
"^((s|l|lvs|5vs)[0-9]*)|(boost-bypass)|(bob)$":
description: List of regulators and its properties
$ref: regulator.yaml#
unevaluatedProperties: false
additionalProperties: false

View File

@ -29,6 +29,7 @@ patternProperties:
"^DSV(LCM|P|N)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
Properties for single Display Bias Voltage regulator.

View File

@ -21,6 +21,7 @@ allOf:
properties:
compatible:
enum:
- richtek,rt5733
- richtek,rt5739
reg:

View File

@ -121,6 +121,7 @@ properties:
description: load switch current regulator description.
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
required:
- compatible

View File

@ -0,0 +1,197 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/richtek,rtq2208.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Richtek RTQ2208 SubPMIC Regulator
maintainers:
- Alina Yu <alina_yu@richtek.com>
description: |
RTQ2208 is a highly integrated power converter that offers functional safety dual
multi-configurable synchronous buck converters and two LDOs.
Bucks support "regulator-allowed-modes" and "regulator-mode". The former defines the permitted
switching operation in normal mode; the latter defines the operation in suspend to RAM mode.
No matter the RTQ2208 is configured to normal or suspend to RAM mode, there are two switching
operation modes for all buck rails, automatic power saving mode (Auto mode) and forced continuous
conduction mode (FCCM).
The definition of modes is in the datasheet which is available in below link
and their meaning is::
0 - Auto mode for power saving, which reducing the switching frequency at light load condition
to maintain high frequency.
1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
Datasheet will be available soon at
https://www.richtek.com/assets/Products
properties:
compatible:
enum:
- richtek,rtq2208
reg:
maxItems: 1
interrupts:
maxItems: 1
richtek,mtp-sel-high:
type: boolean
description:
vout register selection based on this boolean value.
false - Using DVS0 register setting to adjust vout
true - Using DVS1 register setting to adjust vout
regulators:
type: object
additionalProperties: false
patternProperties:
"^buck-[a-h]$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
description for buck-[a-h] regulator.
properties:
regulator-allowed-modes:
description:
two buck modes in different switching accuracy.
0 - Auto mode
1 - FCCM
items:
enum: [0, 1]
"^ldo[1-2]$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
regulator description for ldo[1-2].
required:
- compatible
- reg
- regulators
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@10 {
compatible = "richtek,rtq2208";
reg = <0x10>;
interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
richtek,mtp-sel-high;
regulators {
buck-a {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-b {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-c {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-d {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-e {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-f {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-g {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
buck-h {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <2050000>;
regulator-allowed-modes = <0 1>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <1>;
};
};
ldo1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
};
};
ldo2 {
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
};
};
};
};
};

View File

@ -35,6 +35,7 @@ properties:
"^(p|n)avdd$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description: |
regulator description for pavdd and navdd.

View File

@ -1,88 +0,0 @@
* Dialog Semiconductor SLG51000 Voltage Regulator
Required properties:
- compatible : Should be "dlg,slg51000" for SLG51000
- reg : Specifies the I2C slave address.
- xxx-supply: Input voltage supply regulator for ldo3 to ldo7.
These entries are required if regulators are enabled for a device.
An absence of these properties can cause the regulator registration to fail.
If some of input supply is powered through battery or always-on supply then
also it is required to have these parameters with proper node handle of always
on power supply.
vin3-supply: Input supply for ldo3
vin4-supply: Input supply for ldo4
vin5-supply: Input supply for ldo5
vin6-supply: Input supply for ldo6
vin7-supply: Input supply for ldo7
Optional properties:
- interrupt-parent : Specifies the reference to the interrupt controller.
- interrupts : IRQ line information.
- dlg,cs-gpios : Specify a valid GPIO for chip select
Sub-nodes:
- regulators : This node defines the settings for the regulators.
The content of the sub-node is defined by the standard binding
for regulators; see regulator.txt.
The SLG51000 regulators are bound using their names listed below:
ldo1
ldo2
ldo3
ldo4
ldo5
ldo6
ldo7
Optional properties for regulators:
- enable-gpios : Specify a valid GPIO for platform control of the regulator.
Example:
pmic: slg51000@75 {
compatible = "dlg,slg51000";
reg = <0x75>;
regulators {
ldo1 {
regulator-name = "ldo1";
regulator-min-microvolt = <2400000>;
regulator-max-microvolt = <3300000>;
};
ldo2 {
regulator-name = "ldo2";
regulator-min-microvolt = <2400000>;
regulator-max-microvolt = <3300000>;
};
ldo3 {
regulator-name = "ldo3";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3750000>;
};
ldo4 {
regulator-name = "ldo4";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3750000>;
};
ldo5 {
regulator-name = "ldo5";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1200000>;
};
ldo6 {
regulator-name = "ldo6";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1200000>;
};
ldo7 {
regulator-name = "ldo7";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3750000>;
};
};
};

View File

@ -25,8 +25,8 @@ properties:
patternProperties:
"^(reg11|reg18|usb33)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
required:
- compatible

View File

@ -29,11 +29,13 @@ properties:
Initial data for the LDO1 regulator.
$ref: regulator.yaml#
type: object
unevaluatedProperties: false
micvdd:
description:
Initial data for the MICVDD regulator.
$ref: regulator.yaml#
type: object
unevaluatedProperties: false
additionalProperties: true

View File

@ -0,0 +1,313 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/cirrus,cs42l43.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cirrus Logic CS42L43 Audio CODEC
maintainers:
- patches@opensource.cirrus.com
description: |
The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface
(Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed
for portable applications. It provides a high dynamic range, stereo
DAC for headphone output, two integrated Class D amplifiers for
loudspeakers, and two ADCs for wired headset microphone input or
stereo line input. PDM inputs are provided for digital microphones.
allOf:
- $ref: dai-common.yaml#
properties:
compatible:
enum:
- cirrus,cs42l43
reg:
maxItems: 1
vdd-p-supply:
description:
Power supply for the high voltage interface.
vdd-a-supply:
description:
Power supply for internal analog circuits.
vdd-d-supply:
description:
Power supply for internal digital circuits. Can be internally supplied.
vdd-io-supply:
description:
Power supply for external interface and internal digital logic.
vdd-cp-supply:
description:
Power supply for the amplifier 3 and 4 charge pump.
vdd-amp-supply:
description:
Power supply for amplifier 1 and 2.
reset-gpios:
maxItems: 1
interrupt-controller: true
"#interrupt-cells":
const: 2
interrupts:
maxItems: 1
"#sound-dai-cells":
const: 1
clocks:
items:
- description: Synchronous audio clock provided on mclk_in.
clock-names:
const: mclk
cirrus,bias-low:
type: boolean
description:
Select a 1.8V headset micbias rather than 2.8V.
cirrus,bias-sense-microamp:
description:
Current at which the headset micbias sense clamp will engage, 0 to
disable.
enum: [ 0, 14, 23, 41, 50, 60, 68, 86, 95 ]
default: 0
cirrus,bias-ramp-ms:
description:
Time in milliseconds the hardware allows for the headset micbias to
ramp up.
enum: [ 10, 40, 90, 170 ]
default: 170
cirrus,detect-us:
description:
Time in microseconds the type detection will run for. Long values will
cause more audible effects, but give more accurate detection.
enum: [ 20, 100, 1000, 10000, 50000, 75000, 100000, 200000 ]
default: 10000
cirrus,button-automute:
type: boolean
description:
Enable the hardware automuting of decimator 1 when a headset button is
pressed.
cirrus,buttons-ohms:
description:
Impedance in Ohms for each headset button, these should be listed in
ascending order.
minItems: 1
maxItems: 6
cirrus,tip-debounce-ms:
description:
Software debounce on tip sense triggering in milliseconds.
default: 0
cirrus,tip-invert:
type: boolean
description:
Indicates tip detect polarity, inverted implies open-circuit whilst the
jack is inserted.
cirrus,tip-disable-pullup:
type: boolean
description:
Indicates if the internal pullup on the tip detect should be disabled.
cirrus,tip-fall-db-ms:
description:
Time in milliseconds a falling edge on the tip detect should be hardware
debounced for. Note the falling edge is considered after the invert.
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
default: 500
cirrus,tip-rise-db-ms:
description:
Time in milliseconds a rising edge on the tip detect should be hardware
debounced for. Note the rising edge is considered after the invert.
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
default: 500
cirrus,use-ring-sense:
type: boolean
description:
Indicates if the ring sense should be used.
cirrus,ring-invert:
type: boolean
description:
Indicates ring detect polarity, inverted implies open-circuit whilst the
jack is inserted.
cirrus,ring-disable-pullup:
type: boolean
description:
Indicates if the internal pullup on the ring detect should be disabled.
cirrus,ring-fall-db-ms:
description:
Time in milliseconds a falling edge on the ring detect should be hardware
debounced for. Note the falling edge is considered after the invert.
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
default: 500
cirrus,ring-rise-db-ms:
description:
Time in milliseconds a rising edge on the ring detect should be hardware
debounced for. Note the rising edge is considered after the invert.
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
default: 500
pinctrl:
type: object
$ref: /schemas/pinctrl/pinctrl.yaml#
additionalProperties: false
properties:
gpio-controller: true
"#gpio-cells":
const: 2
gpio-ranges:
items:
- description: A phandle to the CODEC pinctrl node
minimum: 0
- const: 0
- const: 0
- const: 3
patternProperties:
"-state$":
oneOf:
- $ref: "#/$defs/cirrus-cs42l43-state"
- patternProperties:
"-pins$":
$ref: "#/$defs/cirrus-cs42l43-state"
additionalProperties: false
spi:
type: object
$ref: /schemas/spi/spi-controller.yaml#
unevaluatedProperties: false
$defs:
cirrus-cs42l43-state:
type: object
allOf:
- $ref: /schemas/pinctrl/pincfg-node.yaml#
- $ref: /schemas/pinctrl/pinmux-node.yaml#
oneOf:
- required: [ groups ]
- required: [ pins ]
additionalProperties: false
properties:
groups:
enum: [ gpio1, gpio2, gpio3, asp, pdmout2, pdmout1, i2c, spi ]
pins:
enum: [ gpio1, gpio2, gpio3,
asp_dout, asp_fsync, asp_bclk,
pdmout2_clk, pdmout2_data, pdmout1_clk, pdmout1_data,
i2c_sda, i2c_scl,
spi_miso, spi_sck, spi_ssb ]
function:
enum: [ gpio, spdif, irq, mic-shutter, spk-shutter ]
drive-strength:
description: Set drive strength in mA
enum: [ 1, 2, 4, 8, 9, 10, 12, 16 ]
input-debounce:
description: Set input debounce in uS
enum: [ 0, 85 ]
required:
- compatible
- reg
- vdd-p-supply
- vdd-a-supply
- vdd-io-supply
- vdd-cp-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
cs42l43: codec@1a {
compatible = "cirrus,cs42l43";
reg = <0x1a>;
vdd-p-supply = <&vdd5v0>;
vdd-a-supply = <&vdd1v8>;
vdd-io-supply = <&vdd1v8>;
vdd-cp-supply = <&vdd1v8>;
vdd-amp-supply = <&vdd5v0>;
reset-gpios = <&gpio 0>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&gpio>;
interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
#sound-dai-cells = <1>;
clocks = <&clks 0>;
clock-names = "mclk";
cs42l43_pins: pinctrl {
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&cs42l43_pins 0 0 3>;
pinctrl-names = "default";
pinctrl-0 = <&pinsettings>;
pinsettings: default-state {
shutter-pins {
groups = "gpio3";
function = "mic-shutter";
};
};
};
spi {
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <&cs42l43_pins 1 0>;
sensor@0 {
compatible = "bosch,bme680";
reg = <0>;
spi-max-frequency = <1400000>;
};
};
};
};

View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/brcm,bcm63xx-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6348/BCM6358 SPI controller
maintainers:
- Jonas Gorski <jonas.gorski@gmail.com>
description: |
Broadcom "Low Speed" SPI controller found in many older MIPS based Broadband
SoCs.
This controller has a limitation that can not keep the chip select line active
between the SPI transfers within the same SPI message. This can terminate the
transaction to some SPI devices prematurely. The issue can be worked around by
the controller's prepend mode.
allOf:
- $ref: spi-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,bcm6368-spi
- brcm,bcm6362-spi
- brcm,bcm63268-spi
- const: brcm,bcm6358-spi
- enum:
- brcm,bcm6348-spi
- brcm,bcm6358-spi
reg:
maxItems: 1
clocks:
items:
- description: SPI master reference clock
clock-names:
items:
- const: spi
interrupts:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- interrupts
unevaluatedProperties: false
examples:
- |
spi@10000800 {
compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi";
reg = <0x10000800 0x70c>;
interrupts = <1>;
clocks = <&clkctl 9>;
clock-names = "spi";
num-cs = <5>;
#address-cells = <1>;
#size-cells = <0>;
};

View File

@ -86,7 +86,17 @@ properties:
maxItems: 1
clocks:
maxItems: 1
minItems: 1
maxItems: 3
clock-names:
oneOf:
- items:
- const: ref
- items:
- const: ref
- const: ahb
- const: apb
cdns,fifo-depth:
description:

View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/loongson,ls2k-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson SPI controller
maintainers:
- Yinbo Zhu <zhuyinbo@loongson.cn>
allOf:
- $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
oneOf:
- enum:
- loongson,ls2k1000-spi
- items:
- enum:
- loongson,ls2k0500-spi
- const: loongson,ls2k1000-spi
reg:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- clocks
unevaluatedProperties: false
examples:
- |
spi0: spi@1fff0220{
compatible = "loongson,ls2k1000-spi";
reg = <0x1fff0220 0x10>;
clocks = <&clk 17>;
#address-cells = <1>;
#size-cells = <0>;
};

View File

@ -1,61 +0,0 @@
NVIDIA Tegra114 SPI controller.
Required properties:
- compatible : For Tegra114, must contain "nvidia,tegra114-spi".
Otherwise, must contain '"nvidia,<chip>-spi", "nvidia,tegra114-spi"' where
<chip> is tegra124, tegra132, or tegra210.
- reg: Should contain SPI registers location and length.
- interrupts: Should contain SPI interrupts.
- clock-names : Must include the following entries:
- spi
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
- spi
- dmas : Must contain an entry for each entry in clock-names.
See ../dma/dma.txt for details.
- dma-names : Must include the following entries:
- rx
- tx
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
Optional properties:
- nvidia,tx-clk-tap-delay: Delays the clock going out to the external device
with this tap value. This property is used to tune the outgoing data from
Tegra SPI master with respect to outgoing Tegra SPI master clock.
Tap values vary based on the platform design trace lengths from Tegra SPI
to corresponding slave devices. Valid tap values are from 0 thru 63.
- nvidia,rx-clk-tap-delay: Delays the clock coming in from the external device
with this tap value. This property is used to adjust the Tegra SPI master
clock with respect to the data from the SPI slave device.
Tap values vary based on the platform design trace lengths from Tegra SPI
to corresponding slave devices. Valid tap values are from 0 thru 63.
Example:
spi@7000d600 {
compatible = "nvidia,tegra114-spi";
reg = <0x7000d600 0x200>;
interrupts = <0 82 0x04>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car 44>;
clock-names = "spi";
resets = <&tegra_car 44>;
reset-names = "spi";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
<spi-client>@<bus_num> {
...
...
nvidia,rx-clk-tap-delay = <0>;
nvidia,tx-clk-tap-delay = <16>;
...
};
};

View File

@ -0,0 +1,100 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/nvidia,tegra114-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra114 SPI controller
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
properties:
compatible:
oneOf:
- const: nvidia,tegra114-spi
- items:
- enum:
- nvidia,tegra210-spi
- nvidia,tegra124-spi
- const: nvidia,tegra114-spi
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: SPI module clock
clock-names:
items:
- const: spi
resets:
items:
- description: SPI module reset
reset-names:
items:
- const: spi
dmas:
items:
- description: DMA channel for the reception FIFO
- description: DMA channel for the transmission FIFO
dma-names:
items:
- const: rx
- const: tx
spi-max-frequency:
description: Maximum SPI clocking speed of the controller in Hz.
$ref: /schemas/types.yaml#/definitions/uint32
allOf:
- $ref: spi-controller.yaml
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- resets
- reset-names
- dmas
- dma-names
examples:
- |
spi@7000d600 {
compatible = "nvidia,tegra114-spi";
reg = <0x7000d600 0x200>;
interrupts = <0 82 0x04>;
clocks = <&tegra_car 44>;
clock-names = "spi";
resets = <&tegra_car 44>;
reset-names = "spi";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <20000000>;
nvidia,rx-clk-tap-delay = <0>;
nvidia,tx-clk-tap-delay = <16>;
};
};

View File

@ -1,37 +0,0 @@
NVIDIA Tegra20 SFLASH controller.
Required properties:
- compatible : should be "nvidia,tegra20-sflash".
- reg: Should contain SFLASH registers location and length.
- interrupts: Should contain SFLASH interrupts.
- clocks : Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
- spi
- dmas : Must contain an entry for each entry in clock-names.
See ../dma/dma.txt for details.
- dma-names : Must include the following entries:
- rx
- tx
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
Example:
spi@7000c380 {
compatible = "nvidia,tegra20-sflash";
reg = <0x7000c380 0x80>;
interrupts = <0 39 0x04>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car 43>;
resets = <&tegra_car 43>;
reset-names = "spi";
dmas = <&apbdma 11>, <&apbdma 11>;
dma-names = "rx", "tx";
};

View File

@ -0,0 +1,81 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/nvidia,tegra20-sflash.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra20 SFLASH controller
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
properties:
compatible:
const: nvidia,tegra20-sflash
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: module clock
resets:
items:
- description: module reset
reset-names:
items:
- const: spi
dmas:
items:
- description: DMA channel used for reception
- description: DMA channel used for transmission
dma-names:
items:
- const: rx
- const: tx
spi-max-frequency:
description: Maximum SPI clocking speed of the controller in Hz.
$ref: /schemas/types.yaml#/definitions/uint32
allOf:
- $ref: spi-controller.yaml
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- resets
- reset-names
- dmas
- dma-names
examples:
- |
#include <dt-bindings/clock/tegra20-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@7000c380 {
compatible = "nvidia,tegra20-sflash";
reg = <0x7000c380 0x80>;
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car TEGRA20_CLK_SPI>;
resets = <&tegra_car 43>;
reset-names = "spi";
dmas = <&apbdma 11>, <&apbdma 11>;
dma-names = "rx", "tx";
};

View File

@ -1,37 +0,0 @@
NVIDIA Tegra20/Tegra30 SLINK controller.
Required properties:
- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
- reg: Should contain SLINK registers location and length.
- interrupts: Should contain SLINK interrupts.
- clocks : Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
- spi
- dmas : Must contain an entry for each entry in clock-names.
See ../dma/dma.txt for details.
- dma-names : Must include the following entries:
- rx
- tx
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
Example:
spi@7000d600 {
compatible = "nvidia,tegra20-slink";
reg = <0x7000d600 0x200>;
interrupts = <0 82 0x04>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car 44>;
resets = <&tegra_car 44>;
reset-names = "spi";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
};

View File

@ -0,0 +1,90 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/nvidia,tegra20-slink.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra20/30 SLINK controller
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
properties:
compatible:
enum:
- nvidia,tegra20-slink
- nvidia,tegra30-slink
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: module clock
resets:
items:
- description: module reset
reset-names:
items:
- const: spi
dmas:
items:
- description: DMA channel used for reception
- description: DMA channel used for transmission
dma-names:
items:
- const: rx
- const: tx
operating-points-v2:
$ref: /schemas/types.yaml#/definitions/phandle
power-domains:
items:
- description: phandle to the core power domain
spi-max-frequency:
description: Maximum SPI clocking speed of the controller in Hz.
$ref: /schemas/types.yaml#/definitions/uint32
allOf:
- $ref: spi-controller.yaml
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- resets
- reset-names
- dmas
- dma-names
examples:
- |
#include <dt-bindings/clock/tegra20-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@7000d600 {
compatible = "nvidia,tegra20-slink";
reg = <0x7000d600 0x200>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car TEGRA20_CLK_SBC2>;
resets = <&tegra_car 44>;
reset-names = "spi";
dmas = <&apbdma 16>, <&apbdma 16>;
dma-names = "rx", "tx";
};

View File

@ -1,33 +0,0 @@
Binding for Broadcom BCM6348/BCM6358 SPI controller
Required properties:
- compatible: must contain one of "brcm,bcm6348-spi", "brcm,bcm6358-spi".
- reg: Base address and size of the controllers memory area.
- interrupts: Interrupt for the SPI block.
- clocks: phandle of the SPI clock.
- clock-names: has to be "spi".
- #address-cells: <1>, as required by generic SPI binding.
- #size-cells: <0>, also as required by generic SPI binding.
Optional properties:
- num-cs: some controllers have less than 8 cs signals. Defaults to 8
if absent.
Child nodes as per the generic SPI binding.
Example:
spi@10000800 {
compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi";
reg = <0x10000800 0x70c>;
interrupts = <1>;
clocks = <&clkctl 9>;
clock-names = "spi";
num-cs = <5>;
#address-cells = <1>;
#size-cells = <0>;
};

View File

@ -49,6 +49,12 @@ properties:
enum: [ 0, 1 ]
default: 0
power-domains:
maxItems: 1
label:
description: Descriptive name of the SPI controller.
required:
- compatible
- reg

View File

@ -63,6 +63,9 @@ properties:
maximum: 2
default: 1
power-domains:
maxItems: 1
required:
- compatible
- reg

View File

@ -45,6 +45,9 @@ properties:
- const: fspi_en
- const: fspi
power-domains:
maxItems: 1
required:
- compatible
- reg

View File

@ -11,6 +11,7 @@ maintainers:
allOf:
- $ref: spi-controller.yaml#
- $ref: /schemas/arm/primecell.yaml#
# We need a select here so we don't match all nodes with 'arm,primecell'
select:

View File

@ -119,6 +119,10 @@ properties:
- fsl,mpr121
# Monolithic Power Systems Inc. multi-phase controller mp2888
- mps,mp2888
# Monolithic Power Systems Inc. multi-phase controller mp2971
- mps,mp2971
# Monolithic Power Systems Inc. multi-phase controller mp2973
- mps,mp2973
# Monolithic Power Systems Inc. multi-phase controller mp2975
- mps,mp2975
# Honeywell Humidicon HIH-6130 humidity/temperature sensor
@ -315,6 +319,8 @@ properties:
- plx,pex8648
# Pulsedlight LIDAR range-finding sensor
- pulsedlight,lidar-lite-v2
# Renesas HS3001 Temperature and Relative Humidity Sensors
- renesas,hs3001
# Renesas ISL29501 time-of-flight sensor
- renesas,isl29501
# Rohm DH2228FV

View File

@ -27,7 +27,7 @@ not strictly considered I/O devices. They are considered here as well,
although they are not the focus of this document.
Some additional information can also be found in the kernel source under
Documentation/s390/driver-model.rst.
Documentation/arch/s390/driver-model.rst.
The css bus
===========
@ -38,7 +38,7 @@ into several categories:
* Standard I/O subchannels, for use by the system. They have a child
device on the ccw bus and are described below.
* I/O subchannels bound to the vfio-ccw driver. See
Documentation/s390/vfio-ccw.rst.
Documentation/arch/s390/vfio-ccw.rst.
* Message subchannels. No Linux driver currently exists.
* CHSC subchannels (at most one). The chsc subchannel driver can be used
to send asynchronous chsc commands.

View File

@ -332,54 +332,121 @@ Encryption modes and usage
fscrypt allows one encryption mode to be specified for file contents
and one encryption mode to be specified for filenames. Different
directory trees are permitted to use different encryption modes.
Supported modes
---------------
Currently, the following pairs of encryption modes are supported:
- AES-256-XTS for contents and AES-256-CTS-CBC for filenames
- AES-128-CBC for contents and AES-128-CTS-CBC for filenames
- AES-256-XTS for contents and AES-256-HCTR2 for filenames
- Adiantum for both contents and filenames
- AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only)
- SM4-XTS for contents and SM4-CTS-CBC for filenames (v2 policies only)
- AES-128-CBC-ESSIV for contents and AES-128-CTS-CBC for filenames
- SM4-XTS for contents and SM4-CTS-CBC for filenames
If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.
Authenticated encryption modes are not currently supported because of
the difficulty of dealing with ciphertext expansion. Therefore,
contents encryption uses a block cipher in `XTS mode
<https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS>`_ or
`CBC-ESSIV mode
<https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_(ESSIV)>`_,
or a wide-block cipher. Filenames encryption uses a
block cipher in `CTS-CBC mode
<https://en.wikipedia.org/wiki/Ciphertext_stealing>`_ or a wide-block
cipher.
AES-128-CBC was added only for low-powered embedded devices with
crypto accelerators such as CAAM or CESA that do not support XTS. To
use AES-128-CBC, CONFIG_CRYPTO_ESSIV and CONFIG_CRYPTO_SHA256 (or
another SHA-256 implementation) must be enabled so that ESSIV can be
used.
The (AES-256-XTS, AES-256-CTS-CBC) pair is the recommended default.
It is also the only option that is *guaranteed* to always be supported
if the kernel supports fscrypt at all; see `Kernel config options`_.
Adiantum is a (primarily) stream cipher-based mode that is fast even
on CPUs without dedicated crypto instructions. It's also a true
wide-block mode, unlike XTS. It can also eliminate the need to derive
per-file encryption keys. However, it depends on the security of two
primitives, XChaCha12 and AES-256, rather than just one. See the
paper "Adiantum: length-preserving encryption for entry-level
processors" (https://eprint.iacr.org/2018/720.pdf) for more details.
To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast
implementations of ChaCha and NHPoly1305 should be enabled, e.g.
CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM.
The (AES-256-XTS, AES-256-HCTR2) pair is also a good choice that
upgrades the filenames encryption to use a wide-block cipher. (A
*wide-block cipher*, also called a tweakable super-pseudorandom
permutation, has the property that changing one bit scrambles the
entire result.) As described in `Filenames encryption`_, a wide-block
cipher is the ideal mode for the problem domain, though CTS-CBC is the
"least bad" choice among the alternatives. For more information about
HCTR2, see `the HCTR2 paper <https://eprint.iacr.org/2021/1441.pdf>`_.
AES-256-HCTR2 is another true wide-block encryption mode that is intended for
use on CPUs with dedicated crypto instructions. AES-256-HCTR2 has the property
that a bitflip in the plaintext changes the entire ciphertext. This property
makes it desirable for filename encryption since initialization vectors are
reused within a directory. For more details on AES-256-HCTR2, see the paper
"Length-preserving encryption with HCTR2"
(https://eprint.iacr.org/2021/1441.pdf). To use AES-256-HCTR2,
CONFIG_CRYPTO_HCTR2 must be enabled. Also, fast implementations of XCTR and
POLYVAL should be enabled, e.g. CRYPTO_POLYVAL_ARM64_CE and
CRYPTO_AES_ARM64_CE_BLK for ARM64.
Adiantum is recommended on systems where AES is too slow due to lack
of hardware acceleration for AES. Adiantum is a wide-block cipher
that uses XChaCha12 and AES-256 as its underlying components. Most of
the work is done by XChaCha12, which is much faster than AES when AES
acceleration is unavailable. For more information about Adiantum, see
`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf>`_.
SM4 is a Chinese block cipher that is an alternative to AES. It has
not seen as much security review as AES, and it only has a 128-bit key
size. It may be useful in cases where its use is mandated.
Otherwise, it should not be used. For SM4 support to be available, it
also needs to be enabled in the kernel crypto API.
The (AES-128-CBC-ESSIV, AES-128-CTS-CBC) pair exists only to support
systems whose only form of AES acceleration is an off-CPU crypto
accelerator such as CAAM or CESA that does not support XTS.
New encryption modes can be added relatively easily, without changes
to individual filesystems. However, authenticated encryption (AE)
modes are not currently supported because of the difficulty of dealing
with ciphertext expansion.
The remaining mode pairs are the "national pride ciphers":
- (SM4-XTS, SM4-CTS-CBC)
Generally speaking, these ciphers aren't "bad" per se, but they
receive limited security review compared to the usual choices such as
AES and ChaCha. They also don't bring much new to the table. It is
suggested to only use these ciphers where their use is mandated.
Kernel config options
---------------------
Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in
only the basic support from the crypto API needed to use AES-256-XTS
and AES-256-CTS-CBC encryption. For optimal performance, it is
strongly recommended to also enable any available platform-specific
kconfig options that provide acceleration for the algorithm(s) you
wish to use. Support for any "non-default" encryption modes typically
requires extra kconfig options as well.
Below, some relevant options are listed by encryption mode. Note,
acceleration options not listed below may be available for your
platform; refer to the kconfig menus. File contents encryption can
also be configured to use inline encryption hardware instead of the
kernel crypto API (see `Inline encryption support`_); in that case,
the file contents mode doesn't need to supported in the kernel crypto
API, but the filenames mode still does.
- AES-256-XTS and AES-256-CTS-CBC
- Recommended:
- arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
- x86: CONFIG_CRYPTO_AES_NI_INTEL
- AES-256-HCTR2
- Mandatory:
- CONFIG_CRYPTO_HCTR2
- Recommended:
- arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
- arm64: CONFIG_CRYPTO_POLYVAL_ARM64_CE
- x86: CONFIG_CRYPTO_AES_NI_INTEL
- x86: CONFIG_CRYPTO_POLYVAL_CLMUL_NI
- Adiantum
- Mandatory:
- CONFIG_CRYPTO_ADIANTUM
- Recommended:
- arm32: CONFIG_CRYPTO_CHACHA20_NEON
- arm32: CONFIG_CRYPTO_NHPOLY1305_NEON
- arm64: CONFIG_CRYPTO_CHACHA20_NEON
- arm64: CONFIG_CRYPTO_NHPOLY1305_NEON
- x86: CONFIG_CRYPTO_CHACHA20_X86_64
- x86: CONFIG_CRYPTO_NHPOLY1305_SSE2
- x86: CONFIG_CRYPTO_NHPOLY1305_AVX2
- AES-128-CBC-ESSIV and AES-128-CTS-CBC:
- Mandatory:
- CONFIG_CRYPTO_ESSIV
- CONFIG_CRYPTO_SHA256 or another SHA-256 implementation
- Recommended:
- AES-CBC acceleration
fscrypt also uses HMAC-SHA512 for key derivation, so enabling SHA-512
acceleration is recommended:
- SHA-512
- Recommended:
- arm64: CONFIG_CRYPTO_SHA512_ARM64_CE
- x86: CONFIG_CRYPTO_SHA512_SSSE3
Contents encryption
-------------------
@ -493,7 +560,14 @@ This structure must be initialized as follows:
be set to constants from ``<linux/fscrypt.h>`` which identify the
encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS
(1) for ``contents_encryption_mode`` and FSCRYPT_MODE_AES_256_CTS
(4) for ``filenames_encryption_mode``.
(4) for ``filenames_encryption_mode``. For details, see `Encryption
modes and usage`_.
v1 encryption policies only support three combinations of modes:
(FSCRYPT_MODE_AES_256_XTS, FSCRYPT_MODE_AES_256_CTS),
(FSCRYPT_MODE_AES_128_CBC, FSCRYPT_MODE_AES_128_CTS), and
(FSCRYPT_MODE_ADIANTUM, FSCRYPT_MODE_ADIANTUM). v2 policies support
all combinations documented in `Supported modes`_.
- ``flags`` contains optional flags from ``<linux/fscrypt.h>``:

View File

@ -146,9 +146,10 @@ For the rest of this document we will prefix all userspace ids with ``u`` and
all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So
an idmapping will be written as ``u0:k10000:r10000``.
For example, the id ``u1000`` is an id in the upper idmapset or "userspace
idmapset" starting with ``u1000``. And it is mapped to ``k11000`` which is a
kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``.
For example, within this idmapping, the id ``u1000`` is an id in the upper
idmapset or "userspace idmapset" starting with ``u0``. And it is mapped to
``k11000`` which is a kernel id in the lower idmapset or "kernel idmapset"
starting with ``k10000``.
A kernel id is always created by an idmapping. Such idmappings are associated
with user namespaces. Since we mainly care about how idmappings work we're not
@ -373,6 +374,13 @@ kernel maps the caller's userspace id down into a kernel id according to the
caller's idmapping and then maps that kernel id up according to the
filesystem's idmapping.
From the implementation point it's worth mentioning how idmappings are represented.
All idmappings are taken from the corresponding user namespace.
- caller's idmapping (usually taken from ``current_user_ns()``)
- filesystem's idmapping (``sb->s_user_ns``)
- mount's idmapping (``mnt_idmap(vfsmnt)``)
Let's see some examples with caller/filesystem idmapping but without mount
idmappings. This will exhibit some problems we can hit. After that we will
revisit/reconsider these examples, this time using mount idmappings, to see how

View File

@ -85,13 +85,14 @@ prototypes::
struct dentry *dentry, struct fileattr *fa);
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
locking rules:
all may block
============== =============================================
============== ==================================================
ops i_rwsem(inode)
============== =============================================
============== ==================================================
lookup: shared
create: exclusive
link: exclusive (both)
@ -115,7 +116,8 @@ atomic_open: shared (exclusive if O_CREAT is set in open flags)
tmpfile: no
fileattr_get: no or exclusive
fileattr_set: exclusive
============== =============================================
get_offset_ctx no
============== ==================================================
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem
@ -374,10 +376,17 @@ invalidate_lock before invalidating page cache in truncate / hole punch
path (and thus calling into ->invalidate_folio) to block races between page
cache invalidation and page cache filling functions (fault, read, ...).
->release_folio() is called when the kernel is about to try to drop the
buffers from the folio in preparation for freeing it. It returns false to
indicate that the buffers are (or may be) freeable. If ->release_folio is
NULL, the kernel assumes that the fs has no private interest in the buffers.
->release_folio() is called when the MM wants to make a change to the
folio that would invalidate the filesystem's private data. For example,
it may be about to be removed from the address_space or split. The folio
is locked and not under writeback. It may be dirty. The gfp parameter
is not usually used for allocation, but rather to indicate what the
filesystem may do to attempt to free the private data. The filesystem may
return false to indicate that the folio's private data cannot be freed.
If it returns true, it should have already removed the private data from
the folio. If a filesystem does not provide a ->release_folio method,
the pagecache will assume that private data is buffer_heads and call
try_to_free_buffers().
->free_folio() is called when the kernel has dropped the folio
from the page cache.

View File

@ -21,8 +21,8 @@ explained further below, some of which can be reconfigured dynamically on the
fly using a remount ('mount -o remount ...') of the filesystem. A tmpfs
filesystem can be resized but it cannot be resized to a size below its current
usage. tmpfs also supports POSIX ACLs, and extended attributes for the
trusted.* and security.* namespaces. ramfs does not use swap and you cannot
modify any parameter for a ramfs filesystem. The size limit of a ramfs
trusted.*, security.* and user.* namespaces. ramfs does not use swap and you
cannot modify any parameter for a ramfs filesystem. The size limit of a ramfs
filesystem is how much memory you have available, and so care must be taken if
used so to not run out of memory.
@ -97,6 +97,9 @@ mount with such options, since it allows any user with write access to
use up all the memory on the machine; but enhances the scalability of
that instance in a system with many CPUs making intensive use of it.
If nr_inodes is not 0, that limited space for inodes is also used up by
extended attributes: "df -i"'s IUsed and IUse% increase, IFree decreases.
tmpfs blocks may be swapped out, when there is a shortage of memory.
tmpfs has a mount option to disable its use of swap:
@ -123,6 +126,37 @@ sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled: which can
be used to deny huge pages on all tmpfs mounts in an emergency, or to
force huge pages on all tmpfs mounts for testing.
tmpfs also supports quota with the following mount options
======================== =================================================
quota User and group quota accounting and enforcement
is enabled on the mount. Tmpfs is using hidden
system quota files that are initialized on mount.
usrquota User quota accounting and enforcement is enabled
on the mount.
grpquota Group quota accounting and enforcement is enabled
on the mount.
usrquota_block_hardlimit Set global user quota block hard limit.
usrquota_inode_hardlimit Set global user quota inode hard limit.
grpquota_block_hardlimit Set global group quota block hard limit.
grpquota_inode_hardlimit Set global group quota inode hard limit.
======================== =================================================
None of the quota related mount options can be set or changed on remount.
Quota limit parameters accept a suffix k, m or g for kilo, mega and giga
and can't be changed on remount. Default global quota limits are taking
effect for any and all user/group/project except root the first time the
quota entry for user/group/project id is being accessed - typically the
first time an inode with a particular id ownership is being created after
the mount. In other words, instead of the limits being initialized to zero,
they are initialized with the particular value provided with these mount
options. The limits can be changed for any user/group id at any time as they
normally can be.
Note that tmpfs quotas do not support user namespaces so no uid/gid
translation is done if quotas are enabled inside user namespaces.
tmpfs has a mount option to set the NUMA memory allocation policy for
all files in that instance (if CONFIG_NUMA is enabled) - which can be
adjusted on the fly via 'mount -o remount ...'

View File

@ -260,9 +260,11 @@ filesystem. The following members are defined:
void (*evict_inode) (struct inode *);
void (*put_super) (struct super_block *);
int (*sync_fs)(struct super_block *sb, int wait);
int (*freeze_super) (struct super_block *);
int (*freeze_super) (struct super_block *sb,
enum freeze_holder who);
int (*freeze_fs) (struct super_block *);
int (*thaw_super) (struct super_block *);
int (*thaw_super) (struct super_block *sb,
enum freeze_wholder who);
int (*unfreeze_fs) (struct super_block *);
int (*statfs) (struct dentry *, struct kstatfs *);
int (*remount_fs) (struct super_block *, int *, char *);
@ -515,6 +517,7 @@ As of kernel 2.6.22, the following members are defined:
int (*fileattr_set)(struct mnt_idmap *idmap,
struct dentry *dentry, struct fileattr *fa);
int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
};
Again, all methods are called without any locks being held, unless
@ -675,7 +678,10 @@ otherwise noted.
called on ioctl(FS_IOC_SETFLAGS) and ioctl(FS_IOC_FSSETXATTR) to
change miscellaneous file flags and attributes. Callers hold
i_rwsem exclusive. If unset, then fall back to f_op->ioctl().
``get_offset_ctx``
called to get the offset context for a directory inode. A
filesystem must define this operation to use
simple_offset_dir_operations.
The Address Space Object
========================

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