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

Merge branch 'for-6.7/config_pm' into for-linus

Browse Source 
- #ifdef CONFIG_PM removal from HID code (Thomas Weißschuh)
This commit is contained in:
Jiri Kosina 2023-11-01 00:07:35 +01:00
commit 20cd569d7e
3796 changed files with 83509 additions and 46549 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@ -74,7 +74,7 @@ modules.order
#
# RPM spec file (make rpm-pkg)
#
/*.spec
/kernel.spec
/rpmbuild/
#

1
.mailmap
View File

@ -377,6 +377,7 @@ Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
Matthieu CASTET <castet.matthieu@free.fr>
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>

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

@ -84,7 +84,7 @@ What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled
Date: Oct 27, 2020
KernelVersion: 5.11.0
Contact: dmaengine@vger.kernel.org
Description: To indicate if PASID (process address space identifier) is
Description: To indicate if user PASID (process address space identifier) is
enabled or not for this device.
What: /sys/bus/dsa/devices/dsa<m>/state

9
Documentation/ABI/testing/sysfs-class-led
View File

@ -59,6 +59,15 @@ Description:
brightness. Reading this file when no hw brightness change
event has happened will return an ENODATA error.
What: /sys/class/leds/<led>/color
Date: June 2023
KernelVersion: 6.5
Description:
Color of the LED.
This is a read-only file. Reading this file returns the color
of the LED as a string (e.g: "red", "green", "multicolor").
What: /sys/class/leds/<led>/trigger
Date: March 2006
KernelVersion: 2.6.17

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

@ -1437,180 +1437,6 @@ Description:
If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to
be flushed, otherwise it is not necessary.
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the HPB specification version.
The full information about the descriptor can be found in the UFS
HPB (Host Performance Booster) Extension specifications.
Example: version 1.2.3 = 0123h
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control
What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_control
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows an indication of the HPB control mode.
00h: Host control mode
01h: Device control mode
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_region_size
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the bHPBRegionSize which can be calculated
as in the following (in bytes):
HPB Region size = 512B * 2^bHPBRegionSize
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_number_lu
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the maximum number of HPB LU supported by
the device.
00h: HPB is not supported by the device.
01h ~ 20h: Maximum number of HPB LU supported by the device
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_subregion_size
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the bHPBSubRegionSize, which can be
calculated as in the following (in bytes) and shall be a multiple of
logical block size:
HPB Sub-Region size = 512B x 2^bHPBSubRegionSize
bHPBSubRegionSize shall not exceed bHPBRegionSize.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_max_active_regions
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the maximum number of active HPB regions that
is supported by the device.
The file is read only.
What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the maximum number of HPB regions assigned to
the HPB logical unit.
The file is read only.
What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the start offset of HPB pinned region.
The file is read only.
What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of HPB pinned regions assigned to
the HPB logical unit.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of reads that changed to HPB read.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of reads that cannot be changed to
HPB read.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_noti_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of response UPIUs that has
recommendations for activating sub-regions and/or inactivating region.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_active_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: For the HPB device control mode, this entry shows the number of
active sub-regions recommended by response UPIUs. For the HPB host control
mode, this entry shows the number of active sub-regions recommended by the
HPB host control mode heuristic algorithm.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_inactive_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: For the HPB device control mode, this entry shows the number of
inactive regions recommended by response UPIUs. For the HPB host control
mode, this entry shows the number of inactive regions recommended by the
HPB host control mode heuristic algorithm.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the number of read buffer commands for
activating sub-regions recommended by response UPIUs.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the requeue timeout threshold for write buffer
command in ms. The value can be changed by writing an integer to
this entry.
What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd
What: /sys/bus/platform/devices/*.ufs/attributes/max_data_size_hpb_single_cmd
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the maximum HPB data size for using a single HPB
command.
=== ========
00h 4KB
01h 8KB
02h 12KB
...
FFh 1024KB
=== ========
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable
What: /sys/bus/platform/devices/*.ufs/flags/hpb_enable
Date: June 2021
Contact: Daejun Park <daejun7.park@samsung.com>
Description: This entry shows the status of HPB.
== ============================
0 HPB is not enabled.
1 HPB is enabled
== ============================
The file is read only.
Contact: Daniil Lunev <dlunev@chromium.org>
What: /sys/bus/platform/drivers/ufshcd/*/capabilities/
What: /sys/bus/platform/devices/*.ufs/capabilities/
@ -1648,76 +1474,3 @@ Description: Indicates status of Write Booster.
The file is read only.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: In host control mode, reads are the major source of activation
trials. Once this threshold hs met, the region is added to the
"to-be-activated" list. Since we reset the read counter upon
write, this include sending a rb command updating the region
ppn as well.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: In host control mode, we think of the regions as "buckets".
Those buckets are being filled with reads, and emptied on write.
We use entries_per_srgn - the amount of blocks in a subregion as
our bucket size. This applies because HPB1.0 only handles
single-block reads. Once the bucket size is crossed, we trigger
a normalization work - not only to avoid overflow, but mainly
because we want to keep those counters normalized, as we are
using those reads as a comparative score, to make various decisions.
The normalization is dividing (shift right) the read counter by
the normalization_factor. If during consecutive normalizations
an active region has exhausted its reads - inactivate it.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: Region deactivation is often due to the fact that eviction took
place: A region becomes active at the expense of another. This is
happening when the max-active-regions limit has been crossed.
In host mode, eviction is considered an extreme measure. We
want to verify that the entering region has enough reads, and
the exiting region has much fewer reads. eviction_thld_enter is
the min reads that a region must have in order to be considered
a candidate for evicting another region.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: Same as above for the exiting region. A region is considered to
be a candidate for eviction only if it has fewer reads than
eviction_thld_exit.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: In order not to hang on to "cold" regions, we inactivate
a region that has no READ access for a predefined amount of
time - read_timeout_ms. If read_timeout_ms has expired, and the
region is dirty, it is less likely that we can make any use of
HPB reading it so we inactivate it. Still, deactivation has
its overhead, and we may still benefit from HPB reading this
region if it is clean - see read_timeout_expiries.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: If the region read timeout has expired, but the region is clean,
just re-wind its timer for another spin. Do that as long as it
is clean and did not exhaust its read_timeout_expiries threshold.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: The frequency with which the delayed worker that checks the
read_timeouts is awakened.
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req
Date: February 2021
Contact: Avri Altman <avri.altman@wdc.com>
Description: In host control mode the host is the originator of map requests.
To avoid flooding the device with map requests, use a simple throttling
mechanism that limits the number of inflight map requests.

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

@ -102,9 +102,9 @@ What: /sys/fs/f2fs/<disk>/max_small_discards
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description: Controls the issue rate of discard commands that consist of small
blocks less than 2MB. The candidates to be discarded are cached until
checkpoint is triggered, and issued during the checkpoint.
By default, it is disabled with 0.
blocks less than 2MB. The candidates to be discarded are cached during
checkpoint, and issued by issue_discard thread after checkpoint.
It is enabled by default.
What: /sys/fs/f2fs/<disk>/max_ordered_discard
Date: October 2022

13
Documentation/admin-guide/cgroup-v1/memory.rst
View File

@ -92,6 +92,13 @@ Brief summary of control files.
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
memory.kmem.limit_in_bytes Deprecated knob to set and read the kernel
memory hard limit. Kernel hard limit is not
supported since 5.16. Writing any value to
do file will not have any effect same as if
nokmem kernel parameter was specified.
Kernel memory is still charged and reported
by memory.kmem.usage_in_bytes.
memory.kmem.usage_in_bytes show current kernel memory allocation
memory.kmem.failcnt show the number of kernel memory usage
hits limits
@ -195,11 +202,11 @@ are not accounted. We just account pages under usual VM management.
RSS pages are accounted at page_fault unless they've already been accounted
for earlier. A file page will be accounted for as Page Cache when it's
inserted into inode (radix-tree). While it's mapped into the page tables of
inserted into inode (xarray). While it's mapped into the page tables of
processes, duplicate accounting is carefully avoided.
An RSS page is unaccounted when it's fully unmapped. A PageCache page is
unaccounted when it's removed from radix-tree. Even if RSS pages are fully
unaccounted when it's removed from xarray. Even if RSS pages are fully
unmapped (by kswapd), they may exist as SwapCache in the system until they
are really freed. Such SwapCaches are also accounted.
A swapped-in page is accounted after adding into swapcache.
@ -907,7 +914,7 @@ experiences some pressure. In this situation, only group C will receive the
notification, i.e. groups A and B will not receive it. This is done to avoid
excessive "broadcasting" of messages, which disturbs the system and which is
especially bad if we are low on memory or thrashing. Group B, will receive
notification only if there are no event listers for group C.
notification only if there are no event listeners for group C.
There are three optional modes that specify different propagation behavior:

2
Documentation/admin-guide/cgroup-v2.rst
View File

@ -1045,7 +1045,7 @@ All time durations are in microseconds.
- user_usec
- system_usec
and the following three when the controller is enabled:
and the following five when the controller is enabled:
- nr_periods
- nr_throttled

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

@ -7076,6 +7076,13 @@
disables both lockup detectors. Default is 10
seconds.
workqueue.unbound_cpus=
[KNL,SMP] Specify to constrain one or some CPUs
to use in unbound workqueues.
Format: <cpu-list>
By default, all online CPUs are available for
unbound workqueues.
workqueue.watchdog_thresh=
If CONFIG_WQ_WATCHDOG is configured, workqueue can
warn stall conditions and dump internal state to
@ -7097,15 +7104,6 @@
threshold repeatedly. They are likely good
candidates for using WQ_UNBOUND workqueues instead.
workqueue.disable_numa
By default, all work items queued to unbound
workqueues are affine to the NUMA nodes they're
issued on, which results in better behavior in
general. If NUMA affinity needs to be disabled for
whatever reason, this option can be used. Note
that this also can be controlled per-workqueue for
workqueues visible under /sys/bus/workqueue/.
workqueue.power_efficient
Per-cpu workqueues are generally preferred because
they show better performance thanks to cache
@ -7121,6 +7119,18 @@
The default value of this parameter is determined by
the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
workqueue.default_affinity_scope=
Select the default affinity scope to use for unbound
workqueues. Can be one of "cpu", "smt", "cache",
"numa" and "system". Default is "cache". For more
information, see the Affinity Scopes section in
Documentation/core-api/workqueue.rst.
This can be changed after boot by writing to the
matching /sys/module/workqueue/parameters file. All
workqueues with the "default" affinity scope will be
updated accordignly.
workqueue.debug_force_rr_cpu
Workqueue used to implicitly guarantee that work
items queued without explicit CPU specified are put

5
Documentation/admin-guide/perf/alibaba_pmu.rst
View File

@ -88,6 +88,11 @@ data bandwidth::
-e ali_drw_27080/hif_rmw/ \
-e ali_drw_27080/cycle/ -- sleep 10
Example usage of counting all memory read/write bandwidth by metric::
perf stat -M ddr_read_bandwidth.all -- sleep 10
perf stat -M ddr_write_bandwidth.all -- sleep 10
The average DRAM bandwidth can be calculated as follows:
- Read Bandwidth = perf_hif_rd * DDRC_WIDTH * DDRC_Freq / DDRC_Cycle

29
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -450,6 +450,35 @@ this allows system administrators to override the
``IA64_THREAD_UAC_NOPRINT`` ``prctl`` and avoid logs being flooded.
io_uring_disabled
=================
Prevents all processes from creating new io_uring instances. Enabling this
shrinks the kernel's attack surface.
= ======================================================================
0 All processes can create io_uring instances as normal. This is the
default setting.
1 io_uring creation is disabled (io_uring_setup() will fail with
-EPERM) for unprivileged processes not in the io_uring_group group.
Existing io_uring instances can still be used. See the
documentation for io_uring_group for more information.
2 io_uring creation is disabled for all processes. io_uring_setup()
always fails with -EPERM. Existing io_uring instances can still be
used.
= ======================================================================
io_uring_group
==============
When io_uring_disabled is set to 1, a process must either be
privileged (CAP_SYS_ADMIN) or be in the io_uring_group group in order
to create an io_uring instance. If io_uring_group is set to -1 (the
default), only processes with the CAP_SYS_ADMIN capability may create
io_uring instances.
kexec_load_disabled
===================

12
Documentation/arch/arm64/cpu-feature-registers.rst
View File

@ -175,6 +175,8 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
| SME | [27-24] | y |
+------------------------------+---------+---------+
| MTE | [11-8] | y |
+------------------------------+---------+---------+
| SSBS | [7-4] | y |
@ -288,8 +290,18 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
| CSSC | [55-52] | y |
+------------------------------+---------+---------+
| RPRFM | [51-48] | y |
+------------------------------+---------+---------+
| BC | [23-20] | y |
+------------------------------+---------+---------+
| MOPS | [19-16] | y |
+------------------------------+---------+---------+
| APA3 | [15-12] | y |
+------------------------------+---------+---------+
| GPA3 | [11-8] | y |
+------------------------------+---------+---------+
| RPRES | [7-4] | y |
+------------------------------+---------+---------+
| WFXT | [3-0] | y |

3
Documentation/arch/arm64/elf_hwcaps.rst
View File

@ -305,6 +305,9 @@ HWCAP2_SMEF16F16
HWCAP2_MOPS
Functionality implied by ID_AA64ISAR2_EL1.MOPS == 0b0001.
HWCAP2_HBC
Functionality implied by ID_AA64ISAR2_EL1.BC == 0b0001.
4. Unused AT_HWCAP bits
-----------------------

2
Documentation/arch/arm64/silicon-errata.rst
View File

@ -71,6 +71,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A520 | #2966298 | ARM64_ERRATUM_2966298 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |

4
Documentation/arch/loongarch/introduction.rst
View File

@ -381,9 +381,9 @@ Documentation of LoongArch ISA:
Documentation of LoongArch ELF psABI:
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.01-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-EN.pdf (in English)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.01-EN.pdf (in English)
Linux kernel repository of Loongson and LoongArch:

31
Documentation/bpf/btf.rst
View File

@ -726,8 +726,8 @@ same as the one describe in :ref:`BTF_Type_String`.
4.2 .BTF.ext section
--------------------
The .BTF.ext section encodes func_info and line_info which needs loader
manipulation before loading into the kernel.
The .BTF.ext section encodes func_info, line_info and CO-RE relocations
which needs loader manipulation before loading into the kernel.
The specification for .BTF.ext section is defined at ``tools/lib/bpf/btf.h``
and ``tools/lib/bpf/btf.c``.
@ -745,15 +745,20 @@ The current header of .BTF.ext section::
__u32 func_info_len;
__u32 line_info_off;
__u32 line_info_len;
/* optional part of .BTF.ext header */
__u32 core_relo_off;
__u32 core_relo_len;
};
It is very similar to .BTF section. Instead of type/string section, it
contains func_info and line_info section. See :ref:`BPF_Prog_Load` for details
about func_info and line_info record format.
contains func_info, line_info and core_relo sub-sections.
See :ref:`BPF_Prog_Load` for details about func_info and line_info
record format.
The func_info is organized as below.::
func_info_rec_size
func_info_rec_size /* __u32 value */
btf_ext_info_sec for section #1 /* func_info for section #1 */
btf_ext_info_sec for section #2 /* func_info for section #2 */
...
@ -773,7 +778,7 @@ Here, num_info must be greater than 0.
The line_info is organized as below.::
line_info_rec_size
line_info_rec_size /* __u32 value */
btf_ext_info_sec for section #1 /* line_info for section #1 */
btf_ext_info_sec for section #2 /* line_info for section #2 */
...
@ -787,6 +792,20 @@ kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct
bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the
beginning of section (``btf_ext_info_sec->sec_name_off``).
The core_relo is organized as below.::
core_relo_rec_size /* __u32 value */
btf_ext_info_sec for section #1 /* core_relo for section #1 */
btf_ext_info_sec for section #2 /* core_relo for section #2 */
``core_relo_rec_size`` specifies the size of ``bpf_core_relo``
structure when .BTF.ext is generated. All ``bpf_core_relo`` structures
within a single ``btf_ext_info_sec`` describe relocations applied to
section named by ``btf_ext_info_sec->sec_name_off``.
See :ref:`Documentation/bpf/llvm_reloc.rst <btf-co-re-relocations>`
for more information on CO-RE relocations.
4.2 .BTF_ids section
--------------------

1
Documentation/bpf/index.rst
View File

@ -29,6 +29,7 @@ that goes into great technical depth about the BPF Architecture.
bpf_licensing
test_debug
clang-notes
linux-notes
other
redirect

0
Documentation/bpf/standardization/linux-notes.rst → Documentation/bpf/linux-notes.rst
View File

304
Documentation/bpf/llvm_reloc.rst
View File

@ -240,3 +240,307 @@ The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations::
Offset Info Type Symbol's Value Symbol's Name
000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text
0000000000000040 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text
.. _btf-co-re-relocations:
=================
CO-RE Relocations
=================
From object file point of view CO-RE mechanism is implemented as a set
of CO-RE specific relocation records. These relocation records are not
related to ELF relocations and are encoded in .BTF.ext section.
See :ref:`Documentation/bpf/btf.rst <BTF_Ext_Section>` for more
information on .BTF.ext structure.
CO-RE relocations are applied to BPF instructions to update immediate
or offset fields of the instruction at load time with information
relevant for target kernel.
Field to patch is selected basing on the instruction class:
* For BPF_ALU, BPF_ALU64, BPF_LD `immediate` field is patched;
* For BPF_LDX, BPF_STX, BPF_ST `offset` field is patched;
* BPF_JMP, BPF_JMP32 instructions **should not** be patched.
Relocation kinds
================
There are several kinds of CO-RE relocations that could be split in
three groups:
* Field-based - patch instruction with field related information, e.g.
change offset field of the BPF_LDX instruction to reflect offset
of a specific structure field in the target kernel.
* Type-based - patch instruction with type related information, e.g.
change immediate field of the BPF_ALU move instruction to 0 or 1 to
reflect if specific type is present in the target kernel.
* Enum-based - patch instruction with enum related information, e.g.
change immediate field of the BPF_LD_IMM64 instruction to reflect
value of a specific enum literal in the target kernel.
The complete list of relocation kinds is represented by the following enum:
.. code-block:: c
enum bpf_core_relo_kind {
BPF_CORE_FIELD_BYTE_OFFSET = 0, /* field byte offset */
BPF_CORE_FIELD_BYTE_SIZE = 1, /* field size in bytes */
BPF_CORE_FIELD_EXISTS = 2, /* field existence in target kernel */
BPF_CORE_FIELD_SIGNED = 3, /* field signedness (0 - unsigned, 1 - signed) */
BPF_CORE_FIELD_LSHIFT_U64 = 4, /* bitfield-specific left bitshift */
BPF_CORE_FIELD_RSHIFT_U64 = 5, /* bitfield-specific right bitshift */
BPF_CORE_TYPE_ID_LOCAL = 6, /* type ID in local BPF object */
BPF_CORE_TYPE_ID_TARGET = 7, /* type ID in target kernel */
BPF_CORE_TYPE_EXISTS = 8, /* type existence in target kernel */
BPF_CORE_TYPE_SIZE = 9, /* type size in bytes */
BPF_CORE_ENUMVAL_EXISTS = 10, /* enum value existence in target kernel */
BPF_CORE_ENUMVAL_VALUE = 11, /* enum value integer value */
BPF_CORE_TYPE_MATCHES = 12, /* type match in target kernel */
};
Notes:
* ``BPF_CORE_FIELD_LSHIFT_U64`` and ``BPF_CORE_FIELD_RSHIFT_U64`` are
supposed to be used to read bitfield values using the following
algorithm:
.. code-block:: c
// To read bitfield ``f`` from ``struct s``
is_signed = relo(s->f, BPF_CORE_FIELD_SIGNED)
off = relo(s->f, BPF_CORE_FIELD_BYTE_OFFSET)
sz = relo(s->f, BPF_CORE_FIELD_BYTE_SIZE)
l = relo(s->f, BPF_CORE_FIELD_LSHIFT_U64)
r = relo(s->f, BPF_CORE_FIELD_RSHIFT_U64)
// define ``v`` as signed or unsigned integer of size ``sz``
v = *({s|u}<sz> *)((void *)s + off)
v <<= l
v >>= r
* The ``BPF_CORE_TYPE_MATCHES`` queries matching relation, defined as
follows:
* for integers: types match if size and signedness match;
* for arrays & pointers: target types are recursively matched;
* for structs & unions:
* local members need to exist in target with the same name;
* for each member we recursively check match unless it is already behind a
pointer, in which case we only check matching names and compatible kind;
* for enums:
* local variants have to have a match in target by symbolic name (but not
numeric value);
* size has to match (but enum may match enum64 and vice versa);
* for function pointers:
* number and position of arguments in local type has to match target;
* for each argument and the return value we recursively check match.
CO-RE Relocation Record
=======================
Relocation record is encoded as the following structure:
.. code-block:: c
struct bpf_core_relo {
__u32 insn_off;
__u32 type_id;
__u32 access_str_off;
enum bpf_core_relo_kind kind;
};
* ``insn_off`` - instruction offset (in bytes) within a code section
associated with this relocation;
* ``type_id`` - BTF type ID of the "root" (containing) entity of a
relocatable type or field;
* ``access_str_off`` - offset into corresponding .BTF string section.
String interpretation depends on specific relocation kind:
* for field-based relocations, string encodes an accessed field using
a sequence of field and array indices, separated by colon (:). It's
conceptually very close to LLVM's `getelementptr <GEP_>`_ instruction's
arguments for identifying offset to a field. For example, consider the
following C code:
.. code-block:: c
struct sample {
int a;
int b;
struct { int c[10]; };
} __attribute__((preserve_access_index));
struct sample *s;
* Access to ``s[0].a`` would be encoded as ``0:0``:
* ``0``: first element of ``s`` (as if ``s`` is an array);
* ``0``: index of field ``a`` in ``struct sample``.
* Access to ``s->a`` would be encoded as ``0:0`` as well.
* Access to ``s->b`` would be encoded as ``0:1``:
* ``0``: first element of ``s``;
* ``1``: index of field ``b`` in ``struct sample``.
* Access to ``s[1].c[5]`` would be encoded as ``1:2:0:5``:
* ``1``: second element of ``s``;
* ``2``: index of anonymous structure field in ``struct sample``;
* ``0``: index of field ``c`` in anonymous structure;
* ``5``: access to array element #5.
* for type-based relocations, string is expected to be just "0";
* for enum value-based relocations, string contains an index of enum
value within its enum type;
* ``kind`` - one of ``enum bpf_core_relo_kind``.
.. _GEP: https://llvm.org/docs/LangRef.html#getelementptr-instruction
.. _btf_co_re_relocation_examples:
CO-RE Relocation Examples
=========================
For the following C code:
.. code-block:: c
struct foo {
int a;
int b;
unsigned c:15;
} __attribute__((preserve_access_index));
enum bar { U, V };
With the following BTF definitions:
.. code-block::
...
[2] STRUCT 'foo' size=8 vlen=2
'a' type_id=3 bits_offset=0
'b' type_id=3 bits_offset=32
'c' type_id=4 bits_offset=64 bitfield_size=15
[3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[4] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
...
[16] ENUM 'bar' encoding=UNSIGNED size=4 vlen=2
'U' val=0
'V' val=1
Field offset relocations are generated automatically when
``__attribute__((preserve_access_index))`` is used, for example:
.. code-block:: c
void alpha(struct foo *s, volatile unsigned long *g) {
*g = s->a;
s->a = 1;
}
00 <alpha>:
0: r3 = *(s32 *)(r1 + 0x0)
00: CO-RE <byte_off> [2] struct foo::a (0:0)
1: *(u64 *)(r2 + 0x0) = r3
2: *(u32 *)(r1 + 0x0) = 0x1
10: CO-RE <byte_off> [2] struct foo::a (0:0)
3: exit
All relocation kinds could be requested via built-in functions.
E.g. field-based relocations:
.. code-block:: c
void bravo(struct foo *s, volatile unsigned long *g) {
*g = __builtin_preserve_field_info(s->b, 0 /* field byte offset */);
*g = __builtin_preserve_field_info(s->b, 1 /* field byte size */);
*g = __builtin_preserve_field_info(s->b, 2 /* field existence */);
*g = __builtin_preserve_field_info(s->b, 3 /* field signedness */);
*g = __builtin_preserve_field_info(s->c, 4 /* bitfield left shift */);
*g = __builtin_preserve_field_info(s->c, 5 /* bitfield right shift */);
}
20 <bravo>:
4: r1 = 0x4
20: CO-RE <byte_off> [2] struct foo::b (0:1)
5: *(u64 *)(r2 + 0x0) = r1
6: r1 = 0x4
30: CO-RE <byte_sz> [2] struct foo::b (0:1)
7: *(u64 *)(r2 + 0x0) = r1
8: r1 = 0x1
40: CO-RE <field_exists> [2] struct foo::b (0:1)
9: *(u64 *)(r2 + 0x0) = r1
10: r1 = 0x1
50: CO-RE <signed> [2] struct foo::b (0:1)
11: *(u64 *)(r2 + 0x0) = r1
12: r1 = 0x31
60: CO-RE <lshift_u64> [2] struct foo::c (0:2)
13: *(u64 *)(r2 + 0x0) = r1
14: r1 = 0x31
70: CO-RE <rshift_u64> [2] struct foo::c (0:2)
15: *(u64 *)(r2 + 0x0) = r1
16: exit
Type-based relocations:
.. code-block:: c
void charlie(struct foo *s, volatile unsigned long *g) {
*g = __builtin_preserve_type_info(*s, 0 /* type existence */);
*g = __builtin_preserve_type_info(*s, 1 /* type size */);
*g = __builtin_preserve_type_info(*s, 2 /* type matches */);
*g = __builtin_btf_type_id(*s, 0 /* type id in this object file */);
*g = __builtin_btf_type_id(*s, 1 /* type id in target kernel */);
}
88 <charlie>:
17: r1 = 0x1
88: CO-RE <type_exists> [2] struct foo
18: *(u64 *)(r2 + 0x0) = r1
19: r1 = 0xc
98: CO-RE <type_size> [2] struct foo
20: *(u64 *)(r2 + 0x0) = r1
21: r1 = 0x1
a8: CO-RE <type_matches> [2] struct foo
22: *(u64 *)(r2 + 0x0) = r1
23: r1 = 0x2 ll
b8: CO-RE <local_type_id> [2] struct foo
25: *(u64 *)(r2 + 0x0) = r1
26: r1 = 0x2 ll
d0: CO-RE <target_type_id> [2] struct foo
28: *(u64 *)(r2 + 0x0) = r1
29: exit
Enum-based relocations:
.. code-block:: c
void delta(struct foo *s, volatile unsigned long *g) {
*g = __builtin_preserve_enum_value(*(enum bar *)U, 0 /* enum literal existence */);
*g = __builtin_preserve_enum_value(*(enum bar *)V, 1 /* enum literal value */);
}
f0 <delta>:
30: r1 = 0x1 ll
f0: CO-RE <enumval_exists> [16] enum bar::U = 0
32: *(u64 *)(r2 + 0x0) = r1
33: r1 = 0x1 ll
108: CO-RE <enumval_value> [16] enum bar::V = 1
35: *(u64 *)(r2 + 0x0) = r1
36: exit

25
Documentation/bpf/standardization/abi.rst Normal file
View File

@ -0,0 +1,25 @@
.. contents::
.. sectnum::
===================================================
BPF ABI Recommended Conventions and Guidelines v1.0
===================================================
This is version 1.0 of an informational document containing recommended
conventions and guidelines for producing portable BPF program binaries.
Registers and calling convention
================================
BPF has 10 general purpose registers and a read-only frame pointer register,
all of which are 64-bits wide.
The BPF calling convention is defined as:
* R0: return value from function calls, and exit value for BPF programs
* R1 - R5: arguments for function calls
* R6 - R9: callee saved registers that function calls will preserve
* R10: read-only frame pointer to access stack
R0 - R5 are scratch registers and BPF programs needs to spill/fill them if
necessary across calls.

2
Documentation/bpf/standardization/index.rst
View File

@ -12,7 +12,7 @@ for the working group charter, documents, and more.
:maxdepth: 1
instruction-set
linux-notes
abi
.. Links:
.. _IETF BPF Working Group: https://datatracker.ietf.org/wg/bpf/about/

44
Documentation/bpf/standardization/instruction-set.rst
View File

@ -1,11 +1,11 @@
.. contents::
.. sectnum::
========================================
eBPF Instruction Set Specification, v1.0
========================================
=======================================
BPF Instruction Set Specification, v1.0
=======================================
This document specifies version 1.0 of the eBPF instruction set.
This document specifies version 1.0 of the BPF instruction set.
Documentation conventions
=========================
@ -97,26 +97,10 @@ Definitions
A: 10000110
B: 11111111 10000110
Registers and calling convention
================================
eBPF has 10 general purpose registers and a read-only frame pointer register,
all of which are 64-bits wide.
The eBPF calling convention is defined as:
* R0: return value from function calls, and exit value for eBPF programs
* R1 - R5: arguments for function calls
* R6 - R9: callee saved registers that function calls will preserve
* R10: read-only frame pointer to access stack
R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if
necessary across calls.
Instruction encoding
====================
eBPF has two instruction encodings:
BPF has two instruction encodings:
* the basic instruction encoding, which uses 64 bits to encode an instruction
* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
@ -260,7 +244,7 @@ BPF_END 0xd0 0 byte swap operations (see `Byte swap instructions`_ b
========= ===== ======= ==========================================================
Underflow and overflow are allowed during arithmetic operations, meaning
the 64-bit or 32-bit value will wrap. If eBPF program execution would
the 64-bit or 32-bit value will wrap. If BPF program execution would
result in division by zero, the destination register is instead set to zero.
If execution would result in modulo by zero, for ``BPF_ALU64`` the value of
the destination register is unchanged whereas for ``BPF_ALU`` the upper
@ -373,7 +357,7 @@ BPF_JNE 0x5 any PC += offset if dst != src
BPF_JSGT 0x6 any PC += offset if dst > src signed
BPF_JSGE 0x7 any PC += offset if dst >= src signed
BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_
BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_
BPF_CALL 0x8 0x1 call PC += imm see `Program-local functions`_
BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_
BPF_EXIT 0x9 0x0 return BPF_JMP only
BPF_JLT 0xa any PC += offset if dst < src unsigned
@ -382,7 +366,7 @@ BPF_JSLT 0xc any PC += offset if dst < src signed
BPF_JSLE 0xd any PC += offset if dst <= src signed
======== ===== === =========================================== =========================================
The eBPF program needs to store the return value into register R0 before doing a
The BPF program needs to store the return value into register R0 before doing a
``BPF_EXIT``.
Example:
@ -424,8 +408,8 @@ Program-local functions
~~~~~~~~~~~~~~~~~~~~~~~
Program-local functions are functions exposed by the same BPF program as the
caller, and are referenced by offset from the call instruction, similar to
``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to
the caller.
``BPF_JA``. The offset is encoded in the imm field of the call instruction.
A ``BPF_EXIT`` within the program-local function will return to the caller.
Load and store instructions
===========================
@ -502,9 +486,9 @@ Atomic operations
Atomic operations are operations that operate on memory and can not be
interrupted or corrupted by other access to the same memory region
by other eBPF programs or means outside of this specification.
by other BPF programs or means outside of this specification.
All atomic operations supported by eBPF are encoded as store operations
All atomic operations supported by BPF are encoded as store operations
that use the ``BPF_ATOMIC`` mode modifier as follows:
* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations
@ -594,7 +578,7 @@ where
Maps
~~~~
Maps are shared memory regions accessible by eBPF programs on some platforms.
Maps are shared memory regions accessible by BPF programs on some platforms.
A map can have various semantics as defined in a separate document, and may or
may not have a single contiguous memory region, but the 'map_val(map)' is
currently only defined for maps that do have a single contiguous memory region.
@ -616,6 +600,6 @@ identified by the given id.
Legacy BPF Packet access instructions
-------------------------------------
eBPF previously introduced special instructions for access to packet data that were
BPF previously introduced special instructions for access to packet data that were
carried over from classic BPF. However, these instructions are
deprecated and should no longer be used.

9
Documentation/core-api/printk-formats.rst
View File

@ -15,9 +15,10 @@ Integer types
If variable is of Type, use printk format specifier:
------------------------------------------------------------
char %d or %x
signed char %d or %hhx
unsigned char %u or %x
short int %d or %x
char %u or %x
short int %d or %hx
unsigned short int %u or %x
int %d or %x
unsigned int %u or %x
@ -27,9 +28,9 @@ Integer types
unsigned long long %llu or %llx
size_t %zu or %zx
ssize_t %zd or %zx
s8 %d or %x
s8 %d or %hhx
u8 %u or %x
s16 %d or %x
s16 %d or %hx
u16 %u or %x
s32 %d or %x
u32 %u or %x

356
Documentation/core-api/workqueue.rst
View File

@ -1,6 +1,6 @@
====================================
Concurrency Managed Workqueue (cmwq)
====================================
=========
Workqueue
=========
:Date: September, 2010
:Author: Tejun Heo <tj@kernel.org>
@ -25,8 +25,8 @@ there is no work item left on the workqueue the worker becomes idle.
When a new work item gets queued, the worker begins executing again.
Why cmwq?
=========
Why Concurrency Managed Workqueue?
==================================
In the original wq implementation, a multi threaded (MT) wq had one
worker thread per CPU and a single threaded (ST) wq had one worker
@ -220,17 +220,16 @@ resources, scheduled and executed.
``max_active``
--------------
``@max_active`` determines the maximum number of execution contexts
per CPU which can be assigned to the work items of a wq. For example,
with ``@max_active`` of 16, at most 16 work items of the wq can be
executing at the same time per CPU.
``@max_active`` determines the maximum number of execution contexts per
CPU which can be assigned to the work items of a wq. For example, with
``@max_active`` of 16, at most 16 work items of the wq can be executing
at the same time per CPU. This is always a per-CPU attribute, even for
unbound workqueues.
Currently, for a bound wq, the maximum limit for ``@max_active`` is
512 and the default value used when 0 is specified is 256. For an
unbound wq, the limit is higher of 512 and 4 *
``num_possible_cpus()``. These values are chosen sufficiently high
such that they are not the limiting factor while providing protection
in runaway cases.
The maximum limit for ``@max_active`` is 512 and the default value used
when 0 is specified is 256. These values are chosen sufficiently high
such that they are not the limiting factor while providing protection in
runaway cases.
The number of active work items of a wq is usually regulated by the
users of the wq, more specifically, by how many work items the users
@ -348,27 +347,346 @@ Guidelines
level of locality in wq operations and work item execution.
Affinity Scopes
===============
An unbound workqueue groups CPUs according to its affinity scope to improve
cache locality. For example, if a workqueue is using the default affinity
scope of "cache", it will group CPUs according to last level cache
boundaries. A work item queued on the workqueue will be assigned to a worker
on one of the CPUs which share the last level cache with the issuing CPU.
Once started, the worker may or may not be allowed to move outside the scope
depending on the ``affinity_strict`` setting of the scope.
Workqueue currently supports the following affinity scopes.
``default``
Use the scope in module parameter ``workqueue.default_affinity_scope``
which is always set to one of the scopes below.
``cpu``
CPUs are not grouped. A work item issued on one CPU is processed by a
worker on the same CPU. This makes unbound workqueues behave as per-cpu
workqueues without concurrency management.
``smt``
CPUs are grouped according to SMT boundaries. This usually means that the
logical threads of each physical CPU core are grouped together.
``cache``
CPUs are grouped according to cache boundaries. Which specific cache
boundary is used is determined by the arch code. L3 is used in a lot of
cases. This is the default affinity scope.
``numa``
CPUs are grouped according to NUMA bounaries.
``system``
All CPUs are put in the same group. Workqueue makes no effort to process a
work item on a CPU close to the issuing CPU.
The default affinity scope can be changed with the module parameter
``workqueue.default_affinity_scope`` and a specific workqueue's affinity
scope can be changed using ``apply_workqueue_attrs()``.
If ``WQ_SYSFS`` is set, the workqueue will have the following affinity scope
related interface files under its ``/sys/devices/virtual/WQ_NAME/``
directory.
``affinity_scope``
Read to see the current affinity scope. Write to change.
When default is the current scope, reading this file will also show the
current effective scope in parentheses, for example, ``default (cache)``.
``affinity_strict``
0 by default indicating that affinity scopes are not strict. When a work
item starts execution, workqueue makes a best-effort attempt to ensure
that the worker is inside its affinity scope, which is called
repatriation. Once started, the scheduler is free to move the worker
anywhere in the system as it sees fit. This enables benefiting from scope
locality while still being able to utilize other CPUs if necessary and
available.
If set to 1, all workers of the scope are guaranteed always to be in the
scope. This may be useful when crossing affinity scopes has other
implications, for example, in terms of power consumption or workload
isolation. Strict NUMA scope can also be used to match the workqueue
behavior of older kernels.
Affinity Scopes and Performance
===============================
It'd be ideal if an unbound workqueue's behavior is optimal for vast
majority of use cases without further tuning. Unfortunately, in the current
kernel, there exists a pronounced trade-off between locality and utilization
necessitating explicit configurations when workqueues are heavily used.
Higher locality leads to higher efficiency where more work is performed for
the same number of consumed CPU cycles. However, higher locality may also
cause lower overall system utilization if the work items are not spread
enough across the affinity scopes by the issuers. The following performance
testing with dm-crypt clearly illustrates this trade-off.
The tests are run on a CPU with 12-cores/24-threads split across four L3
caches (AMD Ryzen 9 3900x). CPU clock boost is turned off for consistency.
``/dev/dm-0`` is a dm-crypt device created on NVME SSD (Samsung 990 PRO) and
opened with ``cryptsetup`` with default settings.
Scenario 1: Enough issuers and work spread across the machine
-------------------------------------------------------------
The command used: ::
$ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k --ioengine=libaio \
--iodepth=64 --runtime=60 --numjobs=24 --time_based --group_reporting \
--name=iops-test-job --verify=sha512
There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512``
makes ``fio`` generate and read back the content each time which makes
execution locality matter between the issuer and ``kcryptd``. The followings
are the read bandwidths and CPU utilizations depending on different affinity
scope settings on ``kcryptd`` measured over five runs. Bandwidths are in
MiBps, and CPU util in percents.
.. list-table::
:widths: 16 20 20
:header-rows: 1
* - Affinity
- Bandwidth (MiBps)
- CPU util (%)
* - system
- 1159.40 ±1.34
- 99.31 ±0.02
* - cache
- 1166.40 ±0.89
- 99.34 ±0.01
* - cache (strict)
- 1166.00 ±0.71
- 99.35 ±0.01
With enough issuers spread across the system, there is no downside to
"cache", strict or otherwise. All three configurations saturate the whole
machine but the cache-affine ones outperform by 0.6% thanks to improved
locality.
Scenario 2: Fewer issuers, enough work for saturation
-----------------------------------------------------
The command used: ::
$ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
--ioengine=libaio --iodepth=64 --runtime=60 --numjobs=8 \
--time_based --group_reporting --name=iops-test-job --verify=sha512
The only difference from the previous scenario is ``--numjobs=8``. There are
a third of the issuers but is still enough total work to saturate the
system.
.. list-table::
:widths: 16 20 20
:header-rows: 1
* - Affinity
- Bandwidth (MiBps)
- CPU util (%)
* - system
- 1155.40 ±0.89
- 97.41 ±0.05
* - cache
- 1154.40 ±1.14
- 96.15 ±0.09
* - cache (strict)
- 1112.00 ±4.64
- 93.26 ±0.35
This is more than enough work to saturate the system. Both "system" and
"cache" are nearly saturating the machine but not fully. "cache" is using
less CPU but the better efficiency puts it at the same bandwidth as
"system".
Eight issuers moving around over four L3 cache scope still allow "cache
(strict)" to mostly saturate the machine but the loss of work conservation
is now starting to hurt with 3.7% bandwidth loss.
Scenario 3: Even fewer issuers, not enough work to saturate
-----------------------------------------------------------
The command used: ::
$ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
--ioengine=libaio --iodepth=64 --runtime=60 --numjobs=4 \
--time_based --group_reporting --name=iops-test-job --verify=sha512
Again, the only difference is ``--numjobs=4``. With the number of issuers
reduced to four, there now isn't enough work to saturate the whole system
and the bandwidth becomes dependent on completion latencies.
.. list-table::
:widths: 16 20 20
:header-rows: 1
* - Affinity
- Bandwidth (MiBps)
- CPU util (%)
* - system
- 993.60 ±1.82
- 75.49 ±0.06
* - cache
- 973.40 ±1.52
- 74.90 ±0.07
* - cache (strict)
- 828.20 ±4.49
- 66.84 ±0.29
Now, the tradeoff between locality and utilization is clearer. "cache" shows
2% bandwidth loss compared to "system" and "cache (struct)" whopping 20%.
Conclusion and Recommendations
------------------------------
In the above experiments, the efficiency advantage of the "cache" affinity
scope over "system" is, while consistent and noticeable, small. However, the
impact is dependent on the distances between the scopes and may be more
pronounced in processors with more complex topologies.
While the loss of work-conservation in certain scenarios hurts, it is a lot
better than "cache (strict)" and maximizing workqueue utilization is
unlikely to be the common case anyway. As such, "cache" is the default
affinity scope for unbound pools.
* As there is no one option which is great for most cases, workqueue usages
that may consume a significant amount of CPU are recommended to configure
the workqueues using ``apply_workqueue_attrs()`` and/or enable
``WQ_SYSFS``.
* An unbound workqueue with strict "cpu" affinity scope behaves the same as
``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the
latter and an unbound workqueue provides a lot more flexibility.
* Affinity scopes are introduced in Linux v6.5. To emulate the previous
behavior, use strict "numa" affinity scope.
* The loss of work-conservation in non-strict affinity scopes is likely
originating from the scheduler. There is no theoretical reason why the
kernel wouldn't be able to do the right thing and maintain
work-conservation in most cases. As such, it is possible that future
scheduler improvements may make most of these tunables unnecessary.
Examining Configuration
=======================
Use tools/workqueue/wq_dump.py to examine unbound CPU affinity
configuration, worker pools and how workqueues map to the pools: ::
$ tools/workqueue/wq_dump.py
Affinity Scopes
===============
wq_unbound_cpumask=0000000f
CPU
nr_pods 4
pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
pod_node [0]=0 [1]=0 [2]=1 [3]=1
cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
SMT
nr_pods 4
pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
pod_node [0]=0 [1]=0 [2]=1 [3]=1
cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
CACHE (default)
nr_pods 2
pod_cpus [0]=00000003 [1]=0000000c
pod_node [0]=0 [1]=1
cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
NUMA
nr_pods 2
pod_cpus [0]=00000003 [1]=0000000c
pod_node [0]=0 [1]=1
cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
SYSTEM
nr_pods 1
pod_cpus [0]=0000000f
pod_node [0]=-1
cpu_pod [0]=0 [1]=0 [2]=0 [3]=0
Worker Pools
============
pool[00] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 0
pool[01] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 0
pool[02] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 1
pool[03] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 1
pool[04] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 2
pool[05] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 2
pool[06] ref= 1 nice= 0 idle/workers= 3/ 3 cpu= 3
pool[07] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 3
pool[08] ref=42 nice= 0 idle/workers= 6/ 6 cpus=0000000f
pool[09] ref=28 nice= 0 idle/workers= 3/ 3 cpus=00000003
pool[10] ref=28 nice= 0 idle/workers= 17/ 17 cpus=0000000c
pool[11] ref= 1 nice=-20 idle/workers= 1/ 1 cpus=0000000f
pool[12] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=00000003
pool[13] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=0000000c
Workqueue CPU -> pool
=====================
[ workqueue \ CPU 0 1 2 3 dfl]
events percpu 0 2 4 6
events_highpri percpu 1 3 5 7
events_long percpu 0 2 4 6
events_unbound unbound 9 9 10 10 8
events_freezable percpu 0 2 4 6
events_power_efficient percpu 0 2 4 6
events_freezable_power_ percpu 0 2 4 6
rcu_gp percpu 0 2 4 6
rcu_par_gp percpu 0 2 4 6
slub_flushwq percpu 0 2 4 6
netns ordered 8 8 8 8 8
...
See the command's help message for more info.
Monitoring
==========
Use tools/workqueue/wq_monitor.py to monitor workqueue operations: ::
$ tools/workqueue/wq_monitor.py events
total infl CPUtime CPUhog CMwake mayday rescued
total infl CPUtime CPUhog CMW/RPR mayday rescued
events 18545 0 6.1 0 5 - -
events_highpri 8 0 0.0 0 0 - -
events_long 3 0 0.0 0 0 - -
events_unbound 38306 0 0.1 - - - -
events_unbound 38306 0 0.1 - 7 - -
events_freezable 0 0 0.0 0 0 - -
events_power_efficient 29598 0 0.2 0 0 - -
events_freezable_power_ 10 0 0.0 0 0 - -
sock_diag_events 0 0 0.0 0 0 - -
total infl CPUtime CPUhog CMwake mayday rescued
total infl CPUtime CPUhog CMW/RPR mayday rescued
events 18548 0 6.1 0 5 - -
events_highpri 8 0 0.0 0 0 - -
events_long 3 0 0.0 0 0 - -
events_unbound 38322 0 0.1 - - - -
events_unbound 38322 0 0.1 - 7 - -
events_freezable 0 0 0.0 0 0 - -
events_power_efficient 29603 0 0.2 0 0 - -
events_freezable_power_ 10 0 0.0 0 0 - -

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

@ -41,8 +41,8 @@ Support
Architectures
~~~~~~~~~~~~~
Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, and
xtensa, and the tag-based KASAN modes are supported only on arm64.
Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, xtensa,
and loongarch, and the tag-based KASAN modes are supported only on arm64.
Compilers
~~~~~~~~~

1
Documentation/devicetree/bindings/ata/pata-common.yaml
View File

@ -38,6 +38,7 @@ patternProperties:
ID number 0 and the slave drive will have ID number 1. The PATA port
nodes will be named "ide-port".
type: object
additionalProperties: false
properties:
reg:

3
Documentation/devicetree/bindings/bus/fsl,imx8qxp-pixel-link-msi-bus.yaml
View File

@ -73,9 +73,6 @@ patternProperties:
"^.*@[0-9a-f]+$":
description: Devices attached to the bus
type: object
properties:
reg:
maxItems: 1
required:
- reg

81
Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml vendored Normal file
View File

@ -0,0 +1,81 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright (C) 2023 Renesas Electronics Corp.
%YAML 1.2
---
$id: http://devicetree.org/schemas/cache/andestech,ax45mp-cache.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Andestech AX45MP L2 Cache Controller
maintainers:
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
description:
A level-2 cache (L2C) is used to improve the system performance by providing
a large amount of cache line entries and reasonable access delays. The L2C
is shared between cores, and a non-inclusive non-exclusive policy is used.
select:
properties:
compatible:
contains:
enum:
- andestech,ax45mp-cache
required:
- compatible
properties:
compatible:
items:
- const: andestech,ax45mp-cache
- const: cache
reg:
maxItems: 1
interrupts:
maxItems: 1
cache-line-size:
const: 64
cache-level:
const: 2
cache-sets:
const: 1024
cache-size:
enum: [131072, 262144, 524288, 1048576, 2097152]
cache-unified: true
next-level-cache: true
additionalProperties: false
required:
- compatible
- reg
- interrupts
- cache-line-size
- cache-level
- cache-sets
- cache-size
- cache-unified
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
cache-controller@13400000 {
compatible = "andestech,ax45mp-cache", "cache";
reg = <0x13400000 0x100000>;
interrupts = <508 IRQ_TYPE_LEVEL_HIGH>;
cache-line-size = <64>;
cache-level = <2>;
cache-sets = <1024>;
cache-size = <262144>;
cache-unified;
};

11
Documentation/devicetree/bindings/clock/renesas,5p35023.yaml
View File

@ -37,6 +37,9 @@ properties:
maxItems: 1
'#clock-cells':
description:
The index in the assigned-clocks is mapped to the output clock as below
0 - REF, 1 - SE1, 2 - SE2, 3 - SE3, 4 - DIFF1, 5 - DIFF2.
const: 1
clocks:
@ -68,7 +71,7 @@ examples:
reg = <0x68>;
#clock-cells = <1>;
clocks = <&x1_x2>;
clocks = <&x1>;
renesas,settings = [
80 00 11 19 4c 02 23 7f 83 19 08 a9 5f 25 24 bf
@ -79,8 +82,8 @@ examples:
assigned-clocks = <&versa3 0>, <&versa3 1>,
<&versa3 2>, <&versa3 3>,
<&versa3 4>, <&versa3 5>;
assigned-clock-rates = <12288000>, <25000000>,
<12000000>, <11289600>,
<11289600>, <24000000>;
assigned-clock-rates = <24000000>, <11289600>,
<11289600>, <12000000>,
<25000000>, <12288000>;
};
};

2
Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
View File

@ -87,7 +87,7 @@ required:
- interrupts
- ports
additionalProperties: false
unevaluatedProperties: false
examples:
- |

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

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

83
Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
View File

@ -1,83 +0,0 @@
* BCM2835 DMA controller
The BCM2835 DMA controller has 16 channels in total.
Only the lower 13 channels have an associated IRQ.
Some arbitrary channels are used by the firmware
(1,3,6,7 in the current firmware version).
The channels 0,2 and 3 have special functionality
and should not be used by the driver.
Required properties:
- compatible: Should be "brcm,bcm2835-dma".
- reg: Should contain DMA registers location and length.
- interrupts: Should contain the DMA interrupts associated
to the DMA channels in ascending order.
- interrupt-names: Should contain the names of the interrupt
in the form "dmaXX".
Use "dma-shared-all" for the common interrupt line
that is shared by all dma channels.
- #dma-cells: Must be <1>, the cell in the dmas property of the
client device represents the DREQ number.
- brcm,dma-channel-mask: Bit mask representing the channels
not used by the firmware in ascending order,
i.e. first channel corresponds to LSB.
Example:
dma: dma@7e007000 {
compatible = "brcm,bcm2835-dma";
reg = <0x7e007000 0xf00>;
interrupts = <1 16>,
<1 17>,
<1 18>,
<1 19>,
<1 20>,
<1 21>,
<1 22>,
<1 23>,
<1 24>,
<1 25>,
<1 26>,
/* dma channel 11-14 share one irq */
<1 27>,
<1 27>,
<1 27>,
<1 27>,
/* unused shared irq for all channels */
<1 28>;
interrupt-names = "dma0",
"dma1",
"dma2",
"dma3",
"dma4",
"dma5",
"dma6",
"dma7",
"dma8",
"dma9",
"dma10",
"dma11",
"dma12",
"dma13",
"dma14",
"dma-shared-all";
#dma-cells = <1>;
brcm,dma-channel-mask = <0x7f35>;
};
DMA clients connected to the BCM2835 DMA controller must use the format
described in the dma.txt file, using a two-cell specifier for each channel.
Example:
bcm2835_i2s: i2s@7e203000 {
compatible = "brcm,bcm2835-i2s";
reg = < 0x7e203000 0x24>;
clocks = <&clocks BCM2835_CLOCK_PCM>;
dmas = <&dma 2>,
<&dma 3>;
dma-names = "tx", "rx";
};

102
Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml Normal file
View File

@ -0,0 +1,102 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/brcm,bcm2835-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: BCM2835 DMA controller
maintainers:
- Nicolas Saenz Julienne <nsaenz@kernel.org>
description:
The BCM2835 DMA controller has 16 channels in total. Only the lower
13 channels have an associated IRQ. Some arbitrary channels are used by the
VideoCore firmware (1,3,6,7 in the current firmware version). The channels
0, 2 and 3 have special functionality and should not be used by the driver.
allOf:
- $ref: dma-controller.yaml#
properties:
compatible:
const: brcm,bcm2835-dma
reg:
maxItems: 1
interrupts:
description:
Should contain the DMA interrupts associated to the DMA channels in
ascending order.
minItems: 1
maxItems: 16
interrupt-names:
minItems: 1
maxItems: 16
'#dma-cells':
description: The single cell represents the DREQ number.
const: 1
brcm,dma-channel-mask:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Bitmask of available DMA channels in ascending order that are
not reserved by firmware and are available to the
kernel. i.e. first channel corresponds to LSB.
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- "#dma-cells"
- brcm,dma-channel-mask
examples:
- |
dma-controller@7e007000 {
compatible = "brcm,bcm2835-dma";
reg = <0x7e007000 0xf00>;
interrupts = <1 16>,
<1 17>,
<1 18>,
<1 19>,
<1 20>,
<1 21>,
<1 22>,
<1 23>,
<1 24>,
<1 25>,
<1 26>,
/* dma channel 11-14 share one irq */
<1 27>,
<1 27>,
<1 27>,
<1 27>,
/* unused shared irq for all channels */
<1 28>;
interrupt-names = "dma0",
"dma1",
"dma2",
"dma3",
"dma4",
"dma5",
"dma6",
"dma7",
"dma8",
"dma9",
"dma10",
"dma11",
"dma12",
"dma13",
"dma14",
"dma-shared-all";
#dma-cells = <1>;
brcm,dma-channel-mask = <0x7f35>;
};
...

106
Documentation/devicetree/bindings/dma/fsl,edma.yaml
View File

@ -21,32 +21,41 @@ properties:
- enum:
- fsl,vf610-edma
- fsl,imx7ulp-edma
- fsl,imx8qm-adma
- fsl,imx8qm-edma
- fsl,imx93-edma3
- fsl,imx93-edma4
- items:
- const: fsl,ls1028a-edma
- const: fsl,vf610-edma
reg:
minItems: 2
minItems: 1
maxItems: 3
interrupts:
minItems: 2
maxItems: 17
minItems: 1
maxItems: 64
interrupt-names:
minItems: 2
maxItems: 17
minItems: 1
maxItems: 64
"#dma-cells":
const: 2
enum:
- 2
- 3
dma-channels:
const: 32
minItems: 1
maxItems: 64
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
maxItems: 2
big-endian:
@ -65,6 +74,29 @@ required:
allOf:
- $ref: dma-controller.yaml#
- if:
properties:
compatible:
contains:
enum:
- fsl,imx8qm-adma
- fsl,imx8qm-edma
- fsl,imx93-edma3
- fsl,imx93-edma4
then:
properties:
"#dma-cells":
const: 3
# It is not necessary to write the interrupt name for each channel.
# instead, you can simply maintain the sequential IRQ numbers as
# defined for the DMA channels.
interrupt-names: false
clock-names:
items:
- const: dma
clocks:
maxItems: 1
- if:
properties:
compatible:
@ -72,18 +104,26 @@ allOf:
const: fsl,vf610-edma
then:
properties:
clocks:
minItems: 2
clock-names:
items:
- const: dmamux0
- const: dmamux1
interrupts:
minItems: 2
maxItems: 2
interrupt-names:
items:
- const: edma-tx
- const: edma-err
reg:
minItems: 2
maxItems: 3
"#dma-cells":
const: 2
dma-channels:
const: 32
- if:
properties:
@ -92,14 +132,22 @@ allOf:
const: fsl,imx7ulp-edma
then:
properties:
clock:
minItems: 2
clock-names:
items:
- const: dma
- const: dmamux0
interrupts:
minItems: 2
maxItems: 17
reg:
minItems: 2
maxItems: 2
"#dma-cells":
const: 2
dma-channels:
const: 32
unevaluatedProperties: false
@ -153,3 +201,47 @@ examples:
clock-names = "dma", "dmamux0";
clocks = <&pcc2 IMX7ULP_CLK_DMA1>, <&pcc2 IMX7ULP_CLK_DMA_MUX1>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/imx93-clock.h>
dma-controller@44000000 {
compatible = "fsl,imx93-edma3";
reg = <0x44000000 0x200000>;
#dma-cells = <3>;
dma-channels = <31>;
interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX93_CLK_EDMA1_GATE>;
clock-names = "dma";
};

31
Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
View File

@ -15,13 +15,19 @@ allOf:
properties:
compatible:
enum:
# APQ8064, IPQ8064 and MSM8960
- qcom,bam-v1.3.0
# MSM8974, APQ8074 and APQ8084
- qcom,bam-v1.4.0
# MSM8916 and SDM845
- qcom,bam-v1.7.0
oneOf:
- enum:
# APQ8064, IPQ8064 and MSM8960
- qcom,bam-v1.3.0
# MSM8974, APQ8074 and APQ8084
- qcom,bam-v1.4.0
# MSM8916, SDM630
- qcom,bam-v1.7.0
- items:
- enum:
# SDM845, SM6115, SM8150, SM8250 and QCM2290
- qcom,bam-v1.7.4
- const: qcom,bam-v1.7.0
clocks:
maxItems: 1
@ -38,7 +44,7 @@ properties:
iommus:
minItems: 1
maxItems: 4
maxItems: 6
num-channels:
$ref: /schemas/types.yaml#/definitions/uint32
@ -81,6 +87,15 @@ required:
- qcom,ee
- reg
anyOf:
- required:
- qcom,powered-remotely
- required:
- qcom,controlled-remotely
- required:
- clocks
- clock-names
additionalProperties: false
examples:

6
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
View File

@ -49,6 +49,12 @@ Optional properties for AXI DMA and MCDMA:
register as configured in h/w. Takes values {8...26}. If the property
is missing or invalid then the default value 23 is used. This is the
maximum value that is supported by all IP versions.
Optional properties for AXI DMA:
- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP.
- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from
0-255. Setting this value to zero disables the delay timer interrupt.
1 timeout interval = 125 * clock period of SG clock.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:

3
Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
View File

@ -48,6 +48,9 @@ properties:
default: 16
enum: [2, 4, 8, 16, 32, 64, 128, 256]
power-domains:
maxItems: 1
required:
- compatible
- reg

82
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
View File

@ -1,82 +0,0 @@
GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
=================================================================
This uses GPIO lines and a challenge & response mechanism to arbitrate who is
the master of an I2C bus in a multimaster situation.
In many cases using GPIOs to arbitrate is not needed and a design can use
the standard I2C multi-master rules. Using GPIOs is generally useful in
the case where there is a device on the bus that has errata and/or bugs
that makes standard multimaster mode not feasible.
Note that this scheme works well enough but has some downsides:
* It is nonstandard (not using standard I2C multimaster)
* Having two masters on a bus in general makes it relatively hard to debug
problems (hard to tell if i2c issues were caused by one master, another, or
some device on the bus).
Algorithm:
All masters on the bus have a 'bus claim' line which is an output that the
others can see. These are all active low with pull-ups enabled. We'll
describe these lines as:
- OUR_CLAIM: output from us signaling to other hosts that we want the bus
- THEIR_CLAIMS: output from others signaling that they want the bus
The basic algorithm is to assert your line when you want the bus, then make
sure that the other side doesn't want it also. A detailed explanation is best
done with an example.
Let's say we want to claim the bus. We:
1. Assert OUR_CLAIM.
2. Waits a little bit for the other sides to notice (slew time, say 10
microseconds).
3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are
done.
4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
5. If not, back off, release the claim and wait for a few more milliseconds.
6. Go back to 1 (until retry time has expired).
Required properties:
- compatible: i2c-arb-gpio-challenge
- our-claim-gpio: The GPIO that we use to claim the bus.
- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
Note that some implementations may only support a single other master.
- I2C arbitration bus node. See i2c-arb.txt in this directory.
Optional properties:
- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
- wait-retry-us: we'll attempt another claim after this many microseconds.
Default is 3000 us.
- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
Example:
i2c@12ca0000 {
compatible = "acme,some-i2c-device";
#address-cells = <1>;
#size-cells = <0>;
};
i2c-arbitrator {
compatible = "i2c-arb-gpio-challenge";
i2c-parent = <&{/i2c@12CA0000}>;
our-claim-gpio = <&gpf0 3 1>;
their-claim-gpios = <&gpe0 4 1>;
slew-delay-us = <10>;
wait-retry-us = <3000>;
wait-free-us = <50000>;
i2c-arb {
#address-cells = <1>;
#size-cells = <0>;
i2c@52 {
// Normal I2C device
};
};
};

135
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml Normal file
View File

@ -0,0 +1,135 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-arb-gpio-challenge.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
maintainers:
- Doug Anderson <dianders@chromium.org>
- Peter Rosin <peda@axentia.se>
description: |
This uses GPIO lines and a challenge & response mechanism to arbitrate who is
the master of an I2C bus in a multimaster situation.
In many cases using GPIOs to arbitrate is not needed and a design can use the
standard I2C multi-master rules. Using GPIOs is generally useful in the case
where there is a device on the bus that has errata and/or bugs that makes
standard multimaster mode not feasible.
Note that this scheme works well enough but has some downsides:
* It is nonstandard (not using standard I2C multimaster)
* Having two masters on a bus in general makes it relatively hard to debug
problems (hard to tell if i2c issues were caused by one master, another,
or some device on the bus).
Algorithm:
All masters on the bus have a 'bus claim' line which is an output that the
others can see. These are all active low with pull-ups enabled. We'll
describe these lines as:
* OUR_CLAIM: output from us signaling to other hosts that we want the bus
* THEIR_CLAIMS: output from others signaling that they want the bus
The basic algorithm is to assert your line when you want the bus, then make
sure that the other side doesn't want it also. A detailed explanation is
best done with an example.
Let's say we want to claim the bus. We:
1. Assert OUR_CLAIM.
2. Waits a little bit for the other sides to notice (slew time, say 10
microseconds).
3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we
are done.
4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
5. If not, back off, release the claim and wait for a few more milliseconds.
6. Go back to 1 (until retry time has expired).
properties:
compatible:
const: i2c-arb-gpio-challenge
i2c-parent:
$ref: /schemas/types.yaml#/definitions/phandle
description:
The I2C bus that this multiplexer's master-side port is connected to.
our-claim-gpios:
maxItems: 1
description:
The GPIO that we use to claim the bus.
slew-delay-us:
default: 10
description:
Time to wait for a GPIO to go high.
their-claim-gpios:
minItems: 1
maxItems: 8
description:
The GPIOs that the other sides use to claim the bus. Note that some
implementations may only support a single other master.
wait-free-us:
default: 50000
description:
We'll give up after this many microseconds.
wait-retry-us:
default: 3000
description:
We'll attempt another claim after this many microseconds.
i2c-arb:
type: object
$ref: /schemas/i2c/i2c-controller.yaml
unevaluatedProperties: false
description:
I2C arbitration bus node.
required:
- compatible
- i2c-arb
- our-claim-gpios
- their-claim-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c-arbitrator {
compatible = "i2c-arb-gpio-challenge";
i2c-parent = <&i2c_4>;
our-claim-gpios = <&gpf0 3 GPIO_ACTIVE_LOW>;
their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>;
slew-delay-us = <10>;
wait-retry-us = <3000>;
wait-free-us = <50000>;
i2c-arb {
#address-cells = <1>;
#size-cells = <0>;
sbs-battery@b {
compatible = "sbs,sbs-battery";
reg = <0xb>;
sbs,poll-retry-count = <1>;
};
embedded-controller@1e {
compatible = "google,cros-ec-i2c";
reg = <0x1e>;
interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&gpx1>;
pinctrl-names = "default";
pinctrl-0 = <&ec_irq>;
wakeup-source;
};
};
};

35
Documentation/devicetree/bindings/i2c/i2c-arb.txt
View File

@ -1,35 +0,0 @@
Common i2c arbitration bus properties.
- i2c-arb child node
Required properties for the i2c-arb child node:
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties for i2c-arb child node:
- Child nodes conforming to i2c bus binding
Example :
/*
An NXP pca9541 I2C bus master selector at address 0x74
with a NXP pca8574 GPIO expander attached.
*/
arb@74 {
compatible = "nxp,pca9541";
reg = <0x74>;
i2c-arb {
#address-cells = <1>;
#size-cells = <0>;
gpio@38 {
compatible = "nxp,pca8574";
reg = <0x38>;
#gpio-cells = <2>;
gpio-controller;
};
};
};

46
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
View File

@ -4,21 +4,29 @@
$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP PCA954x I2C bus switch
title: NXP PCA954x I2C and compatible bus switches
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description:
The binding supports NXP PCA954x and PCA984x I2C mux/switch devices.
allOf:
- $ref: /schemas/i2c/i2c-mux.yaml#
The NXP PCA954x and compatible devices are I2C bus
multiplexer/switches that share the same functionality
and register layout.
The devices usually have 4 or 8 child buses, which are
attached to the parent bus by using the SMBus "Send Byte"
command.
properties:
compatible:
oneOf:
- enum:
- maxim,max7356
- maxim,max7357
- maxim,max7358
- maxim,max7367
- maxim,max7368
- maxim,max7369
- nxp,pca9540
- nxp,pca9542
- nxp,pca9543
@ -59,10 +67,34 @@ properties:
description: if present, overrides i2c-mux-idle-disconnect
$ref: /schemas/mux/mux-controller.yaml#/properties/idle-state
vdd-supply:
description: A voltage regulator supplying power to the chip. On PCA9846
the regulator supplies power to VDD2 (core logic) and optionally to VDD1.
required:
- compatible
- reg
allOf:
- $ref: /schemas/i2c/i2c-mux.yaml#
- if:
not:
properties:
compatible:
contains:
enum:
- maxim,max7367
- maxim,max7369
- nxp,pca9542
- nxp,pca9543
- nxp,pca9544
- nxp,pca9545
then:
properties:
interrupts: false
"#interrupt-cells": false
interrupt-controller: false
unevaluatedProperties: false
examples:
@ -74,11 +106,13 @@ examples:
#size-cells = <0>;
i2c-mux@74 {
compatible = "nxp,pca9548";
compatible = "nxp,pca9545";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
vdd-supply = <&p3v3>;
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;

5
Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
View File

@ -9,6 +9,9 @@ title: Freescale MXS Inter IC (I2C) Controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
enum:
@ -37,7 +40,7 @@ required:
- dmas
- dma-names
additionalProperties: false
unevaluatedProperties: false
examples:
- |

29
Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
View File

@ -1,29 +0,0 @@
* NXP PCA9541 I2C bus master selector
Required Properties:
- compatible: Must be "nxp,pca9541"
- reg: The I2C address of the device.
The following required properties are defined externally:
- I2C arbitration bus node. See i2c-arb.txt in this directory.
Example:
i2c-arbitrator@74 {
compatible = "nxp,pca9541";
reg = <0x74>;
i2c-arb {
#address-cells = <1>;
#size-cells = <0>;
eeprom@54 {
compatible = "atmel,24c08";
reg = <0x54>;
};
};
};

56
Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml Normal file
View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/nxp,pca9541.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP PCA9541 I2C bus master selector
maintainers:
- Peter Rosin <peda@axentia.se>
properties:
compatible:
const: nxp,pca9541
reg:
maxItems: 1
i2c-arb:
type: object
$ref: /schemas/i2c/i2c-controller.yaml
unevaluatedProperties: false
description:
I2C arbitration bus node.
required:
- compatible
- reg
- i2c-arb
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
i2c-arbitrator@74 {
compatible = "nxp,pca9541";
reg = <0x74>;
i2c-arb {
#address-cells = <1>;
#size-cells = <0>;
eeprom@54 {
compatible = "atmel,24c08";
reg = <0x54>;
};
};
};
};

1
Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
View File

@ -269,6 +269,7 @@ examples:
port {
ov7251_ep: endpoint {
data-lanes = <0 1>;
link-frequencies = /bits/ 64 <240000000 319200000>;
remote-endpoint = <&csiphy3_ep>;
};
};

15
Documentation/devicetree/bindings/i3c/i3c.yaml
View File

@ -135,9 +135,10 @@ patternProperties:
minimum: 0x1
maximum: 0xff
description: |
Dynamic address to be assigned to this device. This property is only
valid if the I3C device has a static address (first cell of the reg
property != 0).
Dynamic address to be assigned to this device. In case static address is
present (first cell of the reg property != 0), this address is assigned
through SETDASA. If static address is not present, this address is assigned
through SETNEWDA after assigning a temporary address via ENTDAA.
required:
- reg
@ -163,12 +164,18 @@ examples:
pagesize = <0x8>;
};
/* I3C device with a static I2C address. */
/* I3C device with a static I2C address and assigned address. */
thermal_sensor: sensor@68,39200144004 {
reg = <0x68 0x392 0x144004>;
assigned-address = <0xa>;
};
/* I3C device with only assigned address. */
pressure_sensor: sensor@0,39200124004 {
reg = <0x0 0x392 0x124000>;
assigned-address = <0xc>;
};
/*
* I3C device without a static I2C address but requiring
* resources described in the DT.

248
Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
View File

@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/input/azoteq,iqs7222.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Azoteq IQS7222A/B/C Capacitive Touch Controller
title: Azoteq IQS7222A/B/C/D Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch
controllers that feature additional sensing capabilities.
The Azoteq IQS7222A, IQS7222B, IQS7222C and IQS7222D are multichannel
capacitive touch controllers that feature additional sensing capabilities.
Link to datasheets: https://www.azoteq.com/
@ -21,6 +21,7 @@ properties:
- azoteq,iqs7222a
- azoteq,iqs7222b
- azoteq,iqs7222c
- azoteq,iqs7222d
reg:
maxItems: 1
@ -173,6 +174,152 @@ properties:
maximum: 3000
description: Specifies the report rate (in ms) during ultra-low-power mode.
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
trackpad:
type: object
description: Represents all channels associated with the trackpad.
properties:
azoteq,channel-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 12
items:
minimum: 0
maximum: 13
description:
Specifies the order of the channels that participate in the trackpad.
Specify 255 to omit a given channel for the purpose of mapping a non-
rectangular trackpad.
azoteq,num-rows:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 12
description: Specifies the number of rows that comprise the trackpad.
azoteq,num-cols:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 12
description: Specifies the number of columns that comprise the trackpad.
azoteq,top-speed:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 4
minimum: 0
maximum: 1020
description:
Specifies the speed (in coordinates traveled per conversion) after
which coordinate filtering is no longer applied.
azoteq,bottom-speed:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description:
Specifies the speed (in coordinates traveled per conversion) after
which coordinate filtering is linearly reduced.
azoteq,use-prox:
type: boolean
description:
Directs the trackpad to respond to the proximity states of the
selected channels instead of their corresponding touch states.
Note the trackpad cannot report granular coordinates during a
state of proximity.
patternProperties:
"^azoteq,lower-cal-(x|y)$":
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's lower starting points.
"^azoteq,upper-cal-(x|y)$":
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's upper starting points.
"^event-(press|tap|(swipe|flick)-(x|y)-(pos|neg))$":
type: object
$ref: input.yaml#
description:
Represents a press or gesture event reported by the trackpad. Specify
'linux,code' under the press event to report absolute coordinates.
properties:
linux,code: true
azoteq,gesture-angle-tighten:
type: boolean
description:
Limits the tangent of the gesture angle to 0.5 (axial gestures
only). If specified in one direction, the effect is applied in
either direction.
azoteq,gesture-max-ms:
multipleOf: 16
minimum: 0
maximum: 4080
description:
Specifies the length of time (in ms) within which a tap, swipe
or flick gesture must be completed in order to be acknowledged
by the device. The number specified for any one swipe or flick
gesture applies to all other swipe or flick gestures.
azoteq,gesture-min-ms:
multipleOf: 16
minimum: 0
maximum: 4080
description:
Specifies the length of time (in ms) for which a tap gesture must
be held in order to be acknowledged by the device.
azoteq,gesture-dist:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description:
Specifies the distance (in coordinates) across which a swipe or
flick gesture must travel in order to be acknowledged by the
device. The number specified for any one swipe or flick gesture
applies to all remaining swipe or flick gestures.
For tap gestures, this property specifies the distance from the
original point of contact across which the contact is permitted
to travel before the gesture is rejected by the device.
azoteq,gpio-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 3
items:
minimum: 0
maximum: 2
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
1: GPIO3
2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
trackpad gesture).
additionalProperties: false
required:
- azoteq,channel-select
additionalProperties: false
patternProperties:
"^cycle-[0-9]$":
type: object
@ -288,6 +435,10 @@ patternProperties:
Activates the reference channel in response to proximity events
instead of touch events.
azoteq,counts-filt-enable:
type: boolean
description: Applies counts filtering to the channel.
azoteq,ati-band:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
@ -432,12 +583,12 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
1: GPIO3 (IQS7222C only)
2: GPIO4 (IQS7222C only)
1: GPIO3
2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
slider gesture).
slider/trackpad gesture).
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
@ -521,16 +672,16 @@ patternProperties:
minimum: 0
maximum: 65535
description:
Specifies the speed of movement after which coordinate filtering is
no longer applied.
Specifies the speed (in coordinates traveled per conversion) after
which coordinate filtering is no longer applied.
azoteq,bottom-speed:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description:
Specifies the speed of movement after which coordinate filtering is
linearly reduced.
Specifies the speed (in coordinates traveled per conversion) after
which coordinate filtering is linearly reduced.
azoteq,bottom-beta:
$ref: /schemas/types.yaml#/definitions/uint32
@ -595,10 +746,10 @@ patternProperties:
minimum: 0
maximum: 4080
description:
Specifies the distance across which a swipe or flick gesture must
travel in order to be acknowledged by the device. The number spec-
ified for any one swipe or flick gesture applies to all remaining
swipe or flick gestures.
Specifies the distance (in coordinates) across which a swipe or
flick gesture must travel in order to be acknowledged by the
device. The number specified for any one swipe or flick gesture
applies to all remaining swipe or flick gestures.
azoteq,gpio-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
@ -610,8 +761,8 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
1: GPIO3 (IQS7222C only)
2: GPIO4 (IQS7222C only)
1: GPIO3
2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
@ -629,8 +780,8 @@ patternProperties:
description: |
Represents a GPIO mapped to one or more events as follows:
gpio-0: GPIO0
gpio-1: GPIO3 (IQS7222C only)
gpio-2: GPIO4 (IQS7222C only)
gpio-1: GPIO3
gpio-2: GPIO4
allOf:
- $ref: ../pinctrl/pincfg-node.yaml#
@ -641,11 +792,53 @@ patternProperties:
additionalProperties: false
allOf:
- $ref: touchscreen/touchscreen.yaml#
- if:
properties:
compatible:
contains:
const: azoteq,iqs7222b
enum:
- azoteq,iqs7222a
- azoteq,iqs7222b
- azoteq,iqs7222c
then:
properties:
touchscreen-size-x: false
touchscreen-size-y: false
touchscreen-inverted-x: false
touchscreen-inverted-y: false
touchscreen-swapped-x-y: false
trackpad: false
patternProperties:
"^channel-([0-9]|1[0-9])$":
properties:
azoteq,counts-filt-enable: false
- if:
properties:
compatible:
contains:
enum:
- azoteq,iqs7222b
- azoteq,iqs7222c
then:
patternProperties:
"^channel-([0-9]|1[0-9])$":
properties:
azoteq,ulp-allow: false
- if:
properties:
compatible:
contains:
enum:
- azoteq,iqs7222b
- azoteq,iqs7222d
then:
patternProperties:
@ -657,13 +850,22 @@ allOf:
properties:
azoteq,ref-select: false
"^slider-[0-1]$": false
- if:
properties:
compatible:
contains:
const: azoteq,iqs7222b
then:
patternProperties:
"^channel-([0-9]|1[0-9])$":
patternProperties:
"^event-(prox|touch)$":
properties:
azoteq,gpio-select: false
"^slider-[0-1]$": false
"^gpio-[0-2]$": false
- if:
@ -704,10 +906,6 @@ allOf:
else:
patternProperties:
"^channel-([0-9]|1[0-9])$":
properties:
azoteq,ulp-allow: false
"^slider-[0-1]$":
patternProperties:
"^event-(press|tap|(swipe|flick)-(pos|neg))$":

41
Documentation/devicetree/bindings/input/stmpe-keypad.txt
View File

@ -1,41 +0,0 @@
* STMPE Keypad
Required properties:
- compatible : "st,stmpe-keypad"
- linux,keymap : See ./matrix-keymap.txt
Optional properties:
- debounce-interval : Debouncing interval time in milliseconds
- st,scan-count : Scanning cycles elapsed before key data is updated
- st,no-autorepeat : If specified device will not autorepeat
- keypad,num-rows : See ./matrix-keymap.txt
- keypad,num-columns : See ./matrix-keymap.txt
Example:
stmpe_keypad {
compatible = "st,stmpe-keypad";
debounce-interval = <64>;
st,scan-count = <8>;
st,no-autorepeat;
linux,keymap = <0x205006b
0x4010074
0x3050072
0x1030004
0x502006a
0x500000a
0x5008b
0x706001c
0x405000b
0x6070003
0x3040067
0x303006c
0x60400e7
0x602009e
0x4020073
0x5050002
0x4030069
0x3020008>;
};

769
Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml Normal file
View File

@ -0,0 +1,769 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/azoteq,iqs7211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Azoteq IQS7210A/7211A/E Trackpad/Touchscreen Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
The Azoteq IQS7210A, IQS7211A and IQS7211E trackpad and touchscreen control-
lers employ projected-capacitance sensing and can track two contacts.
Link to datasheets: https://www.azoteq.com/
properties:
compatible:
enum:
- azoteq,iqs7210a
- azoteq,iqs7211a
- azoteq,iqs7211e
reg:
maxItems: 1
irq-gpios:
maxItems: 1
description:
Specifies the GPIO connected to the device's active-low RDY output. The
pin doubles as the IQS7211E's active-low MCLR input, in which case this
GPIO must be configured as open-drain.
reset-gpios:
maxItems: 1
description:
Specifies the GPIO connected to the device's active-low MCLR input. The
device is temporarily held in hardware reset prior to initialization if
this property is present.
azoteq,forced-comms:
type: boolean
description:
Enables forced communication; to be used with host adapters that cannot
tolerate clock stretching.
azoteq,forced-comms-default:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
description:
Indicates if the device's OTP memory enables (1) or disables (0) forced
communication by default. Specifying this property can expedite startup
time if the default value is known.
If this property is not specified, communication is not initiated until
the device asserts its RDY pin shortly after exiting hardware reset. At
that point, forced communication is either enabled or disabled based on
the presence or absence of the 'azoteq,forced-comms' property.
azoteq,rate-active-ms:
minimum: 0
maximum: 65535
description: Specifies the report rate (in ms) during active mode.
azoteq,rate-touch-ms:
minimum: 0
maximum: 65535
description: Specifies the report rate (in ms) during idle-touch mode.
azoteq,rate-idle-ms:
minimum: 0
maximum: 65535
description: Specifies the report rate (in ms) during idle mode.
azoteq,rate-lp1-ms:
minimum: 0
maximum: 65535
description: Specifies the report rate (in ms) during low-power mode 1.
azoteq,rate-lp2-ms:
minimum: 0
maximum: 65535
description: Specifies the report rate (in ms) during low-power mode 2.
azoteq,timeout-active-ms:
multipleOf: 1000
minimum: 0
maximum: 65535000
description:
Specifies the length of time (in ms) to wait for an event before moving
from active mode to idle or idle-touch modes.
azoteq,timeout-touch-ms:
multipleOf: 1000
minimum: 0
maximum: 65535000
description:
Specifies the length of time (in ms) to wait for an event before moving
from idle-touch mode to idle mode.
azoteq,timeout-idle-ms:
multipleOf: 1000
minimum: 0
maximum: 65535000
description:
Specifies the length of time (in ms) to wait for an event before moving
from idle mode to low-power mode 1.
azoteq,timeout-lp1-ms:
multipleOf: 1000
minimum: 0
maximum: 65535000
description:
Specifies the length of time (in ms) to wait for an event before moving
from low-power mode 1 to low-power mode 2.
azoteq,timeout-lp2-ms:
multipleOf: 1000
minimum: 0
maximum: 60000
description:
Specifies the rate (in ms) at which the trackpad reference values
are updated during low-power modes 1 and 2.
azoteq,timeout-ati-ms:
multipleOf: 1000
minimum: 0
maximum: 60000
description:
Specifies the delay (in ms) before the automatic tuning implementation
(ATI) is retried in the event it fails to complete.
azoteq,timeout-comms-ms:
minimum: 0
maximum: 65535
description:
Specifies the delay (in ms) before a communication window is closed.
azoteq,timeout-press-ms:
multipleOf: 1000
minimum: 0
maximum: 60000
description:
Specifies the length of time (in ms) to wait before automatically
releasing a press event. Specify zero to allow the press state to
persist indefinitely.
azoteq,fosc-freq:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
description: |
Specifies the device's core clock frequency as follows:
0: 14 MHz
1: 18 MHz
azoteq,fosc-trim:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
description: Specifies the device's core clock frequency trim.
azoteq,num-contacts:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 2
default: 0
description: Specifies the number of contacts reported by the device.
azoteq,contact-split:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the contact (finger) split factor.
azoteq,trim-x:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the horizontal trim width.
azoteq,trim-y:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the vertical trim height.
trackpad:
type: object
description: Represents all channels associated with the trackpad.
properties:
azoteq,rx-enable:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
items:
minimum: 0
maximum: 7
description:
Specifies the order of the CRx pin(s) associated with the trackpad.
azoteq,tx-enable:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 12
items:
minimum: 0
maximum: 11
description:
Specifies the order of the CTx pin(s) associated with the trackpad.
azoteq,channel-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 36
items:
minimum: 0
maximum: 255
description: |
Specifies the channels mapped to each cycle in the following order:
Cycle 0, slot 0
Cycle 0, slot 1
Cycle 1, slot 0
Cycle 1, slot 1
...and so on. Specify 255 to disable a given slot.
azoteq,ati-frac-div-fine:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the trackpad's ATI fine fractional divider.
azoteq,ati-frac-mult-coarse:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
description: Specifies the trackpad's ATI coarse fractional multiplier.
azoteq,ati-frac-div-coarse:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the trackpad's ATI coarse fractional divider.
azoteq,ati-comp-div:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the trackpad's ATI compensation divider.
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description: Specifies the trackpad's ATI target.
azoteq,touch-enter:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's touch entrance factor.
azoteq,touch-exit:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's touch exit factor.
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's stationary touch threshold.
azoteq,conv-period:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's conversion period.
azoteq,conv-frac:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the trackpad's conversion frequency fraction.
patternProperties:
"^event-(tap(-double|-triple)?|hold|palm|swipe-(x|y)-(pos|neg)(-hold)?)$":
type: object
$ref: ../input.yaml#
description:
Represents a gesture event reported by the trackpad. In the case of
axial gestures, the duration or distance specified in one direction
applies to both directions along the same axis.
properties:
linux,code: true
azoteq,gesture-max-ms:
minimum: 0
maximum: 65535
description: Specifies the maximum duration of tap/swipe gestures.
azoteq,gesture-mid-ms:
minimum: 0
maximum: 65535
description:
Specifies the maximum duration between subsequent tap gestures
(IQS7211E only).
azoteq,gesture-min-ms:
minimum: 0
maximum: 65535
description: Specifies the minimum duration of hold gestures.
azoteq,gesture-dist:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description:
Specifies the minimum (swipe) or maximum (tap and hold) distance
a finger may travel to be considered a gesture.
azoteq,gesture-dist-rep:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description:
Specifies the minimum distance a finger must travel to elicit a
repeated swipe gesture (IQS7211E only).
azoteq,gesture-angle:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 75
description:
Specifies the maximum angle (in degrees) a finger may travel to
be considered a swipe gesture.
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 42
description: Specifies the palm gesture threshold (IQS7211E only).
additionalProperties: false
dependencies:
azoteq,rx-enable: ["azoteq,tx-enable"]
azoteq,tx-enable: ["azoteq,rx-enable"]
azoteq,channel-select: ["azoteq,rx-enable"]
additionalProperties: false
alp:
type: object
$ref: ../input.yaml#
description: Represents the alternate low-power channel (ALP).
properties:
azoteq,rx-enable:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
items:
minimum: 0
maximum: 7
description:
Specifies the CRx pin(s) associated with the ALP in no particular
order.
azoteq,tx-enable:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 12
items:
minimum: 0
maximum: 11
description:
Specifies the CTx pin(s) associated with the ALP in no particular
order.
azoteq,ati-frac-div-fine:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the ALP's ATI fine fractional divider.
azoteq,ati-frac-mult-coarse:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
description: Specifies the ALP's ATI coarse fractional multiplier.
azoteq,ati-frac-div-coarse:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the ALP's ATI coarse fractional divider.
azoteq,ati-comp-div:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the ALP's ATI compensation divider.
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description: Specifies the ALP's ATI target.
azoteq,ati-base:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 8
minimum: 0
maximum: 255
description: Specifies the ALP's ATI base.
azoteq,ati-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
description: |
Specifies the ALP's ATI mode as follows:
0: Partial
1: Full
azoteq,sense-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
description: |
Specifies the ALP's sensing mode as follows:
0: Self capacitive
1: Mutual capacitive
azoteq,debounce-enter:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the ALP's debounce entrance factor.
azoteq,debounce-exit:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the ALP's debounce exit factor.
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description: Specifies the ALP's proximity or touch threshold.
azoteq,conv-period:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the ALP's conversion period.
azoteq,conv-frac:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the ALP's conversion frequency fraction.
linux,code: true
additionalProperties: false
button:
type: object
description: Represents the inductive or capacitive button.
properties:
azoteq,ati-frac-div-fine:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the button's ATI fine fractional divider.
azoteq,ati-frac-mult-coarse:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
description: Specifies the button's ATI coarse fractional multiplier.
azoteq,ati-frac-div-coarse:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the button's ATI coarse fractional divider.
azoteq,ati-comp-div:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 31
description: Specifies the button's ATI compensation divider.
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description: Specifies the button's ATI target.
azoteq,ati-base:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 8
minimum: 0
maximum: 255
description: Specifies the button's ATI base.
azoteq,ati-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
description: |
Specifies the button's ATI mode as follows:
0: Partial
1: Full
azoteq,sense-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
description: |
Specifies the button's sensing mode as follows:
0: Self capacitive
1: Mutual capacitive
2: Inductive
azoteq,touch-enter:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the button's touch entrance factor.
azoteq,touch-exit:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the button's touch exit factor.
azoteq,debounce-enter:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the button's debounce entrance factor.
azoteq,debounce-exit:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the button's debounce exit factor.
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 65535
description: Specifies the button's proximity threshold.
azoteq,conv-period:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the button's conversion period.
azoteq,conv-frac:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the button's conversion frequency fraction.
patternProperties:
"^event-(prox|touch)$":
type: object
$ref: ../input.yaml#
description:
Represents a proximity or touch event reported by the button.
properties:
linux,code: true
additionalProperties: false
additionalProperties: false
wakeup-source: true
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
dependencies:
touchscreen-size-x: ["azoteq,num-contacts"]
touchscreen-size-y: ["azoteq,num-contacts"]
touchscreen-inverted-x: ["azoteq,num-contacts"]
touchscreen-inverted-y: ["azoteq,num-contacts"]
touchscreen-swapped-x-y: ["azoteq,num-contacts"]
required:
- compatible
- reg
- irq-gpios
additionalProperties: false
allOf:
- $ref: touchscreen.yaml#
- if:
properties:
compatible:
contains:
const: azoteq,iqs7210a
then:
properties:
alp:
properties:
azoteq,rx-enable:
maxItems: 4
items:
minimum: 4
else:
properties:
azoteq,timeout-press-ms: false
alp:
properties:
azoteq,ati-mode: false
button: false
- if:
properties:
compatible:
contains:
const: azoteq,iqs7211e
then:
properties:
reset-gpios: false
trackpad:
properties:
azoteq,tx-enable:
maxItems: 13
items:
maximum: 12
alp:
properties:
azoteq,tx-enable:
maxItems: 13
items:
maximum: 12
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touch@56 {
compatible = "azoteq,iqs7210a";
reg = <0x56>;
irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio 17 (GPIO_ACTIVE_LOW |
GPIO_PUSH_PULL)>;
azoteq,num-contacts = <2>;
trackpad {
azoteq,rx-enable = <6>, <5>, <4>, <3>, <2>;
azoteq,tx-enable = <1>, <7>, <8>, <9>, <10>;
};
button {
azoteq,sense-mode = <2>;
azoteq,touch-enter = <40>;
azoteq,touch-exit = <36>;
event-touch {
linux,code = <KEY_HOME>;
};
};
alp {
azoteq,sense-mode = <1>;
linux,code = <KEY_POWER>;
};
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touch@56 {
compatible = "azoteq,iqs7211e";
reg = <0x56>;
irq-gpios = <&gpio 4 (GPIO_ACTIVE_LOW |
GPIO_OPEN_DRAIN)>;
trackpad {
event-tap {
linux,code = <KEY_PLAYPAUSE>;
};
event-tap-double {
linux,code = <KEY_SHUFFLE>;
};
event-tap-triple {
linux,code = <KEY_AGAIN>;
};
event-hold {
linux,code = <KEY_STOP>;
};
event-palm {
linux,code = <KEY_EXIT>;
};
event-swipe-x-pos {
linux,code = <KEY_REWIND>;
};
event-swipe-x-pos-hold {
linux,code = <KEY_PREVIOUS>;
};
event-swipe-x-neg {
linux,code = <KEY_FASTFORWARD>;
};
event-swipe-x-neg-hold {
linux,code = <KEY_NEXT>;
};
event-swipe-y-pos {
linux,code = <KEY_VOLUMEUP>;
};
event-swipe-y-pos-hold {
linux,code = <KEY_MUTE>;
};
event-swipe-y-neg {
linux,code = <KEY_VOLUMEDOWN>;
};
event-swipe-y-neg-hold {
linux,code = <KEY_MUTE>;
};
};
};
};
...

6
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
View File

@ -93,6 +93,12 @@ properties:
minimum: 1
maximum: 255
threshold:
description: Allows setting the "click"-threshold in the range from 0 to 255.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-fuzz-x: true

2
Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
View File

@ -24,6 +24,8 @@ properties:
maxItems: 1
reset-gpios:
maxItems: 1
vdd-supply:
description: Power supply regulator for the chip
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true

5
Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml
View File

@ -52,6 +52,11 @@ properties:
touchscreen-swapped-x-y: true
touchscreen-max-pressure: true
linux,keycodes:
description: Keycodes for the touch keys
minItems: 1
maxItems: 15
additionalProperties: false
required:

108
Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
View File

@ -1,108 +0,0 @@
STMPE Touchscreen
----------------
Required properties:
- compatible: "st,stmpe-ts"
Optional properties:
- st,ave-ctrl : Sample average control
0 -> 1 sample
1 -> 2 samples
2 -> 4 samples
3 -> 8 samples
- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
0 -> 10 us
1 -> 50 us
2 -> 100 us
3 -> 500 us
4 -> 1 ms
5 -> 5 ms
6 -> 10 ms
7 -> 50 ms
- st,settling : Panel driver settling time (recommended is 2)
0 -> 10 us
1 -> 100 us
2 -> 500 us
3 -> 1 ms
4 -> 5 ms
5 -> 10 ms
6 -> 50 ms
7 -> 100 ms
- st,fraction-z : Length of the fractional part in z (recommended is 7)
(fraction-z ([0..7]) = Count of the fractional part)
- st,i-drive : current limit value of the touchscreen drivers
0 -> 20 mA (typical 35mA max)
1 -> 50 mA (typical 80 mA max)
Optional properties common with MFD (deprecated):
- st,sample-time : ADC conversion time in number of clock.
0 -> 36 clocks
1 -> 44 clocks
2 -> 56 clocks
3 -> 64 clocks
4 -> 80 clocks (recommended)
5 -> 96 clocks
6 -> 124 clocks
- st,mod-12b : ADC Bit mode
0 -> 10bit ADC
1 -> 12bit ADC
- st,ref-sel : ADC reference source
0 -> internal
1 -> external
- st,adc-freq : ADC Clock speed
0 -> 1.625 MHz
1 -> 3.25 MHz
2 || 3 -> 6.5 MHz
Node should be child node of stmpe node to which it belongs.
Note that common ADC settings of stmpe_touchscreen (child) will take precedence
over the settings done in MFD.
Example:
stmpe811@41 {
compatible = "st,stmpe811";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touch_int>;
#address-cells = <1>;
#size-cells = <0>;
reg = <0x41>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio4>;
interrupt-controller;
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
/* Common ADC settings */
/* 3.25 MHz ADC clock speed */
st,adc-freq = <1>;
/* 12-bit ADC */
st,mod-12b = <1>;
/* internal ADC reference */
st,ref-sel = <0>;
/* ADC converstion time: 80 clocks */
st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
reg = <0>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 7 length fractional part in z */
st,fraction-z = <7>;
/*
* 50 mA typical 80 mA max touchscreen drivers
* current limit value
*/
st,i-drive = <1>;
};
stmpe_adc {
compatible = "st,stmpe-adc";
st,norequest-mask = <0x0F>;
};
};

12
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
View File

@ -106,6 +106,12 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 4096
dma-noncoherent:
description:
Present if the GIC redistributors permit programming shareability
and cacheability attributes but are connected to a non-coherent
downstream interconnect.
msi-controller:
description:
Only present if the Message Based Interrupt functionality is
@ -193,6 +199,12 @@ patternProperties:
compatible:
const: arm,gic-v3-its
dma-noncoherent:
description:
Present if the GIC ITS permits programming shareability and
cacheability attributes but is connected to a non-coherent
downstream interconnect.
msi-controller: true
"#msi-cells":

1
Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
View File

@ -37,6 +37,7 @@ properties:
- renesas,intc-ex-r8a77990 # R-Car E3
- renesas,intc-ex-r8a77995 # R-Car D3
- renesas,intc-ex-r8a779a0 # R-Car V3U
- renesas,intc-ex-r8a779f0 # R-Car S4-8
- renesas,intc-ex-r8a779g0 # R-Car V4H
- const: renesas,irqc

230
Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
View File

@ -19,20 +19,19 @@ description: |
- NMI edge select (NMI is not treated as NMI exception and supports fall edge and
stand-up edge detection interrupts)
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
items:
- enum:
- renesas,r9a07g043u-irqc # RZ/G2UL
- renesas,r9a07g044-irqc # RZ/G2{L,LC}
- renesas,r9a07g054-irqc # RZ/V2L
- const: renesas,rzg2l-irqc
'#interrupt-cells':
description: The first cell should contain external interrupt number (IRQ0-7) and the
second cell is used to specify the flag.
description: The first cell should contain a macro RZG2L_{NMI,IRQX} included in the
include/dt-bindings/interrupt-controller/irqc-rzg2l.h and the second
cell is used to specify the flag.
const: 2
'#address-cells':
@ -44,7 +43,96 @@ properties:
maxItems: 1
interrupts:
maxItems: 41
minItems: 41
items:
- description: NMI interrupt
- description: IRQ0 interrupt
- description: IRQ1 interrupt
- description: IRQ2 interrupt
- description: IRQ3 interrupt
- description: IRQ4 interrupt
- description: IRQ5 interrupt
- description: IRQ6 interrupt
- description: IRQ7 interrupt
- description: GPIO interrupt, TINT0
- description: GPIO interrupt, TINT1
- description: GPIO interrupt, TINT2
- description: GPIO interrupt, TINT3
- description: GPIO interrupt, TINT4
- description: GPIO interrupt, TINT5
- description: GPIO interrupt, TINT6
- description: GPIO interrupt, TINT7
- description: GPIO interrupt, TINT8
- description: GPIO interrupt, TINT9
- description: GPIO interrupt, TINT10
- description: GPIO interrupt, TINT11
- description: GPIO interrupt, TINT12
- description: GPIO interrupt, TINT13
- description: GPIO interrupt, TINT14
- description: GPIO interrupt, TINT15
- description: GPIO interrupt, TINT16
- description: GPIO interrupt, TINT17
- description: GPIO interrupt, TINT18
- description: GPIO interrupt, TINT19
- description: GPIO interrupt, TINT20
- description: GPIO interrupt, TINT21
- description: GPIO interrupt, TINT22
- description: GPIO interrupt, TINT23
- description: GPIO interrupt, TINT24
- description: GPIO interrupt, TINT25
- description: GPIO interrupt, TINT26
- description: GPIO interrupt, TINT27
- description: GPIO interrupt, TINT28
- description: GPIO interrupt, TINT29
- description: GPIO interrupt, TINT30
- description: GPIO interrupt, TINT31
- description: Bus error interrupt
interrupt-names:
minItems: 41
items:
- const: nmi
- const: irq0
- const: irq1
- const: irq2
- const: irq3
- const: irq4
- const: irq5
- const: irq6
- const: irq7
- const: tint0
- const: tint1
- const: tint2
- const: tint3
- const: tint4
- const: tint5
- const: tint6
- const: tint7
- const: tint8
- const: tint9
- const: tint10
- const: tint11
- const: tint12
- const: tint13
- const: tint14
- const: tint15
- const: tint16
- const: tint17
- const: tint18
- const: tint19
- const: tint20
- const: tint21
- const: tint22
- const: tint23
- const: tint24
- const: tint25
- const: tint26
- const: tint27
- const: tint28
- const: tint29
- const: tint30
- const: tint31
- const: bus-err
clocks:
maxItems: 2
@ -72,6 +160,23 @@ required:
- power-domains
- resets
allOf:
- $ref: /schemas/interrupt-controller.yaml#
- if:
properties:
compatible:
contains:
const: renesas,r9a07g043u-irqc
then:
properties:
interrupts:
minItems: 42
interrupt-names:
minItems: 42
required:
- interrupt-names
unevaluatedProperties: false
examples:
@ -80,55 +185,66 @@ examples:
#include <dt-bindings/clock/r9a07g044-cpg.h>
irqc: interrupt-controller@110a0000 {
compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc";
reg = <0x110a0000 0x10000>;
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>,
<&cpg CPG_MOD R9A07G044_IA55_PCLK>;
clock-names = "clk", "pclk";
power-domains = <&cpg>;
resets = <&cpg R9A07G044_IA55_RESETN>;
compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc";
reg = <0x110a0000 0x10000>;
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "nmi",
"irq0", "irq1", "irq2", "irq3",
"irq4", "irq5", "irq6", "irq7",
"tint0", "tint1", "tint2", "tint3",
"tint4", "tint5", "tint6", "tint7",
"tint8", "tint9", "tint10", "tint11",
"tint12", "tint13", "tint14", "tint15",
"tint16", "tint17", "tint18", "tint19",
"tint20", "tint21", "tint22", "tint23",
"tint24", "tint25", "tint26", "tint27",
"tint28", "tint29", "tint30", "tint31";
clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>,
<&cpg CPG_MOD R9A07G044_IA55_PCLK>;
clock-names = "clk", "pclk";
power-domains = <&cpg>;
resets = <&cpg R9A07G044_IA55_RESETN>;
};

30
Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
View File

@ -1,30 +0,0 @@
STMicroelectronics STi System Configuration Controlled IRQs
-----------------------------------------------------------
On STi based systems; External, CTI (Core Sight), PMU (Performance Management),
and PL310 L2 Cache IRQs are controlled using System Configuration registers.
This driver is used to unmask them prior to use.
Required properties:
- compatible : Should be "st,stih407-irq-syscfg"
- st,syscfg : Phandle to Cortex-A9 IRQ system config registers
- st,irq-device : Array of IRQs to enable - should be 2 in length
- st,fiq-device : Array of FIQs to enable - should be 2 in length
Optional properties:
- st,invert-ext : External IRQs can be inverted at will. This property inverts
these IRQs using bitwise logic. A number of defines have been
provided for convenience:
ST_IRQ_SYSCFG_EXT_1_INV
ST_IRQ_SYSCFG_EXT_2_INV
ST_IRQ_SYSCFG_EXT_3_INV
Example:
irq-syscfg {
compatible = "st,stih407-irq-syscfg";
st,syscfg = <&syscfg_cpu>;
st,irq-device = <ST_IRQ_SYSCFG_PMU_0>,
<ST_IRQ_SYSCFG_PMU_1>;
st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>,
<ST_IRQ_SYSCFG_DISABLED>;
};

65
Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml Normal file
View File

@ -0,0 +1,65 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/st,stih407-irq-syscfg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STi System Configuration Controlled IRQs
maintainers:
- Patrice Chotard <patrice.chotard@foss.st.com>
description:
On STi based systems; External, CTI (Core Sight), PMU (Performance
Management), and PL310 L2 Cache IRQs are controlled using System
Configuration registers. This device is used to unmask them prior to use.
properties:
compatible:
const: st,stih407-irq-syscfg
st,syscfg:
description: Phandle to Cortex-A9 IRQ system config registers
$ref: /schemas/types.yaml#/definitions/phandle
st,irq-device:
description: Array of IRQs to enable.
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: Enable the IRQ of the channel one.
- description: Enable the IRQ of the channel two.
st,fiq-device:
description: Array of FIQs to enable.
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: Enable the IRQ of the channel one.
- description: Enable the IRQ of the channel two.
st,invert-ext:
description: External IRQs can be inverted at will. This property inverts
these three IRQs using bitwise logic, each one being encoded respectively
on the first, second and fourth bit.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3, 4, 5, 6 ]
required:
- compatible
- st,syscfg
- st,irq-device
- st,fiq-device
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq-st.h>
irq-syscfg {
compatible = "st,stih407-irq-syscfg";
st,syscfg = <&syscfg_cpu>;
st,irq-device = <ST_IRQ_SYSCFG_PMU_0>,
<ST_IRQ_SYSCFG_PMU_1>;
st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>,
<ST_IRQ_SYSCFG_DISABLED>;
};
...

41
Documentation/devicetree/bindings/iommu/arm,smmu.yaml
View File

@ -271,6 +271,47 @@ allOf:
enum:
- qcom,msm8998-smmu-v2
- qcom,sdm630-smmu-v2
then:
anyOf:
- properties:
clock-names:
items:
- const: bus
clocks:
items:
- description: bus clock required for downstream bus access and for
the smmu ptw
- properties:
clock-names:
items:
- const: iface
- const: mem
- const: mem_iface
clocks:
items:
- description: interface clock required to access smmu's registers
through the TCU's programming interface.
- description: bus clock required for memory access
- description: bus clock required for GPU memory access
- properties:
clock-names:
items:
- const: iface-mm
- const: iface-smmu
- const: bus-smmu
clocks:
items:
- description: interface clock required to access mnoc's registers
through the TCU's programming interface.
- description: interface clock required to access smmu's registers
through the TCU's programming interface.
- description: bus clock required for the smmu ptw
- if:
properties:
compatible:
contains:
enum:
- qcom,sm6375-smmu-v2
then:
anyOf:

12
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
View File

@ -78,6 +78,9 @@ properties:
- mediatek,mt8173-m4u # generation two
- mediatek,mt8183-m4u # generation two
- mediatek,mt8186-iommu-mm # generation two
- mediatek,mt8188-iommu-vdo # generation two
- mediatek,mt8188-iommu-vpp # generation two
- mediatek,mt8188-iommu-infra # generation two
- mediatek,mt8192-m4u # generation two
- mediatek,mt8195-iommu-vdo # generation two
- mediatek,mt8195-iommu-vpp # generation two
@ -123,6 +126,7 @@ properties:
description: |
This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as
defined in
dt-binding/memory/mediatek,mt8188-memory-port.h for mt8188,
dt-binding/memory/mt2701-larb-port.h for mt2701 and mt7623,
dt-binding/memory/mt2712-larb-port.h for mt2712,
dt-binding/memory/mt6779-larb-port.h for mt6779,
@ -155,6 +159,8 @@ allOf:
- mediatek,mt6795-m4u
- mediatek,mt8173-m4u
- mediatek,mt8186-iommu-mm
- mediatek,mt8188-iommu-vdo
- mediatek,mt8188-iommu-vpp
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@ -168,6 +174,8 @@ allOf:
compatible:
enum:
- mediatek,mt8186-iommu-mm
- mediatek,mt8188-iommu-vdo
- mediatek,mt8188-iommu-vpp
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@ -194,7 +202,9 @@ allOf:
properties:
compatible:
contains:
const: mediatek,mt8195-iommu-infra
enum:
- mediatek,mt8188-iommu-infra
- mediatek,mt8195-iommu-infra
then:
required:

22
Documentation/devicetree/bindings/iommu/qcom,iommu.yaml
View File

@ -17,11 +17,16 @@ description: |
properties:
compatible:
items:
- enum:
- qcom,msm8916-iommu
- qcom,msm8953-iommu
- const: qcom,msm-iommu-v1
oneOf:
- items:
- enum:
- qcom,msm8916-iommu
- qcom,msm8953-iommu
- const: qcom,msm-iommu-v1
- items:
- enum:
- qcom,msm8976-iommu
- const: qcom,msm-iommu-v2
clocks:
items:
@ -64,6 +69,8 @@ patternProperties:
enum:
- qcom,msm-iommu-v1-ns
- qcom,msm-iommu-v1-sec
- qcom,msm-iommu-v2-ns
- qcom,msm-iommu-v2-sec
interrupts:
maxItems: 1
@ -71,6 +78,11 @@ patternProperties:
reg:
maxItems: 1
qcom,ctx-asid:
$ref: /schemas/types.yaml#/definitions/uint32
description:
The ASID number associated to the context bank.
required:
- compatible
- interrupts

15
Documentation/devicetree/bindings/leds/common.yaml
View File

@ -83,8 +83,7 @@ properties:
- enum:
# LED will act as a back-light, controlled by the framebuffer system
- backlight
# LED will turn on (but for leds-gpio see "default-state" property in
# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
# LED will turn on (see also "default-state" property)
- default-on
# LED "double" flashes at a load average based rate
- heartbeat
@ -158,6 +157,18 @@ properties:
For flash LED controllers with configurable current this property is
mandatory for the LEDs in the non-flash modes (e.g. torch or indicator).
max-brightness:
description:
Normally, the maximum brightness is determined by the hardware, and this
property is not required. This property is used to set a software limit.
It could happen that an LED is made so bright that it gets damaged or
causes damage due to restrictions in a specific system, such as mounting
conditions.
Note that this flag is mainly used for PWM-LEDs, where it is not possible
to map brightness to current. Drivers for other controllers should use
led-max-microamp.
$ref: /schemas/types.yaml#definitions/uint32
panic-indicator:
description:
This property specifies that the LED should be used, if at all possible,

55
Documentation/devicetree/bindings/leds/leds-an30259a.txt
View File

@ -1,55 +0,0 @@
* Panasonic AN30259A 3-channel LED driver
The AN30259A is a LED controller capable of driving three LEDs independently. It supports
constant current output and sloping current output modes. The chip is connected over I2C.
Required properties:
- compatible: Must be "panasonic,an30259a".
- reg: I2C slave address.
- #address-cells: Must be 1.
- #size-cells: Must be 0.
Each LED is represented as a sub-node of the panasonic,an30259a node.
Required sub-node properties:
- reg: Pin that the LED is connected to. Must be 1, 2, or 3.
Optional sub-node properties:
- function :
see Documentation/devicetree/bindings/leds/common.txt
- color :
see Documentation/devicetree/bindings/leds/common.txt
- label :
see Documentation/devicetree/bindings/leds/common.txt (deprecated)
- linux,default-trigger :
see Documentation/devicetree/bindings/leds/common.txt
Example:
#include <dt-bindings/leds/common.h>
led-controller@30 {
compatible = "panasonic,an30259a";
reg = <0x30>;
#address-cells = <1>;
#size-cells = <0>;
led@1 {
reg = <1>;
linux,default-trigger = "heartbeat";
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_RED>;
};
led@2 {
reg = <2>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_GREEN>;
};
led@3 {
reg = <3>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_BLUE>;
};
};

13
Documentation/devicetree/bindings/leds/leds-aw2013.yaml
View File

@ -20,9 +20,20 @@ properties:
reg:
maxItems: 1
interrupts:
maxItems: 1
description: Open-drain, low active interrupt pin "INTN".
Used to report completion of operations (power up, LED breath effects).
vcc-supply:
description: Regulator providing power to the "VCC" pin.
vio-supply:
description: Regulator providing power for pull-up of the I/O lines.
"VIO1" in the typical application circuit example of the datasheet.
Note that this regulator does not directly connect to AW2013, but is
needed for the correct operation of the interrupt and I2C lines.
"#address-cells":
const: 1
@ -52,6 +63,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
i2c {
@ -61,6 +73,7 @@ examples:
led-controller@45 {
compatible = "awinic,aw2013";
reg = <0x45>;
interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
#address-cells = <1>;
#size-cells = <0>;

64
Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml Normal file
View File

@ -0,0 +1,64 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-group-multicolor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Multi-color LED built with monochromatic LEDs
maintainers:
- Jean-Jacques Hiblot <jjhiblot@traphandler.com>
description: |
This driver combines several monochromatic LEDs into one multi-color
LED using the multicolor LED class.
properties:
compatible:
const: leds-group-multicolor
leds:
description:
An aray of monochromatic leds
$ref: /schemas/types.yaml#/definitions/phandle-array
required:
- leds
allOf:
- $ref: leds-class-multicolor.yaml#
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
monochromatic-leds {
compatible = "gpio-leds";
led0: led-0 {
gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
color = <LED_COLOR_ID_RED>;
};
led1: led-1 {
gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_GREEN>;
};
led2: led-2 {
gpios = <&mcu_pio 2 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_BLUE>;
};
};
multi-led {
compatible = "leds-group-multicolor";
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_INDICATOR;
leds = <&led0>, <&led1>, <&led2>;
};
...

4
Documentation/devicetree/bindings/leds/nxp,pca953x.yaml
View File

@ -29,6 +29,10 @@ properties:
gpio-controller: true
gpio-line-names:
minItems: 1
maxItems: 16
'#gpio-cells':
const: 2

81
Documentation/devicetree/bindings/leds/nxp,pca995x.yaml Normal file
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/leds/nxp,pca995x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP PCA995x LED controllers
maintainers:
- Isai Gaspar <isaiezequiel.gaspar@nxp.com>
- Marek Vasut <marex@denx.de>
description:
The NXP PCA9952/PCA9955B are programmable LED controllers connected via I2C
that can drive 16 separate lines. Each of them can be individually switched
on and off, and brightness can be controlled via individual PWM.
Datasheets are available at
https://www.nxp.com/docs/en/data-sheet/PCA9952_PCA9955.pdf
https://www.nxp.com/docs/en/data-sheet/PCA9955B.pdf
properties:
compatible:
enum:
- nxp,pca9952
- nxp,pca9955b
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^led@[0-9a-f]+$":
type: object
$ref: common.yaml#
unevaluatedProperties: false
properties:
reg:
minimum: 0
maximum: 15
required:
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@1 {
compatible = "nxp,pca9955b";
reg = <0x01>;
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0x0>;
color = <LED_COLOR_ID_RED>;
function = LED_FUNCTION_POWER;
};
led@2 {
reg = <0x2>;
color = <LED_COLOR_ID_WHITE>;
function = LED_FUNCTION_STATUS;
};
};
};
...

84
Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml Normal file
View File

@ -0,0 +1,84 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/panasonic,an30259a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Panasonic AN30259A 3-channel LED controller
maintainers:
- Iskren Chernev <me@iskren.info>
description:
The AN30259A is a LED controller capable of driving three LEDs independently.
It supports constant current output and sloping current output modes. The chip
is connected over I2C.
properties:
compatible:
const: panasonic,an30259a
reg:
maxItems: 1
interrupts:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^led@[1-3]$":
$ref: common.yaml#
unevaluatedProperties: false
properties:
reg:
enum: [ 1, 2, 3 ]
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@30 {
compatible = "panasonic,an30259a";
reg = <0x30>;
#address-cells = <1>;
#size-cells = <0>;
led@1 {
reg = <1>;
linux,default-trigger = "heartbeat";
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_RED>;
};
led@2 {
reg = <2>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_GREEN>;
};
led@3 {
reg = <3>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_BLUE>;
};
};
};
...

4
Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml
View File

@ -35,7 +35,7 @@ properties:
description: GPIO pin to enable/disable the device.
patternProperties:
"^led@[0-6]$":
"^led@[0-5]$":
type: object
$ref: common.yaml#
unevaluatedProperties: false
@ -43,7 +43,7 @@ patternProperties:
properties:
reg:
minimum: 0
maximum: 6
maximum: 5
required:
- reg

2
Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
View File

@ -18,8 +18,6 @@ description: |
The device has two LED outputs referred as GRNLED and AMBLED in data-sheet.
select: false
properties:
compatible:
const: rohm,bd71828-leds

41
Documentation/devicetree/bindings/media/i2c/ov5695.txt
View File

@ -1,41 +0,0 @@
* Omnivision OV5695 MIPI CSI-2 sensor
Required Properties:
- compatible: shall be "ovti,ov5695"
- clocks: reference to the xvclk input clock
- clock-names: shall be "xvclk"
- avdd-supply: Analog voltage supply, 2.8 volts
- dovdd-supply: Digital I/O voltage supply, 1.8 volts
- dvdd-supply: Digital core voltage supply, 1.2 volts
- reset-gpios: Low active reset gpio
The device node shall contain one 'port' child node with an
'endpoint' subnode for its digital output video port,
in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The endpoint optional property 'data-lanes' shall be "<1 2>".
Example:
&i2c7 {
ov5695: camera-sensor@36 {
compatible = "ovti,ov5695";
reg = <0x36>;
pinctrl-names = "default";
pinctrl-0 = <&clk_24m_cam>;
clocks = <&cru SCLK_TESTCLKOUT1>;
clock-names = "xvclk";
avdd-supply = <&pp2800_cam>;
dovdd-supply = <&pp1800>;
dvdd-supply = <&pp1250_cam>;
reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
port {
wcam_out: endpoint {
remote-endpoint = <&mipi_in_wcam>;
data-lanes = <1 2>;
};
};
};
};

52
Documentation/devicetree/bindings/media/i2c/ov7251.txt
View File

@ -1,52 +0,0 @@
* Omnivision 1/7.5-Inch B&W VGA CMOS Digital Image Sensor
The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
with an active array size of 640H x 480V. It is programmable through a serial
I2C interface.
Required Properties:
- compatible: Value should be "ovti,ov7251".
- clocks: Reference to the xclk clock.
- clock-names: Should be "xclk".
- clock-frequency: Frequency of the xclk clock.
- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
to the hardware pin XSHUTDOWN which is physically active low.
- vdddo-supply: Chip digital IO regulator.
- vdda-supply: Chip analog regulator.
- vddd-supply: Chip digital core regulator.
The device node shall contain one 'port' child node with a single 'endpoint'
subnode for its digital output video port, in accordance with the video
interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
&i2c1 {
...
ov7251: camera-sensor@60 {
compatible = "ovti,ov7251";
reg = <0x60>;
enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&camera_bw_default>;
clocks = <&clks 200>;
clock-names = "xclk";
clock-frequency = <24000000>;
vdddo-supply = <&camera_dovdd_1v8>;
vdda-supply = <&camera_avdd_2v8>;
vddd-supply = <&camera_dvdd_1v2>;
port {
ov7251_ep: endpoint {
clock-lanes = <1>;
data-lanes = <0>;
remote-endpoint = <&csi0_ep>;
};
};
};
};

31
Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
View File

@ -5,26 +5,41 @@
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5693.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Omnivision OV5693 CMOS Sensor
title: Omnivision OV5693/OV5695 CMOS Sensors
maintainers:
- Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
description: |
The Omnivision OV5693 is a high performance, 1/4-inch, 5 megapixel, CMOS
image sensor that delivers 2592x1944 at 30fps. It provides full-frame,
The Omnivision OV5693/OV5695 are high performance, 1/4-inch, 5 megapixel, CMOS
image sensors that deliver 2592x1944 at 30fps. It provides full-frame,
sub-sampled, and windowed 10-bit MIPI images in various formats via the
Serial Camera Control Bus (SCCB) interface.
OV5693 is controlled via I2C and two-wire Serial Camera Control Bus (SCCB).
The sensor output is available via CSI-2 serial data output (up to 2-lane).
OV5693/OV5695 are controlled via I2C and two-wire Serial Camera Control Bus
(SCCB). The sensor output is available via CSI-2 serial data output (up to
2-lane).
allOf:
- $ref: /schemas/media/video-interface-devices.yaml#
- if:
properties:
compatible:
contains:
const: ovti,ov5693
then:
properties:
port:
properties:
endpoint:
required:
- link-frequencies
properties:
compatible:
const: ovti,ov5693
enum:
- ovti,ov5693
- ovti,ov5695
reg:
maxItems: 1
@ -34,6 +49,9 @@ properties:
System input clock (aka XVCLK). From 6 to 27 MHz.
maxItems: 1
clock-names:
const: xvclk
dovdd-supply:
description:
Digital I/O voltage supply, 1.8V.
@ -72,7 +90,6 @@ properties:
required:
- data-lanes
- link-frequencies
required:
- compatible

109
Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml Normal file
View File

@ -0,0 +1,109 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov7251.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OmniVision OV7251 Image Sensor
description:
The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
with an active array size of 640H x 480V. It is programmable through a serial
I2C interface.
maintainers:
- Todor Tomov <todor.too@gmail.com>
properties:
compatible:
const: ovti,ov7251
reg:
maxItems: 1
clocks:
description: XCLK Input Clock
clock-names:
const: xclk
clock-frequency:
description: Frequency of the xclk clock in Hz.
vdda-supply:
description: Analog voltage supply, 2.8 volts
vddd-supply:
description: Digital core voltage supply, 1.2 volts
vdddo-supply:
description: Digital I/O voltage supply, 1.8 volts
enable-gpios:
maxItems: 1
description:
Reference to the GPIO connected to the XSHUTDOWN pin, if any. Polarity
is GPIO_ACTIVE_HIGH.
port:
description: Digital Output Port
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
clock-lanes:
maximum: 1
data-lanes:
maxItems: 1
link-frequencies: true
required:
- data-lanes
- link-frequencies
required:
- compatible
- reg
- clocks
- vdddo-supply
- vdda-supply
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
camera@3c {
compatible = "ovti,ov7251";
reg = <0x3c>;
clocks = <&clks 1>;
clock-frequency = <24000000>;
vdddo-supply = <&ov7251_vdddo_1v8>;
vdda-supply = <&ov7251_vdda_2v8>;
vddd-supply = <&ov7251_vddd_1v5>;
enable-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
port {
ov7251_ep: endpoint {
remote-endpoint = <&csi0_ep>;
clock-lanes = <1>;
data-lanes = <0>;
link-frequencies = /bits/ 64 <240000000 319200000>;
};
};
};
};
...

1
Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
View File

@ -54,6 +54,7 @@ properties:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
properties:
endpoint:

2
Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
View File

@ -69,6 +69,7 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: Input port
properties:
@ -89,6 +90,7 @@ properties:
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: Output port
properties:

1
Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
View File

@ -59,7 +59,6 @@ allOf:
compatible:
contains:
enum:
- fsl,imx8mq-csi
- fsl,imx8mm-csi
then:
required:

4
Documentation/devicetree/bindings/media/renesas,vin.yaml
View File

@ -95,7 +95,7 @@ properties:
synchronization is selected.
default: 1
field-active-even: true
field-even-active: true
bus-width: true
@ -144,7 +144,7 @@ properties:
synchronization is selected.
default: 1
field-active-even: true
field-even-active: true
bus-width: true

1
Documentation/devicetree/bindings/media/rockchip-isp1.yaml
View File

@ -199,6 +199,7 @@ examples:
wcam: camera@36 {
compatible = "ovti,ov5695";
reg = <0x36>;
clocks = <&cru SCLK_TESTCLKOUT1>;
port {
wcam_out: endpoint {

1
Documentation/devicetree/bindings/media/samsung,fimc.yaml
View File

@ -57,6 +57,7 @@ properties:
patternProperties:
"^port@[01]$":
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Camera A and camera B inputs.

43
Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
View File

@ -34,6 +34,9 @@ patternProperties:
- allwinner,sun6i-a31-clock-reset
- fixed-factor-clock
required:
- compatible
allOf:
- if:
properties:
@ -55,25 +58,17 @@ patternProperties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 2
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
@ -85,25 +80,17 @@ patternProperties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
@ -119,9 +106,6 @@ patternProperties:
offset of the bit controlling this particular gate in
the register.
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
@ -129,16 +113,11 @@ patternProperties:
minItems: 1
maxItems: 32
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
@ -150,9 +129,6 @@ patternProperties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 4
description: >
@ -162,16 +138,11 @@ patternProperties:
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
@ -183,16 +154,8 @@ patternProperties:
"#reset-cells":
const: 1
# Already checked in the main schema
compatible: true
phandle: true
required:
- "#reset-cells"
- compatible
additionalProperties: false
required:
- compatible

42
Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
View File

@ -57,25 +57,17 @@ patternProperties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
@ -91,9 +83,6 @@ patternProperties:
offset of the bit controlling this particular gate in
the register.
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
@ -101,16 +90,11 @@ patternProperties:
minItems: 1
maxItems: 32
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
@ -122,34 +106,8 @@ patternProperties:
"#reset-cells":
const: 1
# Already checked in the main schema
compatible: true
phandle: true
required:
- "#reset-cells"
- compatible
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-a23-codec-analog
then:
properties:
# Already checked in the main schema
compatible: true
phandle: true
required:
- compatible
additionalProperties: false
required:
- compatible

1
Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
View File

@ -6,6 +6,7 @@ at boot time according to the device tree.
Required properties:
- compatible: Should be "atmel,sama5d2-flexcom"
or "microchip,sam9x7-flexcom", "atmel,sama5d2-flexcom"
- reg: Should be the offset/length value for Flexcom dedicated
I/O registers (without USART, TWI or SPI registers).
- clocks: Should be the Flexcom peripheral clock from PMC.

1
Documentation/devicetree/bindings/mfd/atmel-gpbr.txt
View File

@ -6,6 +6,7 @@ Required properties:
- compatible: Should be one of the following:
"atmel,at91sam9260-gpbr", "syscon"
"microchip,sam9x60-gpbr", "syscon"
"microchip,sam9x7-gpbr", "microchip,sam9x60-gpbr", "syscon"
- reg: contains offset/length value of the GPBR memory
region.

1
Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
View File

@ -8,6 +8,7 @@ Required properties:
"atmel,sama5d3-hlcdc"
"atmel,sama5d4-hlcdc"
"microchip,sam9x60-hlcdc"
"microchip,sam9x75-xlcdc"
- reg: base address and size of the HLCDC device registers.
- clock-names: the name of the 3 clocks requested by the HLCDC device.
Should contain "periph_clk", "sys_clk" and "slow_clk".

1
Documentation/devicetree/bindings/mfd/atmel-matrix.txt
View File

@ -14,6 +14,7 @@ Required properties:
"atmel,at91sam9x5-matrix", "syscon"
"atmel,sama5d3-matrix", "syscon"
"microchip,sam9x60-matrix", "syscon"
"microchip,sam9x7-matrix", "atmel,at91sam9x5-matrix", "syscon"
- reg: Contains offset/length value of the Bus Matrix
memory region.

1
Documentation/devicetree/bindings/mfd/atmel-smc.txt
View File

@ -10,6 +10,7 @@ Required properties:
"atmel,sama5d3-smc", "syscon"
"atmel,sama5d2-smc", "syscon"
"microchip,sam9x60-smc", "syscon"
"microchip,sam9x7-smc", "atmel,at91sam9260-smc", "syscon"
- reg: Contains offset/length value of the SMC memory
region.

4
Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
View File

@ -35,7 +35,7 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm63xx-gpio.yaml"
$ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@ -44,7 +44,7 @@ patternProperties:
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6318-pinctrl.yaml"
$ref: /schemas/pinctrl/brcm,bcm6318-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in

4
Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
View File

@ -35,7 +35,7 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm63xx-gpio.yaml"
$ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@ -44,7 +44,7 @@ patternProperties:
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm63268-pinctrl.yaml"
$ref: /schemas/pinctrl/brcm,bcm63268-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in

4
Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
View File

@ -35,7 +35,7 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm63xx-gpio.yaml"
$ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@ -44,7 +44,7 @@ patternProperties:
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6328-pinctrl.yaml"
$ref: /schemas/pinctrl/brcm,bcm6328-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in

4
Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
View File

@ -35,7 +35,7 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm63xx-gpio.yaml"
$ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@ -44,7 +44,7 @@ patternProperties:
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6358-pinctrl.yaml"
$ref: /schemas/pinctrl/brcm,bcm6358-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in

4
Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
View File

@ -35,7 +35,7 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm63xx-gpio.yaml"
$ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@ -44,7 +44,7 @@ patternProperties:
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6362-pinctrl.yaml"
$ref: /schemas/pinctrl/brcm,bcm6362-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in

4
Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
View File

@ -35,7 +35,7 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm63xx-gpio.yaml"
$ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
@ -44,7 +44,7 @@ patternProperties:
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6368-pinctrl.yaml"
$ref: /schemas/pinctrl/brcm,bcm6368-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in

48
Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
View File

@ -37,6 +37,7 @@ properties:
max77693-muic:
type: object
additionalProperties: false
deprecated: true
properties:
compatible:
@ -45,6 +46,21 @@ properties:
required:
- compatible
muic:
type: object
additionalProperties: false
properties:
compatible:
const: maxim,max77693-muic
connector:
$ref: /schemas/connector/usb-connector.yaml#
unevaluatedProperties: false
required:
- compatible
motor-driver:
type: object
additionalProperties: false
@ -107,6 +123,38 @@ examples:
};
};
muic {
compatible = "maxim,max77693-muic";
connector {
compatible = "samsung,usb-connector-11pin",
"usb-b-connector";
label = "micro-USB";
type = "micro";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
muic_to_usb: endpoint {
remote-endpoint = <&usb_to_muic>;
};
};
port@3 {
reg = <3>;
muic_to_mhl: endpoint {
remote-endpoint = <&mhl_to_muic>;
};
};
};
};
};
motor-driver {
compatible = "maxim,max77693-haptic";
haptic-supply = <&ldo26_reg>;

6
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
View File

@ -41,6 +41,7 @@ properties:
- qcom,pm660
- qcom,pm660l
- qcom,pm7250b
- qcom,pm7550ba
- qcom,pm7325
- qcom,pm8004
- qcom,pm8005
@ -70,6 +71,8 @@ properties:
- qcom,pm8994
- qcom,pm8998
- qcom,pma8084
- qcom,pmc8180
- qcom,pmc8180c
- qcom,pmd9635
- qcom,pmi632
- qcom,pmi8950
@ -88,6 +91,7 @@ properties:
- qcom,pms405
- qcom,pmx55
- qcom,pmx65
- qcom,pmx75
- qcom,smb2351
- const: qcom,spmi-pmic
@ -127,7 +131,7 @@ patternProperties:
"^audio-codec@[0-9a-f]+$":
type: object
additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet
$ref: /schemas/sound/qcom,pm8916-wcd-analog-codec.yaml#
"^charger@[0-9a-f]+$":
type: object

1
Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
View File

@ -130,7 +130,6 @@ dependencies:
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
i2c {
#address-cells = <1>;

297
Documentation/devicetree/bindings/mfd/st,stmpe.yaml Normal file
View File

@ -0,0 +1,297 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/st,stmpe.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectonics Port Expander (STMPE)
description: STMicroelectronics Port Expander (STMPE) is a series of slow
bus controllers for various expanded peripherals such as GPIO, keypad,
touchscreen, ADC, PWM or rotator. It can contain one or several different
peripherals connected to SPI or I2C.
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
enum:
- st,stmpe601
- st,stmpe801
- st,stmpe811
- st,stmpe1600
- st,stmpe1601
- st,stmpe2401
- st,stmpe2403
reg:
maxItems: 1
interrupts:
maxItems: 1
vcc-supply: true
vio-supply: true
reset-gpios:
maxItems: 1
wakeup-source: true
st,autosleep-timeout:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 4, 16, 32, 64, 128, 256, 512, 1024 ]
description: Time idle before going to automatic sleep to save power
st,sample-time:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3, 4, 5, 6 ]
description: |
Sample time per iteration
0 = 36 clock ticks
1 = 44 clock ticks
2 = 56 clock ticks
3 = 64 clock ticks
4 = 80 clock ticks - recommended
5 = 96 clock ticks
6 = 124 clock ticks
st,mod-12b:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description: ADC bit mode 0 = 10bit ADC, 1 = 12bit ADC
st,ref-sel:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description: ADC reference source 0 = internal, 1 = external
st,adc-freq:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3 ]
description: |
ADC clock speed
0 = 1.625 MHz
1 = 3.25 MHz
2, 3 = 6.5 MHz
adc:
type: object
$ref: /schemas/iio/adc/st,stmpe-adc.yaml#
gpio:
type: object
$ref: /schemas/gpio/st,stmpe-gpio.yaml#
keyboard-controller:
type: object
$ref: /schemas/input/matrix-keymap.yaml#
unevaluatedProperties: false
properties:
compatible:
const: st,stmpe-keypad
debounce-interval:
description: Debouncing interval in milliseconds
$ref: /schemas/types.yaml#/definitions/uint32
st,no-autorepeat:
description: If present, the keys will not autorepeat when pressed
$ref: /schemas/types.yaml#/definitions/flag
st,scan-count:
description: Scanning cycles elapsed before key data is updated
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
- linux,keymap
pwm:
type: object
$ref: /schemas/pwm/pwm.yaml#
unevaluatedProperties: false
properties:
compatible:
const: st,stmpe-pwm
"#pwm-cells":
const: 2
touchscreen:
type: object
$ref: /schemas/input/touchscreen/touchscreen.yaml#
unevaluatedProperties: false
properties:
compatible:
const: st,stmpe-ts
st,ave-ctrl:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3 ]
description: |
Sample average control
0 = 1 sample
1 = 2 samples
2 = 4 samples
3 = 8 samples
st,touch-det-delay:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
description: |
Touch detection delay
0 = 10 us
1 = 50 us
2 = 100 us
3 = 500 us - recommended
4 = 1 ms
5 = 5 ms
6 = 10 ms
7 = 50 ms
st,settling:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
description: |
Panel driver settling time
0 = 10 us
1 = 100 us
2 = 500 us - recommended
3 = 1 ms
4 = 5 ms
5 = 10 ms
6 = 50 ms
7 = 100 ms
st,fraction-z:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
description: Length of the fractional part in z, recommended is 7
(fraction-z ([0..7]) = Count of the fractional part)
st,i-drive:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
description: |
current limit value of the touchscreen drivers
0 = 20 mA (typical 35 mA max)
1 = 50 mA (typical 80 mA max)
required:
- compatible
additionalProperties: false
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/input.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
port-expander@43 {
compatible = "st,stmpe2401";
reg = <0x43>;
reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
interrupt-parent = <&gpio>;
vcc-supply = <&db8500_vsmps2_reg>;
vio-supply = <&db8500_vsmps2_reg>;
wakeup-source;
st,autosleep-timeout = <1024>;
gpio {
compatible = "st,stmpe-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
st,norequest-mask = <0xf0f002>;
};
keyboard-controller {
compatible = "st,stmpe-keypad";
debounce-interval = <64>;
st,scan-count = <8>;
st,no-autorepeat;
keypad,num-rows = <8>;
keypad,num-columns = <8>;
linux,keymap = <
MATRIX_KEY(0x00, 0x00, KEY_1)
MATRIX_KEY(0x00, 0x01, KEY_2)
MATRIX_KEY(0x00, 0x02, KEY_3)
MATRIX_KEY(0x00, 0x03, KEY_4)
MATRIX_KEY(0x00, 0x04, KEY_5)
MATRIX_KEY(0x00, 0x05, KEY_6)
MATRIX_KEY(0x00, 0x06, KEY_7)
MATRIX_KEY(0x00, 0x07, KEY_8)
MATRIX_KEY(0x00, 0x08, KEY_9)
MATRIX_KEY(0x00, 0x09, KEY_0)
>;
};
pwm {
compatible = "st,stmpe-pwm";
#pwm-cells = <2>;
};
};
port-expander@41 {
compatible = "st,stmpe811";
reg = <0x41>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio>;
st,adc-freq = <1>;
st,mod-12b = <1>;
st,ref-sel = <0>;
st,sample-time = <4>;
adc {
compatible = "st,stmpe-adc";
st,norequest-mask = <0x0f>;
#io-channel-cells = <1>;
};
gpio {
compatible = "st,stmpe-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
pwm {
compatible = "st,stmpe-pwm";
#pwm-cells = <2>;
};
touchscreen {
compatible = "st,stmpe-ts";
st,ave-ctrl = <3>;
st,touch-det-delay = <5>;
st,settling = <3>;
st,fraction-z = <7>;
st,i-drive = <1>;
};
};
};
...

12
Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
View File

@ -106,6 +106,7 @@ properties:
const: st,stpmic1-regulators
ldo3:
$ref: /schemas/regulator/regulator.yaml
type: object
properties:
@ -128,6 +129,7 @@ properties:
additionalProperties: false
ldo4:
$ref: /schemas/regulator/regulator.yaml
type: object
properties:
@ -142,11 +144,14 @@ properties:
regulator-name: true
regulator-boot-on: true
regulator-always-on: true
regulator-min-microvolt: true
regulator-max-microvolt: true
regulator-over-current-protection: true
additionalProperties: false
vref_ddr:
$ref: /schemas/regulator/regulator.yaml
type: object
properties:
@ -165,6 +170,7 @@ properties:
additionalProperties: false
boost:
$ref: /schemas/regulator/regulator.yaml
type: object
properties:
@ -187,10 +193,8 @@ properties:
"^(buck[1-4]|ldo[1-6]|vref_ddr|boost|pwr_sw[1-2])-supply$":
description: STPMIC1 voltage regulators supplies
"^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
$ref: ../regulator/regulator.yaml
"^ldo[1-2,5-6]$":
$ref: /schemas/regulator/regulator.yaml
type: object
properties:
@ -213,6 +217,7 @@ properties:
additionalProperties: false
"^buck[1-4]$":
$ref: /schemas/regulator/regulator.yaml
type: object
properties:
@ -237,6 +242,7 @@ properties:
additionalProperties: false
"^pwr_sw[1-2]$":
$ref: /schemas/regulator/regulator.yaml
type: object
properties:

20
Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
View File

@ -72,44 +72,52 @@ properties:
main voltage domain for the chip.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_varm:
description: The voltage for the ARM Cortex A-9 CPU.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_vmodem:
description: The voltage for the modem subsystem.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_vpll:
description: The voltage for the phase locked loop clocks.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_vsmps1:
description: Also known as VIO12, is a step-down voltage regulator
for 1.2V I/O. SMPS means System Management Power Source.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_vsmps2:
description: Also known as VIO18, is a step-down voltage regulator
for 1.8V I/O. SMPS means System Management Power Source.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_vsmps3:
description: This is a step-down voltage regulator
for 0.87 thru 1.875V I/O. SMPS means System Management Power Source.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_vrf1:
description: RF transceiver voltage regulator.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sva_mmdsp:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
@ -117,18 +125,21 @@ properties:
for video encoding and decoding.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sva_mmdsp_ret:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator for retention mode.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sva_pipe:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator for the data pipe.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sia_mmdsp:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
@ -136,18 +147,21 @@ properties:
for image encoding and decoding.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sia_mmdsp_ret:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator for retention mode.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sia_pipe:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator for the data pipe.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_sga:
description: Smart Graphics Accelerator (SGA) voltage regulator.
@ -155,6 +169,7 @@ properties:
accelerator block.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_b2r2_mcde:
description: Blit Blend Rotate and Rescale (B2R2), and Multi-Channel
@ -162,28 +177,33 @@ properties:
blocks.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_esram12:
description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_esram12_ret:
description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator for
retention mode.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_esram34:
description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
db8500_esram34_ret:
description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator for
retention mode.
type: object
$ref: ../regulator/regulator.yaml#
unevaluatedProperties: false
required:
- compatible

42
Documentation/devicetree/bindings/mfd/stmpe.txt
View File

@ -1,42 +0,0 @@
* ST Microelectronics STMPE Multi-Functional Device
STMPE is an MFD device which may expose the following inbuilt devices: gpio,
keypad, touchscreen, adc, pwm, rotator.
Required properties:
- compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
- reg : I2C/SPI address of the device
Optional properties:
- interrupts : The interrupt outputs from the controller
- interrupt-controller : Marks the device node as an interrupt controller
- wakeup-source : Marks the input device as wakable
- st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
- irq-gpio : If present, which GPIO to use for event IRQ
Optional properties for devices with touch and ADC (STMPE811|STMPE610):
- st,sample-time : ADC conversion time in number of clock.
0 -> 36 clocks 4 -> 80 clocks (recommended)
1 -> 44 clocks 5 -> 96 clocks
2 -> 56 clocks 6 -> 124 clocks
3 -> 64 clocks
- st,mod-12b : ADC Bit mode
0 -> 10bit ADC 1 -> 12bit ADC
- st,ref-sel : ADC reference source
0 -> internal 1 -> external
- st,adc-freq : ADC Clock speed
0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
1 -> 3.25 MHz
Example:
stmpe1601: stmpe1601@40 {
compatible = "st,stmpe1601";
reg = <0x40>;
interrupts = <26 0x4>;
interrupt-parent = <&gpio6>;
interrupt-controller;
wakeup-source;
st,autosleep-timeout = <1024>;
};

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