github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-05-24 15:12:13 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

Merge branch 'for-5.14/amd-sfh' into for-linus

Browse Source 
- support for Renoir and Cezanne SoCs
- support for Ambient Light Sensor
- support for Human Presence Detection sensor

all from Basavaraj Natikar
This commit is contained in:
Jiri Kosina 2021-06-30 09:02:28 +02:00
commit 5a94296bc0
3566 changed files with 105723 additions and 39075 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.gitignore vendored
View File

@ -48,14 +48,11 @@
*.xz
*.zst
Module.symvers
modules.builtin
modules.order
#
# Top-level generic files
#
/tags
/TAGS
/linux
/modules-only.symvers
/vmlinux
@ -66,6 +63,7 @@ modules.order
/vmlinuz
/System.map
/Module.markers
/modules.builtin
/modules.builtin.modinfo
/modules.nsdeps
@ -114,6 +112,10 @@ patches-*
patches
series
# ctags files
tags
TAGS
# cscope files
cscope.*
ncscope.*

1
.mailmap
View File

@ -160,6 +160,7 @@ Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
Jens Axboe <axboe@suse.de>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>

5
CREDITS
View File

@ -1874,6 +1874,11 @@ S: Krosenska' 543
S: 181 00 Praha 8
S: Czech Republic
N: Murali Karicheri
E: m-karicheri2@ti.com
D: Keystone NetCP driver
D: Keystone PCIe host controller driver
N: Jan "Yenya" Kasprzak
E: kas@fi.muni.cz
D: Author of the COSA/SRP sync serial board driver.

2
Documentation/ABI/obsolete/sysfs-class-dax
View File

@ -1,7 +1,7 @@
What: /sys/class/dax/
Date: May, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description: Device DAX is the device-centric analogue of Filesystem
DAX (CONFIG_FS_DAX). It allows memory ranges to be
allocated and mapped without need of an intervening file

2
Documentation/ABI/obsolete/sysfs-kernel-fadump_registered
View File

@ -1,4 +1,4 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.
What: /sys/kernel/fadump_registered
Date: Feb 2012

2
Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem
View File

@ -1,4 +1,4 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.
What: /sys/kernel/fadump_release_mem
Date: Feb 2012

2
Documentation/ABI/removed/sysfs-bus-nfit
View File

@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/regionX/nfit/ecc_unit_size
Date: Aug, 2017
KernelVersion: v4.14 (Removed v4.18)
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Size of a write request to a DIMM that will not incur a
read-modify-write cycle at the memory controller.

14
Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe Normal file
View File

@ -0,0 +1,14 @@
What: /sys/bus/coresight/devices/trbe<cpu>/align
Date: March 2021
KernelVersion: 5.13
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows the TRBE write pointer alignment. This value
is fetched from the TRBIDR register.
What: /sys/bus/coresight/devices/trbe<cpu>/flag
Date: March 2021
KernelVersion: 5.13
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows if TRBE updates in the memory are with access
and dirty flag updates as well. This value is fetched from
the TRBIDR register.

30
Documentation/ABI/testing/sysfs-bus-event_source-devices-dsa Normal file
View File

@ -0,0 +1,30 @@
What: /sys/bus/event_source/devices/dsa*/format
Date: April 2021
KernelVersion: 5.13
Contact: Tom Zanussi <tom.zanussi@linux.intel.com>
Description: Read-only. Attribute group to describe the magic bits
that go into perf_event_attr.config or
perf_event_attr.config1 for the IDXD DSA pmu. (See also
ABI/testing/sysfs-bus-event_source-devices-format).
Each attribute in this group defines a bit range in
perf_event_attr.config or perf_event_attr.config1.
All supported attributes are listed below (See the
IDXD DSA Spec for possible attribute values)::
event_category = "config:0-3" - event category
event = "config:4-31" - event ID
filter_wq = "config1:0-31" - workqueue filter
filter_tc = "config1:32-39" - traffic class filter
filter_pgsz = "config1:40-43" - page size filter
filter_sz = "config1:44-51" - transfer size filter
filter_eng = "config1:52-59" - engine filter
What: /sys/bus/event_source/devices/dsa*/cpumask
Date: April 2021
KernelVersion: 5.13
Contact: Tom Zanussi <tom.zanussi@linux.intel.com>
Description: Read-only. This file always returns the cpu to which the
IDXD DSA pmu is bound for access to all dsa pmu
performance monitoring events.

40
Documentation/ABI/testing/sysfs-bus-nfit
View File

@ -5,7 +5,7 @@ Interface Table (NFIT)' section in the ACPI specification
What: /sys/bus/nd/devices/nmemX/nfit/serial
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Serial number of the NVDIMM (non-volatile dual in-line
memory module), assigned by the module vendor.
@ -14,7 +14,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/handle
Date: Apr, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The address (given by the _ADR object) of the device on its
parent bus of the NVDIMM device containing the NVDIMM region.
@ -23,7 +23,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/device
Date: Apr, 2015
KernelVersion: v4.1
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Device id for the NVDIMM, assigned by the module vendor.
@ -31,7 +31,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/rev_id
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Revision of the NVDIMM, assigned by the module vendor.
@ -39,7 +39,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/phys_id
Date: Apr, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Handle (i.e., instance number) for the SMBIOS (system
management BIOS) Memory Device structure describing the NVDIMM
@ -49,7 +49,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/flags
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The flags in the NFIT memory device sub-structure indicate
the state of the data on the nvdimm relative to its energy
@ -68,7 +68,7 @@ What: /sys/bus/nd/devices/nmemX/nfit/format1
What: /sys/bus/nd/devices/nmemX/nfit/formats
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The interface codes indicate support for persistent memory
mapped directly into system physical address space and / or a
@ -84,7 +84,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/vendor
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Vendor id of the NVDIMM.
@ -92,7 +92,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/dsm_mask
Date: May, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported device specific control
functions relative to the NVDIMM command family supported by the
@ -102,7 +102,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/family
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Displays the NVDIMM family command sets. Values
0, 1, 2 and 3 correspond to NVDIMM_FAMILY_INTEL,
@ -118,7 +118,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/id
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI specification 6.2 section 5.2.25.9, defines an
identifier for an NVDIMM, which refelects the id attribute.
@ -127,7 +127,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system vendor id of the NVDIMM non-volatile memory
subsystem controller.
@ -136,7 +136,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_rev_id
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system revision id of the NVDIMM non-volatile memory subsystem
controller, assigned by the non-volatile memory subsystem
@ -146,7 +146,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_device
Date: Apr, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) Sub-system device id for the NVDIMM non-volatile memory
subsystem controller, assigned by the non-volatile memory
@ -156,7 +156,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/revision
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI NFIT table revision number.
@ -164,7 +164,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/scrub
Date: Sep, 2016
KernelVersion: v4.9
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RW) This shows the number of full Address Range Scrubs (ARS)
that have been completed since driver load time. Userspace can
@ -177,7 +177,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/hw_error_scrub
Date: Sep, 2016
KernelVersion: v4.9
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RW) Provides a way to toggle the behavior between just adding
the address (cache line) where the MCE happened to the poison
@ -196,7 +196,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/dsm_mask
Date: Jun, 2017
KernelVersion: v4.13
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) The bitmask indicates the supported bus specific control
functions. See the section named 'NVDIMM Root Device _DSMs' in
@ -205,7 +205,7 @@ Description:
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
Date: Apr, 2020
KernelVersion: v5.8
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RW) The Intel platform implementation of firmware activate
support exposes an option let the platform force idle devices in
@ -225,7 +225,7 @@ Description:
What: /sys/bus/nd/devices/regionX/nfit/range_index
Date: Jun, 2015
KernelVersion: v4.2
Contact: linux-nvdimm@lists.01.org
Contact: nvdimm@lists.linux.dev
Description:
(RO) A unique number provided by the BIOS to identify an address
range. Used by NVDIMM Region Mapping Structure to uniquely refer

4
Documentation/ABI/testing/sysfs-bus-papr-pmem
View File

@ -1,7 +1,7 @@
What: /sys/bus/nd/devices/nmemX/papr/flags
Date: Apr, 2020
KernelVersion: v5.8
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
@ -36,7 +36,7 @@ Description:
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
Date: May, 2020
KernelVersion: v5.9
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report various performance stats related to papr-scm NVDIMM
device. Each stat is reported on a new line with each line

16
Documentation/ABI/testing/sysfs-class-net-qmi
View File

@ -58,3 +58,19 @@ Description:
Indicates the mux id associated to the qmimux network interface
during its creation.
What: /sys/class/net/<iface>/qmi/pass_through
Date: January 2021
KernelVersion: 5.12
Contact: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Description:
Boolean. Default: 'N'
Set this to 'Y' to enable 'pass-through' mode, allowing packets
in MAP format to be passed on to the stack.
Normally the rmnet driver (CONFIG_RMNET) is then used to process
and demultiplex these packets.
'Pass-through' mode can be enabled when the device is in
'raw-ip' mode only.

12
Documentation/ABI/testing/sysfs-class-rtrs-client
View File

@ -34,6 +34,9 @@ Description: Multipath policy specifies which path should be selected on each IO
min-inflight (1):
select path with minimum inflights.
min-latency (2):
select path with minimum latency.
What: /sys/class/rtrs-client/<session-name>/paths/
Date: Feb 2020
KernelVersion: 5.7
@ -95,6 +98,15 @@ KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the destination address of the path
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/cur_latency
Date: Feb 2020
KernelVersion: 5.7
Contact: Jack Wang <jinpu.wang@cloud.ionos.com> Danil Kipnis <danil.kipnis@cloud.ionos.com>
Description: RO, Contains the latency time calculated by the heart-beat messages.
Whenever the client sends heart-beat message, it checks the time gap
between sending the heart-beat message and receiving the ACK.
This value can be changed regularly.
What: /sys/class/rtrs-client/<session-name>/paths/<src@dst>/stats/reset_all
Date: Feb 2020
KernelVersion: 5.7

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

@ -285,7 +285,7 @@ Description: Disable L3 cache indices
All AMD processors with L3 caches provide this functionality.
For details, see BKDGs at
http://developer.amd.com/documentation/guides/Pages/default.aspx
https://www.amd.com/en/support/tech-docs?keyword=bios+kernel
What: /sys/devices/system/cpu/cpufreq/boost

9
Documentation/ABI/testing/sysfs-driver-input-exc3000
View File

@ -15,3 +15,12 @@ Description: Reports the model identification provided by the touchscreen, fo
Access: Read
Valid values: Represented as string
What: /sys/bus/i2c/devices/xxx/type
Date: Jan 2021
Contact: linux-input@vger.kernel.org
Description: Reports the type identification provided by the touchscreen, for example "PCAP82H80 Series"
Access: Read
Valid values: Represented as string

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

@ -276,7 +276,7 @@ Date April 2019
Contact: "Daniel Rosenberg" <drosen@google.com>
Description: If checkpoint=disable, it displays the number of blocks that
are unusable.
If checkpoint=enable it displays the enumber of blocks that
If checkpoint=enable it displays the number of blocks that
would be unusable if checkpoint=disable were to be set.
What: /sys/fs/f2fs/<disk>/encoding
@ -409,3 +409,32 @@ Description: Give a way to change checkpoint merge daemon's io priority.
I/O priority "3". We can select the class between "rt" and "be",
and set the I/O priority within valid range of it. "," delimiter
is necessary in between I/O class and priority number.
What: /sys/fs/f2fs/<disk>/ovp_segments
Date: March 2021
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Shows the number of overprovision segments.
What: /sys/fs/f2fs/<disk>/compr_written_block
Date: March 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the block count written after compression since mount. Note
that when the compressed blocks are deleted, this count doesn't
decrease. If you write "0" here, you can initialize
compr_written_block and compr_saved_block to "0".
What: /sys/fs/f2fs/<disk>/compr_saved_block
Date: March 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the saved block count with compression since mount. Note
that when the compressed blocks are deleted, this count doesn't
decrease. If you write "0" here, you can initialize
compr_written_block and compr_saved_block to "0".
What: /sys/fs/f2fs/<disk>/compr_new_inode
Date: March 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the count of inode newly enabled for compression since mount.
Note that when the compression is disabled for the files, this count
doesn't decrease. If you write "0" here, you can initialize
compr_new_inode to "0".

25
Documentation/ABI/testing/sysfs-kernel-mm-cma Normal file
View File

@ -0,0 +1,25 @@
What: /sys/kernel/mm/cma/
Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
/sys/kernel/mm/cma/ contains a subdirectory for each CMA
heap name (also sometimes called CMA areas).
Each CMA heap subdirectory (that is, each
/sys/kernel/mm/cma/<cma-heap-name> directory) contains the
following items:
alloc_pages_success
alloc_pages_fail
What: /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_success
Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
the number of pages CMA API succeeded to allocate
What: /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_fail
Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
the number of pages CMA API failed to allocate

4
Documentation/ABI/testing/sysfs-module
View File

@ -37,13 +37,13 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
What: /sys/module/*/{coresize,initsize}
Date: Jan 2012
KernelVersion:»·3.3
KernelVersion: 3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module size in bytes.
What: /sys/module/*/taint
Date: Jan 2012
KernelVersion:»·3.3
KernelVersion: 3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module taint flags:
== =====================

2
Documentation/admin-guide/devices.txt
View File

@ -4,7 +4,7 @@
1 char Memory devices
1 = /dev/mem Physical memory access
2 = /dev/kmem Kernel virtual memory access
2 = /dev/kmem OBSOLETE - replaced by /proc/kcore
3 = /dev/null Null device
4 = /dev/port I/O port access
5 = /dev/zero Null byte source

11
Documentation/admin-guide/gpio/gpio-mockup.rst
View File

@ -17,17 +17,18 @@ module.
gpio_mockup_ranges
This parameter takes an argument in the form of an array of integer
pairs. Each pair defines the base GPIO number (if any) and the number
of lines exposed by the chip. If the base GPIO is -1, the gpiolib
will assign it automatically.
pairs. Each pair defines the base GPIO number (non-negative integer)
and the first number after the last of this chip. If the base GPIO
is -1, the gpiolib will assign it automatically. while the following
parameter is the number of lines exposed by the chip.
Example: gpio_mockup_ranges=-1,8,-1,16,405,4
Example: gpio_mockup_ranges=-1,8,-1,16,405,409
The line above creates three chips. The first one will expose 8 lines,
the second 16 and the third 4. The base GPIO for the third chip is set
to 405 while for two first chips it will be assigned automatically.
gpio_named_lines
gpio_mockup_named_lines
This parameter doesn't take any arguments. It lets the driver know that
GPIO lines exposed by it should be named.

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

@ -1469,6 +1469,12 @@
Don't use this when you are not running on the
android emulator
gpio-mockup.gpio_mockup_ranges
[HW] Sets the ranges of gpiochip of for this device.
Format: <start1>,<end1>,<start2>,<end2>...
gpio-mockup.gpio_mockup_named_lines
[HW] Let the driver know GPIO lines should be named.
gpt [EFI] Forces disk with valid GPT signature but
invalid Protective MBR to be treated as GPT. If the
primary GPT is corrupted, it enables the backup/alternate
@ -1492,10 +1498,6 @@
Format: <unsigned int> such that (rxsize & ~0x1fffc0) == 0.
Default: 1024
gpio-mockup.gpio_mockup_ranges
[HW] Sets the ranges of gpiochip of for this device.
Format: <start1>,<end1>,<start2>,<end2>...
hardlockup_all_cpu_backtrace=
[KNL] Should the hard-lockup detector generate
backtraces on all cpus.
@ -1833,6 +1835,18 @@
initcall functions. Useful for debugging built-in
modules and initcalls.
initramfs_async= [KNL]
Format: <bool>
Default: 1
This parameter controls whether the initramfs
image is unpacked asynchronously, concurrently
with devices being probed and
initialized. This should normally just work,
but as a debugging aid, one can get the
historical behaviour of the initramfs
unpacking being completed before device_ and
late_ initcalls.
initrd= [BOOT] Specify the location of the initial ramdisk
initrdmem= [KNL] Specify a physical address and size from which to
@ -1877,13 +1891,6 @@
bypassed by not enabling DMAR with this option. In
this case, gfx device will use physical address for
DMA.
forcedac [X86-64]
With this option iommu will not optimize to look
for io virtual address below 32-bit forcing dual
address cycle on pci bus for cards supporting greater
than 32-bit addressing. The default is to look
for translation below 32-bit and if not available
then look in the higher range.
strict [Default Off]
With this option on every unmap_single operation will
result in a hardware IOTLB flush operation as opposed
@ -1972,6 +1979,14 @@
nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
iommu.forcedac= [ARM64, X86] Control IOVA allocation for PCI devices.
Format: { "0" | "1" }
0 - Try to allocate a 32-bit DMA address first, before
falling back to the full range if needed.
1 - Allocate directly from the full usable range,
forcing Dual Address Cycle for PCI cards supporting
greater than 32-bit addressing.
iommu.strict= [ARM64] Configure TLB invalidation behaviour
Format: { "0" | "1" }
0 - Lazy mode.
@ -2801,7 +2816,24 @@
seconds. Use this parameter to check at some
other rate. 0 disables periodic checking.
memtest= [KNL,X86,ARM,PPC] Enable memtest
memory_hotplug.memmap_on_memory
[KNL,X86,ARM] Boolean flag to enable this feature.
Format: {on | off (default)}
When enabled, runtime hotplugged memory will
allocate its internal metadata (struct pages)
from the hotadded memory which will allow to
hotadd a lot of memory without requiring
additional memory to do so.
This feature is disabled by default because it
has some implication on large (e.g. GB)
allocations in some configurations (e.g. small
memory blocks).
The state of the flag can be read in
/sys/module/memory_hotplug/parameters/memmap_on_memory.
Note that even when enabled, there are a few cases where
the feature is not effective.
memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest
Format: <integer>
default : 0 <disable>
Specifies the number of memtest passes to be
@ -3250,6 +3282,8 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
@ -4996,6 +5030,10 @@
slram= [HW,MTD]
slab_merge [MM]
Enable merging of slabs with similar size when the
kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
slab_nomerge [MM]
Disable merging of slabs with similar size. May be
necessary if there is some reason to distinguish
@ -5043,6 +5081,9 @@
lower than slub_max_order.
For more information see Documentation/vm/slub.rst.
slub_merge [MM, SLUB]
Same with slab_merge.
slub_nomerge [MM, SLUB]
Same with slab_nomerge. This is supported for legacy.
See slab_nomerge for more information.

9
Documentation/admin-guide/mm/memory-hotplug.rst
View File

@ -357,6 +357,15 @@ creates ZONE_MOVABLE as following.
Unfortunately, there is no information to show which memory block belongs
to ZONE_MOVABLE. This is TBD.
.. note::
Techniques that rely on long-term pinnings of memory (especially, RDMA and
vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory
hot remove. Pinned pages cannot reside on ZONE_MOVABLE, to guarantee that
memory can still get hot removed - be aware that pinning can fail even if
there is plenty of free memory in ZONE_MOVABLE. In addition, using
ZONE_MOVABLE might make page pinning more expensive, because pages have to be
migrated off that zone first.
.. _memory_hotplug_how_to_offline_memory:
How to offline memory

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

@ -402,7 +402,7 @@ compact_fail
but failed.
It is possible to establish how long the stalls were using the function
tracer to record how long was spent in __alloc_pages_nodemask and
tracer to record how long was spent in __alloc_pages() and
using the mm_page_alloc tracepoint to identify which allocations were
for huge pages.

99
Documentation/admin-guide/mm/userfaultfd.rst
View File

@ -63,36 +63,36 @@ the generic ioctl available.
The ``uffdio_api.features`` bitmask returned by the ``UFFDIO_API`` ioctl
defines what memory types are supported by the ``userfaultfd`` and what
events, except page fault notifications, may be generated.
events, except page fault notifications, may be generated:
If the kernel supports registering ``userfaultfd`` ranges on hugetlbfs
virtual memory areas, ``UFFD_FEATURE_MISSING_HUGETLBFS`` will be set in
``uffdio_api.features``. Similarly, ``UFFD_FEATURE_MISSING_SHMEM`` will be
set if the kernel supports registering ``userfaultfd`` ranges on shared
memory (covering all shmem APIs, i.e. tmpfs, ``IPCSHM``, ``/dev/zero``,
``MAP_SHARED``, ``memfd_create``, etc).
- The ``UFFD_FEATURE_EVENT_*`` flags indicate that various other events
other than page faults are supported. These events are described in more
detail below in the `Non-cooperative userfaultfd`_ section.
The userland application that wants to use ``userfaultfd`` with hugetlbfs
or shared memory need to set the corresponding flag in
``uffdio_api.features`` to enable those features.
- ``UFFD_FEATURE_MISSING_HUGETLBFS`` and ``UFFD_FEATURE_MISSING_SHMEM``
indicate that the kernel supports ``UFFDIO_REGISTER_MODE_MISSING``
registrations for hugetlbfs and shared memory (covering all shmem APIs,
i.e. tmpfs, ``IPCSHM``, ``/dev/zero``, ``MAP_SHARED``, ``memfd_create``,
etc) virtual memory areas, respectively.
If the userland desires to receive notifications for events other than
page faults, it has to verify that ``uffdio_api.features`` has appropriate
``UFFD_FEATURE_EVENT_*`` bits set. These events are described in more
detail below in `Non-cooperative userfaultfd`_ section.
- ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports
``UFFDIO_REGISTER_MODE_MINOR`` registration for hugetlbfs virtual memory
areas.
Once the ``userfaultfd`` has been enabled the ``UFFDIO_REGISTER`` ioctl should
be invoked (if present in the returned ``uffdio_api.ioctls`` bitmask) to
register a memory range in the ``userfaultfd`` by setting the
The userland application should set the feature flags it intends to use
when invoking the ``UFFDIO_API`` ioctl, to request that those features be
enabled if supported.
Once the ``userfaultfd`` API has been enabled the ``UFFDIO_REGISTER``
ioctl should be invoked (if present in the returned ``uffdio_api.ioctls``
bitmask) to register a memory range in the ``userfaultfd`` by setting the
uffdio_register structure accordingly. The ``uffdio_register.mode``
bitmask will specify to the kernel which kind of faults to track for
the range (``UFFDIO_REGISTER_MODE_MISSING`` would track missing
pages). The ``UFFDIO_REGISTER`` ioctl will return the
the range. The ``UFFDIO_REGISTER`` ioctl will return the
``uffdio_register.ioctls`` bitmask of ioctls that are suitable to resolve
userfaults on the range registered. Not all ioctls will necessarily be
supported for all memory types depending on the underlying virtual
memory backend (anonymous memory vs tmpfs vs real filebacked
mappings).
supported for all memory types (e.g. anonymous memory vs. shmem vs.
hugetlbfs), or all types of intercepted faults.
Userland can use the ``uffdio_register.ioctls`` to manage the virtual
address space in the background (to add or potentially also remove
@ -100,21 +100,46 @@ memory from the ``userfaultfd`` registered range). This means a userfault
could be triggering just before userland maps in the background the
user-faulted page.
The primary ioctl to resolve userfaults is ``UFFDIO_COPY``. That
atomically copies a page into the userfault registered range and wakes
up the blocked userfaults
(unless ``uffdio_copy.mode & UFFDIO_COPY_MODE_DONTWAKE`` is set).
Other ioctl works similarly to ``UFFDIO_COPY``. They're atomic as in
guaranteeing that nothing can see an half copied page since it'll
keep userfaulting until the copy has finished.
Resolving Userfaults
--------------------
There are three basic ways to resolve userfaults:
- ``UFFDIO_COPY`` atomically copies some existing page contents from
userspace.
- ``UFFDIO_ZEROPAGE`` atomically zeros the new page.
- ``UFFDIO_CONTINUE`` maps an existing, previously-populated page.
These operations are atomic in the sense that they guarantee nothing can
see a half-populated page, since readers will keep userfaulting until the
operation has finished.
By default, these wake up userfaults blocked on the range in question.
They support a ``UFFDIO_*_MODE_DONTWAKE`` ``mode`` flag, which indicates
that waking will be done separately at some later time.
Which ioctl to choose depends on the kind of page fault, and what we'd
like to do to resolve it:
- For ``UFFDIO_REGISTER_MODE_MISSING`` faults, the fault needs to be
resolved by either providing a new page (``UFFDIO_COPY``), or mapping
the zero page (``UFFDIO_ZEROPAGE``). By default, the kernel would map
the zero page for a missing fault. With userfaultfd, userspace can
decide what content to provide before the faulting thread continues.
- For ``UFFDIO_REGISTER_MODE_MINOR`` faults, there is an existing page (in
the page cache). Userspace has the option of modifying the page's
contents before resolving the fault. Once the contents are correct
(modified or not), userspace asks the kernel to map the page and let the
faulting thread continue with ``UFFDIO_CONTINUE``.
Notes:
- If you requested ``UFFDIO_REGISTER_MODE_MISSING`` when registering then
you must provide some kind of page in your thread after reading from
the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``.
The normal behavior of the OS automatically providing a zero page on
an anonymous mmaping is not in place.
- You can tell which kind of fault occurred by examining
``pagefault.flags`` within the ``uffd_msg``, checking for the
``UFFD_PAGEFAULT_FLAG_*`` flags.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate
@ -122,9 +147,9 @@ Notes:
- You get the address of the access that triggered the missing page
event out of a struct uffd_msg that you read in the thread from the
uffd. You can supply as many pages as you want with ``UFFDIO_COPY`` or
``UFFDIO_ZEROPAGE``. Keep in mind that unless you used DONTWAKE then
the first of any of those IOCTLs wakes up the faulting thread.
uffd. You can supply as many pages as you want with these IOCTLs.
Keep in mind that unless you used DONTWAKE then the first of any of
those IOCTLs wakes up the faulting thread.
- Be sure to test for all errors including
(``pollfd[0].revents & POLLERR``). This can happen, e.g. when ranges

49
Documentation/admin-guide/reporting-issues.rst
View File

@ -24,7 +24,8 @@ longterm series? One still supported? Then search the `LKML
you don't find any, install `the latest release from that series
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
mailing list (stable@vger.kernel.org) and CC the regressions list
(regressions@lists.linux.dev).
(regressions@lists.linux.dev); ideally also CC the maintainer and the mailing
list for the subsystem in question.
In all other cases try your best guess which kernel part might be causing the
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@ -48,8 +49,9 @@ before the issue occurs.
If you are facing multiple issues with the Linux kernel at once, report each
separately. While writing your report, include all information relevant to the
issue, like the kernel and the distro used. In case of a regression, CC the
regressions mailing list (regressions@lists.linux.dev) to your report; also try
to include the commit-id of the change causing it, which a bisection can find.
regressions mailing list (regressions@lists.linux.dev) to your report. Also try
to pin-point the culprit with a bisection; if you succeed, include its
commit-id and CC everyone in the sign-off-by chain.
Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
@ -198,10 +200,11 @@ report them:
* Send a short problem report to the Linux stable mailing list
(stable@vger.kernel.org) and CC the Linux regressions mailing list
(regressions@lists.linux.dev). Roughly describe the issue and ideally
explain how to reproduce it. Mention the first version that shows the
problem and the last version that's working fine. Then wait for further
instructions.
(regressions@lists.linux.dev); if you suspect the cause in a particular
subsystem, CC its maintainer and its mailing list. Roughly describe the
issue and ideally explain how to reproduce it. Mention the first version
that shows the problem and the last version that's working fine. Then
wait for further instructions.
The reference section below explains each of these steps in more detail.
@ -768,7 +771,9 @@ regular internet search engine and add something like
the results to the archives at that URL.
It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
at this point.
at this point. If your report needs to be filed in a bug tracker, you may want
to check the mailing list archives for the subsystem as well, as someone might
have reported it only there.
For details how to search and what to do if you find matching reports see
"Search for existing reports, first run" above.
@ -1249,9 +1254,10 @@ and the oldest where the issue occurs (say 5.8-rc1).
When sending the report by mail, CC the Linux regressions mailing list
(regressions@lists.linux.dev). In case the report needs to be filed to some web
tracker, proceed to do so; once filed, forward the report by mail to the
regressions list. Make sure to inline the forwarded report, hence do not attach
it. Also add a short note at the top where you mention the URL to the ticket.
tracker, proceed to do so. Once filed, forward the report by mail to the
regressions list; CC the maintainer and the mailing list for the subsystem in
question. Make sure to inline the forwarded report, hence do not attach it.
Also add a short note at the top where you mention the URL to the ticket.
When mailing or forwarding the report, in case of a successful bisection add the
author of the culprit to the recipients; also CC everyone in the signed-off-by
@ -1536,17 +1542,20 @@ Report the regression
*Send a short problem report to the Linux stable mailing list
(stable@vger.kernel.org) and CC the Linux regressions mailing list
(regressions@lists.linux.dev). Roughly describe the issue and ideally
explain how to reproduce it. Mention the first version that shows the
problem and the last version that's working fine. Then wait for further
instructions.*
(regressions@lists.linux.dev); if you suspect the cause in a particular
subsystem, CC its maintainer and its mailing list. Roughly describe the
issue and ideally explain how to reproduce it. Mention the first version
that shows the problem and the last version that's working fine. Then
wait for further instructions.*
When reporting a regression that happens within a stable or longterm kernel
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
the start to get the issue reported quickly. Hence a rough description is all
it takes.
the start to get the issue reported quickly. Hence a rough description to the
stable and regressions mailing list is all it takes; but in case you suspect
the cause in a particular subsystem, CC its maintainers and its mailing list
as well, because that will speed things up.
But note, it helps developers a great deal if you can specify the exact version
And note, it helps developers a great deal if you can specify the exact version
that introduced the problem. Hence if possible within a reasonable time frame,
try to find that version using vanilla kernels. Lets assume something broke when
your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
@ -1563,7 +1572,9 @@ pinpoint the exact change that causes the issue (which then can easily get
reverted to fix the issue quickly). Hence consider to do a proper bisection
right away if time permits. See the section 'Special care for regressions' and
the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
perform one.
perform one. In case of a successful bisection add the author of the culprit to
the recipients; also CC everyone in the signed-off-by chain, which you find at
the end of its commit message.
Reference for "Reporting issues only occurring in older kernel version lines"

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

@ -483,10 +483,11 @@ modprobe
========
The full path to the usermode helper for autoloading kernel modules,
by default "/sbin/modprobe". This binary is executed when the kernel
requests a module. For example, if userspace passes an unknown
filesystem type to mount(), then the kernel will automatically request
the corresponding filesystem module by executing this usermode helper.
by default ``CONFIG_MODPROBE_PATH``, which in turn defaults to
"/sbin/modprobe". This binary is executed when the kernel requests a
module. For example, if userspace passes an unknown filesystem type
to mount(), then the kernel will automatically request the
corresponding filesystem module by executing this usermode helper.
This usermode helper should insert the needed module into the kernel.
This sysctl only affects module autoloading. It has no effect on the
@ -1457,11 +1458,22 @@ unprivileged_bpf_disabled
=========================
Writing 1 to this entry will disable unprivileged calls to ``bpf()``;
once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` will return
``-EPERM``.
once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` or ``CAP_BPF``
will return ``-EPERM``. Once set to 1, this can't be cleared from the
running kernel anymore.
Once set, this can't be cleared.
Writing 2 to this entry will also disable unprivileged calls to ``bpf()``,
however, an admin can still change this setting later on, if needed, by
writing 0 or 1 to this entry.
If ``BPF_UNPRIV_DEFAULT_OFF`` is enabled in the kernel config, then this
entry will default to 2 instead of 0.
= =============================================================
0 Unprivileged calls to ``bpf()`` are enabled
1 Unprivileged calls to ``bpf()`` are disabled without recovery
2 Unprivileged calls to ``bpf()`` are disabled
= =============================================================
watchdog
========

33
Documentation/arm64/booting.rst
View File

@ -277,9 +277,40 @@ Before jumping into the kernel, the following conditions must be met:
- SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
For CPUs with Advanced SIMD and floating point support:
- If EL3 is present:
- CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
- If EL2 is present and the kernel is entered at EL1:
- CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
- if EL3 is present:
- CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
- ZCR_EL3.LEN must be initialised to the same value for all CPUs the
kernel is executed on.
- If the kernel is entered at EL1 and EL2 is present:
- CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
- CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
- ZCR_EL2.LEN must be initialised to the same value for all CPUs the
kernel will execute on.
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level.
enter the kernel in the same exception level. Where the values documented
disable traps it is permissible for these traps to be enabled so long as
those traps are handled transparently by higher exception levels as though
the values documented were set.
The boot loader is expected to enter the kernel on each CPU in the
following manner:

2
Documentation/arm64/elf_hwcaps.rst
View File

@ -74,7 +74,7 @@ HWCAP_ASIMD
HWCAP_EVTSTRM
The generic timer is configured to generate events at a frequency of
approximately 100KHz.
approximately 10KHz.
HWCAP_AES
Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.

6
Documentation/arm64/tagged-address-abi.rst
View File

@ -113,6 +113,12 @@ ABI relaxation:
- ``shmat()`` and ``shmdt()``.
- ``brk()`` (since kernel v5.6).
- ``mmap()`` (since kernel v5.6).
- ``mremap()``, the ``new_address`` argument (since kernel v5.6).
Any attempt to use non-zero tagged pointers may result in an error code
being returned, a (fatal) signal being raised, or other modes of
failure.

2
Documentation/block/data-integrity.rst
View File

@ -1,4 +1,4 @@
==============
==============
Data Integrity
==============

30
Documentation/cdrom/cdrom-standard.rst
View File

@ -146,18 +146,18 @@ with the kernel as a block device by registering the following general
*struct file_operations*::
struct file_operations cdrom_fops = {
NULL, /∗ lseek ∗/
block _read , /∗ read—general block-dev read ∗/
block _write, /∗ write—general block-dev write ∗/
NULL, /∗ readdir ∗/
NULL, /∗ select ∗/
cdrom_ioctl, /∗ ioctl ∗/
NULL, /∗ mmap ∗/
cdrom_open, /∗ open ∗/
cdrom_release, /∗ release ∗/
NULL, /∗ fsync ∗/
NULL, /∗ fasync ∗/
NULL /∗ revalidate ∗/
NULL, /* lseek */
block _read , /* read--general block-dev read */
block _write, /* write--general block-dev write */
NULL, /* readdir */
NULL, /* select */
cdrom_ioctl, /* ioctl */
NULL, /* mmap */
cdrom_open, /* open */
cdrom_release, /* release */
NULL, /* fsync */
NULL, /* fasync */
NULL /* revalidate */
};
Every active CD-ROM device shares this *struct*. The routines
@ -250,12 +250,12 @@ The drive-specific, minor-like information that is registered with
`cdrom.c`, currently contains the following fields::
struct cdrom_device_info {
const struct cdrom_device_ops * ops; /* device operations for this major */
const struct cdrom_device_ops * ops; /* device operations for this major */
struct list_head list; /* linked list of all device_info */
struct gendisk * disk; /* matching block layer disk */
void * handle; /* driver-dependent data */
int mask; /* mask of capability: disables them */
int mask; /* mask of capability: disables them */
int speed; /* maximum speed for reading data */
int capacity; /* number of discs in a jukebox */
@ -569,7 +569,7 @@ the *CDC_CLOSE_TRAY* bit in *mask*.
In the file `cdrom.c` you will encounter many constructions of the type::
if (cdo->capability & ∼cdi->mask & CDC _⟨capability⟩) ...
if (cdo->capability & ~cdi->mask & CDC _<capability>) ...
There is no *ioctl* to set the mask... The reason is that
I think it is better to control the **behavior** rather than the

4
Documentation/core-api/cachetlb.rst
View File

@ -213,9 +213,9 @@ Here are the routines, one by one:
there will be no entries in the cache for the kernel address
space for virtual addresses in the range 'start' to 'end-1'.
The first of these two routines is invoked after map_kernel_range()
The first of these two routines is invoked after vmap_range()
has installed the page table entries. The second is invoked
before unmap_kernel_range() deletes the page table entries.
before vunmap_range() deletes the page table entries.
There exists another whole class of cpu cache issues which currently
require a whole different set of interfaces to handle properly.

88
Documentation/core-api/dma-api.rst
View File

@ -563,6 +563,16 @@ Free a region of memory previously allocated using dma_alloc_pages().
dev, size, dma_handle and dir must all be the same as those passed into
dma_alloc_pages(). page must be the pointer returned by dma_alloc_pages().
::
int
dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
size_t size, struct page *page)
Map an allocation returned from dma_alloc_pages() into a user address space.
dev and size must be the same as those passed into dma_alloc_pages().
page must be the pointer returned by dma_alloc_pages().
::
void *
@ -584,6 +594,84 @@ dev, size, dma_handle and dir must all be the same as those passed into
dma_alloc_noncoherent(). cpu_addr must be the virtual address returned by
dma_alloc_noncoherent().
::
struct sg_table *
dma_alloc_noncontiguous(struct device *dev, size_t size,
enum dma_data_direction dir, gfp_t gfp,
unsigned long attrs);
This routine allocates <size> bytes of non-coherent and possibly non-contiguous
memory. It returns a pointer to struct sg_table that describes the allocated
and DMA mapped memory, or NULL if the allocation failed. The resulting memory
can be used for struct page mapped into a scatterlist are suitable for.
The return sg_table is guaranteed to have 1 single DMA mapped segment as
indicated by sgt->nents, but it might have multiple CPU side segments as
indicated by sgt->orig_nents.
The dir parameter specified if data is read and/or written by the device,
see dma_map_single() for details.
The gfp parameter allows the caller to specify the ``GFP_`` flags (see
kmalloc()) for the allocation, but rejects flags used to specify a memory
zone such as GFP_DMA or GFP_HIGHMEM.
The attrs argument must be either 0 or DMA_ATTR_ALLOC_SINGLE_PAGES.
Before giving the memory to the device, dma_sync_sgtable_for_device() needs
to be called, and before reading memory written by the device,
dma_sync_sgtable_for_cpu(), just like for streaming DMA mappings that are
reused.
::
void
dma_free_noncontiguous(struct device *dev, size_t size,
struct sg_table *sgt,
enum dma_data_direction dir)
Free memory previously allocated using dma_alloc_noncontiguous(). dev, size,
and dir must all be the same as those passed into dma_alloc_noncontiguous().
sgt must be the pointer returned by dma_alloc_noncontiguous().
::
void *
dma_vmap_noncontiguous(struct device *dev, size_t size,
struct sg_table *sgt)
Return a contiguous kernel mapping for an allocation returned from
dma_alloc_noncontiguous(). dev and size must be the same as those passed into
dma_alloc_noncontiguous(). sgt must be the pointer returned by
dma_alloc_noncontiguous().
Once a non-contiguous allocation is mapped using this function, the
flush_kernel_vmap_range() and invalidate_kernel_vmap_range() APIs must be used
to manage the coherency between the kernel mapping, the device and user space
mappings (if any).
::
void
dma_vunmap_noncontiguous(struct device *dev, void *vaddr)
Unmap a kernel mapping returned by dma_vmap_noncontiguous(). dev must be the
same the one passed into dma_alloc_noncontiguous(). vaddr must be the pointer
returned by dma_vmap_noncontiguous().
::
int
dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
size_t size, struct sg_table *sgt)
Map an allocation returned from dma_alloc_noncontiguous() into a user address
space. dev and size must be the same as those passed into
dma_alloc_noncontiguous(). sgt must be the pointer returned by
dma_alloc_noncontiguous().
::
int

22
Documentation/core-api/irq/irq-domain.rst
View File

@ -42,10 +42,10 @@ irq_domain usage
================
An interrupt controller driver creates and registers an irq_domain by
calling one of the irq_domain_add_*() functions (each mapping method
has a different allocator function, more on that later). The function
will return a pointer to the irq_domain on success. The caller must
provide the allocator function with an irq_domain_ops structure.
calling one of the irq_domain_add_*() or irq_domain_create_*() functions
(each mapping method has a different allocator function, more on that later).
The function will return a pointer to the irq_domain on success. The caller
must provide the allocator function with an irq_domain_ops structure.
In most cases, the irq_domain will begin empty without any mappings
between hwirq and IRQ numbers. Mappings are added to the irq_domain
@ -147,6 +147,7 @@ Legacy
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
irq_domain_create_simple()
irq_domain_create_legacy()
The Legacy mapping is a special case for drivers that already have a
@ -169,13 +170,13 @@ supported. For example, ISA controllers would use the legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
Most users of legacy mappings should use irq_domain_add_simple() which
will use a legacy domain only if an IRQ range is supplied by the
system and will otherwise use a linear domain mapping. The semantics
of this call are such that if an IRQ range is specified then
Most users of legacy mappings should use irq_domain_add_simple() or
irq_domain_create_simple() which will use a legacy domain only if an IRQ range
is supplied by the system and will otherwise use a linear domain mapping.
The semantics of this call are such that if an IRQ range is specified then
descriptors will be allocated on-the-fly for it, and if no range is
specified it will fall through to irq_domain_add_linear() which means
*no* irq descriptors will be allocated.
specified it will fall through to irq_domain_add_linear() or
irq_domain_create_linear() which means *no* irq descriptors will be allocated.
A typical use case for simple domains is where an irqchip provider
is supporting both dynamic and static IRQ assignments.
@ -186,6 +187,7 @@ that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
irq_domain_add_simple() and irq_domain_create_simple() as well as
irq_domain_add_legacy() and irq_domain_create_legacy() are functionally
equivalent, except for the first argument is different - the former
accepts an Open Firmware specific 'struct device_node', while the latter

6
Documentation/core-api/mm-api.rst
View File

@ -92,3 +92,9 @@ More Memory Management Functions
:export:
.. kernel-doc:: mm/page_alloc.c
.. kernel-doc:: mm/mempolicy.c
.. kernel-doc:: include/linux/mm_types.h
:internal:
.. kernel-doc:: include/linux/mm.h
:internal:
.. kernel-doc:: include/linux/mmzone.h

26
Documentation/core-api/symbol-namespaces.rst
View File

@ -43,14 +43,14 @@ exporting of kernel symbols to the kernel symbol table, variants of these are
available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and
EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace.
Please note that due to macro expansion that argument needs to be a
preprocessor symbol. E.g. to export the symbol `usb_stor_suspend` into the
namespace `USB_STORAGE`, use::
preprocessor symbol. E.g. to export the symbol ``usb_stor_suspend`` into the
namespace ``USB_STORAGE``, use::
EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE);
The corresponding ksymtab entry struct `kernel_symbol` will have the member
`namespace` set accordingly. A symbol that is exported without a namespace will
refer to `NULL`. There is no default namespace if none is defined. `modpost`
The corresponding ksymtab entry struct ``kernel_symbol`` will have the member
``namespace`` set accordingly. A symbol that is exported without a namespace will
refer to ``NULL``. There is no default namespace if none is defined. ``modpost``
and kernel/module.c make use the namespace at build time or module load time,
respectively.
@ -64,7 +64,7 @@ and EXPORT_SYMBOL_GPL() macro expansions that do not specify a namespace.
There are multiple ways of specifying this define and it depends on the
subsystem and the maintainer's preference, which one to use. The first option
is to define the default namespace in the `Makefile` of the subsystem. E.g. to
is to define the default namespace in the ``Makefile`` of the subsystem. E.g. to
export all symbols defined in usb-common into the namespace USB_COMMON, add a
line like this to drivers/usb/common/Makefile::
@ -96,7 +96,7 @@ using a statement like::
MODULE_IMPORT_NS(USB_STORAGE);
This will create a `modinfo` tag in the module for each imported namespace.
This will create a ``modinfo`` tag in the module for each imported namespace.
This has the side effect, that the imported namespaces of a module can be
inspected with modinfo::
@ -113,7 +113,7 @@ metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). Refer to section
4. Loading Modules that use namespaced Symbols
==============================================
At module loading time (e.g. `insmod`), the kernel will check each symbol
At module loading time (e.g. ``insmod``), the kernel will check each symbol
referenced from the module for its availability and whether the namespace it
might be exported to has been imported by the module. The default behaviour of
the kernel is to reject loading modules that don't specify sufficient imports.
@ -138,19 +138,19 @@ missing imports. Fixing missing imports can be done with::
A typical scenario for module authors would be::
- write code that depends on a symbol from a not imported namespace
- `make`
- ``make``
- notice the warning of modpost telling about a missing import
- run `make nsdeps` to add the import to the correct code location
- run ``make nsdeps`` to add the import to the correct code location
For subsystem maintainers introducing a namespace, the steps are very similar.
Again, `make nsdeps` will eventually add the missing namespace imports for
Again, ``make nsdeps`` will eventually add the missing namespace imports for
in-tree modules::
- move or add symbols to a namespace (e.g. with EXPORT_SYMBOL_NS())
- `make` (preferably with an allmodconfig to cover all in-kernel
- ``make`` (preferably with an allmodconfig to cover all in-kernel
modules)
- notice the warning of modpost telling about a missing import
- run `make nsdeps` to add the import to the correct code location
- run ``make nsdeps`` to add the import to the correct code location
You can also run nsdeps for external module builds. A typical usage is::

2
Documentation/dev-tools/gdb-kernel-debugging.rst
View File

@ -114,7 +114,7 @@ Examples of using the Linux-provided gdb helpers
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
....
- Examine fields of the current task struct::
- Examine fields of the current task struct(supported by x86 and arm64 only)::
(gdb) p $lx_current().pid
$1 = 4998

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

@ -11,46 +11,56 @@ designed to find out-of-bound and use-after-free bugs. KASAN has three modes:
2. software tag-based KASAN (similar to userspace HWASan),
3. hardware tag-based KASAN (based on hardware memory tagging).
Software KASAN modes (1 and 2) use compile-time instrumentation to insert
validity checks before every memory access, and therefore require a compiler
Generic KASAN is mainly used for debugging due to a large memory overhead.
Software tag-based KASAN can be used for dogfood testing as it has a lower
memory overhead that allows using it with real workloads. Hardware tag-based
KASAN comes with low memory and performance overheads and, therefore, can be
used in production. Either as an in-field memory bug detector or as a security
mitigation.
Software KASAN modes (#1 and #2) use compile-time instrumentation to insert
validity checks before every memory access and, therefore, require a compiler
version that supports that.
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
Generic KASAN is supported in GCC and Clang. With GCC, it requires version
8.3.0 or later. Any supported Clang version is compatible, but detection of
out-of-bounds accesses for global variables is only supported since Clang 11.
Tag-based KASAN is only supported in Clang.
Software tag-based KASAN mode is only supported in Clang.
Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390
The hardware KASAN mode (#3) relies on hardware to perform the checks but
still requires a compiler version that supports memory tagging instructions.
This mode is supported in GCC 10+ and Clang 11+.
Both software KASAN modes work with SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only supports SLUB.
Currently, generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390,
and riscv architectures, and tag-based KASAN modes are supported only for arm64.
Usage
-----
To enable KASAN configure kernel with::
To enable KASAN, configure the kernel with::
CONFIG_KASAN = y
CONFIG_KASAN=y
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN),
CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN), and
CONFIG_KASAN_HW_TAGS (to enable hardware tag-based KASAN).
and choose between ``CONFIG_KASAN_GENERIC`` (to enable generic KASAN),
``CONFIG_KASAN_SW_TAGS`` (to enable software tag-based KASAN), and
``CONFIG_KASAN_HW_TAGS`` (to enable hardware tag-based KASAN).
For software modes, you also need to choose between CONFIG_KASAN_OUTLINE and
CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types.
The former produces smaller binary while the latter is 1.1 - 2 times faster.
For software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and
``CONFIG_KASAN_INLINE``. Outline and inline are compiler instrumentation types.
The former produces a smaller binary while the latter is 1.1-2 times faster.
Both software KASAN modes work with both SLUB and SLAB memory allocators,
while the hardware tag-based KASAN currently only support SLUB.
For better error reports that include stack traces, enable CONFIG_STACKTRACE.
To augment reports with last allocation and freeing stack of the physical page,
it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
To include alloc and free stack traces of affected slab objects into reports,
enable ``CONFIG_STACKTRACE``. To include alloc and free stack traces of affected
physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``.
Error reports
~~~~~~~~~~~~~
A typical out-of-bounds access generic KASAN report looks like this::
A typical KASAN report looks like this::
==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
@ -123,41 +133,57 @@ A typical out-of-bounds access generic KASAN report looks like this::
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================
The header of the report provides a short summary of what kind of bug happened
and what kind of access caused it. It's followed by a stack trace of the bad
access, a stack trace of where the accessed memory was allocated (in case bad
access happens on a slab object), and a stack trace of where the object was
freed (in case of a use-after-free bug report). Next comes a description of
the accessed slab object and information about the accessed memory page.
The report header summarizes what kind of bug happened and what kind of access
caused it. It is followed by a stack trace of the bad access, a stack trace of
where the accessed memory was allocated (in case a slab object was accessed),
and a stack trace of where the object was freed (in case of a use-after-free
bug report). Next comes a description of the accessed slab object and the
information about the accessed memory page.
In the last section the report shows memory state around the accessed address.
Internally KASAN tracks memory state separately for each memory granule, which
In the end, the report shows the memory state around the accessed address.
Internally, KASAN tracks memory state separately for each memory granule, which
is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
memory state section of the report shows the state of one of the memory
granules that surround the accessed address.
For generic KASAN the size of each memory granule is 8. The state of each
For generic KASAN, the size of each memory granule is 8. The state of each
granule is encoded in one shadow byte. Those 8 bytes can be accessible,
partially accessible, freed or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 0 means that all 8 bytes of the corresponding
partially accessible, freed, or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 00 means that all 8 bytes of the corresponding
memory region are accessible; number N (1 <= N <= 7) means that the first N
bytes are accessible, and other (8 - N) bytes are not; any negative value
indicates that the entire 8-byte word is inaccessible. KASAN uses different
negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible. For tag-based KASAN modes this
last report section shows the memory tags around the accessed address
(see the `Implementation details`_ section).
In the report above, the arrow points to the shadow byte ``03``, which means
that the accessed address is partially accessible.
For tag-based KASAN modes, this last report section shows the memory tags around
the accessed address (see the `Implementation details`_ section).
Note that KASAN bug titles (like ``slab-out-of-bounds`` or ``use-after-free``)
are best-effort: KASAN prints the most probable bug type based on the limited
information it has. The actual type of the bug might be different.
Generic KASAN also reports up to two auxiliary call stack traces. These stack
traces point to places in code that interacted with the object but that are not
directly present in the bad access stack trace. Currently, this includes
call_rcu() and workqueue queuing.
Boot parameters
~~~~~~~~~~~~~~~
KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.
By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.
Hardware tag-based KASAN mode (see the section about various modes below) is
intended for use in production as a security mitigation. Therefore, it supports
boot parameters that allow to disable KASAN competely or otherwise control
particular KASAN features.
boot parameters that allow disabling KASAN or controlling its features.
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
@ -174,26 +200,8 @@ particular KASAN features.
traces collection (default: ``on``).
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``). Note, that tag
checking gets disabled after the first reported bug.
For developers
~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some part of the kernel, and
therefore needs to be disabled. To disable instrumentation for specific files
or directories, add a line similar to the following to the respective kernel
Makefile:
- For a single file (e.g. main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
report or also panic the kernel (default: ``report``). The panic happens even
if ``kasan_multi_shot`` is enabled.
Implementation details
----------------------
@ -201,12 +209,11 @@ Implementation details
Generic KASAN
~~~~~~~~~~~~~
From a high level perspective, KASAN's approach to memory error detection is
similar to that of kmemcheck: use shadow memory to record whether each byte of
memory is safe to access, and use compile-time instrumentation to insert checks
of shadow memory on each memory access.
Software KASAN modes use shadow memory to record whether each byte of memory is
safe to access and use compile-time instrumentation to insert shadow memory
checks before each memory access.
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (16TB
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
translate a memory address to its corresponding shadow address.
@ -215,113 +222,105 @@ address::
static inline void *kasan_mem_to_shadow(const void *addr)
{
return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
+ KASAN_SHADOW_OFFSET;
}
where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation is used to insert memory access checks. Compiler
inserts function calls (__asan_load*(addr), __asan_store*(addr)) before each
memory access of size 1, 2, 4, 8 or 16. These functions check whether memory
access is valid or not by checking corresponding shadow memory.
inserts function calls (``__asan_load*(addr)``, ``__asan_store*(addr)``) before
each memory access of size 1, 2, 4, 8, or 16. These functions check whether
memory accesses are valid or not by checking corresponding shadow memory.
GCC 5.0 has possibility to perform inline instrumentation. Instead of making
function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
With inline instrumentation, instead of making function calls, the compiler
directly inserts the code to check shadow memory. This option significantly
enlarges the kernel, but it gives an x1.1-x2 performance boost over the
outline-instrumented kernel.
Generic KASAN also reports the last 2 call stacks to creation of work that
potentially has access to an object. Call stacks for the following are shown:
call_rcu() and workqueue queuing.
Generic KASAN is the only mode that delays the reuse of freed object via
Generic KASAN is the only mode that delays the reuse of freed objects via
quarantine (see mm/kasan/quarantine.c for implementation).
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Software tag-based KASAN requires software memory tagging support in the form
of HWASan-like compiler instrumentation (see HWASan documentation for details).
Software tag-based KASAN is currently only implemented for arm64 architecture.
Software tag-based KASAN uses a software memory tagging approach to checking
access validity. It is currently only implemented for the arm64 architecture.
Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
to store a pointer tag in the top byte of kernel pointers. Like generic KASAN
it uses shadow memory to store memory tags associated with each 16-byte memory
cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
to store memory tags associated with each 16-byte memory cell (therefore, it
dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds this tag into the returned
On each memory allocation, software tag-based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds the same tag into the returned
pointer.
Software tag-based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that tag of the memory that
is being accessed is equal to tag of the pointer that is used to access this
memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
before each memory access. These checks make sure that the tag of the memory
that is being accessed is equal to the tag of the pointer that is used to access
this memory. In case of a tag mismatch, software tag-based KASAN prints a bug
report.
Software tag-based KASAN also has two instrumentation modes (outline, that
emits callbacks to check memory accesses; and inline, that performs the shadow
Software tag-based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
simply printed from the function that performs the access check. With inline
instrumentation a brk instruction is emitted by the compiler, and a dedicated
brk handler is used to print bug reports.
printed from the function that performs the access check. With inline
instrumentation, a ``brk`` instruction is emitted by the compiler, and a
dedicated ``brk`` handler is used to print bug reports.
Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Software tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Software tag-based KASAN currently only supports tagging of slab and page_alloc
memory.
Hardware tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Hardware tag-based KASAN is similar to the software mode in concept, but uses
Hardware tag-based KASAN is similar to the software mode in concept but uses
hardware memory tagging support instead of compiler instrumentation and
shadow memory.
Hardware tag-based KASAN is currently only implemented for arm64 architecture
and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
Instruction Set Architecture, and Top Byte Ignore (TBI).
Instruction Set Architecture and Top Byte Ignore (TBI).
Special arm64 instructions are used to assign memory tags for each allocation.
Same tags are assigned to pointers to those allocations. On every memory
access, hardware makes sure that tag of the memory that is being accessed is
equal to tag of the pointer that is used to access this memory. In case of a
tag mismatch a fault is generated and a report is printed.
access, hardware makes sure that the tag of the memory that is being accessed is
equal to the tag of the pointer that is used to access this memory. In case of a
tag mismatch, a fault is generated, and a report is printed.
Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with 0xFF pointer tag aren't checked). The value 0xFE is currently
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Hardware tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
Hardware tag-based KASAN currently only supports tagging of slab and page_alloc
memory.
If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN
won't be enabled. In this case all boot parameters are ignored.
If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN
will not be enabled. In this case, all KASAN boot parameters are ignored.
Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when kasan.mode=off is provided, or when the hardware doesn't
Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
support MTE (but supports TBI).
Hardware tag-based KASAN only reports the first found bug. After that MTE tag
Hardware tag-based KASAN only reports the first found bug. After that, MTE tag
checking gets disabled.
What memory accesses are sanitised by KASAN?
--------------------------------------------
Shadow memory
-------------
The kernel maps memory in a number of different parts of the address
space. This poses something of a problem for KASAN, which requires
that all addresses accessed by instrumented code have a valid shadow
region.
The kernel maps memory in several different parts of the address space.
The range of kernel virtual addresses is large: there is not enough real
memory to support a real shadow region for every address that could be
accessed by the kernel. Therefore, KASAN only maps real shadow for certain
parts of the address space.
The range of kernel virtual addresses is large: there is not enough
real memory to support a real shadow region for every address that
could be accessed by the kernel.
By default
~~~~~~~~~~
Default behaviour
~~~~~~~~~~~~~~~~~
By default, architectures only map real memory over the shadow region
for the linear mapping (and potentially other small areas). For all
@ -330,10 +329,9 @@ page is mapped over the shadow area. This read-only shadow page
declares all memory accesses as permitted.
This presents a problem for modules: they do not live in the linear
mapping, but in a dedicated module space. By hooking in to the module
allocator, KASAN can temporarily map real shadow memory to cover
them. This allows detection of invalid accesses to module globals, for
example.
mapping but in a dedicated module space. By hooking into the module
allocator, KASAN temporarily maps real shadow memory to cover them.
This allows detection of invalid accesses to module globals, for example.
This also creates an incompatibility with ``VMAP_STACK``: if the stack
lives in vmalloc space, it will be shadowed by the read-only page, and
@ -344,9 +342,10 @@ CONFIG_KASAN_VMALLOC
~~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
cost of greater memory usage. Currently this is only supported on x86.
cost of greater memory usage. Currently, this is supported on x86,
riscv, s390, and powerpc.
This works by hooking into vmalloc and vmap, and dynamically
This works by hooking into vmalloc and vmap and dynamically
allocating real shadow memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
@ -365,28 +364,76 @@ memory.
To avoid the difficulties around swapping mappings around, KASAN expects
that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.
not be covered by the early shadow page but will be left unmapped.
This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86, and can simplify support of
This allows ``VMAP_STACK`` support on x86 and can simplify support of
architectures that do not have a fixed module region.
CONFIG_KASAN_KUNIT_TEST and CONFIG_KASAN_MODULE_TEST
----------------------------------------------------
For developers
--------------
KASAN tests consist of two parts:
Ignoring accesses
~~~~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some parts of the kernel, and
therefore needs to be disabled.
Other parts of the kernel might access metadata for allocated objects.
Normally, KASAN detects and reports such accesses, but in some cases (e.g.,
in memory allocators), these accesses are valid.
For software KASAN modes, to disable instrumentation for a specific file or
directory, add a ``KASAN_SANITIZE`` annotation to the respective kernel
Makefile:
- For a single file (e.g., main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
For software KASAN modes, to disable instrumentation on a per-function basis,
use the KASAN-specific ``__no_sanitize_address`` function attribute or the
generic ``noinstr`` one.
Note that disabling compiler instrumentation (either on a per-file or a
per-function basis) makes KASAN ignore the accesses that happen directly in
that code for software KASAN modes. It does not help when the accesses happen
indirectly (through calls to instrumented functions) or with the hardware
tag-based mode that does not use compiler instrumentation.
For software KASAN modes, to disable KASAN reports in a part of the kernel code
for the current task, annotate this part of the code with a
``kasan_disable_current()``/``kasan_enable_current()`` section. This also
disables the reports for indirect accesses that happen through function calls.
For tag-based KASAN modes (include the hardware one), to disable access
checking, use ``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that
temporarily disabling access checking via ``page_kasan_tag_reset()`` requires
saving and restoring the per-page KASAN tag via
``page_kasan_tag``/``page_kasan_tag_set``.
Tests
~~~~~
There are KASAN tests that allow verifying that KASAN works and can detect
certain types of memory corruptions. The tests consist of two parts:
1. Tests that are integrated with the KUnit Test Framework. Enabled with
``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
automatically in a few different ways, see the instructions below.
automatically in a few different ways; see the instructions below.
2. Tests that are currently incompatible with KUnit. Enabled with
``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can
only be verified manually, by loading the kernel module and inspecting the
only be verified manually by loading the kernel module and inspecting the
kernel log for KASAN reports.
Each KUnit-compatible KASAN test prints a KASAN report if an error is detected.
Then the test prints its number and status.
Each KUnit-compatible KASAN test prints one of multiple KASAN reports if an
error is detected. Then the test prints its number and status.
When a test passes::
@ -414,30 +461,24 @@ Or, if one of the tests failed::
not ok 1 - kasan
There are a few ways to run KUnit-compatible KASAN tests.
1. Loadable module
~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` enabled, ``CONFIG_KASAN_KUNIT_TEST`` can be built as
a loadable module and run on any architecture that supports KASAN by loading
the module with insmod or modprobe. The module is called ``test_kasan``.
With ``CONFIG_KUNIT`` enabled, KASAN-KUnit tests can be built as a loadable
module and run by loading ``test_kasan.ko`` with ``insmod`` or ``modprobe``.
2. Built-In
~~~~~~~~~~~
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
on any architecure that supports KASAN. These and any other KUnit tests enabled
will run and print the results at boot as a late-init call.
With ``CONFIG_KUNIT`` built-in, KASAN-KUnit tests can be built-in as well.
In this case, the tests will run at boot as a late-init call.
3. Using kunit_tool
~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it's also
possible use ``kunit_tool`` to see the results of these and other KUnit tests
in a more readable way. This will not print the KASAN reports of the tests that
passed. Use `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it is also
possible to use ``kunit_tool`` to see the results of KUnit tests in a more
readable way. This will not print the KASAN reports of the tests that passed.
See `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html

4
Documentation/devicetree/bindings/.gitignore vendored
View File

@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
*.example.dts
processed-schema*.yaml
processed-schema*.json
/processed-schema*.yaml
/processed-schema*.json

75
Documentation/devicetree/bindings/arm/ete.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/ete.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ARM Embedded Trace Extensions
maintainers:
- Suzuki K Poulose <suzuki.poulose@arm.com>
- Mathieu Poirier <mathieu.poirier@linaro.org>
description: |
Arm Embedded Trace Extension(ETE) is a per CPU trace component that
allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
architecture and has extended support for future architecture changes.
The trace generated by the ETE could be stored via legacy CoreSight
components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
legacy CoreSight components, a node must be listed per instance, along
with any optional connection graph as per the coresight bindings.
See bindings/arm/coresight.txt.
properties:
$nodename:
pattern: "^ete([0-9a-f]+)$"
compatible:
items:
- const: arm,embedded-trace-extension
cpu:
description: |
Handle to the cpu this ETE is bound to.
$ref: /schemas/types.yaml#/definitions/phandle
out-ports:
description: |
Output connections from the ETE to legacy CoreSight trace bus.
$ref: /schemas/graph.yaml#/properties/ports
properties:
port:
description: Output connection from the ETE to legacy CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- cpu
additionalProperties: false
examples:
# An ETE node without legacy CoreSight connections
- |
ete0 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_0>;
};
# An ETE node with legacy CoreSight connections
- |
ete1 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_1>;
out-ports { /* legacy coresight connection */
port {
ete1_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
};
...

4
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
View File

@ -142,8 +142,8 @@ mpp50 50 gpio, ge1(rxclk), mss_i2c(sda), spi1(csn0), uart2(txd), uart0(rxd), xg(
mpp51 51 gpio, ge1(rxd0), mss_i2c(sck), spi1(csn1), uart2(rxd), uart0(cts), sdio(pwr10)
mpp52 52 gpio, ge1(rxd1), synce1(clk), synce2(clk), spi1(csn2), uart1(cts), led(clk), pcie(rstoutn), pcie0(clkreq)
mpp53 53 gpio, ge1(rxd2), ptp(clk), spi1(csn3), uart1(rxd), led(stb), sdio(led)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio(card_detect)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio_wp(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio_cd(card_detect)
mpp56 56 gpio, tdm(drx), au(i2sdo_spdifo), spi0(clk), uart1(rxd), sata1(present_act), sdio(clk)
mpp57 57 gpio, mss_i2c(sda), ptp(pclk_out), tdm(intn), au(i2sbclk), spi0(mosi), uart1(txd), sata0(present_act), sdio(cmd)
mpp58 58 gpio, mss_i2c(sck), ptp(clk), tdm(rstn), au(i2sdi), spi0(miso), uart1(cts), led(clk), sdio(d0)

49
Documentation/devicetree/bindings/arm/trbe.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/trbe.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ARM Trace Buffer Extensions
maintainers:
- Anshuman Khandual <anshuman.khandual@arm.com>
description: |
Arm Trace Buffer Extension (TRBE) is a per CPU component
for storing trace generated on the CPU to memory. It is
accessed via CPU system registers. The software can verify
if it is permitted to use the component by checking the
TRBIDR register.
properties:
$nodename:
const: "trbe"
compatible:
items:
- const: arm,trace-buffer-extension
interrupts:
description: |
Exactly 1 PPI must be listed. For heterogeneous systems where
TRBE is only supported on a subset of the CPUs, please consult
the arm,gic-v3 binding for details on describing a PPI partition.
maxItems: 1
required:
- compatible
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
trbe {
compatible = "arm,trace-buffer-extension";
interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
};
...

2
Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
View File

@ -60,7 +60,6 @@ properties:
maxItems: 2
idt,xtal-load-femtofarads:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 9000
maximum: 22760
description: Optional load capacitor for XTAL1 and XTAL2
@ -84,7 +83,6 @@ patternProperties:
enum: [ 1800000, 2500000, 3300000 ]
idt,slew-percent:
description: The Slew rate control for CMOS single-ended.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 80, 85, 90, 100 ]
required:

2
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
View File

@ -109,7 +109,7 @@ required:
- resets
- ddc
unevaluatedProperties: false
additionalProperties: false
examples:
- |

3
Documentation/devicetree/bindings/display/renesas,du.yaml
View File

@ -51,6 +51,9 @@ properties:
resets: true
reset-names: true
power-domains:
maxItems: 1
ports:
$ref: /schemas/graph.yaml#/properties/port
description: |

1
Documentation/devicetree/bindings/dma/qcom,gpi.yaml
View File

@ -20,6 +20,7 @@ properties:
compatible:
enum:
- qcom,sdm845-gpi-dma
- qcom,sm8150-gpi-dma
reg:
maxItems: 1

46
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.txt
View File

@ -1,46 +0,0 @@
Bindings for the Broadcom's brcm,bcm6345-gpio memory-mapped GPIO controllers.
These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
are the only ones which don't need a pinctrl driver.
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
Required properties:
- compatible: should be "brcm,bcm6345-gpio"
- reg-names: must contain
"dat" - data register
"dirout" - direction (output) register
- reg: address + size pairs describing the GPIO register sets;
order must correspond with the order of entries in reg-names
- #gpio-cells: must be set to 2. The first cell is the pin number and
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller: Marks the device node as a gpio controller.
Optional properties:
- native-endian: use native endian memory.
Examples:
- BCM6338:
gpio: gpio-controller@fffe0407 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0407 1>, <0xfffe040f 1>;
#gpio-cells = <2>;
gpio-controller;
};
- BCM6345:
gpio: gpio-controller@fffe0406 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0406 2>, <0xfffe040a 2>;
native-endian;
#gpio-cells = <2>;
gpio-controller;
};

86
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml Normal file
View File

@ -0,0 +1,86 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6345 GPIO controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description: |+
Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
are the only ones which don't need a pinctrl driver.
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
and dirout registers, where GPIO state can be read and/or written, and the
direction changed from input to output.
properties:
compatible:
enum:
- brcm,bcm6318-gpio
- brcm,bcm6328-gpio
- brcm,bcm6345-gpio
- brcm,bcm6358-gpio
- brcm,bcm6362-gpio
- brcm,bcm6368-gpio
- brcm,bcm63268-gpio
gpio-controller: true
"#gpio-cells":
const: 2
gpio-ranges:
maxItems: 1
native-endian: true
reg:
maxItems: 2
reg-names:
items:
- const: dirout
- const: dat
required:
- compatible
- reg
- reg-names
- gpio-controller
- '#gpio-cells'
additionalProperties: false
examples:
- |
gpio@fffe0406 {
compatible = "brcm,bcm6345-gpio";
reg-names = "dirout", "dat";
reg = <0xfffe0406 2>, <0xfffe040a 2>;
native-endian;
gpio-controller;
#gpio-cells = <2>;
};
- |
gpio@0 {
compatible = "brcm,bcm63268-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 52>;
#gpio-cells = <2>;
};

77
Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml Normal file
View File

@ -0,0 +1,77 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/fairchild,74hc595.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic 8-bit shift register
maintainers:
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:
enum:
- fairchild,74hc595
- nxp,74lvc594
reg:
maxItems: 1
gpio-controller: true
'#gpio-cells':
description:
The second cell is only used to specify the GPIO polarity.
const: 2
registers-number:
description: Number of daisy-chained shift registers
enable-gpios:
description: GPIO connected to the OE (Output Enable) pin.
maxItems: 1
spi-max-frequency: true
patternProperties:
"^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
type: object
properties:
gpio-hog: true
gpios: true
output-high: true
output-low: true
line-name: true
required:
- gpio-hog
- gpios
additionalProperties: false
required:
- compatible
- reg
- gpio-controller
- '#gpio-cells'
- registers-number
additionalProperties: false
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
gpio5: gpio5@0 {
compatible = "fairchild,74hc595";
reg = <0>;
gpio-controller;
#gpio-cells = <2>;
registers-number = <4>;
spi-max-frequency = <100000>;
};
};

27
Documentation/devicetree/bindings/gpio/gpio-74x164.txt
View File

@ -1,27 +0,0 @@
* Generic 8-bits shift register GPIO driver
Required properties:
- compatible: Should contain one of the following:
"fairchild,74hc595"
"nxp,74lvc594"
- reg : chip select number
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- registers-number: Number of daisy-chained shift registers
Optional properties:
- enable-gpios: GPIO connected to the OE (Output Enable) pin.
Example:
gpio5: gpio5@0 {
compatible = "fairchild,74hc595";
reg = <0>;
gpio-controller;
#gpio-cells = <2>;
registers-number = <4>;
spi-max-frequency = <100000>;
};

78
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/realtek,otto-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek Otto GPIO controller
maintainers:
- Sander Vanheule <sander@svanheule.net>
- Bert Vermeulen <bert@biot.com>
description: |
Realtek's GPIO controller on their MIPS switch SoCs (Otto platform) consists
of two banks of 32 GPIOs. These GPIOs can generate edge-triggered interrupts.
Each bank's interrupts are cascased into one interrupt line on the parent
interrupt controller, if provided.
This binding allows defining a single bank in the devicetree. The interrupt
controller is not supported on the fallback compatible name, which only
allows for GPIO port use.
properties:
$nodename:
pattern: "^gpio@[0-9a-f]+$"
compatible:
items:
- enum:
- realtek,rtl8380-gpio
- realtek,rtl8390-gpio
- const: realtek,otto-gpio
reg:
maxItems: 1
"#gpio-cells":
const: 2
gpio-controller: true
ngpios:
minimum: 1
maximum: 32
interrupt-controller: true
"#interrupt-cells":
const: 2
interrupts:
maxItems: 1
required:
- compatible
- reg
- "#gpio-cells"
- gpio-controller
additionalProperties: false
dependencies:
interrupt-controller: [ interrupts ]
examples:
- |
gpio@3500 {
compatible = "realtek,rtl8380-gpio", "realtek,otto-gpio";
reg = <0x3500 0x1c>;
gpio-controller;
#gpio-cells = <2>;
ngpios = <24>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&rtlintc>;
interrupts = <23>;
};
...

82
Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml Normal file
View File

@ -0,0 +1,82 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/rockchip,gpio-bank.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip GPIO bank
maintainers:
- Heiko Stuebner <heiko@sntech.de>
properties:
compatible:
enum:
- rockchip,gpio-bank
- rockchip,rk3188-gpio-bank0
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
gpio-controller: true
"#gpio-cells":
const: 2
interrupt-controller: true
"#interrupt-cells":
const: 2
required:
- compatible
- reg
- interrupts
- clocks
- gpio-controller
- "#gpio-cells"
- interrupt-controller
- "#interrupt-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
pinctrl: pinctrl {
#address-cells = <1>;
#size-cells = <1>;
ranges;
gpio0: gpio@2000a000 {
compatible = "rockchip,rk3188-gpio-bank0";
reg = <0x2000a000 0x100>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 9>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio1: gpio@2003c000 {
compatible = "rockchip,gpio-bank";
reg = <0x2003c000 0x100>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 10>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
};

28
Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
View File

@ -1,28 +0,0 @@
SIRF Hardware spinlock device Binding
-----------------------------------------------
Required properties :
- compatible : shall contain only one of the following:
"sirf,hwspinlock"
- reg : the register address of hwspinlock
- #hwlock-cells : hwlock users only use the hwlock id to represent a specific
hwlock, so the number of cells should be <1> here.
Please look at the generic hwlock binding for usage information for consumers,
"Documentation/devicetree/bindings/hwlock/hwlock.txt"
Example of hwlock provider:
hwlock {
compatible = "sirf,hwspinlock";
reg = <0x13240000 0x00010000>;
#hwlock-cells = <1>;
};
Example of hwlock users:
node {
...
hwlocks = <&hwlock 2>;
...
};

62
Documentation/devicetree/bindings/i2c/i2c-mpc.txt
View File

@ -1,62 +0,0 @@
* I2C
Required properties :
- reg : Offset and length of the register set for the device
- compatible : should be "fsl,CHIP-i2c" where CHIP is the name of a
compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121,
mpc5200 or mpc5200b. For the mpc5121, an additional node
"fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
Recommended properties :
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
information for the interrupt. This should be encoded based on
the information in section 2) depending on the type of interrupt
controller you have.
- fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
- clock-frequency : desired I2C bus clock frequency in Hz.
- fsl,timeout : I2C bus timeout in microseconds.
Examples :
/* MPC5121 based board */
i2c@1740 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <100000>;
};
i2ccontrol@1760 {
compatible = "fsl,mpc5121-i2c-ctrl";
reg = <0x1760 0x8>;
};
/* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
/* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
fsl,timeout = <10000>;
};

98
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml Normal file
View File

@ -0,0 +1,98 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mpc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I2C-Bus adapter for MPC824x/83xx/85xx/86xx/512x/52xx SoCs
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- mpc5200-i2c
- fsl,mpc5200-i2c
- fsl,mpc5121-i2c
- fsl,mpc8313-i2c
- fsl,mpc8543-i2c
- fsl,mpc8544-i2c
- const: fsl-i2c
- items:
- const: fsl,mpc5200b-i2c
- const: fsl,mpc5200-i2c
- const: fsl-i2c
reg:
maxItems: 1
interrupts:
maxItems: 1
fsl,preserve-clocking:
$ref: /schemas/types.yaml#/definitions/flag
description: |
if defined, the clock settings from the bootloader are
preserved (not touched)
fsl,timeout:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
I2C bus timeout in microseconds
fsl,i2c-erratum-a004447:
$ref: /schemas/types.yaml#/definitions/flag
description: |
Indicates the presence of QorIQ erratum A-004447, which
says that the standard i2c recovery scheme mechanism does
not work and an alternate implementation is needed.
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
/* MPC5121 based board */
i2c@1740 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5121-i2c", "fsl-i2c";
reg = <0x1740 0x20>;
interrupts = <11 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <100000>;
};
/* MPC5200B based board */
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,preserve-clocking;
};
/* MPC8544 base board */
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8544-i2c", "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
fsl,timeout = <10000>;
};
...

2
Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
View File

@ -49,7 +49,7 @@ additionalProperties: true
examples:
- |
i3c-master@a0000000 {
compatible = "silvaco,i3c-master";
compatible = "silvaco,i3c-master-v1";
clocks = <&zynqmp_clk 71>, <&fclk>, <&sclk>;
clock-names = "pclk", "fast_clk", "slow_clk";
interrupt-parent = <&gic>;

1
Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
View File

@ -102,7 +102,6 @@ patternProperties:
st,adc-channel-names:
description: List of single-ended channel names.
$ref: /schemas/types.yaml#/definitions/string-array
st,filter-order:
description: |

2
Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
View File

@ -1,7 +1,7 @@
Hisilicon RoCE DT description
Hisilicon RoCE engine is a part of network subsystem.
It works depending on other part of network wubsytem, such as, gmac and
It works depending on other part of network subsystem, such as gmac and
dsa fabric.
Additional properties are described here:

32
Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
View File

@ -39,6 +39,13 @@ properties:
(active low). The line must be flagged with
GPIO_ACTIVE_LOW.
wake-gpios:
maxItems: 1
description:
Optional GPIO specifier for the touchscreen's wake pin
(active low). The line must be flagged with
GPIO_ACTIVE_LOW.
linux,gpio-keymap:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
@ -53,6 +60,29 @@ properties:
or experiment to determine which bit corresponds to which input. Use
KEY_RESERVED for unused padding values.
atmel,wakeup-method:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
The WAKE line is an active-low input that is used to wake up the touch
controller from deep-sleep mode before communication with the controller
could be started. This optional feature used to minimize current
consumption when the controller is in deep sleep mode. This feature is
relevant only to some controller families, like mXT1386 controller for
example.
The WAKE pin can be connected in one of the following ways:
1) left permanently low
2) connected to the I2C-compatible SCL pin
3) connected to a GPIO pin on the host
enum:
- 0 # ATMEL_MXT_WAKEUP_NONE
- 1 # ATMEL_MXT_WAKEUP_I2C_SCL
- 2 # ATMEL_MXT_WAKEUP_GPIO
default: 0
wakeup-source:
type: boolean
required:
- compatible
- reg
@ -63,6 +93,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/atmel-maxtouch.h>
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
@ -75,6 +106,7 @@ examples:
reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
vdda-supply = <&ab8500_ldo_aux2_reg>;
vdd-supply = <&ab8500_ldo_aux5_reg>;
atmel,wakeup-method = <ATMEL_MXT_WAKEUP_I2C_SCL>;
};
};

1
Documentation/devicetree/bindings/input/input.yaml
View File

@ -38,6 +38,5 @@ properties:
Duration in seconds which the key should be kept pressed for device to
reset automatically. Device with key pressed reset feature can specify
this property.
$ref: /schemas/types.yaml#/definitions/uint32
additionalProperties: true

843
Documentation/devicetree/bindings/input/iqs626a.yaml Normal file
View File

@ -0,0 +1,843 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/iqs626a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Azoteq IQS626A Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
The Azoteq IQS626A is a 14-channel capacitive touch controller that features
additional Hall-effect and inductive sensing capabilities.
Link to datasheet: https://www.azoteq.com/
allOf:
- $ref: touchscreen/touchscreen.yaml#
properties:
compatible:
const: azoteq,iqs626a
reg:
maxItems: 1
interrupts:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 0
azoteq,suspend-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the power mode during suspend as follows:
0: Automatic (same as normal runtime, i.e. suspend/resume disabled)
1: Low power (all sensing at a reduced reporting rate)
2: Ultra-low power (ULP channel proximity sensing)
3: Halt (no sensing)
azoteq,clk-div:
type: boolean
description: Divides the device's core clock by a factor of 4.
azoteq,ulp-enable:
type: boolean
description:
Permits the device to automatically enter ultra-low-power mode from low-
power mode.
azoteq,ulp-update:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4, 5, 6, 7]
default: 3
description: |
Specifies the rate at which the trackpad, generic and Hall channels are
updated during ultra-low-power mode as follows:
0: 8
1: 13
2: 28
3: 54
4: 89
5: 135
6: 190
7: 256
azoteq,ati-band-disable:
type: boolean
description: Disables the ATI band check.
azoteq,ati-lp-only:
type: boolean
description: Limits automatic ATI to low-power mode.
azoteq,gpio3-select:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4, 5, 6, 7]
default: 1
description: |
Selects the channel or group of channels for which the GPIO3 pin
represents touch state as follows:
0: None
1: ULP channel
2: Trackpad
3: Trackpad
4: Generic channel 0
5: Generic channel 1
6: Generic channel 2
7: Hall channel
azoteq,reseed-select:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the event(s) that prompt the device to reseed (i.e. reset the
long-term average) of an associated channel as follows:
0: None
1: Proximity
2: Proximity or touch
3: Proximity, touch or deep touch
azoteq,thresh-extend:
type: boolean
description: Multiplies all touch and deep-touch thresholds by 4.
azoteq,tracking-enable:
type: boolean
description:
Enables all associated channels to track their respective reference
channels.
azoteq,reseed-offset:
type: boolean
description:
Applies an 8-count offset to all long-term averages upon either ATI or
reseed events.
azoteq,rate-np-ms:
minimum: 0
maximum: 255
default: 150
description: Specifies the report rate (in ms) during normal-power mode.
azoteq,rate-lp-ms:
minimum: 0
maximum: 255
default: 150
description: Specifies the report rate (in ms) during low-power mode.
azoteq,rate-ulp-ms:
multipleOf: 16
minimum: 0
maximum: 4080
default: 0
description: Specifies the report rate (in ms) during ultra-low-power mode.
azoteq,timeout-pwr-ms:
multipleOf: 512
minimum: 0
maximum: 130560
default: 2560
description:
Specifies the length of time (in ms) to wait for an event before moving
from normal-power mode to low-power mode, or (if 'azoteq,ulp-enable' is
present) from low-power mode to ultra-low-power mode.
azoteq,timeout-lta-ms:
multipleOf: 512
minimum: 0
maximum: 130560
default: 40960
description:
Specifies the length of time (in ms) to wait before resetting the long-
term average of all channels. Specify the maximum timeout to disable it
altogether.
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
patternProperties:
"^ulp-0|generic-[0-2]|hall$":
type: object
description:
Represents a single sensing channel. A channel is active if defined and
inactive otherwise.
properties:
azoteq,ati-exclude:
type: boolean
description:
Prevents the channel from participating in an ATI event that is
manually triggered during initialization.
azoteq,reseed-disable:
type: boolean
description:
Prevents the channel from being reseeded if the long-term average
timeout (defined in 'azoteq,timeout-lta') expires.
azoteq,meas-cap-decrease:
type: boolean
description:
Decreases the internal measurement capacitance from 60 pF to 15 pF.
azoteq,rx-inactive:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
default: 0
description: |
Specifies how inactive CRX pins are to be terminated as follows:
0: VSS
1: Floating
2: VREG (generic channels only)
azoteq,linearize:
type: boolean
description:
Enables linearization of the channel's counts (generic and Hall
channels) or inverts the polarity of the channel's proximity or
touch states (ULP channel).
azoteq,dual-direction:
type: boolean
description:
Specifies that the channel's long-term average is to freeze in the
presence of either increasing or decreasing counts, thereby permit-
ting events to be reported in either direction.
azoteq,filt-disable:
type: boolean
description: Disables raw count filtering for the channel.
azoteq,ati-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
description: |
Specifies the channel's ATI mode as follows:
0: Disabled
1: Semi-partial
2: Partial
3: Full
The default value is a function of the channel and the device's reset
user interface (RUI); reference the datasheet for further information
about the available RUI options.
azoteq,ati-base:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [75, 100, 150, 200]
description:
Specifies the channel's ATI base. The default value is a function
of the channel and the device's RUI.
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 32
minimum: 0
maximum: 2016
description:
Specifies the channel's ATI target. The default value is a function
of the channel and the device's RUI.
azoteq,cct-increase:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 16
default: 0
description:
Specifies the degree to which the channel's charge cycle time is to
be increased, with 0 representing no increase. The maximum value is
limited to 4 in the case of the ULP channel, and the property is un-
available entirely in the case of the Hall channel.
azoteq,proj-bias:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the bias current applied during projected-capacitance
sensing as follows:
0: 2.5 uA
1: 5 uA
2: 10 uA
3: 20 uA
This property is unavailable in the case of the Hall channel.
azoteq,sense-freq:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
description: |
Specifies the channel's sensing frequency as follows (parenthesized
numbers represent the frequency if 'azoteq,clk-div' is present):
0: 4 MHz (1 MHz)
1: 2 MHz (500 kHz)
2: 1 MHz (250 kHz)
3: 500 kHz (125 kHz)
This property is unavailable in the case of the Hall channel. The
default value is a function of the channel and the device's RUI.
azoteq,ati-band-tighten:
type: boolean
description:
Tightens the ATI band from 1/8 to 1/16 of the desired target (ULP and
generic channels only).
azoteq,proj-enable:
type: boolean
description: Enables projected-capacitance sensing (ULP channel only).
azoteq,filt-str-np-cnt:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description:
Specifies the raw count filter strength during normal-power mode (ULP
and generic channels only).
azoteq,filt-str-lp-cnt:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description:
Specifies the raw count filter strength during low-power mode (ULP and
generic channels only).
azoteq,filt-str-np-lta:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description:
Specifies the long-term average filter strength during normal-power
mode (ULP and generic channels only).
azoteq,filt-str-lp-lta:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description:
Specifies the long-term average filter strength during low-power mode
(ULP and generic channels only).
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 channel.
This property is unavailable in the case of the Hall channel. The
default value is a function of the channel and the device's RUI.
azoteq,tx-enable:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
items:
minimum: 0
maximum: 7
description:
Specifies the TX pin(s) associated with the channel.
This property is unavailable in the case of the Hall channel. The
default value is a function of the channel and the device's RUI.
azoteq,local-cap-size:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4]
default: 0
description: |
Specifies the capacitance to be added to the channel as follows:
0: 0 pF
1: 0.5 pF
2: 1.0 pF
3: 1.5 pF
4: 2.0 pF
This property is unavailable in the case of the ULP or Hall channels.
azoteq,sense-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 8, 9, 12, 14, 15]
description: |
Specifies the channel's sensing mode as follows:
0: Self capacitance
1: Projected capacitance
8: Self inductance
9: Mutual inductance
12: External
14: Hall effect
15: Temperature
This property is unavailable in the case of the ULP or Hall channels.
The default value is a function of the channel and the device's RUI.
azoteq,tx-freq:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the inductive sensing excitation frequency as follows
(parenthesized numbers represent the frequency if 'azoteq,clk-div'
is present):
0: 16 MHz (4 MHz)
1: 8 MHz (2 MHz)
2: 4 MHz (1 MHz)
3: 2 MHz (500 kHz)
This property is unavailable in the case of the ULP or Hall channels.
azoteq,invert-enable:
type: boolean
description:
Inverts the polarity of the states reported for proximity, touch and
deep-touch events relative to their respective thresholds (generic
channels only).
azoteq,comp-disable:
type: boolean
description:
Disables compensation for the channel (generic channels only).
azoteq,static-enable:
type: boolean
description:
Enables the static front-end for the channel (generic channels only).
azoteq,assoc-select:
$ref: /schemas/types.yaml#/definitions/string-array
minItems: 1
maxItems: 6
items:
enum:
- ulp-0
- trackpad-3x2
- trackpad-3x3
- generic-0
- generic-1
- generic-2
- hall
description:
Specifies the associated channels for which the channel serves as a
reference channel. By default, no channels are selected. This prop-
erty is only available for the generic channels.
azoteq,assoc-weight:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
default: 0
description:
Specifies the channel's impact weight if it acts as an associated
channel (0 = 0% impact, 255 = 200% impact). This property is only
available for the generic channels.
patternProperties:
"^event-(prox|touch|deep)(-alt)?$":
type: object
description:
Represents a proximity, touch or deep-touch event reported by the
channel in response to a decrease in counts. Node names suffixed with
'-alt' instead correspond to an increase in counts.
By default, the long-term average tracks an increase in counts such
that only events corresponding to a decrease in counts are reported
(refer to the datasheet for more information).
Specify 'azoteq,dual-direction' to freeze the long-term average when
the counts increase or decrease such that events of either direction
can be reported. Alternatively, specify 'azoteq,invert-enable' to in-
vert the polarity of the states reported by the channel.
Complementary events (e.g. event-touch and event-touch-alt) can both
be present and specify different key or switch codes, but not differ-
ent thresholds or hysteresis (if applicable).
Proximity events are unavailable in the case of the Hall channel, and
deep-touch events are only available for the generic channels. Unless
otherwise specified, default values are a function of the channel and
the device's RUI.
properties:
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description: Specifies the threshold for the event.
azoteq,hyst:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
description:
Specifies the hysteresis for the event (touch and deep-touch
events only).
linux,code:
$ref: /schemas/types.yaml#/definitions/uint32
description: Numeric key or switch code associated with the event.
linux,input-type:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 5]
description:
Specifies whether the event is to be interpreted as a key (1) or
a switch (5). By default, Hall-channel events are interpreted as
switches and all others are interpreted as keys.
dependencies:
linux,input-type: ["linux,code"]
additionalProperties: false
dependencies:
azoteq,assoc-weight: ["azoteq,assoc-select"]
additionalProperties: false
"^trackpad-3x[2-3]$":
type: object
description:
Represents all channels associated with the trackpad. The channels are
collectively active if the trackpad is defined and inactive otherwise.
properties:
azoteq,ati-exclude:
type: boolean
description:
Prevents the trackpad channels from participating in an ATI event
that is manually triggered during initialization.
azoteq,reseed-disable:
type: boolean
description:
Prevents the trackpad channels from being reseeded if the long-term
average timeout (defined in 'azoteq,timeout-lta') expires.
azoteq,meas-cap-decrease:
type: boolean
description:
Decreases the internal measurement capacitance from 60 pF to 15 pF.
azoteq,rx-inactive:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
default: 0
description: |
Specifies how inactive CRX pins are to be terminated as follows:
0: VSS
1: Floating
azoteq,linearize:
type: boolean
description: Inverts the polarity of the trackpad's touch state.
azoteq,dual-direction:
type: boolean
description:
Specifies that the trackpad's long-term averages are to freeze in
the presence of either increasing or decreasing counts, thereby
permitting events to be reported in either direction.
azoteq,filt-disable:
type: boolean
description: Disables raw count filtering for the trackpad channels.
azoteq,ati-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the trackpad's ATI mode as follows:
0: Disabled
1: Semi-partial
2: Partial
3: Full
azoteq,ati-base:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 6
maxItems: 9
items:
minimum: 45
maximum: 300
default: [45, 45, 45, 45, 45, 45, 45, 45, 45]
description: Specifies each individual trackpad channel's ATI base.
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 32
minimum: 0
maximum: 2016
default: 0
description: Specifies the trackpad's ATI target.
azoteq,cct-increase:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 4
default: 0
description:
Specifies the degree to which the trackpad's charge cycle time is to
be increased, with 0 representing no increase.
azoteq,proj-bias:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the bias current applied during projected-capacitance
sensing as follows:
0: 2.5 uA
1: 5 uA
2: 10 uA
3: 20 uA
azoteq,sense-freq:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: |
Specifies the trackpad's sensing frequency as follows (parenthesized
numbers represent the frequency if 'azoteq,clk-div' is present):
0: 4 MHz (1 MHz)
1: 2 MHz (500 kHz)
2: 1 MHz (250 kHz)
3: 500 kHz (125 kHz)
azoteq,ati-band-tighten:
type: boolean
description:
Tightens the ATI band from 1/8 to 1/16 of the desired target.
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 6
maxItems: 9
items:
minimum: 0
maximum: 255
default: [0, 0, 0, 0, 0, 0, 0, 0, 0]
description:
Specifies each individual trackpad channel's touch threshold.
azoteq,hyst:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
default: 0
description: Specifies the trackpad's touch hysteresis.
azoteq,lta-update:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4, 5, 6, 7]
default: 0
description: |
Specifies the update rate of the trackpad's long-term average during
ultra-low-power mode as follows:
0: 2
1: 4
2: 8
3: 16
4: 32
5: 64
6: 128
7: 255
azoteq,filt-str-trackpad:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description: Specifies the trackpad coordinate filter strength.
azoteq,filt-str-np-cnt:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description:
Specifies the raw count filter strength during normal-power mode.
azoteq,filt-str-lp-cnt:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
description:
Specifies the raw count filter strength during low-power mode.
linux,keycodes:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 6
description: |
Specifies the numeric keycodes associated with each available gesture
in the following order (enter 0 for unused gestures):
0: Positive flick or swipe in X direction
1: Negative flick or swipe in X direction
2: Positive flick or swipe in Y direction
3: Negative flick or swipe in Y direction
4: Tap
5: Hold
azoteq,gesture-swipe:
type: boolean
description:
Directs the device to interpret axial gestures as a swipe (finger
remains on trackpad) instead of a flick (finger leaves trackpad).
azoteq,timeout-tap-ms:
multipleOf: 16
minimum: 0
maximum: 4080
default: 0
description:
Specifies the length of time (in ms) within which a trackpad touch
must be released in order to be interpreted as a tap.
azoteq,timeout-swipe-ms:
multipleOf: 16
minimum: 0
maximum: 4080
default: 0
description:
Specifies the length of time (in ms) within which an axial gesture
must be completed in order to be interpreted as a flick or swipe.
azoteq,thresh-swipe:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
default: 0
description:
Specifies the number of points across which an axial gesture must
travel in order to be interpreted as a flick or swipe.
dependencies:
azoteq,gesture-swipe: ["linux,keycodes"]
azoteq,timeout-tap-ms: ["linux,keycodes"]
azoteq,timeout-swipe-ms: ["linux,keycodes"]
azoteq,thresh-swipe: ["linux,keycodes"]
additionalProperties: false
required:
- compatible
- reg
- interrupts
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
iqs626a@44 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "azoteq,iqs626a";
reg = <0x44>;
interrupt-parent = <&gpio>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
azoteq,rate-np-ms = <16>;
azoteq,rate-lp-ms = <160>;
azoteq,timeout-pwr-ms = <2560>;
azoteq,timeout-lta-ms = <32768>;
ulp-0 {
azoteq,meas-cap-decrease;
azoteq,ati-base = <75>;
azoteq,ati-target = <1024>;
azoteq,rx-enable = <2>, <3>, <4>,
<5>, <6>, <7>;
event-prox {
linux,code = <KEY_POWER>;
};
};
trackpad-3x3 {
azoteq,filt-str-np-cnt = <1>;
azoteq,filt-str-lp-cnt = <1>;
azoteq,hyst = <4>;
azoteq,thresh = <35>, <40>, <40>,
<38>, <33>, <38>,
<35>, <35>, <35>;
azoteq,ati-mode = <3>;
azoteq,ati-base = <195>, <195>, <195>,
<195>, <195>, <195>,
<195>, <195>, <195>;
azoteq,ati-target = <512>;
azoteq,proj-bias = <1>;
azoteq,sense-freq = <2>;
linux,keycodes = <KEY_VOLUMEUP>,
<KEY_VOLUMEDOWN>,
<KEY_NEXTSONG>,
<KEY_PREVIOUSSONG>,
<KEY_PLAYPAUSE>,
<KEY_STOPCD>;
azoteq,gesture-swipe;
azoteq,timeout-swipe-ms = <800>;
azoteq,timeout-tap-ms = <400>;
azoteq,thresh-swipe = <40>;
};
/*
* Preserve the default register settings for
* the temperature-tracking channel leveraged
* by reset user interface (RUI) 1.
*
* Scalar properties (e.g. ATI mode) are left
* untouched by simply omitting them; boolean
* properties must be specified explicitly as
* needed.
*/
generic-2 {
azoteq,reseed-disable;
azoteq,meas-cap-decrease;
azoteq,dual-direction;
azoteq,comp-disable;
azoteq,static-enable;
};
hall {
azoteq,reseed-disable;
azoteq,meas-cap-decrease;
event-touch {
linux,code = <SW_LID>;
};
};
};
};
...

75
Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs5xx.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/azoteq,iqs5xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Azoteq IQS550/572/525 Trackpad/Touchscreen Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
The Azoteq IQS550, IQS572 and IQS525 trackpad and touchscreen controllers
employ projected-capacitance sensing and can track up to five independent
contacts.
Link to datasheet: https://www.azoteq.com/
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
enum:
- azoteq,iqs550
- azoteq,iqs572
- azoteq,iqs525
reg:
maxItems: 1
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
wakeup-source: true
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@74 {
compatible = "azoteq,iqs550";
reg = <0x74>;
interrupt-parent = <&gpio>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH>;
reset-gpios = <&gpio 22 (GPIO_ACTIVE_LOW |
GPIO_PUSH_PULL)>;
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
};
};
...

119
Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml Normal file
View File

@ -0,0 +1,119 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/hycon,hy46xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hycon HY46XX series touchscreen controller bindings
description: |
There are 6 variants of the chip for various touch panel sizes and cover lens material
Glass: 0.3mm--4.0mm
PET/PMMA: 0.2mm--2.0mm
HY4613(B)-N048 < 6"
HY4614(B)-N068 7" .. 10.1"
HY4621-NS32 < 5"
HY4623-NS48 5.1" .. 7"
Glass: 0.3mm--8.0mm
PET/PMMA: 0.2mm--4.0mm
HY4633(B)-N048 < 6"
HY4635(B)-N048 < 7" .. 10.1"
maintainers:
- Giulio Benetti <giulio.benetti@benettiengineering.com>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
enum:
- hycon,hy4613
- hycon,hy4614
- hycon,hy4621
- hycon,hy4623
- hycon,hy4633
- hycon,hy4635
reg:
maxItems: 1
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
vcc-supply: true
hycon,threshold:
description: Allows setting the sensitivity in the range from 0 to 255.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
hycon,glove-enable:
type: boolean
description: Allows enabling glove setting.
hycon,report-speed-hz:
description: Allows setting the report speed in Hertz.
minimum: 1
maximum: 255
hycon,noise-filter-enable:
type: boolean
description: Allows enabling power noise filter.
hycon,filter-data:
description: Allows setting how many samples throw before reporting touch
in the range from 0 to 5.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 5
hycon,gain:
description: Allows setting the sensitivity distance in the range from 0 to 5.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 5
hycon,edge-offset:
description: Allows setting the edge compensation in the range from 0 to 16.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 16
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-fuzz-x: true
touchscreen-fuzz-y: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
interrupt-controller: true
additionalProperties: false
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@1c {
compatible = "hycon,hy4633";
reg = <0x1c>;
interrupt-parent = <&gpio2>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
};
};
...

73
Documentation/devicetree/bindings/input/touchscreen/ilitek_ts_i2c.yaml Normal file
View File

@ -0,0 +1,73 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/ilitek_ts_i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ilitek I2C Touchscreen Controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
enum:
- ilitek,ili2130
- ilitek,ili2131
- ilitek,ili2132
- ilitek,ili2316
- ilitek,ili2322
- ilitek,ili2323
- ilitek,ili2326
- ilitek,ili2520
- ilitek,ili2521
reg:
const: 0x41
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
wakeup-source:
type: boolean
description: touchscreen can be used as a wakeup source.
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
additionalProperties: false
required:
- compatible
- reg
- interrupts
- reset-gpios
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@41 {
compatible = "ilitek,ili2520";
reg = <0x41>;
interrupt-parent = <&gpio1>;
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
touchscreen-inverted-y;
wakeup-source;
};
};

80
Documentation/devicetree/bindings/input/touchscreen/iqs5xx.txt
View File

@ -1,80 +0,0 @@
Azoteq IQS550/572/525 Trackpad/Touchscreen Controller
Required properties:
- compatible : Must be equal to one of the following:
"azoteq,iqs550"
"azoteq,iqs572"
"azoteq,iqs525"
- reg : I2C slave address for the device.
- interrupts : GPIO to which the device's active-high RDY
output is connected (see [0]).
- reset-gpios : GPIO to which the device's active-low NRST
input is connected (see [1]).
Optional properties:
- touchscreen-min-x : See [2].
- touchscreen-min-y : See [2].
- touchscreen-size-x : See [2]. If this property is omitted, the
maximum x-coordinate is specified by the
device's "X Resolution" register.
- touchscreen-size-y : See [2]. If this property is omitted, the
maximum y-coordinate is specified by the
device's "Y Resolution" register.
- touchscreen-max-pressure : See [2]. Pressure is expressed as the sum of
the deltas across all channels impacted by a
touch event. A channel's delta is calculated
as its count value minus a reference, where
the count value is inversely proportional to
the channel's capacitance.
- touchscreen-fuzz-x : See [2].
- touchscreen-fuzz-y : See [2].
- touchscreen-fuzz-pressure : See [2].
- touchscreen-inverted-x : See [2]. Inversion is applied relative to that
which may already be specified by the device's
FLIP_X and FLIP_Y register fields.
- touchscreen-inverted-y : See [2]. Inversion is applied relative to that
which may already be specified by the device's
FLIP_X and FLIP_Y register fields.
- touchscreen-swapped-x-y : See [2]. Swapping is applied relative to that
which may already be specified by the device's
SWITCH_XY_AXIS register field.
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/gpio/gpio.txt
[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Example:
&i2c1 {
/* ... */
touchscreen@74 {
compatible = "azoteq,iqs550";
reg = <0x74>;
interrupt-parent = <&gpio>;
interrupts = <17 4>;
reset-gpios = <&gpio 27 1>;
touchscreen-size-x = <640>;
touchscreen-size-y = <480>;
touchscreen-max-pressure = <16000>;
};
/* ... */
};

87
Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml Normal file
View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/melfas,mms114.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Melfas MMS114 family touchscreen controller bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: touchscreen.yaml#
properties:
$nodename:
pattern: "^touchscreen(@.*)?$"
compatible:
items:
- enum:
- melfas,mms114
- melfas,mms134s
- melfas,mms136
- melfas,mms152
- melfas,mms345l
reg:
description: I2C address
clock-frequency:
description: I2C client clock frequency, defined for host
minimum: 100000
maximum: 400000
interrupts:
maxItems: 1
avdd-supply:
description: Analog power supply regulator on AVDD pin
vdd-supply:
description: Digital power supply regulator on VDD pin
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-fuzz-x: true
touchscreen-fuzz-y: true
touchscreen-fuzz-pressure: true
touchscreen-inverted-x: true
touchscreen-inverted-y: true
touchscreen-swapped-x-y: true
touchscreen-max-pressure: true
additionalProperties: false
required:
- compatible
- reg
- interrupts
- touchscreen-size-x
- touchscreen-size-y
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@48 {
compatible = "melfas,mms114";
reg = <0x48>;
interrupt-parent = <&gpio>;
interrupts = <39 IRQ_TYPE_EDGE_FALLING>;
avdd-supply = <&ldo1_reg>;
vdd-supply = <&ldo2_reg>;
touchscreen-size-x = <720>;
touchscreen-size-y = <1280>;
touchscreen-fuzz-x = <10>;
touchscreen-fuzz-y = <10>;
touchscreen-fuzz-pressure = <10>;
touchscreen-inverted-x;
touchscreen-inverted-y;
};
};
...

42
Documentation/devicetree/bindings/input/touchscreen/mms114.txt
View File

@ -1,42 +0,0 @@
* MELFAS MMS114/MMS152/MMS345L touchscreen controller
Required properties:
- compatible: should be one of:
- "melfas,mms114"
- "melfas,mms152"
- "melfas,mms345l"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- touchscreen-size-x: See [1]
- touchscreen-size-y: See [1]
Optional properties:
- touchscreen-fuzz-x: See [1]
- touchscreen-fuzz-y: See [1]
- touchscreen-fuzz-pressure: See [1]
- touchscreen-inverted-x: See [1]
- touchscreen-inverted-y: See [1]
- touchscreen-swapped-x-y: See [1]
[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Example:
i2c@00000000 {
/* ... */
touchscreen@48 {
compatible = "melfas,mms114";
reg = <0x48>;
interrupts = <39 0>;
touchscreen-size-x = <720>;
touchscreen-size-y = <1280>;
touchscreen-fuzz-x = <10>;
touchscreen-fuzz-y = <10>;
touchscreen-fuzz-pressure = <10>;
touchscreen-inverted-x;
touchscreen-inverted-y;
};
/* ... */
};

69
Documentation/devicetree/bindings/input/touchscreen/mstar,msg2638.yaml Normal file
View File

@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/mstar,msg2638.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MStar msg2638 touchscreen controller Bindings
maintainers:
- Vincent Knecht <vincent.knecht@mailoo.org>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
const: mstar,msg2638
reg:
const: 0x26
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
vdd-supply:
description: Power supply regulator for the chip
vddio-supply:
description: Power supply regulator for the I2C bus
touchscreen-size-x: true
touchscreen-size-y: true
additionalProperties: false
required:
- compatible
- reg
- interrupts
- reset-gpios
- touchscreen-size-x
- touchscreen-size-y
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@26 {
compatible = "mstar,msg2638";
reg = <0x26>;
interrupt-parent = <&msmgpio>;
interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&msmgpio 100 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&ts_int_reset_default>;
vdd-supply = <&pm8916_l17>;
vddio-supply = <&pm8916_l5>;
touchscreen-size-x = <2048>;
touchscreen-size-y = <2048>;
};
};
...

1
Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
View File

@ -92,7 +92,6 @@ properties:
this interconnect to send RPMh commands.
qcom,bcm-voter-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Names for each of the qcom,bcm-voters specified.

4
Documentation/devicetree/bindings/interrupt-controller/idt,32434-pic.yaml
View File

@ -22,6 +22,9 @@ properties:
reg:
maxItems: 1
interrupts:
maxItems: 1
interrupt-controller: true
required:
@ -29,6 +32,7 @@ required:
- compatible
- reg
- interrupt-controller
- interrupts
additionalProperties: false

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

@ -34,6 +34,7 @@ properties:
items:
- enum:
- qcom,sc7180-smmu-500
- qcom,sc7280-smmu-500
- qcom,sc8180x-smmu-500
- qcom,sdm845-smmu-500
- qcom,sm8150-smmu-500

57
Documentation/devicetree/bindings/iommu/sprd,iommu.yaml Normal file
View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright 2020 Unisoc Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Unisoc IOMMU and Multi-media MMU
maintainers:
- Chunyan Zhang <zhang.lyra@gmail.com>
properties:
compatible:
enum:
- sprd,iommu-v1
"#iommu-cells":
const: 0
description:
Unisoc IOMMUs are all single-master IOMMU devices, therefore no
additional information needs to associate with its master device.
Please refer to the generic bindings document for more details,
Documentation/devicetree/bindings/iommu/iommu.txt
reg:
maxItems: 1
clocks:
description:
Reference to a gate clock phandle, since access to some of IOMMUs are
controlled by gate clock, but this is not required.
required:
- compatible
- reg
- "#iommu-cells"
additionalProperties: false
examples:
- |
iommu_disp: iommu@63000800 {
compatible = "sprd,iommu-v1";
reg = <0x63000800 0x80>;
#iommu-cells = <0>;
};
- |
iommu_jpg: iommu@62300300 {
compatible = "sprd,iommu-v1";
reg = <0x62300300 0x80>;
#iommu-cells = <0>;
clocks = <&mm_gate 1>;
};
...

4
Documentation/devicetree/bindings/leds/leds-bcm6328.txt
View File

@ -4,8 +4,8 @@ This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268.
In these SoCs it's possible to control LEDs both as GPIOs or by hardware.
However, on some devices there are Serial LEDs (LEDs connected to a 74x164
controller), which can either be controlled by software (exporting the 74x164
as spi-gpio. See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or
by hardware using this driver.
as spi-gpio. See Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml),
or by hardware using this driver.
Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and
exporting the 74x164 as spi-gpio prevents those LEDs to be hardware
controlled, so the only chance to keep them working is by using this driver.

2
Documentation/devicetree/bindings/leds/leds-bcm6358.txt
View File

@ -3,7 +3,7 @@ LEDs connected to Broadcom BCM6358 controller
This controller is present on BCM6358 and BCM6368.
In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller),
which can either be controlled by software (exporting the 74x164 as spi-gpio.
See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or
See Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), or
by hardware using this driver.
Required properties:

57
Documentation/devicetree/bindings/leds/leds-rt4505.yaml Normal file
View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-rt4505.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Richtek RT4505 Single Channel LED Driver
maintainers:
- ChiYuan Huang <cy_huang@richtek.com>
description: |
The RT4505 is a flash LED driver that can support up to 375mA and 1.5A for
torch and flash mode, respectively.
The data sheet can be found at:
https://www.richtek.com/assets/product_file/RT4505/DS4505-02.pdf
properties:
compatible:
const: richtek,rt4505
reg:
description: I2C slave address of the controller.
maxItems: 1
led:
type: object
$ref: common.yaml#
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
led-controller@63 {
compatible = "richtek,rt4505";
reg = <0x63>;
rt4505_flash: led {
function = LED_FUNCTION_FLASH;
color = <LED_COLOR_ID_WHITE>;
led-max-microamp = <375000>;
flash-max-microamp = <1500000>;
flash-max-timeout-us = <800000>;
};
};
};

20
Documentation/devicetree/bindings/media/renesas,drif.yaml
View File

@ -99,32 +99,26 @@ properties:
Indicates that the channel acts as primary among the bonded channels.
port:
type: object
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
description:
Child port node corresponding to the data input, in accordance with the
video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The port node must contain at least one endpoint.
Child port node corresponding to the data input. The port node must
contain at least one endpoint.
properties:
endpoint:
type: object
$ref: /schemas/graph.yaml#/$defs/endpoint-base
unevaluatedProperties: false
properties:
remote-endpoint:
description:
A phandle to the remote tuner endpoint subnode in remote node
port.
sync-active:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
description:
Indicates sync signal polarity, 0/1 for low/high respectively.
This property maps to SYNCAC bit in the hardware manual. The
default is 1 (active high).
additionalProperties: false
required:
- compatible
- reg

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

@ -193,23 +193,35 @@ required:
- interrupts
- clocks
- power-domains
- resets
if:
properties:
compatible:
contains:
enum:
- renesas,vin-r8a7778
- renesas,vin-r8a7779
- renesas,rcar-gen2-vin
then:
required:
- port
else:
required:
- renesas,id
- ports
allOf:
- if:
not:
properties:
compatible:
contains:
enum:
- renesas,vin-r8a7778
- renesas,vin-r8a7779
then:
required:
- resets
- if:
properties:
compatible:
contains:
enum:
- renesas,vin-r8a7778
- renesas,vin-r8a7779
- renesas,rcar-gen2-vin
then:
required:
- port
else:
required:
- renesas,id
- ports
additionalProperties: false

177
Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml Normal file
View File

@ -0,0 +1,177 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6318-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6318 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6318 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6318-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6318-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6318-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6318-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 50>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@10 {
compatible = "brcm,bcm6318-pinctrl";
reg = <0x18 0x10>, <0x54 0x18>;
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "ephy0_spd_led";
pins = "gpio0";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "ephy1_spd_led";
pins = "gpio1";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "ephy2_spd_led";
pins = "gpio2";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "ephy3_spd_led";
pins = "gpio3";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio4";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio5";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio6";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio7";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio8";
};
pinctrl_inet_fail_led: inet_fail_led-pins {
function = "inet_fail_led";
pins = "gpio9";
};
pinctrl_dsl_led: dsl_led-pins {
function = "dsl_led";
pins = "gpio10";
};
pinctrl_post_fail_led: post_fail_led-pins {
function = "post_fail_led";
pins = "gpio11";
};
pinctrl_wlan_wps_led: wlan_wps_led-pins {
function = "wlan_wps_led";
pins = "gpio12";
};
pinctrl_usb_pwron: usb_pwron-pins {
function = "usb_pwron";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio13";
};
pinctrl_usb_active: usb_active-pins {
function = "usb_active";
pins = "gpio40";
};
};
};

194
Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml Normal file
View File

@ -0,0 +1,194 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm63268-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM63268 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM63268 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm63268-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm63268-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@100000c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm63268-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x100000c0 0x80>;
ranges = <0 0x100000c0 0x80>;
gpio@0 {
compatible = "brcm,bcm63268-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 52>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@10 {
compatible = "brcm,bcm63268-pinctrl";
reg = <0x10 0x4>, <0x18 0x8>, <0x38 0x4>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio0";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio1";
};
};
pinctrl_hsspi_cs4: hsspi_cs4-pins {
function = "hsspi_cs4";
pins = "gpio16";
};
pinctrl_hsspi_cs5: hsspi_cs5-pins {
function = "hsspi_cs5";
pins = "gpio17";
};
pinctrl_hsspi_cs6: hsspi_cs6-pins {
function = "hsspi_cs6";
pins = "gpio8";
};
pinctrl_hsspi_cs7: hsspi_cs7-pins {
function = "hsspi_cs7";
pins = "gpio9";
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio18";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio19";
};
};
pinctrl_vreq_clk: vreq_clk-pins {
function = "vreq_clk";
pins = "gpio22";
};
pinctrl_pcie_clkreq_b: pcie_clkreq_b-pins {
function = "pcie_clkreq_b";
pins = "gpio23";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio30";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio31";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
pinctrl_gpio35_alt: gpio35_alt-pins {
function = "gpio35_alt";
pin = "gpio35";
};
pinctrl_dectpd: dectpd-pins {
function = "dectpd";
group = "dectpd_grp";
};
pinctrl_vdsl_phy_override_0: vdsl_phy_override_0-pins {
function = "vdsl_phy_override_0";
group = "vdsl_phy_override_0_grp";
};
pinctrl_vdsl_phy_override_1: vdsl_phy_override_1-pins {
function = "vdsl_phy_override_1";
group = "vdsl_phy_override_1_grp";
};
pinctrl_vdsl_phy_override_2: vdsl_phy_override_2-pins {
function = "vdsl_phy_override_2";
group = "vdsl_phy_override_2_grp";
};
pinctrl_vdsl_phy_override_3: vdsl_phy_override_3-pins {
function = "vdsl_phy_override_3";
group = "vdsl_phy_override_3_grp";
};
pinctrl_dsl_gpio8: dsl_gpio8-pins {
function = "dsl_gpio8";
group = "dsl_gpio8";
};
pinctrl_dsl_gpio9: dsl_gpio9-pins {
function = "dsl_gpio9";
group = "dsl_gpio9";
};
};
};

162
Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml Normal file
View File

@ -0,0 +1,162 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6328-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6328 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6328 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6328-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6328-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6328-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6328-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 32>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6328-pinctrl";
reg = <0x18 0x10>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio11";
};
pinctrl_pcie_clkreq: pcie_clkreq-pins {
function = "pcie_clkreq";
pins = "gpio16";
};
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "led";
pins = "gpio17";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "led";
pins = "gpio18";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "led";
pins = "gpio19";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "led";
pins = "gpio20";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio25";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio26";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio27";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio28";
};
pinctrl_hsspi_cs1: hsspi_cs1-pins {
function = "hsspi_cs1";
pins = "hsspi_cs1";
};
pinctrl_usb_port1_device: usb_port1_device-pins {
function = "usb_device_port";
pins = "usb_port1";
};
pinctrl_usb_port1_host: usb_port1_host-pins {
function = "usb_host_port";
pins = "usb_port1";
};
};
};

130
Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml Normal file
View File

@ -0,0 +1,130 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6358-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6358 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6358 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6358-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6358-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@fffe0080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6358-gpio-sysctl", "syscon", "simple-mfd";
reg = <0xfffe0080 0x80>;
ranges = <0 0xfffe0080 0x80>;
gpio@0 {
compatible = "brcm,bcm6358-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 40>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6358-pinctrl";
reg = <0x18 0x4>;
pinctrl_ebi_cs: ebi_cs-pins {
function = "ebi_cs";
groups = "ebi_cs_grp";
};
pinctrl_uart1: uart1-pins {
function = "uart1";
groups = "uart1_grp";
};
pinctrl_serial_led: serial_led-pins {
function = "serial_led";
groups = "serial_led_grp";
};
pinctrl_legacy_led: legacy_led-pins {
function = "legacy_led";
groups = "legacy_led_grp";
};
pinctrl_led: led-pins {
function = "led";
groups = "led_grp";
};
pinctrl_spi_cs_23: spi_cs-pins {
function = "spi_cs";
groups = "spi_cs_grp";
};
pinctrl_utopia: utopia-pins {
function = "utopia";
groups = "utopia_grp";
};
pinctrl_pwm_syn_clk: pwm_syn_clk-pins {
function = "pwm_syn_clk";
groups = "pwm_syn_clk_grp";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
groups = "sys_irq_grp";
};
};
};

236
Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml Normal file
View File

@ -0,0 +1,236 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6362-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6362 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6362 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6362-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6362-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6362-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6362-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 48>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6362-pinctrl";
reg = <0x18 0x10>, <0x38 0x4>;
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio0";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
pins = "gpio1";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio2";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio3";
};
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio4";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio5";
};
pinctrl_robosw_led0: robosw_led0-pins {
function = "robosw_led0";
pins = "gpio6";
};
pinctrl_robosw_led1: robosw_led1-pins {
function = "robosw_led1";
pins = "gpio7";
};
pinctrl_inet_led: inet_led-pins {
function = "inet_led";
pins = "gpio8";
};
pinctrl_spi_cs2: spi_cs2-pins {
function = "spi_cs2";
pins = "gpio9";
};
pinctrl_spi_cs3: spi_cs3-pins {
function = "spi_cs3";
pins = "gpio10";
};
pinctrl_ntr_pulse: ntr_pulse-pins {
function = "ntr_pulse";
pins = "gpio11";
};
pinctrl_uart1_scts: uart1_scts-pins {
function = "uart1_scts";
pins = "gpio12";
};
pinctrl_uart1_srts: uart1_srts-pins {
function = "uart1_srts";
pins = "gpio13";
};
pinctrl_uart1: uart1-pins {
pinctrl_uart1_sdin: uart1_sdin-pins {
function = "uart1_sdin";
pins = "gpio14";
};
pinctrl_uart1_sdout: uart1_sdout-pins {
function = "uart1_sdout";
pins = "gpio15";
};
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio16";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio17";
};
pinctrl_adsl_spi_clk: adsl_spi_clk-pins {
function = "adsl_spi_clk";
pins = "gpio18";
};
pinctrl_adsl_spi_cs: adsl_spi_cs-pins {
function = "adsl_spi_cs";
pins = "gpio19";
};
};
pinctrl_ephy0_led: ephy0_led-pins {
function = "ephy0_led";
pins = "gpio20";
};
pinctrl_ephy1_led: ephy1_led-pins {
function = "ephy1_led";
pins = "gpio21";
};
pinctrl_ephy2_led: ephy2_led-pins {
function = "ephy2_led";
pins = "gpio22";
};
pinctrl_ephy3_led: ephy3_led-pins {
function = "ephy3_led";
pins = "gpio23";
};
pinctrl_ext_irq0: ext_irq0-pins {
function = "ext_irq0";
pins = "gpio24";
};
pinctrl_ext_irq1: ext_irq1-pins {
function = "ext_irq1";
pins = "gpio25";
};
pinctrl_ext_irq2: ext_irq2-pins {
function = "ext_irq2";
pins = "gpio26";
};
pinctrl_ext_irq3: ext_irq3-pins {
function = "ext_irq3";
pins = "gpio27";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
};
};

246
Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml Normal file
View File

@ -0,0 +1,246 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,bcm6368-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6368 GPIO System Controller Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Broadcom BCM6368 SoC GPIO system controller which provides a register map
for controlling the GPIO and pins of the SoC.
properties:
"#address-cells": true
"#size-cells": true
compatible:
items:
- const: brcm,bcm6368-gpio-sysctl
- const: syscon
- const: simple-mfd
ranges:
maxItems: 1
reg:
maxItems: 1
patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
$ref: "../gpio/brcm,bcm6345-gpio.yaml"
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
$ref: "../pinctrl/brcm,bcm6368-pinctrl.yaml"
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml.
required:
- "#address-cells"
- compatible
- ranges
- reg
- "#size-cells"
additionalProperties: false
examples:
- |
syscon@10000080 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "brcm,bcm6368-gpio-sysctl", "syscon", "simple-mfd";
reg = <0x10000080 0x80>;
ranges = <0 0x10000080 0x80>;
gpio@0 {
compatible = "brcm,bcm6368-gpio";
reg-names = "dirout", "dat";
reg = <0x0 0x8>, <0x8 0x8>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 38>;
#gpio-cells = <2>;
};
pinctrl: pinctrl@18 {
compatible = "brcm,bcm6368-pinctrl";
reg = <0x18 0x4>, <0x38 0x4>;
pinctrl_analog_afe_0: analog_afe_0-pins {
function = "analog_afe_0";
pins = "gpio0";
};
pinctrl_analog_afe_1: analog_afe_1-pins {
function = "analog_afe_1";
pins = "gpio1";
};
pinctrl_sys_irq: sys_irq-pins {
function = "sys_irq";
pins = "gpio2";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio3";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio4";
};
};
pinctrl_inet_led: inet_led-pins {
function = "inet_led";
pins = "gpio5";
};
pinctrl_ephy0_led: ephy0_led-pins {
function = "ephy0_led";
pins = "gpio6";
};
pinctrl_ephy1_led: ephy1_led-pins {
function = "ephy1_led";
pins = "gpio7";
};
pinctrl_ephy2_led: ephy2_led-pins {
function = "ephy2_led";
pins = "gpio8";
};
pinctrl_ephy3_led: ephy3_led-pins {
function = "ephy3_led";
pins = "gpio9";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio10";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio11";
};
pinctrl_robosw_led0: robosw_led0-pins {
function = "robosw_led0";
pins = "gpio12";
};
pinctrl_robosw_led1: robosw_led1-pins {
function = "robosw_led1";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio14";
};
pinctrl_pci: pci-pins {
pinctrl_pci_req1: pci_req1-pins {
function = "pci_req1";
pins = "gpio16";
};
pinctrl_pci_gnt1: pci_gnt1-pins {
function = "pci_gnt1";
pins = "gpio17";
};
pinctrl_pci_intb: pci_intb-pins {
function = "pci_intb";
pins = "gpio18";
};
pinctrl_pci_req0: pci_req0-pins {
function = "pci_req0";
pins = "gpio19";
};
pinctrl_pci_gnt0: pci_gnt0-pins {
function = "pci_gnt0";
pins = "gpio20";
};
};
pinctrl_pcmcia: pcmcia-pins {
pinctrl_pcmcia_cd1: pcmcia_cd1-pins {
function = "pcmcia_cd1";
pins = "gpio22";
};
pinctrl_pcmcia_cd2: pcmcia_cd2-pins {
function = "pcmcia_cd2";
pins = "gpio23";
};
pinctrl_pcmcia_vs1: pcmcia_vs1-pins {
function = "pcmcia_vs1";
pins = "gpio24";
};
pinctrl_pcmcia_vs2: pcmcia_vs2-pins {
function = "pcmcia_vs2";
pins = "gpio25";
};
};
pinctrl_ebi_cs2: ebi_cs2-pins {
function = "ebi_cs2";
pins = "gpio26";
};
pinctrl_ebi_cs3: ebi_cs3-pins {
function = "ebi_cs3";
pins = "gpio27";
};
pinctrl_spi_cs2: spi_cs2-pins {
function = "spi_cs2";
pins = "gpio28";
};
pinctrl_spi_cs3: spi_cs3-pins {
function = "spi_cs3";
pins = "gpio29";
};
pinctrl_spi_cs4: spi_cs4-pins {
function = "spi_cs4";
pins = "gpio30";
};
pinctrl_spi_cs5: spi_cs5-pins {
function = "spi_cs5";
pins = "gpio31";
};
pinctrl_uart1: uart1-pins {
function = "uart1";
group = "uart1_grp";
};
};
};

38
Documentation/devicetree/bindings/mtd/tango-nand.txt
View File

@ -1,38 +0,0 @@
Sigma Designs Tango4 NAND Flash Controller (NFC)
Required properties:
- compatible: "sigma,smp8758-nand"
- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
- dmas: reference to the DMA channel used by the controller
- dma-names: "rxtx"
- clocks: reference to the system clock
- #address-cells: <1>
- #size-cells: <0>
Children nodes represent the available NAND chips.
See Documentation/devicetree/bindings/mtd/nand-controller.yaml for generic bindings.
Example:
nandc: nand-controller@2c000 {
compatible = "sigma,smp8758-nand";
reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
dmas = <&dma0 3>;
dma-names = "rxtx";
clocks = <&clkgen SYS_CLK>;
#address-cells = <1>;
#size-cells = <0>;
nand@0 {
reg = <0>; /* CS0 */
nand-ecc-strength = <14>;
nand-ecc-step-size = <1024>;
};
nand@1 {
reg = <1>; /* CS1 */
nand-ecc-strength = <14>;
nand-ecc-step-size = <1024>;
};
};

1
Documentation/devicetree/bindings/net/qcom,ipa.yaml
View File

@ -105,7 +105,6 @@ properties:
- description: Whether the IPA clock is enabled (if valid)
qcom,smem-state-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: The names of the state bits used for SMP2P output
items:
- const: ipa-clock-enabled-valid

2
Documentation/devicetree/bindings/net/renesas,ether.yaml
View File

@ -10,7 +10,7 @@ allOf:
- $ref: ethernet-controller.yaml#
maintainers:
- Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
- Sergei Shtylyov <sergei.shtylyov@gmail.com>
properties:
compatible:

2
Documentation/devicetree/bindings/net/renesas,etheravb.yaml
View File

@ -51,12 +51,12 @@ properties:
clocks:
minItems: 1
maxItems: 2
items:
- description: AVB functional clock
- description: Optional TXC reference clock
clock-names:
minItems: 1
items:
- const: fck
- const: refclk

1
Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
View File

@ -9,7 +9,6 @@ Required properties:
"mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
"mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
"mediatek,mt8516-efuse", "mediatek,efuse": for MT8516
"mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
- reg: Should contain registers location and length
= Data cells =

43
Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
View File

@ -1,43 +0,0 @@
HiSilicon Hip05 and Hip06 PCIe host bridge DT description
HiSilicon PCIe host controller is based on the Synopsys DesignWare PCI core.
It shares common functions with the PCIe DesignWare core driver and inherits
common properties defined in
Documentation/devicetree/bindings/pci/designware-pcie.txt.
Additional properties are described here:
Required properties
- compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
- reg: Should contain rc_dbi, config registers location and length.
- reg-names: Must include the following entries:
"rc_dbi": controller configuration registers;
"config": PCIe configuration space registers.
- msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
- port-id: Should be 0, 1, 2 or 3.
Optional properties:
- status: Either "ok" or "disabled".
- dma-coherent: Present if DMA operations are coherent.
Hip05 Example (note that Hip06 is the same except compatible):
pcie@b0080000 {
compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
reg-names = "rc_dbi", "config";
bus-range = <0 15>;
msi-parent = <&its_pcie>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
dma-coherent;
ranges = <0x82000000 0 0x00000000 0x220 0x00000000 0 0x10000000>;
num-lanes = <8>;
port-id = <1>;
#interrupt-cells = <1>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x0 0 0 1 &mbigen_pcie 1 10
0x0 0 0 2 &mbigen_pcie 2 11
0x0 0 0 3 &mbigen_pcie 3 12
0x0 0 0 4 &mbigen_pcie 4 13>;
};

181
Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml Normal file
View File

@ -0,0 +1,181 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/mediatek-pcie-gen3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Gen3 PCIe controller on MediaTek SoCs
maintainers:
- Jianjun Wang <jianjun.wang@mediatek.com>
description: |+
PCIe Gen3 MAC controller for MediaTek SoCs, it supports Gen3 speed
and compatible with Gen2, Gen1 speed.
This PCIe controller supports up to 256 MSI vectors, the MSI hardware
block diagram is as follows:
+-----+
| GIC |
+-----+
^
|
port->irq
|
+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7| (PCIe intc)
+-+-+-+-+-+-+-+-+
^ ^ ^
| | ... |
+-------+ +------+ +-----------+
| | |
+-+-+---+--+--+ +-+-+---+--+--+ +-+-+---+--+--+
|0|1|...|30|31| |0|1|...|30|31| |0|1|...|30|31| (MSI sets)
+-+-+---+--+--+ +-+-+---+--+--+ +-+-+---+--+--+
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | | (MSI vectors)
| | | | | | | | | | | |
(MSI SET0) (MSI SET1) ... (MSI SET7)
With 256 MSI vectors supported, the MSI vectors are composed of 8 sets,
each set has its own address for MSI message, and supports 32 MSI vectors
to generate interrupt.
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
properties:
compatible:
const: mediatek,mt8192-pcie
reg:
maxItems: 1
reg-names:
items:
- const: pcie-mac
interrupts:
maxItems: 1
ranges:
minItems: 1
maxItems: 8
resets:
minItems: 1
maxItems: 2
reset-names:
minItems: 1
maxItems: 2
items:
- const: phy
- const: mac
clocks:
maxItems: 6
clock-names:
items:
- const: pl_250m
- const: tl_26m
- const: tl_96m
- const: tl_32k
- const: peri_26m
- const: top_133m
assigned-clocks:
maxItems: 1
assigned-clock-parents:
maxItems: 1
phys:
maxItems: 1
'#interrupt-cells':
const: 1
interrupt-controller:
description: Interrupt controller node for handling legacy PCI interrupts.
type: object
properties:
'#address-cells':
const: 0
'#interrupt-cells':
const: 1
interrupt-controller: true
required:
- '#address-cells'
- '#interrupt-cells'
- interrupt-controller
additionalProperties: false
required:
- compatible
- reg
- reg-names
- interrupts
- ranges
- clocks
- '#interrupt-cells'
- interrupt-controller
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
pcie: pcie@11230000 {
compatible = "mediatek,mt8192-pcie";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
reg = <0x00 0x11230000 0x00 0x4000>;
reg-names = "pcie-mac";
interrupts = <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH 0>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0x00 0x12000000 0x00
0x12000000 0x00 0x1000000>;
clocks = <&infracfg 44>,
<&infracfg 40>,
<&infracfg 43>,
<&infracfg 97>,
<&infracfg 99>,
<&infracfg 111>;
clock-names = "pl_250m", "tl_26m", "tl_96m",
"tl_32k", "peri_26m", "top_133m";
assigned-clocks = <&topckgen 50>;
assigned-clock-parents = <&topckgen 91>;
phys = <&pciephy>;
phy-names = "pcie-phy";
resets = <&infracfg_rst 2>,
<&infracfg_rst 3>;
reset-names = "phy", "mac";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &pcie_intc 0>,
<0 0 0 2 &pcie_intc 1>,
<0 0 0 3 &pcie_intc 2>,
<0 0 0 4 &pcie_intc 3>;
pcie_intc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
};
};
};

12
Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
View File

@ -17,6 +17,7 @@ allOf:
properties:
compatible:
oneOf:
- const: renesas,pcie-r8a7779 # R-Car H1
- items:
- enum:
- renesas,pcie-r8a7742 # RZ/G1H
@ -74,7 +75,16 @@ required:
- clocks
- clock-names
- power-domains
- resets
if:
not:
properties:
compatible:
contains:
const: renesas,pcie-r8a7779
then:
required:
- resets
unevaluatedProperties: false

113
Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml Normal file
View File

@ -0,0 +1,113 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/sifive,fu740-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SiFive FU740 PCIe host controller
description: |+
SiFive FU740 PCIe host controller is based on the Synopsys DesignWare
PCI core. It shares common features with the PCIe DesignWare core and
inherits common properties defined in
Documentation/devicetree/bindings/pci/designware-pcie.txt.
maintainers:
- Paul Walmsley <paul.walmsley@sifive.com>
- Greentime Hu <greentime.hu@sifive.com>
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
properties:
compatible:
const: sifive,fu740-pcie
reg:
maxItems: 3
reg-names:
items:
- const: dbi
- const: config
- const: mgmt
num-lanes:
const: 8
msi-parent: true
interrupt-names:
items:
- const: msi
- const: inta
- const: intb
- const: intc
- const: intd
resets:
description: A phandle to the PCIe power up reset line.
maxItems: 1
pwren-gpios:
description: Should specify the GPIO for controlling the PCI bus device power on.
maxItems: 1
reset-gpios:
maxItems: 1
required:
- dma-coherent
- num-lanes
- interrupts
- interrupt-names
- interrupt-parent
- interrupt-map-mask
- interrupt-map
- clock-names
- clocks
- resets
- pwren-gpios
- reset-gpios
unevaluatedProperties: false
examples:
- |
bus {
#address-cells = <2>;
#size-cells = <2>;
#include <dt-bindings/clock/sifive-fu740-prci.h>
pcie@e00000000 {
compatible = "sifive,fu740-pcie";
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
reg = <0xe 0x00000000 0x0 0x80000000>,
<0xd 0xf0000000 0x0 0x10000000>,
<0x0 0x100d0000 0x0 0x1000>;
reg-names = "dbi", "config", "mgmt";
device_type = "pci";
dma-coherent;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x60080000 0x0 0x60080000 0x0 0x10000>, /* I/O */
<0x82000000 0x0 0x60090000 0x0 0x60090000 0x0 0xff70000>, /* mem */
<0x82000000 0x0 0x70000000 0x0 0x70000000 0x0 0x1000000>, /* mem */
<0xc3000000 0x20 0x00000000 0x20 0x00000000 0x20 0x00000000>; /* mem prefetchable */
num-lanes = <0x8>;
interrupts = <56>, <57>, <58>, <59>, <60>, <61>, <62>, <63>, <64>;
interrupt-names = "msi", "inta", "intb", "intc", "intd";
interrupt-parent = <&plic0>;
interrupt-map-mask = <0x0 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 &plic0 57>,
<0x0 0x0 0x0 0x2 &plic0 58>,
<0x0 0x0 0x0 0x3 &plic0 59>,
<0x0 0x0 0x0 0x4 &plic0 60>;
clock-names = "pcie_aux";
clocks = <&prci PRCI_CLK_PCIE_AUX>;
resets = <&prci 4>;
pwren-gpios = <&gpio 5 0>;
reset-gpios = <&gpio 8 0>;
};
};

29
Documentation/devicetree/bindings/pci/tango-pcie.txt
View File

@ -1,29 +0,0 @@
Sigma Designs Tango PCIe controller
Required properties:
- compatible: "sigma,smp8759-pcie"
- reg: address/size of PCI configuration space, address/size of register area
- bus-range: defined by size of PCI configuration space
- device_type: "pci"
- #size-cells: <2>
- #address-cells: <3>
- msi-controller
- ranges: translation from system to bus addresses
- interrupts: spec for misc interrupts, spec for MSI
Example:
pcie@2e000 {
compatible = "sigma,smp8759-pcie";
reg = <0x50000000 0x400000>, <0x2e000 0x100>;
bus-range = <0 3>;
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
msi-controller;
ranges = <0x02000000 0x0 0x00400000 0x50400000 0x0 0x3c00000>;
interrupts =
<54 IRQ_TYPE_LEVEL_HIGH>, /* misc interrupts */
<55 IRQ_TYPE_LEVEL_HIGH>; /* MSI */
};

9
Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
View File

@ -16,13 +16,15 @@ allOf:
properties:
compatible:
oneOf:
- const: ti,j721e-pcie-ep
- description: PCIe EP controller in AM64
items:
- const: ti,am64-pcie-ep
- const: ti,j721e-pcie-ep
- description: PCIe EP controller in J7200
items:
- const: ti,j7200-pcie-ep
- const: ti,j721e-pcie-ep
- description: PCIe EP controller in J721E
items:
- const: ti,j721e-pcie-ep
reg:
maxItems: 4
@ -66,7 +68,6 @@ required:
- power-domains
- clocks
- clock-names
- dma-coherent
- max-functions
- phys
- phy-names

20
Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
View File

@ -16,13 +16,15 @@ allOf:
properties:
compatible:
oneOf:
- const: ti,j721e-pcie-host
- description: PCIe controller in AM64
items:
- const: ti,am64-pcie-host
- const: ti,j721e-pcie-host
- description: PCIe controller in J7200
items:
- const: ti,j7200-pcie-host
- const: ti,j721e-pcie-host
- description: PCIe controller in J721E
items:
- const: ti,j721e-pcie-host
reg:
maxItems: 4
@ -46,12 +48,17 @@ properties:
maxItems: 1
clocks:
maxItems: 1
description: clock-specifier to represent input to the PCIe
minItems: 1
maxItems: 2
description: |+
clock-specifier to represent input to the PCIe for 1 item.
2nd item if present represents reference clock to the connector.
clock-names:
minItems: 1
items:
- const: fck
- const: pcie_refclk
vendor-id:
const: 0x104c
@ -62,6 +69,8 @@ properties:
- const: 0xb00d
- items:
- const: 0xb00f
- items:
- const: 0xb010
msi-map: true
@ -78,7 +87,6 @@ required:
- vendor-id
- device-id
- msi-map
- dma-coherent
- dma-ranges
- ranges
- reset-gpios

2
Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
View File

@ -33,6 +33,8 @@ Required properties:
- #address-cells: specifies the number of cells needed to encode an
address. The value must be 0.
Optional properties:
- dma-coherent: present if DMA operations are coherent
Example:
++++++++

2
Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
View File

@ -118,7 +118,7 @@ patternProperties:
description:
Specifies the Spread Spectrum Clocking mode used. It can be NO_SSC,
EXTERNAL_SSC or INTERNAL_SSC.
Refer include/dt-bindings/phy/phy-cadence-torrent.h for the constants to be used.
Refer include/dt-bindings/phy/phy-cadence.h for the constants to be used.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
default: 0

143
Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml Normal file
View File

@ -0,0 +1,143 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6318-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6318 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6318 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6318-pinctrl
reg:
maxItems: 2
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ ephy0_spd_led, ephy1_spd_led, ephy2_spd_led, ephy3_spd_led,
ephy0_act_led, ephy1_act_led, ephy2_act_led, ephy3_act_led,
serial_led_data, serial_led_clk, inet_act_led, inet_fail_led,
dsl_led, post_fail_led, wlan_wps_led, usb_pwron,
usb_device_led, usb_active ]
pins:
enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7,
gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio40 ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6318-pinctrl";
reg = <0x18 0x10>, <0x54 0x18>;
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "ephy0_spd_led";
pins = "gpio0";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "ephy1_spd_led";
pins = "gpio1";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "ephy2_spd_led";
pins = "gpio2";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "ephy3_spd_led";
pins = "gpio3";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio4";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio5";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio6";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio7";
};
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio8";
};
pinctrl_inet_fail_led: inet_fail_led-pins {
function = "inet_fail_led";
pins = "gpio9";
};
pinctrl_dsl_led: dsl_led-pins {
function = "dsl_led";
pins = "gpio10";
};
pinctrl_post_fail_led: post_fail_led-pins {
function = "post_fail_led";
pins = "gpio11";
};
pinctrl_wlan_wps_led: wlan_wps_led-pins {
function = "wlan_wps_led";
pins = "gpio12";
};
pinctrl_usb_pwron: usb_pwron-pins {
function = "usb_pwron";
pins = "gpio13";
};
pinctrl_usb_device_led: usb_device_led-pins {
function = "usb_device_led";
pins = "gpio13";
};
pinctrl_usb_active: usb_active-pins {
function = "usb_active";
pins = "gpio40";
};
};

164
Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml Normal file
View File

@ -0,0 +1,164 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm63268-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM63268 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM63268 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm63268-pinctrl
reg:
maxItems: 3
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ serial_led_clk, serial_led_data, hsspi_cs4, hsspi_cs5,
hsspi_cs6, hsspi_cs7, adsl_spi_miso, adsl_spi_mosi,
vreq_clk, pcie_clkreq_b, robosw_led_clk, robosw_led_data,
nand, gpio35_alt, dectpd, vdsl_phy_override_0,
vdsl_phy_override_1, vdsl_phy_override_2,
vdsl_phy_override_3, dsl_gpio8, dsl_gpio9 ]
pins:
enum: [ gpio0, gpio1, gpio16, gpio17, gpio8, gpio9, gpio18, gpio19,
gpio22, gpio23, gpio30, gpio31, nand_grp, gpio35
dectpd_grp, vdsl_phy_override_0_grp,
vdsl_phy_override_1_grp, vdsl_phy_override_2_grp,
vdsl_phy_override_3_grp, dsl_gpio8, dsl_gpio9 ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@10 {
compatible = "brcm,bcm63268-pinctrl";
reg = <0x10 0x4>, <0x18 0x8>, <0x38 0x4>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio0";
};
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio1";
};
};
pinctrl_hsspi_cs4: hsspi_cs4-pins {
function = "hsspi_cs4";
pins = "gpio16";
};
pinctrl_hsspi_cs5: hsspi_cs5-pins {
function = "hsspi_cs5";
pins = "gpio17";
};
pinctrl_hsspi_cs6: hsspi_cs6-pins {
function = "hsspi_cs6";
pins = "gpio8";
};
pinctrl_hsspi_cs7: hsspi_cs7-pins {
function = "hsspi_cs7";
pins = "gpio9";
};
pinctrl_adsl_spi: adsl_spi-pins {
pinctrl_adsl_spi_miso: adsl_spi_miso-pins {
function = "adsl_spi_miso";
pins = "gpio18";
};
pinctrl_adsl_spi_mosi: adsl_spi_mosi-pins {
function = "adsl_spi_mosi";
pins = "gpio19";
};
};
pinctrl_vreq_clk: vreq_clk-pins {
function = "vreq_clk";
pins = "gpio22";
};
pinctrl_pcie_clkreq_b: pcie_clkreq_b-pins {
function = "pcie_clkreq_b";
pins = "gpio23";
};
pinctrl_robosw_led_clk: robosw_led_clk-pins {
function = "robosw_led_clk";
pins = "gpio30";
};
pinctrl_robosw_led_data: robosw_led_data-pins {
function = "robosw_led_data";
pins = "gpio31";
};
pinctrl_nand: nand-pins {
function = "nand";
group = "nand_grp";
};
pinctrl_gpio35_alt: gpio35_alt-pins {
function = "gpio35_alt";
pin = "gpio35";
};
pinctrl_dectpd: dectpd-pins {
function = "dectpd";
group = "dectpd_grp";
};
pinctrl_vdsl_phy_override_0: vdsl_phy_override_0-pins {
function = "vdsl_phy_override_0";
group = "vdsl_phy_override_0_grp";
};
pinctrl_vdsl_phy_override_1: vdsl_phy_override_1-pins {
function = "vdsl_phy_override_1";
group = "vdsl_phy_override_1_grp";
};
pinctrl_vdsl_phy_override_2: vdsl_phy_override_2-pins {
function = "vdsl_phy_override_2";
group = "vdsl_phy_override_2_grp";
};
pinctrl_vdsl_phy_override_3: vdsl_phy_override_3-pins {
function = "vdsl_phy_override_3";
group = "vdsl_phy_override_3_grp";
};
pinctrl_dsl_gpio8: dsl_gpio8-pins {
function = "dsl_gpio8";
group = "dsl_gpio8";
};
pinctrl_dsl_gpio9: dsl_gpio9-pins {
function = "dsl_gpio9";
group = "dsl_gpio9";
};
};

127
Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml Normal file
View File

@ -0,0 +1,127 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6328-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM6328 pin controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
- Jonas Gorski <jonas.gorski@gmail.com>
description:
Bindings for Broadcom's BCM6328 memory-mapped pin controller.
properties:
compatible:
const: brcm,bcm6328-pinctrl
reg:
maxItems: 1
patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
properties:
function:
enum: [ serial_led_data, serial_led_clk, inet_act_led, pcie_clkreq,
led, ephy0_act_led, ephy1_act_led, ephy2_act_led,
ephy3_act_led, hsspi_cs1, usb_device_port, usb_host_port ]
pins:
enum: [ gpio6, gpio7, gpio11, gpio16, gpio17, gpio18, gpio19,
gpio20, gpio25, gpio26, gpio27, gpio28, hsspi_cs1,
usb_port1 ]
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pinctrl@18 {
compatible = "brcm,bcm6328-pinctrl";
reg = <0x18 0x10>;
pinctrl_serial_led: serial_led-pins {
pinctrl_serial_led_data: serial_led_data-pins {
function = "serial_led_data";
pins = "gpio6";
};
pinctrl_serial_led_clk: serial_led_clk-pins {
function = "serial_led_clk";
pins = "gpio7";
};
};
pinctrl_inet_act_led: inet_act_led-pins {
function = "inet_act_led";
pins = "gpio11";
};
pinctrl_pcie_clkreq: pcie_clkreq-pins {
function = "pcie_clkreq";
pins = "gpio16";
};
pinctrl_ephy0_spd_led: ephy0_spd_led-pins {
function = "led";
pins = "gpio17";
};
pinctrl_ephy1_spd_led: ephy1_spd_led-pins {
function = "led";
pins = "gpio18";
};
pinctrl_ephy2_spd_led: ephy2_spd_led-pins {
function = "led";
pins = "gpio19";
};
pinctrl_ephy3_spd_led: ephy3_spd_led-pins {
function = "led";
pins = "gpio20";
};
pinctrl_ephy0_act_led: ephy0_act_led-pins {
function = "ephy0_act_led";
pins = "gpio25";
};
pinctrl_ephy1_act_led: ephy1_act_led-pins {
function = "ephy1_act_led";
pins = "gpio26";
};
pinctrl_ephy2_act_led: ephy2_act_led-pins {
function = "ephy2_act_led";
pins = "gpio27";
};
pinctrl_ephy3_act_led: ephy3_act_led-pins {
function = "ephy3_act_led";
pins = "gpio28";
};
pinctrl_hsspi_cs1: hsspi_cs1-pins {
function = "hsspi_cs1";
pins = "hsspi_cs1";
};
pinctrl_usb_port1_device: usb_port1_device-pins {
function = "usb_device_port";
pins = "usb_port1";
};
pinctrl_usb_port1_host: usb_port1_host-pins {
function = "usb_host_port";
pins = "usb_port1";
};
};

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